[fedora-arm] dietlibc port?

[Gordan Bobic]

omalleys at msu.edu wrote:

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

Forking a distro is a bit too much for me to chew at the moment. Just 
fixing up the packages I actually need to use is enough work as it is, 
without taking on all the rest as well. :)

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

Maybe, but the person whose email address is all over the spec file 
responded to the RH bugzilla ticket pretty quickly. :)

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

I suspect the reason it's not on is because:

1) Most code hasn't been written with it in mind

2) Vectorizer is not working well enough to make a difference worth 
pursuing even on the code that has been written with it in mind.

3) Because it's not widely used, it is probably deemed insufficiently 
tested. GCC seems to miscompile at lesser provocations (see earlier in 
this thread about binaries that segfault when -O > 1 is used.

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

Yes, I get depressed every time I look at the ver-growing list of open 
bugs I have filed on RH bugzilla...

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

Here are some links to threads where I discussed this on some other 
mailing lists years ago. Not much has changed since then:

http://gcc.gnu.org/ml/gcc-help/2007-08/msg00167.html

And another one loosely touching upon the subject on the GSL mailing list:

http://www.mail-archive.com/help-gsl@gnu.org/msg01453.html

I wouldn't hold my breath for a properly working GCC vectorizer. 
<sarcasm>MMX and SSE have been around for only a decade and a half, we 
can't expect the most widely used compiler in the world to catch up so 
soon.</sarcasm>

Gordan