500+ entries in 0.065s
: 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.
: 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 )
: may recall, 1st draft of ffa
used genericism, i removed it
: note that mmap is not a front burner item currently for asciilifeform - i dun need it in ffa
, will come back to it after.
: bvt: even the current (ch11 and after) ffa
relies on a gnat with working forced-inlining
: granted, an unrolled ffa
would operate on a fixed width (e.g. 8192) of primary fz.
: 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).
: 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
: bvt: i expect one would trivially get a 10-20x speedup over the ordinary ffa
, esp. if the item still fits in l1
: before considering to bake irons, it is worth to see what a 100%-asmic ffa
: 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... )
: 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~
: 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.
: ( '1st commandment' of ffa
: thou shalt not branch on seekrit bits. '2nd commandment' -- thou shalt not index memory by seekrit bits ... )
: 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
: 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.
: in a hypothetical asmistic branch of ffa
, you'd want to implement whole comba in asm, rather than merely word mul
: my understanding is that asmism would go only for lower-level ffa
code, i.e. barret/modexp will remain as-is.
: 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 ☟
: 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.
: ( not particularly useful for ffa
, but potentially elsewhere.. )
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
: 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 ]
: mircea_popescu: after ffa
is fielded, i'ma add gmp etc carmichaelisms to phuctor.
: 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.
: 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...
: 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... ☟
: 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.
: the only 'magic number' in ffa
is the concession that all FZ must be at least 256bits long
: 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
: ( recall that ffa
dun use memory allocators , disk, etc )
: 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
: ( observe, the only 'access pointer' in ffa
is where it sucks in cmdline args from unix )
: 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)
: for comparison, ada sores of ch14 ffa
, incl. comments, weighs ~300kB
: anyway, nothing wrong with that ffa
design choice, if you like it ; if you don't anymore, also not the end of world.
: Logged on 2019-01-06 00:08 mircea_popescu: nobody is going to hate your ffa
if it includes montgomery, with the proper warning.
: nobody is going to hate your ffa
if it includes montgomery, with the proper warning. ☟
: 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 .
: 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
: ( 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' ! )
: 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.
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, 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
: 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.
: 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
: 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
: and yes, I'm eating up ffa
with an eye on "maybe I can finally get rid of MPI!!"
: the 1 application where ffa
defo dunwork, and koch -- does, is phuctor.
: esp because correctly written, with tests etc. so can meaningfully do ffa
-eucrypt vs mpi-eucrypt as a benchmark.
: right. a mpi-eucrypt vs ffa
-eucrypt head-on will be interesting to see.
: it needs an entirely other item ( which can be sewn from ffa
parts, but has not been of yet )
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
: as i've said previously, ffa
post-ch6 is largely an 'uglification' to buy usable performance on pc.
: 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.
: 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"
: thus far i've found that ffa
speed is almost exact function of cpu clock (for given bitness of cpu)
: that's precisely why the slow pace - I need a bit of fresher mind to get back and read through the rest of ffa
: 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.
: asciilifeform: FFA
: 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.
: 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.
: ( and incidentally if you disable the bounds checks, having been satisfied with the proofs, ffa
speeds up by another 2x 'for phree' )
: but i expect ffa
-cum-asmism will still beat shit out of koch-cum-asmism
: incidentally, it's a 'fair fight', i.e. both ch14 ffa
and mpi-koch lack asmism
is impressed with asciilifeform's lolcat skillz in latest ffa
: 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 )
: 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.)
: 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.) ☟
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