If I Had a Hammer 208
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.
Two transition periods? (Score:2, Interesting)
Maybe I'm over simplifying it.
Re:Two transition periods? (Score:5, Funny)
No really, I mean it.
Re:Two transition periods? (Score:5, Informative)
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 [dramexchange.com].
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.)
Re:Two transition periods? (Score:1)
Zooner or lader ve vill find use fer all of those 64 address lines. Sooner than one would expect, I presume. So really, why not push those barriers 'a lot' further. Why not abandon 'bittedness' altogether?
I'd bet there's some decent research on computing sans bittedness. Even perl does that. Damn, some ancient LISP machine could do that.
Well, hell yes, now that all processors hurl at GHz+, well get more and more interpreted languages, it's just so much simpler.
Re:Two transition periods? (Score:1)
Re:Two transition periods? (Score:2)
Anyway, there's plenty of use for 128 bit arithmetics, we're just not using things to their full potential.
Re:Two transition periods? (Score:1)
If you're talking about just a large address space rather than a large memory then it's more reasonable (eg every TCP port on every IPv6 address, that's about 80 bits of space), but there's no pressing reason why the processor itself should have a 128-bit wide memory bus just for that reason. It's just a waste of silicon.
And as for 128-bit *integer* arithmetic: can you give some examples? Certainly there are integer computations going on with more than that accuracy using bignums (often to represent rational numbers as a pair of large integers), but 128 bits won't be enough for those either, you'll still have to use bignums. At best a 128-bit CPU could do those calculations twice as fast as a 64-bit one.
Re:Two transition periods? (Score:1, Offtopic)
Step 1: Build a 128-bit CPU.
Step 2: ????^H^H^H^HConvince every atom in the known universe to keep a video diary.
Step 3: Profit!!!!
When do we get funding?
Re:Two transition periods? (Score:1)
128 bits CPUs would allow for 128 bit operation computations faster than 32 or 64 bit processors, I think. And in fields where extreme precision is important and speed is also important, this might be an issue.
Then again, I'm no expert and Errare humanum est...
Just my 0.02
Re:Two transition periods? (Score:3, Informative)
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.
Re:Two transition periods? (Score:5, Insightful)
Actually, it is a very large number for disk arrays.
I'm unaware of a filesystem that can scale as large as XFS [sgi.com]; 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 [berkeley.edu] 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.)
Re:Two transition periods? (Score:2, Funny)
Re:Two transition periods? (Score:3, Interesting)
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...
Atomic scale circuits (Score:3, Interesting)
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.
Re:Atomic scale circuits (Score:2)
Further, 64bit nubmers are -extremely- common for database architectures (primarily as ID's or what-have-you).. Hell, we're seeing a lot of 128bit numbers already, and 32bit architectres have to resort to slow big-num algorithms. This sort of operation requires 64bit INTs as opposed to void*'s but the two typically coincide within a given CPU.
-Michael
Re:Two transition periods? (Score:2)
If we confine the discussion to microprocessors (reasonable, since there were 60-bit mainframes in the 1960s) we don't even start counting until the 8-bit 8008 circa 1972 (although we could start with the 4-bit 4004 in 1971 -- giving a four-bit increase in one year. Oops). (And actually, the picture is more confusing than that -- most of the early 8-bit chips supported 16-bit addressing, although some of them multiplexed the address lines).
If we stick with the Intel line, the (also 8-bit) 8080 appeared in 1974, the 16-bit 8086 in 1978, and the 32-bit 80386 in 1985. At that rate, doubling in bit width roughly every 7 years, Intel is ten years late with its 64-bit chip, and should have already introduced a 128-bit chip.
If we ignore the 8008, we get a width increase of about 2 bits/year, which actually works out closer to the real numbers -- the 64-bit x86 successor appearing circa 2001/2002. At that rate, look for a 128-bit Intel chip circa 2034, or just a few years short of the Unix clock rollover date (but by then we'll all be on 64-bit time).
Re:Two transition periods? (Score:2)
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.
Isn't true: HDD capacity is growing at (at least) ~60% PER YEAR. Even with the conservative figures here [dell.com] (HD size for 2002 given as 36Gb), that means selling average home user drives of 1.5 Tb in 2010 (starting from 60Gb disks in 2002, you come up with 2.5Tb disks in 2010).
The UCB site manages to grasp that in general, the conceptual failure is to imagine that there is some linearity in information growth. There isn't. Chart anything you like in this area and the graph will be a big sqr(x) type of affair with a scary looking rate of growth at the end. Hold on tight! As the UCB site says "shipments of digital magnetic storage are essentially doubling every year" doubling!
Q. What does every extra bit in an address give you?
A. Double the address space.
Q. How many more bits are there in 64 bit addressing from 32?
A. 32 bits
Q. Which means...?
A. We have 32 years until we're back to where we are today regarding information size vs addressing space.
Oh yeah, 32 years is a real long time. Y2K anyone?
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.
I think you misread me. I dont advocate the need to be able to mmap the web; but local devices? Surely. this has been a problem in 32bits for a long time. There's nothing magic about 64bits. It's just bigger. It too will fall.
And your last comment about cache misses! Are you joking? If you need more than 64bits of space it doesn't matter how much better a 64bit address system cache would work because it can't do the job. Even with the "cache misses", a >64bit system is infinitly faster because it will work. If you need the space, you need the space.
0.02
Re:Two transition periods? (Score:2)
Same thing with hard drives. A single atom can't hold more than one charge at once (well, it can, but that's a whole different concept,) and we've gotten pretty small on the hard drives as well. The only way to increase capacity is to increase the number of platters or the diameter (and the diameter is limited as well, I'd hate to see what centrifugal force would do to a 5' wide iron disk spinning at 7200 RPM.. or the amount of power required to spin it)
Of course, there are always quantum computers, holographic storage, etc, so then I could just be totally wrong. But with our current technology, we're close to maxing out. We should probably dedicate more time and effort to these new fields rather than just extending and band-aiding what we already have.
Re:Two transition periods? (Score:2)
cache for the tape robots, and store up to a petabyte of data.
It may not be the fastest fileserver in the world, but nonetheless there are inodes which uniquely identify every file. The filesystem we used was SAM-FS, running on 64-bit solaris.
Simon
Re:Two transition periods? (Score:2)
A petabyte is only 1024 TB. The sizes we're talking about are about seven orders of magnitude larger than that.
Unless, of course, you have 18,000 Sony Petasites at 1000 TB each.
Do you have 18,000 Petasites?
Re:Two transition periods? (Score:3, Funny)
Isnt that what
Re:Two transition periods? (Score:2)
I hope I'm not the only one looking at that and thinking 'What the hell kind of media besides HDD am I going to back this up on?
I recently purchased two 120GB IDE drives to hold my MP3 collection ripped from my CD collection.
I've been ripping for about 5 days now, and I'm in the C's. (320KB encoding, Athlon 1.33 running RH Linux is doing the ripping, about 8 hrs a day)
I started looking for a backup method besides HDD. Tapes are at best at 110/220GB with SuperDLT. But for home use spending about $5000 for a single tape drive when a hard drive of that size is $200 is out of sight.
Tape tech has GOT to catch up somehow and get down to the cost/MB that HDDs are or we're going to be in an interesting quandary for backing stuff up for DR purposes.
Re:Two transition periods? (Score:2)
Even if you use 320kbps MP3s, you can't get near CD quality unless you use certain encoders. (Use Lame, don't use AudioCatalyst.) And if you use a good encoder you can probably get all the quality you need at 192VBR.
Whatever you do, use VBR. That way whatever you encode doesn't use the full bandwidth for silence, and doesn't feel limited to that for the complex bits.
You may know all this already, but if you don't you'll be a lot happier to find out in the Cs than the Xs.
Re:Two transition periods? (Score:2)
Re:Two transition periods? (Score:2)
I've worked as a programmer before, so I don't know how that fits into your theory.
What the job entails is writing development tools (network simulators, etc), install code, simple UI stuff, and test suites which I then had to execute.
I think the appropriate title for the job is "Junior Whipping Boy" and entails all the annoying stuff that the people with seniority don't want to do.
Re:Two transition periods? (Score:2, Redundant)
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.
Sure, you can munge it so that your physical storage space isn't represented by a single pointer (most 32-bit OS's do that now, since otherwise you'd be limited to a 2G partition and files), but it's a lot easier on everyone if you just handle it with a large enough pointer.
I'll admit, I'm having a hard time coming up with a real use for a 128-bit integer operation (crypto maybe; perhaps neural networks). Engineering and FP ops are different - they use different registers and the FPU, so talking about more precision isn't relevant here. Of course, I suspect people had a difficult time thinking of a use for 64-bit operations back when we were using 8 or 16 bit general purpose CPUs.
Re:Two transition periods? (Score:4, Informative)
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.
Re:Two transition periods? (Score:2)
Given my own numbers and the rapid acceleration of drive capacties over the past 5 years, I think you're wrong.
I support servers in a Fortune 500 financial services corporation. My rough, low-ball estimates of our current hard disk storage space is 1.4PB (petabytes, of about 1.4 million gigabytes) on desktops, servers, big iron, DASD and SAN. It's probably closer to 2PB... you can't imagine the amount of drivespace a huge corporate enterpise requires. If I have 2PB of data storage in one 30,000 employee US company, that's already one eight-thousandth of the 16EB "worldwide ever" total you're working with.
Think about it, take all the private desktop PCs bought in the past three years; they're probably averaging 15-20 GB per unit in drive space. If there were 70 million PCs sold worldwide in 1999 (found via Google), and we triple that (again, probably low for the last coule of years), 210 millions PCs times 20 GB is 4.2EB, again a quarter of the 16EB you are working with.
Between corporate and private puchases, I'd bet 16EB worth of digital storage has been manufactured and sold in the past 24 months.
Re:Two transition periods? (Score:2)
Thank you, Junis in Afghanistan.
We just rolled out (between 2000 and mid-2001) 4000 branch desktops with 733 MHz processors and 20GB hard drives. The corporate standard (new employee PCs) get a 1.6GHz P4 with 20 to 40 gigs of HD, and 256-512 megs of RAM.
Why do you think corporations ask for such big tax incentives and charge so much for goods and services? So that managers who make commission can keep up their income from the IBM sales rep.
Re:Two transition periods? (Score:2)
That's not true. MIPS R1x000 processors, which I use exclusively at work, support either a 32-bit mode with a 32-bit pointer, or a 64-bit mode with a pointer that is a full 64 bits wide. You can malloc() all day long in 64-bit mode.
Re:Two transition periods? (Score:2)
Hammer has 40 bits of addressing space (as you mentioned) and 48 bits of virtual space (memory map tables) so it's not quite out of the memory limit woods yet.
64 Bits has other advantages. File and partition sizes can now be extended more easily. File limits of 2 and 4 GB were common before (Linux had this problem until recent patches) Large files are usefull in databases.
One could claim that Scientific calculations are where the true advantages lie. But most complex calculations might not even fit well with 64 (or even 128) bit values (cryptography). Most programs have custom integer/floating point libraries that handle large values, and will likely continue to need these libraries even with 64 or 128 bit CPUs. A jump to 128 bit CPU wouldn't help much here, and wouldn't mean much to the database vendors who are still happily trying to fill up a 64 bit address space.
We're not really ready for 128 yet. Tho only major advantage of 128 would be in data bus size, to move more data into the cache per fetch. Some processors already do this for speed reasons.
Re:Two transition periods? (Score:1)
Hammer has 40 bits of addressing space (as you mentioned) and 48 bits of virtual space (memory map tables) so it's not quite out of the memory limit woods yet.
That sounds like an implementation detail; it makes sense to only support 40 address lines when that's a fair bit more than you're likely to see before a process shrink or revision of the architecture. Extra lines cost money, and there's no reason to spend that money if it won't be put to use.
Re:Two transition periods? (Score:2)
I found it dissapointing that these limits were in the design up front without apparent room for expansion (free bits to be used in the future) This means that when they do decide to expand the addressing range, they will have to redisign the page table layout and force OS writers to change their code to use it. It would have been nicer to have expansion room built in to the page table design and simply have the CPU implementation have limited pinouts.
While I'm griping, I'll also mention that the X86-16 (Virtual real mode) support has been dropped when in 64 bit mode. I know that noone uses it much anymore, but there are still old legacy games that I have that run in DOS mode and it would be nice to be able to support them.
Re:Two transition periods? (Score:2)
Not a problem, boot in legacy mode and Virtual
Real mode is still there. Your old DOS games wouldn't work under a 32 bit OS,let alone a 64 bit one.
Re:Two transition periods? (Score:2)
I found it dissapointing that these limits were in the design up front without apparent room for expansion (free bits to be used in the future) This means that when they do decide to expand the addressing range, they will have to redisign the page table layout and force OS writers to change their code to use it. It would have been nicer to have expansion room built in to the page table design and simply have the CPU implementation have limited pinouts.
WTF are you talking about? The page tables clearly show 12 Reserved (MBZ) bits in all page tables. That allows for a full 64-bit paged address space (40+12 = 52 bits, with 12-bits for offset within page = 64).
Re:Two transition periods? (Score:3, Informative)
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).
Re:Two transition periods? (Score:2)
Figures 17 and 18 (Pg 58, 59).
The virtual address is 48 bits marked as sign extended, not reserved MBZ. I guess they could add a Level 5 page map and go to a 56 bit virtual and a Level 6 page table for 64 bit virtual. Then they could run into the same problem that *Motorola had 68000 -> 68020.
I think this is what I was remembering when I said the OS would have to be rewritten to use more memory.
As for Physical addressing, Figure 13 PTE (p. 51)shows 4kb Pages using 28 bit base pointer with 12 bit offset for total of 40 bit physical. With 12 bits reserved, you could extend that to 52 bit physical.
However, Figure 14 (P. 53) PDE shows the 2MB page directory entry with 19 bit base and 21 offset for 40 total, but with another 9 bits not used. This 40 plus the previously unused 12 to 52. Plus the new unused 9 gets you to 61. Almost there, but only in 2MB page mode.
Once again the OS would have to be rewritten to use more memory.
* 68000 used 24 of 32 bits, ignoring the high bits. Some programmers tried to use them for other things. When 68020 came out and started using those bits, the old code wouldn't run and had to be rewritten.
Re:Two transition periods? (Score:1)
This means that rate of growth of addressable bits is 1 bit per 18 months.
Do the arithmetic and we may see the 64 bit address bit limit getting hit within our lifetimes...assuming that we currently need 40 bits of addressable memory.
Re:Two transition periods? (Score:1, Insightful)
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.
Re:Two transition periods? (Score:1)
Re:Two transition periods? (Score:2)
Re:Two transition periods? (Score:5, Informative)
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.
Re:Two transition periods? (Score:1)
A few specialised 128-bit instructions don't come anywhere near having the full 128-bit addressing and general purpose registers that a true 128-bit chip would use.
I'm not convinced we'll ever get to a true 128-bit architecture except for research / novelty value. You won't need a 128-bit address space until long after we've done away with digital computers, and getting more performance will probably come from chaining lots of 16/32/64 bit chips together rather than making a single big one.
Re:Two transition periods? (Score:2)
But you and the other guy are talking about two different things. He's talking about 128-bit addressing, or a chip that uses 128-bit pointers. That would allow you to address 2^128 bits of RAM, which is lots, lots. (2^64 is 18 million TB, I think.)
You're talking about vector registers, which are multiples of your pointer or integer size. A chip could grab four 32-bit values in a single fetch and store them in a 128-bit register, so the chip could work on all four of them without having to go back to cache or main memory for the next value. This is not a new idea, but it's also got nothing to do with 128-bit addressing.
Re:Two transition periods? (Score:2)
No, it means one with 128-bit-wide pointers. This isn't complicated...
Re:Two transition periods? (Score:2)
A chip with 64-bit registers can operate either as a 32-bit or 64-bit chip. (Or, presumably, as a 4 or 8 or 16, or whatever.) If the application code was compiled to an ABI that uses a 32-bit pointer, then it executes as 32-bit code; and vice versa. See the MIPS R1x000 architecture for information about this.
The thing that distinguishes 64-bit operation from 32-bit operation is that extra-large pointer, which allows contiguous memory addressing in vast excess of the 2 GB limit of 32-bit code.
A chip with one or more 128-bit-wide registers, like say the PowerPC G4 with AltiVec (the precise model number escapes me), is not, de facto, a 128-bit chip. Likewise, Intel chips with MMX have a number of 64-bit registers, but that doesn't make it a 64-bit chip.
You're simply confusing vector processing (operating atomically on a vector, or array, of values) with 128-bit addressing (using a 128-bit-wide pointer to identify memory addresses).
Re:Two transition periods? (Score:1)
Excellent point. It seems a shame that we had to have 16 bit processors while we migrated from 8 bits to 32. I mean, really, what was the big deal in quadrupling the data lines instead of doubling.
Re:Two transition periods? (Score:2, Informative)
For instance: when you switch tasks you have to save old registers. Numerous and huge register spills (as this is called) costs a lot of bandwidth and time and cuts into your latency.
For graphics processors, 128 bit datapaths can make sense, yet 128 bit instructions are enormous, even for VLIW. For microcontrollers 8-bits are still very much in use. For DSPs you also see funny bithlengths such as 24, 48, 56 and 96 bits.
These are common topics in news:alt.arch which nominally is about computer architecture, though usually it does look like computer archaeology. Current topics include PDP10 (almost always), VAX and M68000.
Re:Two transition periods? (Score:1)
I'll be long retired by then. Your grandchildren can deal with it then.
Re:Two transition periods? (Score:3, Interesting)
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).
Re:Two transition periods? (Score:2, Interesting)
The definition of a 64 bit processor is that it has 64 bit adressing - 64 bit pointers. Everything else, 64 bit registers etc - is just the icing on the cake and the things you would expect.
With this in mind, it's easy to see why you're wrong. At this point in time, there does not exist enough memory in the world to fill the 64 bit addressing space. So why on earth would anyone want a larger pointer, when we don't have anything to use it for?
While I'm sure this will change at one point (since 640 kbyte really isn't enough for everyone), it doesn't make sense to build a processor for requirements that might be 20 years away.
And in case you're wondering; the so-called 128 bit processors of today are really only 32 or 64 bit processors, but since we lack the terminology for describing a processor with 64 or 128 bit registors, memory bus width, internal processing capabilities etc., the marketing dudes get away with calling them 128 bit processors.
End of dry definition.
Bo Thorsen,
SuSE Labs.
How was the test performed on linux (Score:1)
(Seriously though, I hope they haven't left the extended paging bug in)
Re:How was the test performed on linux (Score:4, Informative)
AGP seems to be a problem on the first sample as all of the demonstration system were running without AGP videocards.
Re:How was the test performed on linux (Score:2)
Since that bug is already fixed on current Athlons, I seriously doubt it'll be a problem with Hammer.
299,792,458 m/s...not just a good idea, its the law!
Compiled for 64 Bit...and Programmed for 64 Bit.. (Score:2, Insightful)
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...??
Re:Compiled for 64 Bit...and Programmed for 64 Bit (Score:5, Interesting)
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
Re:Compiled for 64 Bit...and Programmed for 64 Bit (Score:5, Informative)
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.
Re:Compiled for 64 Bit...and Programmed for 64 Bit (Score:2, Informative)
I have been working for SuSE on porting gcc and binutils for x86-64 for over a year now, and it has been pretty painless. After we had the basic system running, I ported a fullblown but small linux system to it (sysvinit, linux-utils, vim etc.) and the only thing I had to do was to make configure scripts grok the x86_64-unknown-linux architecture.
If you take a look at the design papers on x86-64.org or amd.com, you will find that the architecture is very easy to port to. It's basically an athlon with 64 bit adressing modes on top (very simplified way of looking at it). What AMD has done is to do the exact same transition that Intel did from i286 to i386 - 16 to 32 bit.
The new architecture is impressively easy to handle, and gcc can by now optimize almost as good for x86-64 as for i386. It's really just a matter of recompiling.
And if you don't want to do that, run the 32 bit binary. The x86-64 architecture includes running i386 binaries at native speed. This is no marketing crap, it really is the same as you would expect from an athlon.
Of course, if your application has assembler in it, you have to port this. But take a look at the docs again, and you'll feel very much at home there. Actually the extra registers will give you a warm fuzzy feeling inside
I appreciate your point, because for a lot of platform it would be true. But on this one it simply isn't.
Bo Thorsen,
SuSE Labs.
Re:Compiled for 64 Bit...and Programmed for 64 Bit (Score:2)
Obviously you're not aware of how the Athlon works, among other things.
Internally, it has many more registers than four. x86 instructions only reference four registers, but internally the Athlon uses it's full set to speed up the code, as well as exploiting several types of parallelism.
For higher level languages, it is even less of an issue. There may be some impact on my Java code as to whether "int" or "long" has faster operations, but I'll guarantee that all my code using "double" will fly. The best part is that I won't even have to recompile! =)
The other thing I'll gain is that all of my dynamic allocations will have much larger memory limits. The virtual memory limit per process for the first Linux port to Hammer [x86-64.org] is 511 GB.
299,792,458 m/s...not just a good idea, its the law!
Re:Bzzt! (Score:2)
Yes, the Athlon extracts parallelism from the incoming instruction stream.
The point is simply that there is more than one way to skin a cat. No one ever would have thought that x86 would scale so well or be so competitive with RISC. (Alpha was/is great, and I'll never understand why DEC/Compaq dropped the ball so badly there...)
when a program needs to deal with more variables then registers are available they still need to spill data onto the stack (into ram) which is AMAZINGLY slow.
Don't you mean L1 cache?
Your reference box, eh? Since you're breaking your NDA just to tell us you have one (I presume), why don't you enlighten us as to the clock speed on that puppy? ;-)
Regardless, a 50-fold improvement in calculation speed is unlikely to be the result of additional registers... It would more likely be the SIMD type instructions, which use additional registers even in IA32.
299,792,458 m/s...not just a good idea, its the law!
They mention the need for plugin AMD compilers (Score:3, Insightful)
Simple enough to say.
I just wanted a lead-in for the following question:
Did anyone else see a banner ad for Visual Studio
Re:They mention the need for plugin AMD compilers (Score:3, Insightful)
Obviously this isn't what AMD need to do, they need to help people making compilers which support their platform. That's something I'd like to say of my company but it's hard enough work getting AMD to answer E-mail, let alone provide documentation and hardware samples of forthcoming CPUs. You'd think they'd care a bit more since we're the only people in the world making a compiler with vectorizes for 3D Now!, wouldn't you?
By contrast, Intel give us virtually everything we could want in the world short of hard cash. Even though they have a department working on their own (highly competent) compiler, they recognise that wide support of their CPUs is a good thing and they should do everything to encourage it. AMD don't quite appear to have the same attitude at present although we live in hope.
Also, AMD have kind of backed off their proprietary SIMD implementation (3D Now!) with their latest Athlon XPs. The 3D Now! Professional (as far as we can tell), is actually just the old 3D Now! but with SSE as well. An admission of defeat with regards to SIMD software support? One wonders what they're going to do with regards to double float and 128-bit integer SIMD, if anything (Hammer?). Support SSE2 and call it 3D Now! Advanced Server?
Re:They mention the need for plugin AMD compilers (Score:1)
So they make a 64 bit plug in for Visual Studio.. great what do you run it on now?
I doubt Windows XP will know to save the other registers on a task switch or be able to address the extra memory without playing page table games. That leaves AMD to come up with a better optimised 32 bit compiler like Intel did? But why the hell would they do that?
Like it or not AMD is stuck waiting for Microsoft for this one but I wouldn't hold my breath.
Re:They mention the need for plugin AMD compilers (Score:2)
Re:They mention the need for plugin AMD compilers (Score:2)
No XP preview for the AMD (Score:1)
Re:No XP preview for the AMD (Score:2)
Re:No XP preview for the AMD (Score:1)
You misread me. I'm not saying that AMD are anti-MS, I'm saying why are MS anti AMD by not giving them a preview of the 64bit Win XP?
maybe they just don't have one (Score:2)
Therefore IA64 Windows is not compatible with X86-64 Windows, even though both the Itanium & Hammer are compatible with X82-IA32 windows (although the Itanium is like 486 slow as far as X86 code is concerned)
What was slowing down X86-64 recompiling/developing is that Hammer CPUs only came out now, & that software compiling was real slow. Hence AMD commissioned Transmeta to bring out a X86-64 code-morphing version of their CPU, for avaliability to software developers to speed up re-compiling, etc.
Re:maybe they just don't have one (Score:1)
Itanium's 64 bit setup is has a IA64 (or whatever its called) instruction set (although it does have a marginal x86 IA32 compatibility layer), so its not compatible with the X86-64 instruction set of AMD's Hammer series CPUs.
What exactly does this have to do with anything? MS has a 64-bit Windows - they should be able to add a hammer target machine and just build binaries for it. Sure it takes 20 minutes to boot, but the ia64 port should have nailed all the nasty bugs.
porting OSes take longer than 20mins (Score:2)
I think the fact is that it takes more than 20mins to port an OS to a completelly different hardware platform, with a different instruction set, etc.
Hence Hammer's big advantage (Score:2)
Re:No XP preview for the AMD (Score:2)
See the pseudo 64-bit Winodws/Alpha for example or the statement by Microsoft that there will be 32-bit parts in IA64-Windows....
Re:Win XP will not work on Hammer (yet) (Score:1)
I know Intel do not believe in this 64-bit hype yet, as there exist absolutely no software on the 64bit market.
Re:No XP preview for the AMD (Score:1)
For those who don't know, NetBSD is not a Microsoft product.
Who says AMD don't have a sense of humour (Score:5, Interesting)
Re:Who says AMD don't have a sense of humour (Score:2, Informative)
Re:Who says AMD don't have a sense of humour (Score:1)
Re:Who says AMD don't have a sense of humour (Score:1)
Heh heh, note the rest of that image. (Score:2)
Toms pics need mirroring for direct linking (Score:2)
I s'pose he got the shits with people posting his pics on UBB & Fusetalk forums etc, causing a big drain on bandwidth without any 'compensatory' page counts.
So if you want to link a THG pic, either just link the page its on, or mirror the pic for direct linking, complete with a link to the pic's page as well (its consided the bare minimum of good web protocal to at least link the original page if you are going to link to a mirror of the page or some of its content)
that's illegal (Score:2, Insightful)
Re:that's illegal. No (Score:2, Insightful)
Re:Who says AMD don't have a sense of humour (Score:2)
Re:Who says AMD don't have a sense of humour (Score:4, Interesting)
If I Had a Hammer... (Score:3, Funny)
now michael??? (Score:1)
NEWS FOR NERDS, NOT COMEDIANS.
please everyone reply with all the "HAMMER" headlines here so i don't have to watch it on the main page.
Ofcourse Tom has a say in this as well.... (Score:1, Redundant)
Tom's Hardware apparently dropped by as well, check it out here [tomshardware.com].
"486DX-still-going-strong dept" (Score:2, Funny)
That's what I was hoping when I bought an old IBM Thinkpad off eBay a while back. Unfortunately, the truth has been painful - to even install a relatively recent Linux distribution I need more memory (for one) than the max potential for the unit...I think I'll stay with good ol' Pentium Pro 200's and up...
Re:"486DX-still-going-strong dept" (Score:1)
Memory, yes that might be a sticking point with an old laptop. If you have the memory, Slackware or one of the minimalist distributions will run fine on a 486. Don't ask it to do too much, and you will be happy. If you can't think of anything else to do with them, 486 laptops make fine routers.
someone has to say it (Score:4, Funny)
"When the only tool you have is a hammer, all your problems start to look like nails."
Could this be what gives .Net/Java an advantage? (Score:1)
It's conceivable that Microsoft won't make too much use of this, wanting to stay friendly with Intel - but what if the Mono project did? We could end up with
Personally I'm a Java fan myself rather than
Jon
Marketing (Score:1)
However, AMD did a great job with the processor's name. Now they can get that early 90's Oak-town rapper with the enormous pants for the promos. Add background dancers surfing the web with stylish laptops in between pelvic gyrations, and a catchy slogan like "Hey, Pentium IV, U Can't Touch This." Remember the name recognition generated by the dancing Intel Inside guy? This would easily beat it by a factor of n.
Re:Marketing (Score:2)
The word "Hammer" lights up with an AMD logo. MC Hammer walks on and says, "I knew they'd call me. All the time."
Of course, they'd have to license that commercial from Miller Brewing Co.
Intel's little gingle on AMD board (Score:1)
If I Had a Hammer... (Score:2)
I'd hammer in the evening,
I'd hammer at... What?
Damn, this thing just cracked in half!
If I had a hammer.. (Score:2)
I wanna see Hammer-based computers in storerooms running Linux with Windows as an optional downgrade..
Informative article (Score:4, Funny)
When the team that ported Linux has something to say, let us know. It's good that AMD is showing sample parts that work.
I expect that at least one of the big search engines will convert over to these things soon. They need multi-gigabyte address space in the servers.
AMD announces Suse Linux support (Score:2)
Quote:
AMD (NYSE: AMD) today announced that SuSE Linux AG, one of the world's leading providers of the Linux operating system, has submitted enhancements to the official Linux kernel.
Read the rest here: http://www.amdzone.com/releaseview.cfm?ReleaseID=8 10 [amdzone.com]
Re:Compiler questions... (Score:2)
See the main page of http://gcc.gnu.org/: