omalleys(a)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