One of my engineering highlights was Russ reviewing a few of my contributions to Golang (to the core http library). He's a super cool and nice guy. I don't really write that much Go anymore, but it was a fun & cute language when it first came out.
I once wrote him an email asking what font was used in the plan9 papers. He replied. It's Lucida Sans Unicode. He even provided a url to paper published by the maker of the font.
Zmij and xjb are in a league of their own. Broadly speaking, dtoa first has to find the shortest decimal representation of the floating-point input, and then format that decimal representation into a string. Zmij and xjb pull far ahead of the others mostly by speeding up the second part of that process.
uscale is quite good without the stringification, as are many other algorithms. I would say uscale's main strength isn't its speed, but rather its simplicity and, more importantly, the fact that it does both formatting and parsing using a single ~11 KiB table, which no other state-of-the-art algorithm offers (although yy comes close).
The core of newer methods like yy, xjb and zmij is remarkably simple: https://vitaut.net/posts/2026/yy-dtoa/. Shortest uscale is basically Schubfach or, rather, it's variant called Teju Jagua and has 2-3 wide multiplications compared to 1 for newer methods.
The complexity is optional and comes from squeezing the last few nanoseconds =).
Right, that's basically what I was trying to say (in so many words). I learned a lot from your dtoa blog posts and Zmij's implementation. Thank you!
> has 2-3 wide multiplications compared to 1 for newer methods.
As written, the `shortFloat()` function always calls `uscale()` two times, followed by an optional third call. Each `uscale()` does two wide multiplications (one full 64x64->128 and one 64x64->hi64, in case we want to make that distinction), so that works out to either 4 or 6 wide multiplications in total. I think `shortFloat()` could be rewritten to always do exactly 2 wide multiplications (both 64x64->128) at the cost of some more ALU operations. However, I don't see how that could be further reduced to only one wide multiplication.
EDIT: Going back to look at Zmij's to_decimal, I just realized that it also doesn't do just one wide multiplication in the sense I originally meant, so what you're saying is likely correct in the first place. I overzealously used a different definition of "wide multiplication", which I probably should've realized, given the fact that my numbers are exactly double yours, but alas. My apologies.
FYI you linked to a really old version of the GCC documentation. Google apparently loves those old docs, so they often show up near the top of search results despite being ancient. For posterity, here's the latest version: https://gcc.gnu.org/onlinedocs/gcc-16.1.0/gcc/Vector-Extensi....
Zig vectors do not necessarily force data into SIMD registers; a scalar implementation would work equally well. This is not just a theoretical argument, because Zig code that uses `@Vector` also has to compile for architectures that do not have SIMD instructions.
That being said, the parent commenter is actually referring to other recent proposals as opposed to existing `@Vector` functionality:
It's not designed for IoT devices per se, the naming is just terrible. A comparison to OpenWrt is not warranted here, although to reiterate, the naming is terrible.
In a way, it is for "IoT" devices...but enterprisey things. Where I work we have it on a few devices that I guess you could call an "IoT" device. Unattended driver kiosks for truck scales, manufacturing equipment that requires windows, industrial control panels, etc.
That's what it is for. A lot of this stuff uses really old software, some of which the vendor doesn't even exist anymore, and it only runs on Windows so these control panels and devices need windows (unless you manage to get some of it working on wine but that's usually not viable in these cases).
So yeah, it's supposed to be a full desktop, because these devices often require it to some extent, albeit a little slimmed down and LTS.
I think HN would be surprised to learn just how many devices run windows out there in the world outside of silicon valley. Windows is everywhere you'd hope never to see it running at.
well, i am not surprised that anything with a GUI would run some form of windows, even ATMs. i would not have categorized them as IoT devices though, but fair point.
https://research.swtch.com/fp
https://github.com/golang/go/blob/go1.27.0/src/internal/strc...