Was forumating a crbug; and realized I was using Node. I'm doing the console.log with node.... when I grab the code and run it in a webpage it doesn't suffer the same slowdown.
On Fri, Apr 6, 2018 at 3:13 PM, J Decker <d3c...@gmail.com> wrote: > Sorry got busy with other things. > > This gist is fast. > https://gist.github.com/d3x0r/be849400be3ea30877568e5656a86ca3 > how to slow down. > > (line 1) > function pcg_setseq_128_srandom_r() > { > //const state = new Uint32Array([0,0,0,0,0,0,0,0]); > const state = [0,0,0,0,0,0,0,0]; > > uncomment the first line to use uInt32array and comment the second const > state line . (use typed array instead of array). > > (On my system it reports Done in 2045 /ms 48899.75550122249 > 1564792.1760391197) as is , with a standard array. > If it runs more than 4 seconds I end it... because it will be 15-20 > seconds . (Done in 22615 /ms 4421.843908910016 141499.0050851205) > > With the following mentioned speedups Uint32array IS faster.... > The first thing, replace the state with Uint32array, if fast reports (Done > in 1530 /ms 65359.47712418301 2091503.2679738563 ) > > ---------- > Okay? Is that reproducable? > > > > How to speed up. > 1) remove the console.log( testRng ); on line 46. (it's done before the > loop, no the logging itself is not measured in the speed) > or 2) comment out state: new Uint32Array([0,0,0,0,0,0,0,0]), on line > 10. This is a Uint32Array that is put into the RNG object returned; and > if console.log doesn't log a uint32array type it's fast. > 3) > > > > On Friday, April 6, 2018 at 2:28:40 AM UTC-7, Jakob Gruber wrote: >> >> If you do end up with a good repro for the performance difference between >> typed arrays and arrays, please post it at crbug.com/v8/new. >> >> On Fri, Apr 6, 2018 at 8:33 AM, <mog...@syntheticsemantics.com> wrote: >> >>> Are you able to hoist the memory allocations out of the library so the >>> caller can allocate the buffers it needs and reuse them from call to call? >>> new in JS has GC overhead not present in C++ alloc/free. Aside from >>> those variables, the rest are stack allocations and GC won't play much role. >>> >>> -J >>> >>> >>> On Wednesday, April 4, 2018 at 7:03:05 PM UTC-7, J Decker wrote: >>>> >>>> How long of a story to tell(?)... >>>> >>>> I have this procedural random generator, that uses the result of sha2 >>>> as a stream of bits, regenerating another sha2 hash when the 256 bits are >>>> all consumed. I started to use this for perlin noise generation, and >>>> thought I found sha2 was the culprit consuming most of the time. Since I'm >>>> making something just generally random, I went looking for alternative, >>>> lightweight, RNGs. After digging for a while I stumbled on PCG ( >>>> http://www.pcg-random.org/using-pcg.html) It's basically a header-only >>>> library because it attempts to generate everything as inline... >>>> >>>> I made this JS port of it https://gist.github.com/d3 >>>> x0r/345b256be6569c0086c328a8d1b4be01 >>>> This is the first revision ... https://gist.github.com/d3 >>>> x0r/345b256be6569c0086c328a8d1b4be01/fffa8e906d5723e66f7e9ba >>>> a950b3b3d5b4895c7 >>>> It has a better flow matching what the C code does closer... the >>>> current version is fast generating 115k bits per millisecond (vs the 9.3k >>>> bpms of sha2); however, when compared to the C version, which generates >>>> 1.1Mbps it's a factor of 10 off... and the routine is generally only doing >>>> 64 bit integer math (though the test was compiled in 32 bit mode so it was >>>> really just 32 bit registers emulating 64 bit). >>>> >>>> if I just change the arrays created in getState() (first function), to >>>> Uint32Array() it runs MUCH slower... >>>> >>>> ---- >>>> As I write this I was updating some, and some of my numbers from before >>>> are a factor of 8 off because I was counting bytes not bits; except in the >>>> sha2, which is really slow... But I would like to take this opportunity to >>>> say... >>>> >>>> crypto.subtle.digest("SHA-256", buffer).then(hash=>hash ); >>>> >>>> is the same output type as my javascript version I'm using ( forked >>>> from a fork of forge library and consolidated to just the one return >>>> type...), but is another 10x slower than my javascript sha-256. >>>> >>>> I keep thinking 'Oh I'll just compile this and even use intel >>>> accelearted sha2msg1 and sha2msg2 instructions to make the C version 8x >>>> faster than it is in C straight, which itself was already faster than the >>>> JS version; and hook it into a ... ( oh wait I want to do this on a >>>> webpage! can't say Node addon there...). >>>> >>>> Well... back to optimizing. >>>> ---- >>>> >>>> I was working also on a simple test case to show where using a simple >>>> array vs a typed array causes a speed difference, but it's not immediately >>>> obvious what I'm doing that's causing it to deoptimize.... so I'll work on >>>> building that up until it breaks; or conversely strip the other until it >>>> speeds up.. >>>> >>>> https://github.com/d3x0r/-/blob/master/org.d3x0r.common/salt >>>> y_random_generator.js#L86 This is getting the bits from a typed >>>> array; and it's really not that complex (especially if only getting 1 bit >>>> at a time which is what I was last speed testing with; but turns out all >>>> the time is really here, swapping out sha2 for pcg(without typed arrays) >>>> dropped that from 150ms to 50ms but the remaining was still 3500ms... so I >>>> misread the initial performance graph I guess... >>>> >>>> There's a stack of what were C macros to make the whole thing more >>>> readable... https://github.com/d3x0r/-/blob/master/org.d3x0r >>>> .common/salty_random_generator.js#L25 and if I inline these, there's >>>> no improvement so I guess they're all small to qualify for auto inlining >>>> anyway. The version that's current on github ended up creating a new >>>> uint32array(1) for every result; I moved that out locally so I can use just >>>> a single buffer for that result and it sped up the initialization from >>>> 700ms to 200ms (cumulative times) but there's still like 80% of the time in >>>> the remainder of the getBuffer routine; maybe I need to move things out of >>>> the uint8arrays (data from sha2/pcg) >>>> >>>> >>>> -- > -- > v8-users mailing list > v8-users@googlegroups.com > http://groups.google.com/group/v8-users > --- > You received this message because you are subscribed to the Google Groups > "v8-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to v8-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
