Mandrake To Support AMD's Hammer
ruiner writes "Mandrake has announced their intention to support AMD's Hammer with a 64 bit version optimized for the new CPU. Redhat is also rumored to be following Suse's lead. 'This new generation of AMD Athlon and AMD Opteron processors is extremely exciting. A version of Mandrake Linux dedicated to these powerful 64-bit processors can certainly accelerate MandrakeSoft's growing adoption in the Linux corporate market' said Jacques Le Marois, CEO of MandrakeSoft."
from the hammer-time-joke-goes-here dept.
Followed by a press release from AMD and mandrake saying "can't touch this!"
I'm not knocking Hammer, but why does everyone act like the Itanium and Hammer versions of Linux are the first 64 bit versions? I was running 64 bit Linux several years ago on my Multia!
Once you have GCC that will compile for the target arch, and you have the needed changes to Linux to support that arch, why is it more than bunch of builds to get a 64 bit version? Many (perhaps even most) apps are now 64 bit clean (unlike certain other criminal OS's).
Why does everyone ignore the MIPS and Alpha versions?
(and OT: When will a MIPS version of Linux with full support for the extra hardware in an Indy come out?)
www.eFax.com are spammers
For those who don't know, because its very unclear from the article, Suse was the first (or at least before Mandrake) linux distro to announce Hammer support.
Check it out here
-Spyky
Why do they allways use the word "exciting". Do they copy and paste from each other?
When his defense asked, "Which computer has Jon Johansen trespassed upon?" the answer was: "His own."
Talk about how people say MIPS and Alpha is dead (just a little trolling) - who honestly uses or knows of someone using a 386 anymore.
Why don't all distro companiesstart atleast compiling for 486 and also have at the least a distro that is compiled entirely for, say 586 (like Mandrake).
I don't understand why companies like RedHat (who make a great solid modern distro) don't make available for the more modern processors a distro optimized for it.
Why sacrafice new technology (speed) for the old and thus making the new run at the speeds of the old?
They're not crowing about the fact that they can compile for these systems, they're crowing about the fact that they are going to compile for these systems, and support them. Since compiling code into working binaries and supporting those binaries is what Mandrake does, I think they're justified in crowing about this. As a big AMD fan, I applaud Mandrake for this, even though I use and support Debian myself.
Slackware and Redhat and SuSE may or may not support this platform directly, I don't know. It's certainly not guaranteed. There are plenty of platforms they don't support, even though they could. It's probably going to depend on whether they think they can make enough money off of it.
And yes, Debian will almost certainly support the Hammer as soon as we get our hands on some. But then we're insane, and support everything we can. Who else still supports m68k and ARM? Who else is _adding_ support for HPPA and Super8? We do it because it's fun, not because we're trying to make money.
(As for the thing about security advisories, that's a bit off-topic, but I will say that Debian's security list is intended for Debian's users, so that they know when officially supported packages are available, and it's not our fault that bugtraq decided to subscribe to our list. Complain to bugtraq if it bothers you that much.)
MTRR == Memory Type Range Register
/proc/mtrr.
Used to set different policy (uncacheable, write-back, write-combing) to address ranges. Eg, for address ranges that correspond to PCI addresses (ie memory mapped IO addresses), by setting these ranges to write-combining the CPU will try to gather writes up into big writes to make most efficient use of IO bus bandwidth. (ie get higher MB/s out of your AGP or PCI - important for graphics).
see linux/Documentation/mtrr.txt and
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
AMD Hammer/Opteron is completely IA32 (ie normal 32bit x86) compatible - all IA32 OSes boot on it, it has a standard IA32 BIOS, applications will run fine on it. If you run a x86-64 OS, then you will be able to run both 32bit and 64bit x86-64 software (side by side).
/guess/)
/emulated/ in silicon and hence slow
c le.pl?sid=02/06/26/0116225
Ie x86-64 is:
- IA32 (8086 mode et al too - i
- standard IA32 BIOS
- additional x86-64 mode
Apparently 32-bit Linux and Windows booted almost first time on early silicon, and they've had absolutely no 32bit compatibility problems - it all works. then it took just a week for AMD to get linux to boot into x86-64 mode (iirc from the talk linked below).
IA64 / Itanium on the other hand is a completely new architecture:
- completely different instruction set
- completely different ABI
- new weird "look it does everything" BIOS (EFI)
- IA32 is
There's a good talk by an AMD engineer on the AMD Hammer arch. given at the recent kernel summit at:
http://ksmp3rep.sf.net/KSMP3s/amd64.mp3
found amongst other kernel summit talks at:
http://linuxkernel.foundries.sourceforge.net/arti
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
http://saveie6.com/
At the moment, only the new 1.0GHz Alpha EV68 chips are faster then the current P4 processors, and the Itanium and Athlon are right up there as well. The rather substatial lead in FP performance that the Alpha used to have has virtually disapeared these days when compared to x86 chips. The very fastest EV67 chips are slower then the fastest x86 chips (note: I'm using Spec CFP2000 for comparison here, if you know of any FP benchmarks that run on both platforms I'd like to hear about them).
.18um process. Alpha still gives more performance with fewer engineering resources than any other chip, and EV7 will only widen the gap.
As for the future, Alpha's time on this planet is very limited. EV7 is still supposed to come out, and I've heard from reliable sources that it should post some very impressive scores for floating point due to it's HUGE memory bandwidth. However Intel's Itanium 2 is also supposed to post some rather impressive scores (they're talking about 1300-1350 in Spec CFP2000, which would put it ahead of the current champion Power4 processors from IBM). AMD's Hammer won't be any slouch either, as it's on-chip memory controller should boost it's score quite nicely.
This is a good summary, except that ignorant slashdotters reading this might not realize how far ahead P4, Alpha, Power4 and Athlon are in front of all other CPU architectures (i.e. PA-RISC, US III, Itanium1, MIPS, and most especially G4*) in single-CPU SPEC performance. Just to be clear: Alpha's performance is still at or near the top.
* no, there's no official G4 SPEC entry (because Apple is too chicken), but c't benchmarked it and boy does it suck. SPECint performance on par with a 933 MHz PIII, and SPECfp on par with a 500 MHz one.
Second, you probably haven't seen the leaked slide of SPEC scores for the 1250 MHz EV68 (they should be official at spec.org real soon now), which put it almost precisely equal to 1.3 GHz Power4 SPEC scores, despite not having the dubious advantage of 128MB L2 cache (under normal operation the Power4 cache is shared amongst 4 or 8 cores, but for SPEC one core gets it all).
Third, EV7 will have a substantial lead in SPECfp upon release (and might briefly take SPECint as well), although there's no doubt that Power4 and P4 will continue to improve, and Itanium2 on SPECfp and Hammer on SPECint will also be contenders.
But the most shocking part of all this is that, unlike Athlon/Hammer, P4, Itanium and Power4, Alpha is achieving all this performance on someone else's standard fab process (rather than tweaking the process to fit the chip design, which is a huge huge help; compare performance of those architectures where the designer owns the fab--P4, Athlon, Power4, Itanium--to those where it doesn't--PA, MIPS, SPARC). And, unlike current Athlons, Hammer, P4s since January, and Power4, it's an old
Like it or not, Alpha is dead. It's been sold many times and basically salavaged for scrap (Intel now owns most of the old Alpha technology). You're mentioning Titanic is actually quite approriate, because that was the last gasp for Alpha. If you look at new movie production, they're moving to x86, just like all the rest of the world. MIPS might have a future in the embedded space, where it's currently second to ARM. Alpha technology might have a bit of a future in Intel's IA-64 (though I'm skeptical as to how well they'll be able to integrate the pure-RISC Alpha technology into the VLIW IA-64 technology), but as a product on it's own, stick a fork in it.
Again, you're correct. But the death of Alpha is entirely to do with marketing and zero to do with performance. Before Power4, Alpha was the clear single-CPU performance leader in the 64-bit market, and if the Alpha team had gotten more resources and support from Compaq, Alpha's performance lead would still be huge.
That said, all of this seems slightly academic considering that for the past year and the forseeable future, the SPECint leader has been and will be a commodity x86 chip costing ~$600 (against 64-bit competition costing 100x that per CPU). The P4 seems to have taken on the Alpha mantle: world-beating SPEC performance with a high-clocked small-die chip utilizing innovative microarchitectural features and excellent circuit-level design. That it has done so despite being hobbled with the x86 ISA is even more impressive.