On Thu, Feb 3, 2011 at 4:39 PM, Douglas Geiger <[email protected]> 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. 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 Wed, Feb 2, 2011 at 4:14 PM, Tom Rondeau <[email protected]> wrote: >> 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 Foster 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 >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > > -- > Doug Geiger > [email protected] > _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
