Hacker News Reader

Comment by fizixer | Hacker News Reader

My motto in this regard is 'simplify the hardware as much as possible and do your partitioning and structures and abstractions in the software'.

So single address space or no? I ask 'which way gives the smaller chip footprint'?

I think we spend (waste?) too much time trying to do things in hardware when we could offer an extremely simple core to the s/w layer. That makes h/w designer's job easy and leaves a ton of footprint where you can put more cores.

Make the core RRISC (reduced-reduced-instruction-set-computer) and offer it in 64-core or 256-core versions and let the programmers have fun with it.

Looking at the brainiac-vs-speed-demon debate (from this [1]), I'm squarely in the speed-demon camp.

[1] http://www.lighterra.com/papers/modernmicroprocessors/

View on HN

The Cell processor was an example of that. One MIPS CPU surrounded by 7 (8 on a good chip) simpler processors, with DMA between all units but not shared memory. But the Cell only had 256 KB (not MB) of RAM local to each support processor. That just wasn't enough.

A Cell with a few megabytes of RAM in each support processor might be useful for bulk packet processing. IBM built some blade servers like that. They were powerful, but too weird to sell in volume, and were discontinued in early 2012.

That's the problem with exotic architectures. It's quite possible to build very high performance special purpose systems, but if the volume isn't there, they can't compete with commodity hardware. Google, Facebook, or Amazon, who consume enough hardware to justify going custom, might do things in this direction.

256-core units are already available: http://www.mellanox.com/page/products_dyn?product_family=241 . They're kinda hard to use, and most programmers would much rather have a single fast processor than a zillon cores.

It depends what you mean by hard to use. If it's an obsure architecture for which assembler, compiler, linker, the whole toolchain is not easily available, then the difficulty has nothing to do with the high core count.

Also I'm not sure why a simpler core (note: simple architecture not slower core) would be so slow that it would be unusable. I mean such cores are called "speed demon" for a reason I assume.

I personally would love to see 256-core 64-bit ARM-compatible becoming mainstream (by compatible I mean take the ARM instruction set and reduce it in half or a quarter).

The Tilera architecture required assembler for effective usage due to its idiosyncracies.

The main problem is access to DRAM is a terrible bottleneck, and adding cores makes this worse if they all need to access it. You can fill a die with ALUs but unless you can keep them fed this doesn't help you at all. That's why Tilera focused on the network stream use case; there's enough storage on-die for a few frames per core, and the data to operate on can "flow" through the system from one 10G Ethernet MAC to another.

Many thanks for the link. It is an amazing read, should be an HN topic on its own

Reply on news.ycombinator.com