[Liboil] Is liboil still alive?

[Thiago Galesi]

>
> 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
OpenMPI :)

>
> 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
fastest one.

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
>>> any
>>> meaningful activity since June of 2008.
>>> Is the liboil project still alive?  (i.e., should I bother to ask my
>>> questions?)
>>
>> 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
> http://lists.freedesktop.org/mailman/listinfo/liboil
>



-- 
-
Thiago Galesi