I've used https://instaguide.io/info.html?type=c5a.24xlarge#tab=lstopo
to browse the info. It is getting a bit old though.
That is nice. But no detail after gen 5, so mostly historical interest.
Readit NewsMany clouds don’t guarantee that small instances won’t span NUMA nodes.
Here on HN I saw a comment by someone running VM scale sets with hundreds or even thousands of nodes and their trick was to overprovision and then delete the instances that span NUMA nodes.
You’re right, it’s not guaranteed.
Also the hypervisor might lie to you - claiming a single NUMA node but actually crossing two on the VM host.
This is one of those way down the road optimizations for folks in fairly rare scale situations in fairly rare tight loops.
Most of us are in the realm of the lowest hanging fruit being database queries that could be 100x faster and functions being called a million times a day that only need to be called twice.
Whilst you’re right in broad strokes, I would observe that “the garbage-collector” is one of those tight loops.
Single-threaded JavaScript is perhaps one of the best defences against NUMA, but anyone running a process on multiple cores and multiple gigabytes should at least know about the problem.
Very detailed and accurate description. The author clearly knows way more than I do, but I would venture a few notes:
1. In the cloud, it can be difficult to know the NUMA characteristics of your VMs. AWS, Google, etc., do not publish it. I found the ‘lscpu’ command helpful.
2. Tools like https://github.com/SoilRos/cpu-latency plot the core-to-core latency on a 2d grid. There are many example visualisations on that page; maybe you can find the chip you are using.
3. If you get to pick VM sizes, pick ones the same size as a NUMA node on the underlying hardware. Eg prefer 64-core m8g.16xlarge over 96-core m8g.24xlarge which will span two nodes.
> It feels like the industry quickly moved beyond the reach of the "hobbyist". There were no more "clever tricks" to be employed
It happened in a matter of a few years. The Apple II was built as a machine capable of running Breakout in software. Woz picked the 6502 (originally for the Apple One) because he could afford it.
It wasn't that long after that Commodore released the C64. They chose the 6502 because they'd bought the 6502 fab to protect their calculator business (and then they used it to assemble custom video and audio chips). From there, we were off to the races with respect to larger and larger engineering requirements.
Oddly, I wrote a bit about it a few days ago (in the context of John Gruber's recent discussion on the Apple and Commodore microcomputers): https://mschaef.com/c64
The Commodore machine contemporaneous with the Apple II was the PET.
Apple I - July 1976
Commodore PET - January 1977
Apple II - June 1977
C64 - January 1982
All four used the 6502.
> mix randomisation into hash tables.
I believe you don't understand.
In go, they literally randomly permute the iteration order of the map each time you iterate over it.
e.g
for x in map {
}
for x in map {
// different order
}
var randomUser User
for userId, user in usersMap {
randomUser = user
break
}
Do note your last example makes a biased, or poorly random, selection.
bboreham commented on What would a Kubernetes 2.0 look like matduggan.com/what-would-... · Posted by u/Bogdanp
YAML is a JSON superset. Of course anything that supports YAML supports JSON.
But it’s also true on the output side. Kubectl doesn’t output yaml unless you ask it to. The APIs only support json and protobuf, not yaml.
bboreham commented on The radix 2^51 trick (2017) chosenplaintext.ca/articl... · Posted by u/blobcode
bboreham commented on The radix 2^51 trick (2017) chosenplaintext.ca/articl... · Posted by u/blobcode
> Aside: Why 13 bits instead of 12? For our purposes, we’re going to ignore the carries in the most significant limb, allowing numbers to wrap when they overflow past 2256 - 1 (just like how unsigned addition works in C with normal size integer types). As a result, we can assign 52 bits to the most significant limb and ignore the fact that it will run out of room for carries before the other limbs do.
Why not give the top limb 64 bits and the other four limbs 48 bits each, then? You can accumulate more additions before normalization, you can take advantage of word alignment during splitting and normalization if your instruction set has anything useful there, and your overflow properties are identical, no?
Then you would need 6 words to hold a 256-bit value instead of 5 in the OP, and consequently more instructions to add them.
Span = an event (which is bascially just a log with an associated trace), and some data fields. Trace = a log for a request with a unique Id.
A useful thing about opentelemetry is that there's auto-instrumentation so you can get this all out-of-the-box for most JVM apps. Of course you could probably log your queries instead, so it's not necessarily a game-changer but a nice-to-have.
Also the standardization is nice.