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.

Comments

Two transition periods?

[Mattygfunk]

So it will be a few years until we all have 64-bit PC's with applications written for them. I don't understand why the development work wasn't put into 128-bit processors in the first place. Wouldn't this avoid the next transition period when most applications are written for 64-bit machines?

Maybe I'm over simplifying it.

Re:Two transition periods?

[Ed Avis]

64 bits should be enough for anyone.

No really, I mean it.

Re:Two transition periods?

[XBL]

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.

Re:Two transition periods?

[Anonymous Coward]

As you double the width you increase memory consumption without necessarily also doubling the performance. Going 8 to 16 and 16 to 32 gave you better instruction set maps, going from 32 to 64 didn't offer much more, going to 128 bits is for general purpose processors more costly than beneficial.

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?

[ToLu the Happy Furby]

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

Re:Two transition periods?

[DrSpin]

In the late '50s/early 60s, when the first mainframes were built, they were all approx 60 bits. Thereafter, all "cost is no object" computers were 60/64 bits. There is not much evidence that anyone will ever want to go further than 64 bits. There are significant overheads to longer words (ever heard of "carry propagation"?).

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?

[mirko]

Or maybe it would be a good idea to start making good asynchronous systems based on collaborating heterogeneous processors ?

Re:Two transition periods?

[Mike Connell]

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.

Re:Two transition periods?

[Zathrus]

No, 64-bits is not enough. There were optical storage arrays built nearly 10 years ago that used the full 64-bit address space (yes, it was largely done to prove you could, but there are systems being built now to use the entire 64-bit address space).

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?

[Geek In Training]

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

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?

[foobar104]

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

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?

[foobar104]

Whilst 16 Exobytes might sound like a BIGNUM for RAM, it isn't that much of a bignum for large scale disk arrays.

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 /earth and set the permissions to 700, please.

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?

[foobar104]

I was only trying to make the point that 128-bits is useful in some niche applications, and it has already been done.

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?

[IPFreely]

All true and relevant, However...

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?

[psavo]

The point wasn't about handling ipv6 addresses, but about th reason behind choosing 128 bits for _addressing computer interfaces_. There's no much extrapolating in idea that one day a computer will have so much memory that 64bits would not be enough. Yes, it may take many years, but it's still not that far away.
Anyway, there's plenty of use for 128 bit arithmetics, we're just not using things to their full potential.

Re:Two transition periods?

[foobar104]

Correct, but a "128-bit processor" doesn't mean one with a 128-bit address bus.

No, it means one with 128-bit-wide pointers. This isn't complicated...

Re:Two transition periods?

[Chris Burke]

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.

Re:Two transition periods?

[thorsen]

You're not oversimplifying, you're simply wrong :-) I believe the cause for your mistake is that you are listening to marketing guys without realizing it. So, some facts to set the record straight.

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.

Re:Two transition periods?

[foobar104]

It has nothing to do with the size of pointers. It has everything to do with the size of the registers. How did you get to be posting at +2 with a clue of this size?

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?

[IPFreely]

The 40 bit address and 48 bit virtual limits are inherent in the page table mappings. (See the AMD Spec)

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?

[OS24Ever]

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.

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?

[Sunthalazar]

Actually I think I would prefer the permissions to be 777, or at least 770 if I was lucky enough to be a part of the earth group. Since I really don't think I'm the user. :)

Re:Two transition periods?

[bhurt]

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

Re:Two transition periods?

[Mike Connell]

A few corrections...

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

[spiro_killglance]

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.

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?

[Space cowboy]

Buy a petaserver from Sony. You use (say) 10Tb of
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?

[WNight]

Have you checked out r3mix.net yet? It's a good place to start before a big encoding project.

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?

[Amazing Quantum Man]

The 40 bit address and 48 bit virtual limits are inherent in the page table mappings. (See the AMD Spec [amd.com])
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?

[Amazing Quantum Man]

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

Re:Two transition periods?

[foobar104]

Buy a petaserver from Sony. You use (say) 10Tb of cache for the tape robots, and store up to a petabyte of data.

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?

[_ph1ux_]

"all the pr0n, all the MP3s, all the source code, all the PowerPoints, everything-- on one server with one big filesystem"

Isnt that what .NET is for?

Re:Two transition periods?

[IPFreely]

OK, My turn. It's been a while since I actually read that document (like, over a year) So I refresh.

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?

[AJWM]

Where'd you pull those numbers/dates from? Somewhere dark, I imagine.

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?

[OS24Ever]

Thanks for the link & the suggestion. I'll check it out.

Re:Two transition periods?

[WNight]

Perhaps.

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?

