Performance of 64-bit vs. 32-bit Windows Dual Core

mikemuch writes "ExtremeTech's Loyd Case has done extensive testing on the same dual-core Athlon X2 4800+ system to explore performance differences between Windows XP Professional x64 and good ole Win32. The biggest hurdle is getting the right drivers. There are a few performance surprises, particularly in 3D games."

Comments

Biggest Benefit

[dsginter]

The spyware can all be run on one of the cores while the other can be used to get work done. I'm getting one for my father-in-law.

Re:Biggest Benefit

[Wocko]

AKA the "hard" core.

Re:Biggest Benefit

[Bega]

I'd recommed getting him a computer that actually works.

Plenty of time to wait for 64 bit apps.

[Godeke]

The good this article tells us is that the 64 bit OS doesn't cause any significant loss of performance for the 32 bit applications that will function under it. On the other hand, the only 64 bit to 32 bit comparisons they have also show almost no differences. I think this is the most telling:

The good news is that 32-bit Far Cry (as of the 1.31 patch) runs fine under Windows 64-bit mode, with very little performance penalty. When we move to the base 64-bit version, we pick up a couple of frames per second at 1280x1024, but we defy anyone to actually notice the difference between 79.5 and 82 fps.

The good news is that the enhanced version still clocks in at 80 fps. This bodes well for 64-bit gaming, as game developers can add substantial new content and detail without sacrificing performance.

Desktop applications (even games) don't need the one thing that 64 bit computing really excels at: massive addressing space. A database server that is compiled to 64 bit code will have access to much more RAM, and thus have much better performance if RAM bound (which many DBs are). Meanwhile for POV-Ray the fastest result of 383 seconds was the 32bit application on 64 OS!

I think that it is safe to hold off on 64 bit for your personal desktop until a larger share of applications are compiled with 64 bit optimizations, but unlike the 16 -> 32 bit shift, I suspect the results will be underwhelming except for extremely memory consuming applications.

Re:Plenty of time to wait for 64 bit apps.

[hunterx11]

In addition to being able to address much more RAM, x86-64 chips also have more general purpose registers than their 32-bit brethren. This would probably account for performance gains more than anything else in most applications.

Re:Plenty of time to wait for 64 bit apps.

[AKAImBatman]

Arguably, though, you'd see much more of a performance gap if the applications were better designed to take advantage of the 64 bit power of the processor. That means not just a recompile as a 64 bit application, but having the app actually use 64 bit numbers whenever possible.

It's a bit like the jump to 32bit. When all we had was 16bit software to test, the performance numbers tended to be equal. Once the software started showing up that was written for 64bit processing, we started seeing a major performance gap.

Re:Plenty of time to wait for 64 bit apps.

[Bloater]

> Is it possible that diminishing returns is kicking in on the register set size, or simply bad compilers (or use thereof)?

Bad compilers or more likely they haven't hand optimised their inner loops.

Most high performance ia32 (Intel Architecture 32 bit) software has hand tuned assembler for the tight inner loops, but it takes time, experience and skill to create such assembler. Some discussions I've seen put recent gcc compiling generic C for amd64 at close to the performance of hand optimised assembler for ia32 on the same Athlon 64 (for tight inner loops).

There was an article about an assembler version of a cryptographic function that showed amd64 was capable of a *huge* performance increase over ia32, due to its increased register set.

However it can also come down to implementation quality. IIRC, benchmarks of early amd64 xeon chips showed that they performed worse than ia32 on the same chip for tests that athlon 64 shows a performance *boost* in its 64 bit mode.

Re:Plenty of time to wait for 64 bit apps.

[caspper69]

Well, as ironic as it is, gcc is the one that used to suck when it came to generating functions called with the __fastcall calling convention (where function arguments are passed via registers instead of on the stack). But now, the ABI for x86-64 seems to encourage the __fastcall convention by default (assuming this is due to the extra general purpose registers). I found this out when doing some OS dev and some ASM test routines were not working in 64-bit mode. I was looking in RAX like I always had (well, EAX at least), and lo and behold, no value!! Well, a quick read of an AMD64 ABI guide from x86-64.org (which went offline last week, don't know if it's back), and I was ready to rock and roll again.

