log
600+ entries in 0.063s
mircea_popescu: then you can say "hey folks, we're done with the ffa that i know how to do, item is shelved for now, will pick it up if i wise up"
mircea_popescu: now you're in the position where you complain "no cash for pizarro" and "no time for ffa".
asciilifeform: do we have to do the 'do you want CORRECT ffa or fast ffa' thrd again.
mircea_popescu: the question is specific enough. you a) failed to publish any ffa matter during the MONTH of february. not during ~each individual week~, as the original notion went, after the last time we reviewed this, more or less around http://ossasepia.com/2018/02/06/its-only-words-and-assumptions-and-priorities-and-ouch/
asciilifeform: for instance ? 'on what burned cycles?' 3h on xray. 22 on pizarro (iron what-do, and learning how to mircea_popescuate forums, which not ready for field of yet). 30+ on ffa.
mircea_popescu: asciilifeform so what am i putting in this month's report, " alf was gonna do ffa but went away to play with xrays instead" ?
asciilifeform: mircea_popescu: i've had occasion to move the stack limit ( when tested ffa with massive fz widths, recall , all allocations are on stack ) but not otherwise
asciilifeform: ( as asciilifeform recently discovered re ffa. it dun thread, and gcc correctly snips out all pertinent coad )
asciilifeform: asciilifeform's 1st step in writing ffa, recall, was to conceive of (and prove) an arithmetic workaround for above. that, right off the bat, cost ~10fold cpu.
asciilifeform: as is all current test build of ffa, etc
asciilifeform: ( i dun currently use, but it's definitely going into the final revs of ffa )
asciilifeform: ( e.g., ffa, built yes on arm64 using ave1's system, but it's spartan to the point of starvation featurewise)
asciilifeform: one could actually ffa on that ( if somehow find one ! )
asciilifeform: ( btw the obj reason why none of this is visible in ffa -- there aint any tasks! so even in ljmp mode it shits out same coad )
asciilifeform: ( to 0 measurable diff in ffa, oddly enuff, but on e.g. tiny micros might make a diff.. )
asciilifeform nao wonders if there's a seekrit chest fulla ffa speedup in this dig
asciilifeform: mircea_popescu: i've had to up stack depth on 1 occasion before -- when testing ffa with ridiculously wide bitnesses ( recall, item runs 100% stackistically )
asciilifeform: mircea_popescu: ffa built with inlining switched off is actually ok test for ~that~ imho
asciilifeform will re-play ffa benchmarks on the longjmp gnat, once the latter's built, but doesn't expect to find any measurable diff
asciilifeform: ( ftr all 'canonical' ffa tests are built with o2 : http://btcbase.org/patches/ffa_ch16_miller_rabin.kv/tree/ffa/libffa/ffa.gpr#L56 )
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.