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

[Martix]

lets see now 1 core for Vista 2nd core for Spyware. Extra processor needed for apps 1 core for apps and the 2nd for anti virus, adaware removers ect

Re:Biggest Benefit

[syousef]

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.

The spyware companies all SAY they won't touch the second core now, and they may stick to it for a little while, but that's so that when you buy 2 cores, they have twice the zombie power per PC at your expense!!!

Re:Biggest Benefit

[Wocko]

AKA the "hard" core.

Re:Biggest Benefit

[Bega]

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

performance difference

[mytho]

I noticed some recent changes of software vendors pushing along 64 bit platforms. Don't know if the bare paower is ready to be fed to home users, but i'm pretty convinced that a new are of computing power is happening

Re:performance difference

[Anonymous Coward]

Particularly the 64bit spell checker.

Re:performance difference

[JonLatane]

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

Re:performance difference

[NanoGator]

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

Is there a practical difference between the two? I mean, if I sat down and used a dual processor machine for a day, then somebody magically swapped it for a dual core machine the next day, would I notice?

Re:performance difference

[mrtivo]

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

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

Re:performance difference

[KillShill]

one of them is economical and the other is not.

that about sums about the differences, at least in amd's lineup.

intel's is like 2 cpus with the power of 1.5 (and that's being generous).

where on earth did you get the idea that "core" meant anything other than "processor"?

it's just two processors on one die (package).

Re:performance difference

[Tony Hoyle]

Depends on whether they share L2 cache or not... the Intel dual core hasn't been released yet so we don't know whether they are.

If the cache is shared then dual core will suffer the same problems as hyperthreading - actually making the processor slower for many tasks.

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.

Re:performance difference

[Ernesto Alvarez]

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.

He does not mean a true lock up. He probably meant that the interface slowed to the point of making it almost unuseable (you can eventually gain control, but it takes a lot of patience). I have a single processor at work (W2k) and whenever that happens, it is a royal pain in the ass. At home I have two cores (dual athlon MP) and I barely notice anything when it happens, and when I do, I use the other processor to "convince" it to stop messsing around (SIGKILL does wonders).

Granted, you don't feel that so hard with linux (no wonder I use it at home, same for most unices I guess), but that effect can make a windows system a very unpleasant place to work.
I've seen it at home though (looks like the SBLive driver installer does not like multiprocessors), and in that case (using w2k) you still keep the system under control.

I'd take a machine with two slower processors (or a dual core, I guess) than one with a fast one anytime. Dual processors are really "smooth" machines.

Re:performance difference

[fitten]

If the cache is shared then dual core will suffer the same problems as hyperthreading - actually making the processor slower for many tasks.

And making some other tasks a bit faster... multithreaded/multiprocess apps that share data heavily won't have to pay as high a penalty with all the MOESI traffic.

Also, a shared L2 cache when only one CPU is really doing much means that most of the L2 can be used by it exclusively. Instead of two 1M L2 caches, for example, with one of those being almost not used at all, then you have one shared 2M L2 cache. Also, in the case of more agressive power management, one of the cores may be shut down and then you actually have one core with a 2M L2 cache instead of one core with a 1M L2 cache and the other one being asleep.

There are many advantages to having shared L2 cache as well as some penalties. On the whole, a shared L2 among the cores is considered the superior solution over seperate L2s per core.

Re:performance difference

[fitten]

the Intel dual core hasn't been released yet so we don't know whether they are

Actually, it was released a while back and you can buy them from Dell. And don't follow up this post with some fanboi crap about not being "true" dual core. There are two cores on the single piece of silicon for both the AMD and Intel dual core parts. That is all that is required to be "dual core". Anything else is just fanbois trying to somehow diffrentiate AMD and Intel and make themselves feel proud (while showing their complete ignorance to anyone who knows anything about CPUs).

For the record, I have a friend who has a Dell dual core machine. I plan to buy an AMD dual core machine (in upgrade parts) for Christmas.

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.

[Krach42]

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.

Very telling, in fact, I think you'll find that the 16-32bit shift only helped in applications that were extremely memory consuming for their time.

Odd thing is, it's about 2^16 times easier to exhaust a 16-bit memory address space than it is a 32-bit memory address space.

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.

[drgonzo59]

...as soon as that can be harnessed by the application programmers and compilers. Right now that is still not the case for most programs out there.

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

[ZenShadow]

Actually, any 64-bit compiler will automatically use the additional registers. Any compiler that doesn't is just plain stupid. If MSVC doesn't generate good 64-bit code, then use gcc or even icc.

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

--S

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

[Surt]

Games need a couple of things that 64bit can provide:

64bit operations - there are a lot of places where you can make use of 64 bit vs 32 bit integers to reduce (halve) the number of instructions you execute. This assumes that your performance is instruction bounded rather than memory bounded, which is sometimes the case.

easier handling of 64bit color formats without conversions

massive memory - games will happily use as much memory as you have, peddling of course to some least common denominator. But if everybody could upgrade their gaming PC's to a terabyte of ram next year for $100, I'll guarantee you there will be games that use that much ram (and use it to great effect) the year after.

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

[Godeke]

An interesting point, but apparently the apps that were recompiled are not doing a great job at doing so. A game would seem to be an excellent candidate for register usage of this nature (they have tight inner loops and more registers means less memory access). Yet, that did not appear to be the result in the case of Far Cry.

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

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

[fshalor]

It's waiting for Vista sp2_64.

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.

[Chris_Jefferson]

Actually, by the time of the 16 -> 32 bit move, most applications were already using more than 16 bits (thats 64K) of memory, by a range of different nasty shifting and overlay methods, and moving to a clean flat address space was really overdue, and something lots of people were desperate to get. If you managed to avoid having to program in that time be very thankful :)

One really nice thing about the 32 -> 64 bit move is with a few exceptions, it looks like we won't have to do any paging and overlay this time, as anyone who wants the bigger address space can already get a 64-bit processor.

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

[dbialac]

I think we should be glad for the simple fact that we didn't take the huge "performance increase" penalty that we took going from 16-bit to 32-bit. Anybody who honestly thought Win95 was faster than Win3.1 must have been smoking meth while using 3.1.

Back then, we were hitting memory ceilings created by the fact that protected mode existed, which was the justification for moving up to 32-bits despite the speed decrease. It's good to see that intel + ms did a much better job of at least keeping things on par for this transition, which outside of the Server and extreme gaming arenas seems a bit unnecessary.

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.

[ZenShadow]

There are two areas I can think of where this matters greatly -- one is calling conventions as you point out, and the other is register allocation when dealing with code in general (sorry for the imprecise description of the latter, I'm not a compiler guy :-).

In other words, if I have eight 32-bit counter variables used heavily in a short block of code, The AMD64 version should be able to stick them all in regsters and use them. If it's using the IA32 register allocation algorithm though, they'd end up getting swapped around a lot in four or fewer registers.

I'm not saying that MSVC has the latter problem (and in fact I can't imagine that it would), but that's more what I was asking about. :-)

--S

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

[kesuki]

linux etc. have been working on being 'ready' for 64-bit systems for a while now, and many programs are written so that the compiler can adjust the code to work better when compliled as optomized for a certain cpu etc, as another poster mentioned here Linux apps tend to get a good boost when recomplied for 64-bit, just from the compiler options being given at compile time. admitedly 10-15% isn't that 'huge' a gap but the code executable was only tweaked as much as the gcc could do so without the code being written specifically for 64-bit cpus.

So yeah, I'd have to agree, these synthetic benchmarks are pretty useless other than to say 'amd-64 cpus have a really good 32-bit mode.' which is not really that big of news ;) Also, it's pretty hard to write an app for 64-bit that Won't slow down terribly on 32-bit machines.

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

