lame benchmarks (pun intended)

[vox]

The 10+ year old 500MHz PowerMac is beating the AmigaOne 500, too. Oh the humanity!

Its clear AMCC CPUs are not performance wise and meant for integrated combos and not desktops. Or software is just not optimized for them since they should have multimedia instructions of their own but not as standard as Altivec (have 24 additional digital signal processing instructions). However, SAM460 does make good use of fast RAM, SATA and PCI-E and will try to balance the loss there to make it overall feel the same / faster execept in any CPU intensive tasks.

Previous benches like Ragemem tests at AW,nt showed it, but not that 500Mhz G4 can beat SAM 460 http://httwww.amigaworld.net/modules/newbb/viewtopic.php?forum=14&topic_id=32815&viewmode=thread&order=0

That is a bit surprising!

[x303]

Tested with WinUAE. Lame 3.99.3 compiles it in 58 secs.

:laughing:

[wawrzon]

@kas1e: mufa might mix something up, although as another native polish speaker i must confirm that he explicitely claims that his version of lame is altivec enabled. time for him to confirm or contradict that, otherwise we must assume pirus graph is correct, besides...

@piru: ..has it now been confirmed that the same file has been used for the test??

[kas1e]

@wawrzon

@kas1e: mufa might mix something up, although as another native polish speaker i must confirm that he explicitely claims that his version of lame is altivec enabled. time for him to confirm or contradict that, otherwise we must assume pirus graph is correct, besides...

Still dunno how 1.8ghz can be the same as 1.4ghz by tests. Something wrong somethere still.

[Hans_]

So we know two things:
- Altivec use is great and speeds up some multimedia demanding tasks 2x
- X1000 is champion in same fair category of non altivec use, in this case. Good, so its worthwhile after all as "new miggy champ"

Not so fast. If mufa did indeed use an altivec enabled version, then nothing can be concluded in the non-altivec case. Wait until mufa confirms what he did (preferably by rerunning his tests and explicitly recording the version of lame that he used each time).

Hans

[Piru]

@piru: ..has it now been confirmed that the same file has been used for the test??

The "Mac mini G4 1.5GHz" 33 second result is from a test that used the AKsack.wav.

This file (and the Mac mini G4 33 sec result) are derived from an earlier benchmark:
http://www.apc74.ppa.pl/PPA/Efika_vs_reszta_swiata.html#table7 and
http://www.apc74.ppa.pl/PPA/Efika_vs_reszta_swiata.html#table8

In this old benchmark non-altivec lame was utilized.

[Hans_]

@wawrzon


Still dunno how 1.8ghz can be the same as 1.4ghz by tests. Something wrong somethere still.

CPU performance is affected by a lot more than just the clock speed. The design of the pipe-line also affects performance, a long with a heap of other design factors. One of PASemi's goals was energy efficiency, and the G4's design may have delivered higher performance per clock at the cost of greater energy consumption.

I'm not saying that this is how it is (I haven't looked at it in detail), just that it is possible.

Hans

[Piru]

Still dunno how 1.8ghz can be the same as 1.4ghz by tests. Something wrong somethere still.

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).

[rebraist]

this test is no good!
how can pasemi make 18 seconds with altivec and 18 seconds with altivec off?
for the same reason a g4 makes 36 sec without altivec and 17 seconds with altivec?
it does mean that x1000 benchmark are simply and totally without altivec in both cases!
edit: test says it's altivec enabled in both tests... so really my g4 is faster than an x1000?
and what about an x1000 without altivec?

[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.

[wawrzon]

@karlos, yeah, just thought the same, even if file was not placed in ram for conversion. my i7/2.93 needs 7s:

C:\Programme\Lame For Audacity>lame AKsack.wav AKsack.mp3
LAME 3.99.3 32bits (http://lame.sf.net)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding AKsack.wav to AKsack.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:07/    0:07|    0:07/    0:07|   36.295x|    0:00
-------------------------------------------------------------------------------
   kbps        MS  %     long switch short %
  128.0      100.0        74.4  13.4  12.2
Writing LAME Tag...done
ReplayGain: +0.5dB

[TheBilgeRat]

darren@themintybox ~/Desktop $ time lame AKsack.wav
LAME 3.98.4 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:04/    0:04|    0:04/    0:04|   57.782x|    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   0m4.778s
user   0m4.690s
sys   0m0.080s

in a VirtualBox VM of Linux Mint 10

core I-7 unlocked 3.4Ghz, 8Gb of ram assigned to the VB

[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?

[krashan]

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?

Piru simply has taken the X1000 result from the Mufa's graph. Mufa clearly states he used AltiVec enabled LAME on his X1000 to perform the test. At least he is convinced of it. So for X1000 it is just single result. For mac Mini 1.5 GHz we have two results: 33 seconds is without AltiVec, 17 seconds is with AltiVec.

[kas1e]

Piru simply has taken the X1000 result from the Mufa's graph. Mufa clearly states he used AltiVec enabled LAME on his X1000 to perform the test. At least he is convinced of it. So for X1000 it is just single result. For mac Mini 1.5 GHz we have two results: 33 seconds is without AltiVec, 17 seconds is with AltiVec.

While i still think that mufa messing things up, will be pretty intersting to know, the results without altivec then. Its unpossible that they will be slower than on sam460 (or the same). Just unreal even with everything taking in account. And did he for sure use that AKsack.wav ?