[Liboil] [announce] oil-0.1.0

[David Schleef]

On Thu, Aug 27, 2009 at 08:00:23PM +0800, cee1 wrote:
> Some thoughts:
> 1) liboil and oil defines a model: a public function symbol which is bound
> to one of a series implements. Orc will generate only one proper implement
> for such a function symbol(again, am I right?). This applies well to the
> case of inline assembly optimization, but what if approximation algorithm
> optimization? I think we still need the model of one public function symbol,
> multiple implements.

This is exactly the case where the liboil model breaks down.  If
you have one public symbol for a function that might be used by
multiple modules in a complex application, the modules would
potentially fight over which approximation to use.

Also, in my observation, changing the underlying approximation for
an algorithm changes more than just the implemenation of the
liboil-like functions that would be used: it potentially changes
the optimal memory layout, function prototypes, iterators, etc.

For example, the idct8x8_s16 and idct8x8lim10_s16 classes in
liboil do the same operation, but the latter limits the calculation
to the lowest 10 coefficients of the 8x8 DCT block, assuming the
rest of the coefficients are zero.  If these were merged into the
same symbol, the calling code would have to always zero the upper
54 coefficients in case the non-approximated code was called (say
for testing, or for the case where another module overwrote the
preferred implementation.)  This negates much of the reason for
using the approximation in the first place.

> 2) Does Orc perform runtime test like liboil?

I wrote:

> > And if you want to be overly careful and do all
> > the tests at runtime, you can do that, too.

This is all exposed in the API.

> 3) How to generate code in runtime? fork a process and exec "as"?

The source code is not hidden.  Short answer is "no".



dave...