[Liboil] Is liboil still alive?
thiagogalesi at gmail.com
Fri Feb 20 08:32:01 PST 2009
> Correct; but there's lots of things that happen locally in each
> process in the overall distributed/parallel job. These kinds of local
> things are what we're interested in from liboil.
> We do have some numerical operations in MPI, and shared memory message
> transports (e.g., sending messages from one process to another
> transits through shared memory). So we're definitely interested in
> oil_u8_copy(), for example. Some of the other operations may be
> useful as well, but I haven't gotten to look closely at those yet --
> my efforts so far have been with oil_u8_copy().
ok! I imagined this would be the case, there's no distributed
computing without local computing :) As I said, I'm not familiar to
> The general flavor of my questions are:
> - Does oil_u8_copy() make non-temporal copies?
Ok, AFAIK (and that's what I remember from the docs)
When you start a liboil app it will test all different variants of a
function according to your processor's capabilities and will use the
So, even though non-temporal copies are faster, it's essentially down
to what the benchmark found out. It is possible that non-temporal
copies are not implemented, for example check liboil/sse/copy_sse.c
And you can always write your own 'u8_copy' backend as well.
> - In my benchmarking, oil_u8_copy() seems to beat gcc's memcpy() for
> small sizes (e.g., <=128 bytes) for old versions of gcc (3.4.6/the
> default on RHEL4) on older xeon hardware. The docs say that
> oil_u8_copy() is only optimized for small sizes; so that's fine. But
> using more recent hardware (e.g., woodcrest- or wolfdale-class
> servers), the picture becomes much less clear about whether gcc
> 3.4.x's memcpy() is faster than oil_u8_copy() or not. Using other
> compilers' memcpy() implementations (e.g., intel compiler, pathscale
> compiler, etc.) seem to always beat oil_u8_copy(), regardless of size
> and hardware. Newer gcc's (e.g., 4.3.x) also seem to always beat
> oil_u8_copy(), regardless of size and hardware. My question is: is
> this expected behavior?
I'd say it's not expected behaviour :) Problem is, more and more
optimizations are being tucked inside the silicon, as well as gcc and
others becoming "smarter" so, I wouldn't be surprised if gcc comes
with a smarter memcpy.
But for more complex things liboil should perform better.
> Or is there ongoing tuning occurring in
> liboil for oil_u8_copy() (etc.) to try to be as fast as possible and
> beat other implementations?
I think that's liboil's idea, but there doesn't seem to be much
movement going on (as you noticed as well)
>>> But in looking
>>> through the mailing list archives, it seems that there hasn't been
>>> meaningful activity since June of 2008.
>>> Is the liboil project still alive? (i.e., should I bother to ask my
>> I'm afraid I can't answer that question, but liboil is used in several
>> projects including gstreamer, etc
> Good to know.
> Jeff Squyres
> Cisco Systems
> Liboil mailing list
> Liboil at lists.freedesktop.org
More information about the Liboil