[fedora-arm] dietlibc port?

[omalleys at msu.edu]

Quoting Gordan Bobic <gordan at bobich.net>:

> omalleys at msu.edu wrote:
>
>>>>>> Sounds like you found a solution ^^
>>>>>
>>>>> It's a solution for me, but from tthe philosophical point of view,
>>>>> there
>>>>> is probably the greater issue of the distribution to consider. Is
>>>>> dietlibc really that useful on a non-embedded distribution (yes, I know
>>>>> I'm referring to the ARM port of something as non-embedded)? What
>>>>> really
>>>>
>>>> Well a major reason to rely on a distro with a well-stocked repo of
>>>> binaries is that you can just use them, and other people have been
>>>> banging on them and fixing them too.  The prebuilt stuff is all built
>>>> against glibc so that's a strong reason to stick with that.
>>>
>>> The point I was getting to was that the stock of packages at least in
>>> the base distro should be consistent across platforms, except in very
>>> hardware-specific cases (e.g. there's probably no point in having grub
>>> on ARM or uboot on x86).
>>
>> uboot on x86 would be nice... :P  Although so would a shipping A9MP
>> chip... :)
>
> And I was just thinking grub would be nice on ARM. :)

I like OpenFirmware. :P

>> I agree with the jist of what you are saying.
>>
>> I also understand the first time you work through the code, you are
>> going to find arch specific bugs, that aren't easy to solve and need to
>> be pushed upstream to the source to get fixed and I am guessing most
>> projects don't have a lot of ARM support.
>
> If that were the case - fine. But dietlibc has claimed ARM support since
> at least v0.30. The really staggering part is that it fails on x86-64,
> too, and failing the test suite it brings with itself seems to be deemed
> the norm.

I vaguely recall them having tests for unimplemented features..

>>>>> concerns me is that it doesn't build on x86 either, at which point I
>>>>> can't but question what the point of having it in the current state is
>>>>> at all.
>>>>
>>>> Dunno.  However I do know that there is a lot of politics at least in
>>>> the past around glibc
>>>>
>>>> http://www.google.com/#hl=en&source=hp&q=glibc+drepper+arrogant
>>>>
>>>> ... so it wouldn't surprise me if it's in the distro as a hedge on that
>>>> as much as anything else.
>>
>> Debian/Ubuntu switched to eglibc which is a "variant" of glibc for
>> embedded systems. They tend to accept more patches. It is compatible
>> wherever possible and they do push changes to the mainline glibc.
>>
>> I think it started mainly because they couldnt get patches put in
>> mainline fast enough and they needed less bloat for embedded like dietlibc.
>
> Much as I hate to say this, but I think they did the right thing. What
> are the chances of the same happening in Fedora?

It sounds like they did the right thing.. I think what they do is they  
take mainline glibc and fold their patches into it and release it as a  
version.

I think you almost have to fork fedora for a bit and see if you can  
get everything built, fix everything that doesn't and get those bugs  
fixed upstream then propose it as a major change for 16.

>> I thought Damn Small Linux, and the Linux router project used dietlibc
>> but I could be wrong or they may have switched to eglibc too. Maybe
>> dietglibc is abandon or folded into eglibc.
>
> Doesn't seem to be abandoned, from what I can tell.

It just hasn't been updated in a year and if 64-bit doesnt work right,  
that is kind of a red flag to me.

>>> It seriously makes you wonder how come there isn't a better, less
>>> politically encumbered libc around. The really vexing thing about the
>>> situation is that both glibc and dietlibc are very gcc specific. This
>>> rather precludes the possibility of having an entire distro built with
>>> another (better) compiler.
>>
>> The Intel compiler's performance boosts of 800% you are seeing are
>> really the SSE optimisation routines. Which Intel is insanely good at it
>> and kudos to them, but they also make the hardware.
>
> Of course. Disappointingly, though most programmers don't use a decent
> vectorizing compiler, so they don't bother making sure that their loops
> vectorize nicely, which limits the effectiveness of a good compiler.
> It's not a replacement for good programming. :(

No but a lot of times if you point it out to them they will fix it. :P
However I'm not sure most distributions by default have vectorization on.


>> If you DO find places in the code where gcc doesn't autovectorize the
>> code properly, please report the code segments as bugs to the gcc group.
>> They need to be aware of the issue so it can be fixed it.
>
> I have done that to some length in the past, and the "better vectorizer"
> is always "due in the next version, just a couple of months away". After
> 3 years of no obvious improvement, I gave up.

I just report them and let them put it on their toDo list, or fix them. :P
It depends on the project whether it gets put at a high enough  
priority to get done.


>> GCC supports a lot more platforms and it might not be the fastest
>> compiler on a specific platform. But it isn't a complete dog either.
>
> It could be argued that this is because most of the competition is
> totally useless. Have a look at the article I wrote on the subject here,
> originally some 3 years ago:
>
> http://www.altechnative.net/?p=58
>
> Having re-run the tests for ICC and GCC the other day with the latest
> versions, the ICC speed-up is virtually identical.
>
> Now if only we could get OSS developers to test that their code works
> correctly with something other than GCC and make sure that their loops
> are written in such a way that they vectorize, there would be a LOT of
> potential performance to be gained.

hmm how are the loops written so they didn't vectorize with gcc in  
your tests? :)