Take a look at all 3000+ SPEC2000 results published on spec.org. Every single one of them reports single core or single processor results. All 26 CPU2000 bench programs are single threaded.
Clearly you don't understand what 'single threaded' means. The number of treads that a piece of software uses has nothing to do with the numbers that you're reading on the SPEC results page.
Quote:
In the case of P4 HT on versus off, the P4 performed worse when HT was turned on, most likely due to the loss of resources which were shared with some other thread of execution when HT was on.
It's not real easy to find SPEC results for runs that differ only by HT Enabled vs HT Disabled, but I took a quick check and found these two:
It's virtually the only way to assess multi-core, multiprocessor performance using the SPEC CPU bench. If it tells very little, then we should stop using it.
Fine, if you don't like it then don't use it.
Quote:
So, what are the difference exactly between the Power5 and Power4? What was the huge step forward? What does the RealWorldTech article say that I don't say?
I'm really curious about it.
I've already posted the link. If you've read the friendly article, then you'll know. If you haven't read it, then maybe you should. Paul does a much better job of covering this in the article than I'm going to be to do here.
Quote:
No, IBM didn't really care about it...
I think that we can agree that PPC wasn't IBM's highest priority but you've got to give them credit for all the money and time that they've poured into that project.
Take a look at all 3000+ SPEC2000 results published on spec.org. Every single one of them reports single core or single processor results.
Ummm, there are results for '2 cores, 2 chips, 1 core/chip'.
There are results for ' 8 cores, 4 chips, 2 cores/chip'.
There are even results for '64 cores, 32 chips, 2 cores/chip'. And there may be results for other combinations but it's not worth my time to document them all. For anyone who wants to see recent examples, click here: http://www.spec.org/cpu2000/results/res2004q4/
There's quite a body of literature that discusses the level of ILP that's actually present SPEC. There's not much but there's more than zero. In these papers you will find discussions of the effectiveness of various compilers (and CPUs) in taking advantage of that ILP.
Ummm, there are results for '2 cores, 2 chips, 1 core/chip'.
There are results for ' 8 cores, 4 chips, 2 cores/chip'.
There are even results for '64 cores, 32 chips, 2 cores/chip'. And there may be results for other combinations but it's not worth my time to document them all. For anyone who wants to see recent examples, click here: http://www.spec.org/cpu2000/results/res2004q4/
Yeah, but look at the scores. SPEC CPU2000 is single threaded and only tests the performance of 1 core. Look at them very carefully. Every single SPEC CPUint/fp2000 bench is single threaded, runs on one core.
For example, look at the SPECint2000 Power5 scores:
A 1.65 GHz Power5 with a "#CPU" of "1 core, 1 chip, 1 chip/core (SMT off)" has a base SPECint2k of 1200. Next line down is a system with "8 cores, 4 chips, 2 cores/chip (SMT off)" yet the SPECint2k score is only 1383. Think about that. A system with 8 cores only yields a 15% performance improvement in SPECint2000. I hope that strikes you as really strange.
Then look at the eServer P5 595 system again. It has 1.9 GHz Power5 CPUs. That's a 15% improvement in clock rate over the 1.65 GHz p5 590 system. The SPECint2k score is 1383/1200 = 1.15, a 15% improvement!
The 15% difference in SPECint2k is accounted for by the 15% increase in clock rate. SPEC CPUint2000 is single threaded and can only run on one core at a time.
The 64 core p5 595 has a base score of 2549 while the 32 core p5 590 has a base score of 2223. 2549/2223 = 1.15 (15%) directly corresponds to the 1.9/1.65 = 1.15 (15%) clock rate increase. You would think that having twice as many cores would yield more than a 15% increase in performance, but in the case of SPECfp2000, it doesn't matter, because it is single threaded code, and the clock rate increase exactly accounts for the performance difference.
It can only run on 1 core at a time.
Now the OpenPower 720 CPUint/fp2000 scores versus the eServer p5 590 scores are interesting. Same 1.65 GHz Power5 CPU, yet the OpenPower system has 7% and 19% lower int and fp scores. The OpenPower system runs Linux with the IBM XL compilers. The eServer p5 590 runs AIX with IBM XL compilers. Hmm, something tells me that IBM has optimized IBM XL compilers for AIX better than the XL compilers for Linux.
Quote:
There's quite a body of literature that discusses the level of ILP that's actually present SPEC. There's not much but there's more than zero. In these papers you will find discussions of the effectiveness of various compilers (and CPUs) in taking advantage of that ILP.
ILP has not much to do with multithreading. Instruction level parallelism is about extracting as much performancing out of single threaded code, one stream of execution, as possible. Multithreaded code means that the code has two concurrent streams of execution.
To take advantage of multi-core, simultaneous multithreading, or both requires that a code be multithreaded. A task is split up into multiple streams of execution and then the streams are run in parallel. The CPUs that are able to do this are multi-core processors, simultaneous multithreaded processors, or those that combine both. The SPEC_rate scores are the benches that provide a measure of how well a multiprocessing system performs. Look at the scores. Having multiple cores actually improve the SPEC_rate scores by the appropriate amounts.
Clearly you don't understand what 'single threaded' means. The number of treads that a piece of software uses has nothing to do with the numbers that you're reading on the SPEC results page.
You said: There's quite a lot of multithreading in [SPECint/fp2000]. In fact, this gets brought up all the time in discussions of Intel's Hyperthreading technology.
If SPEC CPU2000 is multithreaded, why don't the processors with multiple cores or SMT reflect that?
Why is an 8 core IBM eServer p5 595 only 15% faster than a 1 core eServer p5 590?
And you need to look at the P4 HT enabled vs disabled scores again. When HT is enabled, the P4 is generally a little bit slower in SPEC CPU2000.
Quote:
I've already posted the link. If you've read the friendly article, then you'll know. If you haven't read it, then maybe you should. Paul does a much better job of covering this in the article than I'm going to be to do here.
Hehe. I'll repeat. The big difference between the Power4 and Power5 is the memory subsystem. The Power4 and Power5 have the same exact number of execution resources (ALUs, FPUs and LSUs). The evolution is providing the resources for SMT support and a much better memory subsystem. That's it.
What you said: Not even close. POWER5 is a huge step forward. If you read the RealWorldTech article, you would realize that they support my statement exactly.
Quote:
I think that we can agree that PPC wasn't IBM's highest priority but you've got to give them credit for all the money and time that they've poured into that project.
Yeah, but look at the scores. SPEC CPU2000 is single threaded and only tests the performance of 1 core. Look at them very carefully. Every single SPEC CPUint/fp2000 bench is single threaded, runs on one core.
If you take an app that has a single thread and you put it onto a platform with more than one CPU then that app is not going to run on only one CPU unless you specifically lock the thread to a CPU. Execution is going to move between CPUs as the scheduler sees fit.
How do you know the exact thread structure of these tests? Do you have the source code. Can you provide us with a link that confirms your opinion?
Quote:
I hope that strikes you as really strange.
That's a very odd thing to hope for. I've made it very clear that there is limited ILP.
Quote:
It can only run on 1 core at a time.
That wasn't my point. Compilers can take advantage of the ILP and having multiple cores means that you have multiple caches which gives the scheduler options for increasing the cache hit rate.
Quote:
To take advantage of multi-core, simultaneous multithreading, or both requires that a code be multithreaded.
No, in fact you've already cited data that shows that there are improvements running on more than one core.
Quote:
If SPEC CPU2000 is multithreaded, why don't the processors with multiple cores or SMT reflect that?
I was wrong to say that there is 'quite a lot'. I corrected that in later postings.
Quote:
Why is an 8 core IBM eServer p5 595 only 15% faster than a 1 core eServer p5 590?
see above.
Quote:
And you need to look at the P4 HT enabled vs disabled scores again. When HT is enabled, the P4 is generally a little bit slower in SPEC CPU2000.
Gheese dude it's a typo; and more to the point, I cited the data, and the effect is 1 blessed percent. I was responding to the claim that HT enabled vs disabled was a significant issue. I pointed out that it's no big deal.
You're changing your story about POWER5. What you originally said was
Quote:
A Power5 core is just simply an evolution of the Power4 core
And you repeated this again in your last post
Quote:
Hehe. I'll repeat. The big difference between the Power4 and Power5 is the memory subsystem. The Power4 and Power5 have the same exact number of execution resources (ALUs, FPUs and LSUs).
Which of course is not true, The truth is that in addition to the changes to the memory subsystem, the POWER5 has SMT and POWER4 doesn't. To quote the link that I provided:
Quote:
To support SMT, the POWER5fs architects increased the number GPR physical rename registers from 80 to 120 and the number of FPR rename registers from 72 to 120 [1][2]. The additional FP rename capability had the benefit of increasing POWER5fs single thread performance on some HPC workloads compared to the original POWER4 microarchitecture; this gain stemmed from an enhanced ability to execute critical code sections out of order.
Despite the significant internal and external architectural changes that separate the POWER4 and POWER5, their device floorplans are remarkably similar...
So you're mixing up the time line when you write
Quote:
The evolution is providing the resources for SMT support and a much better memory subsystem. That's it.
If you had said that in the first place then I wouldn't have referred you the RWT article.
If you take an app that has a single thread and you put it onto a platform with more than one CPU then that app is not going to run on only one CPU unless you specifically lock the thread to a CPU. Execution is going to move between CPUs as the scheduler sees fit.
Moving a single thread around from processor to processor only decreases performance. That's why modern OS schedulers will keep the thread on one processor, and thus only one processor will be used.
Quote:
How do you know the exact thread structure of these tests? Do you have the source code. Can you provide us with a link that confirms your opinion?
I have the SPEC CPU source code, although I have not examined it in detail. The fact that SPEC CPU is single-threaded is so well-known that I can't find any documentation about it.
Quote:
That wasn't my point. Compilers can take advantage of the ILP and having multiple cores means that you have multiple caches which gives the scheduler options for increasing the cache hit rate.
ILP has nothing to do with the number of cores. Auto-parallelizing compilers for general code effectively do not exist. If you give the compiler a single-threaded program (like SPEC CPU), you get a single-threaded program out.
It is usually not possible for a single core to take advantage of multiple caches at once.
Moving a single thread around from processor to processor only decreases performance. That's why modern OS schedulers will keep the thread on one processor, and thus only one processor will be used.
Nope, in fact schedulers do move threads. That's the default behavior for schedulers. Moving them effectively is the issue, and the fact is that some code benefits from being locked to a CPU and some doesn't. Haven't you ever played with this?
Quote:
The fact that SPEC CPU is single-threaded is so well-known that I can't find any documentation about it.
That's one of the most, ummmm, interesting definitions of 'well known' that I've ever heard.
Care to say why running the code on multiple cores improves its performance?
Quote:
ILP has nothing to do with the number of cores.
No one ever said that ILP depended on the number of cores. How in the freaking heck could it possible?
And now from the Office of Sweeping Generalities
Quote:
Auto-parallelizing compilers for general code effectively do not exist.
Cheese, and some people say that I'm given to over generalization. I think I've found my match.
But more to the point, we're not talking about 'general code' we're talking about Engineering and Scientific codes -- and these kinds of codes are 'generally' good candidates for parallelizing compilers.
That's just one of many. This topic is old, old, old.
Quote:
If you give the compiler a single-threaded program (like SPEC CPU), you get a single-threaded program out.
Actually it is possible to spawn new threads and handle the rescychronization issues. Most compilers don't know how, and it's not always a good idea, and maybe it's Wednesday and there are no piano lessions (it's an old Pogo joke (probably not worth making but I am, after all, a silly fool)).
Quote:
It is usually not possible for a single core to take advantage of multiple caches at once.
I never said that it was. The point is that if you have two cores AND you have more cache (which as we know isn't always the case but I feel like have I to say this just to short circuit another objection); then there are games that the scheduler can play that allows it to take advantage of the fact that some data (or code) may already be 'pre-fetched' in 'the other cache'.
I have no idea what you guys are saying but this is a lot of fun as you're both very convincing.
I find myself siding with one post and saying "yea take that" just to have my excitement crushed by the reply. I then side with that reply post and think, "you douche bag, very clearly you're out of your mind"! This is quickly followed by, "but then again, the reply to the reply does sound pretty convincing".
Anyway, I'm going to bed but I'm sure glad smart people like you guys figure all this crap out so I can read these boards
If you take an app that has a single thread and you put it onto a platform with more than one CPU then that app is not going to run on only one CPU unless you specifically lock the thread to a CPU. Execution is going to move between CPUs as the scheduler sees fit.
And most schedulers will give a single threaded app one CPU or core to run it. It would only move it if there is a higher priority item. Still it only runs on only 1 CPU at a time.
Quote:
How do you know the exact thread structure of these tests? Do you have the source code. Can you provide us with a link that confirms your opinion?
Q12: What is the difference between a "rate" and a "non-rate" metric?
A12: There are several different ways to measure computer performance. One way is to measure how fast the computer completes a single task; this is a speed measurement. Another way is to measure how many tasks a computer can accomplish in a certain amount of time; this is called a throughput, capacity or rate measurement.
The SPEC speed metrics, or non-rate metrics, (i.e., SPECint2000) are used for comparing the ability of a computer to complete single tasks. The SPEC rate metrics (i.e., SPECint_rate2000) measure the throughput or rate of a machine carrying out a number of similar tasks. Traditionally, the rate metrics have been used to demonstrate the performance of multi-processor systems.
A single task equates to single threaded code. All the performance numbers for SPECint/fp2k indicate it is single threaded code.
Quote:
That's a very odd thing to hope for. I've made it very clear that there is limited ILP.
That wasn't my point. Compilers can take advantage of the ILP and having multiple cores means that you have multiple caches which gives the scheduler options for increasing the cache hit rate.
It still means the code is single threaded. It still means the OS will run the single threaded code on one core and not move it to another core. The only reason an OS scheduler would move a thread from one core to another is if there are higher priority threads needing core resources. That really isn't going to happen in benchmark runs.
Quote:
THT:To take advantage of multi-core, simultaneous multithreading, or both requires that a code be multithreaded.
sillyfool: No, in fact you've already cited data that shows that there are improvements running on more than one core.
The only data I've cited is that SPECint/fp2k runs only on 1 core of a multiprocessor system, SMT system, or a system with both. SPECint/fp2k assesses the performance of one core only (and its memory system and compiler/OS).
The only way to assess performance of multiprocessor systems, SMT systems, or systems that have both is to use the SPEC_rate scores.
Quote:
Gheese dude it's a typo; and more to the point, I cited the data, and the effect is 1 blessed percent. I was responding to the claim that HT enabled vs disabled was a significant issue. I pointed out that it's no big deal.
You cited data erroneously. Your links indicate that:
The Dell Precision results does not say it was HT enabled or not. But you stated: 1267 (Enabled) vs 1252 (Disabled) is about 1%.
The Intel D875PBZ results page state that it had HT on. Was this the system you quoted to have HT on? Because if you did, you quoted the peak score.
The "1252 (Disabled)" doesn't make sense since the Intel D875PBZ states that it had HT enabled.
This is what I think. The Dell Precision system had HT disabled and achieved a base SPECfp2k score of 1267. The Intel D875PBZ had HT enabled and achieved a based SPECfp2k score of 1252. The HT-enabled system (D875PBZ) was slower because the processor had to split its resources for 2 threads while the HT-disabled system (Dell Precision) performed 1% better because it could devote all of its resources to one 1 thread.
One thing that you'll find in the published results however is that Intel made motherboards or Intel tested systems seem to have better performance than boards made by other vendors given the same CPU. It's amazing enough to wonder if Intel is "knows" something that others don't.
Quote:
You're changing your story about POWER5. What you originally said was A Power5 core is just simply an evolution of the Power4 core
...
Which of course is not true, The truth is that in addition to the changes to the memory subsystem, the POWER5 has SMT and POWER4 doesn't.
I also said in the same paragraph: But as far as SPECint/fp2000 are concerned, it only runs on one core or one processor. In terms of execution units and SPEC, the three are nearly identical.
And I said later in the same post: Power5 improves on the Power4's memory system with an on-die main memory controller, a backside L3 cache, lower latency cache at all levels, and more register resources.
You know why I bolded more register resources in quoting myself? Because those resources were needed to support SMT, but in terms of SPECint/fp2k where SMT was off, and the Power5 eeks out more single threaded performance because it would have more register resources. I quote from the very same RealWorldTech article you linked and make bold the part that is important in the context of SPECint/fp2k:
To support SMT, the POWER5?s architects increased the number GPR physical rename registers from 80 to 120 and the number of FPR rename registers from 72 to 120 [1][2]. The additional FP rename capability had the benefit of increasing POWER5?s single thread performance on some HPC workloads compared to the original POWER4 microarchitecture; this gain stemmed from an enhanced ability to execute critical code sections out of order.
You even quoted this paragraph youself. The article states "additional FP rename capability had the benefit of increasing POWER5?s single thread performance on some HPC workloads compared to the original POWER4 microarchitecture." Wow, additional registers helping single thread performance.
Look at what I said again: "Power5 improves on the Power4's memory system with an on-die main memory controller, a backside L3 cache, lower latency cache at all levels, and more register resources." Wow, additional registers was one of the improvements from Power4 to Power5.
Lets do some more quoting from the RealWorldTech article:
But higher clock frequency and SMT, are not the primary performance differentiator between the POWER4 and POWER5 architectures. Nearly ten years ago when DEC MPU designers were considering their third generation RISC design, chief Alpha architect Dick Sites reportedly summarized his analysis of the biggest short coming of the second generation EV5 chip with the concise phrase ?It?s the memory, stupid?. It is clear now that IBM?s server MPU architects consider Site?s advice as relevant today as it was a decade ago. The most distinguishing characteristics of the POWER5 are the extent that IBM improved upon the POWER4+?s cache and memory system hierarchy.
RealWorldTech says that "SMT [is] not the primary performance differentiator." It says that the "most distinguishing characteristics of the POWER5 are the extent that IBM improved upon the POWER4+?s cache and memory system hierarchy." Does that say SMT is "huge" to you? It doesn't to me. It's evolutionary.
Quote:
So you're mixing up the time line when you write ... If you had said that in the first place then I wouldn't have referred you the RWT article.
I consider SMT to be an evolution. I contend that it is only an evolution and the adjective of "huge" doesn't really apply when SMT added to Power4, (let alone the SMT added to the P4). I'd call it huge when execution resources (ALUs, FPUs, LSUs) are added along with SMT so that a multiprocessor-like speedup can be had.
In the context of my original post about Power4/Power5/970 and SPEC, the only thing important was that the Power5 had more register resources (among other memory improvements) than the Power4. Those additional register resources added were for SMT, but SMT provides no performance benefit for SPECint/fp2k benches in of itself. The benches are single threaded! And all Power5 SPECint/fp2k scores were done with SMT off. The only advantage that SMT added for SPECint/fp2k was coincidental, and that came in the form of more register resources.
It is widely known that SPEC is heavily dependent on the memory subsystem, but as it is completely cross-platform code no optimizations are made for a particular hardware system... at least outside of the compilers, some of which specifically detect when they are compiling SPEC and do special things that are only useful for speeding up SPEC.
A problem with this is that it makes SPEC not particularly representative of code that somebody actually optimizes for the platform, even without trying to take advantage of things like SIMD units and multiple processors.
One thing that you'll find in the published results however is that Intel made motherboards or Intel tested systems seem to have better performance than boards made by other vendors given the same CPU. It's amazing enough to wonder if Intel is "knows" something that others don't.
Hmm... yeah. Intel know how to design boards better than sweatshops out in Taiwan. That should be a nobrainer.
If you mean with that higer clocked frequency (3.6GHz) wil the CPU's perform faster than a 2.7GHz PPC? Answer is no, but I'm surprised you never reasearched the MHz myth before.
Apple is betting on future CPU's from intel besides. I don't think the current ones are what compelled Apple to switch, because they are not that impressive performance per clock cycle. Look at AMD smoke'en'em at 2.6 GHz.
I dont buy the MHZ myth crap, in the proc war, you mac zelots never account for the fact that Windows XP is bady stiched together 12 year old (based on NT 3.5) bloatware, it is insainly inefficiant and in 90% of cases loaded with crap whereas Macosx runs on BSD and is always being tweaked for peak efficiency whilst at the same time Win gets more bloat (Jag->panther->tiger VS XP->sp1->sp2)
also, due to NDAs and tha sort of thing, the numbers we are seeing now are bogus because the people with the kind of access to do propper testing (not just a benchmark in the middle of a trade show) are not talking - also the current OS version is not what will be shipping on the intel units (unless 10.4.2, 10.4.3...are all held till like April ) so no one knows what the proformance of the final units will be, hell no one even knows the specs or pricepoints.
WOW, THT! I don't think I've seen you get this charged up over anything for a loooong time (if ever). I always learn something new whenever you step into the fray, though.
Windows XP is bady stiched together 12 year old (based on NT 3.5) bloatware, it is insainly inefficiant and in 90% of cases loaded with crap whereas Macosx runs on BSD and is always being tweaked for peak efficiency whilst at the same time Win gets more bloat (Jag->panther->tiger VS XP->sp1->sp2)
Is this something that you blindly believe because your cult leader, Stevo, said, or beause you personally investigated it?
The fact that XP is based (somewhat loosely now) on NT 3.5 is a good thing, because NT 3.5 will give any Unix a run for its money in terms of speed and stability. Certifying the software for it was a bitch though.
The fact that XP is based (somewhat loosely now) on NT 3.5 is a good thing, because NT 3.5 will give any Unix a run for its money in terms of speed and stability. Certifying the software for it was a bitch though.
WOW, THT! I don't think I've seen you get this charged up over anything for a loooong time (if ever). I always learn something new whenever you step into the fray, though.
Comments
Take a look at all 3000+ SPEC2000 results published on spec.org. Every single one of them reports single core or single processor results. All 26 CPU2000 bench programs are single threaded.
Clearly you don't understand what 'single threaded' means. The number of treads that a piece of software uses has nothing to do with the numbers that you're reading on the SPEC results page.
In the case of P4 HT on versus off, the P4 performed worse when HT was turned on, most likely due to the loss of resources which were shared with some other thread of execution when HT was on.
It's not real easy to find SPEC results for runs that differ only by HT Enabled vs HT Disabled, but I took a quick check and found these two:
http://www.spec.org/cpu2000/results/...701-02363.html
http://www.spec.org/cpu2000/results/...616-02266.html
1267 (Enabled) vs 1252 (Disabled) is about 1%.
It's virtually the only way to assess multi-core, multiprocessor performance using the SPEC CPU bench. If it tells very little, then we should stop using it.
Fine, if you don't like it then don't use it.
So, what are the difference exactly between the Power5 and Power4? What was the huge step forward? What does the RealWorldTech article say that I don't say?
I'm really curious about it.
I've already posted the link. If you've read the friendly article, then you'll know. If you haven't read it, then maybe you should. Paul does a much better job of covering this in the article than I'm going to be to do here.
No, IBM didn't really care about it...
I think that we can agree that PPC wasn't IBM's highest priority but you've got to give them credit for all the money and time that they've poured into that project.
Take a look at all 3000+ SPEC2000 results published on spec.org. Every single one of them reports single core or single processor results.
Ummm, there are results for '2 cores, 2 chips, 1 core/chip'.
There are results for ' 8 cores, 4 chips, 2 cores/chip'.
There are even results for '64 cores, 32 chips, 2 cores/chip'. And there may be results for other combinations but it's not worth my time to document them all. For anyone who wants to see recent examples, click here: http://www.spec.org/cpu2000/results/res2004q4/
There's quite a body of literature that discusses the level of ILP that's actually present SPEC. There's not much but there's more than zero. In these papers you will find discussions of the effectiveness of various compilers (and CPUs) in taking advantage of that ILP.
Originally posted by sillyfool
Ummm, there are results for '2 cores, 2 chips, 1 core/chip'.
There are results for ' 8 cores, 4 chips, 2 cores/chip'.
There are even results for '64 cores, 32 chips, 2 cores/chip'. And there may be results for other combinations but it's not worth my time to document them all. For anyone who wants to see recent examples, click here: http://www.spec.org/cpu2000/results/res2004q4/
Yeah, but look at the scores. SPEC CPU2000 is single threaded and only tests the performance of 1 core. Look at them very carefully. Every single SPEC CPUint/fp2000 bench is single threaded, runs on one core.
For example, look at the SPECint2000 Power5 scores:
base peak
eServer p5 590(1650MHz,1CPU) 1core,1chip,1core/chip(SMT off) 1200 1259
eServer p5 595(1900MHz,1CPU) 8cores,4chips,2cores/chip(SMT off) 1383 1451
A 1.65 GHz Power5 with a "#CPU" of "1 core, 1 chip, 1 chip/core (SMT off)" has a base SPECint2k of 1200. Next line down is a system with "8 cores, 4 chips, 2 cores/chip (SMT off)" yet the SPECint2k score is only 1383. Think about that. A system with 8 cores only yields a 15% performance improvement in SPECint2000. I hope that strikes you as really strange.
Then look at the eServer P5 595 system again. It has 1.9 GHz Power5 CPUs. That's a 15% improvement in clock rate over the 1.65 GHz p5 590 system. The SPECint2k score is 1383/1200 = 1.15, a 15% improvement!
The 15% difference in SPECint2k is accounted for by the 15% increase in clock rate. SPEC CPUint2000 is single threaded and can only run on one core at a time.
Another example. Look at these SPECfp2k scores:
base peak
OpenPower720(1650MHz,Linux) 1core,1chip,2cores/chip (SMT off) 1865 1966
eServer p5 590(1650MHz,1CPU) 32cores,16chips,2cores/chip(SMT off) 2223 2398
eServer p5 595(1900MHz,1CPU) 64cores,32chips,2cores/chip(SMT off) 2549 2733
The 64 core p5 595 has a base score of 2549 while the 32 core p5 590 has a base score of 2223. 2549/2223 = 1.15 (15%) directly corresponds to the 1.9/1.65 = 1.15 (15%) clock rate increase. You would think that having twice as many cores would yield more than a 15% increase in performance, but in the case of SPECfp2000, it doesn't matter, because it is single threaded code, and the clock rate increase exactly accounts for the performance difference.
It can only run on 1 core at a time.
Now the OpenPower 720 CPUint/fp2000 scores versus the eServer p5 590 scores are interesting. Same 1.65 GHz Power5 CPU, yet the OpenPower system has 7% and 19% lower int and fp scores. The OpenPower system runs Linux with the IBM XL compilers. The eServer p5 590 runs AIX with IBM XL compilers. Hmm, something tells me that IBM has optimized IBM XL compilers for AIX better than the XL compilers for Linux.
There's quite a body of literature that discusses the level of ILP that's actually present SPEC. There's not much but there's more than zero. In these papers you will find discussions of the effectiveness of various compilers (and CPUs) in taking advantage of that ILP.
ILP has not much to do with multithreading. Instruction level parallelism is about extracting as much performancing out of single threaded code, one stream of execution, as possible. Multithreaded code means that the code has two concurrent streams of execution.
To take advantage of multi-core, simultaneous multithreading, or both requires that a code be multithreaded. A task is split up into multiple streams of execution and then the streams are run in parallel. The CPUs that are able to do this are multi-core processors, simultaneous multithreaded processors, or those that combine both. The SPEC_rate scores are the benches that provide a measure of how well a multiprocessing system performs. Look at the scores. Having multiple cores actually improve the SPEC_rate scores by the appropriate amounts.
[edit: shortened code width]
Originally posted by sillyfool
Clearly you don't understand what 'single threaded' means. The number of treads that a piece of software uses has nothing to do with the numbers that you're reading on the SPEC results page.
You said: There's quite a lot of multithreading in [SPECint/fp2000]. In fact, this gets brought up all the time in discussions of Intel's Hyperthreading technology.
If SPEC CPU2000 is multithreaded, why don't the processors with multiple cores or SMT reflect that?
Why is an 8 core IBM eServer p5 595 only 15% faster than a 1 core eServer p5 590?
And you need to look at the P4 HT enabled vs disabled scores again. When HT is enabled, the P4 is generally a little bit slower in SPEC CPU2000.
I've already posted the link. If you've read the friendly article, then you'll know. If you haven't read it, then maybe you should. Paul does a much better job of covering this in the article than I'm going to be to do here.
Hehe. I'll repeat. The big difference between the Power4 and Power5 is the memory subsystem. The Power4 and Power5 have the same exact number of execution resources (ALUs, FPUs and LSUs). The evolution is providing the resources for SMT support and a much better memory subsystem. That's it.
What you said: Not even close. POWER5 is a huge step forward. If you read the RealWorldTech article, you would realize that they support my statement exactly.
I think that we can agree that PPC wasn't IBM's highest priority but you've got to give them credit for all the money and time that they've poured into that project.
From the perspective of Apple, no, I wouldn't.
Yeah, but look at the scores. SPEC CPU2000 is single threaded and only tests the performance of 1 core. Look at them very carefully. Every single SPEC CPUint/fp2000 bench is single threaded, runs on one core.
If you take an app that has a single thread and you put it onto a platform with more than one CPU then that app is not going to run on only one CPU unless you specifically lock the thread to a CPU. Execution is going to move between CPUs as the scheduler sees fit.
How do you know the exact thread structure of these tests? Do you have the source code. Can you provide us with a link that confirms your opinion?
I hope that strikes you as really strange.
That's a very odd thing to hope for. I've made it very clear that there is limited ILP.
It can only run on 1 core at a time.
That wasn't my point. Compilers can take advantage of the ILP and having multiple cores means that you have multiple caches which gives the scheduler options for increasing the cache hit rate.
To take advantage of multi-core, simultaneous multithreading, or both requires that a code be multithreaded.
No, in fact you've already cited data that shows that there are improvements running on more than one core.
If SPEC CPU2000 is multithreaded, why don't the processors with multiple cores or SMT reflect that?
I was wrong to say that there is 'quite a lot'. I corrected that in later postings.
Why is an 8 core IBM eServer p5 595 only 15% faster than a 1 core eServer p5 590?
see above.
And you need to look at the P4 HT enabled vs disabled scores again. When HT is enabled, the P4 is generally a little bit slower in SPEC CPU2000.
Gheese dude it's a typo; and more to the point, I cited the data, and the effect is 1 blessed percent. I was responding to the claim that HT enabled vs disabled was a significant issue. I pointed out that it's no big deal.
You're changing your story about POWER5. What you originally said was
A Power5 core is just simply an evolution of the Power4 core
And you repeated this again in your last post
Hehe. I'll repeat. The big difference between the Power4 and Power5 is the memory subsystem. The Power4 and Power5 have the same exact number of execution resources (ALUs, FPUs and LSUs).
Which of course is not true, The truth is that in addition to the changes to the memory subsystem, the POWER5 has SMT and POWER4 doesn't. To quote the link that I provided:
To support SMT, the POWER5fs architects increased the number GPR physical rename registers from 80 to 120 and the number of FPR rename registers from 72 to 120 [1][2]. The additional FP rename capability had the benefit of increasing POWER5fs single thread performance on some HPC workloads compared to the original POWER4 microarchitecture; this gain stemmed from an enhanced ability to execute critical code sections out of order.
Despite the significant internal and external architectural changes that separate the POWER4 and POWER5, their device floorplans are remarkably similar...
So you're mixing up the time line when you write
The evolution is providing the resources for SMT support and a much better memory subsystem. That's it.
If you had said that in the first place then I wouldn't have referred you the RWT article.
Originally posted by sillyfool
If you take an app that has a single thread and you put it onto a platform with more than one CPU then that app is not going to run on only one CPU unless you specifically lock the thread to a CPU. Execution is going to move between CPUs as the scheduler sees fit.
Moving a single thread around from processor to processor only decreases performance. That's why modern OS schedulers will keep the thread on one processor, and thus only one processor will be used.
How do you know the exact thread structure of these tests? Do you have the source code. Can you provide us with a link that confirms your opinion?
I have the SPEC CPU source code, although I have not examined it in detail. The fact that SPEC CPU is single-threaded is so well-known that I can't find any documentation about it.
That wasn't my point. Compilers can take advantage of the ILP and having multiple cores means that you have multiple caches which gives the scheduler options for increasing the cache hit rate.
ILP has nothing to do with the number of cores. Auto-parallelizing compilers for general code effectively do not exist. If you give the compiler a single-threaded program (like SPEC CPU), you get a single-threaded program out.
It is usually not possible for a single core to take advantage of multiple caches at once.
Moving a single thread around from processor to processor only decreases performance. That's why modern OS schedulers will keep the thread on one processor, and thus only one processor will be used.
Nope, in fact schedulers do move threads. That's the default behavior for schedulers. Moving them effectively is the issue, and the fact is that some code benefits from being locked to a CPU and some doesn't. Haven't you ever played with this?
The fact that SPEC CPU is single-threaded is so well-known that I can't find any documentation about it.
That's one of the most, ummmm, interesting definitions of 'well known' that I've ever heard.
Care to say why running the code on multiple cores improves its performance?
ILP has nothing to do with the number of cores.
No one ever said that ILP depended on the number of cores. How in the freaking heck could it possible?
And now from the Office of Sweeping Generalities
Auto-parallelizing compilers for general code effectively do not exist.
Cheese, and some people say that I'm given to over generalization. I think I've found my match.
But more to the point, we're not talking about 'general code' we're talking about Engineering and Scientific codes -- and these kinds of codes are 'generally' good candidates for parallelizing compilers.
Here's a link to one that claims 2x performance improvement in SPEC: http://www.apc.waseda.ac.jp/apc2003poster/00-2.pdf
That's just one of many. This topic is old, old, old.
If you give the compiler a single-threaded program (like SPEC CPU), you get a single-threaded program out.
Actually it is possible to spawn new threads and handle the rescychronization issues. Most compilers don't know how, and it's not always a good idea, and maybe it's Wednesday and there are no piano lessions (it's an old Pogo joke (probably not worth making but I am, after all, a silly fool)).
It is usually not possible for a single core to take advantage of multiple caches at once.
I never said that it was. The point is that if you have two cores AND you have more cache (which as we know isn't always the case but I feel like have I to say this just to short circuit another objection); then there are games that the scheduler can play that allows it to take advantage of the fact that some data (or code) may already be 'pre-fetched' in 'the other cache'.
I find myself siding with one post and saying "yea take that" just to have my excitement crushed by the reply. I then side with that reply post and think, "you douche bag, very clearly you're out of your mind"! This is quickly followed by, "but then again, the reply to the reply does sound pretty convincing".
Anyway, I'm going to bed but I'm sure glad smart people like you guys figure all this crap out so I can read these boards
Originally posted by sillyfool
If you take an app that has a single thread and you put it onto a platform with more than one CPU then that app is not going to run on only one CPU unless you specifically lock the thread to a CPU. Execution is going to move between CPUs as the scheduler sees fit.
And most schedulers will give a single threaded app one CPU or core to run it. It would only move it if there is a higher priority item. Still it only runs on only 1 CPU at a time.
How do you know the exact thread structure of these tests? Do you have the source code. Can you provide us with a link that confirms your opinion?
From the spec.org FAQ:
Q12: What is the difference between a "rate" and a "non-rate" metric?
A12: There are several different ways to measure computer performance. One way is to measure how fast the computer completes a single task; this is a speed measurement. Another way is to measure how many tasks a computer can accomplish in a certain amount of time; this is called a throughput, capacity or rate measurement.
The SPEC speed metrics, or non-rate metrics, (i.e., SPECint2000) are used for comparing the ability of a computer to complete single tasks. The SPEC rate metrics (i.e., SPECint_rate2000) measure the throughput or rate of a machine carrying out a number of similar tasks. Traditionally, the rate metrics have been used to demonstrate the performance of multi-processor systems.
A single task equates to single threaded code. All the performance numbers for SPECint/fp2k indicate it is single threaded code.
That's a very odd thing to hope for. I've made it very clear that there is limited ILP.
That wasn't my point. Compilers can take advantage of the ILP and having multiple cores means that you have multiple caches which gives the scheduler options for increasing the cache hit rate.
It still means the code is single threaded. It still means the OS will run the single threaded code on one core and not move it to another core. The only reason an OS scheduler would move a thread from one core to another is if there are higher priority threads needing core resources. That really isn't going to happen in benchmark runs.
THT:To take advantage of multi-core, simultaneous multithreading, or both requires that a code be multithreaded.
sillyfool: No, in fact you've already cited data that shows that there are improvements running on more than one core.
The only data I've cited is that SPECint/fp2k runs only on 1 core of a multiprocessor system, SMT system, or a system with both. SPECint/fp2k assesses the performance of one core only (and its memory system and compiler/OS).
The only way to assess performance of multiprocessor systems, SMT systems, or systems that have both is to use the SPEC_rate scores.
Gheese dude it's a typo; and more to the point, I cited the data, and the effect is 1 blessed percent. I was responding to the claim that HT enabled vs disabled was a significant issue. I pointed out that it's no big deal.
You cited data erroneously. Your links indicate that:
SPECfp2k SPECfp2k_base
Intel D875PBZ 1core, 1chip, 1core/chip (HT enabled) 1267 1252
Dell Precision 1core, 1chip, 1core/chip 1285 1267
The Dell Precision results does not say it was HT enabled or not. But you stated: 1267 (Enabled) vs 1252 (Disabled) is about 1%.
The Intel D875PBZ results page state that it had HT on. Was this the system you quoted to have HT on? Because if you did, you quoted the peak score.
The "1252 (Disabled)" doesn't make sense since the Intel D875PBZ states that it had HT enabled.
This is what I think. The Dell Precision system had HT disabled and achieved a base SPECfp2k score of 1267. The Intel D875PBZ had HT enabled and achieved a based SPECfp2k score of 1252. The HT-enabled system (D875PBZ) was slower because the processor had to split its resources for 2 threads while the HT-disabled system (Dell Precision) performed 1% better because it could devote all of its resources to one 1 thread.
One thing that you'll find in the published results however is that Intel made motherboards or Intel tested systems seem to have better performance than boards made by other vendors given the same CPU. It's amazing enough to wonder if Intel is "knows" something that others don't.
You're changing your story about POWER5. What you originally said was A Power5 core is just simply an evolution of the Power4 core
...
Which of course is not true, The truth is that in addition to the changes to the memory subsystem, the POWER5 has SMT and POWER4 doesn't.
I also said in the same paragraph: But as far as SPECint/fp2000 are concerned, it only runs on one core or one processor. In terms of execution units and SPEC, the three are nearly identical.
And I said later in the same post: Power5 improves on the Power4's memory system with an on-die main memory controller, a backside L3 cache, lower latency cache at all levels, and more register resources.
You know why I bolded more register resources in quoting myself? Because those resources were needed to support SMT, but in terms of SPECint/fp2k where SMT was off, and the Power5 eeks out more single threaded performance because it would have more register resources. I quote from the very same RealWorldTech article you linked and make bold the part that is important in the context of SPECint/fp2k:
To support SMT, the POWER5?s architects increased the number GPR physical rename registers from 80 to 120 and the number of FPR rename registers from 72 to 120 [1][2]. The additional FP rename capability had the benefit of increasing POWER5?s single thread performance on some HPC workloads compared to the original POWER4 microarchitecture; this gain stemmed from an enhanced ability to execute critical code sections out of order.
You even quoted this paragraph youself. The article states "additional FP rename capability had the benefit of increasing POWER5?s single thread performance on some HPC workloads compared to the original POWER4 microarchitecture." Wow, additional registers helping single thread performance.
Look at what I said again: "Power5 improves on the Power4's memory system with an on-die main memory controller, a backside L3 cache, lower latency cache at all levels, and more register resources." Wow, additional registers was one of the improvements from Power4 to Power5.
Lets do some more quoting from the RealWorldTech article:
But higher clock frequency and SMT, are not the primary performance differentiator between the POWER4 and POWER5 architectures. Nearly ten years ago when DEC MPU designers were considering their third generation RISC design, chief Alpha architect Dick Sites reportedly summarized his analysis of the biggest short coming of the second generation EV5 chip with the concise phrase ?It?s the memory, stupid?. It is clear now that IBM?s server MPU architects consider Site?s advice as relevant today as it was a decade ago. The most distinguishing characteristics of the POWER5 are the extent that IBM improved upon the POWER4+?s cache and memory system hierarchy.
RealWorldTech says that "SMT [is] not the primary performance differentiator." It says that the "most distinguishing characteristics of the POWER5 are the extent that IBM improved upon the POWER4+?s cache and memory system hierarchy." Does that say SMT is "huge" to you? It doesn't to me. It's evolutionary.
So you're mixing up the time line when you write ... If you had said that in the first place then I wouldn't have referred you the RWT article.
I consider SMT to be an evolution. I contend that it is only an evolution and the adjective of "huge" doesn't really apply when SMT added to Power4, (let alone the SMT added to the P4). I'd call it huge when execution resources (ALUs, FPUs, LSUs) are added along with SMT so that a multiprocessor-like speedup can be had.
In the context of my original post about Power4/Power5/970 and SPEC, the only thing important was that the Power5 had more register resources (among other memory improvements) than the Power4. Those additional register resources added were for SMT, but SMT provides no performance benefit for SPECint/fp2k benches in of itself. The benches are single threaded! And all Power5 SPECint/fp2k scores were done with SMT off. The only advantage that SMT added for SPECint/fp2k was coincidental, and that came in the form of more register resources.
No, I wasn't mixing up anything.
[edit: grammar]
A problem with this is that it makes SPEC not particularly representative of code that somebody actually optimizes for the platform, even without trying to take advantage of things like SIMD units and multiple processors.
One thing that you'll find in the published results however is that Intel made motherboards or Intel tested systems seem to have better performance than boards made by other vendors given the same CPU. It's amazing enough to wonder if Intel is "knows" something that others don't.
Hmm... yeah. Intel know how to design boards better than sweatshops out in Taiwan. That should be a nobrainer.
Originally posted by onlooker
If you mean with that higer clocked frequency (3.6GHz) wil the CPU's perform faster than a 2.7GHz PPC? Answer is no, but I'm surprised you never reasearched the MHz myth before.
Apple is betting on future CPU's from intel besides. I don't think the current ones are what compelled Apple to switch, because they are not that impressive performance per clock cycle. Look at AMD smoke'en'em at 2.6 GHz.
I dont buy the MHZ myth crap, in the proc war, you mac zelots never account for the fact that Windows XP is bady stiched together 12 year old (based on NT 3.5) bloatware, it is insainly inefficiant and in 90% of cases loaded with crap whereas Macosx runs on BSD and is always being tweaked for peak efficiency whilst at the same time Win gets more bloat (Jag->panther->tiger VS XP->sp1->sp2)
also, due to NDAs and tha sort of thing, the numbers we are seeing now are bogus because the people with the kind of access to do propper testing (not just a benchmark in the middle of a trade show) are not talking - also the current OS version is not what will be shipping on the intel units (unless 10.4.2, 10.4.3...are all held till like April ) so no one knows what the proformance of the final units will be, hell no one even knows the specs or pricepoints.
Windows XP is bady stiched together 12 year old (based on NT 3.5) bloatware, it is insainly inefficiant and in 90% of cases loaded with crap whereas Macosx runs on BSD and is always being tweaked for peak efficiency whilst at the same time Win gets more bloat (Jag->panther->tiger VS XP->sp1->sp2)
Is this something that you blindly believe because your cult leader, Stevo, said, or beause you personally investigated it?
The fact that XP is based (somewhat loosely now) on NT 3.5 is a good thing, because NT 3.5 will give any Unix a run for its money in terms of speed and stability. Certifying the software for it was a bitch though.
Originally posted by skatman
The fact that XP is based (somewhat loosely now) on NT 3.5 is a good thing, because NT 3.5 will give any Unix a run for its money in terms of speed and stability. Certifying the software for it was a bitch though.
Originally posted by Randycat99
WOW, THT! I don't think I've seen you get this charged up over anything for a loooong time (if ever).
Aww jeez, look what I started....
Yea, lots of info in here, I love it.