On 7/11/10, Bill Gatliff <b...@billgatliff.com> wrote: > But then doesn't that mean that everything is "armel", so we never have a > hope of having Debian officially support more than one combination?
Well, "armel" should be as generic as possible. In an ideal world, it would be called "arm" and run on pretty much all ARM processors. After all, Debian's tagline is "The Universal Operating System", while cpu-specific tweaking is the speciality of Gentoo, OpenEmbedded and so on. But, since "arm" was already taken, and it used emulated hardfloat instructions instead of softfloat, the main advantage of facing the pain and embarassment of a new port was that it would make FP 11 times faster on all ARM CPUs, as well as permitting use of real FPUs, making it 30 or 40 times faster. That's the difference between encoding a 30-second MP3 in a minute or encoding it in 2 seconds. The argument in favour of yet another ARM Debian arch (making four so far) is the figure of another 30% being waved about. Not another factor of 30, just another 30%, and presumably that figure comes from beating some worst-case situation to death. Actual figures would be nice. > I'm ok with that, actually--- an ecosystem of unofficial "armel" > repositories cropping up containing optimized packages for specific > configurations. Yes. That is the right way to go to leverage FPUs in the Debian framework, and was one of the justifications for the upheavals that the "armel" port caused. Where does this "30%" figure that's been floated around for hardfloat ABI over softfloat ABI with VFP instructions come from? Do we have any actual measurements? Wanting to politick a fourth Debian ARM architecture into dpkg, with all the work that involves for other people, just to get a few percent speed increase in a few packages doesn't seem worth doing. You can get a 3 or 4 times speed increase with an FPU-specific armel repository, which is a mechanism well suited to supporting specific combinations. It doesn't seem worth causing all that pain again just to get an extra 30% of frames per second in glgears. It's an optimization, yes, but look at the cost. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikcay4wm1vgdvnt-irv5b357esxpu6fyebw4...@mail.gmail.com
