Video Encoding

Since XMPEG does not have a Linux port, we will use MEncoder under 64-bit and 32-bit operation. Obviously, we are attempting to replicate our Windows MPEG2 to DivX conversion as accurately as possible using MEncoder 3.3.1. We used the bundled GCC and make RPMs to compile MPlayer (and lame) for these benchmarks. For Windows, we used a precompiled binary of MEncoder.

Below is the command that we used to produce a DivX .avi from a 700MB MPEG2.

mencoder sample.mpg - nosound - ovc lavc vcodec=mpeg4:vpass=2 - o sample.avi

Frames per Second, more are better.

MEncoder 3.3.1

These encoding tests seem fairly close in tolerance, but no matter how many times we ran the benchmark, the initial recording was reported. The Fedora benchmark seemed the most interesting; both the 32-bit and 64-bit versions of Fedora reported exceptionally poor scores.

Audio Encoding

Since we are still testing out-of-the-box Operating Systems, we did not compile our own binaries for lame 3.96. For Windows, we went with Mitok compilation (which, sadly, has no 64-bit counterpart).

We ran lame on a 700MB .wav file using the command equivalent to the one below:

lame sample.wav -b 192 -m s -h >/dev/null

Encoding time, lower is better.

lame 3.96

Again, like the MEncoder testing, our encoding tests always reported the same values; thus, making it a very reliable benchmark. Although not as dramatic as the video encoding benchmark, the Fedora Core 2 took a small performance hit against the SuSE 9.1 encoding.

A Quick Bit about the Operating Systems Rendering Tests
Comments Locked

29 Comments