[ultranova]

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

More likely those tight inner loops are optimized for the current amount of registers, so if they need to access the same address several times per frame they do all the accesses in the row, so they don't need to move it to and from a register.

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.

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

[JPriest]

With being 64 bit it also requires much more RAM. So if you load your system with 2x as much RAM, and an equally clocked 64 bit CPU you will get exactly the same performance as long as your 64 bit drivers are good enough.

Currently the most significant gain for this change is in marketing.

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

[Krach42]

But now-a-days the data bus line is not related to the size of the computing word.

CPUs request data in cache-line sizes, and not in word-sizes. Since the CPU is requesting in cache-line sizes, then having a bus wide enough to transport the cache-line will make things faster, anything else expects waste.

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

[Krach42]

Actually, I did deal with program in the 16-bit segement 16-bit address space day and age, also with the interaction with EMS, copying data in and out of it like a secondary store.

Unlike most kids I had fun as a child. If by fun you mean, drilling holes in my head by dealing with braindead architectures.

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

[Hal_Porter]

Yeah, no one would be stupid enough to do a nasty paging scheme to get more than 4GB on a 32 bit system ;-)

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

[Hal_Porter]

64bit operations - there are a lot of places where you can make use of 64 bit vs 32 bit integers to reduce (halve) the number of instructions you execute. This assumes that your performance is instruction bounded rather than memory bounded, which is sometimes the case.

Not sure that many real applications are limited by instruction fetches to be honest. I'm sure you find some pathological cases, but not many.

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

[Vladimir]

One thing people seems to forget is mmap(). When you can mmap your 1TB drive into the address space you can do many things much cleaner/more efficient. For example, GNU grep supports "--mmap" flag that sometimes produces a significant performance boost.

Second, 64bit CPU, hopefully, means death of 32bit filesizes because of lazy programmers. 2^64 bytes should be enough for everybody! It's also good that in 64 bit mode AMD/Intel are not slower -- that would be a major roadblock in their acceptance (though Nocona was slower than Northwood, yet people ate that)

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

[_Shorty-dammit]

I believe you meant to say "assembly" and not "assembler," as an assembler is to assembly code what a compiler is to C code. You write assembly code. You use an assembler to get your binaries.

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

[Nefarious Wheel]

More useful to the OS than apps, I'd think. Extra registers would be more useful the more processes and threads you had to support -- anything that needs a context switch would be faster if you could cache register sets that define the context in the registers themselves, rather than having to swap the register data in from slower RAM or (shudder) disk. So a good test might be to compare how the two architectures could handle massive numbers of processes and threads. More registers would favor a Citrix server over a game, perhaps. More a matter of the right usage profile than a footrace?

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

[garylian]

The bottom line is, most coding isn't very pretty, nor is it designed for speed, unless it is specifically done for high end graphics/gaming.

I think that beauty of Assembly has been essentially lost for most development shops.

Lord knows, programming in Assembly/machine language is brutally hard on a developer. It must have been the hardest class I ever took, outside of some of the higher maths.

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

[Dwonis]

Ever try mmap()ing a file over NFS? Always have a Plan B.

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

[Stevyn]

About the 16->32 shift, if I remember correctly (I was young at the time) wasn't that pretty much everyone already had a 486 or a pentium and windows 95 was coming out?

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

[ZenShadow]

In IA32, task switching is supported at the hardware level with the TSS (task state segment). When a context switch occurs, the registers and whatnot are automatically copies to the TSS, and a new task's TSS is copied in. Point being, *all* of the registers are changed after a task switch. End result, additional registers are actually a burden for task switching rather than a benefit.

Unless I'm misunderstanding your point. :-)

I'm pretty sure that the hardware task management stuff has changed drastically under AMD64, and if someone can clarify this it would be useful info...

--S

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

[tabrisnet]

No, you cannot do this. Otherwise you would have a kernel->userspace information leak. Any/all registers are accessible to an application when it is running. Additionally, it has the potential to cause data corruption. Thus it is that registers are saved and restored on context-switches, plus-or-minus the returns from syscalls of course.

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

[GotenXiao]

AMD don't make Xeons.

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

[Bloater]

and am64 xeon is one that can interpret amd64 instructions, as opposed to an ia32-only xeon that can only interpret ia32 instructions.

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

[Bloater]

no they don't, but Intel make Xeons that can interpret AMD64 instructions - thus being amd64 xeons - just like AMD make "Intel Architecture 32bit" only Athlons and Semprons. I'm not sure if they're available for sale though.

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

[Bert64]

