athlon64 - reccomendations?

[Blue_MiSfit]

hey all,

So I ended up getting rid of my old board and CPU (donated them to my mom's machine), and picking up an athlon64 2800+ and another 512 megs of ddr400

Anyway, I am going to install XP 64 bit edition alongside XP pro, and was wondering what (if any) changes I could make to take advantage of my 64 bit chip in windows64bit edition.

Specifically, are there builds of VirtualDub/AviSynth/XviD/FFDShow that are optimized for the AMD64? or even a native 64 bit binary?

I'm not too up on compiling things under windows, but if ppl think it might be worth it I would be willing to try.

Suggestions/comments etc welcome.

~misfit

[Sharktooth]

Uhm... it's not all about "compile for 64bit"...
Some components of those softwares are written in assembly, so they need to be ported and optimized for the x86-64 instruction set and then compiled with a x86-64 compiler (yasm for example).
Fortunately the port is really easy but the optimization is always tricky. Also because the athlon 64 cpus has more registers than standard x86 cpus. See the Figure:
http://www.devx.com/assets/amd/5929.gif
Then, even the C code must be ported, but the process can be "automated"...
More info about porting 32bit code to 64bit code are available on the AMD (http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252,00.html) website.

[BoNz1]

There is a x86-64 port of XviD already. But, it is not in the cvs yet. Also, it will probably be a little ways away from working in windows right away even once it is.

[mediator]

I think you will never see a big boost in performance for XviD when going from 32->64 bits. Alot of time critical thing is mostly done already in 64/128 bits (MMX/SSE2) on 32 bits CPUs and what does not fit for processing with MMX/SSE2 will not be a lot faster just because there are more registers (well a bit, maybe).

I wouldn't expect too much... (sorry if I have to disappoint you).

But this doesn't mean that nobody should try to prove the difference :)

[Blue_MiSfit]

I had figured as much regarding xvid, but i wonder about other things like avisynth, plugins, ffdshow etc... I thought I saw a 64 bit build of vdub sitting somewhere...

Just wondering if theres ANY tools I can use to speed up my process chain...

[Joe Fenton]

64-bit VDub is here (http://prdownloads.sourceforge.net/virtualdub/VirtualDub-1.6.1-AMD64.zip).

Linux has a 64-bit version of the xvidcore as that it all it uses for decoding/encoding. I haven't seen any 64-bit versions of the xvid Windows codec. Actually, most of all the video stuff that was already available for Linux has been converted to 64-bit - xvid, ffmpeg, a52dec, libmad, lame, etc..

I would be nice though to have Linux versions of VirtualDub and AVS. I really miss those sometimes.

[Blue_MiSfit]

I have considered switching to linux for doing my encoding work, but decided against it for those very reasons - no avisynth and no vdub.

Someday perhaps we will have the equivalent of avisynth in linux... and all in delightful 64 bit

[Sharktooth]

Originally posted by mediator
I think you will never see a big boost in performance for XviD when going from 32->64 bits. Alot of time critical thing is mostly done already in 64/128 bits (MMX/SSE2) on 32 bits CPUs and what does not fit for processing with MMX/SSE2 will not be a lot faster just because there are more registers (well a bit, maybe).

I wouldn't expect too much... (sorry if I have to disappoint you).

But this doesn't mean that nobody should try to prove the difference :)
Uhm... i think there will be a huge performance boost instead...
Athlon 64 has 2x SSE(XMM) registers (16 registers vs. 8 of the 32 bit CPUs)...

[LordRPI]

It's not always the number of registers that will speed things up, but I'm sure AMD is smart enough to account for this on the dispatch/execution side of things.

Remember that rule #1 of modern processor design is: Smaller is Faster.

[Joe Fenton]

Originally posted by Blue_MiSfit
I have considered switching to linux for doing my encoding work, but decided against it for those very reasons - no avisynth and no vdub.

Someday perhaps we will have the equivalent of avisynth in linux... and all in delightful 64 bit

Actually, VirtualDub using AVS does work under WINE in Linux. It's a little finicky, but does work for most folks. There's a thread on that in the Linux section of the forum. Unfortunately, that means it is just 32-bit, but it's better than nothing.

Personally, I like to use dvd::rip to convert DVDs into AVIs in Linux. It's really very similar to Gordian Knot (which uses both AVS and VDub).

[EnergeticBence]

Just remember the P4 with SSE2 is very fast, personally I'm not convinced 64bit code would have much advantage over SSE2. ( And intel has such amazing compilers for the P4. )
There is a very nice comparsion of the x86 and the x85-64 code on the A64 here:
http://www.cpuid.com/K8/index.php
I think those might be quite realistic results. ( But then again L1-L2-memory architecture is always a question, as well as multithreading. )
10-20%, about same amount of gain as from SSE2/3+multithreading. Don't expect miracles on the average user level, incidentally the K8 is NOT really the best in desktop. 2-8 way servers and workstations it is unbeatable by anything x86.
Let's not forget xvid doesn't like P4 at all, ( I wonder why CCE does though. ) so I think having an A64 is a good thing but not as good as to warrant a change from P4. ( I'm quite happy with my P4 3.0. )
And recompiling things for A64 is a good idea. ( Same for P4, it was shown intel compilers with the right flags can result in 5-10% gain vs default. )
The whole point of 64bit is the 4GB memory limit, really.

[Joe Fenton]

Originally posted by EnergeticBence
Just remember the P4 with SSE2 is very fast, personally I'm not convinced 64bit code would have much advantage over SSE2.

That makes little sense as the AMD64 has SSE2 as well. In 64bit mode, you get twice as many registers to use with SSE2, so it's a clear winner. Twice as many normal registers, and twice as many registers for SSE/SSE2. The x87 FPU and MMX stay the same between modes, so you wouldn't see any gain there.

[EnergeticBence]

Do not forget: the P4 has 2 SSE2 FPU pipelines, and real time clock of 3.4 vs say 2.2 Ghz. ( Not top models of course. )

Check out any synthetic test, and you'll see P4 with SSE2 wins vs A64 with SSE2 only because of it's higher clock. Clock for clock A64 is surely faster, but P4 is STILL 1Ghz faster on average.
There was a very good video encoding test a while back.
http://www6.tomshardware.com/cpu/20040601/socket_939-20.html
http://www6.tomshardware.com/cpu/20040601/socket_939-21.html
( And I know about the people who do not trust THG. )
You cannot judge CPU speed based on registers, that's something of an ideal case scenario, that NEVER happens in real life.
There are the sandra sythetic tests, and even without SMT P4 is on par with A64, with SMT, it can theoretically almost double the output, in reality it doesn't translate into more than 20% TOPS. There are a lots of limiting factors.
It seems like video encoding is often memory bandwidth limited anyway. Here is another, slightly older test though.
http://www.digit-life.com/articles2/intelamdcpuroundupvideo/index.html
http://www.digit-life.com/articles2/intel-prescott-1066-unofficial/test2.html
Do not get deceived by model numbers on athlon ( Or P4 for that matter. ) They do approximate the difference, but you have to keep track of the real clockspeed too.
As far as I know any attempted tests under windows XP 64bit beta? ran much slower than their 32 bit counterparts, there are still issues to figure, and the future is of multithreading/multicores anyway. ( Something that already gives the HT P4 about 20% benefit in optimized apps. )

[chilledoutuk]

When it comes to bang for buck the athlon 64 wins you can pickup a a64 3400+ for the same price as a 3.2ghz prescot. at stock clock speed there pretty well matched apart from the prescot doubling as a space heater due to the clock speed.

what this ultimatly means is that you can overclock the athlon 64's on air quite easily and still keep safe temps when encoding.

Whereas the p4 to overclock you really need watercooling if your going to be doing encoding.

gamr had some xvid builds optimised for amd64 under 32 bit os's but his site is dead now (well at least last time i looked). when ms finaly release 64 bit xp then they will be more motivation to optimise for the amd 64 architechture.

[dragongodz]

incidentally the K8 is NOT really the best in desktop.
careful, your bias is showing. :)

and you'll see P4 with SSE2 wins vs A64 with SSE2
theres also another thread around here somewhere that shows that when the intel compiler is used SSE2 was disabled for AMD64 cpus even though they support it. intel's compiler would activate it for real intel cpus only. hmm now thats fair isnt it. a guy went in and edited/removed the cpu check and the test exe then used SSE2 on AMD64 and got a huge speed increase.

There was a very good video encoding test a while back.
which was ran on the 32bit version of windows. does that make a difference ? yes actually it does. have a look here
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=1884&p=17
and compare the lame 32bit and 64bit test.

theres also another thread that i linked to a test with zip(linux version) which showed something like 40%-60%(was quite some time ago so i forget exactly) speed increase when 64bit compilede and ran on a 64bit OS.

so in reality a lot of factors will decide how fast different programs will run. the fact that Xvid uses nasm and can use yasm(64bit version on nasm basically) for some of its routines suggests there should be a noticable speed increase when ran on a 64bit OS. however that wont be true of all programs.

[MacAddict]

Wow, thanks for that link showing the LAME encoding test dragongodz. M$ clearly seems to be delaying the 64bit release to allow Intel to catch up with AMD, this should come as no surprise.

[trbarry]

The big factor is that P64 supports SSE2 so more assembler things will be optimized for this expecting some machines will actually be able to run it.

I can't comment on how fast it is but as an assembler programmer I want one simply because it is so convenient to have more registers.

- Tom

[Sharktooth]

Not only that but a 128k L1 cache a low latency integrated dual channel memory controller, 1GHz HyperTransport etc. are like a turbo boost when working with large data sets (provided you use fast RAM modules)...
It only depends in how the coders can take advantage of those resources (read: optimizations).

[Prettz]

I read somewhere that under 64-bit long mode all the MMX instructions are no longer usable, and are replaced by 64-bit versions of some of the other x86 instructions, so you're left with 64-bit GPRs and SSE. Is that true?

[mikeX]

a friend of mine reported some very dissapointing results regarding XviD encoding with transcode v0.6.12 (http://www.transcoding.org/), ~5 fps faster than my Athon XP 1800+
his specs are athlon64 @3.2, 512mb kingston running Debian AMD64 [testing]
he got much better results on xp[32bit] with gordian knot[aka vdub & avs]
HOWEVER, he used an old version of transcode, + he couldn't complete any encode since it segfaulted after a while. my guess is he screwed up somewhere when compiling either XviD, or transcode [audio encoding to ogg vorbis worked fine though, but again no spectacular speed difference, note however that cpu usage was at a about 70% (any ideas why?)]...

i'll return with more details [source, encoding settings, etc] once he gets his stuff working correctly...

[saratoga]

Originally posted by EnergeticBence
Just remember the P4 with SSE2 is very fast, personally I'm not convinced 64bit code would have much advantage over SSE2.

You realize x86-64 not only includes SSE2, but exapnds it by adding 2x the SSE registers right? They're not alternatives, rather 64 bit mode expands and complements SSE2.

[Joe Fenton]

Originally posted by Prettz
I read somewhere that under 64-bit long mode all the MMX instructions are no longer usable, and are replaced by 64-bit versions of some of the other x86 instructions, so you're left with 64-bit GPRs and SSE. Is that true?

64bit Windows got rid of use of both MMX and the x87 FPU in 64bit applications. You are supposed to use scalar SSE instead of x87 FPU, and ISSE instead of MMX.

64bit Linux places no such restrictions on applications, which is one reason 64bit Linux has been out for months. You don't have to change much to get a 32bit program to recompile as 64bit.

Note that this has nothing to do with the hardware. The AMD64 and EM64T CPUs have no trouble with x87 or MMX in 64bit long mode. It is only a software ABI issue in 64bit Windows. Perhaps Intel "suggested" to MS that it change the ABI in that manner because they intend to phase out those parts of 64bit Intel CPUs in the future for less expensive chips.

[squid_80]

Both Microsoft and AMD have said that MMX, 3DNOW etc aren't supported on windows for AMD64, but that's not exactly true (at least for the current beta). All the instruction sets which use the mm0-mm7 registers work fine. So porting xvid is a pretty simple job, especially if you start with the source for the linux AMD64 port.

For those who are hoping for a significant speed increase - don't hold your breath. Assembly code will run at pretty much the same speed whether it's in 32 or 64 bit mode. The only advantage that comes with 64-bit are the extra xmm registers and if you have a look at the xvid .asm files you'll see there's only a few functions which use all 8 existing registers, so having 8 more to play with isn't going to help much.

[Tommy Carrot]

Originally posted by squid_80
For those who are hoping for a significant speed increase - don't hold your breath. Assembly code will run at pretty much the same speed whether it's in 32 or 64 bit mode. The only advantage that comes with 64-bit are the extra xmm registers and if you have a look at the xvid .asm files you'll see there's only a few functions which use all 8 existing registers, so having 8 more to play with isn't going to help much.

Probably 64 bit mode shouldn't help much, but somehow it still does, according to Edouard Gomez(xvid developer)'s experiments with an opteron (http://list.xvid.org/pipermail/xvid-devel/2004-December/004767.html). :)

[squid_80]

...Or it could be because it's compared to an AthlonXP 2200+, which doesn't have SSE2 (among other disadvantages). A better comparison would be the 32-bit version vs 64-bit on the same system. Perhaps someone with both linux versions of the codec could do a similar test? Since I've spent the last three weeks doing a windows port, I'd be very interested to see what the difference in speed works out to be.

[evade]

I did a small test with an early version of this port to the effect of a 3% increase in speed from a 32-bit environment to a 64-bit environment on the same machine.

http://forums.gentoo.org/viewtopic.php?t=235974

I will do further testing and report here when the patch is merged with cvs.

[Prettz]

Originally posted by Joe Fenton
64bit Windows got rid of use of both MMX and the x87 FPU in 64bit applications. You are supposed to use scalar SSE instead of x87 FPU, and ISSE instead of MMX.
And then how would they have us calculate transcendal functions, though software!?!? :mad:

[dragongodz]

For those who are hoping for a significant speed increase - don't hold your breath. Assembly code will run at pretty much the same speed whether it's in 32 or 64 bit mode. The only advantage that comes with 64-bit are the extra xmm registers and if you have a look at the xvid .asm files you'll see there's only a few functions which use all 8 existing registers, so having 8 more to play with isn't going to help much.
well to get the full benefit of course sections would need rewritin of course. its like running a program that has no SSE optimisations on a cpu that has SSE, its not being use so no benefit. however once code is written to then use that feature the increase can be very noticable.

[Shinigami-Sama]

well
personaly I would say the a64 not only beause of the price:proformace raito but If you play games of the rig they will run better and _possilbe_ audio will encode faster because I've _heard_ tale of the xp64 porting jobs to the duaterboards
don't quote on that because it's _unconfimered_ but It came from a friend who works for ms :)

[Joe Fenton]

Originally posted by squid_80
Both Microsoft and AMD have said that MMX, 3DNOW etc aren't supported on windows for AMD64, but that's not exactly true (at least for the current beta). All the instruction sets which use the mm0-mm7 registers work fine. So porting xvid is a pretty simple job, especially if you start with the source for the linux AMD64 port.

For those who are hoping for a significant speed increase - don't hold your breath. Assembly code will run at pretty much the same speed whether it's in 32 or 64 bit mode. The only advantage that comes with 64-bit are the extra xmm registers and if you have a look at the xvid .asm files you'll see there's only a few functions which use all 8 existing registers, so having 8 more to play with isn't going to help much.

The instructions work, yes. The registers are not maintained across task switches in 64bit applications. So using those instructions will cause strange results depending on the operation of the rest of the system. You MUST NOT use those instruction sets in Win64 or you WILL eventually have trouble. Period. AMD and Microsoft aren't telling you these things out of the goodness of their hearts. They're covering their butts in case you complain that the official release of XP64 doesn't run your program correctly. It's your fault for using instructions when they told you specifically not to. :p

[Joe Fenton]

Originally posted by Prettz
And then how would they have us calculate transcendal functions, though software!?!? :mad:

Yes... which has been done for many decades on all sorts of computer systems. Intel has always endorsed using software transcendentals over the x87 versions as the software versions are normally faster.

If you look at the typical transcendental library used by gcc programs, it is made of software algorithms which only use multiply-add FP instructions and possibly a reciprocal estimate when avaiable.

[squid_80]

Originally posted by Joe Fenton
The instructions work, yes. The registers are not maintained across task switches in 64bit applications. So using those instructions will cause strange results depending on the operation of the rest of the system. You MUST NOT use those instruction sets in Win64 or you WILL eventually have trouble. Period. AMD and Microsoft aren't telling you these things out of the goodness of their hearts. They're covering their butts in case you complain that the official release of XP64 doesn't run your program correctly. It's your fault for using instructions when they told you specifically not to. :p

That's what I thought too. But to make sure I did some testing (running several native 64-bit programs (with MMX instructions) concurrently over several hours) and there were no errors. Then I checked further (with the help of codeanalyst) and found the operating system uses FXSAVE and FXRSTOR to save and restore the SIMD state. Which makes sense - it's easier to do FXSAVE rather than save all the XMM registers one by one.
I haven't seen anything where Microsoft specifically say the MMX registers aren't saved across task switches. They said context switches, which is a bit ambiguous and may just mean function calls.

It's not that I want to use MMX code, I'm all for converting everything to SSE. But in a lot of cases (Athlon64 in particular, P4 not so much) SSE instructions have the same latency as MMX plus memory addresses need to be 16-byte aligned. So the code ends up slower overall.

[wiak]

Originally posted by BoNz1
There is a x86-64 port of XviD already. But, it is not in the cvs yet. Also, it will probably be a little ways away from working in windows right away even once it is.
where?

[BoNz1]

Wups, wiak scroll up and see evade's post ;).

[Joe Fenton]

Originally posted by squid_80
It's not that I want to use MMX code, I'm all for converting everything to SSE. But in a lot of cases (Athlon64 in particular, P4 not so much) SSE instructions have the same latency as MMX plus memory addresses need to be 16-byte aligned. So the code ends up slower overall.

Well, either MS will change their minds and tell people they CAN use x87 and MMX in 64bit apps, or they won't. If I had to guess, I'd say that you can probably get away with it in XP64, but not Longhorn 64. However, if it fails on a future OS and you are being warned now, best to follow the warnings. Of course, you could always just update it later and tell folks to update. :D

If SSE has the same latency as MMX but operates on twice the data at once, how do you get code that is slower? Also, the alignment of data makes the operations faster because you don't have to fetch across cache lines for the data. So 16-byte aligning SSE data avoids slowdown. It's only when you don't align the data that things can slow down. That also affects MMX, but the alignment is different since MMX is 8-bytes instead of 16.

[squid_80]

Originally posted by Joe Fenton
Well, either MS will change their minds and tell people they CAN use x87 and MMX in 64bit apps, or they won't. If I had to guess, I'd say that you can probably get away with it in XP64, but not Longhorn 64. However, if it fails on a future OS and you are being warned now, best to follow the warnings. Of course, you could always just update it later and tell folks to update. :D

If SSE has the same latency as MMX but operates on twice the data at once, how do you get code that is slower? Also, the alignment of data makes the operations faster because you don't have to fetch across cache lines for the data. So 16-byte aligning SSE data avoids slowdown. It's only when you don't align the data that things can slow down. That also affects MMX, but the alignment is different since MMX is 8-bytes instead of 16.

I doubt MS will change their position. Since SSE supercedes the older instruction sets I'd say there's a fair chance they'll be dropped from future CPUs. Hence microsoft's stance.

The alignment issue is the main hassle with xvid. A lot of the data worked on is in blocks of 8x8 bytes, taken from the incoming frame which is stored in memory line by line. So every second block has data that is only 8 byte aligned rather than 16. Previously it was fine to reference any memory with operations like PSHUFW, changing them to PSHUFLW and PSHUFHW using aligned memory references is a painful experience. I know it'll probably have to be done eventually, but using the existing mmx code is easier for now.

[foxyshadis]

Originally posted by Joe Fenton
Well, either MS will change their minds and tell people they CAN use x87 and MMX in 64bit apps, or they won't. If I had to guess, I'd say that you can probably get away with it in XP64, but not Longhorn 64. However, if it fails on a future OS and you are being warned now, best to follow the warnings. Of course, you could always just update it later and tell folks to update. :D

Of course, by the time the day comes when support is dropped in the new OS or an update to XP64 and the codec stops working, most people won't know or remember why, and you'll curse Microsoft for breaking third-party products, even though they gave everyone a two-year warning.

Microsoft let the world know in 1996 that it was switching to NT in two years (obviously they were two years too optimistic), and that software would have to start conforming to NT's stringent access and protection modes. Yet we all saw how many games, drivers, and programs broke in 2k.

I wonder if it'd be more efficent to just expand the memory lines to be interleaved, 8 bytes null, 8 bytes data, 8 bytes null, etc. to make alignment simple and fast.

[Joe Fenton]

Originally posted by foxyshadis
Of course, by the time the day comes when support is dropped in the new OS or an update to XP64 and the codec stops working, most people won't know or remember why, and you'll curse Microsoft for breaking third-party products, even though they gave everyone a two-year warning.

Microsoft let the world know in 1996 that it was switching to NT in two years (obviously they were two years too optimistic), and that software would have to start conforming to NT's stringent access and protection modes. Yet we all saw how many games, drivers, and programs broke in 2k.

Exactly. Best not to try to see what you can get away with - just follow the rules. Especially since by the time the rule gets enforced, people will have forgotten how they were breaking it in the first place. 8)

I wonder if it'd be more efficent to just expand the memory lines to be interleaved, 8 bytes null, 8 bytes data, 8 bytes null, etc. to make alignment simple and fast.

Probably not. Half of making a fast program is knowing how the data patterns go and how cacheing affects it. It's probably better to change the routines so that the extra data stays in the cache so that future SSE routines have cached data. Perhaps a different layout in the buffer for macroblocks would work better.

[sysKin]

Originally posted by squid_80
A lot of the data worked on is in blocks of 8x8 bytes, taken from the incoming frame which is stored in memory line by line. So every second block has data that is only 8 byte aligned rather than 16. Previously it was fine to reference any memory with operations like PSHUFW, changing them to PSHUFLW and PSHUFHW using aligned memory references is a painful experience. I know it'll probably have to be done eventually, but using the existing mmx code is easier for now.
Actually, that's not quite right. Mpeg-4 works on 16x16 macroblocks so all data that is aligned to these macroblocks will be aligned. However, motition estimation and compensation accesses half of its data ("current picture") in 16-byte-aligned pattern and the other half ("reference picture") completely unaligned. There is no way to align the other half. Unless accessing it is also fast, we're dead when it comes to speed.

Now, I have a question: what's the point of not supporting MMX/FPU? Is Intel really going to try releasing CPUs that don't have this unit - a CPU that runs 64-bit code *only* without any (practical) 32-bit compatibility?

[squid_80]

Originally posted by sysKin
Actually, that's not quite right. Mpeg-4 works on 16x16 macroblocks so all data that is aligned to these macroblocks will be aligned. However, motition estimation and compensation accesses half of its data ("current picture") in 16-byte-aligned pattern and the other half ("reference picture") completely unaligned. There is no way to align the other half. Unless accessing it is also fast, we're dead when it comes to speed.
So that's what's happening. Understanding what each assembly function does is easy, but I don't really know where they fit into the big picture. It was the interpolate8x8 functions I was thinking of, now I know why.

Now, I have a question: what's the point of not supporting MMX/FPU? Is Intel really going to try releasing CPUs that don't have this unit - a CPU that runs 64-bit code *only* without any (practical) 32-bit compatibility?
Who knows what the story is, microsoft are just saying to use SSE because MMX and x87 are deprecated. I was just speculating that maybe they know something we don't.

[Sharktooth]

... Intel chips runs SSEx instructions faster due to the higher clock ...
That's a sort of "retaliation" from intel.

[Joe Fenton]

Originally posted by sysKin
Now, I have a question: what's the point of not supporting MMX/FPU? Is Intel really going to try releasing CPUs that don't have this unit - a CPU that runs 64-bit code *only* without any (practical) 32-bit compatibility?

Well, let me give you a serious guess - Intel is having so much trouble with keeping the temperatures down, they asked MS to deprecate the FPU and MMX so they could switch those units off in 64bit mode to drop the power dissapation and reduce temperatures.

Most CPUs these days allow the system programmer to switch off units in the CPU independently. Many also allow the units to be clocked at lower frequencies independently as well, but to get temps down Intel wants them off.

The x87 FPU is a big chunk of silicon, and MMX isn't small either. Turning them off can be a big power/heat savings.

[saratoga]

Originally posted by Joe Fenton
Well, let me give you a serious guess - Intel is having so much trouble with keeping the temperatures down, they asked MS to deprecate the FPU and MMX so they could switch those units off in 64bit mode to drop the power dissapation and reduce temperatures.

Most CPUs these days allow the system programmer to switch off units in the CPU independently. Many also allow the units to be clocked at lower frequencies independently as well, but to get temps down Intel wants them off.

The x87 FPU is a big chunk of silicon, and MMX isn't small either. Turning them off can be a big power/heat savings.

As far as I know, x87 and SSE/2/3 units use much of the same hardware, afterall they do most of the same things, just with different instructions.

My guess is they want to replace x87 because its so bizarre. Even AMD isn't too keen on it (their x86-64 instruction set includes 16 registers for x86, and even for all of Intel's SSE1/2/3 stuff, but doesn't touch x87). If it really does get replaced by a semi-well thoughtout system, its probably for the better.

[Shinigami-Sama]

yeah
it'll just be a bitch to reconfigure for youi guys
but will make things much similar in the long run

[Joe Fenton]

Originally posted by saratoga
As far as I know, x87 and SSE/2/3 units use much of the same hardware, afterall they do most of the same things, just with different instructions.

Nope - separate hardware. The MMX registers are accessed through the same interface as the x87 registers, but the three systems don't share any execution units at all.