log
600+ entries in 0.064s
asciilifeform: trinque: see ffa as example
asciilifeform: diana_coman: he said 'threading model' so i assumed he found some ffa-style fascistic constraint to put on it, lol
shinohai: Not bad, just noticed last nite ave1's site back up so in process of building musl gnat today then on to revisiting ffa stuffs
mod6: I'm even spending a few spare cycles on FFA chapter 1.
asciilifeform: meanwhile, http://btcbase.org/patches/ffa_ch16_miller_rabin.kv << ty phf !
diana_coman: yay, m-r on ffa; now I'll really have to schedule ffa feast during breaks from work, lol
phf: i don't understand how anyone can read the logs with one eye, this shit's exponential: i'm behind on ffa, so the recent work on e.g. gcd or miller-rabin is particularly slow going.
asciilifeform: in so far as anyone can tell, it's troo, and then 64bit witnesses suffice for 4096bit candidates. but not only relies on riemann, but dun win anyffin in ffa, where very small and very large number eat same cpu.
asciilifeform: btw, imho it's a good example of 'ffa-style' narrowing of problem domain ( there is no good reason for ancient tx to be rewritable )
asciilifeform: ( alert reader will notice, it is based on http://www.loper-os.org/pub/ffa/hypertext/ch15/fz_measr__adb.htm#29_13 )
asciilifeform: may recall, 1st draft of ffa used genericism, i removed it
asciilifeform: note that mmap is not a front burner item currently for asciilifeform - i dun need it in ffa, will come back to it after.
a111: Logged on 2018-11-16 23:13 asciilifeform: it is on hold pending resolution of http://btcbase.org/log/2018-10-26#1866266 ( and is taking back seat to ffa currently )
asciilifeform: http://btcbase.org/log/2019-01-22#1889099 << i daren't to 'do something about it' until properly understood the problem. sorta like didnt dare to attempt trb in 2013, or ffa in 2015, etc ☝︎
asciilifeform: bvt: even the current (ch11 and after) ffa relies on a gnat with working forced-inlining
asciilifeform: granted, an unrolled ffa would operate on a fixed width (e.g. 8192) of primary fz.
bvt: i guess i could do some experiments here. the immediate question is that ffa does plenty of FZ_Adds with different FZ'Length, so full unrolling would not really work (unless i miss something).
asciilifeform: koch's turd, despite being implemented in c, with no bounds checks, actually loses to ch14 ffa , for inputs of same ~width~ -- despite fact that he doesn't constanttime and thereby gets to skip massive work
asciilifeform: bvt: i expect one would trivially get a 10-20x speedup over the ordinary ffa, esp. if the item still fits in l1
asciilifeform: before considering to bake irons, it is worth to see what a 100%-asmic ffa would give.
asciilifeform: nao, it isn't as if the current ffa, with 2.7sec 4096-bit modexp, is immediately usable to eat packets at line rate. but that part at least theoretically parallelizes ( i.e. a rack fulla multicore boxen running ffa, can theoretically eat packets at line rate... )
asciilifeform: helps to recall that the problem which originally prompted asciilifeform to write ffa, is a (currently hypothetical) application where rsa sigs are carried in ~individual packets~
asciilifeform: ftr i suspect that entirely ordinary algos, such as are seen in the current ffa, would already give ~line-rate~ (i.e. , 4096 modexp faster than 1G/s nic can give you new inputs to modexp on ) if implemented in iron properly.
asciilifeform: ( '1st commandment' of ffa : thou shalt not branch on seekrit bits. '2nd commandment' -- thou shalt not index memory by seekrit bits ... )
a111: Logged on 2019-01-20 16:23 asciilifeform: as i noted previously -- i do not expect to find any moar ~asymptotic~ speedups for ffa algos , such that are relevant to the sizes of numbers typically used in public key crypto
asciilifeform: 1 annoying aspect of 'iron ffa'-gedankenexperiment, is that none of the available fpga ( either 'ice40' series, or the evil ones ) are anywhere near big enuff to prototype with. it'd have to be simulated a la http://www.loper-os.org/?p=2593 , slowly, and then straight to silicon.
asciilifeform: in a hypothetical asmistic branch of ffa, you'd want to implement whole comba in asm, rather than merely word mul
bvt: my understanding is that asmism would go only for lower-level ffa code, i.e. barret/modexp will remain as-is.
asciilifeform: http://www.loper-os.org/pub/ffa/hypertext/ch15/w_mul__adb.htm#95_14 << specifically here, currently we do 4 MUL instrs for where really needs only 1
asciilifeform: as i noted previously -- i do not expect to find any moar ~asymptotic~ speedups for ffa algos , such that are relevant to the sizes of numbers typically used in public key crypto
asciilifeform: bvt: there's a long list of things that asciilifeform considered and (for time being) rejected from ffa, on acct of costing substantial complexity for very small saving of cpu cost. e.g. unrolled comba.
asciilifeform: http://btcbase.org/log/2019-01-20#1888467 << gotta nitpick here: it aint allocations (which in ffa planet are always done by stack frame, in O(1) ) that leads to slow, but cache eviction ( as well as linear overhead from doing moar ops in general ) ☝︎
asciilifeform: ( not particularly useful for ffa, but potentially elsewhere.. )
bvt: http://bvt-trace.net/vpatches/ffa_ch4_ffacalc.kv.vpatch.bvt.sig http://bvt-trace.net/vpatches/ffa_ch5_egypt.kv.vpatch.bvt.sig http://bvt-trace.net/vpatches/ffa_ch6_simplest_rsa.kv.vpatch.bvt.sig
bvt: asciilifeform: http://bvt-trace.net/vpatches/ffa_ch1_genesis.kv.vpatch.bvt.sig http://bvt-trace.net/vpatches/ffa_ch2_logicals.kv.vpatch.bvt.sig http://bvt-trace.net/vpatches/ffa_ch3_shifts.kv.vpatch.bvt.sig
mircea_popescu: not ffa ; the "lfence" bs i mean.
asciilifeform takes the occasion to observe that ffa is 'speculation'-proof, not only in theory but as empirically tested on 7 ( & counting ) intel boxen of various vintages
mod6: Would be awesome if Pizzaro could sell iron that can run cuntoo + ffa + fg + trb out of the gate [ + others too, i.e. eulora, etc ]
asciilifeform: mircea_popescu: after ffa is fielded, i'ma add gmp etc carmichaelisms to phuctor.
asciilifeform: re verifications, observe the general pattern in ffaism: i expect any serious user to have a private battery of tests to verify that his, particular, ffa builds, actually conform to the declared behaviours.
a111: Logged on 2019-01-14 02:37 mircea_popescu: in other news, ffa chapters are such a pleasure. it seems to me by now ffa has become such a largest-rock in the loperos garden...
mircea_popescu: in other news, ffa chapters are such a pleasure. it seems to me by now ffa has become such a largest-rock in the loperos garden...
asciilifeform: meanwhile, in other lulz, http://koclab.org/ffa.html
diana_coman: http://btcbase.org/log/2019-01-11#1886349 -> better spent on ffa, surely; thanks for the offer anyway though! ☝︎
asciilifeform: a 'graduate' of ffa (i.e. fella who ~read~ the thing, as it was intended to be read, and fit-in-head) will have no trouble writing his particular variant of correct prime generator for his particular type of key.
asciilifeform: the only 'magic number' in ffa is the concession that all FZ must be at least 256bits long
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: ( recall that ffa dun use memory allocators , disk, etc )
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: 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 actually considered a fortran ffa, in '16
asciilifeform: ( observe that ch1 ffa actually starts out by http://www.loper-os.org/?p=1913#selection-337.0-1150.0 , i.e. banning 90% of ada.. why didja suppose this was. )
asciilifeform: ( observe, the only 'access pointer' in ffa is where it sucks in cmdline args from unix )
asciilifeform: mod6: at the risk of sounding like mircea_popescu in earlier thread -- why is this a mega-project ? i reground ffa to keccak in about 10minute (after getting hold of a working keccak-vtron)
asciilifeform: for comparison, ada sores of ch14 ffa, incl. comments, weighs ~300kB
asciilifeform: http://btcbase.org/log/2019-01-06#1885042 << this'll be handy when i get to asmized variant of inner muls in ffa. looking forward to reading ave1's piece. ☝︎
a111: Logged on 2019-01-05 16:40 asciilifeform: http://btcbase.org/log/2019-01-05#1884626 << i suspect phf is hunting elk in kamchatka, or similar , atm ( i.e. still waiting for http://btcbase.org/patches?patchset=ffa refresh , so i dun think he's been at console much recently )
mircea_popescu: anyway, nothing wrong with that ffa design choice, if you like it ; if you don't anymore, also not the end of world.
a111: Logged on 2019-01-06 00:08 mircea_popescu: nobody is going to hate your ffa if it includes montgomery, with the proper warning.
mircea_popescu: nobody is going to hate your ffa if it includes montgomery, with the proper warning.
asciilifeform: to round out the 'loose ends' thread -- asciilifeform also has a ~90% built node-walker and www front end for same. but it is in refrigerator, no one is direly starving for the lack of the thing, i expect i'll come back and finish it off strictly after ffa is fielded .
asciilifeform: hopefully he comes back soonish ( i'ma not even pester him re bolix, bolix is asciilifeform's personal war, learned not to expect help from anyone, and currently in refrigerator, i dun expect to spend much time on it while ffa undone )
asciilifeform: http://btcbase.org/log/2019-01-05#1884626 << i suspect phf is hunting elk in kamchatka, or similar , atm ( i.e. still waiting for http://btcbase.org/patches?patchset=ffa refresh , so i dun think he's been at console much recently ) ☝︎
asciilifeform: ( already hats off to ave1 , who did year+ of gnat cleanup that asciilifeform was solidly convinced he'd have to do with own hands; and the fixed inlining gave us a ~2x ffa speedup 'for phree' ! )
asciilifeform: also at some point it'd be great to have a mips gnat, so i can plant ffa on pocket-sized irons. but that's for muchlaters.
asciilifeform: ffa is designed to be used via pcode (aka 'peh') but i'm not about to tell folx that they absolutely must. given the stated reqs (you gotta test for div0ism, we dun do it internally given as it's thermonuke performance) it can be safely used directly.
asciilifeform: diana_coman: btw it is perfectly ok also to simply invoke the knobs exported in ffa.ads directly, but then you gotta take care of 1) endianism of the words being put in and gotten out , to match yours 2) testing for div0 , as done in http://www.loper-os.org/pub/ffa/hypertext/ch14/ffa_calc__adb.htm
diana_coman: asciilifeform, first I do need to finish getting the ffa in, so that will still take quite a while; other than that, it's more a matter of "as time permits" and as mircea_popescu says it's not top priority; that being said yes, I'd like to do it and see some timings and comparison for myself
asciilifeform: i'd expect that it would cost 1 or 2 diana_coman-days to glue ch14 ffa to euloratron, to see how performs using diana_coman's existing m-r etc.
diana_coman: asciilifeform, sometimes I wonder what exactly do you think you need/don't have to move to Romania or wherever else you consider it to be "paradise, can now do just ffa/trb/..."
diana_coman: asciilifeform, re m-r: I implemented it using mpi as per http://ossasepia.com/2017/12/28/eucrypt-chapter-3-miller-rabin-implementation/ ; ofc I'd rather use ffa ct-time implementation but it's not a sticking point per se i.e. I can switch my implementation from relying on mpi to relying on ffa, no?
asciilifeform: ( i.e. one would have to put in mircea_popescu's specced exponent bitness where 'Bitness' is in http://www.loper-os.org/pub/ffa/hypertext/ch14/fz_modex__adb.htm#85_14 , to get the speedup )
diana_coman: asciilifeform, thing is: from eucrypt and eulora pov, mpi is used for "big num arithmetics" only so I CAN in fact switch to ffa even without ct-time miller-rabin esp if ffa turns out to be...faster than mpi
diana_coman: and yes, I'm eating up ffa with an eye on "maybe I can finally get rid of MPI!!"
asciilifeform: the 1 application where ffa defo dunwork, and koch -- does, is phuctor.
mircea_popescu: esp because correctly written, with tests etc. so can meaningfully do ffa-eucrypt vs mpi-eucrypt as a benchmark.
mircea_popescu: right. a mpi-eucrypt vs ffa-eucrypt head-on will be interesting to see.
asciilifeform: it needs an entirely other item ( which can be sewn from ffa parts, but has not been of yet )
a111: Logged on 2018-11-16 23:13 asciilifeform: it is on hold pending resolution of http://btcbase.org/log/2018-10-26#1866266 ( and is taking back seat to ffa currently )
asciilifeform: same thing as in e.g. http://www.loper-os.org/pub/ffa/hypertext/ch14/fz_mul__adb.htm#164_7 .
asciilifeform trimmed iron stash down to 2 'alphas', 1 runs barbaric 'tru64' (for that bolix emulator), 1 nao set up for 'ffa on arch that aint x64 or arm' tests laters
asciilifeform: as i've said previously, ffa post-ch6 is largely an 'uglification' to buy usable performance on pc.
diana_coman: if nitpick at all, the one thing that consistently nags at me (though for which I can't make up my mind as to actual solution) is the implicit reliance on indices to be in fact starting from 1 when copying stuff e.g. http://btcbase.org/patches/ffa_ch7_turbo_egyptians.kv#L187
asciilifeform: ftr i very much appreciate all nitpicks, even purely stylistic ones, an explicit objective of ffa is to be not only bug-free but entirely clean of sharp edges, to the extent possible on the available irons.
diana_coman: asciilifeform, phf updated with my sigs for FFA ch7 and ch8: http://ossasepia.com/reference-code-shelf/#selection-627.0-665.43
diana_coman: asciilifeform, you broke all your links on your www to FFA code on btcbase when you changed the name of vpatches because of keccak vs sha: e.g. btcbase.org/patches/ffa_ch7_turbo_egyptians/tree/ffa/ffacalc/cmdline.ads#L42 in Ch8 404s now because no ".kv"
asciilifeform: thus far i've found that ffa speed is almost exact function of cpu clock (for given bitness of cpu)
diana_coman: that's precisely why the slow pace - I need a bit of fresher mind to get back and read through the rest of ffa
a111: Logged on 2017-10-08 00:20 asciilifeform: http://btcbase.org/log/2017-10-07#1722411 << 1 ) ffa is closed form. i.e. it CAN be written as a number of nand gates, with a 'funnel' at the top, to which you present a,b,c, e.g. 4096bit, numbers, and at the bottom in a little cup you get a^b mod c , and with NO UPWARDS FEEDBACK FLOW of information , i.e. answer comes after same interval of time always, and with strictly downwards signals.
feedbot: http://qntra.net/2018/12/stanislav-datskovskiy-publishes-fully-constant-time-code-for-barretts-modular-reduction-as-part-of-ffa-library/ << Qntra -- Stanislav Datskovskiy Publishes Fully Constant Time Code For Barrett's Modular Reduction As Part Of FFA Library
pehbot: asciilifeform: FFA Ver: 00000000000000000000000000000000000000000000000000000000000000FF
asciilifeform: !A V[FFA Ver: ]#
asciilifeform: mircea_popescu: if someone knows how to make ffa moar 'docs is the program'-y, oughta write in and tell asciilifeform , cuz i came as close to it as i knew how.
asciilifeform: mircea_popescu: phunphakt, since last night , massive uptick in heathens visiting ffa www, even curl'ing patches. but so far none have the balls to speak up.
asciilifeform: ( and incidentally if you disable the bounds checks, having been satisfied with the proofs, ffa speeds up by another 2x 'for phree' )
asciilifeform: but i expect ffa-cum-asmism will still beat shit out of koch-cum-asmism
asciilifeform: incidentally, it's a 'fair fight', i.e. both ch14 ffa and mpi-koch lack asmism
a111: Logged on 2018-11-16 23:13 asciilifeform: it is on hold pending resolution of http://btcbase.org/log/2018-10-26#1866266 ( and is taking back seat to ffa currently )
a111: Logged on 2018-12-22 17:25 diana_coman: asciilifeform, phf I've signed and mirrored ch6 of ffa: http://ossasepia.com/reference-code-shelf/#selection-603.0-617.46
asciilifeform: http://btcbase.org/log/2018-12-24#1882931 << fwliw i have a 90+% written node-and-tx-hunter with wwwistic frontend etc. but it is currently on shelf, taking back seat to ffa ☝︎