Slashdot Mirror
Red Hat Reveals Support For AMD's Hammer
Anonymous Coward writes "Red Hat had been rumored to be working on support AMD's Hammer architecture, and now they have made it official. Now if I can get a hold of one of these my little site will finally be able to handle a good slashdotting with 16GB of DDR333! 'Red Hat will provide native 64-bit support for processors based on AMD's x86-64 technology, while providing support for existing 32-bit Linux-based applications.'" Combine this with Linus' feelings and Hammer is looking better and better.
Linus wants hammer to get popular so intel gets off thier asses. he was not talking about widespread adoption of hammer within the linux kernal. he was talking about hammer paving the way for other 64 but processors.
Is this really a surprise? It seems only natural for Red Hat to support as much hardware as they can. While im not suggesting a Red Hat for toasters any time soon, supporting Hammer seems logical to me. Or am I missing something completely?
Doh! Linus doesn't have warm fuzzy feelings towards the Hammer, or rather he's never expressed them. The poster is referring to a post on LKML on paging issues with Itanium.
Linus didn't endorse one platform or the other, he only explained that if Hammer was to become dominant instead of Itanium, it would save the kernel developers problems solving the Itanium paging problems.
Now, the obvious question when dealing with a corp and linux hardware support. Will they put an effort into coding it (the compiler in this case), or will they wait for the lusers to finish coding it and then take the credit?
Seriously, is Redhat good about this? I know some hardware manufacturers are like this about "thier" drivers.
*sniff* *sniff* *sniff* somethings burning. Oh, its just my karma...
Any sufficiently advanced influence is indistinguishable from control.
Now if I can get a hold of one of these my little site will finally be able to handle a good slashdotting with 16GB of DDR333!
;)
Just as long as you lose that 14.4 modem you are hosting off.
Replacing your commodore 64 is just a start
Moderate this as a flame if you want cause I am sick and tired of this x86-64 bullcrap.
Lets see, the history of slashdot and most of computer-geekdom has always ribbed Intel for maintaining backwards compatibility with processors more than a decade old. Sure, x86 is great due to all the applications out for it, but in all honesty why can't we move away from it?
With Slashdot, Linus and most of the online review sites pushing for x86-64, one has to wonder if AMD is slipping cash under the table to all these parties. If not, then what happened to those people who wanted innovation in the releam of processors and just not cheap hacks upon hacks upon hacks? It's kinda funny but the way AMD is going is sorta the way Microsoft is: maintain backward compatibility at all costs.
My guess is that most people pushing x86-64 have yet to write a program more complicated than "hello world!". Let's stick to our desire for innovation and truely stand behind the company willing to shed the baggage: Intel.
Press releases detailing SuSE's work on Linux for the Hammer can be found here (20th March 2002), here (28th February 2002) and here (31st January 2001).
Roger Whittaker (SuSE Linux Ltd)
Hmmm. I'm probably more interested than most in the prospects of large address spaces, however I don't imagine typical web sites are where this technology will be best exploited. Think seriously, moving to 8 byte addresses has the following effects:
- Massively expanding address space and hence (for the first time - IMHO) making the holy grail of direct manipulation of persistent data structures a realistic proposition.
- Expanding the size of today's simple data structures. Consider, for example, a simple bi-directional linked list of 32-bit integers using a forwards and backwards pointer. A 32 bit arch has a 200% overhead, but 64 bit ach has 400% which should somewhat diminish expectations for magical performance!
Don't get me wrong. I think 64 bit is likely to be at least as important a step as 32 bit was c. 20 years ago, however I don't expect more than a small niche for such systems until resource allocation is re-thought.After all, it's a very simple matter to recode your source to run on a new architecture, once the preliminary work has been done.
You can only get anywhere if you have backward compatibility. Whilst Windows software will have to be rewritten for 64-bit execution, much of what exists on Linux should just recompile. AMD's decision to implement backward compatibility means that they will certainly be the choice of the home user, even if they don't make it big in the world of the office.
Like car accidents, most hardware problems are due to driver error.
I can't help but feel that "real" manager's will just say Itanium plus winXP despite the advantages of Hammer and RedHat
AMD has almost constantly succeeded to deliver technically better hardware for a lower price. Given the current economic downturn (blabla) and the lessons learned in the dotcom meltdown (e.g. that image is not everything) even your average modestly intelligent manager type will perhaps chose the cheaper, better product. Besides, I don't think AMD is still viewed as that kind of an underdog anymore! And Linux on the server front looks good, too. So I think the chances are good.
Another issue is of course whether an 64+ bit addressing architecture is needed for mainstream PCs yet. But as we all know: it's not whether you need it - it's whether the industry thinks you need it!
Remember this, year 1992?
"Digital Equipment unveils the 150-MHz Alpha 21064 64-bit microprocessor". That was kind of one checkpoint, this year, I believe might be another.
Ok, I'll probably buy AMD but
If Intel wins then Windows is stuffed,
Because most of the Linux software is open source so I can recompile for Intel, on the other hand most of the Windows software I use is closed source.
thank God the internet isn't a human right.
The question that begs asking is if we actually need 64 bits. While the point of oodles of memory, etc can be made, consider google. Google has oodles of CPU's working together. 64 bits will buy them nothing. And somehow I tend to think this is how computing will go.
And also consider the fact that quite a few companies have 64 bits, Digital, Sun. And did the world change? Not really...
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
My thoughts were the same when 32bit came in, until I relealised.
The new insturusction and architecture improvements in 32bit x86 made for a good performance overhead.
The memory bus was twice wide on a 32bit system , so the pointers on the linked list may have been twice the size but becuase of the wider bus there was no performance hit.
One of the create benifits of 32bit was that you could have numbers +-64000 in one register, giving the greatest performance increase.
The extra wide bus is gonig to give some performance gains on 64Bit systems, but I don't see the extra address space or larger numbers being that benifitial.. Well maybe the extra address space will help with threading and process management, and mean that bloatware can be even more bloated.
thank God the internet isn't a human right.
Stating that they are supporting a 64-bit CPU should mean that all the code that makes up RedHat properly compiles on this particular 64-bit CPU (i.e. is 64-bit pure) and that the compiler handles the CPU properly. Since we are dealing with open source, all the distributions could put together a 64-bit version easily by simply upgrading to the latest 64-bit friendly source and doing a build.
What I am wondering about is how much of the code is not 64-bit pure, and who will take care of making it 64-bit pure in time for Hammer to be released. It is a real problem after all.
Everybody and their cat will support the Hammer when it finally arrives, linux, windows, (MacOS X?), bsd, (solaris??).
And about 16GB of memory. Either you put 4GB DDR333 SIMMs in your four slots, or you have a mobo with a lot of SIMM slots. Having a larger address range is great, but I wouldn't want it if I don't get more memory as well;) Let's hope the memory prices can fall a little again.
Most of the 64-bit pure-ness has already been done. So have the endian-ness.
If the code runs on Sun, Mac OS X, x86 and Alpha then theres a good change it will run on Hammer or IA-64 without any significant changes(if any).
thank God the internet isn't a human right.
Anonymous Coward writes: Now if I can get a hold of one of these my little site will finally be able to handle a good slashdotting with 16GB of DDR333!
/. you need one of those just to keep up!
Not only that Anonymous Coward, but with the amount of posts you make to
This comment was generated by a Squadron of Ultra Ninjas
Well there are a few points where i would see 64bit computing making a difference. First of all the I/O part, using native 64bit data types for your 64bit PCI slots, moving over 64bit wide I/O channels.. this will save you quite a bit when using gigabit network cards and high end I/O controllers such as raid. Also the graphics / 3D market can benifit from this.. first the graphics industry is moving to higher requirements for prescision of colors and coordinates (so using native 64bit numbers for them won't impact performance as much, but allow a much higher prescision), and it will also be able to use the 64bit I/O busses (the first mobo's i've seen for these CPU's don't have 64bit AGP yet, but i am sure it will happen)
;-)
Last, all this creates a nice new tech platform.. 64bit PCI slots (running on 133 or 64 mhz), and DDR333 ram..
All in all it will make more sence in the beginning to use all this goodness for I/O demanding applications (servers) but i am sure it will break through in the profesional graphics market soon enough, with the consumer market laging behind only a bit.
Also remeber, linux _needs_ 64bit computing.. while linux wasn't that sensitive to the Y2K problem, the 32bit time value used is gonna run out in the next 30 years.. native 64bit integers would mean you can use 64bits for your seconds since 1/1/1970, so keep linux running for a while longer
Yes, we can argue that RAM is cheap... but as you eloquently point out, buying more RAM doesn't overcome all of the implications. Other bottlenecks exist, and I can think of several:
And, I'm sure that there are more:-)
I remember when 48K was considered overkill because you couldn't fill it
I remember when 360k was enough for software and data
I remember when I got a 20 meg hd for my XT "just in case"
I remember when I didn't wear these damn Depends. NURSE!!!
If you aren't part of the solution, there is good money to be made prolonging the problem
We all know that 64bit is going to replace 32bit. AMD and Intel are important because huge volumes and low costs are what will finally make 64bit machines ubiquitous, i.e. aunt Edna will be able to buy one at Walmart for a couple of hundred bucks. Like it or not one of these architectures will be the "new x86" and nearly all software will be written for it, displacing 32bit machines as well as all the 64bit niche architectures on the market now.
As for Sparc, Alpha, etc. being "better": Since when was the best solution guaranteed victory?
According to a recent press-release, MandrakeSoft has also worked with AMD to get Hammer supported on early 2003.
The joint Press release (MandrakeSoft/AMD- June 27th) is available here.
Would i rather have 64bits or
8 way SMP with decient
thread and process management
and reasonable security in the CPU instruction set.
mainstream SMP systems will change the world, mainstream 64bits won't(unless they add all of the above).
thank God the internet isn't a human right.
just too bad that the anouncement is only for the high-end versions of the redhat distro
we're stuck in 32-bit-hell for the rest of our days, and redhat turns into the new M$ -- evil and agressive...
oh... wait... it's linux... move along people... nothing to read here...
Has the word laptop case-mod of the year (actually that's more than one word) written all over it for someone with the right state of mind and with a little too much money, or just enough as you can put it.
At least given my experience with 64 bit SPARC chips, and the 64 bit Solaris operating system, 64 bits hardly made a difference either way. And I'm not slamming Sun, either.
IANAKE. (I am not a kernel expert, but this is my understanding of the situation.)
Sun incrementally worked its way up to 64 bits in the operating system. I believe first they offered 64 bit OS calls, then later moved the OS itself to 64 bits. Solaris 7 was, at least, the most visible transition, when you had a choice of installing a 32 bit OS, or a 64 bit OS.
What will surprise some people (and be intuitive to others) is that many applications actually ran a bit SLOWER with the OS in 64 bit mode. What? Yup. And for good reason, too.
The problem was that you had the overhead of a 64 bit operating system to run 32 bit applications. More overhead means less application performance. More work was required to do the same tasks.
And many applications are hard pressed to take advantage of 64 bit features. Its like putting a hot-rod engine into your daddy's Oldsmobile and keeping the original tranny. But yes, it works.
Mind you, there are applications which can take some more advantage of 64 bits, and the future in operating systems isn't 32 bits. So it is still good to have an operating system go that direction. It is just that for most people, there isn't a big WOW FACTOR when you go 64.
Here's what AMD is really thinking
Come on, people, really. Don't support AMD. They are not the noble David against the nasty Goliath. They are just as much a nasty Goliath themself, except for the fact that they don't have much market share... But they sure are acting like they do. If AMD and Intel keep pushing their 'Trusted Computing' wheelbarrow, I swear I will buy an underpowered Transmetta or even a fucking Macintosh just to avoid Palladium.
I let most of them go, but you've just tipped me over my annoyance limit for today. The word you wanted was your, not you're. You're is short for you are, and the phrase "you are cache will only hold half as many of them" clearly makes no sense. Here endeth the lesson.
I feel there is a need to re-think the way in which resources are allocated (from a holistic perspective) before we can reap big benefits from a 64-bit architecture. To a large extent 32 bit programmers had it easy - any memory address is a single register value - which was far easier to manage than the previous generation of baroque memory models where programmers had to consider system level minutia in order to ensure their programs were efficient. (Read Bentley's "Programming Pearls" if you want a superb example.) This simplicity was, in my opinion, central to the overwhelming success of 32 bit processors.
In order to exploit 64 bit address spaces it is imperative that the conceptual model within which application developers wave their cabalist wands doesn't become polluted. At the moment, I feel the future lies in the widespread adoption of generics where additional settings (say specified maximum sizes for linked lists) would allow compilation to use short representations of memory offsets (in place of pointers) with the added advantage that this should force locality of reference and pave the way to "page-miss prediction" which promises still further performance advantages.
P.S. Thanks for the hint about EROS - I was aware of it existence. Another one worth a mention is POST, (which I played about with for a bit but then discarded as a nice idea with a flaky implementation.)
making the holy grail of direct manipulation of persistent data structures a realistic proposition.
IIRC, this *was* done in multics.
Large pointers into small blocks of storage seems wasteful somehow.
Well, there's only one problem with your assertion... the Itanium already is out, and the Itanium 2 is close to release. OEMs are already building Itanium 2 boxes.
And for that matter, those Itanium 2 boxes are fast. On the SPEC CPU2000 benchmarks, the two fastest boxes are 1ghz I2s, and the next six spots are held by boxes running POWER4s (all running at >1ghz), Alphas, and a coulpe of SGIs. And there are a large number of vendors who have already committed to creating IA64 versions of their software from Microsoft to Oracle. Pretty much all of the big names have signed on.
Is anybody even planning on selling a server with Hammers yet? Has AMD even given anybody any silicon to play with? Intel was giving out development samples of the Itanium over two years ago. Intel might not have the reputation or experience of Sun or IBM with high-end servers, but they've certainly got more than AMD who have never had a successfull server line before. It's obvious you're a fan of AMD, but don't let your biases get in the way of reality.
Don't forget that the 64-bit data will be coming from a wide memory bus, so there is essentially no extra overhead for getting 64 bits at a time. For many data structures (for instance an array of 32 bit integers) there is no additional overhead.
However, your basic point is right, just as it was for a doubly linked list of shorts on a 32-bit architecture. Larger pointers, and some level of data bloat (ints will now be 64 bits, for instance) are to be expected.
So, it is not so much that "resource reallocation must be rethought", it is simply that many applications don't yet need 64-bit power. The immediate adopters will be areas like scientific processing/visualization, CAD/CAM/CAE and large databases (this is the enterprise server role AMD is hoping Opteron nails). CAD users have been hard up against current addressing limits, and will welcome the ability to handle larger models. A little extra bloat is in the noise, especially since the whole point is to address massive amounts of RAM. The SUSE implementation allows 512 GB of virtual address space per process, for instance. Hammer's SMP capabilties and scalable memory architecture are just more icing on the cake.
"Normal" users can buy Hammer systems and run 32-bit software/OSes just fine (faster than any P4), then upgrade to 64 bits when they need it. People will find ways to use all that power, natural speech interfaces come to mind. Games will probably push the 4 GB barrier sooner than you'd think as well.
By the way, the claim is that 64-bit code for the Hammer will run 30% faster than the equivalent 32-bit code. This is due to x86-64 having more general purpose registers among other things.
I think that x86-64 is a brilliant move on the part of AMD, and if Hammer performs as advertised AMD will take major marketshare and profits from Intel. I can't wait to get my hands on a system, myself. :-)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
I think another reason why Itanium CPU's haven't been accepted is their stratospheric prices.
When the price of the Itanium 2 CPU is somewhere between US$1,000 and US$3,000, no wonder why there's not much interest nowadays. My guess is that AMD's X86-compatible chips using the Hammer core design will probably be at most US$550 to US$600 in price for the fastest versions.
Actually AMD has managed to take 10% of the low end server market with their MP chips.
Its not much of a foot in the door but its something that should allow them to push Hammer into the market.
Besides if all of your 32 bit code still works on the Hammer (and runs fast), along side 64 bit code, then what's to prevent this chip from making a good entry into this market?
Not true at all....
1: a single CPU has to sit in wait states at some point holding up everything, in a 2 CPU system one CPU can frequently continue (try running windows NT with 2CPU's there's a big difference in smoothness!), you can set the afinity of processes so that one CPU is always left doing the dirty work and the system doesn't get clogged up.
2: a single CPU has a single cache shared by everything, when it page faults it page faults,
In theory you should have less problems with page faults and cache misses on a 2 CPU system.
a very cut down example, here thread 1 has code with a lot of page faults, thread 2 is compleatly page alighed and doesn't page fault.
Thread 1 CPU 1 page faults causing a slowdown on CPU1
Thread 2 doesn't with no CPU slowdown.
On a 1 CPU system
Thread 1 page faults, swap to Thread 2 no page fault, swap to Thread 1 page faults.
3:You can have seperate databusses &co for each CPU giving you twice the memory bandwidth. etc.......
4: If investement was placed in the area (see cray, or mosix!) 2 CPU's would be a hell of a lot faster than 1, infact 2 CPU's would be a kids toy and home machines might have tens of CPUS/GPU's, with decient process/thread management and all the stuff that PC's should do. Why not max out SMP and parrell processing, there'd be a hell of a lot better AI's and smoother running machines out there if they did.
In 20 years time if my PC? isn't running at least 20,000 threads and at least 1,000 concurrent threads then I'm going to be upset.
BTW.
Why are you storing all your data in RAM? you should be using a fast HDD.
thank God the internet isn't a human right.
> On the SPEC CPU2000 benchmarks, the two fastest
> boxes are 1ghz I2s
That's only true because of Itanium 2's floating-point performance. Real server workloads don't use floating point. For a slightly more realistic workload, look at the SPEC CINT numbers. There, the 1GHz Itanium 2 falls behind 2.4GHz Pentium 4s and Xeons.
Furthermore, none of these SPEC bencharks are nearly as memory-intensive as real server workloads. That's where Itanium really gets Hammered.
Some points:
1) PCs are the fastest machines you can get until you get to workstations costing several times as much. None of the low end Sun or SGI machines can touch a good dual proc PC for performance.
2) PCs are pervasive. If you aren't rich and want to use your machine for some prosumer video editing, what are you to do? PCs allow people who otherwise could not enter this field to enter it.
3) RAM is dirt cheap.
Thus, if the only thing stopping PCs from being good low end video editing workstations is an artificial RAM limit, then why not move to 64 bits and get rid of it?
A deep unwavering belief is a sure sign you're missing something...
propper hardware or setup a processing farm.
>>>>>>>>>
I don't know if PCs *aren't* proper hardware. PC platforms today are very powerful. Let's compare a dual processor Hammer setup to a dual processor Sun Blade 2000. The Hammer clearly wins in the CPU speed department, the UltraSparcs in the Blade already lab behind a high-end P4. The Hammer wins in memory bandwidth (5.4 GB/sec vs 2.4 to 4.8 GB/sec). The Hammer wins bus bandwidth (6.4 GB/sec per processor vs 4.8 GB/sec). The Hammer, if equiped with a relatively cheap Quadro 4 graphics card, is extremely competitive (within 10-20%) in the graphics department. So, for something like $6000 you can have a digital video workstation that rivals a Sun costing many times more. If Hammer were 32-bit, it would be a huge lost opportunity for the digital video market.
A deep unwavering belief is a sure sign you're missing something...