Printable View
SourceQuote:
According to the internal document from the manufacturers (Intel Extreme 2 X6800 vs Core AMD Athlon 64 FX 62 & Intel Pentium XE 965) Pentium XE 965 could perform 5-10% (2-3% for Athlon 64 FX 62) explains in 64-bit, Core 2 center was found no obvious boost.
:stick:
Wonder how long Intel can/is going to ditch 64bit, sooner or later they will have to jump on the bandwagon.
I thought that moment would come with Vista, but now I'm not so sure. Anybody got a link explaining which 32-bit apps will work/have problems with Vista, and why?
CONROE is 64bit cappable right?
Yup... Has Intel's EM64T.Quote:
Originally Posted by TEDY
These are Intel's numbers.
For real environment these numbers will be more ;)
How about "cpus dont gain from 64bits" for a more accurate title (in regards to the article posted)
The point here is that Core2 gains less from running 64 bit code than AMD64 does, at least that is what some people said.Quote:
Originally Posted by Ailleur
I am running a benchmark on this as we speak, eta 20 minutes.
Ahh yes my bad, when i first read the sentence i thought every intel scored 5-10% higher and all of amd was 2-3%.Quote:
Originally Posted by uOpt
Carry on!
Yeah I don't think so. :nono:Quote:
Originally Posted by Cooper
What`s wrong with the source ?Quote:
Originally Posted by ScottFern
So conroe performs close to its potential in both 32 bit and 64 bit environments and people complain, shouldn't the complaint be that amd's performance drops so much from moving from the native 64bit to 32bit mode?
Conroe outperforming amd in both 32 and 64 bit environments certainly removes another factor from the performance showdown however.
K8 is 32bit and 64bit native. it's not that there is a drop from 64bit to 32bit, it's that the advantages of x86-64 give a performance boost when properly taken advantage of ;)Quote:
Originally Posted by onewingedangel
Still a shame about the drivers :( Maybe i`m out of date, but do ALL drivers still need to be 64-bit for Windows 64?Quote:
Originally Posted by ozzimark
I ran some 64 bit benchmarks in addition to my 32bit benchmarks.
In my 32 bit FreeBSD tests for C/C++ compilation a 2.40 Conroe with DDR533 is 5-8% faster than a 2.60 with DDR432 (*), or about 14-17% faster per MHz.
Running some similar C/C++ compilations on 64 bit Linux (all software 64 bit), the 2.40 GHz Conroe is 18-25% faster than a 2450 MHz Opteron.
I'd say the lack of 64 bit performance on Conroe is a myth.
This is preliminary. I have problems controlling the Conroe's clocks from Linux, I am not 100% sure I am actually at 2.4 GHz here. Damn BadAxe...
(*) Before anybody cries foul: the 5-8% of the 2.4 Conroe versus 2.6 Opteron are only for C/C++ compilation, Conroe goes to 20% advantage for scripting languages and Lisp and to 25-30% for low quality video. The number here are purely for C/C++ compilation. I full 64 bit version of my benchmarks is in the works.
interesting
Would you mind running more tests for us?Quote:
Originally Posted by uOpt
The full set of 32 bit results is here. Has the Conroe at a few frequencies and a ton of AMD64 chips and some Pentium-Ms thrown in:
http://www.cons.org/cracauer/crabench/core2.user.html
Results with multithreading/processes:
http://www.cons.org/cracauer/crabench/core2.wall.html
Rather nice write up man.
Good work as usual :toast:
Quote:
Originally Posted by uOpt
This is exactly what I was thinking about when I commented earlier. There is no way Conroe is somehow not optimized for 64bit Windows OSes. It seems more like propoganda than anything else.
uOpt
do these charts basically just support what u said in post #16? as I'm not familar with a number of those benchs, would you mind summarising the important impacts out of the result. thx
If anything, Conroe should be superior to AMD in 64-bit due to using full SSE2 capabilities, which is very optimized in Conroe..
The performance might not be overly noticable at first, because most compilers were made with the K8 foremost in mind.
Intel's 64-bit compilers which will have Conroe optimizations should noticeably higher performance.
The type of application will vastly influence the performance gain aswell. Not every application will benefit from the use of expanded registers and SSE2.
There is no comparison, no evidence. Just thoughts. Also all Netburst, K8 and Core2 Duo will perform different on different OSes and different software in 32bit and in 64bit environment. For example the K8 perofrms almost same on WindowsXP x64 and many times slower than XP x32, but it performs much better on Linux 64bit than Linux 32bit. There is some explanation and it is reasonable, the instruction fetching. I wonder how Vista will be optimized for Conroe. Vista was cancelled many times and the last time was becouse Core2 optimizations.Quote:
Originally Posted by Cooper
Did I get it right?Quote:
Originally Posted by uOpt
You run compilation tests on a 32bit BSD kernel and a 64bit Linux kernel and compare the results.
I think even on one kernel there can be optimizations for one of the architectures present while the other runs unoptimized code (example: sse2 code for intel chip while no sse2/3dnow for amd). But with two completely different kernels this comparison is even more meaningless - I think.
If somebody can assure me that all the kernels are optimized for both architectures - but IMHO nobody can.
Just my 2cents
mibo
well if you want a completely un Optimized OS, you are going to have to make your own...:fact: when you try to make a fast os you have to use hardware specific features if you want it to run well. Although you would make one that runs equally well on both Current/Next gen AMD/Intel chips. but you would lose out on some of the more advanced features you can use to make your OS even better.Quote:
Originally Posted by mibo
Although the OS that is closest to unbiased towards AMD or Intel would be BeOS.
I don't compare BSD to Linux. I compare 32 bit results AMD64 to Conroe and 64 bit results AMD64 to Conroe to find out whether Conroe is weaker in the 64 bit part. The 32 bit tests happen to be done in FreeBSD and the 64 bit tests in Linux. Both are not compared to each other. Only the processors are compared to each other on the different bit sizes.Quote:
Originally Posted by mibo
The kernel is almost irrelevant for the benchmarks I present in the "user time" charts, they spend all their time in userland and there's no parallelism.
It is true that the applications have been compiled with generic options that has the same code run on all architectures.
No, post number 16 just says that Conroe has the same advantage over AMD64 in 64 bit code as it has in 32 bit code.Quote:
Originally Posted by gazzoom
Post number 16 says that assumptions that Conroe is somehow not as good in 64 bit code are unfounded.Quote:
as I'm not familar with a number of those benchs, would you mind summarising the important impacts out of the result. thx
My charts (which are the 32 bit charts) say that Conroe basically rocks but the speed advantage per clock is not as great as people hoped for, at least not for many applications that are important to me - namely C/C++ compilation.
There was some mixup in the exact clocks used there thanks to the Fedora fools messing with the kernel options for cpufreq and I was a little higher than I thought.Quote:
Originally Posted by uOpt
So it looks like the actual speed advantage of Conroe in 64 bits over AMD64 is the same as in 32 bit code, aka nothing to see here.
ummm why don't you use Bios overclocking instead? then you will not have to deal with such software issuesQuote:
Originally Posted by uOpt
The Fedora guys manage to accidentally override the FSB settings and change the clocks. Don't ask. Just use Debian.Quote:
Originally Posted by nn_step
I now have a native kernel running on my FC5 installations, things are better now. Verifying results.
why don't you benchmark on OUR favorite OS.. FreeBSD?Quote:
Originally Posted by uOpt
Availability. The Conroe board is booted under Linux/amd64 now and I have my server running Linux/amd64 permanently running. Both using the same compiler, too. To do FreeBSD I'd had to set up a comparision AMD64 machine.Quote:
Originally Posted by nn_step
There won't be significant performance differences for the user time benchmarks between FreeBSD and Linux anyway as long as you use the same compiler and application versions.
I couldn't expect that Fedora Core 5 got themself into that deep a mess with the cpufreq module. Wait. What did I just say? There's no mess that the Fedora guys's wouldn't be happy to jump into. Why do I keep it? Why do people enjoy watching train wrecks.
Usual disclaimer: I don't own a Conroe chip and if I did I wouldn't overclock it. All running with somebody else.
thx, interesting read this thread
Great stuff uOpt, keep us updated :toast:Quote:
Originally Posted by uOpt
:eek: :slap: :slap: :slap: :slap: :slap: :stick:Quote:
Originally Posted by uOpt
tis true.. hence I love the BSDs. :toast:Quote:
Originally Posted by STEvil
The best part is that all you need to do is recompile the kernel and kick out the speedstep-contrino module which Fedora decided to compile statically in.
But the bad thing about this is that the kernel rebuild procedure in Fedora is absolutely inane and trashy. They really think the enduser doesn't need to recompile a kernel.
Info from Intel Comp. (from employee there) - Release of Conroe cpus will be delayed 2 month! Because overheating cache units and poor performance ... Conroe is very big hype only.
Anyone else able to confirm this?Quote:
Originally Posted by OBR
i have news about it, but not in english ... Conroe have big problem with overheating in aplications with huge using cache. And only small performance improvement against AMD cpus in last revision B1. Intel must delay mass production.. 2 months.
i've seen a 4 day push back...
http://www.digitimes.com/bits_chips/a20060629A2007.html
but nothing about 2 months...
Well... give us something more credible, in any language! Links?!?Quote:
Originally Posted by OBR
windows xp64 was just recompiled. not rewritten for 64bit, thats why you don't see any profit... in 2003 there is performance differenceQuote:
Originally Posted by gOJDO
to others this info is already known for months, the em64t bit implement from intel is still not 100% accurate to the a64. same with sse2 but then visaversa
if you check my thread it's a fact woodcrest gaining 10%less out of 64bit then opteron so its the same for conroe and merom.
http://www.xtremesystems.org/forums/...d.php?t=104214
they delay vista for core :clap: :clap: real link to that news?
I ran some other not to be named stuff and I see more Conroe kicking.
I have two cases of Conroe being 100% faster per clockspeed (3.66 GHz DC Conroe three times faster than 2.4 GHz dual single-core Opteron - which has slow RAM).
One case is 32 bit code and one is 64 bit code, so that is really a non-issue.
The performance characteristic of the 32 bit case is very wired. If you are familiar with Common Lisp programs, you can run Common Lisp programs in "fast mode" and "safe mode". Safe mode adds all times of checks: integer overflow, extra type checking, argument checking etc. Without the extra checks the conroe is 50% faster per clockspeed, with the extra checks it goes towards 100%. It is almost like you get the checks for free.
The 64 bit case of 100% faster is just another random C/C++ compilation is a huge tree and I currently don't have an explanation why the difference is bigger than in my own benchmarks. The tree in question is certainly template-heavy, maybe it is the bigger cache.
try a program that needs more than 16Mb of cache and has random segments in it. you'll see Conroe get beat like a red haired Stepchild
I don't think I have any real-world code that blows a 4 GB cache. Well except that junk tablular generator I wrote at my old employer but let's not talk about that...
My point is Conroe performance takes some surprising turns.
I believe the surprises come not just from the 4 MB cache versus 2 MB for the dual Opterons. I believe that maybe the variable assignment of potentially all 4 MB to one code leads to some surprises.
I should also give the Intel compiler a spin just in case.
oh yes please use the Intel designed benchmark.. it shouldn't be unbiased against non INtel procs :rolleyes:
What program uses more than 16MB of cache?Quote:
Originally Posted by nn_step
Duhh... Minesweeper?Quote:
Originally Posted by shimq1
i think i know what happened here, ill try to simplify my notions with this handy example:the pentium d went from 1fps to 2 fps....massive percent increase, while the conroe went from 50 fps 60fps...not as great as a percent increase lol
:rofl:Quote:
Originally Posted by DoubleZero
But 50fps - 60 fps would be a massive absolute value...Quote:
Originally Posted by grimREEFER
why not get a computer that goes from 0 fps to 1 fps. then the infinite increase in FPS is completely unbeatable :woot:Quote:
Originally Posted by riptide
lolQuote:
Originally Posted by nn_step
Complete and utter Hogwash...
I am running out of time to analyse some of the more interesting/puzzling results and won't come to conclusions before the 4th of July weekend.
I'm throwing some raw data at you, numbers are CPU time used (this is single-thread):
This is compiling/building a Common Lisp system. (BTW, Netburst completely sucks here, I'm glad that episode is over.)Code:Lisp build:
fast safe (fast/safe = target policy)
2.4 939-DC-Opt 505 826 (memory 218 MHz)
2.6 939-DC-Opt 469 731 (memory 216 MHz)
2.4 940-SC-Opt 537 846
2.4 Conroe 328 439
3.66 Conroe 222 296
You can build the program two ways: safe-mode and fast-mode. The safe-mode build will insert a lot of extra checks like type checks, integer overflow checking, function parameter counting etc.
As you can see, the Conroe completely spanks the AMD64s in the safe-mode build, more so than in the safe-mode build. That is puzzling, I have never in my 15 years of Lisp programming seen anything like this. Suddenly you get the insertion of the extra checks almost for free, whereas so far you had to weight getting the checks against twiddling your thumbs for a while duing the build.
Here is a relative index, the first rows giving you:
- performance/MHz fast-mode
- (same, relative to 2.4 Opteron)
- performance/MHz safe-mode
- (same, relative to 2.4 Opteron)
That means Conroe reaches a 50% advantage over AMD64 per clockspeed for the fast-mode build but goes up to 90% advantage for the save-mode build.Code:
fast (rel) safe (rel) fast safe
------------------------------------------------------------
1212.0 (1.0) 1982.4 (1.0) 2.4 939-DC-Opt 505 826
1219.4 (1.0) 1900.6 (1.0) 2.6 939-DC-Opt 469 731
1288.8 (0.9) 2030.4 (1.0) 2.4 940-SC-Opt 537 846
787.2 (1.5) 1053.6 (1.9) 2.4 Conroe 328 439
812.5 (1.5) 1083.4 (1.8) 3.66 Conroe 222 296
Possible explantions include:
- It's the larger cache. Since this compilation is single-thread the AMD64 has 1 MB, the Conroe has between 2 and 4 depending on how it is associated with the one core running the compiler
- Some parallel execution unit in the Conroe picks up the extra instructions to insert the safety checks
- We get the extra instructions cheaper than on AMD64 due to some clever rescheduling in Core2
- The extra instructions to insert the safety check in the compiler normally blow memory prefetch in AMD64 and Netburst but Core2's prefetch is clever enough to find the stuff in advance
- I am doing something wrong here (not likely, I re-ran it a few times)
- All of the above
I need to run a few programs that report cache hits and the like but I don't think any of the performance counter programs that exist are running on Conroe yet.
It was some months ago, so it might not be true. I found this article first,Quote:
Originally Posted by duploxxx
http://www.smarthouse.com.au/Computi...forms/R7G5G6U4 and than I found this
http://www.pcpro.co.uk/news/85506/vi...forrester.html
You really do got me curious here...Quote:
Originally Posted by uOpt
The first thing that cameup to my mind was...***m
thats not for core thats for ViiVQuote:
Originally Posted by gOJDO
Or someone could just use Win 2003 server and 2003 64 Bit server, and use 32/64 Bit Cinebench....Quote:
Originally Posted by nn_step
Is this really this difficult?
I don't understand how comparing results of these two processors in 32bit, and then comparing them again in 64bit would be a revealing test? Wouldn't you be getting rid of more variables if you did a comparision of the differences of A64 machine (32bit vs. 64bit benchmarks) and also a Conroe machine (also 32bit vs 64bit benchmarks) and then compare the deltas of these two machines? Also, are the same benchmarks being used across the two OS's? I understand that an advantage over A64 is trying to be illustrated, but the advantage Conroe holds over A64 is already apparent. It is more interesting to see if Conroe in 32bit gains an advantage over itself in 64bit.Quote:
Originally Posted by uOpt
I was strickly comparing whether Conroes speed advantage in 64 bit code over AMD64 is the same as Conroes speed advantage in 32 bit code over AMD64. It is.Quote:
Originally Posted by phi|os
I did not compare 64 bit performance to 32 bit performance. I'd like to do that but this is more complicated than it sounds. Compilation benchmarks have to target one common platform (which makes one a crosscompiler and the other not unless you make both crosscompiler). Most multimedia programs have hand-coded MMX or SSE assembly routines thrown in that might or might not trigger based on whether you are on x86_86 or i386. Most other benchmarks are either useless artificial benchmarks and/or are one-trick ponies.
source here
http://www.xbitlabs.com/images/cpu/c...t/sandra-1.png
http://www.xbitlabs.com/images/cpu/c...t/sandra-2.png
http://www.xbitlabs.com/images/cpu/c...t/sandra-3.png
http://www.xbitlabs.com/images/cpu/c...t/sandra-4.png
http://www.xbitlabs.com/images/cpu/c...encemark-1.png
http://www.xbitlabs.com/images/cpu/c...encemark-2.png
http://www.xbitlabs.com/images/cpu/c...bit/7zip-1.png
http://www.xbitlabs.com/images/cpu/c...bit/7zip-2.png
http://www.xbitlabs.com/images/cpu/c...-64bit/wme.png
http://www.xbitlabs.com/images/cpu/c...t/pdnbench.png
http://www.xbitlabs.com/images/cpu/c...athematica.png
http://www.xbitlabs.com/images/cpu/c...inebench-1.png
http://www.xbitlabs.com/images/cpu/c...inebench-2.png
http://www.xbitlabs.com/images/cpu/c...inebench-3.png
http://www.xbitlabs.com/images/cpu/c...inebench-4.png
http://www.xbitlabs.com/images/cpu/c...bit/povray.png
http://www.xbitlabs.com/images/cpu/c...bit/ut2004.png
I just read that article too StyM. They said overall Conroe gets ~10% boost in Windows XP 64 over 32 bits. Not bad, AMD gets about ~15%...
Vista isn't coming out for a while longer. Might be even more delayed than planned. Plenty of time for both company's to fix what they need to fix.
C2D still beats FX-62in 64 bit appplications. In some cases out performing FX-64 in 32 bit applications. There is no other AMD process to bench to imply or
suggest what kind of performance gains C2D should be making. There are no AMD processors that even beat C2D in 64 bit applications. Therefore, the gains that FX chip make are mute, period. FX would need to make on average 40% gains in 64 bit applications to be competive with C2D and in most cases beat C2D.
What I don't understand is why the fanboism that FX is better then C2D in 64 bit applications when the gains themselves are so meager. Is this the best you can do? AMD still loses out on every 64 bit benchmark out there. Therefore, it is not better then the C2D in gains from 32 bit applications. What that is called is diminishing returns not gains.
Now is that really what this is about ? This shows how the GAINS are in 64bit, not if conroe is faster then the FX.Quote:
Originally Posted by Eastcoasthandle
Sorry man, but you are paranoiac :para: No one is saying here that C2D is slower than FX. Jesus.. :rolleyes: Thats what I call fanboism. :slapass:Quote:
Originally Posted by Eastcoasthandle
umm Dude who said that about current AMD models?Quote:
Originally Posted by Eastcoasthandle