9 Jul
2018
9 Jul
'18
6:35 p.m.
Hi,
I have submitted a pull request on Github[1] which improves the
performance of the hackrf source. With this patch the conversion
int8_t -> float is done in realtime instead of looking up values in
the "_lut" lookup table.
In this way the compiler is able to generate AVX/SSE code (-O3
-march=native) to perform the conversion.
In [2] you can find a benchmark to show the differences.
Using -Ofast (or -O3) and -march=native I get ~2.8x using an
Intel i7 (4th gen) and 3.1x on a Core i5 (6th gen).
Gqrx with the patched library can play a WFM radio without any
interruption even with just 3 buffers (option="hackrf=0,buffers=3").
Best regards,
Alain
[1] https://github.com/osmocom/gr-osmosdr/pull/14
[2] https://gist.github.com/carpikes/cad029c338605f70d9f687aeee447db4
10 Jul
10 Jul
10:05 a.m.
I would say, just remember that gr-osmosdr is not intended only to x86,
but also for ARM and other archs that does not even have SIMD. Also
there are some x86 nowadays that does not have AVX code. The LUT
solution is the "generic" one that works average on all platforms
(calculate on the fly for any arch that does not have SIMD conversion
will make a great performance loss).
Lucas
Em 09/07/2018 13:35, Alain Carlucci escreveu:
Hi,
I have submitted a pull request on Github[1] which improves the
performance of the hackrf source. With this patch the conversion
int8_t -> float is done in realtime instead of looking up values in
the "_lut" lookup table.
In this way the compiler is able to generate AVX/SSE code (-O3
-march=native) to perform the conversion.
In [2] you can find a benchmark to show the differences.
Using -Ofast (or -O3) and -march=native I get ~2.8x using an
Intel i7 (4th gen) and 3.1x on a Core i5 (6th gen).
Gqrx with the patched library can play a WFM radio without any
interruption even with just 3 buffers (option="hackrf=0,buffers=3").
Best regards,
Alain
[1] https://github.com/osmocom/gr-osmosdr/pull/14
[2] https://gist.github.com/carpikes/cad029c338605f70d9f687aeee447db4
--
Lucas Teske
Teske Virtual System
GPG: BD29 7EF3 4CCB EB61 B790 06C3 351A 8000 DEAD CE11
GPG: 4A90 974B ACE0 A9A6 AF09 B3B1 6C39 C1C1 6A9D A7BE
GPG: BD09 9175 6DE8 37F4 08D3 B296 DE7A 51C3 87C9 27EE
11 Jul
11 Jul
7:05 p.m.
Hi Lucase,
On Tue, Jul 10, 2018 at 05:05:26AM -0300, Lucas Teske wrote:
I would say, just remember that gr-osmosdr is not
intended only to x86,
but also for ARM and other archs that does not even have SIMD. Also
there are some x86 nowadays that does not have AVX code. The LUT
solution is the "generic" one that works average on all platforms
(calculate on the fly for any arch that does not have SIMD conversion
will make a great performance loss).
I agree with the above statement. Having compile-time flags is not a solution,
as most people will just use a distribution package - and distributions will
have to compile the most general and non-cpu-specific code.
The proper approach for this kind of problem is to have run-time CPU feature
detection and then use the most optimal code for the given CPU. This is what
we're e.g. dong in osmo-trx.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
10:03 p.m.
GNUradio has the whole VOLK infrastructure in place to provide generic
code + optimized code per architecture + run time selection and even
benchmarking to select the fastest version.
So I would suggest just using the volk_8i_s32f_convert_32 kernel and
be done with it.
If some current code is faster than the current volk implementations
available, then a second patch can be submitted to volk to add this
arch specific implementation and allow it to be used.
Cheers,
Sylvain
2537
days inactive
2539
days old
3 comments
4 participants
participants (4)
-
Alain Carlucci -
Harald Welte -
Lucas Teske -
Sylvain Munaut