DivX & 64 bit ?

[Tuning]

The divx networks has stated that there will be new DivX and Dr.DivX to support 64 bit AMD processors.And in the press release they have quoted “With the newly optimized edition of our official video encoding product, consumers can create DivX video from any source faster than ever before. We’re very pleased that the Dr. DivX: AMD64 Edition is available for users to easily and quickly create great-looking DivX videos on their PCs.” .The question is this:as AMD 64 is suposed to be backward compatible and can use ordinary DivX,What increase we can find in the new DivX?.Is the avi created using this DivX will able to play in ordinary 32bit processors.Or there will be any other problems?.Thanks.:)

[unmei]

Is the avi created using this DivX will able to play in ordinary 32bit processors

out of the blue: yes
divx is mpeg-4 bitstream and this is independent of whether you use 8bit bus CPU or a 64bit one for encoding or decoding. The encoded file should be bit-identical with one created on a 32 bit machine, or using 32bit software on a 64bit AMD.

What increase we can find in the new DivX?
the possibility what you can do with software is not depending on what size the databus has (or what complexity or speed the cpu has), its only about speed. The new AMD will probably come with some new instruction set, like the known MMX, SSE, 3Dnow! et all these new instructons will not make the computer smarter, they are just a convienent and hopefully faster way to operate with bigger size datatypes, or appl higher level math operations. So the only thing you will ever be able to do with any performance increase (clock frequency, bus width, number of instuctions ...) is doing the same things faster.
(Yes you can encode or decode xvid on a 286er, you just have to replace the SSE optimisations in the code with native x86 instructions ;))

[Tuning]

Yes you can encode or decode xvid on a 286er, you just have to replace the SSE optimisations in the code with native x86 instructions
But i doubt the decoding process requires lot of CPU power and thus the video may become jerky.:)

[unmei]

yeah, you could probably call yourself lucky with 1 frame per half hour playback :p

[DeXT]

Anandtech published in this article (http://www.anandtech.com/cpu/showdoc.html?i=1884&p=17) a massive 34% gain in encoding speed using a 64-bit compiled version of LAME and a 64-bit-aware OS (Red Hat Taroon) with an Athlon64 FX51, when compared to their 32-bit versions. So you can expect a great performance boost when taking full advantage of the 64 bit architecture from AMD (note that this needs 64-bit compiled apps AND a 64-bit OS). Unfortunately WinXP for AMD64 is scheduled for Q1 2004, so you'll better stick to Linux until then.

Meanwhile a call to arms should be made to the developers in order to create 64-bit compatible tools. The guys at Anandtech were unable to run a transcoding test due to compilation issues (as some structures were expected to be 32-bit aligned). I'm afraid the 64-bit path may be longer than expected.

[Doom9]

well, I suppose right now it's a bit hard to create 64bit Windows apps if the OS isn't even available (and not every developer has the proper MSDN subscription to get the 64bit beta). Also, the lame test is somewhat doubtful. Why use minutes instead of seconds as timebase? Is 2 minutes for the 64bit version really 2minutes 00 seconds? And what's 3.07 minutes? 3 Minutes 7 seconds? 3 Minutes, 7/100 seconds?

[unmei]

it looks a bit like a lucky strike, the flops and intops benchs are not impressive at all.
And personally it would take me much more than 34% speed improvement to get excited over hardware, partly cos i just don't have the money to by a new comp "just-because" (i mean there are standard p4 3 times faster than my fast comp and i dont think i really need one of those) and partly cos it only invites to waste more cpu power on bad software design :p a 34% speed increase in software on the other hand is always welcome but sadly much too rare.

Well, anyway, let the 64 bit AMD out and the prices for the 2.5ghz range drop a decent amount, then im happy too :p

[int 21h]

Just because you don't have a 64bit OS doesn't mean you can't take advantage of the 64bit ops in ASM. Having a 64bit OS, will only change addressable memory in use by the OS, it will not directly provide any optimizations.

[DeXT]

Originally posted by int 21h
Just because you don't have a 64bit OS doesn't mean you can't take advantage of the 64bit ops in ASM. Having a 64bit OS, will only change addressable memory in use by the OS, it will not directly provide any optimizations.
According to AMD the OS must support the AMD64 architecture to be able to use the new registers and extended address space from within the applications. Seems this is not like MMX or SSE, which involves just taking use of a bunch of new instructions after checking the processor capabilities.

AMD introduced a new mode called "long mode" which must be activated by the OS at boot time, otherwise the processor works in "legacy mode", looking like a 32 bit processor from the software point of view. The "long mode" has two submodes, called "64-bit mode" and "compatibility mode". The last one is used when executing 32-bit apps from inside a 64-bit OS.

More information can be found on AMD's site, such as this presentation (http://www.amd.com/us-en/assets/content_type/DownloadableAssets/Software_Porting_-_Rich_Brunner.pdf).

[int 21h]

How lame is that...

My mistake then ;)

