Hi Nicolas,
Your results are interesting.
I tried to reproduce them on my SA-1100 platform, but I continue to get results similar to my previous tests:
empeg:~# time ./splay-0.8.2-fp1 -d - WS010038.A08.mp3 >/dev/null
real 1m40.466s user 1m37.240s sys 0m2.450s
empeg:~# time ./madplay -o pcm:- WS010038.A08.mp3 >/dev/null MPEG Audio Decoder version 0.10.4 (beta) - Copyright (C) 2000 Robert Leslie WS010038.A08.mp3: 9550 frames decoded (4:09.4)
real 1m9.162s user 1m6.000s sys 0m0.980s
Since this file's audio playing time is 4:09, I calculate about 40% and 27% CPU respectively for splay and madplay. (This madplay is a developmental 0.10.4b not 0.10.3b but the results are still similar.)
[I note that 40% is an improvement over my previous measurement of 43% for a previous version of splay on this platform :-]
Taking a running snapshot during live audio playback tends to confirm this:
empeg:~# ps u USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND #0 20 0.0 11.7 2188 856 ttyS1 S Feb17 0:09 -bash #0 592 40.6 12.6 1856 924 ttyS1 S 11:15 0:11 ./splay-0.8.2-fp #0 593 0.0 12.6 1856 924 ttyS1 S 11:15 0:00 ./splay-0.8.2-fp #0 594 0.6 12.6 1856 924 ttyS1 S 11:15 0:00 ./splay-0.8.2-fp #0 606 0.0 9.5 2268 696 ttyS1 R 11:16 0:00 ps u
empeg:~# ps u USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND #0 20 0.0 11.8 2188 868 ttyS1 S Feb17 0:09 -bash #0 611 26.8 10.2 7040 748 ttyS1 S 11:17 0:02 ./madplay WS0100 #0 615 0.0 9.4 2268 692 ttyS1 R 11:17 0:00 ps u
For reference:
empeg:~# cat /proc/cpuinfo Processor : Intel StrongARM-1100 rev 9 (v4l) BogoMIPS : 208.08 Hardware : SA1100-based Revision : 0000 Serial : 0000000000000000
empeg:~# uname -a Linux empeg 2.2.14-rmk5-np17-empeg22 #193 Sat Mar 25 18:04:26 GMT 2000 armv4l unknown
Incidentally, your CPU info was:
Processor : Intel StrongARM-1110 rev 5 (v4l) BogoMIPS : 194.15 Hardware : Intel-Assabet
I'm not very familiar with the differences between the SA-1100 and the SA-1110, but my understanding is that the SA-1110 has at least a faster memory bus.
At any rate, the reported time is definitely affected on the SA-110 and possibly the SA-1110 too when threads are used in splay, although curiously, reporting on my SA-1100 is not significantly affected.
To wit:
[without threads] empeg:~# time ./splay-0.8.2-fp1 -t 0 test.mp3
real 4m24.557s user 1m41.140s sys 0m2.650s
[with threads] empeg:~# time ./splay-0.8.2-fp1 test.mp3
real 4m24.727s user 1m34.870s sys 0m5.530s
So the total CPU time on the SA-1100 is similar: 104 vs 100 seconds.
Compare that with the SA-110:
[without threads] labrat:~$ time ./splay-0.8.2-fp1 -t 0 test.mp3
real 4m23.827s user 0m46.620s sys 0m1.850s
[with threads] labrat:~$ time ./splay-0.8.2-fp1 test.mp3
real 4m23.896s user 0m0.650s sys 0m1.540s
That's quite a difference: 48 vs 2 seconds total CPU? Can this be accurate?
labrat:~$ cat /proc/cpuinfo Processor : Intel sa110 rev 3 BogoMips : 262.14 Hardware : Rebel-NetWinder Serial # : 1517 Revision : 44ff
labrat:~$ uname -a Linux labrat 2.2.13 #27 Sat Apr 15 01:32:47 CDT 2000 armv4l unknown
If you believe the "with threads" numbers, splay is using less than 1% of the SA-110 CPU. (Incidentally, `top' seems to confirm this.) Without threads, it's more like 18%. For the record, madplay scores about 16% on the same machine with the same input file.
I don't have access to a SA-1110 machine so I can't compare directly, but I'd be happy to provide a `time' binary if you'd like to take measurements with something better than `top'.
Any idea why the numbers are so different for splay using threads vs splay without threads? Can you compare this on the SA-1110?
In any event, madplay seems to be significantly faster than splay right now *on the SA-1100* regardless of the threads issue. Perhaps someone else could compare on another SA-1100 host?
Cheers,