Re: [Discuss-gnuradio] [VOLK] SIMD accelerated Mersenne-Twister

[Stefan Wunsch]

About the use of VOLK (and random number generators):

I see two large groups of users. The one group knows everything about
their CPU but little about SIMD, the other one knows all about SIMD but
almost nothing about their CPU.

The first group uses VOLK because they call a VOLK function and get in
return the fastest possible implementation without thinking about SIMD
stuff. That's convenient and obviously portable, but you could use,
e.g., an AVX specific implementation as well because you know that it
will work with your CPU. All in all, VOLK is really nice but not
absolutely necessary for your work. That's probably the typical gnuradio
user, who runs his program on a single machine.

The latter group is interested in the portability, which is one of the
unique features of VOLK. E.g., you want to run your program on a server
farm. Then you could know everything about SIMD but you never know on
which machine you'll run your program because there are a lot of
different CPUs used in your farm. Mostly you want to simulate sth if you
have this use-case. And in almost every simulation you need random
numbers ;)

I have to admit that the benefit for gnuradio isn't that great but if
you want to promote VOLK as a generic library for the use of SIMD, the
SFMT (SIMD-oriented fast Mersenne Twister) implementation could be a
really interesting part.

Nevertheless, I will put the code in a VOLK OOT and publish it on my
github page. As far as I understand the copyright problem, this should
be possible because the OOT copyright isn't managed by the FSF (and the
licences match). If someone really starts to use this feature, we can
still reconsider to merge it in VOLK directly.

Greetings
Stefan

On 11/12/2015 04:23 AM, Tom Rondeau wrote:
> On Wed, Nov 11, 2015 at 4:40 PM, Johnathan Corgan <address@hidden>
> wrote:
> 
>> On Wed, Nov 11, 2015 at 10:47 AM, Martin Braun <address@hidden>
>> wrote:
>>
>>
>>> Since you're not the copyright holder of the original code, you have no
>>> way of transferring said copyright to the FSF.
>>>
>>> I'm not sure what the correct way to do this is. An out-of-tree approach
>>> will definitely work, since the licenses are compatible according to
>>> lists provided by e.g. the FSF.
>>> If the authors would agree to a copyright transfer of this copy of the
>>> code, that'll also work but it's annoying to get that.
>>
>>
>> ​While all the above is true, we do occasionally make exceptions for
>> including non-FSF owned code inside GNU Radio, as long a the licenses are
>> compatible.  We try to avoid this as much as possible and have actually
>> been removing such code a little at a time as it becomes possible.​
>>
>> In this case, I don't think we'd want to include it, but I wanted to
>> clarify the above.​
>>
>> --
>> Johnathan Corgan
>> Corgan Labs - SDR Training and Development Services
>> http://corganlabs.com
>>
> 
> 
> I agree with Johnathan. While this is really great work, Stefan, I'm not
> sure it's worth any great hassle on our part to manage it. I'm mostly
> saying this because I don't see where this would be used in large part in
> real-world applications. Most of our randomness is necessary in
> simulation-based flowgraphs. While it's always good to speed up your
> simulation, it's not something that's absolutely critical.
> 
> I think the best case scenario is that we get the copyright agreement from
> the original author. Barring that, if you provide a compelling enough case
> for including it within GNU Radio's source code as opposed to an OOT
> project, we can discuss and reconsider.
> 
> Tom
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>