Quoting Gordan Bobic <gordan@xxxxxxxxxx>: > omalleys@xxxxxxx 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? :) _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