View All Comments

  • TrogdorJW - Tuesday, July 13, 2004 - link

    Great comment, KF. I wasn't bashing on AMD for releasing a 64-bit CPU, but more commenting on the difficulty of getting 64-bit OSes to work properly. The basic install of 64-bit SuSE 9.1 works, but it doesn't include many features that are really desirable. DivX/Xvid decoding and encoding, sound (at least on the systems I've tried, which included integrated Via Envy and Soundblaster Live 5.1), and 3D accelerated graphics are all missing with the initial install. Since I was trying to setup a HTPC system using Linux as the basis, you can imagine what a PITA that was.

    There are of course people that swear that 64-bit Linux is faster at virtually everything in comparison to 32-bit Linux, but then there are also people that swear their RAID 0 setup is significantly faster than a single hard drive in general use. 64-bit right now for *home* computing is pretty much like RAID 0: it's faster in a few specific benchmarks, often significantly so, but in general use it is really not that important. :)

    For business uses (and high-end scientific, etc. computing), 64-bits is great. But then, you really need an Opteron and Opteron motherboard (or at least Athlon 64 FX on an Opteron board) for that type of 64-bit computing environment. Getting hardware out and available now will allow MS and Linux (and whatever else) to actually get to the state where "laymen" can use the enhanced functionality in two years.

    The same thing happened with 32-bit computing: the 386 was released in 1986 or so, and yet we didn't really get a fully functional 32-bit OS for it until four or five years later (OS2). Windows 3.1 actually used various hacks to take advantage of some 32-bit features, and even that didn't debut until about 1990/1991 (IIRC). Compared to 32-bit x86, I have to think that 64-bit x86 is progressing quite nicely, and we should be able to make good use of it in the consumer segment "only" three or so years after its release.
  • KF - Tuesday, July 13, 2004 - link

    I have a feeling for what frustration the reviewer must have gone through attempting to get things to work "the easy way" on Linux, and I congratulate his fortitude. I always try to do it "the way it is supposed work" at first too. A surprising property of Linux is how things that defy solution for the first dozen guesses ultimately yield when you find the right magic wand to wave. If you voice a complaint on a Linux afficianado forum, some superbrain will always chime in that it would be obvious if you weren't misinformed, a whiner and a fool, so STFU. Then you can get into a long discussion of why or why not. The experts will tell you that, with all the shells, tools, scripting, and free compilers inluded, Linux has built in all the facilities to automate whatever took you so long to guess a solution to. There is even a POSIX (general UNIX) standard to conform to. Automating what are long and error prone processes for people is work properly done by computers. Instead you are given a list of gibberish commands and switches to type in at the console, and if that may not work -as is not infrequently the case- you are on your own to guess why. The retailers of software long ago concluded that the major hurdle to acceptance (and profits) was installation, but the premise being that software is free for Linux, Linux authors don't like to get involved with bullcrap for girlie-boys like auto-installation. Just study the man pages.

    In spite of all the things the reviewer had to compromise on, or because of it, the review gave me a clear overall picture of the state of 64 bit home computing. Still, there are abundant testimonials elsewhere from people pleased with 64 bit Linux and Windows, probably because the scope of their use is more limited. When you focus on solving one thing, it is easier.

    To people who say this proves 64 bit computing should have been postponed a few years, I say: No. Until real hardware exists, you can't work out things like this. It is tough on the initial adopters, yes. That makes it easier for the mainsteam that will come onboard in a few years.
  • Myrandex - Tuesday, July 13, 2004 - link

    I have downloaded SuSe 9.1 64bit edition just fine on my eMachines m6805 and my Athlon64 3200+ ps just fine (desktop easier to accomplish then laptop though). 64bit kernal should have been included I thought. And it was free to boot through YaST.
  • TrogdorJW - Monday, July 12, 2004 - link

    Having recently tried to get 64-bit Linux up and running on a system, I can certainly feel the pain. Try getting sound to work properly for added fun, especially with a Via Envy 24-bit sound card! However, that said, I have to strongly disagree with the way these benchmarks were conducted.

    RPMs, while a nice "out-of-box" experience, are really quite a poor way to distribute Linux applications. Sure, they're equivalent to Windows installs, but Windows is one OS, where Linux is about 2000 flavors of the same base OS. I certainly don't see Linux as a viable alternative to Windows for most people right now, but if you do want to use Linux, you should at least use Linux on its own terms.

    What would I do? First, you have to recompile in Linux. Or more specifically, I'm not so concerned about *re*-compiling as I am with compiling in the first place. Getting numerous applications to work properly pretty much requires you to compile the source code. ALSA drivers and libraries for sound are a great example. If you want an "out of box" experience, then downloading and compiling the source code with default options (i.e. "make all; make install") would probably be the best example.

    Funny thing is how you end up trying to conclude with such a positive spin on 64-bit Linux, though. Encoding was pretty much a wash, as was 3D rendering (considering the application used). Database work went to Linux while gaming went to Windows. Several of the tests were even run with 32-bit binaries under a 64-bit OS, which makes the whole comparison virtually meaningless.

    Reality is pretty lousy in 64-bit land - that should have been the conclusion. 64-bit Windows is VERY much Beta right now, and usually consists of running 32-bit applications on a 64-bit OS. 64-bit Linux, on the other hand, is going to suck up weeks of your life as you try to get it working properly, and it still might not beat Windows, unless you're looking to run a database or web server. Woohoo! Sign me up.
  • sprockkets - Monday, July 12, 2004 - link

    That windows lite version which of course is not being sold here in the states would be good. I would use that version in all my computers I sold as well.

    Unlike also with SuSE 9.0, 9.1 doesn't have a kathlon kernel, but then again compiling it from source will fix that quick like, or then again, the only processor to compile for in 64 bit SuSE at the time is for an AMD Athlon 64.
  • Miguelito - Monday, July 12, 2004 - link

    I would highly recommend that you consider doing an addendum to the article with the linux applications recompiled. I'd also use the better windows applications that are available as well to compare best to best.

    I've done some testing with applications at work, and even something simple like openssl sees huge increases in speed when recompiled vs using the binaries from the RPMs. I made some quickie graphs comparins openssl speed tests on itaniums, opterons and even 32bit xeons/opterons: http://www.miguelito.org/openssl and you can see that simply recompiling the same version made a big difference on all the platforms.
  • Locutus4657 - Monday, July 12, 2004 - link

    So when do we get to see an AMD vs. Intel 64 bit comparison?
  • Gatak - Monday, July 12, 2004 - link

    19# You can disable those services. You can enable firewalls, routers and other things. If you do not like the eye candy you can remove that too.

  • Drayvn - Monday, July 12, 2004 - link

    to post 19: they are making a windows gaming OS, where it is totally optimized for games and stuff, go look around im sure ull some information about it somewhere
  • sprockkets - Monday, July 12, 2004 - link

    Would be nice if the games that are developed on non windows machines would then run on non windows machines. It's nice to see UT2k4, but I guess all the hype and rage (perhaps even rightly so) is DirectX instead of OpenGL.

    If they made a version of windows strictly for gaming I would go for it, since that's all I need it for, and since it would do only gaming, it wouldn't be so vunerable with no unecessary running services in the background.

Log in

Don't have an account? Sign up now