The new RTL-based adapter is physically smaller, runs way cooler, but only gets ~6 Gbps from my Mac to my Linux box, with a lot of jitter (iperf3).

The AQC adapter is all metal, gets uncomfortably hot, and sustains 9.3 Gbps, no problem. It's about the same size as the middle adapter in the photo.

The USB-4 AQC adapters are only ~$13 more, and yet are significantly faster with lower jitter. I'm staying with those.

Hope that helps someone!

This concerns unsigned division by a 32 bit constant divisor. Compilers routinely optimize this to a high-multiply by a "magic number" but this number may be up to 33 bits (worst-case, divisor dependent, 7 is a problem child). So you may need a 32x33-bit high multiply.

What compilers do today is some bit tricks to perform a 32x33 bit high multiply through a 32x32 multiply and then handling the last bit specially, through additions and bitshifts. That's the "GM Method" in the paper; the juice to be squeezed out is the extra stuff to handle the 33rd bit.

What the paper observes is that 32x33 high multiply can be performed via a 64x64 high multiply and then the extra stuff goes away. Well yes, of course.

But amazingly in ALL of these worst case situations you can compute a different magic number, and perform a (saturating) increment of the dividend at runtime, and ONLY need a 32 bit high multiply.

That is, these are the two algorithms for unsigned division by constants where the magic number overflows:

- This paper: Promote to twice the bit width, followed by high multiply (32x64 => 64) and then bitshift

- SOTA: Saturating increment of the dividend, then high multiply (32x32 => 32) and then bitshift

Probably the paper's approach is a little better on wide multipliers, but they missed this well-known technique published 15 years ago (and before that, I merely rediscovered it):

https://ridiculousfish.com/blog/posts/labor-of-division-epis...

The answer is that Solod breaks with Go semantics here: it just makes defer block-scoped (and unavailable in for/if blocks, which I don't quite get).

https://github.com/solod-dev/solod/blob/main/doc/spec.md#def...

Join us in pioneering the next generation of nuclear reactors! You'll leverage your software skills alongside nuclear engineers to model, simulate, design, and deploy advanced fission power technology. You will work at the forefront of the nuclear industry, developing novel techniques to reach new levels of safety, efficiency, and resiliency. Come be a part of powering the future with advanced fission power plants to provide clean, reliable, affordable energy.

We are hiring for:

- Software Engineer: https://job-boards.greenhouse.io/oklo/jobs/4018702004

- Senior Software Engineer: https://job-boards.greenhouse.io/oklo/jobs/5739483004

- Software Engineer (Infrastructure): https://job-boards.greenhouse.io/oklo/jobs/5784826004

- Software Quality Assurance Lead: https://job-boards.greenhouse.io/oklo/jobs/5480416004

See more opportunities here: https://job-boards.greenhouse.io/oklo

Please mention Hacker News in your cover letter!

Swift routinely optimizes out reference count traffic.

Pardon?

1. How do we prevent loading a bogus lower through misaligned store or load?

Answer: Misaligned pointer load/stores are trapped; this is simply not allowed.

2. How are pointer stores through a pointer implemented (e.g. `*(char **)p = s`) - does the runtime have to check if *p is "flight" or "heap" to know where to store the lower?

Answer: no. Flight (i.e. local) pointers whose address is taken are not literally implemented as two adjacent words; rather the call frame is allocated with the same object layout as a heap object. The flight pointer is its "intval" and its paired "lower" is at the same offset in the "aux" allocation (presumably also allocated as part of the frame?).

3. How are use-after-return errors prevented? Say I store a local pointer in a global variable and then return. Later, I call a new function which overwrites the original frame - can't I get a bogus `lower` this way?

Answer: no. Call frames are allocated by the GC, not the usual C stack. The global reference will keep the call frame alive.

That leads to the following program, which definitely should not work, and yet does. ~Amazing~ Unbelievable:

    #include 
    
    char *bottles[100];
    
    __attribute__((noinline))
    void beer(int count) {
        char buf[64];
        sprintf(buf, "%d bottles of beer on the wall", count);
        bottles[count] = buf;
    }
    
    int main(void) {
        for (int i=0; i < 100; i++) beer(i);
        for (int i=99; i >= 0; i--) puts(bottles[i]);
    }

https://www.chargerlab.com/complete-pd-3-2-spr-avs-specifica...

The implication is that the next biggest float is (almost) always what you get when you reinterpret its bits as an integer, and add one. For example, start with the zero float: all bits zero. Add one using integer arithmetic. In int-speak it's just one; in float-speak it's a tiny-mantissa denormal. But that's the next float; and `nextafter` is implemented using integer arithmetic.

Learning that floats are ordered according to integer comparisons makes it feel way more natural. But of course there's the usual asterisks: this fails with NaNs, infinities, and negative zero. We get a few nice things, but only a few.

Dyn-safety is another but I had encountered that previously in Swift.

Join us in pioneering the next generation of nuclear reactors! You'll leverage your software skills alongside nuclear engineers to model, simulate, design, and deploy advanced fission power technology. You will work at the forefront of the nuclear industry, developing novel techniques to reach new levels of safety, efficiency, and resiliency. Come be a part of powering the future with advanced fission power plants to provide clean, reliable, affordable energy.

We are hiring for:

- Software Engineer: https://job-boards.greenhouse.io/oklo/jobs/4018702004

- Software Quality Assurance Engineer: https://job-boards.greenhouse.io/oklo/jobs/5480416004

See more opportunities here: https://job-boards.greenhouse.io/oklo

Please mention Hacker News in your cover letter!