heh... using Apple's special SPEC executables maybe. I look at http://www.spec.org for my SPEC results, not something tailored by Apple.
Re:Can't find SPEC results at spec.org for Apple??
on
G5 Benchmark Roundup
·
· Score: 1
.... except that most companies run the SPEC benchmarks and publish the results before you can actually buy a computer with the CPU in it. Check out the history of just about any of the computers listed in the SPEC registry. In fact, the [est] Madison SPEC are already there and I haven't seen where I could buy one of those yet.
Yeah, imagine that... instead of admin forcing folks to use what *they* thought the users should use. To think that any single OS fits all is simple religion.
Can't be killed, true. It's like letting the cat (code) out of the bag. Once it's out, it's out. However, litigation and the like can scare the money away from Linux in a big way, which would relegate Linux back to its tinkering/hacking existance from long ago. You wouldn't see any more of the YYY School switches to Linux... AnyTown, USA switches to Linux... or CompanyB switches to Linux posts anymore, at least for a long time.
Pronounced "Fizz-tee," the software is so powerful, it individually simulated each of the 3 million hairs that cover one of the lead monsters, and into the bargain, it reduced the process from weeks to hours.
When I was in college, Motorola donated tons of stuff to different schools. For instance, we had lots of the 68HC000 trainer boards and plenty of parts to make 68K machines with.
For a project, my partner and I even wrote to Motorola including a parts list and a discussion of the proposal of our project and they shipped us a bunch of free parts to use. At the time, some of the parts we got were near top of the line. For example, the 33/40 MHz 68040s were the top of the line and we requested and received a 25MHz part.
Why did they do these things? Well, just as you said. Get folks to learn using your stuff and they will most likely stick with it or recommend it later. It's an investment for the company.
As opposed to employing Windows administrators? As people have pointed out time and time again, the greater number of systems that a Linux admin can administer is much more than the 30% or so extra that that admin makes.
Yeah, crappy admin. Our team of 10 admin service around 11,000 computers, of which, around 2/3 are Windows boxes. Maybe you should hire admin who know what they are doing.
I know this is mod as funny but, this scenario would be highly doubtful as they would most likely have wanted some level of support to go along with the software.
Something that folks frequently forget is that not everyone knows how to install and support software on Linux much less install and support Linux on hardware. You cannot expect non-technical folks to do it all themselves.
EverQuest had the same rules at one time and it was enforced sometimes. A year or so ago they said they didn't care anymore and relaxed the restrictions a lot.
I haven't been paying attention to it that much but SOE just released the Mac version of EverQuest so I wouldn't be surprised if there isn't a Mac version of SWG somewhere in the pipe.
WHAT IS YOUR FUCKING PROBLEM? WHY ARE YOU THREATENED BY THE FACT THAT A MAC IS FASTER THAN THE FASTEST PC?
I'm not at all. Why are you so threatened that people say that the Mac isn't? I could care less if we were talking about two completely different processors as long as the tests were fair, which they weren't, in a bunch of folk's opinion. Is it that finally Apple presents something to you and you are so desperate to believe it that you will do anything to cling to it?
If it is that important to you, I'll even say that the Mac is faster given that test. I think the test was a waste of time and showed nothing and proof that is conclusive to me of this is given at http://www.spec.org
In fact, if you wish, we can abandon the whole issue of Macs entirely and I'll still argue the same point. Let's concentrate only on gcc vs. the Intel compiler only on the x86 box used. GCC produces an executable that runs given code at speed X seconds on PlatformMoo when using the best set of optimizations it can. The Intel compiler produces an executable that runs the same code at speed (X * 0.70) seconds on PlatformMoo when using the best set of optimizations it can. Which compiler should I use on my computational codes if I want them to run as fast as possible? I could give a rat's ass about what is more beautiful, what licensing I have to have, or who is running the tests or who wrote the compilers. FACT: the Intel compiler generates faster code for the benchmark on the given system as clearly and undesputably shown on the http://www.spec.org web pages. Answer these: which is faster? the gcc executable or the Intel compiler executable? Which reflects more accurately how the system is capable of performing on the given problem?
Heck, let's use car engines as an analogy. Take a car, time it around a track. Put restrictor plates on the carborator. Time it around the track again. Which timing more accurately represents the performance the car is capable of achieving?
I'm guessing both CPUs should also run the same binaries for it to be truly a real test, that way they have the exact same optimizations and algorithms.
if I can complete my task using CompilerB in 2 days when CompilerA takes 4 days, which is my boss going to want me to use?
But you're not talking about COMPILERS, FUCKWIT. You are talking about a combination of COMPILER, OPERATING SYSTEM, AND RUNTIME ENVIRONMENT. You know NOTHING about the compilers you tested. Got it? NOTHING.
I'm not out for an academic exercise. I'm out to see how fast my code can run. Period. If I have to spend a few days to figure out and try a number of different compiler options to get fast code and if it takes a different OS and compiler to get it done for us, we don't have a problem with that. Time is money. We turn around accurate simulations faster for more clients, we succeed. Obviously, our best solution would be hand tuned assembly running on MSDOS, but we do need to have some portability to rapidly port to the next fastest thing and we'd prefer not to have a machine with MSDOS on it.
I just want you to ignore the Mac for a moment and state which executable was faster and which more accurrately reflects the performance characteristics of the system - gcc or Intel - on the SPEC benchmarks. Remember... ignore Mac (although I know that it will be damn near impossible for a Mac zealot to do).
Well... maybe this... what if CompanyX made a compiler tomorrow that only ran on the new G5 and was very good (generating numbers even better than the Intel compiler on the x86 box). Would you still use GCC only to compile everything that will ever run on the G5? What a joke.
Why not put your opinion where your reputation is and come out from behind the AC flag? I think it actually must accurately represent your achievable performance. I'm willing to put my karma on the line. What are you afraid of?
(Personally, I would like to see the G5 be faster than the PC and I
Yeah... generic optimizations across the board may or may not be optimal on a certain target platform. Optimization is something that is very architecturally specific, if you want to squeeze out every last clock cycle. That is why that, even today, the most intensive computation kernels are still hand coded assembly. Sometimes it *is* important to do something in 1 less clock cycle.
That's why using the best compiler on the platform is beneficial. It's the difference between saying that the apps generically suck or they run as best they can, given the current compiler technology. Get new compilers that optimize better and recompile.
As I stated in another thread, on one project I participated in, the choice of compiler made a difference of 100% performance difference. On our simulations, that meant using the right compiler shaved *days* off the runtime. Days = several people's salaries and rapid turnaround time for the simulations. Telling my boss that because using GCC in our case was the right thing to do because it was the same across all platforms although it took 2X as long (and therefore cost 2X as much to do each job), would have been foolish for our careers.
Oh... forgot about the IEEE 754-1985 standard... (been the standard since 1985)
http://research.microsoft.com/~hollasch/cgindex/ co ding/ieeefloat.html
Last updated on Jan 02, 2003.
In case you can't cut-n-paste, here's an excerpt:
The following figure shows the layout for single (32-bit) and double (64-bit) precision floating-point values. The number of bits for each field are shown (bit ranges are in square brackets):
Double Precision The IEEE double precision floating point standard representation requires a 64 bit word, which may be represented as numbered from 0 to 63, left to right. The first bit is the sign bit, S, the next eleven bits are the exponent bits, 'E', and the final 52 bits are the fraction 'F':
[...]
Reference: ANSI/IEEE Standard 754-1985, Standard for Binary Floating Point Arithmetic
Last time I checked, IEEE Double precision floating point was 64 bits. 80 bits is extended mode and non-standard.
Check again. You're about 12 years out of date.
Verion X of the compiler produces great code on architecture X but ultra-crappy code on architecture Y. That is a fair comparison? I don't think so.
Of course it's a fair comparison! It's a comparison with exactly ONE variable. It tells you that code compiled with compiler X runs well on X but poorly on Y. It tells you something FACTUAL, not something INFERENTIAL.
Of course, you may not like the results. Fine. Then get off your ass and improve compiler X. Or pick another compiler THAT EXISTS FOR BOTH PLATFORMS and run the test with it instead. Don't go throwing in random variables to muddy the results.
Heh... my app using Intel's compilers will run 2X as fast as yours compiled with gcc, that's all that matters. That's why you compile with better compilers and throw crappy compilers into/dev/null.
If you are looking for SPEC numbers, which are the theoretical peak performances for the hardware
Ah. I see the problem here.
NO THEY ARE NOT.
If SPEC numbers were theoretical peaks, then we would test microprocessors on multimillion dollar test harnesses instead of in actual systems. SPEC numbers are not meant to be "theoretical peak" anything. They are meant to be a BENCHMARK (perhaps you've heard that term before) for relative comparison of two or more SYSTEMS. Complete systems. Not theoretical components.
Here's what you do. You run the test on one system. You change ONE VARIABLE and run the test again. Did the result go up or down or stay the same? See? You learned something there.
If you go changing EVERYTHING, then you have learned nothing.
You don't even understand what we're talking about.
OK, I'll agree with you on the theoretical part. I misworded that one. SPEC consists of kernels of "real world" problems to give an idea of how things may perform on your system. As with anything, you have to take it with a grain of some salt. It gives you an idea of what your system will do on similar tasks. I chose the wrong word so I'll concede that argument to you and restate.
They indeed do test complete systems. Choice of compiler is a part of that complete system just as choice of operating system and speed of microprocessor are. That is why they are still valid even if using a different brand/version of compiler. You can have everything the same about two systems except the compiler and it will still be two different systems and one is allowed to be better performant than the other and still be a valid test. You would chose the slow system over the faster system simply because all the comparisons used gcc. Meanwhile, I would use the faster system and turn out more work over time and my boss would be happier.
That is the precise reason why you must clearly document exactly what compiler, version, and compile options you use so that they can be reproduced.
Right. But you can't reproduce SPEC on a G5 with the Intel compiler. There is no Intel compiler for the G5. So poof. SPEC with the Intel compiler is not a valid way of comparing a G5 to an Intel system. It's only a valid way of comparing two Intel systems.
Um, no... it's so you can exactly duplicate the hardware and software used to run the benchmark at another site to verify that the results are reproducable.
So, you are saying that SPEC (as well as www.top500.org and others) are all invalid because they don't use gcc.
Yes. That's precisely what I'm saying. If you mean to do a SCIENTIFIC, PRECISE comparison of two systems, you have to do it diligently. Otherwise the results are not useful. We're talking about differences in SPEC scores of 10% here; that's so close as to be virtually meaningless as it is, even under the most rigorous conditions. If you change architectures, chips,
Intel standard practices are that the compiler uses the SSE2 register set for FPU operations if present, even for scalar FPU operations.
You can't use SSE2 registers for double-precision floating point arithmetic. An 80-bit double won't fit in a 64-bit SSE2 register. So enabling SSE2 (1) would not have helped in a double precision benchmark and (2) would have given a misleading result in a single-precision benchmark.
Last time I checked, IEEE Double precision floating point was 64 bits. 80 bits is extended mode and non-standard.
Are you benchmarking the compiler or the hardware? If you are benchmarking the compiler, then use the gcc on both. If you are benchmarking the hardware, use the best available compiler for each machine.
You got that perfectly backwards. If you're trying to test the hardware, you must isolate all other variables. Using different compilers on different machines (when identical compilers are available) yields results that are perfectly meaningless.
Gotta call BS on this. Verion X of the compiler produces great code on architecture X but ultra-crappy code on architecture Y. That is a fair comparison? I don't think so. If you are looking for SPEC numbers, which are the theoretical peak performances for the hardware, you use the best compilers and compile options you can. That is the precise reason why you must clearly document exactly what compiler, version, and compile options you use so that they can be reproduced. In addition, most of the hardware that posts SPEC numbers do not even share the same compiler vendor, much less version, and they are still ranked. So, you are saying that SPEC (as well as www.top500.org and others) are all invalid because they don't use gcc.
I would rather see what the hardware is capable of, not what gcc is capable of.
And I would rather see what the hardware is capable of, not what Intel's compiler is capable of.
Ummm.... the compiler produces code for the CPU to run. Crappy code runs bad. Good code runs good. Good compilers produce good code. Crappy compilers produce crappy code. Again, I could write a version of a benchmark that specifically targets certain architectures and slows down by a factor of 10X. Since it is the same version of my benchmark, by your logic, it is a valid test of the two architectures.
Hell, if you want to do an end-to-end system test, the right way is to build the benchmark with Microsoft Visual Studio on the Dell and Project Builder on the Mac. These are the build environments that people actually use. But since they weren't using Windows on the Dell, they were using Linux, they went with the Linux compiler instead: GCC.
Call up Microsoft and ask 'em what compiler they use to compile Office. I guarantee you it's not Intel's.
Seems to be missing a point.
Not only was the malloc code simply a non-cache coherent malloc library, it was one optimized for certain types of memory allocations, probably ones that work well with the SPEC benchmarks.
And you know this... why? Oh, right, because you have no problem just making shit up to try to bolster your argument.
Ummm... because I read the post. Apple documented the fact as per this excerpt:
"Installed a high performance, single threaded malloc library. This library implementation is geared for speed rather than memory efficiency and is single-threaded which makes it unsuitable for many uses. Special provisions are made for very small allocations (less than 4 bytes)." (Page 5, also see Appendix E, Page 26, Veritest PDF)
This tells me two things... one, it's single-threaded. Two, it was optimized for speed rather than efficiency. Hence my previous statements.
IF you know anything about malloc libraries, you'd know that malloc libraries are expensive bits of code. Not only is there typically a lot of code there but they have nasty cache properties so that
I can't remember for sure, but at one time, I believe you could use certain environment variables or somesuch with certain compilers to force an application to avoid certain code paths, even if they were usable. For example, you could force it to use software IEEE floating point libraries instead of the math coprocessor. It wouldn't be a stretch to figure they could force the app to not use SSE2 in this way.
Slashdot Mirror
heh... using Apple's special SPEC executables maybe. I look at http://www.spec.org for my SPEC results, not something tailored by Apple.
.... except that most companies run the SPEC benchmarks and publish the results before you can actually buy a computer with the CPU in it. Check out the history of just about any of the computers listed in the SPEC registry. In fact, the [est] Madison SPEC are already there and I haven't seen where I could buy one of those yet.
Yeah... sounds a lot like the Reagan years and using defense spending to bankrupt other governments.
Yeah, imagine that... instead of admin forcing folks to use what *they* thought the users should use. To think that any single OS fits all is simple religion.
Wasn't there also supposedly some impurity in the steel of the hull that, in low temperatures, made the hull brittle?
Can't be killed, true. It's like letting the cat (code) out of the bag. Once it's out, it's out. However, litigation and the like can scare the money away from Linux in a big way, which would relegate Linux back to its tinkering/hacking existance from long ago. You wouldn't see any more of the YYY School switches to Linux... AnyTown, USA switches to Linux... or CompanyB switches to Linux posts anymore, at least for a long time.
Think logically, not emotionally.
...and some admin are pretty decent. Our 10 or so guys admin about 7,000 Windows machines and around 4,000 Un*x or Un*x-alikes.
Pronounced "Fizz-tee," the software is so powerful, it individually simulated each of the 3 million hairs that cover one of the lead monsters, and into the bargain, it reduced the process from weeks to hours.
, 00 .html
http://www.wired.com/news/digiwood/0,1412,48052
I believe Toy Story had the list of the names of all the computers in the render farm in the credits near the end.
Like this is a new thing?
When I was in college, Motorola donated tons of stuff to different schools. For instance, we had lots of the 68HC000 trainer boards and plenty of parts to make 68K machines with.
For a project, my partner and I even wrote to Motorola including a parts list and a discussion of the proposal of our project and they shipped us a bunch of free parts to use. At the time, some of the parts we got were near top of the line. For example, the 33/40 MHz 68040s were the top of the line and we requested and received a 25MHz part.
Why did they do these things? Well, just as you said. Get folks to learn using your stuff and they will most likely stick with it or recommend it later. It's an investment for the company.
Is it a bad thing? I don't think so.
That's what I said, but it costs more than $0 last time I visited RH's website.
Maybe we got em all =P
Still, they are out there if you look for them.
Interesting, could we see your proposal with line item figures? or did you just make this number up like most folks do?
Jebus Crisis. Just make the ashtray out of metal, then it won't break at all.
But it could clang around a lot....
As opposed to employing Windows administrators? As people have pointed out time and time again, the greater number of systems that a Linux admin can administer is much more than the 30% or so extra that that admin makes.
Yeah, crappy admin. Our team of 10 admin service around 11,000 computers, of which, around 2/3 are Windows boxes. Maybe you should hire admin who know what they are doing.
I know this is mod as funny but, this scenario would be highly doubtful as they would most likely have wanted some level of support to go along with the software.
Something that folks frequently forget is that not everyone knows how to install and support software on Linux much less install and support Linux on hardware. You cannot expect non-technical folks to do it all themselves.
EverQuest had the same rules at one time and it was enforced sometimes. A year or so ago they said they didn't care anymore and relaxed the restrictions a lot.
I haven't been paying attention to it that much but SOE just released the Mac version of EverQuest so I wouldn't be surprised if there isn't a Mac version of SWG somewhere in the pipe.
WHAT IS YOUR FUCKING PROBLEM? WHY ARE YOU THREATENED BY THE FACT THAT A MAC IS FASTER THAN THE FASTEST PC?
I'm not at all. Why are you so threatened that people say that the Mac isn't? I could care less if we were talking about two completely different processors as long as the tests were fair, which they weren't, in a bunch of folk's opinion. Is it that finally Apple presents something to you and you are so desperate to believe it that you will do anything to cling to it?
If it is that important to you, I'll even say that the Mac is faster given that test. I think the test was a waste of time and showed nothing and proof that is conclusive to me of this is given at http://www.spec.org
In fact, if you wish, we can abandon the whole issue of Macs entirely and I'll still argue the same point. Let's concentrate only on gcc vs. the Intel compiler only on the x86 box used. GCC produces an executable that runs given code at speed X seconds on PlatformMoo when using the best set of optimizations it can. The Intel compiler produces an executable that runs the same code at speed (X * 0.70) seconds on PlatformMoo when using the best set of optimizations it can. Which compiler should I use on my computational codes if I want them to run as fast as possible? I could give a rat's ass about what is more beautiful, what licensing I have to have, or who is running the tests or who wrote the compilers. FACT: the Intel compiler generates faster code for the benchmark on the given system as clearly and undesputably shown on the http://www.spec.org web pages. Answer these: which is faster? the gcc executable or the Intel compiler executable? Which reflects more accurately how the system is capable of performing on the given problem?
Heck, let's use car engines as an analogy. Take a car, time it around a track. Put restrictor plates on the carborator. Time it around the track again. Which timing more accurately represents the performance the car is capable of achieving?
I'm guessing both CPUs should also run the same binaries for it to be truly a real test, that way they have the exact same optimizations and algorithms.
if I can complete my task using CompilerB in 2 days when CompilerA takes 4 days, which is my boss going to want me to use?
But you're not talking about COMPILERS, FUCKWIT. You are talking about a combination of COMPILER, OPERATING SYSTEM, AND RUNTIME ENVIRONMENT. You know NOTHING about the compilers you tested. Got it? NOTHING.
I'm not out for an academic exercise. I'm out to see how fast my code can run. Period. If I have to spend a few days to figure out and try a number of different compiler options to get fast code and if it takes a different OS and compiler to get it done for us, we don't have a problem with that. Time is money. We turn around accurate simulations faster for more clients, we succeed. Obviously, our best solution would be hand tuned assembly running on MSDOS, but we do need to have some portability to rapidly port to the next fastest thing and we'd prefer not to have a machine with MSDOS on it.
I just want you to ignore the Mac for a moment and state which executable was faster and which more accurrately reflects the performance characteristics of the system - gcc or Intel - on the SPEC benchmarks. Remember... ignore Mac (although I know that it will be damn near impossible for a Mac zealot to do).
Well... maybe this... what if CompanyX made a compiler tomorrow that only ran on the new G5 and was very good (generating numbers even better than the Intel compiler on the x86 box). Would you still use GCC only to compile everything that will ever run on the G5? What a joke.
Why not put your opinion where your reputation is and come out from behind the AC flag? I think it actually must accurately represent your achievable performance. I'm willing to put my karma on the line. What are you afraid of?
(Personally, I would like to see the G5 be faster than the PC and I
Yeah... generic optimizations across the board may or may not be optimal on a certain target platform. Optimization is something that is very architecturally specific, if you want to squeeze out every last clock cycle. That is why that, even today, the most intensive computation kernels are still hand coded assembly. Sometimes it *is* important to do something in 1 less clock cycle.
That's why using the best compiler on the platform is beneficial. It's the difference between saying that the apps generically suck or they run as best they can, given the current compiler technology. Get new compilers that optimize better and recompile.
As I stated in another thread, on one project I participated in, the choice of compiler made a difference of 100% performance difference. On our simulations, that meant using the right compiler shaved *days* off the runtime. Days = several people's salaries and rapid turnaround time for the simulations. Telling my boss that because using GCC in our case was the right thing to do because it was the same across all platforms although it took 2X as long (and therefore cost 2X as much to do each job), would have been foolish for our careers.
Oh... forgot about the IEEE 754-1985 standard... (been the standard since 1985)
/ co ding/ieeefloat.html
e e/ ieee.html
http://research.microsoft.com/~hollasch/cgindex
Last updated on Jan 02, 2003.
In case you can't cut-n-paste, here's an excerpt:
The following figure shows the layout for single (32-bit) and double (64-bit) precision floating-point values. The number of bits for each field are shown (bit ranges are in square brackets):
If you prefer a non-Microsoft site:
http://www.psc.edu/general/software/packages/ie
from which:
Double Precision
The IEEE double precision floating point standard representation requires a 64 bit word, which may be represented as numbered from 0 to 63, left to right. The first bit is the sign bit, S, the next eleven bits are the exponent bits, 'E', and the final 52 bits are the fraction 'F':
[...]
Reference:
ANSI/IEEE Standard 754-1985,
Standard for Binary Floating Point Arithmetic
I'm done. May you continue to live in academia.
Last time I checked, IEEE Double precision floating point was 64 bits. 80 bits is extended mode and non-standard.
/dev/null.
Check again. You're about 12 years out of date.
Verion X of the compiler produces great code on architecture X but ultra-crappy code on architecture Y. That is a fair comparison? I don't think so.
Of course it's a fair comparison! It's a comparison with exactly ONE variable. It tells you that code compiled with compiler X runs well on X but poorly on Y. It tells you something FACTUAL, not something INFERENTIAL.
Of course, you may not like the results. Fine. Then get off your ass and improve compiler X. Or pick another compiler THAT EXISTS FOR BOTH PLATFORMS and run the test with it instead. Don't go throwing in random variables to muddy the results.
Heh... my app using Intel's compilers will run 2X as fast as yours compiled with gcc, that's all that matters. That's why you compile with better compilers and throw crappy compilers into
If you are looking for SPEC numbers, which are the theoretical peak performances for the hardware
Ah. I see the problem here.
NO THEY ARE NOT.
If SPEC numbers were theoretical peaks, then we would test microprocessors on multimillion dollar test harnesses instead of in actual systems. SPEC numbers are not meant to be "theoretical peak" anything. They are meant to be a BENCHMARK (perhaps you've heard that term before) for relative comparison of two or more SYSTEMS. Complete systems. Not theoretical components.
Here's what you do. You run the test on one system. You change ONE VARIABLE and run the test again. Did the result go up or down or stay the same? See? You learned something there.
If you go changing EVERYTHING, then you have learned nothing.
You don't even understand what we're talking about.
OK, I'll agree with you on the theoretical part. I misworded that one. SPEC consists of kernels of "real world" problems to give an idea of how things may perform on your system. As with anything, you have to take it with a grain of some salt. It gives you an idea of what your system will do on similar tasks. I chose the wrong word so I'll concede that argument to you and restate.
They indeed do test complete systems. Choice of compiler is a part of that complete system just as choice of operating system and speed of microprocessor are. That is why they are still valid even if using a different brand/version of compiler. You can have everything the same about two systems except the compiler and it will still be two different systems and one is allowed to be better performant than the other and still be a valid test. You would chose the slow system over the faster system simply because all the comparisons used gcc. Meanwhile, I would use the faster system and turn out more work over time and my boss would be happier.
That is the precise reason why you must clearly document exactly what compiler, version, and compile options you use so that they can be reproduced.
Right. But you can't reproduce SPEC on a G5 with the Intel compiler. There is no Intel compiler for the G5. So poof. SPEC with the Intel compiler is not a valid way of comparing a G5 to an Intel system. It's only a valid way of comparing two Intel systems.
Um, no... it's so you can exactly duplicate the hardware and software used to run the benchmark at another site to verify that the results are reproducable.
So, you are saying that SPEC (as well as www.top500.org and others) are all invalid because they don't use gcc.
Yes. That's precisely what I'm saying. If you mean to do a SCIENTIFIC, PRECISE comparison of two systems, you have to do it diligently. Otherwise the results are not useful. We're talking about differences in SPEC scores of 10% here; that's so close as to be virtually meaningless as it is, even under the most rigorous conditions. If you change architectures, chips,
Maybe read this article too, while you are at it. Pay particular note to the SPEC performance charts on page 2.
d =1 296
http://www.amdzone.com/articleview.cfm?articlei
Intel standard practices are that the compiler uses the SSE2 register set for FPU operations if present, even for scalar FPU operations.
You can't use SSE2 registers for double-precision floating point arithmetic. An 80-bit double won't fit in a 64-bit SSE2 register. So enabling SSE2 (1) would not have helped in a double precision benchmark and (2) would have given a misleading result in a single-precision benchmark.
Last time I checked, IEEE Double precision floating point was 64 bits. 80 bits is extended mode and non-standard.
Are you benchmarking the compiler or the hardware? If you are benchmarking the compiler, then use the gcc on both. If you are benchmarking the hardware, use the best available compiler for each machine.
You got that perfectly backwards. If you're trying to test the hardware, you must isolate all other variables. Using different compilers on different machines (when identical compilers are available) yields results that are perfectly meaningless.
Gotta call BS on this. Verion X of the compiler produces great code on architecture X but ultra-crappy code on architecture Y. That is a fair comparison? I don't think so. If you are looking for SPEC numbers, which are the theoretical peak performances for the hardware, you use the best compilers and compile options you can. That is the precise reason why you must clearly document exactly what compiler, version, and compile options you use so that they can be reproduced. In addition, most of the hardware that posts SPEC numbers do not even share the same compiler vendor, much less version, and they are still ranked. So, you are saying that SPEC (as well as www.top500.org and others) are all invalid because they don't use gcc.
I would rather see what the hardware is capable of, not what gcc is capable of.
And I would rather see what the hardware is capable of, not what Intel's compiler is capable of.
Ummm.... the compiler produces code for the CPU to run. Crappy code runs bad. Good code runs good. Good compilers produce good code. Crappy compilers produce crappy code. Again, I could write a version of a benchmark that specifically targets certain architectures and slows down by a factor of 10X. Since it is the same version of my benchmark, by your logic, it is a valid test of the two architectures.
Hell, if you want to do an end-to-end system test, the right way is to build the benchmark with Microsoft Visual Studio on the Dell and Project Builder on the Mac. These are the build environments that people actually use. But since they weren't using Windows on the Dell, they were using Linux, they went with the Linux compiler instead: GCC.
Call up Microsoft and ask 'em what compiler they use to compile Office. I guarantee you it's not Intel's.
Seems to be missing a point.
Not only was the malloc code simply a non-cache coherent malloc library, it was one optimized for certain types of memory allocations, probably ones that work well with the SPEC benchmarks.
And you know this... why? Oh, right, because you have no problem just making shit up to try to bolster your argument.
Ummm... because I read the post. Apple documented the fact as per this excerpt:
"Installed a high performance, single threaded malloc library. This library implementation is geared for speed rather than memory efficiency and is single-threaded which makes it unsuitable for many uses. Special provisions are made for very small allocations (less than 4 bytes)."
(Page 5, also see Appendix E, Page 26, Veritest PDF)
This tells me two things... one, it's single-threaded. Two, it was optimized for speed rather than efficiency. Hence my previous statements.
IF you know anything about malloc libraries, you'd know that malloc libraries are expensive bits of code. Not only is there typically a lot of code there but they have nasty cache properties so that
I can't remember for sure, but at one time, I believe you could use certain environment variables or somesuch with certain compilers to force an application to avoid certain code paths, even if they were usable. For example, you could force it to use software IEEE floating point libraries instead of the math coprocessor. It wouldn't be a stretch to figure they could force the app to not use SSE2 in this way.