Stop Microsoft
Miscellaneous => The Lounge => Topic started by: solemnwarning on 18 April 2006, 19:49
-
I have written a simple benchmark program in C that will work out how many floating point calculations a UNIX system can do in 10 seconds and attached the source to this post, as the results of several machines Here (http://www.hope2work.net/wordpress/?p=99) show, AMD Athlon CPUs pwn and intel sucks, ffs my 2.2GHz Athlon XP did nearly 6x the work of a 3.2GHz P4, and my 1.8GHz Athlon XP does over 4x the work, why do people even buy intel processors when they suck this much?
EDIT: Can admin enable .c, .h, .cpp and .hpp file extentions for upload?
[verwijderd door de beheerder]
-
I get 21,431,390 with my Athlon XP 2600+, but I'm compiling mozilla now so that's not really accurate...
You'd need to make sure all the machines are running basically the same stuff (or the benchmark process mightn't get the same scheduling time). T'wouldn't be a bad idea to make the benchmark log the result in a text file and pass "init=/path/to/benchmark" to the kernel after rebooting. Then the process will run with only the kernel running, and when it's finished you'll have to reset the computer (might even get a kernel panic). Then you can read the result from where you logged it.
They're still not running the same kernel... But it's basically the same.
This benchmark doesn't show that much though.. I somehow doubt Intel chips are this bad overall.........
-
Floating point performance has never been Intel's strength...but these numbers don't seem to make sense as you have them.
Here's my results, anyway...
PowerPC G4 1.5GHz, Mac OS X 10.4.5
32572406
33345288
33165002 (three tries)
I'll get my Pentium 4 done in a little bit.
-
Ok, Pentium 4 2.8GHz, Linux 2.4.29:
16519493
16516455
16002699
Perhaps you should try a benchmark that does integer math, too.
-
Benchmarks are usually done with games like UT2004 or the like ... floating point will give you different results. I don't really believe them myself, I've seen lots of benchmarks with games like UT2004 and the results do favor AMD, but not like this ... it's a more subtle difference.
Examples: (note that most of these were done on Window$ due to the fact that most games don't run on Linux ... and wine kinda blows)
http://www.zdnet.co.uk/reviews/hardware/processorsmemory/0,39024015,39164010,00.htm (http://www.zdnet.co.uk/reviews/hardware/processorsmemory/0,39024015,39164010,00.htm)
http://www.extremetech.com/article2/0,1697,1854918,00.asp (http://www.extremetech.com/article2/0,1697,1854918,00.asp)
And with dual-core AMD is definitely superior:
http://reviews.cnet.com/4520-10442_7-6389077-9.html?tag=btn (http://reviews.cnet.com/4520-10442_7-6389077-9.html?tag=btn)
for more just google "AMD Intel benchmark"
Yeah AMD is better in performance ... so I'm thinking of buying one for my next computer ... building will commence in about 1-2 months ... but there is only one thing holding me back from buying AMD as opposed to Intel ... heat management.
I'd like a guarrantee that my processor (I'll buy the best and probably most expensive one available) won't burn if the cooling system fails. (I'm thinking of putting in liquid cooling just cuz fans get clogged with dust so quickly, and it's a pain to clean it ... my GPU fan got clogged and I got random crashes while playing games) From what evidence I've seen Intel does far better in preventing CPU meltdown/burning ... any evidence to the contrary ? I need hard evidence, like articles and benchmarks, not just you telling me AMD has no heat problems whatsoever.
P.S. All articles I've seen on this issue have favored Intel ... and include very nice pictures of burned AMD CPUs and the motherboard damage that incurrs ... no burned Intel CPU pictures at all.
-
Oh... k.. that init thing does not want to work for me (time appears to be going slower with it...).
Isn't PCMark the thing for benchmarking CPUs?
-
Best of all write it for DOS and then it'll be more acurate as it's only doing one task - your benchmark program.
-
Benchmarks are usually done with games like UT2004 or the like ... floating point will give you different results. I don't really believe them myself, I've seen lots of benchmarks with games like UT2004 and the results do favor AMD, but not like this ... it's a more subtle difference.
Examples: (note that most of these were done on Window$ due to the fact that most games don't run on Linux ... and wine kinda blows)
http://www.zdnet.co.uk/reviews/hardware/processorsmemory/0,39024015,39164010,00.htm (http://www.zdnet.co.uk/reviews/hardware/processorsmemory/0,39024015,39164010,00.htm)
http://www.extremetech.com/article2/0,1697,1854918,00.asp (http://www.extremetech.com/article2/0,1697,1854918,00.asp)
And with dual-core AMD is definitely superior:
http://reviews.cnet.com/4520-10442_7-6389077-9.html?tag=btn (http://reviews.cnet.com/4520-10442_7-6389077-9.html?tag=btn)
for more just google "AMD Intel benchmark"
Yeah AMD is better in performance ... so I'm thinking of buying one for my next computer ... building will commence in about 1-2 months ... but there is only one thing holding me back from buying AMD as opposed to Intel ... heat management.
I'd like a guarrantee that my processor (I'll buy the best and probably most expensive one available) won't burn if the cooling system fails. (I'm thinking of putting in liquid cooling just cuz fans get clogged with dust so quickly, and it's a pain to clean it ... my GPU fan got clogged and I got random crashes while playing games) From what evidence I've seen Intel does far better in preventing CPU meltdown/burning ... any evidence to the contrary ? I need hard evidence, like articles and benchmarks, not just you telling me AMD has no heat problems whatsoever.
P.S. All articles I've seen on this issue have favored Intel ... and include very nice pictures of burned AMD CPUs and the motherboard damage that incurrs ... no burned Intel CPU pictures at all.
Those were the Athlon/Athlon XP, the Athlon 64s dont burn up, tomshardware has a video of the Athlon 64 vs. P4. AMDs also have a lower thermal shutdown threshold, typicaly around 60*C instead of the 90+*C of intels wich would less likely damage the mobo, A64s are also easier to cool. an A64 3000+ Puts out 50 watts of heat at the most, an FX-60 tops at around 90-100 watts, why the P4s go muvh over 100 watts.
-
The pics of burned CPU's are after the thermal shutdown has been disabled. My Athlon 64 3400 over heated and turned off and no problems. Look at it this way: a game that recomends a P4 2.2 gig, or an Athlon XP 2200 is saying the recomended is a 2.2 gig Intel or a 1.8 AMD. I buy for performance, not cooling ability. As long as there is a large heatsink on it it will be fine.
-
The Intel Core Duo's look nice (http://hardware.slashdot.org/hardware/06/04/18/1210230.shtml).
-
To be blunt, I do not trust your benchmark results. You get athlon results two to four times faster than the equivalent Intel chips. You then say "This shows one thing: Athlon CPUs pwn and Intel CPUs are pieces of shit, My 2.2GHz athlon did almost 6x the work of a 3.2GHz intel ffs!"
If you get discrepancies this wide, you really should be looking at your test. Nobody survives in the semiconductor world by selling products that are two to four times slower than the competition at the same prices. Yet you claim they do, despite the fact that no benchmarking professionals have backed this up. Is anyone supposed to take this seriously?
How am I supposed to take this seriously when I can get 13,553,853 fps with this test out of my 460 MHz Celeron with a wussy 128 kb cache With KDE and Mozilla running, XMMS loaded, and a bunch of other dinky stuff running in the background, and you get only 15,108,371 with a modern 2.4 GHZ Intel Celeron? Are you seriously going to tell me that my 460 MHz is almost as fast as that 2.4 GHZ box?
You also publish NO details about the benchmarks. What optimization levels did you use? What compiler? If you used GCC, did you optimize for cpu architecture with the -march= switch? Did you run it on systems that had kernels optimized for their chips? Did you take the SAME binary and run it across platforms? If not, did you use the same compiler and the same version and the same libraries? And don't forget about cache! For heavy FP calculations, a large cache is very important, but you left all that information out.
Finally, Linux is not UNIX. UNIX is a family of operating systems which conform to strict written specs created by the Open Group and then are submitted to the Open Group for a rigourous and expensive testing and certification. Neither Linux nor FreeBSD do that. They are "unix-like systems" or "*nix" systems, but NOT UNIX. Those scumbags at SCO are continually trying to convince everyone that Linux is an illegal UNIX. Don't help them out.
-
I also ran the benchmark with xchat, konqueror and xmms running, its compiled with gcc and no optimization flags, my kernel is compiled for K7, but everything else on my machine is for i386
-
Can admin enable .c, .h, .cpp and .hpp file extentions for upload?
Done. The MIME types are set too.
-
If you want to do a "benchmark," give the computer a real-world floating point problem, with real code. Then see how long it takes to solve it. For example, invert a 2500x2500 floating point matrix filled with random numbers. Do a numerical solution of a differential equation. Do a Fourier transform of an enormously long float array (just make sure that your array dimensions are powers of two, if you want to use the traditional Fast Fourier Algorithm, in case you didn't know that).
Don't have the skill or time to code that? Just install or compile GNU Octave. Optimize it for your architecture if you want, just make sure you optimize it for all of the test archtectures then.
Here's a one line octave command that will invert a 2500x2500 random matrix using code that's fairly serious and built by pros.
octave:1> x=rand(2500);st=cputime();inv(x);et=cputime();et-st
ans = 167.15
On my old celeron 460 with 128 kb of Cache, running Fedora Core 4, stock kernel, stock FC4 RPM of Octave, it took 167 CPU seconds to run.
A big benchmark script for Octave can be found at http://article.gmane.org/gmane.comp.gnu.octave.sources/56
which lets you see what architecture works best for what kind of calculation.
Demonstrate that an architecture can solve a real world problem significantly faster and then you actually have something to talk about.
-
Athlon 64 X2 4400+
%./a.out
In 10 seconds this system has done 48620731 floating-point calculations
%./a.out
In 10 seconds this system has done 50146885 floating-point calculations
%./a.out
In 10 seconds this system has done 77663578 floating-point calculations
%./a.out
In 10 seconds this system has done 56487406 floating-point calculations
%./a.out
In 10 seconds this system has done 75651591 floating-point calculations
%
This was while compiling in the background. WTF is up with the hugely varied results?
I finished up my compiling and ran it again, and got the exact same scores! I also noticed that only one of my cores was bieng used, so I ran it twice at the same time....
%./a.out & && ./a.out &
[1] 41530
[2] 41531
%In 10 seconds this system has done 78938919 floating-point calculations
In 10 seconds this system has done 74342611 floating-point calculations
[2] Done ./a.out
[1] + Done ./a.out
%./a.out & && ./a.out &
[1] 41532
[2] 41533
%In 10 seconds this system has done 54624201 floating-point calculations
In 10 seconds this system has done 51831769 floating-point calculations
[2] Done ./a.out
[1] + Done ./a.out
%
Again, the scored varied wildly, but at least this time I was able to get both cores working. If you add up the scores from the first one I got 153,281,530
Woohoo!
PS: It's a worthless benchmark
-
Rewrote it with help from AlexExtreme, my Athlon XP 3200+ 2.2GHz gets 986487165 floating point calculations done in 10 seconds and took 73 seconds to calculate pi to 20000 digits
[verwijderd door de beheerder]
-
Ok, here's a benchmark specifically targeted at floating point AMD vs. Intel:
http://www.queru.com/articles/Benchmarks.html (http://www.queru.com/articles/Benchmarks.html)
-
Pi...
(http:// http://www.nirvanaexpeditions.com/pictures/others/images/APPLE%20PIE%20(PM).jpg)
This is a step in the right direction. Ok, this is actually fun. Havn't checked the pi algorithm yet, but it looks like real math.
Celeron 460 MHz with 128 KB of cache takes 328 seconds to calculate Pi . Using level 2 optimization on GCC cuts this to 182 seconds.
My advice: just drop the looping (it really is meaningless), and add some more real life problems. I'd love to see the performance comparisons between people boxes, both with no optimization and -O2 flags.
-
My new Athlon64 3000+ machine at work. FreeBSD 6.1-RC1/i386
%./a.out
Starting floating-point benchmark...
This system has calculated 1052454527 floating-point calculations in 10 seconds
Starting pi benchmark...
This system took 80 seconds to calculate pi to 20000 digits
%
I'll do my Athlon64 X2 4400+ system when I get home. :)
-
Hmmm ... how do I compile it ? (I know it's a stupid question, but unless it's got a makefile, I have no clue)
-
Hmmm ... how do I compile it ? (I know it's a stupid question, but unless it's got a makefile, I have no clue)
I was stuck on that too, but made an edumacated guess and got it. All you have to do is type this at the command line (assuming the file is in your PWD)....
%cc ./benchmark.c
The the file will be compiled. The resulting binary should be called "a.out".
After that just execute "a.out" to run the benchmark.
-
Okay, here is my Dual Core 4400+
%./a.out
Starting floating-point benchmark...
This system has calculated 1296222130 floating-point calculations in 10 seconds
Starting pi benchmark...
This system took 65 seconds to calculate pi to 20000 digits
And here it is, two at the same time... (dual core rocks!)
%./a.out & && ./a.out &
[1] 967
[2] 968
Starting floating-point benchmark...
%Starting floating-point benchmark...
%This system has calculated 1251545160 floating-point calculations in 10 seconds
Starting pi benchmark...
This system has calculated 1212464935 floating-point calculations in 10 seconds
Starting pi benchmark...
This system took 66 seconds to calculate pi to 20000 digits
This system took 67 seconds to calculate pi to 20000 digits
[2] Done ./a.out
[1] + Done ./a.out
-
It has the compile command in a comment at the start of the file :\
-
Thanks for the instructions toadlife ... the "gcc -Wall cpuwars.c cpuwars.o" didn't seem to work ...
here are the results for my laptop's 2.8 Ghz P4 (no HT) ... kinda funny how the floating point is half that of toadlife's AMD, but the pi calculation time is pretty close (4-5 sec).
[Draconishinobi@knoppix Downloads]$ ./a.out
Starting floating-point benchmark...
This system has calculated 620565563 floating-point calculations in 10 seconds
Starting pi benchmark...
This system took 72 seconds to calculate pi to 20000 digits
[Draconishinobi@knoppix Downloads]$ ./a.out
Starting floating-point benchmark...
This system has calculated 639032963 floating-point calculations in 10 seconds
Starting pi benchmark...
This system took 71 seconds to calculate pi to 20000 digits
[Draconishinobi@knoppix Downloads]$ ./a.out
Starting floating-point benchmark...
This system has calculated 638959711 floating-point calculations in 10 seconds
Starting pi benchmark...
This system took 72 seconds to calculate pi to 20000 digits
[Draconishinobi@knoppix Downloads]$
-
Thanks for the instructions toadlife ... the "gcc -Wall cpuwars.c cpuwars.o" didn't seem to work ...
gcc -Wall -o cpuwars.o cpuwars.c
-
Pentium M 1.86 GHz 2MB Cache 533 MHz FSB
Cygwin under Windows XP
Pi calculation 42 seconds. 23 seconds with -O2 calculation...
Wierd... Looks like we need to look at the algorithm, make sure it actually does calculate Pi. Maybe timers don't work on Cygwin either....
UPDATE: Yes the algorithm is correct. Here's the original source code: spigot algorithm for the Digits of \pi, Stanley Rabinowitz and Stan Wagon, Amer.Math.Monthly, March 1995, 195-203 soft version at http://paul.rutgers.edu/~rhoads/Code/pi2.c
Here's an updated version without the looping stuff and restructured a little.
I suggest you compile it with
gcc -o cpuwars2 cpuwars2.c
and run it like this
date|cut -c 12-20;./cpuwars2;date|cut -c 12-20 so you can compare the system clock with the program report... of course the system clock will always be longer because of overhead, but if it's a factor of 2 then something is wrong with the timer functions.
And raise the number of iterations back up... I cut it down but I don't wanna re-upload.
[verwijderd door de beheerder]
-
... kinda funny how the floating point is half that of toadlife's AMD, but the pi calculation time is pretty close (4-5 sec).
Like I've been saying, the "floating point calculation" is bogus. If you optimize it with -O2 on the latest code, it will return 0. On Cygwin it returned an insanely large number, like ten times what the rest of you had.
You test a tool by using it for what it was made for. Calculate Pi. Invert a matrix. Fourier transform. Wavelet transform. Calculate prime numbers.
-
%date|cut -c 12-20;./new;date|cut -c 12-20
23:14:53
03141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117381932611793105118548074462379962749567351885752724891227938183011949129833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132000568127145263560827785771342757789609173637178721468440901224953430146549585371050792279689258923542019956112129021960864034418159813629774771309960518707211349999998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001927876611195909216420198
23:14:53
%
Huh? It that what it was supposed to do?
-
Umm no. Here's the output from my PC.
[mobrien@hariel temp]$ date|cut -c 12-20;./a.out;date|cut -c 12-20
00:34:23
Starting pi benchmark...
This system took 32 seconds to calculate pi to 6000 digits
00:34:55
[mobrien@hariel temp]$
If you compiled the original code, you would get the whole output. The idea that solemnwarning came up with (a good one) was to remove the screen output because that slows everything down, while keeping all the number crunching. My version just has the original code commented out instead of erased, so one can uncomment it and see that Pi is actually being calculated.
-
oh, duhhh. I compiled the original code.
Here is it...
Athlon64 X2 4400 (2.2Ghz)
%date|cut -c 12-20;./cpuwars2;date|cut -c 12-20
01:33:56
Starting pi benchmark...
This system took 13 seconds to calculate pi to 6000 digits
01:34:09
%
And two at a time...
%./cpuwars2&;./cpuwars2&
[1] 926
[2] 927
%Starting pi benchmark...
Starting pi benchmark...
This system took 14 seconds to calculate pi to 6000 digits
This system took 14 seconds to calculate pi to 6000 digits
[2] Exit 59 ./cpuwars2
[1] + Exit 59 ./cpuwars2
-
[Draconishinobi@livecd Downloads]$ gcc -Wall -o cpuwars.o cpuwars.c cpuwars.c: In function
-
the main() structure has a variable called totaldigits
it's set to 6000 because I wanted to play around with the code and wanted it to execute fast.
20000 would be a better test. Time taken seems to be non linear with digits.
TeXMeX, the cc and gcc do the same thing on a linux system.
The -Wall just show warnings. You really don't need it because it's a simple program. If anyone knows how to get rid of the warning, please tellme.
-O2 will optimize to level 2 and speed the code execution up.
-march= will optimize the code specifically for your processor. For example
gcc -march=i686 -O2 -o cpuwars2 cpuwars2.c
should theoretically produce the fastest running binary for an i686 architecture.
Comparisons for optimization levels should probably be done and different totaldigits...
Remember, your cpu cache is very important for floating point calculations. A fast CPU with a small cache can be outperformed by a slower cpu with a large cache. If you know what it is, post it.
-
Yup, :D
[Draconishinobi@livecd Downloads]$ gcc -O2 -Wall -o cpuwars2.o cpuwars2.c cpuwars2.c: In function
-
Very cool
And interestingly enough, your system clock and the cpu time agree completely. It actually did take 37 seconds to grind thorugh 20000 digits of Pi.
-
Hmmm ... could it be that some systems calculate smaller numbers of digits of pi faster than others, but then slow down as the numbers of digits increases ? So then how many digits of pi would be a useful benchmark for all systems ? Or would a graph of times at all numbers of digits be more useful ?
-
Hmmm ... could it be that some systems calculate smaller numbers of digits of pi faster than others, but then slow down as the numbers of digits increases ? So then how many digits of pi would be a useful benchmark for all systems ? Or would a graph of times at all numbers of digits be more useful ?
Very very interesting idea. I think it is worth looking into, because the Intel chip processed the 6000 digits much faster than the athlon, but the 20000 calculations were comparable.
Like I said before, nobody survives in the semiconductor world by selling a chip that in general is twice slower than the competition for the same money, but I would expect one chip to excel in certain limited situations (and similarly the other one to excel in other limited situations).
It would be trivial to modify the program to compute multiple lengths of Pi and report them all at once, given the way that I structured the Pi benchmark into a subroutine that takes numdigits as an argument and returns seconds.
I could do it later this week if one of you doesn't have time.
Some different types of calcuilations would really be cool... I'd love to see matrix inversion results. If we used Octave like I suggested, Toadlife's PC would probably kick the crap out of all the rest of ours because Octave is multithreaded and would use both his cores to solve the problem.
-
Well ... I don't think I know enough about benchmarking to actually write anything useful ... sorry