Next updated

Hi list,
I just wanted to point out that I pushed a big change to volk onto the
next branch of our git repo (thanks very much to Nick F. for doing
a ton of the work here). This should not effect anyone, but there’s a
chance this change may affect your builds. If you have problems after
updating, first try to clean up the files with a “git clean -d -x -f”
and rebuild. I’ve done checked it on multiple boxes, and it all looks
ok to me, but I wanted to warn everyone, anyways.

If you have further problems, let me know.

Tom

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

On Wed, Feb 2, 2011 at 4:14 PM, Tom R. [email protected]
wrote:

Tom


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Doug G.
[email protected]

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
optimization?
Thanks,
Doug

Sure, that’s a fair question, although you weren’t supposed to see
that about including orc, now :wink:

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
interface.

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
not required.

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
archs.

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).
http://gnuradio.org/redmine/wiki/gnuradio/volk

Tom

On Thu, 2011-02-03 at 16:57 -0500, Tom R. wrote:

google that it is the oil runtime compiler, and that it is part of the

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs