How are the AMD 64-bit CPUs for A/V work?

[absinthe]

I'll be needing to upgrade my computer soon, and I'm looking at the AMD 64-bit processors. Unfortunately, I know precisely squat about them. It seems that now and again I come across comments on various forums like this one to the effect that "driver availability is limited," etc., etc.

Are the 64-bit processors appropriate for the type of video/audio encoding and editing work we all do, using the usual wide assortment of open-source software - VirtualDub, XviD, DGIndex, CCE, Media Player Classic, TMPGEnc, and so on and so on??

-abs

[nFury8]

Originally posted by absinthe
I'll be needing to upgrade my computer soon, and I'm looking at the AMD 64-bit processors. Unfortunately, I know precisely squat about them. It seems that now and again I come across comments on various forums like this one to the effect that "driver availability is limited," etc., etc.

Are the 64-bit processors appropriate for the type of video/audio encoding and editing work we all do, using the usual wide assortment of open-source software - VirtualDub, XviD, DGIndex, CCE, Media Player Classic, TMPGEnc, and so on and so on??

-abs

Of course they're fine. As it is now, even under a 32-bit environment they're fast. But not so much faster than a P4 with very high clock rates. But I think that you are specifically concerned with 64-bit apps and OS. As far as I know, there's still not much 64-bit ports of most video encoding apps, maybe that's what you meant about those "driver availability is limited" comments. And besides WinXP64-Final Version is still not here until sometime 2005. FYI, I'm mostly using our Dual Opteron at work for my video encoding using most of those apps you mentioned (Vdubmod, DGIndex, Avisynth etc).

[neo75903]

Something to know:
AMS always wondered how comes that Intel P4s always beated AMD on same clock rates despite the far more efficient cpu design of the latest cpus.
This is because Intel let some parts of the cpu internally run at 'double' speed. That means if if your Intel cpu runs at 3.6gig it runs internally at 7.2gig. This is also the reason Intel has serieus problems to increase its cpu speeds, a 4gig would have required some internal parts to run at 8gig with the all know problems.
Intel is now putting its sake in multi-core cpus for further performance increase.
Nice thing to know is that AMD is also bringing out multi-core cpus and yet they havent run into the gig probs leaving amd to play with Intel in every field they want. As far i know none amd runs at 3.0gig yet leaving many options open for amd to increase performace whatever intel will thrown into the ring.

Back to the subject, yes, a 20percent increase in performance for 64bit mode. For the ones in the uk, article 'Windows XP 64bit build 1218',page 20, PCPLUS 222, nov 2004.
Dr. Divx video encoding speed test
(32-bit vs 64-bit performance tests based on time taken to encode a 32MB MPEG video file)
32-bit Windows XP: 225secs
64-bit Windows XP: 183secs

[Joe Fenton]

Originally posted by neo75903
Something to know:
AMS always wondered how comes that Intel P4s always beated AMD on same clock rates despite the far more efficient cpu design of the latest cpus.
This is because Intel let some parts of the cpu internally run at 'double' speed. That means if if your Intel cpu runs at 3.6gig it runs internally at 7.2gig.

Sorry, but that's a complete load. :rolleyes:

Intel chips don't run internally at "double" speed. More than likely, you are thinking about the fact that vector SSE operations on AMD chips sometimes take 2 cycles to complete as opposed to 1 cycle on many Intel chips. It's one of the things AMD will address on the next revision of the AMD64 architecture as well as adding SSE3 instructions.

This is compensated for to a certain extent by the large cache in the AMD64 and the high throughput to and from memory with the on-chip memory controller. Also helpful in 64bit mode is twice the number of registers, both normal and SSE.

However, a number of codecs or encoding programs still run significantly slower on the AMD/AMD64 for yet another reason: they use Intel compilers. The Intel compilers can turn out the fastest code, but are tuned for P4s. Also, Intel deliberately disables SSE code in the executables it turns out if a non-Intel chip is detected. This has been discussed a number of times on the forum here.

If you take the output from the Intel compiler and hack it to ignore the fact it is on an AMD chip, the code suddenly operates about 25% faster than previously. This varies based on the program. This only affects programs which use the compiler for the segments of the code using SSE. The xvid codec uses NASM to assemble the segments of code that do the MMX/SSE optimized routines, so it doesn't show this slow-down when compiled with the Intel compiler.

So, based on how the program is written and what compiler is used to compile the program, the encoding can be as fast or faster with AMD64 than Intel. A number of benchmarks with programs like lame mp3 and xvid show this. DivX gives a clear lead to the Intel chips, but I'll bet you that it is entirely compiled with the Intel compiler, unlike xvid.

[dani82]

i'd been wondering about this, amd cpu isn't based on how fast it operates, but on how fast it performs compare to the P4 (athlon 3000+ xp = P4 3ghz)

does that mean the athlon 3000+ xp is just as fast as the athlon 64bit 3000 cpu?

[mikeX]

regarding the nasm assembler:
It doesn't support x86-64 architectures (namely AMD64), so XviD now uses yasm for AMD64 targets... and btw, porting to AMD64 is not quite complete yet (although it's progressing quite rapidly and should be ready before '05)

[dragongodz]

Intel P4s always beated AMD on same clock rates
this is of course wrong. an AMD 2800+ is not the same clock speed as an Intel 2.8ghz. match up the real clock speeds and the AMD is much faster in 99% of cases.

amd cpu isn't based on how fast it operates, but on how fast it performs compare to the P4
sorry but thats wrong aswell. AMD have said many times and posted on their web site in the past that the ratings are based on what an AMD thunderbird cpu would have to be running at to equal performance. they even posted the particular programs etc they used for benchmarking to give the rating.

about the Intel compiler, totally correct. infact the newer the version the faster the Intel cpu performance seems to be boosted while for the AMD cpus performance is reduced. so Intel compiler 7.1 gives faster output for AMD than 8.1 does while 8.1 gives faster for Intel than 7.1 does. now who do we thank for that anomoly ? ;)

[neo75903]

Sorry, but that's a complete load.

from:
http://www.realworldtech.com/forums/index.cfm?action=detail&PostNum=2933&Thread=1&entryID=42814&roomID=13


First of all, compared to Northwood, there are a heck
of a lot more transistors flapping around at FCLK, the
double frequency clock. The high speed integer core
includes the dcache, ALUs, AGUs, alignment MUX,
and register file.
more

Here's an approximate
shmoo for the integer core:

1.05 V 6.2 GHz
1.15 V 6.7 GHz
1.25 V 7.0 GHz
1.35 V 7.2 GHz


@dragongodz:
Intel woulnd make a chance at the same 'real' clock speeds.
But an 2800+ rated AMD is often faster then a 2.8gig intel equivalent.
AMD is wonders why other tasks were performed equal, the integer for example lacks a bit behind, it is like one part of your car just caint keep up with the other while both are driving the same speed.

[Joe Fenton]

Ah yes. The infamous "double pumped ALU" in NetBurst(TM). Most folks don't understand it, so they wave their hands and tell people it's running at twice the frequency. It's good enough for folks who have never studied electronics.

If you read the Intel literature and examine the diagrams they give on how it operates, one things strikes you - they never say the data is ready in half the time, but that it has half the latency. It's a fine distinction that escapes many folks. Remember that Intel is using a BIG pipelined architecture. Data moves from one stage of the pipe to the next on every clock. It simplifies the circuitry in many ways. The first CPU I designed had a 2 stage pipeline.

If you look at what Intel does in the ALU is two run TWO LOGIC PATHS associated with one stage of the pipe out of step by one half the main clock. They are still running at the normal speed, but because they are 50% out of phase with each other, each clock cycle sees the output of one path a half clock ahead of the other path. This allows certain signals need by the other path to be available a half clock ahead of when they would "normally" recieve them, so they can complete their logic function in one clock cycle, instead of waiting and taking another pipeline stage. This reduces the latency of the pipeline at this stage by half a clock.

It's very subtle and rather ingenious. It works nicely for carry-forward logic used for certain simple operations like adding. You'll notice in Intel's literature than very few things can take advantage of this "double-pumping". That limits it's usefulness as well as demonstrating why Intel chips aren't "twice as fast" despite having a "double pumped" ALU.

[neo75903]

ic, that is interesting to know.
So no parts of the cpu runs at 7.2gig but a double line of 3.2gig.
I presume the increased temperature is due to the increase of the number of components?

[Joe Fenton]

Originally posted by neo75903
ic, that is interesting to know.
So no parts of the cpu runs at 7.2gig but a double line of 3.2gig.
I presume the increased temperature is due to the increase of the number of components?

To clock the paths half a clock out of step, you do need a clock at twice the rate to generate the quadrature signals used by each path. So there's a certain amount of clock circuitry running at twice the rate. But mainly, the heat is due to running at 3.6GHz+ rates. Remember that the AMD parts are all below 3GHz. Power dissipation goes up directly by frequency. Just look at what people overclocking AMD and Intel chips need to do as they increase the frequency.