SuSE Submits Enhancements for AMD Hammer
ackthpt writes "SuSE has this press release as they are submitting enhancements to the Linux kernal particular to the AMD's x86-64 processor instruction set. Anticipated for 2.6 kernel, some enhancements may appear in 2.4, as development is only beginning on 2.5. AMD's take on the announcement as well.". nik notes that SuSE join NetBSD in having ports to Hammer. Usenix members can see the paper Wasabi's Frank van der Linden wrote about the porting effort.
Take a look at GCC main page and you'll see a note on the x86-64 port contributed by SuSE.
--
The Cap is nigh. Time to get a fresh new account.
They are tentatively shceduled to be released at the end of 2002. I would wager that they won't be available in force to the common man until sometime 1st quarter 2003.
This is called a SIMD (single instruction, multiple data) operation. It's what MMX is all about.
It's usually not worth doing this if there's no SIMD hardware support, because the time wasted loading your values and then separating them isn't compensated by the gain in speed. Of course there are special cases (like when dealing with bit strings) where this is used by definition (and will be an improvement).
According to one of the developers from SuSE who worked on this (and demoed SuSE running under one of the x86-64 simulators at a recent OxLUG talk ), SuSE and other porters did indeed make suggestions to AMD as to details of the architecture which were taken up by AMD.
No, you can't, unless you can guarantee that the result from the lower half of the operand will not affect any bits in the upper half. For multiplication this will happen all the time but for addition it will happen whenever the lower operand carries over.
Besides, 64 bit operations are higher latency than 32 bit operations, and the cost of all of the shifting and masking to separate the results would be very high. It would be much faster to just do two separate 32 bit operations.
SIMD is a different story since the hardware assembles and reassembled the operands, and executes them on separate executions units.
http://www6.tomshardware.com/cpu/02q1/020227/
:o
Interesting - they tested one of the Hammer CPUs on Suse, but they only ran XP in 32-bit...
Not necessarily. Recall from this slashdot story about this article the intel compiler also showed similar results over GCC when targetting the Athlon.
GCC's mission statement is not the running time of executable code, we've recently been having a thread about it on the plan9 mailing list (or comp.os.plan9). (although ours started as a flame from Thomas Bushnell that plan9's 8c was nothing more than a "cute toy" - 8c is more concerned with compilation speed than execution time where it beats GCC hands down, if you want raw execution speed look elsewhere).
It could well be that Intel's compiler will show similar performance gains over GCC on the Hammer.
I wonder if every problem will start to look like a nail when the hammer claws it's way out of the AMD tool box.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Oh, I have no doubt that Intel's compiler will produce great 32 bit code on Hammer. Hammer is just a proliferation of K7 with 64 bit extensions, and AMD knows how to optimize their hardware for that compiler (they use it when submitting their SPEC scores).
But Intel's C compiler won't generate 64 bit code, which means that AMD has to rely on GCC for 64 bit applications. So any performance advantage of 64 bit is more than nullified because there's not a decent compiler for it.