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?"
Comment removed based on user account deletion
In other news, temperatures on the University of Illinois campus have mysteriously risen ten degrees. Scientists are still examining possible causes..
"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."
I came.
The applications that are going to be run on this type of machine are designed to be run on this kind of machine.
If your process looks like this:
int main()
{
while (something)
{
doSometing();
}
}
It will hit 100% on one core and that's it. Its not multithreaded - one CPU will churn on it forever and the others will sit around waiting for a task from the OS. 2 course, 200,000 cores the results will be the same. These machines are made for tasks that are broken up into lots of smaller jobs and processed individually. Its not magic - more cores won't get a single threaded process done faster.
Seriously.
Yeah, right, it has optical connections. they will have to be disabled to play videos, otherwise you might copy them!
What are we going to do tonight Brain?
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?
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
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
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
The funny thing is that it teeter-totters back and forth from one core to the other. I wish I knew what made it do that.
The OS runs the process a few milliseconds at a time, then kicks the process of the cpu for another process to run (if there is one, including OS tasks such as I/O routines). When the OS starts up the process again for a few more milliseconds, it may start it up on a different core. That is why both cores will show 50% average utilization.
Now if you set CPU affinity for that process to be on one core, then it will max that core out at 100% and the other core will be idle. This may result in better performance, because you get better cache utilization if the process stays on the same core.
On a related topic, this can also be the case if the app is multithreaded -- sometimes it is more efficient to run multiple threads on the same CPU instead of across CPUs, if each thread is accessing the same region of memory. Otherwise, if the threads are on different CPUs or cores, then the threads are constantly invalidating the cache on the other core, causing more (expensive) reads/writes to main memory.
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.
If you could reason with religious people, there would be no religious people
No, each core is running at 4Ghz. That does not total up to 16 Ghz processing power though, because only multithreaded programs can take advantage of more than one core at once, and they still have to wait if they're sharing data.
Aren't a lot of games and apps single-threaded? Hmmm. I figured that dual/quad-core wasn't all it's cracked up to be. So, essentially, if I have a single-threaded app on a quad core, it'll perform at 1/4th the potential speed.
Yes, although, most high end games and game engines actually are multi-threaded. Few are designed to take advantage of more than 2 cores though, and none that I know of will use 8 or 300,000...
So, essentially, if I have a single-threaded app on a quad core, it'll perform at 1/4th the potential speed.
Not necessarily. If you have 3 women can you make a baby in 3 months instead of 9? Given that it still takes 9 months and 2 of the women are idle, would you say that these women are performing at 1/3rd the potential speed? Same sort of logic applies here. If the task is inherently sequential, having more cores (or ladies) won't make it any faster.
Somethings -are- highly parellizable, like ray-tracing or cutting down all the trees in a forest.. and other things are partly parallelizable... like changing tires (a pit crew can change 4 tires at once... but adding more staff to allow you to change 5 tires at once doesn't make your team any faster...)
That doesn't leave me with a warm and fuzzy feeling inside.
Yes, in general computing applications, an 8GHz CPU would be faster than a quad core 2GHz. (And even under optimal parallilizable situations the 2ghz quadcore would just barely surpass the 8ghz cpu due to lower task switching overhead.) So the faster single cpu is almost always better. The reason we have quad core 2Ghz cpus is that they are much much more practical to actually make, and a lot of the stuff that takes a long time (rendering 3d, encoding movies, etc is actually highly parellizable so we do see a benefit. And much of the single threaded sequential stuff we see is waiting on hard drive performance, network bandedith, or user input... so cpu isn't the bottleneck there anyway.
The funny thing is that it teeter-totters back and forth from one core to the other. I wish I knew what made it do that.
If you look at task manager, there what? some 40+ processes running. The OS rotates them onto an off of the 2 cores based on what they all need in terms of cpu time. So your 'cpu heavy task' gets pulled off a core to give another task a timeslice, and then once its off, it can be scheduled back onto either core. Ideally should stay on one core to maximize level one cache hits, etc, but if its been off the core long enough for the other processes to cache all new memory it doesn't really matter which one it gets assigned to, and in any case flipping from one to the other every now and then makes a almost immeasurably small performance difference.
btw - the 'set processor affinity' feature tells the OS that you really want this process to run on a given cpu/core, instead of hopping around. But in most cases its not something one needs (or gains any benefit) from doing.
I remember something from that time that suggested it was simply a supply issue - AMD weren't big enough to guarantee supply. I remember looking at the figures and being surprised (about the capacity of AMD).
I also remember Jobs saying Intel had shown him _very_ exciting things, hint hint. And they were too.
lemonade was a popular drink and it still is
Surely no one would ever need more...
That University of Illinois machine sounds like it needs more memory.
Only 620TB? Why not bump it up to 640? That should be enough for anybody.
The opinions expressed here are those of this individual, and may not reflect the policy or practice of the collective
A couple things:
x86 chips today are 99% RISC-like (the term RISC is rarely uses today, since basically no modern CPUs are "pure RISC" in design (reduced as in not even having a multiply instruction, like older SPARCs). Sure the exposed architecture is ugly x86, but that's the compiler's job to worry about, not yours. It doesn't really affect the chip performance. Don't forget x86 chips are still the fastest out there, despite the weird interface)
Also, for Joe Sixpack, 64-bit is pointless - especially when the 32-bit version works on the same OS! If you recompile a program as 64-bit (and often that is all there is to it; a recompile), you'll notice that the binaries are larger. In fact, most pointers (memory addresses) now takes up twice the space, so your program also uses more memory. The benefit? Unless your app uses more than around 3GB of RAM, basically zero (On x86 there is a sometimes a slight performance benefit, not because 64-bits is "faster" or anything, but because AMD added some more registers to the x86-64 spec).
Anyhow, i generally view 64-bits as a waste of address space, UNLESS you're accessing large amounts of memory (>3GB per program!). This will be more of a concern in the next few years, but there isn't any rush. I use 64-bit Vista for development (Because I have 4GB of RAM) but otherwise probably wouldn't care. Even Visual Studio (the dev platform for 64-bit code) is mostly a 32-bit app, nor should they change it.
Jeremy
No, that is not a problem. Linux, including Ubuntu, has been running on PS3 since the PS3 was released. Every Ubuntu since 6.10 has run on it. And current releases of other Linux (PPC) distros usually do install, especially the Yellow Dog that is the one officially supported by Sony. But the problem is that the Ubuntu team has too few developers, and new features in Ubuntu releases break the installation in ways that the small Cell/PPC team can't keep up with.
Also, there's nothing really "puny" about the Cell's PPC core, which is a 3.2GHz dual-hyperthread Power core.
The Cell/Linux platform has already got video drivers that offload graphics from the PPC to the DSPs the same way most distros run graphics on separate VGA chips. It's a little buggy, in beta, but that's why the project just needs more developers. Not more FUD.
I don't think you really know anything about how Linux actually runs on the Cell, on the PS3. I think you're just repeating the most whiny posts about it you've heard. Because the reality is very different from what you describe, even if it's still got problems. Problems that don't require waiting for more x86 HW revisions, but rather just a little more work on the Cell Linux that Ubuntu is releasing.
--
make install -not war