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.
good to see that proprietary standards arent taking hold these days
hehe, the hammer.
im sure it'll be just as successfull as the xeon
I can't help but feel that "real"
manager's will just say Itanium plus winXP
despite
the advantages of Hammer and RedHat
trying to hammer the competition into the ground i'd say ;)
US is now divided as the "Red" and "blue" states. Red States = communist countries. Coincidence? I think not
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.
SuSE support AMD Hammer for a While, Does Redhat see that AMD Hammer is worth to put money ?
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.
When 64 bits computers are obsolete, infact computers are obsolete, where we live in a big brother world were every body are cyborgs with DRM, Paddilum, Carnivore, DRM, with out linux. (linux died).
Any way, on September 11th, 2139, The Cyborg Richard Stallman 0.5.6. (Still under devlopment) anounces Gnu H.U.R.D 0.0.1 for the Amd Opteron Processor over 130 years too late!
Its true geeks, read it and weep.
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
The specs are still vapourware... Let tomshardware, anandtech, firingsquad, etc play with it for a while. Then, we will see what it is worth. www.specs.org are perhaps more serious, but a LOT less fun
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)
I don't know what Intel was smoking but you can't just expect the market to completely adopt a New cpu standard such as Itanium, who's going to buy it without a large set of code that will run on it?
This is why the Hammer will come out first, Amd is smart enough to realize that the first few years of hammer, people will need to run some things that there are no 64-bit programs for yet.
Mad props to Amd for not having stuck their heads where the sun doesn't shine this time around!
You know, I have one simple request. And that is to have sharks with frickin' laser beams attached to their heads!
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.
64bits mean, More threads and processes can run
if you give each process 4mb in a 32bit environment then you soon run out of address space for all the processes, giving them 4mb in a 64bit environment and it wil take a hell of a lot longer.
More system resources can be allocated without exhausing 32bit number range.
IPv6 will be quicker on a 64bit system, even if you only take into account that an IPv6 address with fit into a 64bit word.
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.
Your point #2, and final closing comment would
be valid, except for the fact that the AMD
Hammer has different memory models available,
and gcc works with them. This allows a 64bit
application to use 32bit pointers, thus giving
the benefits of the 64bit wide data registers,
as well as the larger register set, while
retaining 32bit pointers if need be.
I suspect that most naysayers about Hammer simply
are people who have not, and probably wont actually read the AMD architectural manuals, and
will instead merely assume things which are
totally incorrect.
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
Neat to have Redhat following Mandrake for once...
Too bad I can't attend to this demo.
Its a yahoo address. You think he used his real info to make it?
He's only anonymous cause he dosnt have a slashdot account.
Step 1: Think.
Step 2: Express thoughts
Combine this with Linus' feelings and Hammer is looking better and better.
:)
As if the average slashdotter needed something other than the gospel according to Linus to convince them
This comment was generated by a Squadron of Ultra Ninjas
Hi Slashdot,
its fun,
now RedHat supports AMD with SuSE development
inside, they get a RedHat logo, the story
"SuSE Submits Enhancements for AMD Hammer"
gets a AMD logo.
Whats so bad with SuSE..;-)
Mike
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!
This is a non-problem - memory is cheap, and if it is not cheap enough to store your linked list of a bazillion ints then you need to change your data structure or algorythms.
However, the biggest performance disbenifit from going 32->64 bits will cache misses. The major performance bottleneck on CPU intensive apps these days is how often you get a cache miss as opposed to a cache hit; by making things twice as big, you're cache will only hold half as many of them.
On those platforms which let you choose if you want to be 32 bit or 64 bit app on a per-application basis, I'm using this rule of thumb: "32 bits unless benchmarks prove me wrong, or I need the address space".
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
1. 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.
Well, EROS does just this on 32 bit systems. (Thankfully), I haven't had to touch EROS much yet, so I don't really know how it handles it, though.
Of course, given there is no driver for hard drives, etc (and last I heard booting the kernel didn't work on systems with more than 256 megs of memory), the fact that it supports persistent state is not particularly useful. But someday...
2. 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!
That's just a bad data structure. What you want is to have each node of the linked list have a fixed size array (say 1-16K, depending on local circumstances), and a couple of extra integers telling you where the start and stop of the arrays are. This is much, must faster, and the memory overhead for the extra pointers (be they 32 or 64 bits) is quite small. It's also quite trivial to program.
Excuse me, the data structure I just described is for queues, not general lists (queues tend to come up more often than list for me so that's what my mind jumped to, I guess). But you see my point, I hope.
I can't really think of a case where a 400% overhead is too much, but 200% is OK.
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?
:) Moderators should be filtered for their sense of humour. Who moderated this down?
My blog
Yeah, your solution is great if you don't (Or rarely) insert or remove items from the queue. Of course as soon as you want to insert a new record in the center of the queue, all hell breaks loose as you start shifting each item down one position in your array. You knew this, of course :)
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.
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.
In my opinion, in order for 64 bit architectures to reach full potential, a change of software structure is required.
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.
> Its like putting a hot-rod engine into your
> daddy's Oldsmobile and keeping the original
> tranny. But yes, it works.
That would probably be just fine. They had pretty good tranny's back then
It has been statistically shown that helmets increase the risk of head injury.
"I am sick and tired of this x86-64 bullcrap... 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."
I'm sure it has nothing to due with the fact that most people are running on a x86 based system. And changing everything to a new architecture - practically a cake walk. And so cheap to do too! No, I'm sure it's all an underground plot. AMD is paying everyone so we'll all buy their chips. And of course AMD has the money to do it too - not like that poor little Intel, who can hardly afford a multi-billion dollar ad campaign. And the government must be in on it too. That's why the government's black helicopters are over my house right now - they are looking for my Athlon! Egads!
"Sure, x86 is great due to all the applications out for it, but in all honesty why can't we move away from it?"
Sun, IBM, and Compaq have been asking people that for years...
The applications are the reasons INTEL can't move away from x86.
"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."
My guess is you've never written a program more complicated than "hello world!", if you've even been that far. Ever ported anything to another architecture? Or OS? Do you have the slightest clue about the magnitude of work involved in creating a compiler that takes advantage of Itanium?
It couldn't possibly be that corporations might still need to use some of that x86 code. *cough*windoze*applications*cough* And a less expensive way to ease the transition to 64 bit, that still allows us use the billions of dollars of software we already have? No, I can't think of any reason why companies would want that...
Seriously - you're either really misinformed or being paid to post this garbage. Intel definately is NOT "the company willing to shed the baggage". 64-bit chips have been out for years - Intel is just trying to catch up. Try IBM, Transmeta, or Sun - if you want innovation, Intel is definately NOT the company to look to.
I hate apple and all there evils but,
they are SMPing all ther profesional power macs,
Hopefully that'll give the PC arena a kick. (better workstation SMP mobos with more that 2 sockets please!)
thank God the internet isn't a human right.
Yeh having to use a crappy PC or Mac workstation instead of the high-end machine they should be using, poor buggers.
thank God the internet isn't a human right.
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.
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.
Unfortunately there is a lot of broken code out there, but in the past 5 years people seem to have got a bit better at following the C standard. My guess is that the only code (that doesn't primarily involved reading/writing binary data) that will need much more than a recompile are programs that were written pre-ANSI, i.e. code written before 1990. There isn't TOO much of that around anymore.
Not that IA-64 is all that great, either. From the looks of things it's more or less a poor-man's Sparc. Not that a cheap Sparc is a bad thing, I guess....
Can you imagine a Beowulf cluster of these things????!!!???
(Sorry, had to do it)
Check out here: http://www.x86-64.org/faq/Port There's no evidence at all to support that code compiled for 64-bit will run any faster, except for programs that address huge amounts of memory (but this is a very small percentage of the market)
That's what i said,
a int is usually a machine word so don't use it where size is important.
use long for 32bit.
Juiz de Fora IRC