Seeing as how MSVC and icc both conform to the x86-64 ABI, I would assume that both are equally capable (they're already damn near the same anyway) of utilizing the extra registers.

Re:Plenty of time to wait for 64 bit apps.

[freidog]

Well x86 chips have pretty well developed methods of dealing the lack of registers.
Register renaming eliminates, or at least minimizes most of the problems with a small register set.
(Athlon64 has something like 72 integer registers and 122 90 bit FP registers (two of these are combined to make an XMM register for SSE vectors), almost all of which are availible in 32 bit mode).

The extra achitectual registers will help with moderate to long term storage (more than a few dozen clock cycles between uses) as the programmer will explicity specify the data remains in the register, where as with current shuffeling it's up to the CPU (and to some extent how the renamed registers are inteded to work) to determine if a write to cache is in order, or not.
And really with the longer storage times, you often have the flexibility to write out to L1 and schedual the load so that there's no penalty for the load. (ie issue the move back to the register the 3 clock cycles prior to when you need it that an L1 load usually takes).

The new registers probably won't make all that much difference in the end. But the again, nothing from the move to 64 bit will be a major impact for a while (at leat on the desktop).

Re:Plenty of time to wait for 64 bit apps.

[Anonymous Brave Guy]

Anyone care to comment on MSVC's capabilities in the 64-bit arena?

Almost non-existent in 6, 7 (.Net 2002) and 7.1 (.Net 2003). We've switched some of our 64-bit test platforms at the office from using an SDK to using the beta of version 8 (VS 2005), which seems to be much better at targetting such a platform, but obviously it's unlikely you'll see the latest and greatest game today built with a compiler that's not due for release until 7 November...

Re:Plenty of time to wait for 64 bit apps.

[caspper69]

You are right on both counts, but the latter is not as big of an issue as RISC advocates would like you to believe. x86 processors since the Pentium Pro (hazy, but maybe the Pentium) have used register renaming, whereby the internal micro-op execution core of the processor has many, many more registers than the IA32 ISA (like 32/64/128 vs. 8).

The greatest speed increase will not come from the number of registers, per se, but rather the compiler's ability to explicitly access those registers. There is only so much a processor can know about a code path prior to execution, and even if it does know as much as we can possibly tell it beforehand, there is no guarantee that two code paths will ever be identical. But a compiler can be much more creative about its knowledge of a given code path and can instead optimize for 16 instead of 8 general purpose registers in addition to making the __fastcall calling convention the ABI's default.

I guess my point is that yes, the number of externally addressable registers is important, but only if a compiler can really make intelligent use of it. Simply using 16 instead of 8 will not get you nearly as much of a speed increase because of the large internal register windows of modern x86(-64) processors. I think you'd be surprised just how optimized that register window is. The speed impact is not zero, but it's nearly imperceptible in most instances. You're much more likely to see a huge imporovement on a given algorithm if all of its instructions and data (and output if it uses it's output for further input) can reside in the on-die cache than anything to do with the number of registers. If that were the case, then we should see a tremendous speed increase just from moving applications to 64-bit. Right now, either due to the compilers not being quite up to snuff or due to the increased memory footprint of 64-bit code, this is simply not the case. Real world ranges from a hit of 10-15% to an increase of 5-10%. Some apps do benefit substantially more, but they are definitely the exception.

Why doesn't the submitter do this?

[theGreater]

http://www.extremetech.com/print_article2/0,1217,a =159811,00.asp
Printable Version
-theGreater.

Re:Why doesn't the submitter do this?

[entrylevel]

Because the printable version automatically redirects to the normal one if the referred is not extremetech.com

After reading the benchmarks...

[vandy1]

I can only conclude that they made no attempt to use the extra registers. Of *course* an f'ing 32-bit system will outpace a 64-bit system; Why do you think most Solaris apps are still 32-bit?

The reason why x86-64 is a win is because there are more registers as well. This allows compilers to do a better job.

Marketing Hype

[oringo]

I still don't understand why someone would need a 64-bit workstation/desktop. What does x86-64 offer you other than the higher price tag? True, AMD-64 rocks in Intel's face, but the performance is gained through a direct memory interface, not by going 64-bit. The tests from TFA shows no difference between running 64-bit and 32-bit applications. If I were to own a x86-64 machine, I bet I'd turn off the 64-bit function to reduce the complexity of running applications.

Re:Marketing Hype

[Chirs]

When running in 64-bit mode you have a cleaner API with more registers. Compiler writers and low-level developers like this.