I believe gcc requires a flag (-mregparm?) in order to do that, it won`t do it by default.. But maybe that's been changed for amd64

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

[Bert64]

Or worse performance, because your memory bandwidth doesn`t change despite the fact that you now have to transfer twice as much data.
That`s why most 64bit machines run most of their apps as 32bit (sparc, mips etc)

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

[Mr Z]

Technically the 64-bit Xeons are EM64T, which isn't precisely x86-64, but close enough. (Just like a 32-bit Athlon isn't precisely the same as a Pentium 4, even at the instruction set level, but it's close enough to run nearly all the same code.)

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

[Mr Z]

People keep mentioning register renaming, and that helps to a point. Mainly it enables out-of-order instruction issue and retirement. The problem is, many functions need more than 8 values "live" simultaneously. Any that do not fit in registers get spilled to the stack. Once on the stack, these values become memory operands as opposed to register operands.

Memory operands are not candidates for register renaming, typically. Thus, code with a large number of "temporaries" will benefit greatly from the increased number of explicit registers. Boring "control code" won't notice much of a difference. Tight compute loops and large, complex functions will.

Unfortunately, it'll be hard to gauge what the impact is, because in parallel we've doubled the size of pointers, thus increasing the memory footprint of the application. Grumble, grumble. That will work against performance.

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

[Bloater]

fraid not, but you'll probably be able to find it on lkml archives.

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

[Surt]

Very few, indeed, though its not just instruction fetch, but execution that is the bounding case. If you're executing in cache, you can plow through a lot more instructions than if your working set includes the memory subsystem.

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

[Mr Z]

Errr... memory footprint doesn't double. Only the size of a pointer doubles in the currently accepted ABIs. So, your memory footprint increases a little but not dramatically. A byte's a byte. GIFs, JPEGs, MP3s, 3-D textures, Word documents... they all take up the same amount of space on a 64-bit machine as they do on a 32-bit machine.

The currently accepted x86-64 ABI is something called "LLP64," which means long long and pointers are 64 bit, whereas int and long are both 32 bit. Here's a handy page describing LLP64 and some alternatives.

The main advantage of 64 bits is large addressable space. If your working set is below 2GB, you won't benefit from that. The main advantage of x86-64 is the larger addressable register file, and that's completely separate of its 64-bit address space.

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

[Mr Z]

Oops, I misspoke. x86-64's ABI is LP64, not LLP64. I just ran this test program:

#include <stdio.h>
main()
{
printf("sizeof(char) = %d\n", sizeof(char));
printf("sizeof(short) = %d\n", sizeof(short));
printf("sizeof(int) = %d\n", sizeof(int));
printf("sizeof(long) = %d\n", sizeof(long));
printf("sizeof(long long) = %d\n", sizeof(long long));
printf("sizeof(void*) = %d\n", sizeof(void*));
return 0;
}

On my dual Opteron 246 system, it prints out:

sizeof(char) = 1
sizeof(short) = 2
sizeof(int) = 4
sizeof(long) = 8
sizeof(long long) = 8
sizeof(void*) = 8

Ignore the crummy formatting... that's Slashdot's fault.

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

[Mr Z]

You actually pass the point of diminishing returns at a size somewhat smaller than a cache line typically unless you can deeply pipeline commands. In a lot of cases, latency matters most, so that limits the chip's ability to pipeline commands. At some point going wider on your external bus is a waste. It complicates too many things at the board level also.

That's why you see processors with L2 line sizes in the 64-byte to 128-byte range, but external busses in the 64-bit to 128-bit range--a ratio that ranges from 4:1 to 16:1 depending on the exact combination.

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

[straybullets]

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)

But all the real unices and cpu already are 64 bit, so if you need such a thing chances are that you are runing some commercial Unix and dedicated hardware to deal with it .

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

[default luser]

The 64-bit version of Far Cry was intended to give increased detail while still delivering similar performance to the 32-bit version.

There are more objects on maps, increased geometric complexity, improved effects, and the view distance has been increased. These are all typically CPU-limited performance barriers. See the [H]ardOCP review to get a feel for what 64-bit brings to the party. It's not an AMAZING improvement, but it is significant.

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

[GotenXiao]

There is no such architecture as AMD64. If you mean x86_64, use its proper name. Additionally, AMD make x86 CPUs. Intel make pseudo x86, IA32 CPUs (pseduo because it no longer is the same as the x86 architecture).

Interestingly, my Athlon64 runs an old, OLD game called Tyrian. A Pentium I runs it. Yet a P4 doesn't. Strange.

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

[Krach42]

Except that every access to memory hits an enitre cache-line. I don't doubt that the external bus is not the entire cache-line wide.

But every access to memory does extract a whole cache-line (or at least more than a single data-bus size connection) at a time. Otherwise you eliminate the relevance of proximity, which is one of the two reasons that cache is useful.

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

[Krach42]

http://www.digit-life.com/articles2/cpu/rmma-p4-la tency.html

Adjacent Cache Line Prefetch (Enabled/Disabled) - to enable/disable the adjacent cache line prefetch mode. When disabled, only one 64 byte line from the 128 byte sector is prefetched (which contains the requested data). When enabled - both lines are prefetched no matter whether they have or have not the requested data.

Wow, it's almost like they're saying that it grabs 64 bytes at a time. And on most production hardware, in fact, the entire 128 byte sector at a time.

Well, not all at one time, they have to break it up to go over the data bus...

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

[caspper69]

Very late post, but no modern operating system uses the hardware based TSS mechanism for task switching. One TSS for each privilege level is required, but software switching of only the required values is much faster than invoking a hardware TSS switch (too much is saved that is not necessary). Further, software based swapping of the TSS is so much faster that Intel and AMD stopped optimizing hardware task switching ages ago. In fact, in long mode (64-bit) you MUST use software switching. The TSS structure is still provided, but you have to patch it using software.

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

[Mr Z]

You're forgetting that the line fill comes "critical word first" on many systems. Once the first word arrives (e.g. the word that the CPU tried to access and which caused a cache miss), the CPU can unstall and proceed as the rest of the cache line arrives in the background. That's why there's such a quick drop off in marginal benefit as you make your bus wider.

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

[Krach42]

But my point is that a 64-bit machine won't have a larger bus than a 32-bit machine.

The 32-bit machine is already transfering at 64-bit or 128-bit.

The original poster was arguing that you would gain speed by the increased bus size. I'm saying, no, because the word size of the computer hasn't been strongly connected to the data-bus from the CPU to memory since the first days of cache.

I'll agree with you (and never did argue) that the memory accesses aren't happening in a critical-word-first order, and that the bus size is not the same size as the cache-line. (I may have incorrectly stated that to begin with, but I didn't argue the point, because I was wrong.)

But the data-bus size and the word size of the computer are most definitly not linked in modern computers, and there's no reason to think that there would be a speed increase for a wider data bus.

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

Re:Why doesn't the submitter do this?

[anti-trojan]

That's why it would be handy if browsers (or a Firefox plugin maybe?) supported a way to include referrer information in the url, such as:

http://www.extremetech.com/print_article2/0,1217,a =159811,00.asp?REFERRER=http://www.extremetech.com /

I know that the example syntax is lame, but you got the point.

Re:Why doesn't the submitter do this?

[Murphy Murph]

Which is more rude?
Slashdotting a server?
Or Slashdotting a server WHILE depriving the host of their ad money?

Re:Why doesn't the submitter do this?

[DeafByBeheading]

Since 90% of slashdotters use adblock, does it really matter?

(Not an adblock user for this reason, although I do let Firefox block popups and I've got Flashblock, 'cause, dammit, you've gotta draw the line somewhere...)

Re:Why doesn't the submitter do this?

[Briareos]

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

Also, the printable version is missing all the benchmark diagrams... :/

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.

Re:After reading the benchmarks...

[vandy1]

s/System/Program/gc. Damn, too early, no coffee yet... :(

Re:After reading the benchmarks...

[Nasarius]

I can only conclude that they made no attempt to use the extra registers.

Of course they didn't. You think these "ExtremeTech" guys have the slightest clue what a register even is?

They tested a whole bunch of 32-bit apps on a 64-bit OS. They found that the 64-bit OS was slightly broken in a couple cases. That's about it.

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.

Re:Marketing Hype

[tayhimself]

I think a point to consider is that in 64-bit mode the Athlon64 is enabling 2x the number of registers. This is why only a few applications (that dont have any reason to be memory limited, but are register limited) get the speedup.

64-bit addressing should be slightly slower than 32-bit addressing because of lower code density so it is not likely to be the cause of speedup.

Of course all these websites are clueless to these things.

Re:Marketing Hype

[Surt]

Assuming you weren't trying to be funny as you were moderated, in 64bit land you can run your 32-bit applications in a more protected way, which can if nothing else, help to increase system stability.

Re:Marketing Hype

[KingEomer]

If we increased the size of the cache to match this, wouldn't it compensate?

Re:Marketing Hype

[EvanED]

It's also possible he was confusing it with ISA. You know, sort of the chip's API.

Re:Marketing Hype

[Zoxed]

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

Geez: you post on Slashdot but you don't know the answer to this. It is obvious that a 64bit processor will run *twice* as fast as a 32bit one.

Re:Marketing Hype

[Carewolf]

You can often optimize yourself out of that by using compiler options. (I am not going to use more than 4GB so just prepend 32bit of zeroes).

Re:Why bother?

[LnxAddct]

Ahh the benefits of having the source to everything on your system.
Regards,
Steve

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?

[Krach42]

Why do you think that people using 64-bit linux are running a 32-bit userland?

They have the source code, you got back, you recompile, you get at 64-bit binary.

Linux is 64-bit kernel and userland.

WINDOWS is 64-bit kernel and device drivers, with 64/32-bit libraries (often time both at the same time) and 32-bit binaries.

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?

[Lisandro]

Not if you use a source-based distro. A friend of mine recently assembled an Athlon64 system using Gentoo and he's in love with the performance.

Re:Better solution than Linux?

[BobaFett]

They have the source code, you got back, you recompile, you get at 64-bit binary.

Try doing that to openoffice. Every distro I've seen so far has only 32-bit office, and that alone drags in a huge train of 32-bit libraries, so you end up with almost a dual install of Gnome. Then there is 64-bit Firefox or Mozilla but it won't load 32-bit shared libraries, so if you want flash or acroread or Real plugins you need 32-bit Mozilla. By the time you're done half the libraries on your system are dual-arch.

Re:Better solution than Linux?

[poopdeville]

Of course he is.

Re:Better solution than Linux?

[ZenShadow]

Gentoo would be 100x better if it had more extensive "build profiles." I'd love to say something like "emerge gnome-system" and have it up and build a full system for me with one command -- inclusive of a decent default USE= setting.

In the mean time, I suffer with 2005.1 and constantly adding packages that should really have been included as dependencies in the gnome meta-package (hal and dbus, anyone?). But it *is* more stable than anything else around, IMHO.

And it is *WAY* faster on AMD64 (although going to a dual-core X2 4200+ from a single-core 3500+ didn't seem to smooth the desktop response at all, which I was surprised at -- but compiles are way nicer now :-).

--S

Re:Better solution than Linux?

[dougmc]

They have the source code, you got back, you recompile, you get at 64-bit binary.

To a degree. Sure, the compiler will create code that only runs on a 64 bit cpu if that's what it's supposed to do, and it may use the extra registers and the like to improve performance, but that doesn't really mean your code is really using 64 bits now.

(Granted, you didn't say it was, but I thought I'd be a bit more explicit.)

For example, if the application did a lot of integer math, and it was programmed to use 32 bit ints, merely recompiling won't make it use 64 bit ints. In theory, merely being able to use 64 bit ints could double the performance of your application right there (because rather than doing two 32 bit operations, it could do just one 64 bit operation), but that's only if your application knows how to do it.

Linux is 64-bit kernel and userland.

`Linux' is a pretty big brush there ...