[dragongodz]

remember these are early tests/examples aswell. i saw on a french site they tested gzip 32bit and 64bit compiled versions. the 64bit was over twice as fast(took less than half the time to compress). so speed increases will depend on the program. also you will probably have to wait until people have been able to play with the cpu for ahile and worked out how to get the best out of them.

"How lame is that..." well still better than Intels stance of "you dont need it until 2007-2008". :D

[Beastie Boy]

Here is a quote directly from the Anandtech review (whose opinions and reviews I highly respect).

32-bit apps under a 32-bit OS

At the launch of the Athlon 64, the predominant operating environment will be running 32-bit applications under a 32-bit OS. All performance benefits the K8 architecture will show here are courtesy of the on-die memory controller, improved branch predictor, higher clock speed and more robust TLBs - none of the performance improvements you'll see in this case will have anything to do with the 64-bit capabilities of the processor.


There are speed improvements over the old chip, but they are nothing to do with the '64 Bitness' without a 64 bit OS.

The 64 bit app tests were quite impressive though. Perhaps a seperate 64bit Linux partition would be good
:)

Cheers, Beastie

[Doobie]

Originally posted by unmei
(Yes you can encode or decode xvid on a 286er, you just have to replace the SSE optimisations in the code with native x86 instructions ;))

The 286 is a 16-bit processor with very limited resource handling ability. So, it's going to take a lot(!) more work than just replacing the SSE instructions.

For a full length movie, it would take years(!) to encode. And, you'll be lucky to have even a slide show for playback.

[ammer]

3.07 mins you have to convert the .07 mins to secs .07min x 60sec/1min = 4.2secs. the minutes cancel and you have seconds plus conversion for mins and secs is 1min = 60sec/1min vice versa 1sec = 1min/60sec. so that'd be 3mins 4.2secs time.

[DeXT]

Ace's hardware published some benchmarks (http://www.aceshardware.com/read.jsp?id=60000256) using a DivX version optimized for AMD64, as well as some other tests submitted by AMD (although they said they verified them). Not a very impressive gain, though (encoding time 7.5 secs vs 8.8 secs, a 15% gain), but not bad at all keeping in mind it's being run under a pre-beta Win64. Having a complete chain of optimized software in the conversion process should improve the thing even further.

[Prettz]

The thing here is that I would assume that ALL of the speed-critical 64-bit integer operations are already completely assembly optimized using MMX and SSE. Also keep in mind that doing 64-bit integer calculations is generally faster with MMX/SSE than with the ALU. 8 more general purpose registers isn't going to make the inner loops that much faster, except the developers might be able to keep more pointer variables in registers rather than on the stack.

[eng3]

I don't know too much about this but I hear that WinXP 64 does not support the AMD64 architecture, only Intel's IA-64, like for the itanium. That makes a pretty big difference since the itanium is VLIW and the AMD64 is not so it is backwards compatible.

I have no idea, but I would think compiling for the AMD64 would be much easier than compiling for the IA-64.
I do hear that WinXP is working on an update to support the AMD64 architecture. I'm a betatester and I've noticed that they ask in some survey's if I own a Athlon64. Since I plan to upgrade in the near future, maybe Athlon64 is the way to go.

[dragongodz]

i dont know where you heard windows 64 wont support amd64 but its wrong.

http://www.microsoft.com/presspass/press/2003/sep03/09-23Athlon64BetaPR.asp

[eng3]

Originally posted by dragongodz
i dont know where you heard windows 64 wont support amd64 but its wrong.

http://www.microsoft.com/presspass/press/2003/sep03/09-23Athlon64BetaPR.asp

Sorry, I meant that I don't think Windows 64 currently supports it because it was written for the itanium (I think).
I know their working on a amd64 version of windows 64.
I hope I can try it out soon.

But my main question was about the XviD support for Amd64

[ToiletDuck]

well, I suppose right now it's a bit hard to create 64bit Windows apps if the OS isn't even available

Couldn't the application itself be 32 bit and run a 64bit encoder?

[zurv]

One can download the windows 2003 64-bit (for Athlon64) from MS now. FYI..


http://www.microsoft.com/windowsserver2003/64bit/extended/trial/default.mspx