In addition, the kernel can provide the full 4GB of virtual address to userspace apps without having to resort to performance-robbing kludges.

Once you switch to 64-bit userspace apps with their huge virtual address space you can also do things like mmap() your entire 500GB disk and manipulate it as though it's all in memory.

The end user might not notice a lot but it's much nicer for coders.

Better solution than Linux?

[00_NOP]

As I understand it, most users of a 64 bit Linux kernel are using a 32 bit (GNU? I want to avoid a religous war :)) userland, whereas this suggests Windows users can mix and match.
Is there a Linux equivalent available?
Having said all that I well remember getting MS to agree with me that there was a bug in their Win32 bolt on for Win16 that meant my software wouldn't run, but they then said they wouldn't fix it! No wonder I eventually switched to Linux... but that'sa whole other story.

Re:Better solution than Linux?

[nukem996]

Im on a 64bit system now. Every open source app that I use has been ported to 64bit. The few 32bit apps that I have run fine in a 64bit environment, all I have to do is make sure I have 32bit libs availible for them. Recent versions of gcc and glibc offer the ablity to do this without any trouble at all. The User Land 32bit was when the AMD64 CPU first came out but things have changed.

Re:Better solution than Linux?

[poopdeville]

Of course he is.

Re:Better solution than Linux?

[WhiteWolf666]

Windows has the same 32-bit cruft.

With 32-bit apps, you need a 32-bit userland. That's the WoW64 bit; it's the 32-bit Windows on Windows cruft.

The main difference is that the linux stuff is organized differently. lib is your 32-bit libraries, while lib64 is your 64-bit stuff.

On Windows, the 'normal' location is where you would find the 64-bit libraries, and the WoW64 stuff is loaded from a separate directory.

Implementation details: http://msdn.microsoft.com/library/default.asp?url= /library/en-us/win64/win64/wow64_implementation_de tails.asp

Select Quote:
The WOW64 emulator runs in user mode, provides an interface between the 32-bit version of Ntdll.dll and the kernel of the processor, and it intercepts kernel calls. The emulator consists of the following DLLs:
Wow64.dll provides the core emulation infrastructure and the thunks for the Ntoskrnl.exe entry-point functions.
Wow64Win.dll provides thunks for the Win32k.sys entry-point functions.
Wow64Cpu.dll provides x86 instruction emulation on Itanium processors. It executes mode-switch instructions on the processor. This DLL is not necessary for x64 processors because they execute x86-32 instructions at full clock speed.
Along with the 64-bit version of Ntdll.dll, these are the only 64-bit binaries that can be loaded into a 32-bit process.
At startup, Wow64.dll loads the x86 version of Ntdll.dll and runs its initialization code, which loads all necessary 32-bit DLLs. Almost all 32-bit DLLs are unmodified copies of 32-bit Windows binaries. However, some of these DLLs are written to behave differently on WOW64 than they do on 32-bit Windows, usually because they share memory with 64-bit system components. All user mode address space above the 32-bit limits (2 GB for most applications, 4 GB for applications marked with the IMAGE_FILE_LARGE_ADDRESS_AWARE flag in the image header) is reserved by the system.

It's a different methodolgy, but most likely one that works as well. I appreciate the Linux one better-- the "normal" 32-bit stuff lives in the "normal" places-- that way, you don't *need* an emulation layer for the 64-bit unaware apps. Rather, 64-bit aware apps know to look in the correct location for the libraries (well, they are told by the OS, anyways). The Linux Way (TM) is slightly more backward compatible, me thinks. You'll *never* experience a problem with a 32-bit app on a 64-bit linux system, while there are some bugs in WoW64 which will probably never be fixed, rather, they'll be 'phased out', in the usual MS fashion (ignored until irrelevant).

Information on the Linux approach is here: http://www.hp.com/workstations/pws/linux/faq.html
Mainly, when recompiling your apps to be native 64-bit, you need to observe the following:
Simple. Just rebuild from scratch and the compiler will build 64-bit by default. This is true for most apps. However, some apps must be made 64-bit clean which means that the developers must review the code to get rid of any assumptions about 32-bitness, such pointer arithmetic issues. Some makefiles that explicitly declare paths such as /lib, /usr/lib and /usr/X11R6/lib might need to be changed to append "64".

Re:Better solution than Linux?

[WhiteWolf666]

Hmm... you're right, and I can't find much information about it.