If you're running an application that's only available in binary form, and was not recompiled in 64 bit more, it'll still be running in 32 bit mode. And if I understand correctly, it won't be able to link against 64 bit libraries, so even your 64-bit only Linux installation might have 32 bit versions of glibc and the like so that you can run applications that were compiled on other (32 bit) systems.

Re:Better solution than Linux?

[Lisandro]

Hey! I use Gentoo, you insensitive clod! :)

Re:Better solution than Linux?

[ZenShadow]

For example, if the application did a lot of integer math, and it was programmed to use 32 bit ints, merely recompiling won't make it use 64 bit ints. In theory, merely being able to use 64 bit ints could double the performance of your application right there (because rather than doing two 32 bit operations, it could do just one 64 bit operation), but that's only if your application knows how to do it.

If you're using gcc's "long long" extension to achieve 64-bitness in 32-bit environments, then recompiling will indeed make your code take advantage of real 64-bitness.

Oh, and longs will automatically become 64-bit as well, so you get a bonus there. Unless you're using them in structures that you're storing directly to disk, in which case you've got work to do. :-)

This pointless message brought to you by my boredom. And now off to bother vendors.

--S

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?

[beeblebrox87]

Openoffice.org2 now compiles natively on amd64. I have a pure 64-bit version running right now, no 32bit libraries required. And why on earth would you want to pollute a nice browser like firefox with flash and acroread?

Re:Better solution than Linux?

[Bastian]

Strange. I would have assumed that Sun, IBM, the Linux/Alpha or Itanium people, someone would have taken the time to port most the major parts of the GNU environment to 64bit by the time X86-64 came out.

Re:Better solution than Linux?

[Hal_Porter]

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

I think you still need to have an emulation layer somewhere. E.g consider a 32 bit application on a 64 bit OS.

Imagine it calls open and passes a 32 bit pointer to a filename as the first argument. If the kernel is 64 bit, someone needs to translate the pointer.

In this case, and probably 99% of the time, this is just a sign or zero extension on the pointer parameters but if you have a function which takes a pointer to a structure containing pointers to other structures, it's much less trivial. But unless you want to have a kernal with two paths, one for 32 bit and one for 64, you have to do the translation somewhere.

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

Re:Better solution than Linux?

[Truekaiser]

*runs gentoo quite happly with out any of those and is still a tad bit faster then any other distro*
why?
it's the use flags not the cflags that give gentoo it's speed.
besides that if a riced up car is gentoo, then debain is that old beat up pinto without seatbelts.
fedora/suse/mandrake(or what ever it is called) is that large suv next door.
and windows is the semi parked in the culdi-sac

Re:Better solution than Linux?

[salimma]

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.

On RPM-based systems, yes. And thanks to RPM's support for multilibs you can actually install standard 32-bit RPMs painlessly.

On Debian-based systems lib is 64-bit, lib32 is 32-bit.

Re:Better solution than Linux?

[KozmoStevnNaut]

You're not helping...

I would rather say that Gentoo is a car than CAN be riced out, but most likely looks like everything else out there, runs at about the same speed and sometimes requires a bit more maintenance. Some people (like me) like the way it works, some people don't.

Debian is more like an 80es 4WD Toyota van; kinda behind on the newest trends, not flashy in any way, but damn reliable, and it'll go just about whereever you want, while still being pretty damn practical.

Oh, and it's "cul de sac", not "culdi-sac"...

Re:Better solution than Linux?

[dougmc]

If you're using gcc's "long long" extension to achieve 64-bitness in 32-bit environments, then recompiling will indeed make your code take advantage of real 64-bitness.

In that case, yes. Perhaps integer math was a poor example. Encryption and compression would be better examples.

Oh, and longs will automatically become 64-bit as well, so you get a bonus there. Unless you're using them in structures that you're storing directly to disk, in which case you've got work to do. :-)

Indeed. And the idea is `just recompile in 64 bit mode, and it'll be faster.' But in this case, it either won't compile, will compile but will crash, or will compile and will run, but will step over itself as it saves data to disk, corrupting it.

Hopefully most of the programs out there, open source at least, are 64 bit friendly by now. Certainly, we've had 64 bit cpus for a long time, it's just that now they're becoming common for PCs.

Of course, just because they're `64 bit friendly', that doesn't mean they take full advantage of a 64 bit cpu.

Re:Better solution than Linux?

[ZenShadow]

I just wish that C(++) would finally ditch the vague type names and go with, say (w)char, (un)signed(8|16|32|64) and so on...

--S

And another change in marching orders:

[MrAnnoyanceToYou]

16TB addressable VM Space should be enough for ANYONE.

Re:And another change in marching orders:

[char1iecha1k]

remember the 2 quote s that bill did not say

"640K ought to be enough for anybody." and "No one will need more than 637 kb of memory for a personal computer."

Re:And another change in marching orders:

[w98]

My favorite, paraphrased, is "We got to the *moon* on 32kb of RAM, and now I need 512MB of RAM just to boot my computer..."

Re:And another change in marching orders:

[smallguy78]

Unless your name is Adobe Photoshop

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.

Re:Good deal

[bach37]

Windows 64 seems to be a good deal.

Until you try to find 64bit drivers for your hardware...

Re:Good deal

[game kid]

Windows 64 seems to be a good deal.

Until you try to find 64bit drivers for your hardware...

Sadly, that jet engine you thought you heard was actually a well-executed (and badly Underrated) joke about Windows' memory requirements soaring past your head.

Mod parent down Redundant, mod grandparent up t3h Insightfulz0r, and have a nice day.

Is it Marketing Hype or just Your Cash?

[WillAffleckUW]

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.

Well, other than addressable memory - got to find some use for those Terabyte flash cards - it's a great excuse to make you pay lots of money for something that's supposedly faster so that you can forget what you really wanted was a faster Gigabit IPv6 Internet that could chop wood faster.

Did I mention you can spend more money? Because too many people have been buying laptops for $399 to $999 instead of the usual $4000, and PCs for $299 to $499 instead of the usual $2000. Have to justify those CEO salaries, don't we?

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?

Re:Standard phallacy

[shmlco]

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

A typical, "yes, but..." is in play here. Additional registers also mean that you have more saves/loads to do on function entry/exit, as well as during thread and process context switches.

