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.
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?
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.
For good or for ill, backwards compatibility is usually necessary in order to insure rapid acceptance and usage.
."
Imagine you are a software company. "We have to retrain all our programmers, buy new compilers AND ditch our old codebase? Can we still write for the old stuff for now? Good . .
I would bet dollars to doughnuts that if DVD players were incapable of playing CD's, there would be quite a few unhappy campers. The relation is the same -- slowly phase out the old while promoting the new.
It had nothing to do with x86 compatability and whooped on all x86 chips on every benchmark that was out there but its all but dead now.
And now you're saying a architecture that doesn't beat the current crop of x86 chips in performence, breaks compatabilty with the x86 architecture, and costs 10 times as much for similar capabilities will somehow succeed?
Once you break compatability with vast amount of software that is out there for x86 you're suddenly no better than all the other 64bit chips that have been out there.
Why go with a relatively untested IA-64 arch when i could go with a Sun, IBM, or SGI box who have all been 64bit for years and have no x86 baggage at all? I'm certanly not saving any money going with Intel's chip plus the other 64bit architectures have much more software support in compairason to IA-64.
As a customer if i buy IA-64 and it fails in the marketplace and support dries up, I'm left with a fairly useless box that can only run the few programs made specifically for IA-64 but if i buy x86-64 and it fails in the market i still have a very usable x86 machine and tons of 32bit software to work with.
SuSE made the 64-bit hammer patch and submitted it to the gcc group a long, long time ago. 'Course, no one cares because it was SuSE and not Red Hat or debian. *scowl*