optimized Geode code (was Re: OLPC upgrades)

[Peter Robinson]

Hi All,

>>> Tiago Marques wrote:
>>>>
>>>> That software is still not compiled for the Geode LX, which further
>>>
>>> slows it down.
>>>>
>>>> As you say, everything uses CPU on the Geode. Things like
>>>
>>> decompressing can be made, probably, a lot faster just by using compiler
>>> optimizations. Has this been considered in any way for future releases?
>>>>
>>>> From my professional experience, compiler optimizations can account
>>>
>>> for 10-30% (or more) free performance.
>>>
>>> It seems the binaries in the OLPC OS image are just generic 386 arch
>>> binaries.  (Is there a way to definitively tell?  A build log like
>>> <http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/latest/devel_jffs2/build.log>
>>> is unclear.)
>>
>> file doesn't say much, everything I have compiled with -march=i686 still
>> shows up as i386 binary. I don't know of anything that might tell us that.

Actually while the binary rpm is labelled i386 its compiled using some
other config which I believe is something around i586 or maybe i486 +
some other options which are specified through rpm. Geode is
essentially i586 + cmov (which on intel cpus is i686). There's been a
discussion on fedora-devel [1] about this exact stuff at the moment
due to the introduction of gcc-4.4 in rawhide and some planned uplift
of compiler options, some which is interesting and alot as usual is
opinion. I did bring up the OLPC Geode case to ensure we we're not
forgotten.

> well we use standard Fedora repositories, so I think everything is
> i386.  It would be interesting to see if it actually made a
> difference, if there were real performance increases perhaps Geode can
> be added as a supported arch in Koji.

Koji can support geode, the problem with going that route is that we
become a secondary architecture which means we have to provide the
build servers for it and the space to host essentially a build
infrastructure to be able to rebuild all of Fedora for geode (the way
koji works).

Basically I think what comes out will be fairly close to optimal for
geode. The difference between what mainline Fedora goes with and if we
did a geode option would probably from my reading something less than
1% difference. They're also looking at the -O options, I think Fedora
uses -O2 atm but is considering -O3 or -Os which would help us as
well. There's also alot of code out there that can hot plug the best
cpu options at run time where it matters (see liboil) for multimedia
etc and cairo, gstreamer and the like already use these fairly
extensively.

I would be personally be wary about secondary arch as it would add
alot of extra work and prob cost with likely sub 1% gains. Also
there's alot of RH Fedora people that are involved from the periphery
with OLPC so I don't think we'll lose out in that regard.

Peter

[1]https://www.redhat.com/archives/fedora-devel-list/2009-February/msg00200.html