[fedora-arm] dietlibc port?

[Gordan Bobic]

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 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.

>>>> 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?

> 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 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. :(

> 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.

> 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.

Gordan