In part 1 of this two-part series, ExtremeTech examines the performance of Windows XP Pro x64 and 32-bit Windows on a dual-core CPU. This part features the AMD Athlon 64 model on both operating systems. The next part will feature Intel’s best dual-core offering.
I’ve been running Windows XP SP2 on my new dual core AMD Athlon 64 x2 4200+ for a few weeks now, and I must say it really does make a difference, but in a way I hadn’t anticpiated (having run dual processor Linux and Unix systems for years).
It really helps the responsiveness of the system. Even when I load up Unreal Tournament 2K4, I can still alt-tab over to another app and the OS is snappy. If there’s a desktop app that freaks out and starts churning 100% of the CPU, like a java or I’m still in good shape since there’s another CPU to handle my requests.
I’ve noticed it’s even more beneficial for Windows than it is for Linux, because of this responsiveness (I rarely ever had any responsiveness lockups with Linux, had them all the time with Windows).
How’s the responsiveness between Linux and Windows compared on the same machine? Can you provide full versions of each?
Thanks!
It’s difficult to compare, since the tasks I perform are usually quite different when I boot into Windows as compared to when I boot into Linux.
When I boot into Windows, it’s a weeks old install of XP SP2. With Linux, it’s a fresh install of Ubuntu 5.10. It’s got 2GB of RAM and an nVidia 6800GT (dual DVI, x16 PCI-Express. 256 MB RAM).
Basic video responsiveness is better in Windows because of the video drivers. Even with the official nVidia drivers installed on Ubuntu, it’s still slower in general (page scrolling, refreshes, redraws) although not by a huge amount. It’s still noticable though. I don’t do any 3D apps with Linux, so I can’t talk on that performance compared with Windows (where I play some shoot-em-up games).
I never had responsiveness problems with Linux. In general, if an app were to freak out, the others would be fine and it wouldn’t hurt system responsiveness. In Windows, an app freaking out could bog down the entire system. With the dual core, Windows is much more responsive to various workloads. With Linux, I don’t notice that much of a difference between dual core and single core. I’m sure it’ll help if I’m doing any intense compiling or something of that nature.
Also, the default kernel from Ubuntu doesn’t support the dual core Athlon chips yet. You’ll have to compile your own kernel, or it won’t see two cores (check /proc) and run in single proc mode. There’s also a problem with running the later kernels and trying to mount extra paritions, which I haven’t worked out yet.
I don’t believe you can see any difference in 2D performance in Linux and Windows if you are using the nvidia drivers with the system you stated.
Sounds like a placebo effect.
If you can, sounds like something is wrong on your system or not properly enabled in your xorg configuration.
I don’t believe you can see any difference in 2D performance in Linux and Windows if you are using the nvidia drivers with the system you stated.
Why don’t you believe it? You don’t want to believe it? Have you actually run both on the same system? I mean, they couldn’t possibly run differently, given that they’re two very different operating systems with vastly different graphical plumbing and a vendor who clearly puts more resources to one over the other (although it’s good they’re putting resources into Linux).
If you can, sounds like something is wrong on your system or not properly enabled in your xorg configuration.
Xorg configuration is fine. The nvidia drivers are in place and working properly. The module is loaded, and xorg clearly shows in the logs that it’s using the correct driver.
Tony,
With Ubuntu 5.10 (as of a new X server a couple days ago) windows rendering/snappyness in my opinion is on par with the Windows GUI. 5.10 uses Ciaro, which in turn uses Giltz (OpenGL) has a backend, so your nice and shinny 6800 is doing the rendering. I have found that adding Option “RenderAccel” “true” to xorg.conf device section can also speed up rendering as well. So I disagree that 5.10 is slower (5.04 was).
And for my system playing Nexuiz or UT2004, they latest nVidia driver has brought FPS pairty for Windows and Linux. Which is something I have long waited for.
As far as the kernel-land. I have not had any trouble mounting, did you report the bug, along with your specs? Aslo, to run 32-bit dual core load the K7-SMP and for 64-bit load the K8-SMP. The defualt kernel is non SMP i386. So yes, everyone needs to load an optimized kernel, esp for HT/Dual CPU/Dual Core support
Maybe this will help:
386 – default, use for Pentium ClassicK6
(no 486,586)
686 – Pentium ProCeleronIIIIIIV (non-ht)
686-SMP Pentium IV HTDual CPUDual core
K7 Athlon, Athlon XP,Athlon 64(32-bit),Duron,Semperon
K7-SMP AthlonXP64X2 (32bit) – Dual CPUDualcore
K8 Athlon 64 (64bit)
K8-SMP Athlon X2Dual
If you compare various benchmarks you’ll see that Linux offers a much better 64-bit performance across the board in comparison to Windows XP Pro x64. This means if you have a 64-bit machine you just got another good reason to switch to Linux.
How much better does Linux run when using AutoCAD, Dreamweaver, or Visual Studio?
Oh wait… guess I’m stuck with Windows. Linux doesn’t work everywhere for everyone. Stop preaching.
No one ever said that linux runs the same apps as windows does. But if the app comes in both Linux and Windows flavors, then the linux version will normally run faster.
The performance gap will get large enough that Linux will be able to run Windows apps in emulation at same speeds as native Windows.
A comparison between the standalone 64 bit Maya renderer on XP64 and a 64bit Linux would be very interesting.
Autocad – that’s going to autodesk’s problem. Microstation should seize the opportunity and get a jump on Autodesk wiht a native 64bit linux port.
Visual Studio – eclipse and many other IDE’s exist on linux. lots of people don’t care about .Net.
Dreamweaver – many alternative visual html editors run on linux, if you need that kind of thing.
The performance gap will get large enough that Linux will be able to run Windows apps in emulation at same speeds as native Windows.
ROTFL! You keep hitting that crack pipe my friend, your brain is obviously damaged beyond repair!
I don’t think he said Linux worked everywhere or for everyone. He just said that it was faster than Windows on the x86_64 hardware – it’s plausible that it comes ahead but could use some benchmarks / real world measurements to prove the point.
Application support is a separate issue from the performance of the underlying memory management / network stack / scheduler, etc etc. Performance can be a reason to switch (either way), app support can be a reason to switch (either way), so can lots of other things.
[side note: I don’t think the grandparent post deserved moderating down by the community at all but it did need more supporting evidence]
“How much better does Linux run when using AutoCAD, Dreamweaver, or Visual Studio?”
Your last name is Bush right?
FWIW – AutoCAD and DreamWeaver can be run easily enough under Linux. Never tried a recent version of Visual Studio, but VS5 ran okay…
FWIW – AutoCAD and DreamWeaver can be run easily enough under Linux. Never tried a recent version of Visual Studio, but VS5 ran okay…
The question is: Why would you (or a significant portion of other users) want to run Visual Studio under Linux?
And to the original line:
How much better does Linux run when using AutoCAD, Dreamweaver, or Visual Studio?
Complaining about Visual Studio not running under Linux is like complaining why you cannot run IBM xlC or ESSL on your x86/x86_64 PC.
linux trumps windows in all cases.
Most compilers don’t have as many optimizations for 64-bit as they do 32-bit. After benchmarking SpecJbb in both 64 and 32-bit machines, it was obvious that the java implementations for 64-bit were highly unoptimized. In the next year or so, I would suspect that 64-bit applications will be 10-20% faster than 32-bit systems… 4 extra registers means fewer reads from memory.
64bit gives you 8 extra general purpose registers and 8 extra SSE registers. This is twice the normal number of registers.
In my experience with Windows XP and linux in both 32bit and 64bit, and with SMP (two opterons), both run about the same speed, with less than 5% difference between the platforms. Windows XP tends to update the GUI more smoothly, but linux multitasks better. These differences are rather small and probably wouldn’t be noticed without lots of switching back and forth actually looking for the differences.
SMP makes more of a difference on Windows for multitasking since its multitasking isn’t quite as good. This is especially noticeable when tasks are hogging the CPU time. Linux’s scheduling better, but SMP still makes a difference. It’s just not as noticeable since it’s scheduler is better. Again, the differences are small and not noticed unless under extreme circumstances (heavy loads for example).
The performance gap will get large enough that Linux will be able to run Windows apps in emulation at same speeds as native Windows.
======
How the hell can that happen when every iteration of KDE/GNOME is progressivly making my desktop into an expensive paperweight?
Sheesh. OPTIMIZE!
Obviously you haven’t use Gnome or KDE in a long time. Every version of KDE since 3.0 has been getting faster, as have the past several versions of Gnome.
either you are using a version like kde 3.0 or kde 3.1
as kde has been optimising since 3.2
gnome has been getting optimised since 2.8 so you must be using 2.6 or before.
other than that you are just a troll
I don’t have a multicore system at home, but I can compare my win2k with my linux-distro.
Refreshing windows and movement of mouse pointer seems to be more fluid in Win2K. However.. under heavy load (or a misbehaving application) Win2K completely fails to respond for anything between 10 seconds and several minutes. This never happens with my linux distro (running Gnome). One app doesn’t bring the other applications to a halt, nor does the desktop fail in responsiveness (though applications take a longer time to start, as is natural under a heavy load).
AFAIK this is partly due to a poor scheduler in Win2K. I believe the scheduler in Win2K3 Server has been improved somewhat – however it still sucks in regard to XP.
dylansmrjones
kristian AT herkild DOT dk
However.. under heavy load (or a misbehaving application) Win2K completely fails to respond for anything between 10 seconds and several minutes.
This is precisely the unexpected benefit that having a dual core with XP brings, in that the system still responds fine in situations that would make a single core XP machine unbearably sluggish.
As a result, I’m very happy with my dual core system. It gives you dual processors with a regular cost motherboard, at only about double the cost of a similar single processor. Quite a bargain.
This is particularly annoying on my laptop. Occasionally the piece of shit VPN client, or a vendor helper app, or even Firefox will consume inordinate amounts of CPU upon the laptop coming out of sleep mode. This makes the laptop take forever to wake up, sometimes more than 2 minutes.
That’s odd, I rarely ever have my system lag so bad that it takes 10 seconds to do anything. When it happens, its always an app gone bad.
2k3 server is very responsive and very good with apps freezing, just as good as XP. The 2 systems I have with the OSes are pretty similar in specs, so..
Interesting. Since I got my password and login to MSDN AA today, I’ll might download the ISO-image when classes are finished to day
– it’s free for me anyway
dylansmrjones
kristian AT herkild DOT dk
I’ve been trying out WXP x64 and… yeah, ok, but are there any applications compiled (or at least compilable) for 64bits (and optimized)?
Sure, POVRay or some high-end graphics packages may be, Mozilla64 and IExplore64, and one game that I know of, Far Cry, which has a patch available, but anything else? Oh, yeah, Java (though not the browser applet plugins). Is that it?
From what I’ve been able to find, WXP x64 is ok but we’re not there yet with 64bit applications. (AFAIK)
Preparing a 64-bit app is a matter of having 64bit-enabled compiler and a source code for that appliaction. So properitary programs will be few steps behind for some time…
Drivers are mostly 32bit so why run 64bit to have it brought to a crawl with the drivers.
Im sitting here ready with 64bit windows but limtied by the drivers available. ATI is the worst at this, they dont have unified drivers for mobile chipsets. The bastards.
When I bought my latest computer I went for XP64 to see what it was all about. I was surprised (to say the least) by it’s enormous speed. Bye Bye waiting times for app/game start.
I can admit that it is a big problem with drivers, especially for all extra devices (like my Rio Karma) which simply doesn’t exist. However, being an early adopter, it’s important to realize that there are setbacks with being in the 1% group that tries a new product.
I’m not on dualcore and the only thing I can really say beyond drivers is that sometimes the system locks at random when closing an app for 1-2 seconds.
But imagine the following on a machine
Running Apache+MySQL+FTP server+Azurues with 100 open torrents. Then startup battlefield 2 and wait for about 0.01 seconds before it kicks in… I’m amazed by the 64bit power I never dreamed of before.
My big question now is, when will games utilize this technology and push the limits some more?
Going back to 32bit? I’m forced to every day in the office and it’s a pain…
I’m amazed by the 64bit power I never dreamed of before. Going back to 32bit? I’m forced to every day in the office and it’s a pain…
The wonders of marketing and the placebo effect …
Do you have any hands on experience or are you just trolling?
I know there is a big “anti” against 64bit, especially here on OSNews… but it’s definitely faster. Maybe MS did some major changes to XP64bit under the hood which just makes it faster? It surely is faster anyway…
I know there is a big “anti” against 64bit, especially here on OSNews… but it’s definitely faster.
From the article:
“We’re really encouraged by the minimal performance losses and encouraged by the potential gains of 64-bit applications.”
Emphasis on “losses” and “potential”.
Very few programs require 64-bit integers and most desktop programs are still happy with a 32-bit address space (although of course that is going to change as everything keeps on expanding.)
Meanwhile, 64-bit pointers and register spills actually cause a slowdown. (But the extra registers more or less make up for that.)
Maybe MS did some major changes to XP64bit under the hood which just makes it faster?
Not impossible, but what could they be? Wouldn’t MS tell us about them? And why wouldn’t they apply those optimisations to the 32-bit version as well?
It surely is faster anyway…
Until I see benchmarks confirming that, this is just the subjective opinion of someone who’s probably invested quite a bit of time (and money?) into running Windows64.
rofl.. Keeps soaking up the marketing..
“… I’m amazed by the 64bit power I never dreamed of before.
LOL .. to funny…
Going back to 32bit? I’m forced to every day in the office and it’s a pain…
Huh?
You are kidding, right?
I’m on 64bit since the good-old-days of Alpha/DEC-Unix (currently typing this on a Dual Opteron/64bit FC4) and I fear that you are suffering from an acute case of “way-too-much-marketing-effect”.
Unless you have >2GB of memory, and you’re running highly optimized memory/CPU intensive applications, your OS, no matter what OS it is, runs slower in 64bit.
Gilboa
x86_64 is faster due to the extra registers available, so running 64-bit gains speed as things are compiled for that it instead of for x86. If the architecture is no different, just switched from 32 to 64 then yes 64 will be slower, this is the reason most userspace apps are 32 bit under solaris etc.
In theory, yes.
But
A. Both MSVC and the GCC’s (The rest of the world) level of optimization in 64bit is far from being equal to their 32bit brethren.
B. Driver optimization in 64bit leaves much to be desired. (Especially when it comes to Windows; Linux’ code is 32bit/64bit free by design)
C. Memory footprint in 64bit (both code and data) is bigger, lowering the cache hit rate. (Which is /very bad/)
In short, I’ve yet to see a 64bit OS outperform a 32bit in non server task. (AKA desktop tasks)
Gilboa
x86_64 is faster due to the extra registers available, so running 64-bit gains speed as things are compiled for that it instead of for x86.
Not necessarily. Benchmarks suggest that it depends on the application whether the slowdown due to the 64 bits or the speedup due to the extra registers dominates.
Shame AMD didn’t make the extra registers available in 32 bit mode as well. With the registers and decoders already there anyway, it wouldn’t have cost any significant extra hardware.
Although Microsoft probably would not have bothered with such an extension, gcc and the open source OSs would have been quick to make use of it and gain some extra speed almost for free.
Shame AMD didn’t make the extra registers available in 32 bit mode as well. With the registers and decoders already there anyway, it wouldn’t have cost any significant extra hardware.
Hmmm…
Although Microsoft probably would not have bothered with such an extension, gcc and the open source OSs would have been quick to make use of it and gain some extra speed almost for free.
That’s not going to last very long, though. Anyone with x64 hardware and Linux (or BSD, or x64 Solaris, …) will move to a fully 64bit environment anyway. Efforts are better spent elsewhere (though I admit the inital coding should/could be minor).
That’s not going to last very long, though. Anyone with x64 hardware and Linux (or BSD, or x64 Solaris, …) will move to a fully 64bit environment anyway.
Architectures that have been 64-bit for a while, e.g. PPC or Sparc still run plenty of 32-bit software, because it’s smaller and faster unless you actually need the 64-bit address space.
I realy HATE HP, I don’t know what they where thinking but they seem to have decided to NOT create native drivers for MOST of their printers… I have a Photosmart that is only a couple of months old and they will not provide x64 drivers. The work-around is to instal the Deskjet 990c driver!! They lack feature big time…
This is just stupid.
Actually, I went out and bought a dual core AMD 64 processor and board. FreeBSD 6.0 Beta3 AMD64, can’t install grub and quite a few other ports. Windows XP 64 same problem with the drivers everyone else is seeing. I went back to XP 32 for the day to day and am now waiting for i386 FreeBSD 6.0 to be released.
And in case anyone wanted to know why I went back to the XP 32 or I386 FreeBSD? One word, Nvidia deskview withe dual monitors. I can’t even get the generic Xorg nv to work under FreeBSD AMD 64. Seems there is a problem with the kernel. Nvidia does supply drivers for XP 64 in beta form
Windows XP x64 is built from Windows Server 2003 and NOT from the 32-bit XP.
According to FSMLabs, an AMD Opteron 265 dual-core system running RTLinux can deliver guaranteed interrupt latencies of no more than five microseconds, with scheduling jitter of no more than eight microseconds, even with Linux under a heavy load.” Heck, with numbers like that it seems like Linux could run circles around XP Pro for audio/video apps such as streaming, recording, and playback!”
http://www.linuxdevices.com/news/NS6761928882.html
Umm….
Most Linux users never ran with an RT patch-set in their lives. (Or any other RT Linux)
Heck, most Linux distributions don’t even turn kernel preemption on (And for a good reason…).
I don’t do audio work, so I can’t really comment on Linux vs. Windows. I assume that they both suck badly… (Though 2.6 should perform better)
Oh… and last time I tried RTAI patch-set, the nVidia driver went to hell… so I doubt that RT-Linux is ready for desktop usage…
Gilboa
What good reason is there not to turn on preemption?, it makes applications run much more relability/smoother and responsive. It’s no wonder people think Linux is less responsive than windows, and 2.6.13 makes better use of preeption. The -ck patches make responsiveness even better especially under load.
I’m not sure that all the preemption sensitive parts of the kernel are already protected by preempt_disable/enable and a lot of things tend to break when someone pre-empt’s your driver when the driver doesn’t expect it.
In my view, kernel preemption is the wrong tool for the /wrong/ job.
Instead of cutting long kernel tasks using involuntary preemption, kernel code should be cut into smaller chunks using workqueues, kthreads, voluntary preemption, etc.
Other then that, AFAIK, Windows doesn’t have kernel preemption either and it’s interrupt latency is in the 2.4 level.
Windows seem more responsive due to better drivers and better software optimization (Flash on Windows vs. Linux is a very good example. Same goes for audio drivers). In most cases, it has nothing to do with the kernel.
Gilboa
Well thats what I mean about 2.6.13, it has the option of voluntary preemption and does make the desktop more reponsive. It’s even got down to moving a Window and not getting any jerking, the kernel has everything to do with it. If OSS cannot do better drivers then they have no choice to try and reduce latency elsewhere.
Actually, if you’re using closed source drivers are even worse; There’s no way of knowing if the binary driver has protected all of it critical sections against involuntary preemption.
As I said, preemption is bad solution; If you are doing a long task in kernel space, once should check the need_sched flag and yield the CPU if it’s time to schedule out.
[quote]
The performance gap will get large enough that Linux will be able to run Windows apps in emulation at same speeds as native Windows.
[/quote]
A Emulation which has the same speed as the native version on the same Hardware ? oO
Eather your Emulation has 0% overhead or your emulation software has to be faster than the native version, in that case you could get rich to sell it to MS 😉
A Emulation which has the same speed as the native version on the same Hardware ? oO
Eather your Emulation has 0% overhead or your emulation software has to be faster than the native version, in that case you could get rich to sell it to MS 😉
You don’t know anything about Wine I can tell. Wine is NOT an emulator but an Win32 API layer on x86-based *nix’es. Therefore there is no or very little performance losses, and in some situations Wine on *nix’es actually performs better than Win2K, XP and 2K3.
You’re spreading FUD about Wine. I’m feeling inclined to politely ask you to get the facts
dylansmrjones
kristian AT herkild DOT dk
You don’t know anything about Wine I can tell.
[…] You’re spreading FUD about Wine.
Mind your language. The original poster didn’t say anything about wine. He was speaking about emulators in general, and as you say yourself: WINE Is No Emulator.
@ nimble
There is only one way realistic way to run Win-apps on *nix’es… and it’s Wine (and WineX)
If you don’t know that you’re troll.
Besides that, I was extremely polite.
dylansmrjones
kristian AT herkild DOT dk
There is only one way realistic way to run Win-apps on *nix’es… and it’s Wine (and WineX)
Never heard of VMWare? Xen? Bochs?
Besides that, I was extremely polite.
I dread to thimk what you’re like when you’re less than “extremely polite”.
There are other ways to run Windows applications under Linux/UNIX. If you are not already familiar with VMWare, it’s a very well-done product. I understand more recent releases of Xen now also support running a Windows environment within a UNIX/Linux environment.
It should be noted too that in some cases WINE (and other methods) do run Windows applications faster than the native code on the same hardware. In some cases, calls in the emulator can be mapped to native system calls that are far more efficient than the native Windows implementation.
A Emulation which has the same speed as the native version on the same Hardware ? oO
Eather your Emulation has 0% overhead or your emulation software has to be faster than the native version, in that case you could get rich to sell it to MS 😉
While I agree with you, there is a twist…
Welcome to the strange and wonderful world of mainframe goodness under x64. With AMD’s Pacifica or Intel’s VT page table extentions due out early 2006 (AMD) and winter 2005 (Intel), there’s no need for emulation.
The main hypervisor and the guest OS will initially have about a 6% impact on each other when they are running and eventually this should — as on the legendary mainframe processors — drop to 0%.
Are we there yet? Nope. Damn close, though!
Xen 3.x, VMware, and a bunch of other hypervisors should make things very very interesting with this new hardware.
lol..what’s that stupid 64 vs 32bit thing about?
i mean, ppl, if you want your 32 bit win STAY with it
there are a few ppl who are working with programms like maya/softimage xsi etc. and these people WILL see a higher performance with their 64-bit applications.
just look at softimage xsi 5.0 64-bit.
sure, if a am a ga(y)mer
i don’t need 64 bit, but that whole “64 bit is 5% slower at games than 32bit” is stupid.
64 bit IS the future, and there are people here, which have more than 4gbyte ram at home.
so plz think guys before saying such things like 64 bit isn’t necessary.
ol..what’s that stupid 64 vs 32bit thing about?
i mean, ppl, if you want your 32 bit win STAY with it
there are a few ppl who are working with programms like maya/softimage xsi etc. and these people WILL see a higher performance with their 64-bit applications.
same debate 10 years ago, some people thought programs in 32bit would automatically be faster than programs for 16bit………
nowhere near the truth
16bit apps “almost” always outperformed 32bit apps.
There was a massive increase in going to 16bit from 8bit, but not from 16bit to 32bit… thats where marketing came into play. They made me “believe” 32bit would be faster, more stable etc etc…
dont be stupid
of course 64bit is far better and faster than 32bit
it has to be, I read it in so many magazines and websites.
what makes you think that just because you said it will be slower, then it will be ?
I have been using computers for over 4 years and they always get faster, so of course 64bit will be faster thant 32bit.
stfu dickhead if you gonna say shit like this