Alexander Yee

We already have 128-bit processors, of sorts. They are called "vector units". ;)

128-bit integers could be useful for bignums. You can do bignum addition on existing SIMD units but you'd have to use tricks to carry the carry between elements and to the next vector — and that makes the resulting code slower than using GPRs.[1]
But I think this would still fit better in vector units than making the integer registers larger: The hw trend (ARM SVE, RISC-V V) is to make vector-width implementation-defined, starting at 128 bits in the low-end.

128-bit floating point is apparently a thing in scientific computing (but I've not seen it myself).

128-bit "pointers" exist in CHERI [2], where they are tagged capabilities that also store the bounds and access rights (rwx) for accessing memory through the pointer.
Addresses are still 64-bit though. GPRs are still 64-bit. The caps are stored in a new register file.

If you want to scale up address spaces, I think the biggest issue is not the number of bits but rather how to coordinate the address space to avoid collisions. One approach would be to re-introduce segmentation (pointer ⇒ segment ID and offset within segment), but unlike earlier system make each segment have its own local namespace of segment IDs it knows and translate between those when transferring pointers between segments.
This idea is used by e.g. the research OS "Twizzer" [3], which was made for a large address space using NVRAM as RAM.
I think this "pointer swizzling"…

Here's my quick take.

A top of the line Zen core is a powerful CPU with wide SIMD (AVX-512 is 16 lanes of 32 bit quantities), significant superscalar parallelism (capable of issuing approximately 4 SIMD operations per clock), and a high clock rate (over 5GHz). There isn't a lot of confusion about what constitutes a "core," though multithreading can inflate the "thread" count. See [1] for a detailed analysis of the Zen 5 line.

A single Granite Ridge core has peak 32 bit multiply-add performance of about 730 GFLOPS.

Nvidia, by contrast, uses the marketing term "core" to refer to a single SIMD lane. Their GPUs are organized as 32 SIMD lanes grouped into each "warp," and 4 warps grouped into a Streaming Multiprocessor (SM). CPU and GPU architectures can't be directly compared, but just going by peak floating point performance, the most comparable granularity to a CPU core is the SM. A warp is in some ways more powerful than a CPU core (generally wider SIMD, larger register file, more local SRAM, better latency hiding) but in other ways less (much less superscalar parallelism, lower clock, around 2.5GHz). A 4090 has 128 SMs, which is a lot and goes a long way to explaining why a GPU has so much throughput. A 1080, by contrast, has 20 SMs - still a goodly number but not mind-meltingly bigger than a high end CPU. See the Nvidia Ada whitepaper [2] for an extremely detailed breakdown of 4090 specs (among other things).

A single Nvidia 4090 "core" has peak 32 bit multiply-add…

Expanding on 3: I think it ends up at O(n^2 * log n) transistors, O(log n) critical path (not sure on routing or what fan-out issues might there be).

Basically: determine end of instruction at each byte (trivial but expensive). Determine end of two instructions at each byte via end2[i]=end[end[i]]. Then end4[i]=end2[end2[i]], etc, log times.

That's essentially log(n) shuffles. With 32-byte/cycle decode that's roughy five 'vpermb ymm's, which is rather expensive (though various forms of shortcuts should exist - for the larger layers direct chasing is probably feasible, and for the smaller ones some special-casing of single-byte instructions could work).

And, actually, given the mention of O(log n)-transistor shuffles at http://www.numberworld.org/blogs/2024_8_7_zen5_avx512_teardown/, it might even just be O(n * log^2(n)) transistors.

Importantly, x86 itself plays no part in the non-trivial part. It applies equqlly to the RISC-V compressed extension, just with a smaller constant.

Intel's argument is exactly that you cannot recognize whether a CPU is not degraded at all or it is partially degraded.

Anecdata point: my 13900K system is a couple of years old, with a December 2022 in-service date, and has been rock solid in everyday use. Until I ran the http://www.numberworld.org/y-cruncher/ benchmark, which reported errors after about an hour.

So for users of the affected CPUs, it may be smart to repeat that experiment before assuming they have "one of the good ones." At this point I'm left wondering how long it will be before faults appear during normal workloads.

The CPUs that have not been overclocked are unlikely to have been degraded.

That is absolutely not the case. My system is running bog-standard BIOS settings from an OEM known to be conservative in that regard (Puget Systems). Among the many reports of problems, there have been quite a few from cloud providers, who don't overclock their systems as a rule.

It should be noted that y-cruncher, that closed-source program, is responsible for every pi computation record since 2010 (back then the record was 2.7T digits). Traditionally these records were held by supercomputers, but it seems that pi computation is no longer a good way to benchmark or stress-test them [1], leaving only interested individuals in the scene.

If pi computation were useful by its own, or there were a lot of people working towards records, we can expect multiple competitive pi computation programs where some of them are hopefully F/OSS. (The algorithm itself is not exactly secret anyway and big ideas are already in public, what makes y-cruncher special is its meticulous optimization.) But I don't see anything like that. There seem no actual demands for pi computation software, not just F/OSS.

[1] http://numberworld.org/y-cruncher/faq.html#why_desktops

I agree. I work in a similar field, and the value of AVX512 is clearly there - it just hasn't been worth implementing for the tiny percentage of market penetration. This is directly due to the market segmentation strategy Intel applied. AMD has raised the ante for AVX512 with two excellent implementations in a row, and for the first time ever I'm definitely considering building AVX512 targets.

Just as a small example from current code, the much more powerful AVX512 byte-granular two register source shuffles (vpermt2b) are very tempting for hashing/lookup table code, turning a current perf bottleneck into something that doesn't even show up in the profiler. And according to (http://www.numberworld.org/blogs/2024_8_7_zen5_avx512_teardown/) Zen5 has not one but _TWO_ of them, at a throughput quadrupling Intel's best effort..