How many in-order cores could one fit on a die? [LWN.net]

How many in-order cores could one fit on a die?

Posted Aug 11, 2023 9:58 UTC (Fri) by paulj (subscriber, #341)
In reply to: How many in-order cores could one fit on a die? by malmedal
Parent article: Another round of speculative-execution vulnerabilities

I'm not sure Niagara failed. It did surprisingly well for Sun. For the stuff it was good at, it was very very good at.

Larrabee failed, but... Intel tried to make that into a GPU competitor. And the amount of RAM was limited.

to post comments

How many in-order cores could one fit on a die?

Posted Aug 11, 2023 17:06 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

I was on a receiving end of trying to make Niagara work (the second one, with multiple FPUs). In Java, which is supposed to be its natural habitat.

It never worked well, garbage collection was slow because even the "parallel" GC in Sun JVM was not quite parallel and the sequential parts were causing huge delays because the single-threaded execution was super-slow.

Later, we tried to use Tilera CPUs (massively parallel CPUs with 32 cores) for networking software, and it ALSO failed miserably. Turns out that occasional serialized code just overwhelms everything. I still have a MikroTik Tilera-based router from that experiment, I'm using it for my home network.

How many in-order cores could one fit on a die?

Posted Aug 11, 2023 19:55 UTC (Fri) by malmedal (subscriber, #56172) [Link]

I also tried Java to try to make use of the Niagara, a major pain point was a number of non thread-safe routines in the standard library.

Especially annoying since I was not making these calls directly, they were from third-party libraries so it was practically impossible to figure out what could be safely run in parallel.

How many in-order cores could one fit on a die?

Posted Aug 14, 2023 8:48 UTC (Mon) by paulj (subscriber, #341) [Link] (2 responses)

I'm not sure Java was its natural habitat either, given the GC issues. It was designed for fairly parallel (multi-thread/process) C/C++ server software - web, SQL, etc.

Tilera, worked on software on that too. The people who architected that software had actually done a pretty good job of making sure the packet processing "hot" paths could all run independently, and each thread (1:1 to CPU core) had its own copy of the data required to process packets. Other, non-forwarding-path "offline" code would then in the background take the per-CPU packet data, process it, figure out what needed to be updated, and update each per-CPU hot-path/packer-processing data state accordingly. That worked very well.

The issue the shop I worked at had with Tilera was that it was unreliable. The hardware had weird lock up bugs. I figured out ways to increase the MTBF of these hard lock ups, by taking more care in programming the broadcom Phys attached to the chip (I think they were on ASIC, and part of the Tilera design - can't quite remember). But... MAU programming via I2C controllers shouldn't really be causing catastrophic lockups of the whole chip. We still had hard lock ups though - never fully figured them all out or work-arounds.

It seemed a 'fragile' and sensitive chip.

How many in-order cores could one fit on a die?

Posted Aug 14, 2023 9:20 UTC (Mon) by paulj (subscriber, #341) [Link]

Uhm, MII MDIO rather, not MAU, I guess.

How many in-order cores could one fit on a die?

Posted Aug 14, 2023 15:38 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> The issue the shop I worked at had with Tilera was that it was unreliable. The hardware had weird lock up bugs.

We found some strange lockups in glibc, something to do with pthreads and signals. We "solved" it by porting musl libc, at that time it was easier to do than figuring out how to build and debug glibc.

But yeah, lockups also happened.

How many in-order cores could one fit on a die?

Posted Aug 17, 2023 11:00 UTC (Thu) by davidgerard (guest, #100304) [Link]

Was also there, did that - went from a Niagara beast machine to Ubuntu VMs. Our actual reason was to get away from Oracle as absolutely fast as possible - but it turned out bogomips were what our apps actually wanted, and 300MHz vs 3GHz did in fact make our apps many times faster.