[Liboil] Re: Questions about liboil
ds at schleef.org
Sat Oct 29 17:04:02 PDT 2005
I hope you don't mind that I forwarded this to the liboil
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
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
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
> Please let us know if we can
> be helpful, especially for the Solaris platform.
Release a version of medialib for Linux?
Big Kitten LLC (http://www.bigkitten.com/) -- data acquisition on Linux
More information about the Liboil