Re:Standard phallacy

[X]

For the most part, the ISA remains unchanged, and to the extent that it is improved, it's important to keep in mind that internally neither Intel nor AMD's chips are actually executing x86 code, as it's translated into an internal instruction set. The same can be said for the registers. While the x86 ISA leaves you with hardly any registers, Intel and AMD's chips do register renaming to hundreds of hardware registers.

Sure, there is some overhead in all that translation, and having a broken instruction set does make the job for compilers and CPU's more difficult, no matter what you do, but you'd be surprised at how little impact that has on x86 performance.

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. Even then, because the number of registers in the ISA no longer correspond to registers in the hardware, real performance advantages may not be what they seem.

Re:Standard phallacy

[dedded]

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

Yep, it's the registers. But in the case of AMD, it's also that memory latency is lower due to the integrated northbridge. On memory intensive jobs, it matters.

Re:Standard phallacy

[dpilot]

So maybe this answers a question I'll be asking in the next several weeks. I'm looking at building a new system, and at the moment am thinking Athlon-64, socket 939, PCI-Express. At the moment, it would be Linux-only, most likely Gentoo.

So am I better off with:
CHOST="i686-pc-linux-gnu"
or:
CHOST="x86_64-pc-linux-gnu"

To be honest, I'm note really going to push the memory requirements or anything else. It's just that it's a faster 32-bit machine, plus has more inches, length *and* girth. Plus it's something fun to fool with.

Re:Standard phallacy

[atrus]

I run a Gentoo x86_64 system. Its a nice machine to develop on. Only downsides are using 32bit binaries: i.e. Flash and win32codecs.

Re:Standard phallacy

[jizmonkey]

A typical, "yes, but..." is in play here. Additional registers also mean that you have more saves/loads to do on function entry/exit, as well as during thread and process context switches.

You only need to save and restore the registers you use, so there is zero loss on enter/leave from adding registers. Thread switches (userthreading is dead, even on elder operating systems like Solaris) are relatively infrequent and have huge overhead, so loading and storing eight more registers is a miniscule cost.

Adding registers to x86 is a huge win for code that can use it and doesn't hurt anything else.

Re:Standard phallacy

[shmlco]

"You only need to save and restore the registers you use, so there is zero loss on enter/leave from adding registers."

Well, of course you only have to save the ones you're going to use. But, then again, not using them is just the same as not having them. So, if you DO plan on using them, then the additional stack frame management applies, the overhead of which in turn still reduces the potential performance gain.

Now, if you'd argued instead that the win from having additional registers that in themselves don't need to be continually reloaded and swapped during a function call washes the stack frame overhead, I might have believed you... *grin*

Re:Standard phallacy

[fitten]

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

This depends a lot on how the code was written.... plus gcc is kinda... not that good for optimization so there are any number of things that could be going on.

Anecdotal evidence is garbage. All of the code I write at home I test in 32-bit and 64-bit modes on an Athlon64. Depending on what the code is, I can see anywhere from up to a 20% increase in performance to a 20% decrease in performance.

For example, if the (C) code you are compiling code that has longs all over the place, you've just doubled your cache pressure going to 32-bit. Did your code really mean to use 64-bit ints there? You'd have to look at the code to be sure but many times, C coders just use longs because they are used to it and this will have a possibly unexpected behaviour in 64-bit mode.

Re:Standard phallacy

[fitten]

"cache pressure going to 64-bit from 32-bit" is how that's supposed to read.

Re:Standard phallacy

[fitten]

If you are making it just to play with and just as a general speed bump, I'd suggest going Athlon64 and have fun. If, for some reason, you don't like 64-bit (some apps/drivers don't work right) you can always install the 32-bit version of the OS (any of them) with no penalties. I personally wouldn't use Gentoo but that's a whole 'nother topic :)

Re:Standard phallacy

[dpilot]

What's wrong with that?
Is it a bit of a pain to set up, or impossible?
This system is also destined to be a MythTV back-end.

Re:Standard phallacy

[pato101]

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

I fully support that. I'm a happy ubuntu64 user. I'll never buy a 32bit CPU anymore. I've tested my AMD64 in crunching numbers and it is about 15% faster when compiling the code in 64bit respect 32bit (Fortran90 code with PGI compiler checked). Also, AMD64 performs much better than P-IV - specially when I access more than 1Gb of RAM, but not limited to that case.

whew!

[Sebastopol]

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

Bridge to Vista

[ackthpt]

My experience, though obviously limited to business applications; is that RedHat runs straight out of the box. Everything, the whole kaboodle: printers, scanners, cameras, flash sticks. Why even consider Windows, it has missed the proverbial boat.

While benchmarks don't show much improvement, it does potentially provide a bridge to Vista, though from what I've been seeing XP to Vista is App..er..Bananas to Oranges. There really does seem to be a slim case for Win64 (there also seems to be a slim case for Vista, however.) So Linux is certainly a fair case to make.

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

[nogginthenog]

Lots of registers has nothing really to do with RISC. x86 is just a shit design!

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

Re:Architecture change

[Jeff DeMaagd]

The number of registers only double to 16 programmer-addressable general registers. Many RISC architectures have 32 or more, some 128.

Re:Architecture change

[lubricated]

ROR KUR5
    IANAL /.
    IIS #$!@
    IIRC ROFL
    ????
    PRFT

Re:Architecture change

[Krach42]

You are definitely someone with too much time on your hands. ;)

But then, I suppose, so am I...

XP 64bit sux go with Linux 64

[nukem996]

While many users have been complaining that Win 64 has little support for their devices and many of their programs are still 32bit this is not the case on Linux. I have been running Linux 64bit for over a year now and have found that everything works with no problem. Every open source apps Ive seen works fine on x86_64 Linux. Infact the only reason why you need 32bit compatiblity on Linux is for closed source software(mainly games). Linux is years ahead of Win and probably any other OS in the 64bit OS area, and its all thanks to it being open source.

Re:XP 64bit sux go with Linux 64

[Timbotronic]

Not trolling - what's your experience been with finding and/or recompiling drivers for x86_64 Linux? I just bought an Acer Ferrari 4000 laptop (awesome machine) which officially supports WinXP x64, so I've got that running fine but the lack of app support at the moment makes it kinda pointless. eg. I'm yet to find a full x64 J2EE Server on Windows.

Re:XP 64bit sux go with Linux 64

[Malc]

I recently built an AMD FX-55 system at work. The 64-bit version of XP was quicker to install and get up and running. No hassles here.

Actually...

[ackthpt]

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.

The spyware will takeover CPU 0, bloat will occupy CPU 1 and your apps will be paged out to a highly fragmented file created by the file system as opposed to a fixed file on a swap partition.

You ought to know that by now.

Re:Actually...

[dgatwood]

Personally, I find it to be much more fun to tune a fish.

Word Count

[Anonymous Coward]

Someone give me the ratio of article text to ad text for those pages.

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?"

Re:Microsoft recommends other operating systems

[GoLGY]

I'd be interested to see how many hardware manafacturers have gone to the effort to providing 64-bit versions of their drivers.

It's clear that obviously some drivers MUST have 64-bit drivers, and even Nvidia have provided a 64-bit set of their drivers, with gamer kiddies driving most of the new hardware blitz these days, but how common is it? And if should driver support for most prepherials is lacking, what is the point of installing XP64 in the first place?

Marginal benefits, but with less hardware support. Doesnt seem like a very good reason to switch, to me.

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

Re:Not in these apps

[illusioned]

If the xvid and divx codecs use ASM to speed things up, and they haven't done optimizations for x86_64, it may just be a matter of them revving up the code to see huge speed gains. I know that on my 64 bit linux box gcc seems a hell of a lot faster then it ever did on 32 bit x86.

