lame benchmarks (pun intended)

[Karlos]

What's interesting about this benchmark is that it takes my Q9450 8 seconds to perform the same test.

Code: [Select]



karlos@Megaburken-II:~/Desktop$ time lame AKsack.wav
LAME 3.98.2 64bits (http://www.mp3dev.org/)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding AKsack.wav to AKsack.wav.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
 10529/10529 (100%)|    0:08/    0:08|    0:08/    0:08|   33.665x|    0:00
-------------------------------------------------------------------------------
   kbps        MS  %     long switch short %
  128.0      100.0        76.1  13.4  10.5
Writing LAME Tag...done
ReplayGain: +0.5dB

real    0m8.175s
user    0m8.120s
sys     0m0.060s


Those old PPC machines don't look too shabby under the circumstances.

[Karlos]

@wawrzon

One thing I notice about my system is that while it takes 8 seconds, my CPU doesn't doesn't seem to step up from 2GHz to the full 2.67GHz in the time it takes to convert the file.

It could be one of those tasks that becomes quite convergent and dependent more on IO than anything.

[Karlos]

It can happen if PA6-T AltiVec isn't as fast as the E600 (7447/7448) one. Considering PA-Semi didn't have the freescale core to derive their work on, this may well be the case.

Also, mp3 encoding is highly CPU bound task, and thus a fast bus doesn't help much. Clearly PA6-T will excel in anything that is memory bound (as we've seen the RageMem and stream benchmarks).

Sorry if I've overlooked it, but can you confirm if the first graph and second graph are based on results carried out under the same conditions?

If that's the case, it suggests that for the PASemi either altivec was enabled in both tests or in neither test. The time was the same in both instances (18s). There should be some difference if one was scalar and the other vector, surely?

[Karlos]

I realise it's a bit off topic, but I'm far more surprised by my Q9450 result. I've gotten it down to ~6.5 seconds using a RAM based tmpfs for source/destination and disabling clock scaling so that the machine is locked at 2.67GHz.

I actually find that a pretty embarrassing result for a 64-bit build, which supposedly has SSE3 enabled by default*. 6MB L2 cache (12 in total, but the Q9450 design is akin to a pair of 6MB cache dual cores), 1333MHz FSB with dual channel DDR3 6-6-6 latency and an X48 chipset. And all I got was a factor of 2.6 over a 1.5GHz G4 when there's a 1.78x increase in clockspeed to start with? That makes this machine, what, 46% faster at this task clock for clock? :lol:

*I'm going to have to rebuild this myself and ensure all SSE3 optimizations are enabled.

[Karlos]

at least on blender test my i7 rig fits the expectations 00:39.26. so that might be a more dependable benchmark-

How is it with one thread?

[Karlos]

is there a way to influence it?

I seem to recall an option in the render settings somewhere for the number of threads, which seemed to be set to 4 on my quad core. Probably be 8 on yours if it is counting logical cores.

[Karlos]

Don't care so much about the thread but the tags are funny.

:lol: I wonder who put that there?

And why do I feel like curried lamb meatballs for dinner...

[Karlos]

you use a non SSE Version on windows.

You might be right about the SSE support (which I mentioned above that I'd have to check), but it most assuredly isn't running on Windows.