[Liboil] Re: Questions about liboil

[David Schleef]

I hope you don't mind that I forwarded this to the liboil
mailing list.


On Sat, Oct 29, 2005 at 02:11:58PM -0700, James Cheng wrote:
> This is James Cheng from the mediaLib team at Sun.  Brian Cameron
> pointed us to your web page for liboil and asked if we could help
> accelerating liboil functions with mediaLib on Solaris.
> 
> After trying a little bit with liboil, I got a couple of questions.
> It seems to me that for any given platform, say Solaris/SPARC, all
> implementations are combined into a single (.so) dynamic library.
> I wonder when more and more functions are added to liboil, will the
> size of the .so increase too much, and will that affect the speed
> of oil_optimize_all() too much?

I'm not too concerned with sheer code size, since essentially
all non-embedded systems are demand-paged these days, so
uninteresting pages won't be loaded.  Besides, average RAM
size is increasing more rapidly than the liboil code base.

As you noticed, the bigger issue is oil_optimize_all(), which
currently takes processor time proportional to the number of
available implementations.  As N gets large, this will clearly
become an issue.  Making this a priority to fix would violate
David's Optimization Rules #1 and #2, which are:

 1. Don't Optimize.  No, really.  Go buy a faster CPU.  Because
    if you're reading this, you probably haven't profiled your
    code and don't even know what needs to be fixed.

 2. Only spend time on code where you are fairly certain you
    can get a 10% overall speedup.  This niche of the open source
    project space has lots of low hanging fruit.  Go fix those
    instead.

I should probably mention Rule #0, too:

 0. All optimization rules have exceptions.

So yes, it will be an issue some day.  But since the central goal
of liboil is to make things faster, I think it's better to work
on stuff that can measurably make actual applications faster.
That pesky corner case of actually starting the app doesn't
matter.  :)

That being said, here are some ideas that can be used in place of
the current strategy:

 - Only profile implementations for a particular function class
   when it is used (or requested).

 - Have an on-disk cache of profile times.  Useful in many cases,
   but needs careful thought on diskless systems.

 - Attempt to develop heuristics for guessing the performance of
   implementations based on programmer rating (0 - "pulled from
   my ass" to 10 - "divinely inspired") and instruction set used.
   This needs tuning for the variety of CPUs out there.

 - Careful culling of crappy code.  (Alliteration accidental.)

The actual solution will probably be a combination of the above
techniques.  The current technique was chosen because it has
very few failure modes, and was needed anyway.

On a side note, I've already done some work on creating shared
objects that are targeted for a particular CPU and thus have
nearly zero startup cost, especially for embedded systems, where
having anything extra has a cost.  This could also be handy for
vendors wishing to (easily) pull a few extra cycles out of a
particular machine, at the cost of not being optimally portable.

> Another question is whether liboil is MT-safe.  It seems to me that
> some global variables, such as inited, are used.  I wonder whether
> the sorting of multiple implementations could get messed up when
> multiple threads are calling oil_init() or oil_optimize_all() at
> about the same time.

No, oil_init() is not currently thread-safe.  It should be.  Once
that is done, all the other (public API) code is thread-safe.

> Any insight on those questions/concerns will be very much appreciated.
> I think you have done a great job on designing the framework to make
> liboil easy to port, test, and use.

Thanks.  Medialib was certainly a significant source of inspiration
for liboil.

> Please let us know if we can
> be helpful, especially for the Solaris platform.

Release a version of medialib for Linux?



dave...

-- 
David Schleef
Big Kitten LLC (http://www.bigkitten.com/) -- data acquisition on Linux