News: Conroe doesn`t gain advantage in 64bit environment

Quote:

---

Originally Posted by mibo

Did I get it right?
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.
Although the OS that is closest to unbiased towards AMD or Intel would be BeOS.

Quote:

---

Originally Posted by mibo

Did I get it right?
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

---

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.

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.

Quote:

---

Originally Posted by gazzoom

uOpt
do these charts basically just support what u said in post #16?

---

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:

---

as I'm not familar with a number of those benchs, would you mind summarising the important impacts out of the result. thx

---

Post number 16 says that assumptions that Conroe is somehow not as good in 64 bit code are unfounded.

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.

Quote:

---

Originally Posted by uOpt

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...

---

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.

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.

Quote:

---

Originally Posted by uOpt

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.

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 issues

Quote:

---

Originally Posted by nn_step

ummm why don't you use Bios overclocking instead? then you will not have to deal with such software issues

---

The Fedora guys manage to accidentally override the FSB settings and change the clocks. Don't ask. Just use Debian.

I now have a native kernel running on my FC5 installations, things are better now. Verifying results.

Quote:

---

Originally Posted by uOpt

The Fedora guys manage to accidentally override the FSB settings and change the clocks. Don't ask. Just use Debian.

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 nn_step

why don't you benchmark on OUR favorite OS.. FreeBSD?

---

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.

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

Quote:

---

Originally Posted by uOpt

The Fedora guys manage to accidentally override the FSB settings and change the clocks. Don't ask. Just use Debian.

I now have a native kernel running on my FC5 installations, things are better now. Verifying results.

---

Great stuff uOpt, keep us updated :toast:

Quote:

---

Originally Posted by uOpt

The Fedora guys manage to accidentally override the FSB settings and change the clocks. Don't ask. Just use Debian.

---

:eek: :slap: :slap: :slap: :slap: :slap: :stick:

Quote:

---

Originally Posted by STEvil

:eek: :slap: :slap: :slap: :slap: :slap: :stick:

---

tis true.. hence I love the BSDs. :toast:

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.

Quote:

---

Originally Posted by OBR

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?

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...

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.

---

Well... give us something more credible, in any language! Links?!?

Quote:

---

Originally Posted by gOJDO

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.

---

windows xp64 was just recompiled. not rewritten for 64bit, thats why you don't see any profit... in 2003 there is performance difference

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:

Quote:

---

Originally Posted by nn_step

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

---

What program uses more than 16MB of cache?

Quote:

---

Originally Posted by shimq1

What program uses more than 16MB of cache?

---

Duhh... Minesweeper?