[Geek In Training]

We've got close to 400 PC's here and none of them have even 1/5 of that. Even the servers only have 8GB's (two 4G SCSI drives).


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?

[Ryan Amos]

Everyone assumes that "Moore's Law" is infallible, where this simply is not true. It's more of a pattern than a law, and it'll come screeching to a halt within the next decade. As soon as we hit 1 atom-wide circuits, that's it, we can't get any smaller. Currently we're about 40 atoms across, though it's hard to 100% accurately count.

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.

Compiled for 64 Bit...and Programmed for 64 Bit..

[PhrozenF]

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

They mention the need for plugin AMD compilers

[Inthewire]

The article suggests that AMD write / release native compilers that plug into Visual Studio...which would be a good thing for MS programmers.
Simple enough to say.

I just wanted a lead-in for the following question:
Did anyone else see a banner ad for Visual Studio .NET on Slashdot yesterday? Or was I hallucinating?

Re:They mention the need for plugin AMD compilers

[Lurks]

The article suggests that AMD write / release native compilers that plug into Visual Studio...which would be a good thing for MS programmers.

I took issue with the author writing that as well. Like it's some trivial task in software engineering to suddenly start writing a compiler which is comparable to what's out there already on the highly competitive x86 platform. (Codeplay does this already of course)

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

[Steveftoth]

Yeah, until MS releases a version of XP that actually runs in 64-bit mode the compiler will be useless. Since until then the processor will run in the 32-bit mode.

Re:They mention the need for plugin AMD compilers

[Steveftoth]

No, not really cause the os can just run in 32-bit mode. Yeah, they could just NOT port it to the new arch. They've already proven to the world that they don't really care about 64 bit all that much after pulling support for Alpha and not diverting enough resources to the IA64 project to get it to work as well as the linux port.

Re:How was the test performed on linux

[tempmpi]

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.

Re:Compiled for 64 Bit...and Programmed for 64 Bit

[Space cowboy]

Applications need to be programmed and optimized to make use of the extra registers, extra info paths, extra instructions available on the new platform

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!

Let's take the example of some of the 1st. generation playstation II code...

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

Exactly the reason why all these gamedev guys kept screaming it is much harder to code for the PS2 than for other platforms

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

Put it in perspective....why don't 16 bit games re-compiled for 32 bit give a "major" performance boost

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

[tempmpi]

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.

That might be true if the only thing that changed were the register,adress space and ALU size, but AMD also removed many flaws of the x86 instruction set. x86 cpus got only 7 registers (EAX,EBX,ECX,EDX,ESI,EDI,EBP) for general purpose use. Other CPUs have much more registers, the lack of registers makes it very hard for compilers or assembler programmers to write efficient code for multiscalar cpus. AMD added more registers. AMD also made a more efficient fpu. You can really get a nice performance boost from these changes with just a rebuild of your software.

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.

That isn't true, almost all programms, even games, are now programmed in C(++).(Or something like Java or Perl, but these programms doesn't matter here) The compiler can really use the extra registers/better fpus without any aid from the programmer(OK, maybe a compiler switch). Things like using the "register" keyword in C isn't really needed as good C compilers are better than most programmers at choosing which variables to keep in registers.

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.

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

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

[thorsen]

You're wrong in this.

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 :-) But my point here is that there is no change in the way you think - no change in the coding philosophy.

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:How was the test performed on linux

[Glock27]

(Seriously though, I hope they haven't left the extended paging bug in)

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!

Re:Compiled for 64 Bit...and Programmed for 64 Bit

[Glock27]

Applications need to be programmed and optimized to make use of the extra registers, extra info paths, extra instructions available on the new platform.

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 is 511 GB.

299,792,458 m/s...not just a good idea, its the law!

Atomic scale circuits

[Mike Greaves]

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

Re:Atomic scale circuits

[maraist]

Other's have mentioned this, but I'll say it anyway. 64bit addressing has no limitations except for the physical number of pins comming out of the CPU; and that can be overcome by simply serializing 2 x 32. As for caching (which other's have brought up), obviously a given architecture would have to use segmented regions (say of 4 Gig max cachable, etc). The main advantage of full 64bit addressing would be proprietary motherboard / PCI cards that allow NUMA style memory architecture's etc. It's not that a full 64bits are needed, but that an arbitrary memory segmentation might be desired where the high bits divide the different nodes, etc.

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:Bzzt!

[Glock27]

Yes, the athlon has shadow registers, but that doesn't obviate the need for more physical registers.. The shadow registers are used to enable superscalar execution..

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!

AMD announces Suse Linux support

[pointwood]

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