yvdriess

Very badly, this is the polar opposite design of a GPU.

It does share the latency-hiding-by-parallelism design, but GPUs do that scheduling on a pretty coarse granularity (viz. warp). The barrel processors on this thing round-robin through each instruction.

GPUs are designed for dense compute: lots of predictable data accesses and control flow, high arithmetic intensity FLOPS.

In contrast, this is designed for lots of data-dependent unpredictable accesses at the 4-8B granularity with little to no FLOPS.

Their multithreaded cores are similar design, yes. It does not do XMT's in-hardware full/empty bit memory access system though.

DRAM is the new I/O. So yes, this is designed to handle 97% of the threads doing constant bad-locality DRAM accesses.

> What are the kinds of challenges to write things efficiently?

The challenge is mostly that you have to create enough fine-grained parallelism and that per thread performance is relatively low. Amdahl's law is in full effect here, a sequential part is going to bite you hard. That's why each die on this chip has two sequential-performance cores.

The graph problems this processor is designed to handle have plenty of parallelism and most of the time those threads will be waiting for (uncached) 8B DRAM accesses.

> From skimming Wikipedia, it looks like a big challenge is cache pollution

This processor has tiny caches and the programmer decides which accesses are cached. In practice, you cache the thread's stack and do all the large graph accesses un-cached, letting the barrel processor hide the latency. There are very fast scratchpads on this thing for when you do need to exploit locality.

There's two single threaded cores, but the four multithreaded cores are indeed Tera-style barrel processors. The Tera paper is even cited directly in the PIUMA white paper: https://arxiv.org/abs/2010.06277

edit: s/eight/four

Their inefficiency at large-scale graph problems is the entire reason DARPA wrote out the program that funded this chip.

Graph workloads and other types of sparse compute. https://www.darpa.mil/program/hierarchical-identify-verify-e...

Not on-chip no, it's still DDR5 DIMMs. What is cool about is that it is using custom DIMMs and memory controllers to do 8B-granularity accesses. Plus, each core has its own MC, as you can see on the die shot. If each MC manages 4GB of DRAM, that would explain the 32GB per chip.

I would not disregard that direction. Architectures that do well on pointer chasing have been attempted in the past (e.g. Cray XMT) and are cropping up in prototypes (PIUMA https://arxiv.org/abs/2010.06277) and startups. The caveat is that latency is hidden with massive amounts of parallelism.

edit: To be clear, I agree with the sentiment that the paper abstract machine models are inadequate in most practical cases. There are workloads where you're dealing with asymptotically large datasets, such as genome assembly and analysis. Even there, the RAM model is abstracting away the bottlenecks of modern computer systems.

And so closing the great circle of UI framework technologies.

GraphBLAS completely revolves around this duality. Sparse linear algebra is really powerful. https://graphblas.org/

That even horizon can be a useful feature, e.g. opaque objects (although technically you do not need void* for that).

Not an Apple innovation.

Intel already launched a processor with 16GB on-package MCDRAM in 2016 (Knight's Landing Xeon Phi). You can even buy an Intel Xeon with 64GB HBM2 today. Nvidia likewise has been packaging HBM with their server GPUs.

Embedded DRAM (eDRAM) been used for long time in the mobile and console space. e.g. IBM's POWER7 (e.g. Nintendo Gamecube) and Intel Haswell products. However, using a logic process node to make DRAM cells is wasteful. Packaging technologies have advanced sufficiently that you now regularly see regular DRAM dies (LPDDR, HBM) being put on-package.

But all of that is packaging and manufacturing technologies. We're still taking to DRAM over a memory bus like we're still living in the '80s. The true innovation I'm looking out for is for a company to stick its neck out and use a different communication standard to talk with the DRAM modules. Something like the CLX.mem standard, which is used in the server space to talk to memory expansion modules.

Correction: the lesson is that you cannot exploit the available ILP by static (compile-time) analysis. There is definitely enough ILP to exploit if you do the analysis at execution time, which is what any modern CPU does with register renaming, reorder buffers, dependency tracking etc.

That's also essentially what the PS3 was. Plenty of developers ended up ignoring the SPUs and treating the Cell as a regular off-the-shelf POWER processor.

To be fair, most of that research happens pre-competitively (cfr imec roadmap). That includes working with tool makers to work out the kinks. Of course there is a big hurdle from there to an actual product-scale deployment.

Do I understand you right that

  for (int i=0; i<4; i++) 
    buf[i] = ((char*)&my_float)[i];

is not undefined behavior? But that

  for (int i=0; i<4; i++)
    buf[i] = ((char*)(int32_t*)&my_float)[i];

is undefined?

AFAIK the underlying mechanism and undefined behaviour is the same.

Indeed. New versions never break the old. Every new feature has to account for interactions with the rest of the language.

Herb Sutter's https://github.com/hsutter/cppfront could be a good strategy to clean it up.

Yes, being able to fwrite() dump floats to binaries is invaluable when working with large datasets. It's common to see binary 'cache' file being created for ASCII inputs (e.g. CSV) when there is any chance of it being fed repeatedly.

That is not a problem, it simply converts the float value to uint32. What the post mentions is `uint32_t my_int = (uint32_t)&my_float;`

That's why it's an Enterprise programming language.

I also immediately noticed it was an old post, because the new standard version have all but eliminated the frustrating complexities of the language. :D

Speculation, but could it be because of a ring topology?

There are other costs than silicon real estate. Those modes and microcode need to be validated, tested and add bloat to the boot software stack.

Interesting to point out that Euroclear and Euronext are based in Belgium.

Yes, it has that one killer feature the other FSs so not have.

Depends on the game and platform. RTS games tend to still have peer to peer netcode. Deterministic simulation is still a thing.

Here is an interesting GDC talk on building a fixed precision engine core to ensure determinism: https://youtu.be/wwLW6CjswxM

When I renovated my house (temperate EU climate), this was actually mandatory: active ventilation and breathing vapor shield in front of the insulation layer.

Indeed, older houses rely on "gravity ventilation", as my architect described it: high-temp heating is used to move stale air around by induction, plenty of nooks and crannies together with the density gradient would suck in fresh air.

When you renovate partially, adding insulation layers and plugging holes, you need to open up the windows for about 5-10 minutes once or twice a day. Paradoxically, the heat loss is mitigated because the fresh air is typically drier, which heats up easier.

It might be a lack of a system or willingness to stick with it until it gets good.

The manager championing it moves, Business shows a low TAM, there is a bad quarter and the CEO needs to appease investors, etc.