Re:Not in these apps

[Krach42]

This likely has to do with a number of nifty factors. For instance with GMP, where you're performing extremely large math. Normally you're stuck with doing something like this:
    MOV32 reg, [src1]
    ADD32 reg, [src2]
    MOV32 [dst], reg
    MOV32 reg, [src1+1]
    ADC32 reg, [src2+1]
    MOV32 [dst+1], reg

Which works nice and all, but it's a ripple carry adder. Ripple carry is SLOW, because you have to wait on definitive resolution of the carry out from one add before you can start with the next add.

On the 64-bit machine, you can take advantage of numerous Carry Look Ahead schemes. Fundamentally, and theoretically, you can break down the carry flag for each bit of the 64-bit add into two levels of logic. No ripple, and both 32-bit adds effectively go through in parallel.

Speed++

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:Sad to say

[HermanAB]

Remember Thunking?

Now that Win can finally run on 64 bit

[WillAffleckUW]

does this mean it's time to start work on 128-bit Linux and Unix?

Hey, I've got to have something to address all the Terabytes in my flash card ...

Re:Now that Win can finally run on 64 bit

[assert(0)]

Not really. Using 128 bits you could address every single atom in the universe, with plenty of bits to spare. We don't need that. Yet...

Re:Now that Win can finally run on 64 bit

[ettlz]

Using 128 bits you could address every single atom in the universe

Well, hey, that's why AtomChip built the 6,8 GHz Quantum Processor!

Re:Now that Win can finally run on 64 bit

[WillAffleckUW]

Not really. Using 128 bits you could address every single atom in the universe, with plenty of bits to spare. We don't need that. Yet...

You mean like we'll never need to use more than 640K of RAM?

I see.

There are the registers to think of, or the very very long words (paragraphs) ...

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.

Re:Now that Win can finally run on 64 bit

[assert(0)]

Looks like you're right. I must've meant 256 bits after all.

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

[Anonymous Coward]

It was, it's called the 386.

However, there were many years between the release of the 32-bit capable 386 and the first mainstream 32bit operating system (Win95). About the same way as AMD64 was released before there was a usable 64-bit (Windows) OS to run on it, although the timespan is shorter this time.

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

[troberto]

It was (i386) but it took almost 10 years for the software to catch up.

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

[Chirs]

Actually there was a new processor required, same as there is now. The Intel 286 was 16-bit, while the 386 was 32-bit. If you wanted a 32-bit system, you needed a 386.

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.

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

[Bent Mind]

I'm actually surprised they've released it at all, personally...

Classic Microsoft development. Back in the Windows 3.1 days, the Apple people would give Microsoft people a lot of flack because Windows ran on top of DOS. They claimed that MacOS was better because it was a real GUI based OS. Windows 95 was Microsoft's answer to the arguement.

It really doesn't suprise me that Microsoft is realeasing a 64-bit Windows now. GNU/Linux has had 64-bit since shortly after AMD released their first 64-bit x86 chip. Most of the Linux people I know haven't been shy about rubbing that fact in Microsoft's face. Linux is currently driving Microsoft development. That's why Microsoft didn't bother with security and stability until the Linux camp started to show them up.

Thinking of the old Apple vs. Microsoft flame wars, and Linux, I still think it's funny that X11 sits on top of a CLI and that it's now considered bad to have the window manager tied directly into the OS. But maybe that has more to do with what you're using the computer for (server vs. workstation).

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

[canadiangoose]

Damn!! I can't believe I missed that! Must remember to stop drinking at work!

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

[ZenShadow]

I agree with most of your post, but just my $0.02 on the last bit:

IMHO the difference between DOS/Win3.1 and *ix/X is vast. Win3.1 attempted to act as the operating environment, not just a windowing system -- the Win16 API had most of the same basic functions as Win32 does today (including File-oriented functions, Network-oriented functions, etc.). X, on the other hand, is *only* a windowing system.

Ironically, I personally think that's a shortcoming of X in some ways. IMHO a new windowing environment needs to be designed that combines at least Graphics/Windowing API, Printing API, Sound API, and probably one or two things I can't think of at the moment. Oh, and it needs to be as configurable by newbies as Windows is (eg. no frigging xorg.conf bull :-).

I imagine we [the Open Source crowd] could build something better than X11 with today's technology if we decided to put our collective intelligence behind it. Hell, it could probably even be X11 backward-compatible. :-)

But I digress...

--S

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

[troberto]

I'm not complaining, I use gentoo.
Ever since I went 64 bit, 1 1/2 years ago.
No Problem.

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

[canadiangoose]

Egad! First someone points out that Linux made it's debut in full 32-bit glory in '91, now you mention the existance of Xenix for 386 in '87!!

I guess I'm ready to have my Geek card revoked. Bummer.

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

[ZenShadow]

How would you propose telling the difference between a an embedded string and a pointer? I can think of a couple of ways, but they're not pretty. :-)

--S

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:Coding practices need rethinking...

[petermgreen]

if you know the granularity of your memory manager you could make the least significan't byte of embedded strings something your memory manager will never give which would still leave you room for 7 characters of text.

Re:Coding practices need rethinking...

[betterthancats]

But the usage of pointers will be relegated to compilers and system programming, since the speed benefit of low-level languages has long been outweighed by high-level language features ... right?

Sure, there are lots of pointers in automatic memory managment, some systems more than others. But you only have to optimize those routines in the compiler/vm.

Or will people keep insisting on writing io/event-bound programs in C.

My program sits in a wait state for 100ms every minute. Thats twice as fast as yours! Look at my elite C-struct programming skills!

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.

I came to the opposite conclusion

[p3d0]

I was impressed that there was practically no degradation when moving from 32-bit to 64 bit. That means there's no real obstacle to adopting 64-bit OSes and apps.

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!

[pookemon]

Couldn't PROGRAMS work?

Nah, use "FILES" - and then put everything in there. ;)

Re:Oh dear... parentheses!

[HermanAB]

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

Re:Oh dear... parentheses!

[level_headed_midwest]

Yeah, Windows handles names really funky. Not case-sensitive, and a bunch of characters not allowed (well, I can understand . \ and $, but why the rest?) I'll even spot them the / vs. \. After using the bash shell under Linux, I feel as if I want to rip my hair out whenever I have to open up cmd.exe on a Windows machine...

Re:Oh dear... parentheses!

[tomas.bjornerback]

Taste this: In the Swedish version of WinXP, the "Program Files" folder is called "Program". Quite a few programs get confused over this... /Tomas

Re:Oh dear... parentheses!

[skryche]

Not to mention... "Program Files"? What else would one expect to find in a directory but files?

The big picture...

[Anonymous Coward]

I think most people hailing 64 bit computing are missing the obvous. You'll need a little more RAM to run equalivent to 32 bits. That's because pointers are platform dependant and on a 32 bit machine they are 32 bits long, and 64 bits on x86-64.

Not that RAM isn't cheap enough today, but when you draw the line, 64 bits doesn't bring anything better to the table if we count out larger address space. Not _really_ worth switching if you don't need that extra RAM (and I doubt most of you do).

Linux 64-bit performance way ahead

[Anonymous Coward]

If you compare various benchmarks you'll see that Linux offer 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.

Re:mod down retarded zealot

[Lisandro]

Are you retarded? It makes it a non-issue because AS OF TODAY, a lot of distros don't have the choice to build 64-bits systems with 64-bits binaries. Sheeze.

    Nice "l33t" speak, by the way.

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.

Re:Not really ...

