log
700+ entries in 0.07s
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 ☝︎
diana_coman: asciilifeform, phf I've signed and mirrored ch6 of ffa: http://ossasepia.com/reference-code-shelf/#selection-603.0-617.46 ☟︎
diana_coman is impressed with asciilifeform's lolcat skillz in latest ffa proof :D
asciilifeform: it is very easy to produce tests like this, cuz ffa tapes can (elementarily) print ffa tapes. ( this is essential, is how e.g. key genning worx )
a111: Logged on 2018-12-22 00:29 asciilifeform: on proper (i.e. constanttimeistic iron mul) irons, 'uniform' and 'slid' test vectors will give same (to within timer jitter) runtimes when fed to ffa (of either ch13 or ch14 variety.)
asciilifeform: on proper (i.e. constanttimeistic iron mul) irons, 'uniform' and 'slid' test vectors will give same (to within timer jitter) runtimes when fed to ffa (of either ch13 or ch14 variety.) ☟︎
asciilifeform: mircea_popescu: example, http://www.loper-os.org/pub/ffa/modexp_tests/10k_shots_512bit_ffa_slid_rnd.tape
asciilifeform in other noose, generating coupla 10k test vectors for ffa ch14b. theory is great, and 'test can reveal presence of bugs but not absence'(tm)(r), but imho gotta have these
asciilifeform: phf: i aint in particular hurry ( possibly unlike mircea_popescu , who wants to emphasize the imho important larger point ). i won't even have time to properly touch the thing until finished ffa. but plz consider what i suggested today.
asciilifeform: if mircea_popescu or anybody else finds a 'clever' in ffa, plox to ping asciilifeform asap so it can be burned out with hot irons.
asciilifeform: ( user porting ffa to new irons is expected to run the litmus )
asciilifeform: i'm sadly in a pile of saecular shit atm, and on top of that behind sched in ffa. so will be slow.
asciilifeform: ( ffa is not threaded per se, but is thread-safe, dun allocate anyffing other than on stack, i.e. can be used inside a thread safely )
asciilifeform: juliankunkel: as a maths fella, you may also find 'ffa' ( asciilifeform's current item, http://www.loper-os.org/?cat=49 ) interesting, world's only sidechannelism-proof crypto lib, ~80% done
asciilifeform: sometimes abstract work is done by kamikazes who do it from principle, at the expense of sleep and walks in park, the way asciilifeform bakes e.g. ffa. but in general yes , it simply dun happen because nobody pays.
asciilifeform: mircea_popescu: fortunately i dun have any complex subexpressions in exponents anywhere in ffa notebook.
asciilifeform: i refuse to use bitmaps for the matholade in ffa, cuz retarded ( not searchable + looks like shit on 3 out of 4 people's displays no matter what you do )
mircea_popescu: "in the end" ffa is a piece of shit, because events from star date 78987.4
asciilifeform: ( compare vs http://www.loper-os.org/pub/ffa/ch12b_exp_timing.png )
diana_coman: asciilifeform, phf I've signed ch4 and ch5 of ffa: http://ossasepia.com/reference-code-shelf/#selection-555.0-593.39
asciilifeform: ( starting with ch12 all ffa tested strictly on ave1's gnat )
asciilifeform hands 100% full with ffa , presently
asciilifeform: http://btcbase.org/log/2018-12-03#1877916 << to date we've had both types of regrind ( e.g. diana_coman reground 'mpi' into 1 genesis, for use in smg ; ffa on other hand had a 'history-preserving' regrind , http://www.loper-os.org/?p=2743 ; and iirc mod6 is baking a 'history' regrind for trb ; diana_coman had 'history' regrind for eucrypt; and possibly i missed somebody in this list ) ☝︎
asciilifeform: http://btcbase.org/log/2018-11-30#1876362 << i'll admit, i kept half-expecting him to actually read a ch of ffa and go 'hmm... maybe i should throw out my c hairball and mecha-proofisms' but of course no dice. ☝︎
diana_coman: asciilifeform, phf my sig for ffa ch3: http://ossasepia.com/reference-code-shelf/#selection-513.0-513.24
asciilifeform: *ffa
asciilifeform: http://www.loper-os.org/pub/ffa/hypertext/ch13/fz_io__adb.htm#29_14 << subj. presumes existence of 'nibbles'
asciilifeform: btw , q for ffa readership, can anybody think of a way to make the digit slider routine non8bitbyte-clean ? ( beyond having ffa eat its pistol on boot if it finds itself on such machine, lol )
asciilifeform: you can browse whole ch13 at http://www.loper-os.org/pub/ffa/hypertext/ch13/ffa_calc__adb.htm , if lazy