lame benchmarks (pun intended)

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

[Piru]

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?

I have no way of knowing how the X1000 and AmigaOne 500 results were derived, except the file and lame options (none) being used. The author claims the X1000 result is from altivec accelerated lame (but I have no way of verifying the claim).

What I did was to run the MorphOS G4 results with altivec enabled lame.

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?

The X1000 result is assumed to be altivec already (as claimed by the author).

[Piru]

Its unpossible that they will be slower than on sam460 (or the same).

PA6-T is easily faster than 460ex in scalar operations, no question about that.

[krashan]

And did he for sure use that AKsack.wav ?

Yes. In the first post he writes "Some time ago I've promised to Recedent, I will confront X1000 with his benchmarks". Then he links to tests performed by Recedent, where testfiles are listed. It is obvious in my opinion, that he used the same file.

[kas1e]

It is obvious in my opinion, that he used the same file.

You know that amiga users can do any kind of not-obvious stuff.. Well, seems just need to wait someone else with that x1000, who can normally explain everything (i.e. what he download, where, how run, with what file, show alivec and non altive results and so on). If then it will be the same bad, then it will be kind of surprise.

[krashan]

If then it will be the same bad, then it will be kind of surprise.

It is not bad at all. MPEG Audio compression operates on relatively small data chunks, L2 cache is very well used. Then LAME is not speeded up much with very good performance of X1000 memory bus. So only clock frequency and processor efficiency counts. We have 7447A processor running at 1.42 GHz in Mac mini and PA6T processor running at 1.80 GHz in X1000. Then clock-wise X1000 is 25% faster. But then PA6T is based on IBM core, not on Freescale core. It is also designed to be more energy saving than 7447. For example AltiVec has one execution unit less compared to 7447. It is not impossible that PA6T "per megahertz" performance is by 25% lower compared to Freescale's e600 core used in 7447.

It resembles the case of Pentium 4, which was significantly slower "per megahertz" compared to Pentium III. On the other hand P4 could be clocked much higher due to its new design. Too bad in case of PA Semi the development has been killed prematurely.

[Tuxedo]

Plz use my benchmark topic to make that tests if possible so we can all ahve same bench base:

http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=30008&forum=2

thank you.

[Kesa]

Is there any way we could include an overclocked G4 mac mini? I've seen people getting theirs up to 1.8Ghz. I ask this as i am considering doing this to mine.

Cheers!

[kas1e]

It is not bad at all.

Its can be not bad, if price of x1000 are around 500usd. But when price are 3k and HW made "from scratch" i somehow was in fairly hopes that it will beat all the macs by everything. Still, i think we need to wait someone else to confirm the results and show us altivec/non altives results one more time. If it will be confirmed, then, its its bad.

[Tuxedo]

how bout use os4emu under MOS to compare test? so we can run the same exe on different machines?

[Piru]

@Piru

According to the lame readme on os4depot, the AmigaOS4 version also lacks altivec support (the porter couldn't get it working properly).

You can easily verify that the lame.g4-3.98.2 binary contains altivec support:

• > wget http://os4depot.net/share/audio/record/lame.lha
  
• > lha x lame.lha
• > ppc-amigaos-objdump -d lame-398-4/bin/lame.g4-3.98.2 | egrep v[0-9]+,

[kas1e]

You can easily verify that the lame.g4-3.98.2 binary contains altivec support:

• > wget http://os4depot.net/share/audio/record/lame.lha
  
• > lha x lame.lha
• > ppc-amigaos-objdump -d lame-398-4/bin/lame.g4-3.98.2 | egrep v[0-9]+,

Doesn't mean much. I also have some stuff which have altivec insturctions inside, but still, that piece of code unused in the necessary place. In the readme to that archive a lot to say about mess with altivec, so it can be not suprise that its just broken, disabled and not works.

[wawrzon]

@kas1e: bad! now you are overreacting. in the end this practical benchmark in comparison with karlos and mine native x86 test shows, that x1k or mac mini for that matter, is almost as usable as middle range about up to date pc hardware. its surely not the whole truth, more to come, but i wouldnt call results devastating. the other question is as always if it is worth these investments but the question stands as it did, nothing changed for better or worse.

[Tuxedo]

On my Peg2@1131 the wav file with lame altivec:


8.RAM Disk:> lame AKsack.wav
LAME 3.98.2 32bits (http://www.mp3dev.org/)
Using polyphase lowpass filter, transition band: 16537 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:22/    0:22|    0:23/    0:23|   12.095x|    0:00
-------------------------------------------------------------------------------
   kbps        MS  %     long switch short %                                  
  128.0      100.0        76.1  13.4  10.5                                    
Writing LAME Tag...done
ReplayGain: +0.5dB

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

[Piru]

Doesn't mean much. I also have some stuff which have altivec insturctions inside, but still, that piece of code unused in the necessary place. In the readme to that archive a lot to say about mess with altivec, so it can be not suprise that its just broken, disabled and not works.

Did you read the readme? Here's the relevant part highlighted by me:

Unfortunately the people who tested the Altivec version for me did not have
any success, and therefore this upload only includes a generic PPC version
of 3.98.4, and Stephan Rupprecht's prior 3.98.2 G4 build.

The archive has 3 lame binaries:

Code: [Select]

[generic]               197665  411156  48.1% -lh5- 3de4 Oct  6  2010 lame-398-4/bin/lame
[generic]                50969  168764  30.2% -lh5- 9a1e Oct  6  2010 lame-398-4/bin/lame-shared
[generic]               322281  710768  45.3% -lh5- 2952 Sep 26  2008 lame-398-4/bin/lame.g4-3.98.2
The first two are the non-altivec builds (one static and the other using SObjs/libmp3lame.so).

The third is the old (26-sep-2008) - altivec enabled - build by Stephan Rupprecht, included as-is.

The same is confirmed here as well:

In any case, no-one loses anything. 3.98.4 for generic PPC, new libmp3lame which was always generic, and the prior 3.98.2 for altivec is in here. Win-win.