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.
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.
The extended paging bug wasn't a simple cpu bug, it was a complex bug between CPU, chipset and videocard. Because the Hammer has a very different i/o architecture compared to the current athlon, the parts of the cpu & chipset that caused the bug should be new designs anyway.
AGP seems to be a problem on the first sample as all of the demonstration system were running without AGP videocards.
Jan
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
In fact, the proposed 64 bit processors will pretty much be doing all known processor design techniques on a chip. At that point, we have used all the ideas that were known when the Vax was designed (approx 1980). Since then, nothing much new has been invented. The only missing piece of technology is content addressable memories (ie execute jump table in single cycle instead of stepping though each option and comparing. These have also been known since about 1980, including how to make them. Used as cache tag ram, they would make a HUGE performance improvement. There is no obvious reason for not using them apart from the fact that its a European development (mostly UK and Germany), and America has a problem with NIH.
I dont deny there are special cases where 128 bits (or even 1024) might pay, but to sell, you need a general purpose machine, and 64 bits is the top whack as far as we know. After that, masssively parallel is more cost effective (ICL DAP, etc).
No need to wait.
;-)
There are already applications that could use > 64 bits of address space. Whilst 16 Exobytes might sound like a BIGNUM for RAM, it isn't that much of a bignum for large scale disk arrays.
At the moment there is an addressing disparity between RAM and storage, but there shouldn't be. Ideally you should be able to memory map everything you need, including the entire filesystem. If you have a FS with 64bit addresses to 512bit blocks, or something larger, you might already need bigger address spaces.
Of course 64 bits sounds like more than we'll ever need, but a bit of imagination is all that's needed to see possible uses of >64bit space today. If you can think about needing to do it now, it's fairly space to say that it will be done in the future.
Modulo one fact: maybe we wont have >64bit addressing. Maybe we'll have XX qubit addressing instead
0.02, etc.
Tales from behind the Lagom Curtain
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.)
One thing to note is that when you have 64-bit addressing, you only get 2^63 worth of storage. Why? Because it's a signed int so you can express a negative offset from current location.
Wrong. Are you perhaps thinking of the offset that is used in address calculation? Or perhaps by your reference to "current location" you are thinking of branch offsets, which are relative to the current IP (or PC, but this is an x86 article)? Regardless, the resulting address is 64 bits, and unsigned. And the base register (as in the instruction "mov rex, [rax +40]") is an unsigned 64 bit integer.
The enemies of Democracy are
Actually, assuming Moore's Law (in it's debased form) continues, we can calculate how long it will be before we need to go to 128 bits. The calculation is easy- 18 months of growth for every extra bit.
So to go from 8 bits to 16 bits took a mere 12 years. Say 1966 to 1978. Going from 16 to 32 took a little bit longer- 24 years (1978-2002). Going from 32 to 64 bits will take 48 years- it'll be 2050 before we outgrow 64 bits.
And it'll be 2242 before we outgrow 128 bits, 2626 before we outgrow 256 bits, 3394 before we outgrow 512 bits, etc.
Of course, there are slight physics problems with Moore's law continuing for the next 1,392 years. But that's for a different post...
"slight physics problems" is right; and how!
;-)
I'm very doubtful that 128-bit machines will *ever* be built; though only a fool would say they definitely won't be built, this early in the game.
32-bit CPU's still take large chunks of silicon, and their features are approaching 1E-7 meters in size. 64-bit machines will not be severely limited until they are trying to manage about 10 orders of magnitude (1E10 times - well over 2^32 times) more circuit elements. If circuits are still basically planar in physical layout, this implies circuit features approaching 1E-12 meters (1E-7 / sqrt( 1E10 ))...
Since silicon atoms are roughly 2.5E-10 meters across, there might be a slight problem with building circuit features this small.
Put another way, the realistic limit for further process shrink is about 2 more orders of magnitude (the circuits would be just a few atoms across) - only 4 more orders of magnitude in total number of circuit elements, not 10.
So I really have a hard time seeing how a computer built with *chips*, that is smaller than a skyscraper, would ever need more than 64 address bits.
-- Mike Greaves
Sorry, my bad. You're partially right and I'm partially wrong.
I took a closer look. The architecture goes up to 52-bit VAs. There are 12 "available" bits that OS'en can use. 12 bits are state bits. 12 bits are Reserved(MBZ), leaving 28 bits currently defined for a 40 bit addressing (28 bit page base + 12bit offset). However, when you add in those MBZ bits, you get a 52 bit address (40bit pagebase +12 bit offset).
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
"all the pr0n, all the MP3s, all the source code, all the PowerPoints, everything-- on one server with one big filesystem"
.NET is for?
Isnt that what