On 21 September 2010 09:40, Mikkel Meyer Andersen <m...@mikl.dk> wrote: > 2010/9/21 Luc Maisonobe <luc.maison...@free.fr>: >> Le 21/09/2010 10:08, Mikkel Meyer Andersen a écrit : >>> 2010/9/21 Luc Maisonobe <luc.maison...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org