asciilifeform: in other noose, asciilifeform made the unhappy discovery that shift-by-zero takes fewer cpu cycles on pretty much all x86 iron vs shift-by-1 .

asciilifeform: this means not only slightly slower gcd than the draft posted earlier (it'll need a mux) but it also means that e.g. http://www.loper-os.org/pub/ffa/hypertext/ch14/fz_qshft__adb.htm#111_14 was in fact leaking, albeit undetectable on the tests given in ch14, and will need mandatory HaveBarrelShifter = 0 (i.e. 5% or so penalty)

asciilifeform: ( and before anyone asks -- neither intel nor amd publish 'tick tables' the way they did in 1990s, and haven't for many yrs )

asciilifeform: this appears to be the kind of boobytrap that can only be found empirically.

asciilifeform found the shift booby by generating ridiculously long random inputs, with variety of hamming weight ranges, and plain old wallclock

asciilifeform set up an experiment with variants of http://p.bvulpes.com/pastes/RMcd3/?raw=true ; will report re same tomorrow

asciilifeform let it go on 2 diff opterons and 2 intels

asciilifeform: hm , prolly oughta test both left and right, and make the operand nonzero (in case the iron does 'clever' with zeros), so gotta redo.. ☟︎

asciilifeform: http://p.bvulpes.com/pastes/7zNhD/?raw=true << the final ver., for the record.

asciilifeform: mircea_popescu: hm what made you remember that d00d existed ?

asciilifeform: http://btcbase.org/log/2019-01-10#1886234 << update : the 1e11-shot ver. reveals no significant avg. delta; rerunning overnight with 1e12. ☝︎

asciilifeform: btw the thing that set asciilifeform's ears standing originally, is that the gcd test battery appeared to give +/- 30% variant runtimes depending on hamming weights. but in 20 repeats of the trial set, the same thing showed up, and with no correlation to hamming weight. and a http://p.bvulpes.com/pastes/wherN/?raw=true ( soft barrelshifter ) version now ends up showing... same thing. i suspect that some peculiarity of the pipeline is

asciilifeform: involved (i.e. interaction with other crapola running on the box) to produce random variance

asciilifeform: thing is, this effect does not appear with e..g modexp, so i gotta find out where it comes from

asciilifeform bbl,meat

asciilifeform: meanwhile, anticlimactic finish to last night's item -- no detectable pattern in shift timing, anywhere

asciilifeform: and the orig. anomaly disappears on irons other than the test box

asciilifeform: i suspect my hdd

asciilifeform: (the test inputs are ~100MB ea.)

asciilifeform: aaand to round off : it vanished on the test box also. culprit appears to have been a running raid-verify job... ☟︎☟︎

asciilifeform: ikr?

asciilifeform: the ultimate tester would be a dos box

asciilifeform: sorta 90% of the reason i want a dos gnat

asciilifeform: errywhere else there's a massive noise component

asciilifeform: some time after i get ffa to field testing , i'ma dust off ave1's bare iron gnat and bake 'ffa os', will be ~same thing

asciilifeform: ( it dun use any osisms other than the cmdline args, which can be hardcoded for test runs; as for i/o, can be rs232, and guesswat, 'os' )

asciilifeform: ( recall that ffa dun use memory allocators , disk, etc )

asciilifeform: pretty sure i mentioned it in the l0gz, it is old idea

asciilifeform: but evidently moar needed than i prev. thought

asciilifeform: ^ mircea_popescu , diana_coman , et al ^

asciilifeform: phf plox to snarf ch15.

asciilifeform: next ch, will be m-r.