IBM's Eight-Core, 4-GHz Power7 Chip

pacopico writes "The first details on IBM's upcoming Power7 chip have emerged. The Register is reporting that IBM will ship an eight-core chip running at 4.0 GHz. The chip will support four threads per core and fit into some huge systems. For example, University of Illinois is going to house a 300,000-core machine that can hit 10 petaflops. It'll have 620 TB of memory and support 5 PB/s of memory bandwidth. Optical interconnects anyone?"

Comments

Great

[afidel]

So you can get 16 cores in a low end box but it still won't have enough I/O slots so you will have to buy a shelf at $obscene_amount, seriously why does IBM put such few I/O slots in the lower end P series boxes?

4 Threads per core?

[jdb2]

It should be noted that previous POWER architectures had 2 threads per core. They also had SMT ( Simultaneous Multi-Threading ) support, which gave them an "effective" 4 threads per core. I wonder. Are the all the threads on the POWER7 "true" threads ( ie. 4 execution units -- 1 per thread ) or is it a 2 thread setup with SMT? On the other hand, if the POWER7 really does have 4 "true" threads, then with SMT you'd get an "effective" *8* threads per core.

jdb2

Re:I have a serious question:

[jcarkeys]

You sir, are correct. Most things aren't set to run in parallel and thus don't get the gains. Gains come from optimized code (obviously), but also doing multiple tasks. Leave Photoshop to render an HDR image and play a game, if you want. Though to be fair, it's not "just 1/4th" performance, the other cores are able to handle some of the other CPU tasks, such as running hardware controllers.

And the reason that it kind've oscillates between cores is because "Set Affinity" tells the process that it's allowed to use that core, not that it has to or even should. If you want something to use both cores, open up two processes, set the first to core 1 and the second to core 2. Most of the time that's unusable like that, but I recently transcoded my entire music library and set one process to do songs from A-M, and the other from N-Z. It really helped

Memory Bandwidth

[Brad1138]

It'll have 620 TB of memory and support 5 PB/s

Is that kind of memory bandwidth possible? You could access the entire 620TB in ~120 milliseconds. I guess nothing is ever to fast, it just seems unrealistically fast.

Re:Memory Bandwidth

[777v777]

It would be incredibly unlikely that each core could directly access the full 620TB. The current largest machines on the Top500 list are all distributed memory machines(clusters). However, the trends in modern interconnect networks are to increase the capabilities for doing stuff like remote direct memory access (RDMA). In such a scheme, the remote memory is not addressable(with load/store instructions), but stuff can be transferred between memories of different nodes by the network hardware. The codes commonly run on the top500 machines are likely written in MPI or MPI/OpenMP. This means they don't need to directly access remote memories.

Re:I have a serious question:

[rbanffy]

"Aren't a lot of games and apps single-threaded?"

And that's one more thing we can thank Microsoft for.

Hadn't DOS and the PC-clones crippled with mono-processor/mono-threading DOS/Windows stack become the dominant architecture for most of the 90s, we would have rock-solid, secure, multi-processor, 64-bit RISC boxes running some flavor of Unix on our desktops by now.

Thanks Bill.

Re:I have a serious question:

[Fweeky]

The benefit? Unless your app uses more than around 3GB of RAM, basically zero

Plenty of things quite enjoy being able to perform operations in 64bits at a time, actually. Especially when it comes to media, crypto, compression, and indeed games; on top of having 2-3x the usable number of general purpose registers, which certainly isn't something to sneer at given how awful x86 has traditionally been in this area. Plenty of things you're likely to actually care about the performance of are likely to get a nice boost.

64-bits as a waste of address space, UNLESS you're accessing large amounts of memory (>3GB per program!)

Well, you generally only get 3GB when you've performed tricks to ask the OS to allow that; e.g. /3GB boot flag, fiddling with MAXDSIZ, or recompiling with a different user/kernel space split.

On top of that, it's not all about RAM, it's about address space; if you've only got 32 bits to play with, you need to be very careful about allocating it, since any wastage can lead to exhausting your virtual address space before your physical space; like with filesystems, fragmentation becomes more of a concern the closer you get to your maximum capacity.

Large virtual spaces are also useful when it comes to doing things like mmapping large files; for instance, a database might like to mmap data files to avoid unnecessary copying you get with read()/write(), but mmapping a 1GB file means you need 1GB of address space, even if you don't touch any of it. When it's common to access disk using memory addresses, 3GB starts looking small very fast.

You also very quickly eat into it using modern graphics cards; 512MB is common, having two isn't that uncommon, and things are moving towards 1GB; bang goes your 3GB, all that frame buffer needs addressing too, on top of the kernel's other needs.

Really, 32bit needs to die screaming, sooner rather than later.