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.
I can't help but feel that "real"
manager's will just say Itanium plus winXP
despite
the advantages of Hammer and RedHat
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)
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.
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
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.
Nothing's wrong with SuSE... But reading your two headlines says to me that
1. is a story about the redhat distribution
2. is a story about AMD's processor
IMHO the iconing is correct!
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
That and I don't think /. has the SuSE logo on file. ;)
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.
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 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.
There may be best practices, but there's no standard I am aware of that says you can't use unions or casts.
I swear people in this thread haven't done much C programming or worked with large codebases. The thing is, it only takes a couple bad/ignorant C programmers to mess up your app. In order to truly say it's 64 bit clean you have to test it. A large app may have had several dozen different programmers or more over its lifetime. Think about what MS would have to go through to actually ship a 64 bit Microsoft Word. One person can not browse a million or more lines of code and give it the 64 bit thumbs up.
Hell, believe it or not sometimes people just make mistakes. C lets you write bad code. There may be a lot of work involved in testing all the code paths. Ideally it would be just a recompile, but to generalize and say "should just be a recompile" doesn't match the actual C/C++ code I have worked with.
I am being realistic. You are being idealistic.
-Kevin
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)
Juiz de Fora IRC