well if you want a completely un Optimized OS, you are going to have to make your own...Originally Posted by mibo
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.
Fast computers breed slow, lazy programmers
The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.
http://www.lighterra.com/papers/modernmicroprocessors/
Modern Ram, makes an old overclocker miss BH-5 and the fun it was
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.
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.
Post number 16 says that assumptions that Conroe is somehow not as good in 64 bit code are unfounded.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.
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
Fast computers breed slow, lazy programmers
The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.
http://www.lighterra.com/papers/modernmicroprocessors/
Modern Ram, makes an old overclocker miss BH-5 and the fun it was
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?
Fast computers breed slow, lazy programmers
The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.
http://www.lighterra.com/papers/modernmicroprocessors/
Modern Ram, makes an old overclocker miss BH-5 and the fun it was
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
Great stuff uOpt, keep us updated
All along the watchtower the watchmen watch the eternal return.
tis true.. hence I love the BSDs.
Fast computers breed slow, lazy programmers
The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.
http://www.lighterra.com/papers/modernmicroprocessors/
Modern Ram, makes an old overclocker miss BH-5 and the fun it was
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?
Fast computers breed slow, lazy programmers
The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.
http://www.lighterra.com/papers/modernmicroprocessors/
Modern Ram, makes an old overclocker miss BH-5 and the fun it was
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...
Athlon XP-M 2500+ 0343MPMW The King is Dead!
Phenom II X6 1090T 1025GPMW Long Live the King!
-------------------------------------------
I'm from the church of the operating room
Well... give us something more credible, in any language! Links?!?
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
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.
Last edited by uOpt; 06-29-2006 at 12:56 PM.
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
Fast computers breed slow, lazy programmers
The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.
http://www.lighterra.com/papers/modernmicroprocessors/
Modern Ram, makes an old overclocker miss BH-5 and the fun it was
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
Fast computers breed slow, lazy programmers
The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.
http://www.lighterra.com/papers/modernmicroprocessors/
Modern Ram, makes an old overclocker miss BH-5 and the fun it was
What program uses more than 16MB of cache?
Duhh... Minesweeper?
Posting Permissions
Reply With Quote
Bookmarks