log☇︎
700+ entries in 0.099s
asciilifeform: a linear process can still be heavy enuff (e.g. a 8192-bit primality test on ffa) that you wouldn't want to wait for it to finish when killing a thread
asciilifeform: if you have cppola ( or even, e.g., an asm-enhanced ffa ) in yer loop, it won't be poll-killable.
asciilifeform: ( see e.g. ch15 ffa )
a111: Logged on 2019-02-12 14:13 asciilifeform: http://btcbase.org/log/2019-02-12#1895234 << ffa uses exceptions strictly as 'fucking stop whole program (and if it's running on a micro, whole machine, and flash 'dead!' lamp) right nao!' , so won't impact. my understanding is that it'd impact only speed of the ~exceptions~, longjump is slower cuz it crosses pages -- cachaistically.
asciilifeform: ( and in the FG reader -- again cuz the underlying i/o routines produce'em )
asciilifeform: ( ffacalc ~does~ have a handler, strictly for trapping invalid cmdline args, ln. 75. )
asciilifeform: ( and since nobody asked 'where exactly does ffa use exceptions? i dun see any throws' -- answr is, ~all~ ada coad where bounds checks are enabled, theoretically 'uses' exception, if you break a bounds check what do you suppose happens.)
asciilifeform: ( in ffa, exceptions are a 'catch fire' condition, and drop into the last-chance handler, but in moar complicated proggy, with, say, devices, you may want to actually handle and keep working )
asciilifeform: http://btcbase.org/log/2019-02-12#1895272 << serpent dun have many jumps in it, recall, it's unrolled, even fewer jumps (conditional or otherwise) than ffa ☝︎
asciilifeform: btw this is why i sewed ffa into a linkable lib. ~it~ can still be built with restrictions even if running inside a proggy with tasks etc
a111: Logged on 2019-02-12 13:18 bvt: i expect it will be slower, but it won't hurt to do the check. the impact will depend on how exceptions are used (i don't think it can have any impact on ffa, for example). but i don't have enough experience with it to provide any numbers
asciilifeform: http://btcbase.org/log/2019-02-12#1895234 << ffa uses exceptions strictly as 'fucking stop whole program (and if it's running on a micro, whole machine, and flash 'dead!' lamp) right nao!' , so won't impact. my understanding is that it'd impact only speed of the ~exceptions~, longjump is slower cuz it crosses pages -- cachaistically. ☝︎☟︎
mircea_popescu: ffa eminently bad for this, cuz of all the ct stuff.
bvt: i expect it will be slower, but it won't hurt to do the check. the impact will depend on how exceptions are used (i don't think it can have any impact on ffa, for example). but i don't have enough experience with it to provide any numbers ☟︎
asciilifeform: http://www.loper-os.org/pub/ffa/gnatology/ave1gnat/index.htm << linked for the log. cross-indexing dunwork currently, as the damn thing aint a gpr project, but currently i dun have time to try to massage it into one , promises to be a week-long shitfest on its own
asciilifeform: and in particular, ln. 1079 of s-taprop-linux.adb , which implements the pthread mechanics behind the gnat scheduler
asciilifeform: ln. 163 of s-tasini.adb ;
asciilifeform: diana_coman: http://btcbase.org/log/2019-02-10#1894644 << >> http://www.loper-os.org/pub/ffa/hypertext/ch16/os__ads.htm#44_24 ☝︎
asciilifeform intends eventually to actually try ffa on a micro with deliberately-glitchy environment, e.g. inside that xray oven, and see how this goes in real life
a111: Logged on 2019-02-05 14:49 asciilifeform: on that subj, attentive ffa reader will notice in certain places asciilifeform marked in comment 'cosmic ray resistance' . this indicates mechanisms where there are two or more separate pieces that ensure a correct computation (or death with alarm bells) if somehow bit flips , when this is inexpensive.
asciilifeform: http://ossasepia.com/2019/02/07/seppuku-job-market-minimal-dynamic-tasking-in-ada/#selection-101.42-101.207 << possibly i mentioned this prev., but asciilifeform avoids secondarystack not because it doesn't work reliably , but because it makes audit of binary moar difficult. i dunno if this concern is really applicable to items other than ffa.
asciilifeform: mircea_popescu: i cant speak for eucrypt, but ffa is at least as much experiment in 'can program be written to make sense?' as it is arithm lib
mircea_popescu: yes "object oriented" verbosity is ridoinculous. nevertheless there is A LOT of meta involved that no ida ever sucks out, cuz it's not machine-accessible. which is why both eucrypt and ffa published chapters look like they do.
asciilifeform: BingoBoingo: i'ma get to it at some pt. currently hands full with 1) ffa 16b & 17 2) looking into to whom we gotta http://btcbase.org/log/2019-02-03#1892227 3) speccing components for 2nd rk plant ☝︎
mircea_popescu: whether you're willing to confront this or not, it's still factual that ~you~ wrote ffa at least ~in part~ because republic, and left to your own devices entirely you'd conceivably be http://btcbase.org/log/2019-02-04#1892360 to this very day! ☝︎
mircea_popescu: where truffle is macro-expanded to "fixed my ffa" ?
mircea_popescu: education is this process whereby people are sharpened, not changed. if girl has it in her to outwrite your ffa, she conceivably will, and if not, she will not. why's this something i'm to fret about ?
mircea_popescu: and then b) why and wherefore is "work" defined in terms of "ffa improvements" ? thing's not even supposed to be ~improvable~.
mircea_popescu: except the situation is exactly reversed : it's not nicoleci that's expected to improve on ffa, it's you that's expected to improve on http://trilema.com/2018/how-things-have-changed/#selection-489.0-501.257
asciilifeform: and yes if/when nicoleci or new one etc sends in an optimization for ffa arithm, i'ma take it back.
asciilifeform: we already iirc did the a:'so how many solved the ffa puzzlers' m : 'i wouldn't waste a precious trained gurl on such dirty works' thrd, dun have to replay.
asciilifeform: on hardwarized ffa variants, this output is to be connected to either an actual bell, or at least red 'sad' lamp.
asciilifeform: on that subj, attentive ffa reader will notice in certain places asciilifeform marked in comment 'cosmic ray resistance' . this indicates mechanisms where there are two or more separate pieces that ensure a correct computation (or death with alarm bells) if somehow bit flips , when this is inexpensive. ☟︎
asciilifeform: truly vintage (ada-83) won't eat ffa, there is use of 'in out' parameters.
asciilifeform: re ada2012, that was actually a good q, and i'll answer it for the log : ffa in fact uses preconditions, a 2012 knob.
asciilifeform: diana_coman: posssibly i oughtn't to graduate'em till they solve all the ffa homeworks.
asciilifeform: verisimilitude: as a concrete example : you will find that ffa uses an unmoving hinge for karatsuba multiplication. consequently all numbers are required to occupy a space that is a power-of-two bits wide. but from this you get a 3-4x simpler mechanism.
asciilifeform: ffa in particular is intended as , among other things, a didactic demonstration of what means 'fits-in-head'.
asciilifeform: i intend to port ffa to msdos, for instance, and don't expect that gnat will be building it ~on~ dos box.
verisimilitude: Alright; I'll keep that in mind when I am finally able to study your FFA.
asciilifeform: http://www.loper-os.org/pub/ffa/hypertext/ch16/ffa_calc__adb.htm << ffa as of ch. 16.
asciilifeform: verisimilitude: in 2016 i found that i gotta write a safety-critical arithmetic system (nao known as ffa) and found that i cannot in good conscience do it in anyffin but ada.
asciilifeform: seems like verisimilitude has visited previously, but nao is getting into adaism via ffa ( http://logs.bvulpes.com/asciilifeform?d=2019-2-5#458157 )
asciilifeform: also unlike e.g. rms, asciilifeform even washes, even tho washing dun even directly bake any ffa...
mircea_popescu: "i can't do any ffa work because i'm working on a manner in which to do it that wouldn't produce the idle inquiry of loc 6 months in"
asciilifeform: http://btcbase.org/log/2019-02-04#1892238 << possibly oughta include the tidbit re arithmetical part of ffa being 100% built (can gen rsa primez nao, can do so easily after ch17, where looping is introduced) ☝︎
asciilifeform: for ffa , the only os knobs you need are 1) a means for getting commandline string 2) equiv. of putchar 3) equiv. of getchar 4) a means to read bytes from a FG .
asciilifeform: re ffa in particular, if yer testing on something truly exotic (in re not having a posix layer) you will have to change a coupla lines in os.adb where i/o happens
asciilifeform: incidentally i expect that results from 'does ffa build' carry over to errybody who is currently using a ffa-derived gpr config ( this includes diana_coman , iirc , and possibly phf )
asciilifeform: incidentally, even old-fashioned barbaric adacorpse gnat was well-behaved re '-static' flag -- there's an os that dun even support static link (crapple) and it will properly barf there, rather than silently build dynamic ( incidentally can still build a runnable ffa there, fwiw, in debug mode -- see readme.txt )
asciilifeform: and http://btcbase.org/patches/ffa_ch16_miller_rabin.kv/tree/ffa/libffa/ffa.gpr .
asciilifeform: specifically http://btcbase.org/patches/ffa_ch16_miller_rabin.kv/tree/ffa/ffacalc/ffa_calc.gpr
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 )