Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On Friday 16 July 2010 10:38:19 Aurelien Jarno wrote:
> I don't say a hardfp port should not be done, but that starting such a
> port should be done based on solid *facts*, benchmarks, tests and so on.
Ok, I just couldn't help it and ran another benchmark, this time I chose
povray (3.6.1-12), first using the karmic version (built with softfp) and then
my own package built using CS compiler (exact same version). I guess gcc-
linaro compiler will perform similarly, but I'm still building this.
I chose one sample scene from the examples, and ran it on both softfp/hardfp
systems with this command:
$ povray +V /usr/share/doc/povray/examples/radiosity/radiosity.pov
this produced a radiosity.png file, which on both systems has the same md5sum:
$ md5sum radiosity.png
c0923759c771679a19a0020c3ac7f6e2 radiosity.png
which means both versions produced exactly the same result (as they should).
if they didn't the benchmark would be qualitative and not quantitative, even
if the image appeared to be exactly the same.
Now, here are the results (which will shock you as much they have shocked me):
softfp:
Total Scene Processing Times
Parse Time: 0 hours 0 minutes 0 seconds (0 seconds)
Photon Time: 0 hours 0 minutes 0 seconds (0 seconds)
Render Time: 0 hours 2 minutes 45 seconds (165 seconds)
Total Time: 0 hours 2 minutes 45 seconds (165 seconds)
(ran 3 times, always the same result)
hardfp:
Total Scene Processing Times
Parse Time: 0 hours 0 minutes 0 seconds (0 seconds)
Photon Time: 0 hours 0 minutes 0 seconds (0 seconds)
Render Time: 0 hours 0 minutes 50 seconds (50 seconds)
Total Time: 0 hours 0 minutes 50 seconds (50 seconds)
(no that's not a mistake, I also ran this 3 times).
Now, do you believe me? Do I have to do a proper "analysis" at the assembly
level of every package to show that hardfp beats the crap out of softfp and it
_should_ be made into a new port?
Konstantinos
Reply to: