by Rob Williams on November 19, 2007 in Processors
We took a look at Intel’s first 45nm desktop offering a few weeks ago and already have a preview of it’s successor. The QX9770 is equipped with a 3.2GHz frequency and is the first Intel CPU to support a 1600MHz Front-Side-Bus. Read on to see how it compares to the rest of our fleet.
When thinking about faster processors or processors with more cores, multi-media projects immediately come to mind as being the prime targets for having the greatest benefit. However, anyone who regularly uses Linux knows that a faster processor can greatly improve application compiling with GCC. Programmers themselves would see the greatest benefit here, but end-users who find themselves compiling large applications often would also reap the rewards.
Even if you don’t use Linux, the results found here can benefit all programmers, as long as you are using a multi-threaded compiler. GCC is completely multi-core friendly, so the results found here should represent the average increase you would see with similar scenarios.
For our testing, we are using Gentoo 2007.0 under the 2.6.22 Gentoo-patched kernel. The system is command-lined-based, with no desktop environment installed, which helps to keep processes to an absolute minimum.
Our target is a copy of Wine 0.9.49 (with fontforge support). We are using GCC 4.1.2 as our compiler. For single core testing, “time make” was used while dual and quad core compilations used “time make -j 3” and “time make -j 5”, respectively.
Although our Q6600 has proven itself impressive in the past, the 3.0GHz+ chips really make an impression on our compiler. Though the 45nm benefits don’t effect anything here, the extra frequency on the QX9770 does.
Even though multi-core processors are not new, it’s tricky finding a photo application that handles them properly. Lightroom was one, Photoshop is another. In light of the fact that it’s difficult to write scripts for more popular image manipulation applications, we are going to test the single core benefit of ImageMagick and UFRaw, two command-line-based applications for Linux.
ImageMagick is a popular choice for those who run websites, as it does what it does well, and that’s altering of images on the fly. Maybe websites and forums use ImageMagick in the background, which is why it’s performance is included here. UFRaw on the other hand is strictly a RAW manipulation tool which includes both a command-line and GUI-based version of the application. The command-line version is ideal for converting many images at a time, which is why we use it here.
For our test here, our script first calls on UFRaw to convert 100 .NEF 10 megapixel camera files using our settings to JPEGs 1000×669 in resolution. ImageMagick is then called up to watermark all 100 new JPEGs and also to create thumbnails of each. This entire process is similar to how we convert/watermark our photos here. An example snippet is below.
ufraw-batch –exif –wb=auto –exposure=0.60 –size=1000,670 –gamma=0.40 –linearity=0.04 –compression=90 –out-type=jpeg –out-path=../files/ *.nef;
composite -gravity SouthEast -geometry 254×55+3+3 whitewatermark.png 001.jpg ~/Output/001.jpg;
The sad thing is that multi-threaded image manipulators seem to be rare in Linux (I haven’t seen any), so while these results scale well with each other, I can’t help but imagine how much better they would be if they took advantage of all the available cores.
To help expand our Linux performance testing, we are now including Tar as a benchmark, similarly to how we use 7-Zip for our Windows benchmarking. For our Tar tests, we are using the same 4GB /Archive/ folder found in our 7-Zip test, which is loaded to the brim with miscellaneous files and sub-folders.
Because both GZip and Bzip2 are popular solutions for Linux users, we are using both in our tests here. Default options are used for both compressors, with the simple syntax: tar z/jcf Archive.tar Archive/.
Gzip is an incredibly fast compressor – it proved 57% faster than our 7-Zip Windows archiving. Quite impressive, considering our Windows compressor was multi-threaded, while Tar/Gzip is not.