j_not_j

If it's a matter of life and death, such as offshore fishing, you probably want a real commercial service.

Like Garmin (Iridium based texts back and forth) or Zoleo. These are physical units that may offer texts or just a simple "sos" button.

Or a recent iPhone will communicate with Starlink, or T-Mobile offers a similar system for Android phones and is also based on Starlink. These can exchange texts which is much more reassuring than a simple sos button.

Of course offerings outside the US may be limited or entirely absent.

I was part of a group touring HP labs in the mid-1970s.

They showed us how they computed the key dimensions and typography with an (HP) minicomputer, then had it print out the commands for some kind of numerically controlled cutting machine on paper tapes using an old ASR33 teletype.

The cutting machine generated moulds for the injection moulding machines making the keys.

The keys are in two parts: light coloured digits and symbols and darker plastic forming the shape of the key itself and surrounding the lighter symbol plastic. As a result, they can be worn down but they can never wear out.

Went for a walk today.

Found a $100 bill in the grass. No-one nearby to think it might belong to them.

Alpha had a lot of implementation problems, e.g. floating point exceptions with untraceable execution paths.

Cray tried to build the T3E (iirc) out of Alphas. DEC bragged how good Alpha was for parallel computing, big memory etc etc.

But Cray publicly denounced Alpha as unusable for parallel processing (the T3E was a bunch of Alphas in some kind of NUMA shared memory.) It was so difficult to make the chips work together.

This was in the Cray Connect or some such glossy publication. Wish I'd kept a copy.

Plus of course the usual DEC marketing incompetence. They feared Alpha undoing their large expensive machine momentum. Small workstation boxes significantly faster than big iron.

Ascending is all you need.

"wet coast"

Slang for BC. It's a joke, because (coastal) BC is mostly wet. And BC is the westernmost province.

"brown toast".

When ordering breakfast, such as eggs and toast. "You want white or brown toast?"

Since most toast is toasted to a brown tone, the question confuses Americans (west-coast, anyways).

It's really the question: white bread toast or whole-wheat bread toast?

"off-sale" at a licensed premises means sale for off-premise consumption.

In BC.

Wouldn't be worth the trouble to try.

Why, you ask?

How do you point it? Where do you point it?

You have a "telescope" with a field of view of one-planets worth of pixels. But the planet is in orbit, so it drifts away from the imaged field of view within minutes.

Meanwhile your sensor is travelling away from the "lens" so transverse velocity would be needed to track the orbit at a delta-v and direction that is unknowable. Unknowable, because you have to know where the planet is, within a radius, to put your "sensor" in the right place in the first place.

Imagine taking a straw, place it in a tree, walk away a few km and focus a telescope on the straw and hope to look through the straw to see an airplane flying past. You have the same set of unknowables.

Beebe publishes a lengthy bibliography.

https://www.netlib.org/tex/bib/prng.pdf

758 pages and counting....

Downey published a (big-endian, SPARC) method in 2007:

https://allendowney.com/research/rand/

And Lemire in 2017 asked the question

https://lemire.me/blog/2017/02/28/how-many-floating-point-nu...

The basic approach: collect top 60 bits of a 64-bit PRNG. (Assume the LSBs are corrupt or zero or nonrandom). Set exponent zero. If the top mantissa bit is zero, shift left, subtract one from exponent. Repeat. When you run out of bits, collect another PRNG from your generator and resume until you have 56 bits of mantissa. When done, your floating-point PRNG is 2^exponent * mantissa.

My short explanation: Suppose you want a random distance. Multiplying a PR integer is the same as selecting a random tile in the distance, and measuring the distance to the (far) edge of the tile. This is the multiply method.

But if you want a real-valued distance even for very near distances, you need to scale your random number and ensure you have random bits throughout the mantissa. So reduce the exponent for every leading zero in your PR integer and shift. Add more bits if needed.

Test: the histogram of exponents for a large-enough set of samples is linear, give or take. Very small floating numbers (less than say 1/32768) are 1/16 as likely as numbers in [0.5,1).

Some comments, in random order:

- your test codes are not reproducible: running twice generates different sets of numbers because they have unknown seeds. As a result, if you change (a) compilers or compiler switches, (b) operating system versions, (c) host processors or (d) architectures, the question arises: what is wrong? What is different? This is known as a regression test.

- try shishua as another speedy PRNG. See https://espadrine.github.io/blog/posts/shishua-the-fastest-p...

- You only test a few times? I think one hundred BigCrush tests, using a set of 100 seeds, would be suitable. Takes a few days on an RPI 4 (with cooler). Run the same 100 tests on a Ryzen and Xeon, just to be sure. They should be bit-for-bit identical.

- 100 BigCrush tests should show only a handful (4 or fewer) duplicate test failures.

- your seeds are almost great: too many people think "42" is random in a space of 0 through 2^64. But 0xdeadbeef is so 1990s...

- you don't need different seeds per PRNG; you can generate reproducible ones (2x to 4x 64bit) from a single good 64-bit seed and your favourite PRNG. Your test code should read a seed or set from the command line (see first item).

- warmups? Really?

- Remember that BigCrush and other tests are created by mathematical people not practical people. Do they test for equal numbers of odd and even results? Hmmmm....

- try Collatz, see https://news.ycombinator.com/item?id=39733685

- the tests are very cache-friendly; nobody does this. It's true that everybody compares against this unrealistic scenario, however.

- if you've spent a month in twisty little PRNG passages, all alike, you are on the first steps of your journey. Take a towel.

J

yes

See https://www.nextplatform.com/2023/05/01/just-how-big-are-nvi...

