discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Using volk in Mac: test report


From: Nick Foster
Subject: Re: [Discuss-gnuradio] Using volk in Mac: test report
Date: Tue, 21 Feb 2012 15:43:48 -0800

Tom, Sean,

There's a couple of things here. First, the Orc volk_32fc_s32f_magnitude_16i_a function is rounding differently than the generic versions on E100 for some reason. Not fatal, totally usable, but it makes the QA code fail. Second, the volk_32fc_x2_multiply_32fc_a looks like it's working fine but the thresholds are too close in the comparison function, which is strange because it uses the same threshold I use everywhere else. I'll keep looking into that. In any case, they're fine for use in Volk as-is.

I think the segfault in volk_32fc_s32fc_multiply_32fc_a is being caused by a bug in the profiler code as well. It's not correctly handling complex scalars. The function itself doesn't actually work either, which doesn't help, but it wasn't caught because the profiler code was buggy...

Tom, I pushed a fix to my github under "volk_fix". For now I've disabled volk_32fc_s32fc_multiple_32fc_a since I can't figure out a clean way to get it to work under Orc; I had a misunderstanding of how float parameters are handled inside array operations. I also added complex scalar handling. I'll keep looking into solving this one for real but this will get things working for now.

--n

On Sat, Feb 18, 2012 at 1:05 PM, Tom Rondeau <address@hidden> wrote:
On Fri, Feb 17, 2012 at 6:04 PM, Nowlan, Sean <address@hidden> wrote:

Don’t know how helpful these are, but here you go.

 

Sean


Sean,
It looks like a couple of functions are failing from the stdout:

volk_32fc_s32f_magnitude_16i_a: fail on arch orc
volk_32fc_x2_multiply_32fc_a: fail on arch orc

These are both the Orc implementations of the functions, which seem to work fine on my Intel processors. I don't have access to an OSX box or an E100, so I can't really test this out. The files you sent me don't (appear to) tell me what the real problem is.

We'll need some other brave soul out there who can dig into these issues on the platforms for us.

Thanks,
Tom


  

From: address@hidden [mailto:address@hidden] On Behalf Of Tom Rondeau
Sent: Friday, February 17, 2012 5:25 PM
To: Nowlan, Sean
Cc: Nick Foster; address@hidden


Subject: Re: [Discuss-gnuradio] Using volk in Mac: test report

 

On Fri, Feb 17, 2012 at 5:11 PM, Nowlan, Sean <address@hidden> wrote:

I built Tom’s safe_align branch on E100 and ran volk_profile. It segfaulted on “RUN_VOLK_TESTS:volk_32fc_s32fc_multiply_32fc_a. I’ll get a stack trace for you.

 

Sean

 

Really interesting that it's the same block. Hopefully, it's a single, simple fix. I'll look into it when you can get me the stack trace.

 

Thanks for reporting!

Tom

 

 

 

From: discuss-gnuradio-bounces+sean.nowlan=address@hidden [mailto:discuss-gnuradio-bounces+sean.nowlan=address@hidden] On Behalf Of Tom Rondeau
Sent: Friday, February 17, 2012 2:33 PM
To: Nick Foster
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Using volk in Mac: test report

 

On Fri, Feb 17, 2012 at 2:30 PM, Nick Foster <address@hidden> wrote:

On Fri, Feb 17, 2012 at 11:20 AM, Carles Fernandez <address@hidden> wrote:

Thanks for the inputs!

We are interested in determining the best architecture at instantation
time. What would be the best strategy? We though about running the
same operations several times for each architecture, measure the
results and use the fastest one for the processing blocks. Would this
be the right approach?

 

Carles,

 

Run volk_profile. It does exactly what you said, and writes the results to ~/.volk/volk_config. Volk reads this file when it is involked (sorry) to determine which particular function to execute. So all you do is run volk_profile once on any given machine, and it's optimized.

 

--n

 

Carles,

This is discussed on the webpage:

 

We'll be updating this as things progress with Volk, but the profiler info is there already.

 

Tom

 

 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]