Slashdot Mirror
If I Had a Hammer
adpowers writes: "Anandtech is running an article about their preview of AMD's Hammer. They had one machine running 32-bit Windows and the other running 64-bit Linux. The Linux machine had a 32 bit program and an identical program that was compiled for 64-bit processor support. Both processors were less than 30 days old and running without any crashes, but they weren't at full speed." We did one Hammer story a day or two ago, but there have been several more posted since then (wild guess: the NDA expired). Tom's Hardware has a story, so does Gamespot.
There's a lot of difference between 32 bit optimized code compiled for 64 Bit, and code written and optimized for 64 bit and compiled for 64 bit.
Applications need to be programmed and optimized to make use of the extra registers, extra info paths, extra instructions available on the new platform. Without that, the application speeds can't be compared, even though the base code and output is the same.
Let's take the example of some of the 1st. generation playstation II code...which was actually code written for a 32 Bit machines, on a different platform like the PC, or the old PSX, now..pure recompiling won't get you any major performance boost, so all the developers had to "re-do" the code to make use of the 128 bit emotion engine.
Exactly the reason why all these gamedev guys kept screaming it is much harder to code for the PS2 than for other platforms....one part of that whole hing is this...the other part is changing graphics APIs.
PCs is dirextx/opengl....and PS2 can be either custom renderers, or Open GL.
Put it in perspective....why don't 16 bit games re-compiled for 32 bit give a "major" performance boost...unless optimised code is included...??
The article suggests that AMD write / release native compilers that plug into Visual Studio...which would be a good thing for MS programmers.
.NET on Slashdot yesterday? Or was I hallucinating?
Simple enough to say.
I just wanted a lead-in for the following question:
Did anyone else see a banner ad for Visual Studio
Writers imply. Readers infer.
64 bits should be enough for anyone.
Why was this declared funny by the moderators? It's true. Most of the code out there (even code for existing 64Bit architectures) uses 64Bit (integer) data types almost exclusively to address memory. 32Bits are not enough anymore to address every byte on your hard disk and on high end machines it's not enough to address every byte of RAM.
64Bits give you 4 billion times more address space. Development in the PC sector is fast but it's not that fast.
Since the invention of the PC, RAM size in the average PC has increased by a factor <10000. Hard disk size has increased by a factor of <100000. That's over 20 years development. An increase in address space of factor 4 billion is going to last us a very long time. We might never hit this mark in consumer machines, because there is only so much information humans can deal with. Even if you start archiving HDTV video uncompressed, the storage addressable with 64Bits is enough for 1 million hours.
I'd also like to give a little perspective regarding computation. If a 3D shooter used 64Bit integers, it could still model the complete earth with sub-nanometer precision.
Even if you work with 1/1000 of a cent precision, 64Bits are going to be enough for all financial computations there will ever be.
More than 64Bits does not make sense for a general purpose microprocessor. You are better off with a processor that has multiple 64Bit integer units than a processor that has fewer 128Bit units.
Whilst 16 Exobytes might sound like a BIGNUM for RAM, it isn't that much of a bignum for large scale disk arrays.
/earth and set the permissions to 700, please.
Actually, it is a very large number for disk arrays.
I'm unaware of a filesystem that can scale as large as XFS; there may be others, though. XFS uses 64-bit addressing, allowing the filesystem to scale to 18 million terabytes (or 18 exabytes, if you prefer). No filesystem in the world has ever remotely approached that size. According to this nifty site, total worldwide disk drive production for the year 2000 only totalled 2.5 million terabytes. So to build a filesystem that's 18 million TB big, you'd have to commandeer all hard drive production, worldwide, for about 12 years.
They estimate that the total amount of data stored on hard drives in the entire world is only about 4 million TB. That means you could theoretically put all the data in the world that is currently stored on hard drives-- all the pr0n, all the MP3s, all the source code, all the PowerPoints, everything-- on one server with one big filesystem, and only use about 1/4 of the filesystem's capacity. Mount it under
Of course, this fact fails to address your basic premise, which seems to be that assigning unique integer addresses to every byte that a computer can access would be a reasonable thing to do.
Even if there were a reason to do such a thing, don't forget that increasing your pointer size decreases your cache efficiency; you can fit twice as many 32-bit pointers in your cache as you can 64-bit pointers, which results in fewer cache misses and overall better performance. (How much better depends on how cache-friendly your task is in the first place, but 32-bit will never be less cache-friendly than 64-bit.)