Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
Matt Sealey a écrit :
> I am fairly sure (oh you did!) find a contrived benchmark to show that
> some code is faster on softfp in some cases, but taking a holistic
> approach I find it hard to believe that every time a floating point
> function is called across any of 20,000 packages possibly running on a
> system in a Debian port, that you will be able to benchmark a
> softfp+vfp system running faster than a hard+vfp one, and the features
> outlined above in the VFPv3 spec, the ability to judge the benefits of
> VFP vs. NEON without compilers generating special magic in the way,
> will help people out and make for a "nicer" system.
>
I think we all agree that in overall hardfp is faster than softfp+vfp.
The question is by how much *from the user experience point of view*. I
don't doubt Eigen3 is a lot faster, but it's not the kind of software
users usually use on their smartphone/tablet/notebook. What users want
is a more reactive machine when doing web browsing, document editing,
video playing and so on.
Keep in mind that creating a new port is a huge work, and from the
experience will take a few years. You have to deal with bootstrapping,
patching code, deal with maintainers, build daemons, etc. All of that
while the code base also evolve as new versions of packages are
uploaded. Moreover at the end to get the port accepted as an official
one, you have to convince it is really useful.
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.
BTW, has anybody thought about increasing the minimum requirement for
the armel port, for example to armv5? Available machines has evolved,
maybe the port should do the same.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: