Via's Nano L2100 takes on Intel's Atom 230 - The Tech Report

Multimedia encoding and editing

Multimedia extensions throughput
Media processing is one of the big reasons these brand-new CPU architectures exist. Intel and Via built all-new chips to incorporate support for the various incarnations of SSE in order to ensure a good user experience with video playback and the like. Before we get to our media tests proper, here's a quick test of media processing power. Sandra's "multimedia" benchmark is intended to show off the benefits of extensions like MMX, SSE, and SSE2. According to SiSoft's FAQ, the benchmark actually does a fractal computation:

This benchmark generates a picture (640x480) of the well-known Mandelbrot fractal, using 255 iterations for each data pixel, in 32 colours. It is a real-life benchmark rather than a synthetic benchmark, designed to show the improvements MMX/Enhanced, 3DNow!/Enhanced, SSE(2) bring to such an algorithm.
The benchmark is multi-threaded for up to 64 CPUs maximum on SMP systems. This works by interlacing, i.e. each thread computes the next column not being worked on by other threads. Sandra creates as many threads as there are CPUs in the system and assignes [sic] each thread to a different CPU.

The integer version of this test uses integer numbers to simulate floating-point math. The floating-point version of the benchmark takes advantage of SSE2 to process up to eight Mandelbrot iterations in parallel.

The fact that both processors perform so well here in comparison to the Pentium M is testament to the media optimizations both firms have put into their new architectures.

LAME MT audio encoding
LAME MT is a multithreaded version of the LAME MP3 encoder. LAME MT was created as a demonstration of the benefits of multithreading specifically on a Hyper-Threaded CPU like the Pentium 4 or the Atom. You can download a paper (in Word format) describing the programming effort.

Rather than run multiple parallel threads, LAME MT runs the MP3 encoder's psycho-acoustic analysis function on a separate thread from the rest of the encoder using simple linear pipelining. That is, the psycho-acoustic analysis happens one frame ahead of everything else, and its results are buffered for later use by the second thread. That means this test won't really use more than two CPU cores.

We have results for two versions of LAME MT from different compilers, one from Microsoft and one from Intel. We are encoding a massive 10-minute, 6-second 101MB WAV file here.

This test gives us a nice opportunity to see how the Atom's Hyper-Threading feature impacts its performance, and here, the boost is considerable. In fact, without Hyper-Threading, the Atom takes roughly twice as long as the Nano to encode this audio file.

We should note, also, that even the slowest config tested here compresses our audio file at a rate about five times faster than real-time playback. For ripping CDs to MP3s, any of these processors should be reasonably capable.

Windows Media Encoder video encoding
For this test, I asked Windows Media Encoder to transcode a 153MB 1080-line widescreen video into a 720-line WMV using its built-in DVD/Hardware profile. Because the default "High definition quality audio" codec threw some errors in Windows Vista, I instead used the "Multichannel audio" codec. Both audio codecs have a variable bitrate peak of 192Kbps.

These CPUs are simply out of their league here. They all finished the job eventually, but the Atom took nearly an hour to encode our three-minute video clip. Today's fastest CPUs can handle this encoding task in under seven minutes. Obviously, you'll want to spend a little bit more on a CPU if you plan to use your computer for this kind of work.

Incidentally, since video playback is probably more important than encoding for these processors, I also tried simply playing back our 1080p WMV source video clip (it's 1440x1080, 24 FPS, with 384Kbps audio). That job, also, proved to be too much for these new CPUs. The Nano shot up to 100% CPU utilization and played the clip with a smattering of obvious dropped frames throughout. The Atom's CPU utilization stayed at around 85%, but it dropped many more frames than the Nano and had long, multi-second pauses where the video image remained static.

Which leads to me this remark: I wouldn't trust the Task Manager CPU utilization readout on a CPU with Hyper-Threading—the OS sees its two hardware threads as two CPU cores and doesn't really know what's happening beneath the covers.

Interestingly enough, the Pentium M was up to the task of playing back the 1080p video clip, with CPU utilization running about 90% and no apparent dropped frames.

Curious to see what these CPUs could handle, I tried playing the compressed 720p version of the video. Surprisingly, both the Nano and Atom struggled with it, as well. I then popped a standard DVD into the drive and tried playing that. On the Nano, CPU utilization ranged between 38 and 57%, with fluid playback. The Atom also had no trouble, with CPU utilization (perhaps deceptively) staying between 32 and 44%.

The HD video playback issues we ran into aren't necessarily game-ending problems for these CPUs. They should both be able to handle more intensive video codecs and higher definition content using the combination of a GPU with video decode acceleration, the most popular standard video formats, and software smart enough to take advantage. I'd expect most PC makers to bundle their systems with such software, where possible. (At present, both Via and Intel claim some degree of MPEG2 decode assist in the IGPs we're using here, but nothing for more advanced codecs.) Just don't expect a single-core Atom or Nano to handle every HD video format flawlessly without assistance.

Oh, by the way, WorldBench has a Windows Media encoder test, as well.