[Anonymous Coward]

select() just called. It turns out you fail the networking portion of the interview.

Re:Good to see them drop the old cruft... not quit

[GMFTatsujin]

It's nice to see the cruft go away -- until you try to run an app that hasn't been ported since God knows when, and the source isn't avilable for recompilation.

And it's hard to know just which apps have 16 bit code in them sometimes. I hope I'm not upgrading myself into a terrible avalanche of secondary upgrades or "learn-to-live-without-it"-itis.

I want what I've got, just *faster.* What's wrong with that?

Depends.

[jd]

On most OS', there's a way to lock an application's threads to a specific processor. Not sure if Vista supports that, but I'd be surprised if it didn't.

Generally, there's no benefit to locking to (or against) a given core, but if you've one core designated for supervisor operations, you don't want applications to interfere with it. In many-way SMP clusters, you also don't want threads geographically spread too far, or you'll lose performance.

The easy way to fix the problem on OS' that don't support CPU-bound applications is to have more cores than a process can have threads.

Re:Depends.

[Hal_Porter]

SetProcessAffinityMask would do it.

Generally, there's no benefit to locking to (or against) a given core, but if you've one core designated for supervisor operations, you don't want applications to interfere with it. In many-way SMP clusters, you also don't want threads geographically spread too far, or you'll lose performance.

I've seen some embedded systems which lock time critical stuff to one core - you probably have one in your cellphone. Then again, the 'cores' in this case are very different from the main processor - different address space, instruction set and so on.

But for normal desktop stuff on a SMP system, you're better off just letting the kernel do it's stuff with scheduling. You can give it some hints with priority, but locking threads to a CPU is likely to make things worse in the long run - imagine if you have two applications which decide that processor 1 is their 'supervisor' processor and lock all their time critical threads on it. They would have been better off not locking an getting the chance to run the supervisor stuff on any processor.

Re:Depends.

[afidel]

Actually it depends, on the XEON line for example you would want to spread your most cache starved applications to CPU's which are geographically distant (that is on different CPU bus's) due to cache coherency issues.

Re:mod down retarded zealot

[HuguesT]

Personnally I don't mind your compiling of your own software on your own machine, but what you say makes little sense.

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

The parent was specifically mentionning choosing a distribution that does support x86_64.

Of course it is a huge issue even for Gentoo to make sure all the packages on offer are 64-bit clean at the source level. There are plenty of ways for a C/C++ application to not behave properly in a 64-bit environment (assumings ints are the same size as pointers for example).

In other words, yes 64-bit is an issue even for source-based distros.

You like to compile and run the greatest, latest and untested in exchange for a 10% boost in performance, good for you, you are doing the community a service.

Personally I like to change my O/S and its components as little as possible (at least not until I can see a marked gain in functionality), and when I do I like everything to still work like before. I also have a fundamental objection to redoing the compiling work (which does cost electricity, genereates heat, wear and tear, etc) over and over again for very little reason. OK for some packages I really need, never for Gnome/KDE or even the kernel if I can help it.

Each to their own.

Do more registers really help?

[WouldIPutMYRealNameO]

