Bernie, > gcc 4.1 in F7 has a backport of these patches. No need to switch to 4.3 > if the only advange is -march=geode.
Excellent. I'll set myself up a F7 environment, and look into the compiler behavior and take a look at the compiler source rpms to see if it supports the limited SSE extensions and the two new Geode-only instructions. F8 is almost released - I can take a look at any compiler/geode changes that we'll get for free in that too. (I saw email about OLPC migrating to that over time, at least for i18n, right?) My strengths are in compilers and optimization, which is why I'm trying to help out in this way. If you and Rob have everything under control, or have a road-map in mind for the future, do please let me know. >> 2. People have experimented with backporting just the Geode gcc changes >> we want to gcc 4.1 or 4.2 with success > That would be me :-) I know - I hope you saw that I acknowledged you as having done this when listing the people involved. Above I was I referring to you and Rob both having made contributions to this effort, with the dividing line fuzzy from what I could find after the fact. > If we diverge too much from upstream, then we need > to rebuild (and debug) all updates ourselves. And at this time we > clearly lack engineering resources to do it. How does this change with the recent email that went out about OLPC having its own build system now? Is that just to rebuild the OLPC-specific bits, and everything else still comes from Fedora? > It was hand coded asm for memXXX() and strXXX() function. The 20% figure > comes from a benchmark that calls them in various ways. Great. Shall I take the src.rpms on the gnashdev.org wiki as incorporating the latest version of your hand coded asm? Or are your patches available somewhere else? >> 5. Benchmarking of performance gains in real applications has not been >> done. > > Yes, that would be interesting. It would be great to have it in > our existing tinderbox. Someone else suggested web page rendering as a metric. I'll see about instrumenting the browser to give us accurate timings for page draws under a debug flag. We can then test out different apps and libraries on local html (including a decent amount of graphics) to see if the improvement is noticeable. > I'd suggest delaying such actions until after both these conditions are > satisfied: > > - we get past stable releases for mass production I think most of this can be done in parallel, in private builds and tests, so it'll be ready to integrate with the main project after your big release. > Creating a new build system from scratch takes a considerable > amount of work, and making it robust takes even more time. Very much agreed. This was in response to info from Rob about issues with getting his own glibc builds to work with the modified compiler, and issues with getting a private instance of Koji working well. Is the OLPC build system in a state where we can request it to build a custom glibc (with your inline asm patches) with a custom gcc? Or do we need some sort of private build system for this effort in the meantime? > Our strategy seems to be adopting the existing build system of Fedora 7, > which is quite consolidated these days, with mijor tweaks to the > "compose tools" part so we can create our JFFS2 images. I saw some email traffic about getting geode added as a supported architecture in Fedora, and not knowing how to request Koji to build a geode-variant of some or all packages. Has this gotten better? > I'd prefer staying on [EMAIL PROTECTED] The traffic is not much and we'd > benefit > from the input of the other OLPC developers. Sounds good. We'll leave it here for now. Thanks for all your info. - Brian _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