Here's what Gentoo says about it, but there really isn't much detail:
Are 32bit applications supported? Is it through emulation or native?

Yes, 32bit applications are fully supported by the CPU, and are executed natively. A standard x86 OS can be installed on an amd64 processor, and can execute 32bit applications from a 64bit operating system if it is capable of mapping the 32bit syscalls to the kernel's 64bit interfaces (such as Linux is capable of doing if you enable it in the kernel). Please see the below section on 32bit support for further information. Please also note there is no performance penalty for running 32bit apps on an amd64 class processor, and will always be faster than the athlonxp line of processors running 32bit code (please note this is different than ia64 itanium processors!)

That's from here http://www.gentoo.org/proj/en/base/amd64/technotes /index.xml?part=1&chap=2

I think if we want to know more about it we have to go stare at the kernel source, and I know that'll confuse me ;-)

I'm wondering how it compares in complexity to WoW64

And another change in marching orders:

[MrAnnoyanceToYou]

16TB addressable VM Space should be enough for ANYONE.

Good deal

[gkozlyk]

Windows 64 seems to be a good deal. From the benchmarks I looked at, i get the same, if not worse performance than the 32-bloat version. Not bad for $140US.

Standard phallacy

[vlad_petric]

The main performance gain from going to x86-64 does not come from larger operands and larger addressing space. It comes from a cleaned-up instruction set architecture and, most importantly, from a larger set of registers. x86-64 has 16 general-purpose registers whereas x86-32 arguably has about 7 GPRs. For x86-32, a compiler generally allocates 2 or at most 3 registers to variables. For x86-64, it can utilize ~12. This greatly reduces the number of loads and stores to the stack. The performance gain comes from the fact that it's much faster to communicate via a register than through memory.

BTW, I don't know about windoze, but in the Linux world going from 32 bits to 64 bits almost always seems to produce a performance gain of 10->20%. I personally tried a simulator I'm using with 64 bits (recompiled with gcc), and got a speedup of 12%.

Re:Standard phallacy

[Elwood P Dowd]

"phallacy"? Is that like when you say it's 7 inches but you know damn well it's 5?

whew!

[Sebastopol]

Boy am I glad all the marketing hype helped make 64-bits a reality! Whew, I can sleep now.

Architecture change

[fjf33]

From what I've been able to understand from other people that know a lot about this than me. The main gain in going from the classic 32bit x86 architecture to the AMD64/x86-64 is that they bring into play some of the things learned from the RISC architecture. Lots of registers that can be used instead of the much slower main memory. The speed comes not from the 64bit wide bus but from being able to use this very fast registers to hold and pass information. So until compilers optimize for using registers instead of the stack, then little will be gained except for higher memory requirements.

Re:Architecture change

[Krach42]

The problem is that it's architected registers.

The "coolest" thing that you can actually do in x86 is called memory value forwarding. (Or something like that).

Basically, you assign an internal register to cache the value of the memory access in an unarchitected register. This means that you can write some code like:

    ROR [mem], 1
    ADD [mem], 2
    ROL [mem], 1

And it will go faster than:

    MOV reg, [mem]
    ROR reg, 1
    ADD reg, 2
    ROL reg, 1
    MOV [mem], reg

This has been true since the 486. (because that's where I learned that, sometimes, it's just not worth putting it into a register on the x86.)

"Limited registers" and "more load/store" are partially informed reasons why x86-64 is faster than x86-32. But in actual truth, it's in "smaller bottleneck for describing dependencies amoung register values."

The Pentium4 has a ton of GPRs. You just can only access 8 of them at a time. Now, you can access 16 of them at a time. This means better dependency description. Not to "you can keep more in registers than in memory".

Microsoft recommends other operating systems

[serano]

A few months ago I bought a new AMD 64-bit processor and mother board. I installed XP Professional 64-bit edition, but the wireless MS mouse and keyboard I had wouldn't work. I couldn't find 64-bit drivers anywhere on MS's site, so I gave them a call. The person on the phone told me the keyboard and mouse wouldn't work with XP 64 and suggested I try another operating system. I asked if she recommmended Red Hat or Gentoo, but she just said, "No comment. Is there anything I can help you with?"

Not in these apps

[mobby_6kl]

