A major difference I've seen in my six months of running amd64 on four, then eight gigabytes of RAM is that normally memory-hogging Firefox doesn't slow down at all. I opened 600+ tabs and it was as quick as if I had but one open.
For Java I'd use IcedTea, there's even a native (alas not very compatible with many applets) 64-bit plugin for firefox. IcedTea is installed by default on Fedora 8 and 9 alpha, I'd be surprised it wouldn't be included in Ubuntu 8.04 final. By the way, IcedTea is based on the GPLed Java code Sun released.
Interesting review, but, beyond the gaming benchmark, a quad core is meant for ... compiling !
Ok, I'm a Gentoo user, and I'm looking for a quad-core for compiling while playing ETQW or UT3.
I'm crazy ?
Perhaps, but I already played UT2K4 while compiling a new kernel or some gentoo upgrade.
I have a 512 Mb P4 Hyperthreaded and it's written on the box that is "multi threaded". It's partly true. In fact, the disk is the limiting factor, but with more RAM, the game can run with no disk access after loading and after, it's only CPU power.
I could also resize an AVCHD video while playing (it's boring to wait for such long process to carry out so I want to play meanwhile) !
Give a chance to Phenom. Try those tests. After all, it's a native quad-core AMD said. Not a twin "double core". It should behave extremly well on massive multitasking, shouldn't it ?
Thanks anyway to all phoronix team for being a very good site about Linux hardware, reviews and much more ! Phoronix rules.
Sorry to say this, but the benchmarks for this article are sorely lacking... I mean, instead of 2 graphs with the same applications (games, which are not even open-source so there is no telling whether they are optimized for 64bit or even _compiled_ for 64bit) there could have been plenty more relevant tests -- for example:
1. Compilation -- it's a quad core, give it some crunching to do with make -j4
2. Encoding -- mencoder with various codecs like xvid/x264, trancode, etc.; you can also run 4 mencoders in parallel to check multitasking.
3. 3D Modelling -- definitely a place for both quad-core and 64bit to shine; POVRay is a great app, why isn't it on the list?
4. Compression with 7z/bzip2/rar, not just gzip which is quite light on the processor
5. Some database tests -- how about MySQL compiled for 64bit and some large-number queries?
6. Other applications people actually run on Linux -- apache/php, postfix, bind, whatnot
7. Instead of the age-old rant about flash, why not some comments on the ammount of RAM being used in 32 vs. 64, detailed per specific application; plus other memory-access tests, like loading a 10kx10k image in GIMP?
All-in-all, the article as it stands promises much but delivers little. This is not to say that your work is not appreciated, on the contrary -- it's just that you can count Linux hardware review sites on the fingers of one hand and it's quite dissappointing to read an article that doesn't quite provide any additional knowledge... Please just take this as little rant about things to improve -- and we all know there is always place for that, right?
I've been saying that using pbizp rather than gzip should give a better impression of what a heavily multithreaded system is capable of. It is binary compatible with standard bzip2 (i.e archives made with can be opened with standard bzip2, and vice versa) and performance should scale accordingly, a much sensitive test than gzip, IMO.
Also this time around there were no ramspeed tests. I think gaming testing is OK for the most part, sure this is Linux, and we have few games, but still they demonstrate how good Linux as a gaming platform could be. Also games tend to stress different parts of a system than "traditional" tests, so I think it is a good inclusion. I, however, don't think they should take the spotlight (though very close, too). At any rate, it is a good thing that Michael takes the time to test different hardware combinations with different software combinations. Another thing that could also be tested are different distributions (not just one) to also give an idea of the differing degree of support and performance delta across the different distros... I'm sure distribution vendors will also be interested on how do their distros compare to others in the performance arena.
I have to agree with many others in this thread. The article is very misleading by it's title. By benching 32-binaries on a 64-bit system you completely take away any advantage it has and doesn't exploit the capabilities of the 64-bit system. I also have to agree with the assessment of the choice of hardware. ATI's linux graphics drivers are still not at the same level of what nvidia's are. The title on the article should have more reflected it's contents which was "The Spider Platform Re-assessed". ATI's drivers are still "teething". If the article was to be what the title says then only tests that had optimized 32-bit and 64-bit binary counterparts should have been used. As well the article should have focused on CPU biased applications instead of applications that are GPU bound since the title is " AMD Phenom 32-bit vs. 64-bit Linux ". I've had issues with phoronix methods of benchmarking before but this brings it to a new low.
Car and Driver would have more credibility if they assessed a Ferrari with space saver tires.
Expanding a bit on what deanjo says, I think a good "gaming" test would be to build from source one of the many variations of the quake engine out there on both 32 and 64-bit arches, and test. These titles shouldn't be GPU bound any more, and the scale in performance may be indeed be assessed with raw CPU power. The ioquake3 tree would be a good start, since the Quke3 engine was of the first engines to ever support SMP, which means scaling should be fairly noticeable running 32-bit single threaded Vs 32-bit multithreaded, and the same for 64-bit, not to mention that the performance delta between 32 and 64-bit should be more accurate. I'm aware that Quake3 is no longer glamorous to the eye, but we'd not be testing "eye-bang", but rather raw CPU power and multithreading scaling. Another good test regarding proprietary 32-bit Vs 64-bit binaries would be to try to measure the performance of UT2004 (about the only commercial game I know of that supports both architectures on Linux). I'm aware that testing ATi Vs nVidia with this title on the latest hardware is not possible due to a number of issues with the game and the OpenGL renderer in say G80 parts (I'm not aware if there are problems with the HD Radeon series). Those two tests would be about the only gaming tests that might be worth performing, as the test is trying to assess 32 Vs 64 bit performance delta. Is nice to see (mind you) the degree of support and performance delta in proprietary games such as the ones tested, so they still have some value to the tests performed.
I bought a Phenom 9500 and installed Ubuntu 7.10
No Kernel panic whatsoever. Everything went smooth except for FGLRX.
In Ubuntu 8.04, it's kicking @$$, FGLRX installs via restricted driver manager. Smooth. I like.