Activity for Warren D. Smith
-
Warren D. Smith posted a comment on discussion Open Discussion
thanks for the edits. I was actually amazed how fast Xoro256() was, only 4 clock cycles, despite appearing to the naked eye to employ at least 14 operations. (In particular it was the same or faster than sfc64 on my system.) This I presume is due to a lot (indeed, more than I would have thought possible) of instruction level parallelism. It might be that is special to my machine & compiler (other machines & compilers will make it super slow?) - I have no idea. Phenomena like this leave me basically...
-
Warning: this stupid sourceforge netpost gizmo is editing what I post to mess it up. I think it is pretty obvious what I actually said, but it posts things different from what I say.
-
Another generator (use WeylIncrem = U64(7640891563999686221) ): uint64 XoroS[5] = {346, 925, 630, 787, 932}; //state /* This generator has period=(2^256-1)2^64>0.9999992^320 and has 320 bits of state. It uses only +, shifts, XORs, and bswap, i.e. is multiplication-free. XoroS[0..3] are updated GF2-linearly while XoroS[4] is a Weyl generator. The output is scrambled using both word-addition, bswap, and variable-distance rotation to obliterate GF2-linear relations. The Weyl component should obliterate...
-
/* Several 64-bit random-word generators by Warren D. Smith 2019. Compile with gcc -Wall -O3 -DNDEBUG */ include <stdio.h></stdio.h> include <assert.h></assert.h> include <inttypes.h></inttypes.h> define uint unsigned int define uint128 __uint128_t define uint64 uint64_t define uint32 uint32_t define uint16 uint16_t define uint8 uint8_t define XOR ^ define U64(y) UINT64_C(y) //allows long constants like U64(0x12345678abcdef0) without overflow //Also available: INT8_C, INT16_C, INT32_C, INT64_C, signed...
-
Oh, the left shift (x<<L)+x, or (x<<L)-x, I do not care which you use; I thought perhaps the minus verson might be a teeny bit more random, but it did not occur to me the plus version has the advantage it can be compiled with an "LEA" instruction. That seems a good enough reason to stick with plus.
-
hmm, actually if we alter the internal logic of sfc64 further to maximally-use the "alternate + and xor" principle, we get (what probably is the best yet; the state is {a,b,c,w}): uint64 WDSrand64(){ uint64 tmp = (b + w) ^ a; a = (b << LSHIFT) - b; b = c ^ (c >> RSHIFT); w += INCREM; c = ((c << BARREL) | (c >> (64-BARREL))) + tmp; return( tmp ); } where INCREM = UINT64_C(7640891575674082921) is suggested, and I have no idea what the best values for LSHIFT, RSHIFT, and BARREL now should be. INCREM...
-
Agggh! it seems plausible the "a + b + counter" would improve if replaced by "(a + counter) ^ a". I meant "(a + counter) ^ b".
-
Also, in Uint64 tmp = a + b + counter++; a = b ^ (b >> RSHIFT); b = c + (c << LSHIFT); it seems plausible the "a + b + counter" would improve if replaced by "(a + counter) ^ a". Again, same speed, but more presumed randomness because if usage of + and ^ are systematically alternated, then you get rid of associativity, get more nonlinearity, etc. My suggestions are not huge improvements, but seems obvious (to me anyhow) they are improvements; and if you want to be empirical about it, it might be detectable...
-
1.Hi, there is an obvious-seeming criticism of (& response improving) your sfc64 routine for creating a 64-bit psu-random. enum {BARREL_SHIFT = 24, RSHIFT = 11, LSHIFT = 3}; Uint64 tmp = a + b + counter++; a = b ^ (b >> RSHIFT); b = c + (c << LSHIFT); c = ((c << BARREL_SHIFT) | (c >> (64-BARREL_SHIFT))) + tmp; return tmp; The "counter++" could be replaced by "(counter+=UINT64_C(7640891575674082921))" which presumably is the same speed but more randomness. Any odd increment could be used. You chose...
1