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.
64 bits should be enough for anyone.
No really, I mean it.
-- Ed Avis ed@membled.com
Umm, first of all it's hard enough to engineer a 64-bit CPU with related components. Then there is the manufactoring details, etc, etc. From that standpoint, it's not economical try to to do a 128 bit CPU now.
Second, there is no point in 128 bit for software right now. We are going to have a hard time even writing software that even requires a 64 bit processor. If we were stuck on 32 bit processors for another 5 years (yet with increasing speed), I really doubt that we would be much futher behind.
I am no expert, but I can't even begin to see the need for 128 bit processors right now. It's better to focus on making the current designs faster.
This is the job of the compiler... If I recompile source code I expect the compiler to optimise the object code in the best way for the target!
No, let's not. The PS2 was so radically different from the PS1 (I've coded both) that it amounted to an architecture change, not just a platform upgrade. The PS1 is a pretty much bog standard CPU+VRAM+DRAM device. The PS2 is a dataflow architecture, with the idea being to set up datastreams, (with the code to execute being part of the stream), and to target those streams with a firing-condition model. This is amazingly versatile (and the device has the bus bandwidth and DMA channels to handle it, the PC doesn't) but it is *very* *very* different from the standard way coding is done. This is why PS2 games are still getting better two years down the line...
Actually I don't think it's much harder at all, it's just different. You have 3 independent CPU's, all of which are pretty damn fast considering they're only at 300MHz. The device can do (peak) 3 billion (3,000,000,000) general purpose floating point multipliy/accumulates per second, and you can get pretty close to that figure, unlike most peak throughput estimates. Bandwidth again, and the use of an opportunistic programming methodology rather than a logical-progression methodology.
Having said that, I'm from a parallel computing background, so using only 3 CPU's is child's play
Because there's a much more quantifiable change in going from 16-bit to 32-bit. Developers had been hacking around the 16-bit limit using 'near' and 'far' pointers (!!), which meant all the cruft from those 16-bit days was still sticking around and causing problems if you just recompiled.
Now they're (at long last!) in the 32-bit arena, there's no such problems. A char* ptr is still a char* ptr, it now just has a greater domain. No cruft. No problems.
This isn't to say that compilers won't get better over time though - optimisation is an inexact science, and you'd hope to see improvements as compiler-writers see how to improve the optimising stage.
Enough...
Simon
Physicists get Hadrons!
64 bits should be enough for anyone.
No really, I mean it.
Clever, Ed. For those who don't get it, he's quite right: 64 bits *will* be enough for anyone.
For those still stuck in mid-90's video game wars, "bit-edness" in the real world refers (technically) to the size of your general purpose integer registers, which, for most intents and purposes, refers to how many memory addresses you can easily and quickly address. 32 bit addressing tops out at 4GB, a value which is often too small for e.g. large databases, which thus tend to live on 64-bit big iron machines. (MS has a hack to give x86 processes access to 36 bits of space, but it requires OS intervention.)
64 bits, on the other hand, works out to 16 billion GB. (That's 16 exobytes IIRC.) For reference, that's roughly 40 times as much memory capacity as there currently is DRAM produced (of all types, for all markets) worldwide in a year, at this January's rate.
I don't have the figures on hand for hard drive production, but I would guess as a first approximation that 16 billion GB is not quite equal to the total number of bits of digital storage of all kinds manufactured throughout computing history up until today. (I'd guess it's too small by a factor of 3 or so.)
In other words, it's quite a lot. Presumably computing will have run into some very different paradigm (wherein the bit-edness of the "CPU" is no longer an applicable term) before any computer has a use for >64 bit addressing.
(FWIW, today's 64-bit processors don't offer all 64 bits of data addressing yet, because no one has a need for more than 40-something, so that's what they offer.)
You also compared the transition from x86 to x86-64 to the transition for PSX to PS2. That is also something very different. The PS2 is hard to code because the design of the graphic subsystem and vector cpus make it very fast on the one hand but also very hard to use the full potential. The PS2 CPUs also hard to use because the caches are too small.
When the 386 was introduces things like games were coded in assembler, at least the performance critical parts. Something that is coded in assembler can't be recompiled. Now even games are coded in high level languages.
Jan
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.)