On 09/02/2015 01:41 PM, Marcus D. Leech wrote:
On 09/02/2015 01:35 PM, Marcus Müller wrote:
I'd say we rather want better
randomness than faster noise sources
If that's the case, I'd recommend that Stefan uses the
normal_distribution variate from boost (Stefan, see my example), rather
than doin
On 09/02/2015 01:35 PM, Marcus Müller wrote:
I'd say we rather want better
randomness than faster noise sources
If that's the case, I'd recommend that Stefan uses the
normal_distribution variate from boost (Stefan, see my example), rather
than doing his own "normalization" of the RV, and we use
> I'd say we rather want better
> randomness than faster noise sources
If that's the case, I'd recommend that Stefan uses the
normal_distribution variate from boost (Stefan, see my example), rather
than doing his own "normalization" of the RV, and we use that.
Regarding Boost's mt19937 and the way
On Wed, Sep 2, 2015 at 12:39 PM, Marcus Müller
wrote:
> Hi Andre!
>
> Wow, that's a bit much to read right now. The problem I have with using
> AVX2 would be portability, which would be no issue if we wrapped RNG in
> a VOLK kernel and offered a good baseline competitor in portable C code.
> Poin
On 02.09.2015 05:10, Stefan Wunsch wrote:
> Now my question: Before doing a pull request, do you have any concerns
> regarding memory use or processing load? Obviously the new
> implementation isn't that light-weight as the ten lines of code before.
> But the current implementation can not be used
Hi Andre!
Wow, that's a bit much to read right now. The problem I have with using
AVX2 would be portability, which would be no issue if we wrapped RNG in
a VOLK kernel and offered a good baseline competitor in portable C code.
Point is though that our alternative in RNG seems to be boost::mt19937,
Hi Stefan,
hehe, I thought you might have an idea how to benchmark memory
consumption. So I'm stuck with this myself :)
What I can definitely say is that the -O3 variant of boost definitely
can't allocate much memory, based on the time it needs -- frequent
allocations would probably have caught m
Hi all,
for me, these results don't look that bad. Consider that the quality of
the random numbers is increased enormously and with an ordinary
simulation you loop the period length of the current generator (about
1e8 samples) multiple times. The results should be highly correlated if
you use appr
Hi guys,
a few days ago I stumbled over an RNG implementation [2] that uses some
of the newer AVX2 instructions. I guess this would improve performance
radically. There is also a paper on the matter [1].
Cheers
Andre
[1] http://agner.org/random/theory/randomvector.pdf
[2] http://agner.org/rando
Hi Stefan,
strange, I was looking at the same code just a few days ago, when I
needed to find out whether I understood filters well enough by pushing
noise through. Here's my small testcases (thankfully I didn't restart my
machine since then -- these were still in /tmp).
So, in fact, I tested the
Hi!
I have discovered that the implemented random number generator in
gnuradio (see file [0]) is almost older than me. As written in the code,
the implementation is taken from 'Numerical recipes in C' (see version
from 1992). The problem is that this algorithm is really bad compared to
current alg
11 matches
Mail list logo
