Re: [Discuss-gnuradio] GNU Radio release 3.6.3 available for download

[Albert Chun-Chieh Huang]

Hi, Tom and Michael,

Here is part of the message when I configure to use gcc 4.7 without orc
support(and the build was failed)

====================
-- ORC support not found, Overruled arch orc
-- Check size of void*[8]
-- Check size of void*[8] - done
-- CPU width is 64 bits, Overruled arch 32
-- Available architectures: 
generic;64;3dnow;abm;popcount;mmx;sse;sse2;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx
-- Available machines: 
generic;sse2_64_mmx;sse3_64;ssse3_64;sse4_a_64;sse4_1_64;sse4_2_64;avx_64_mmx
-- Did not find liborc and orcc, disabling orc support...
====================


For volk_profile output, I'll put it on my public folder of Dropbox
since it's lengthy.

volk_profile output with ORC support:
https://dl.dropbox.com/u/31960195/volk_profile_output.txt

volk_profile output without ORC support:
https://dl.dropbox.com/u/31960195/volk_profile_output_no_orc.txt

Before MacPorts has GNU Radio packages, I always need to build gnuradio
by myself. I remember that I need to modify some files in VOLK in order
to support optimization for AVX. I don't remember the exact reason, but
it's related to Apple assembler and probably xgetbv(?) instruction
set. Here is the version of Apple assembler:

Apple Inc version cctools-836, GNU assembler version 1.38

I wonder if I can use the latest GNU assembler with VOLK?


Thank you very much!

Albert


Michael Dickens <address@hidden> writes:

> Albert - Tom (as a VOLK developer) has some good advice:
>
> (1) Try installing GNU Radio without the +orc variant, and seeing what the 
> configure output is; combined with:
>
> (2) Run "volk_profile" after you've installed GNU Radio.  It will test all of 
> the kernels and create a $HOME/.volk/volk_config file.  If you look in that 
> file, it will tell you what architectures are to be used for each kernel.
>
> Tom - I'm wondering what "volk_profile" is doing?  It looks like it's running 
> through (all?) available kernels for a given algorithm and finding the "best" 
> (fastest?) one.  Is this correct?
>