Re: [Discuss-gnuradio] Next updated

[Nick Foster]

On Thu, 2011-02-03 at 16:57 -0500, Tom Rondeau wrote:
> On Thu, Feb 3, 2011 at 4:39 PM, Douglas Geiger
> <address@hidden> wrote:
> > Among some of the additions in there was the new library libvolk_orc -
> > which apparently requires orc to build. Can you give a brief bit about
> > the use of orc? I gather from google that it is the oil runtime
> > compiler, and that it is part of the liboil, which seems to have at
> > least a related set of goals as volk. Is orc going to become a
> > required/recommended tool for building gnuradio/volk, or is volk
> > simply using it when available to help with optimization?On that
> > subject, can you give a brief bit about the use of orc? I gather from
> > google that it is the oil runtime compiler, and that it is part of the
> > liboil, which seems to have at least a related set of goals as volk.
> > Is orc going to become a required/recommended tool for building
> > gnuradio/volk, or is volk simply using it when available to help with
> > optimization?
> >  Thanks,
> >  Doug
> 
> 
> Sure, that's a fair question, although you weren't supposed to see
> that about including orc, now ;)
> 
> Nick will probably give you a better description than me, but I'll try
> to sum it up quickly.

Just to add to Tom's excellent description: Orc is a generalized vector
assembly language, runtime environment, and compiler intended to provide
fast vectorized machine code for a variety of architectures. The primary
reason for including it in Volk is for use on the NEON architecture.
Using Orc means we don't have to write and test NEON vector assembly
routines for all the Volk stuff. Plus, letting Orc handle vectorizing,
instruction scheduling, loop counting, and alignment makes things much
easier. That said, you can usually do better with hand-tuned assembly;
but if we can get 80% of the speed with 10% of the effort, that's a win
for most users. If you need that last 20%, it might be worth it to you
to hand-code a NEON version of the routine you need.

This is especially helpful on OMAP since current versions of GCC are
really, really bad at vectorizing for NEON. CodeSourcery has done some
good work in this area but their contributions haven't hit the mainline
yet. As a result, there is a large potential gain in Gnuradio capability
on that chipset. We think.

All the intrinsic routines in the current Volk implementation are
x86-specific. These are pretty tightly-crafted for the most part, and
having an Orc alternative to these isn't likely to improve performance
on x86 architectures. But the Orc routines will compile for MMX, SSE,
AltiVec and NEON. I'm expecting that future expansions in capability to
the Volk library will start with an Orc implementation, with intrinsic
implementations following as time allows and need evolves.

The way Volk is structured, if a "fast" implementation of a particular
routine isn't found, Volk will fall back to a generic C implementation
instead. So if there's an Orc version of a routine in Volk and you don't
have Orc installed, it'll just use the generic version instead (if no
platform-specific version is found). This way, Orc will never be
required for Gnuradio -- it'll just speed some things up (on NEON
especially) if you have it.

--n