I have seen a lot of people saying that the main performance enhancement in going to x86-64 for most apps is that you have more registers.
While I am the first to agree that the x86 instruction set is register starved, I was under the impression that most modern CPUs implemented register masking (I can't remember the exact term, it could also be banking or caching). I basically thought that the hardware did fancy things to "cache" registers, so that even though it looks like you're having to fetch stuff from the stack - you are infact getting it from a very fast on-die location.

Can anyone familiar with modern x86 guts comment?

Re:Do more registers really help?

[WhiteWolf666]

I believe its called register renaming, but I probably know less on the topic than you.

The limitations of this are described in more depth here http://64.233.179.104/search?q=cache:5mZte35ICdQJ: www.answers.com/topic/register-renaming+limitation s+of+register+renaming&hl=en&client=safari
And here http://arstechnica.com/cpu/03q1/x86-64/x86-64-3.ht ml
And here
http://www.aceshardware.com/Spades/read.php?articl e_id=53
One significant problem is that this process is not transparent to the coder; it's done on the fly, by the processor, with hints from the compiler.

Re:mod down retarded zealot

[Lisandro]

Personally I like to change my O/S and its components as little as possible (at least not until I can see a marked gain in functionality), and when I do I like everything to still work like before. I also have a fundamental objection to redoing the compiling work (which does cost electricity, genereates heat, wear and tear, etc) over and over again for very little reason. OK for some packages I really need, never for Gnome/KDE or even the kernel if I can help it.

    Which is perfectly fine. I'm not trying to plug Gentoo here, even while i like the distro a lot - i just wanted to mention that source-based distros offer the possibility of a 64-bit userland today, even when a lot of "classic" distros doesn't. You can have a Linux system running a 64-bits kernel with 64-bits applications today if you wish so, and source-based distros is a way.

WOW

[DoctorHibbert]

The key to running 32-bit applications is something Microsoft dubs WOW64; WOW stands for Windows on Windows. Running 32-bit apps in x64 essentially gives each application its own 4GB of virtual memory space, which isolates it from other applications. So if one 32-bit application locks up, it only affects its memory space, not other running 32-bit apps.

Isn't this exactly how it works anyway in Win32?

Re:WOW

[WhiteWolf666]

That's what they wanted you to believe. However, shared system processes would often lockup, freezing the system.

Now, 32-bit applications can trip up on bugs in the WoW64 implementation, and since that is intimately tied to the kernel there's *another* thing to break ;-)

bang for the buck

[blib-hiptop]

I assume you meant to say "bang for the cores" surely dual core ships will be quite a bit cheaper than two single core chips.

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:mod down retarded zealot

[Arker]

You like to compile and run the greatest, latest and untested in exchange for a 10% boost in performance, good for you, you are doing the community a service.

Some of us like to compile older stable tried-and-true versions from source so we can get the compile-time options set the way we want them.

You should see how much faster some gui apps are when you eliminate GNOME support. How much smaller your memory footprint is when you remember to strip debugging symbols (which, believe it or not, distributors sometimes don't do) and remove support for features you don't need. And so on...

Simple fact is if you want full control of your system you need to be comfortable with using software, not just plugging in binaries. If you don't want to do that, there are plenty of people out there making generic binaries you can use, and that's fine, but why the hostility towards people that prefer to use software?

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.

Swapfiles

[Nutria]

your apps will be paged out to a highly fragmented file created by the file system as opposed to a fixed file on a swap partition.

You ought to know that by now.

Yet another great reason to use Linux, where the only type of swapfile you can create is contiguous!

Re:Swapfiles

[Nutria]

According to man mkswap, it wants a blocksize of 1024.

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"!

Re:Not really ...

[$RANDOMLUSER]

For those of you who have never used Berzerkley sockets (Now those guys inhaled. A lot. And often) that's really really really funny. Too bad it's posted AC.

Correct.

[jd]

Now, if you were to use multi-way as a form of spyware/virus mitigation, what you'd do is list the processes you definitely want to have free-reign, and then say that everything NOT on that list is confined to one core. Preferably on someone else's machine, but that's a whole different ballgame.

Re:Correct.

[Hal_Porter]

So your machine can be completely infested with spyware and viruses, but at least they only use cycles on one processor?

Re:Correct.

[jd]

It would avoid slowing anything down. And if you could be certain none of it was (a) legit, and (b) supposed to do I/O, then you simply tell the OS that that core isn't to do I/O. The viruses and spyware can do what the hell they like, then.

(Not all "normal" processes do I/O. Garbage collectors and other "housekeeping" processes do no I/O at all. So you don't have to worry if you don't catch these and authorize them - they don't need to run often enough to care if the CPU is busy with viruses, and don't need any capability that you don't want the viruses to have.)

Re:Correct.

[Hal_Porter]

But you could sandbox processes without locking them to a core.

E.g. I read somewhere that Longhorn will do it for Internet Explorer. Threads from it will still run on any core, but they will be have very low security permissions. But that implies that every dangerous API function be tested to make sure that it respects the permissions, or if it depends on something else which respects them, that it handles the error gracefully.

It's actually kind of fascinating in a morbid way to watch them try to secure IE, despite the fact that things like ActiveX are not really designed with security in mind.

So why would be windows performance...

[ratta]

so important while comparing 32bits vs 64bits?

Re:Good to see them drop the old cruft... not quit

[njchick]

XP 64 is also using \windows\system32 for (surprise, surprise) 64-bit utilities. M$ wouldn't be M$ is they used \windows\system64 for that purpose.

32-bit utilities are placed elsewhere, but they are fooled to think they are in \windows\system32.

you touch on the other problem with the move

[petermgreen]

virtual 8086 mode isn't availible any more and although 16 bit protected mode is i don't belive XP 64 supports using it for win16 apps.

so its goodbye to running any dos or win16 apps without using a slow emulator.

Necessary for 8 megapixel movies

[heroine]

64 bit is useful when you want to manipulate 8 megapixel movies in floating point RGB. 64 bit addressing allows those to be manipulated entirely in RAM with no tiling. The improvement is huge and the money saved on tiling engines can be spent on image manipulation.

No

[vlad_petric]

I believe that's called marketing.

Just wait until spyware is multi-threaded

[bigtrike]

I'm sure it won't be too long until most spyware is rewritten to "take advantage" of multiple processor cores.

Linux same story?

[Noodlenose]

So if I wanted to harness the extra bit of speed that a 64-bit processor would theoretically give me, I would either have to use a distro that has binaries precompiled for 64-bit use or use something whacky like Gentoo and combile all my binaries myself?

performance incrase in 3d games???

[Mika24]

i saw a couple frames per second but nothing that can't be achieved with a simple overclocking

64 bit performance

[Anonymous Coward]

Performance obviously not good enough to survive slashdotting...

8cc ?

[jeti]

Maybe you could also use 8 character constants (8cc) like 'NoString'. But the compiler wornings would drive you crazy. ;-)

Another Slashdot Classic

[BarryNorton]

Terrible summary of a meaningless article

amd64 and pentium4 6xx are not 64-bit CPUs

[laan]

I think it's something that we all must have crystal clear, both new x86-64 series are not full 64-bit CPUs, as x86 based are not CISC nor RISC and even not fully 32 bits processors.
New x86-64/em64t cores have 64 bit addressing and for doing so they have 64-bit GPRs but all other registers and operand sizes are still 32-bits.
So from where did the scientific benchmark performance gain come?
Well, FP units on pentium/athlon chips are 64bits capable(32-bit native) since MMX/3DNOW instruction sets and 128bit capable(64-bit native) since SSE2/3DNOW2 instruction sets. The problem with 128bit instructions is that L1 to L2 bus is only 128-bit(4 words as pentium/athlon caches are 4-way associative) wide so every instruction needed 2 cache accesses if operands where not in registers nor L1. With new 64-bit address spaces the whole memory hierarchy has been upgraded, and thus the 4-way cache can provide 4 long(64-bit) words so new ATC(advanced transfer caches) can provide 256-bit bus wide(only in 64-bit mode, not in legacy mode) and thus both operands can be accessed same time.
Having a 20(aprox) cycles access to L2 you can easily see the resulting speed-up.

Starforce 3 support?

[mosschops]

Last time I checked, most (all?) games using the Starforce 3 copy protection system wouldn't run under x64. It uses a driver for low-level CD access, and there was no 64-bit version available.

I'd quite like to upgrade my home PC to make 64-bit development and testing easier, but I'm gonna hold off if it'll break the 5-6 SF3-protected game titles I own. The games themselves will run fine I'm sure, so it's insane the copy protection is the only obstacle. Who was it that said DRM was not an issue for legal owners?

Re:Starforce 3 support?

[slushbat]

If you want a 64 bit system, don't let the DRM stand in your way. That is not what it is supposed to be for. I think in this case you are well within your rights to look for a crack which will allow you to use the goods you have paid for. Write and complain vociferously to them. How dare they obstruct you in this way.

Re:Starforce 3 support?

[mosschops]

The trouble is that SF3 is very difficult to crack, so there aren't many no-CD cracks available. The couple that I have found are for the original release only, so you can't install any patches.

I think it'd definitely be worth me contacting each of the companies to ask about 64-bit support. If enough of us do it they maybe they'll actually fix it - I'm not very hopeful tho, as it'll probably cost them money to do.

Re:Good to see them drop the old cruft... not quit

[uvatbc]

Thats absolutely correct - Some things never change.

The idea behind the spaces and the parenthesis is to force developers to stop assuming anything about the OS and/or FS naming conventions and restrictions.

Its Valve who hasnt changed despite Microsofts (oh-so-ubiquitous) attempts to force a change.

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.

How to use 16TB

[WetCat]

Actually, a linear RAID of 64 250GB disks - and we can
have 16 TB easily. And then mmap it!

what is not surprising

[mikkom]

What is NOT surprising is how well the microsofts web server handles slashdotting :-)

Active Server Pages error 'ASP 0126' Include file not found /article2/0,1697,1857522,00.asp, line 411 The include file '/component/util_generate_article_discussion_info/ 0,1460,d=4730,00.asp' was not found.

Re:Marketing Hype - Not really...

[3D Lover]

Well, I'm guessing that it won't do YOU a bit of good. However, I am a 3d Animator. My typical scene is limited by the per-task memory limit of 32 bit processors. I've been waiting for the day that I can switch to 64 bits and that day is very close. Autodesk has not released the 64 bit Max yet, but when they do I'll be able to use more then 2 gigs of meshes and textures in my scene.

Gone will be the countless hours of trimming stuff our of my scene so that Max doesn't crash. Oh, and I went through this same thing back in the 16 -> 32 bit upgrade.

bleh, longs.

[Mr Z]

The data type "long" is probably the most useless C data-type these days, having been equal in size to int for so long. In my own code, I tend to have a header with typedefs defining "int_8", "int_16", "int_32" etc. (and unsigned variants) for when the width matters, and I use bare "int" everywhere else.

Code written with "long" everywhere was probably written back in the days when sizeof(int) might be 2. (Or written by someone who coded quite a bit during that era...)

--Joe

Re:bleh, longs.

[fitten]

I do the same except I hate underscores so I have a header file of typedefs that define:

int8
uint8 ...
int64
uint64

and pretty much do the same as you describe.

Re:bleh, longs.

[Mr Z]

I know C99 added this, but I have a codebase that I've been maintaining since before C99. Also, I work with platforms that are still C89, not C99. My main project is an Intellivision emulator that currently ports to Linux, Solaris, MacOS X, and Windows. I intend to port it to a DSP also. I'm pretty sure it'll run just about anywhere with some effort. (There once was a MacOS 9 port.)

It would be a good idea to use inttypes.h if it's available. I just haven't updated my code. One of these days I'll learn autoconf.

Re:bleh, longs.

[fitten]

Man I hate autoconf... in all ways for all things.

Re:Tagging practices need rethinking...

[Anpheus]

And this tag had to occupy some sort of physical storage medium that could be used for something else if applied well. But alas, we can't draw on memory that Just Doesn't Exist in 64bit computing everytime we want to overoptimize some code.