None of thes programs they tested showed any significant difference, but scientific benchmarks seem to show significant improvement. Much smaller, but still detectable improvement in xvid/divx encoding. The 64-bit version of CINEMA 4D also benefits significantly in most cases (page 11).

Good to see them drop the old cruft... not quite

[HishamMuhammad]

A 32-bit application that has any remaining 16-bit code won't run, because WOW64 doesn't support any 16-bit code.

Hooray, it's about time. Further in the same paragraph:

"Program Files" is reserved for 64-bit apps, while "Program Files (x86)" is for 32-bit software. This will sometimes result in strange installer behavior, as with Steam, Valve Software's game download application. Steam insisted that the parentheses in "Program Files (x86)" were illegal characters, and refused to install. You can either install Steam into a different folder (e.g., \games\valve) or change the folder name in the installer to "Progra~2\valve".

Some things never change... ;)

Sad to say

[jmoo]

I've been messing around with Windows long enough to remember the 16bit to 32bit application jump made many years ago (When Windows NT 3.1 came out). A lot of the same stuff was said, lack of 32bit apps, huge memory requirements (32 MB of memory!), poor driver support (not that 16bit windows was a lot better). Windows on Windows is nothing new, you still use WOW32 when access a 16bit app in XP.

Re:performance difference

[JonLatane]

"Dual core" and "dual processor" are two very different things.

I'm taking a big risk by asking this..

[markass530]

but I figure this is the only place I can get a good answer. I was just getting into computers during the 16-32 bit shift, windows 95 etc. (I was 14) How come a new proccesor wasn't required like now? Whats the difference? No need for complete laymans terms, as I consider myself a pretty avid comptuer geek, but certainly no engineer.

Re:I'm taking a big risk by asking this..

[redfieldp]

Intel x86 processors were already 32-bit as of the 386 processor. Therefore, when Windows went 32-bit, all the processors out there were already 32 bit. By contrast, until now all Intel and AMD processors have been 32 bit, with the only 64-bit processors being made by other smaller vendors. Therefore, the processor/OS upgrades are simply closer together this time, and it is more apparent. However, as another poster noted: the same driver/incompatibility issues were present when Windows went 32-bit, it was just that no one had to upgrade their hardware.

Re:I'm taking a big risk by asking this..

[ZenShadow]

That's largely due to the fact that when the 32-bit OS shift happened, most people already had 32-bit processors in their systems.

I'd expect much the same thing to happen here. Microsoft will wait for proliferation of AMD64/EM64T chips before they make a strong push to 64-bit Windows. I'm actually surprised they've released it at all, personally...

--S

Re:I'm taking a big risk by asking this..

[canadiangoose]

A new processor was required for the shift from 16-bits to 32-bits, but you may not have noticed because the processors came out well before the microsoft software that was available to support them.

The first x86 processor to feature 32-bit registers and addressing was the i386 released in 1985. Support for the new 32-bit features of the chip was added to Windows slowly starting with Windows 2.1 in 1987(also known as Windows/386), and provided support for virtual memory and somewhat improved multitasking. The 32-bit features in Windows were optional right through to Windows 3.1 in 1992, infact Win3.1 runs fairly well on a 286/AT with 2MB of memory. Although Windows included some 32-bit code as early as 1987, it did not provide a 32-bit API for applications until the introduction of the Win32 API with Windows NT 3.1 (1993) and Windows 95. There was also a free update released for Windows 3.1 called Win32s that provided a subset of the Win32 API for Windows 3.1 amd Windows for Workgroups 3.11, though it provided rather poor compatibility; major features like comctl32.dll and a real registry were not provided.

The first version of Windows to offer a complete 32-bit kernel and drivers was Windows NT 3.1. It provided proper support for the 32-bit funtionality as early as 1993, but it was not used much outside of a corporate environment. Home users had to wait for Windows 95, 10 frickin' years after the release of the 386!!! Even then, Windows 95 still contained a large ammount of 16-bit code!

Anyhow, I find it funny that people With Athlon64's are complaining about having to wait a year or two for a version of Windows that can make proper use of the processors. At least users now have the option of running 64-bit Linux or BSD, but alternative operating systems for the 386 didn't become available until 1993 with the release of BSD/386 and OS/2 2.0, neither of which were free.

Well, enough of my rambling. Hope that answers your question :)

Re:I'm taking a big risk by asking this..

[Chirs]

Great post. Just a minor nitpick...Linux was released (albeit in a crude form) in 1991.