They estimated $200k for a single NVIDIA GPU-based CPU complete with RAM and networking. That's where my number came from. (RAM and especially very-high-speed networking is very expensive at these scales.)

I don't for a minute believe Deepseek v3 was built with a $6M rental.

Their paper (arxiv 2412:1947) explains they used 2048 H800s. A computer cluster based on 2048 GPUs would have cost around $400M about two years ago when they built it. (Give or take, feel free to post corrections.)

The point is they got it done cheaper than OpenAI/Google/Meta/... etc.

But not cheaply.

I believe the markets are overreacting. Time to buy (tinfa).

Offtopic:

OpenBSD has an installation ramdisk. Just boot that.

See https://raby.sh/installing-openbsd-on-ovhs-vps-2016-kvm-mach...

I've also seen "dd if=path/to/install/ramdisk /dev/sd0" and reboot; depends on being classic BIOS not uefi. Can't find the link tho.

Risk is about probabilities and hazards.

This article is about absolutes and fear. To conflate the two is an obvious rhetorical trick that amounts to clickbait, approximately.

"It's rare for a reentering object to hit a structure..." which is an example of the probability and the hazard. So the risk by most people's definition is "low".

So what's the problem? "According to the European Space Agency, the annual risk..." is the problem. Misusing (or misunderstanding) terminology is typical. Unfortunately, typical for Ars.

There is a real art to doing "benchmarks", more correctly called "synthetic benchmarks" since they don't reflect actual usage but are intended for comparisons.

I had tried pgvector 0.6.2 on an OCI free node (2cpu 64GB) and noticed a few things:

- pgvector build environment does NOT use -O3

- cosine indexing with/without -03 was 1h:6h elapsed time (10M 128 x fp64 table)

- memory consumption for indexing is huge, I estimated 2x table size

- you can do parts of tables (maintenance_work_mem=) substituting disk io for memory and this only doubles elapsed time

My general comment would be: prospective users need effective guidance (beyond the great advice already on the pgvector website) about memory, cpu, and disk.

I really like the pgvectorscale possibilities for faster lookups; some great ideas there.

And he didn't repeat each test case 5 or 9 times, and take the median (or even an average).

There will be operating system noise that can be in the multi-percent range. This is defined as various OS services that run "in the background" taking up cpu time, emptying cache lines (which may be most important), and flushing a few translate lookaside entries.

Once you recognize the variability from run to run, claiming "1%" becomes less credible. Depending on the noise level, of course.

Linux benchmarks like SPECcpu tend to be run in "single-user mode" meaning almost no background processes are running.

OpenBSD source gets independent code reviews, and they run syzcaller continuously.

https://marc.info/?l=openbsd-tech&w=2&r=1&s=coverity&q=b

https://marc.info/?l=openbsd-tech&m=164303498026116&w=2

There is a recent update to the blis alternative to BLAS that includes a number of RISC-V performance optimizations.

https://github.com/flame/blis/pull/737

There are three more I have to use:

4x4 matrix: you are challenged with letter/number for row/column and must respond with the matrix entry. Not much better than totp; try to find it on your phone.

photo array: given an array of challenge photographs, select the one you know is your secret photo.

not-so-secret Q&A: what is your mother's maiden name? Name of your first car? Your second wife's third brother's cousin's name?

See also The Art of Computer Systems Performance Analysis by Jain.

The statistical parts are very good: self contained and with good explanations. Perhaps a weakness is there isn't much on distributed systems.

He did some Youtube videos as well.

Tubes. And diodes (see the BOM).

Depending on your definition of "current chips".

Clear Linux OS defines its minimum hardware requirements to be second-generation Intel® microarchitecture code name Westmere (released in 2010) or later.

source: https://www.clearlinux.org/clear-linux-documentation/guides/...

> FPGA LUTs are just way too slow

If, and of course that is a big if, you can repackage a (parallelizable) calculation into FPGA look-up tables and implement multiples of this (e.g. 8 to 80 times) then you can think maybe it's quicker than CPU at 3GHz.

However, you have to include DMA of the data to and fro. It's unlikely to be worth the very extensive effort of integrating two wildly different technologies.

On the other hand, it may not be a complicated calculation but FPGA can do much lower latency and smaller variance in latency (hello high-frequency traders). That is a very narrow niche.

A simple board with CPU and FPGA is the Arduino MKR Vidor 4000: ARM Cortex 32-bit CPU and Intel Cyclone 10 FPGA). Hardware cost: $85. Full suite of development software $1000 or more (although lesser tools are available for free.)

True this.

I tried it once a long time ago; it failed to find the sqlite3 command (back when SQLite was part of base). I spent way too much time debugging a sqlite-based script until I noticed /usr/bin/sqlite3 was still on my system.

"sysclean is a perl(1) script designed to help remove obsolete files, users and groups, between OpenBSD upgrades."

Or you could read the release notes.

For OpenBSD, only 512MB is needed even with the kernel relinks. Or so my experience with virtual machines says.

I sometimes run two VMs at 512MB each on my 4GB Windows 10 laptop. And I can use Windows apps too at the same time. (VMware workstation.)

If you want to shrink the kernel and the relink memory footprint, @unangst has an unofficial recipe.

He lost me at "ssh root@machine".

Just no.

The assumption appears to be "one" Mars habitat, with a lot of engineered systems to support human (and other) life.

Three would be better, and each should be capable of supporting the population of one of the others (that is, meaningfully under-utilized.)

When, not if, a biosphere breaks down the inhabitants will have a safe refuge.

Meanwhile the under-utilized biosphere can hoard, ummm, accumulate, spare food and water for use in lesser emergencies.