commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [math] new pseudo random number generators
Date Tue, 21 Sep 2010 10:40:21 GMT
On 21 September 2010 09:40, Mikkel Meyer Andersen <mikl@mikl.dk> wrote:
> 2010/9/21 Luc Maisonobe <Luc.Maisonobe@free.fr>:
>> Le 21/09/2010 10:08, Mikkel Meyer Andersen a écrit :
>>> 2010/9/21 Luc Maisonobe <Luc.Maisonobe@free.fr>:
>>>> Le 21/09/2010 09:26, Mikkel Meyer Andersen a écrit :
>>>>>> Here is an extract from the answer from Pierre L'Ecuyer:
>>>>>>
>>>>>>  Our code can be released under either a GPL or a commercial license.
>>>>> Well, what about the Apache License then?
>>>>
>>>> It is their code and I did not use it. The main point is we
>>>> reimplemented it. Of course, relying on their code that is GPLed would
>>>> be a clear no-go as GPL is a category X license (see
>>>> <http://www.apache.org/legal/resolved.html#category-x>).
>>> Exactly. But as I understood, you used some of their optimization
>>> principles - but that is not an issue or?
>>
>> I finally inlined everything, yes but I doubt it would count as a
>> specific optimization found only in this original code. It's a common
>> way and especially when the code to be inlined is one or two
>> instructions only. The elementary transforms here are very simple
>> (things like "v0 ^ (v0 << 25)" or "((z2 & 0x00020000) != 0) ? (z2Prime
^
>> 0xb729fcec) : z2Prime"). Inlining this is common sense.
> Agree.
>>
>>>>
>>>> Perhaps I should give a go to still other optimizations just to make
>>>> more clear our code is really different ?
>>> I'm not sure what you mean?
>>
>> Some ways to optimize further could be to process several numbers in raw
>> to benefit from some of the values being already in register rather than
>> putting them in a memory array to read them back just the next iteration
>> (one Well iteration uses 5 values from the bits pool array, two being
>> close together and the three other being spread in the array).
>> Basically, it would be packing two or more iterations in one call and
>> cache the results. Then, when the user asks for 1 million numbers, some
>> calls would result in simply retrieving one value from the cache and
>> only a few calls would mean cherry picking in the array and performing
>> the bits twiddling.
>>
>> They do not use this kind of tricks in their implementation. By using
>> them in ours, it would make more clear our code is really an original
>> one and not derived from their GPL code.
> It sounds reasonable, but I'm thinking that it might be better to add
> the current code, and then optimise it further afterwards? As I see
> it, that would provide some advantages (e.g. testing, performance etc.
> for everybody).

+1

Also, it would help future maintenance if the optimisations were
documented as comments in the code (rather than being buried in SVN
history).

> Mikkel.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message