asciilifeform: this allows 'P' to be a constant-spacetime operation, and hands the decision of 'just how important to constant-time the whole prime generation' to the author of the tape.
asciilifeform: presently looping is prohibited in pcode, in later ch. will be introduced. (but i am spoiling things..)
asciilifeform: ( in each invocation, P returns 1 if m-r didn't 'go bang' and a 0 if did. )
asciilifeform: per the ffa plan, 'P' command will take two numbers from the stack, a candidate integer and a witness. author of pcode tape determines how many witnesses to use, he iterates by generating witnesses and calling P repeatedly as many times as he wants
asciilifeform: take for example diana_coman's system , where 16 witnesses are used. ( i'd use moar, but let's go with the example. ) so if we're generating 2048b primes (for 4096b rsa mod), per ch.14b timings on asciilifeform's iron this costs ~2.9s per modexp, and thereby ~93sec per m-r procedure.
asciilifeform: this means that the use of gcd litmus very muchly wins.
asciilifeform: btw per asciilifeform's chalkboard, the physical cost of constanttime m-r is ~equal to that of (2 modexps of the given width) x (number of witnesses) .☟︎
asciilifeform: would still be handy if someone knew of a smaller bound for s, but not burning q.☟︎
asciilifeform: hrm , asciilifeform's 'wtf' to this was based on a backwards reading of his chalkboard. modsquares are fast.
asciilifeform: which means ugh, for e.g. 2048bit candidate being tested for primality in constant time, ~each~ witness needs 1 modexp and 2047 modsquares !
asciilifeform: cuz without a bound, s is potentially ffawidth - 1 .
asciilifeform: ... or i suppose if yer still stumped next friday night, then.
asciilifeform: diana_coman: if you're utterly stumped, i can allocate some cycles to the problem tomorrow -- with mircea_popescu's permission ( i swore to him that i will not embroil meself in matters euloric , recall )☟︎
asciilifeform: diana_coman: what i meant was, my proggy has no elaborator, and yours -- has, so i am not qualified to say 'here's how to fix elaborator in static lib' of yet.
asciilifeform: but i cannot yet say conclusively. diana_coman is at the bleeding edge of this q.
asciilifeform: last time i touched the subj with own hands, i concluded that elaborator isn't even permitted in static ada lib.
asciilifeform: diana_coman: if your 'main' is a c/cpp proggy , you gotta trigger the elaborator 'by hand', regardless of which type of lib your ada coad is in, afaik.
asciilifeform: diana_coman: iirc gcd(0,0) is permitted in your sys also
asciilifeform: it is also clearly stated in the proggy comments.
asciilifeform: correct. hence why i decided subj is worth touching in the piece & in the l0gz.
asciilifeform: ( tho it grates on me that i never found any coherent discussion of subj anywhere, yet )
asciilifeform: possibly this is why it was traditionally permitted.
asciilifeform: in situation where cpu cost matters greatly, testing 1 register (output of gcd) for nullity is cheaper than testing two (its args)
asciilifeform: ( and observe that all instances where we divide, we're doomed to check for 0 regardless )
asciilifeform: imho arg can be made for it being the gcd-invoker's responsibility to know what to do with the output☟︎
asciilifeform: i sat down last night and tried to conceive a 'div0'-style situation where you 'bought own cross' as result of permitting gcd(0,0) to execute. but did not find one.
asciilifeform: ^ mircea_popescu , diana_coman , et al ^
asciilifeform: but evidently moar needed than i prev. thought
asciilifeform: pretty sure i mentioned it in the l0gz, it is old idea
asciilifeform: ( recall that ffa dun use memory allocators , disk, etc )
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: 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: errywhere else there's a massive noise component
asciilifeform: sorta 90% of the reason i want a dos gnat
asciilifeform: the ultimate tester would be a dos box
asciilifeform: thing is, this effect does not appear with e..g modexp, so i gotta find out where it comes from
asciilifeform: involved (i.e. interaction with other crapola running on the box) to produce random variance
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: 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 let it go on 2 diff opterons and 2 intels
asciilifeform found the shift booby by generating ridiculously long random inputs, with variety of hamming weight ranges, and plain old wallclock
asciilifeform: this appears to be the kind of boobytrap that can only be found empirically.
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 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: 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: if you never fiddled with the layout, why shouldn't it work
asciilifeform: ( aand on top of that, is victim of the faux-standardization pestilential in unixland )
asciilifeform: in the past asciilifeform used ordinary gnumake for this kinda thing. but it usually resulted in 1000ln 'make'.
asciilifeform: if mircea_popescu says -- i'll believe
asciilifeform: mircea_popescu: does it work in that 'it worx, and 7 others previously barfed' or 'it was 1st i happened to try and it seems to work' ?
asciilifeform: there's 9000 of these, 'cmake', 'bake', 'qtmake', etc
asciilifeform: mircea_popescu: i read the link from earlier, made sense
asciilifeform: ( perhaps can assume either that Mocky could not stomach it, or charged toomuch )
asciilifeform: there are so many and I'm only one << i admit that i'm a little curious why diana_coman & mircea_popescu dun enlist Mocky to carry on client dev -- but it's not my biz , if they dun feel like going into subj, i won't cry
asciilifeform: i find it interesting just how many half-working substitutes for gnumake folx have written
asciilifeform: 'Jam runs on UNIX, VMS, NT, OS/2, Mac OS X, and Mac MPW' << if troo, notbad at least in re portability
asciilifeform: btw it is possible to build cpp with gnatmake, believe or not ( i only tried for simplest case, but does work )
