Work around for gr.multiply_cc( ) for non NEON enabled ARM devices

Has anyone developed a work around for replacing gr.multiple_cc() to
work on ARM devices that have to disable NEON in order to install? I
have two lines in gr.ais that keep giving me overflow.

Thanks ahead of time,

karl

On Thu, Feb 14, 2013 at 10:08 AM, Karl Petrow <
[email protected]> wrote:

karl

You can turn it off. Have you run ‘volk_profile’ on the system, yet? If
so,
that would have generated a ~/.volk/volk_config. You can edit that file
by
hand to specify the architecture you want as ‘generic’ for whatever
kernel
is causing you trouble. This just runs a standard C for loop with no
SIMD
instructions (except whatever the compiler tries to do).

Tom

too much for the RPi.

Thanks

karl

A tangential comment here. You never need to run ordinary commands as
root. The only part of any source
code build that usually requires root privilege (via sudo) is the
install phase, because that’s moving generated
code into parts of the system that you, as an ordinary user, can’t
write to.

But running your applications, building code, etc, don’t require root
privilege.

The Pi is having some problems running:
sudo volk_profile

It pegs out at 100% and I just cut it at 24 hours. I am going to reboot
and run it on terminal only with it overclocked for the weekend, but do
you have any other suggestions? I was really excited about Volk after
reading up on it, but unfortunately it seems to be too much for the RPi.

Thanks

karl

From: [email protected] [mailto:[email protected]] On Behalf Of
Tom R.
Sent: Thursday, February 14, 2013 10:42 AM
To: Karl Petrow
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Work around for gr.multiply_cc( ) for
non NEON enabled ARM devices

On Thu, Feb 14, 2013 at 10:08 AM, Karl Petrow
<[email protected]mailto:[email protected]>
wrote:
Has anyone developed a work around for replacing gr.multiple_cc() to
work on ARM devices that have to disable NEON in order to install? I
have two lines in gr.ais that keep giving me overflow.

Thanks ahead of time,

karl

You can turn it off. Have you run ‘volk_profile’ on the system, yet? If
so, that would have generated a ~/.volk/volk_config. You can edit that
file by hand to specify the architecture you want as ‘generic’ for
whatever kernel is causing you trouble. This just runs a standard C for
loop with no SIMD instructions (except whatever the compiler tries to
do).

Tom

On Fri, Feb 15, 2013 at 12:21 PM, Karl Petrow <
[email protected]> wrote:


Thanks****


karl

You can edit volk/apps/volk_profile.cc and change the the number of
samples
and iterations it runs for each kernel. The function call is (from
volk/lib/qa_utils.h):

#define VOLK_PROFILE(func, tol, scalar, len, iter, results)

So len and iter can be decreased for your processor’s needs.

Tom

On Fri, Feb 15, 2013 at 11:26 AM, Marcus D. Leech [email protected]
wrote:

I’m not sure if you’ve seen some of the RPi/gnuradio commentary, but
this is a good summary:
https://lists.gnu.org/archive/html/discuss-gnuradio/2013-01/msg00226.html

The first test that volk_profile runs
(volk_32fc_s32fc_x2_rotator_32fc_a) takes several minutes on my Core2
duo. I would also expect it to take a very long time on an RPi. That
said, the discussion previously linked would make me think that
running volk_profile on an RPi wouldn’t actually do anything useful as
there’s no SIMD architecture to take advantage of. Everything would be
set to generic after running for a long time which is the same result
as not running volk_profile at all (minus days of runtime).

If you want to test this you can remove that first test from
volk_profile and rebuild. The subsequent tests will probably take
about 10-20 minutes each but you might actually see some progress.

code build that usually requires root privilege (via sudo) is the install
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

-nathan

Ah, I neglected the context of wanting to run volk_profile. Sorry! :slight_smile:

You might first try just manually creating ~/.volk/volk_config and
setting whatever kernel you need set to generic. Unless I’m mistaken
you don’t really need to whole config.

I’m a little confused here. The RPi has no NEON unit. So Volk, which is
designed to accelerate common functions for vector processing units like
NEON, won’t actually do anything on RPi; every kernel executed will be
the unaccelerated generic version. I understand the motivation behind
Tom’s earlier suggestion to fix Volk on non-NEON ARM devices by forcing
all kernels to “generic” in volk_config, but I don’t understand the
reason to attempt to get volk_profile to run on a device which doesn’t
support anything other than the generic kernels.

That said, Volk includes a routine to detect NEON support on ARM
platforms (volk/tmpl/volk_cpu.tmpl.c:static int has_neon(void)), and
should correctly refuse to run NEON kernels on non-NEON platforms,
although I only have one report from a user who tested the negative case
(no NEON) successfully. So all this is to say I have no idea why
volk_profile is hanging, but it’s pointless to run it on your platform
anyway. If you really still want to run volk_profile, try turning down
the number of iterations of each routine to 1 or something and see if it
completes for you.

–n

I recompiled the program with commenting out all non-multiply
kernels(see attached). Still pegged out for 2 hours and still going.
Do you know specifically which kernel relates to the multiply_cc
function?

Thanks again,

kyp

From: [email protected] [mailto:[email protected]] On Behalf Of
Tom R.
Sent: Friday, February 15, 2013 1:09 PM
To: Karl Petrow
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Work around for gr.multiply_cc( ) for
non NEON enabled ARM devices

On Fri, Feb 15, 2013 at 12:21 PM, Karl Petrow
<[email protected]mailto:[email protected]>
wrote:
The Pi is having some problems running:
sudo volk_profile

It pegs out at 100% and I just cut it at 24 hours. I am going to reboot
and run it on terminal only with it overclocked for the weekend, but do
you have any other suggestions? I was really excited about Volk after
reading up on it, but unfortunately it seems to be too much for the RPi.

Thanks

karl

You can edit volk/apps/volk_profile.cc and change the the number of
samples and iterations it runs for each kernel. The function call is
(from volk/lib/qa_utils.h):

#define VOLK_PROFILE(func, tol, scalar, len, iter, results)

So len and iter can be decreased for your processor’s needs.

Tom

From: [email protected]mailto:[email protected]
[mailto:[email protected]mailto:[email protected]] On Behalf
Of Tom R.
Sent: Thursday, February 14, 2013 10:42 AM
To: Karl Petrow
Cc: [email protected]mailto:[email protected]
Subject: Re: [Discuss-gnuradio] Work around for gr.multiply_cc( ) for
non NEON enabled ARM devices

On Thu, Feb 14, 2013 at 10:08 AM, Karl Petrow
<[email protected]mailto:[email protected]>
wrote:
Has anyone developed a work around for replacing gr.multiple_cc() to
work on ARM devices that have to disable NEON in order to install? I
have two lines in gr.ais that keep giving me overflow.

Thanks ahead of time,

karl

You can turn it off. Have you run ‘volk_profile’ on the system, yet? If
so, that would have generated a ~/.volk/volk_config. You can edit that
file by hand to specify the architecture you want as ‘generic’ for
whatever kernel is causing you trouble. This just runs a standard C for
loop with no SIMD instructions (except whatever the compiler tries to
do).

Tom