Coding practices need rethinking...

[mi]

Complex data-structures involve a lot of pointers -- all of which are twice bigger on 64-bit machines. Sometimes, this makes the pointers bigger (or comparable) to the structures themselves.

Most obvious are char * fields. If the string is 8 characters or less, it is cheaper to just store in the structure (and pass by value, where possible).

Considering, that most such strings (and substructures) are malloc-ed (with a couple of pointers worth of malloc's overhead), the case for embedding them becomes even stronger...

Re:Coding practices need rethinking...

[Anpheus]

This has always been true, but here are the problems:

To determine whether or not it's a pointer or a char string, you have to have some bit or set of bits dedicated to a switch.

Well you could say, dedicate the last byte to a true/false value. Then you can't address any memory that corresponds to a string at certain addresses. So if you pick 0x00 then you can't use low memory addresses. If you pick 0xFF you can't use high memory addresses.

If you use the first byte then you can't address any location in memory that, taken mod 256, will equal that value.

So it might seem simple enough but it requires a lot of knowledge about the system in order to make it work right. For example, can you guaruntee that every pointer will be even? If you can, then it's ok to simply declare a string-and-char-pointer-type with least significant bit to be 1 to designate a string within the object.

But can you guaruntee this? Universally? At runtime?

Well you might be able to do this, but can you do it easily? Cleanly? In multiple languages? Suddenly the simplicity becomes a little overwhelming.

Re:Better solution than Linux? NOT!

[troberto]

I have been using a 64-bit userland under Gentoo Linux for over 1 1/2 years. I still have to run some 32 bit apps, like openoffice. It all just works. Of course I have a lot more respect for Gentoo's support ;->

Re:mod down retarded zealot

[Lisandro]

wtf does 'source based' mean? all the stuff you get on a Fedora ISO was compiled at some point.. you just choose the right version (64 bit) and go on your way.

    Means that you download and compile your software packages in-situ instead of waiting for your distro of choice to offer packages precompiled for 64-bits systems. Like the parent poster said, a lot of Linux distro don't offer 64-bit binaries (as of yet), but in a source based distro this is a non issue. Zealot my ass.

Oh dear... parentheses!

[Spy der Mann]

I've had problems installing and / or running apps in directories with parentheses.

And there we go, the MAIN DIRECTORY for storing the program files uses them! Don't they ever learn? We had the same problems when dealing with Program[INSERT BIG UGLY SPACE HERE]Files. Couldn't PROGRAMS work? And look, it's 8 characters long!

Sheesh... (/rant)

Re:Oh dear... parentheses!

[Fulcrum of Evil]

We had the same problems when dealing with Program[INSERT BIG UGLY SPACE HERE]Files. Couldn't PROGRAMS work?

That was kind of the point - forcing programs to deal with spaces forced (some) app developers to deal with spaces generally.

Re:Oh dear... parentheses!

[HermanAB]

Nah, use \BIN for programs - only 3 chars and then we can pretend Windoze is POSIX compliant... ;-)

Re:performance difference

[mrtivo]

Only if you saw them swap machines. That and all the extra noise generated to cool off the extra CPU.

A "new era", no, an incremental improvement

[AHumbleOpinion]

A "new era", no, it's just an incremental improvement. 32- to 64-bit x86 is going to be far less dramatic than 16- to 32-bit.

10 years of support

[Synn]

DEC Alpha's in the mid 90's were 64bit and Linux went through a fairly large push to clean everything up to work with them.

I think that's one of the reasons why everything works so well with AMD64 today under Linux.

Re:10 years of support

[Lucractius]

That and that the AMD64s many many ass kicking improvements owe more than a passing glance to the Alpha, with a significant number of engineers fleeing DEC/Compaq/HP to avoid being layed off, or sold to intel for Itanic, moving to AMD, along with AMD licencing a number of KEY technologies off DEC/Compaq such as the Onboard Memory Controler bus technologies (why the AMD mobos have no southbridge) and the high performance scalability that your seeing in those 4-8 way Opteron Mobos cropping up (though i hasten to say that i dont think this was directly licenced, more, developed using the Licenced tech that came with the Southbridgeless designs and other ALpha based stuff by those DEC/Compaq engineers that moved to AMD)

Re:performance difference

[Creepy]

