On Thu, Feb 3, 2011 at 4:39 PM, Douglas G.
[email protected] wrote:
Is orc going to become a required/recommended tool for building
gnuradio/volk, or is volk simply using it when available to help with
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. You’re correct that Orc has similar goals as
Volk, except that Volk is depending on kernels to be built by hand for
various architectures; Orc is actually probably smarter in that it
compiles vectorized routines for an architecture. In an ideal world,
we shouldn’t need Volk because Orc would be able to do its thing.
There are two main reasons why we went the Volk direction, though.
First, we wanted a standard, immutable* interface for GNU Radio, which
we get to control with Volk. If some Volk functions just become a
pass-through to Orc, at leasts we’ve been able to make a common
The second reason is performance. While the Orc development seems to
be making good strides in this area, the compiled results of Orc can
be suboptimal. Hand-tunning the code using either the intrinsics or
actual assembly gives us the ability to provide excellent results on a
number of platforms (if not all platforms).
I plan that Orc will never be required. The way it works currently is
the way Volk handles all architectures: it looks to see if an
architecture is supported, and will use it if it is. So if Orc is
installed on your system, any Orc functions will also be compiled. We
eventually might get to a point where Orc is recommended, but probably
In my mind, I see Volk development in this way. You need a math kernel
to do some function. You write the generic C++ code that gives you the
results you need. Now, you want to vectorize it. The first thing to do
is probably just create the Orc function to do this. As you (or others
using your Volk kernel) see problems on a particular architecture or
speed concerns (or you just don’t trust what Orc is doing), you can go
in and hand-code your optimized kernels for the function on various
Right now, Orc is still under pretty fast moving development, so we’re
not going to rely on it at all until everything catches up.
*I say immutable, but things could potentially change. We have created
a standard for Volk function naming that you can find at the website
below. We fee that this naming convention covers most of the variants
we could think of. If we follow it, we shouldn’t ever need to change
the Volk API (fingers crossed).