Dual core and dual processor aren't really all that different. The main difference is that dual core has two CPUs on the same die and therefore has shorter distances to travel to the shared memory cache(s). Yes, there's additional glue and such (stuff like shared registers and even some pipeline chunks), but nothing that's a huge fundamental difference.

    For that matter, dual core processors often report as two separate processors, which potentially would cause Windows user license violations if you used a dual, dual-core setup. I believe Microsoft has found a way to identify dual-core CPUs before this even became an issue, so a 2x2 should be fine, but it was an issue.

    As for the performance numbers for games, I'm not entirely surprised... maybe if games threaded themselves better, but most of the time they don't and that is a waste of an extra CPU (well, ok, some compilers may optimize the code for two CPU use, but I don't think they help much, yet). I would expect performance to be optimal in stuff with lots of independent threads like Web Servers (which usually have many processes running many threads) that don't depend on other hardware (like games, which also are throttled by the GPU).

some debunking here

[vlad_petric]

For the most part, the ISA remains unchanged. True, except that a couple of things that were an incredible PITA (pain in the ass) were removed. For example partial register writes, which caused pipeline stalls because it's not really possible to use renaming when you have a partial write followed quickly by a full read. Some instruction which were nasty to implement were also removed. Finally, while there is still some remains of segmentation in x86-64, it's much simpler than x86-32.

While the x86 ISA leaves you with hardly any registers, Intel and AMD's chips do register renaming to hundreds of hardware registers - register renaming is something that you do to allow you to have the same logical register in flight many times (it basically eliminates WAR and WAW register hazards, leaving just true communication). However, if the compiler doesn't have logical registers to allocate to variables, it has to spill them to the stack ... and since memory is not renamed, it really doesn't matter if you have powerful register renaming.

In reality, going from 7 to 16 GPR's is not nearly the win you might think it is, To get really excited you need to be talking about 32 or 64 registers. Sure, 32 register is definitely better, however ... going from 7 to 16 is a big deal. I've seen experiments (stuff that's not published yet, unfortunately) showing how the number of dynamic stores/loads decreases more sharply from 7 to 16 than from 16 to 32. Feel free to contradict me with some other study, though.

Re:Now that Win can finally run on 64 bit

[DoctorBit]

[pedant] Actually, 128 bits can only address the number of atoms in about a billion (american) metric tons of hydrogen, about the weight of a cubic kilometer of water. (6.023 x 10^26 atoms per kilogram x 10^12 kilograms = 6.023 x 10^38 ~= 2^128). 256 bits could probably address every atom in the universe though. (2^256 ~= 10^77). [/pedant]

Interestingly, (to me, anyway), 64 bits can address almost the number of silicon atoms in a typical silicon chip.

For people scratching their heads...

[Hosiah]

Wondering what the heck good all the extra processing power is good for? Because you may play games, compile apps, or even brute-force-crack your favorite target server, but there's one place where you're *guaranteed* to want faster hardware: generating 3D ray-traced graphics!

Yes, I played the Sims, compiled gcc, ran Python chatterbots, had KDE in maximum eye-candy-mode and ran multiple processes in desktops 1-10, but the day I began trying to render a scene with transparent height-fields and looped ISOsurfaces and detailed meshes with fog media and twin area lamps is the day I discovered a new definition of "hardware performance"!

No

[vlad_petric]

I believe that's called marketing.

Re:performance difference

[Anonymous Coward]

Wrong. At least in Athlon 64, both cores have independent 512K or 1MB L2 caches, NOT SHARED. They do, however, share the 128-bit channel to memory.

I work with both dual processor and dual core Athlon 64 / Opteron systems and in terms of performance at the same clock speed and memory timing, there isn't much difference. If anything, the dual core is faster.

By the way, since when does a tight loop lock up a machine? That thread would have 100% CPU utilization, but you can certainly context switch to a higher or equal priority task. Maybe Windows doesn't work that way (?), but I've never had this problem on my Linux box.

Another Slashdot Classic

[BarryNorton]

Terrible summary of a meaningless article

Worth switching if you are...

[Mondor]

What really makes this 64-bit edition interesting, is the amount of RAM that is available for user. As you know, the 32-bit edition supports up to 4Gb which is not even nearly needful for most appliances, including hard 3D gaming, but may be insufficient (in some rare cases) for things like video and multimedia edit. Probably 128Gb, supported by 64-bit edition is a key feature for multimedia designers for making a switch decision.