log
500+ entries in 0.072s
diana_coman: hello asciilifeform ; ftr I've been enjoying the pehbot demos but atm I don't have a lot of time to catch up faster with ffa, sadly.
asciilifeform: oh ha, loox like peh/ffa are clean now ( the ln.1142 is a ~removal~ of uniturd from prev ch)
asciilifeform: http://btcbase.org/patches/ffa_ch17_peh.kv << a++ ty phf , worx
a111: Logged on 2019-03-18 16:28 asciilifeform: BingoBoingo: ffa is 3 ch away from fieldable beta atm ; so in attempt to avoid ending up like mod6 , i'm currently 100% in it. afterwards will switch for a spell to 100% elbows in piz.
asciilifeform: for thread-completeness : 'peh' has exactly 50 subroutines ( 37 procedures, 13 functions ) ; ffa : 245 ( 166 procedures , 79 functions ) .
a111: Logged on 2019-03-15 15:10 mircea_popescu: asciilifeform i think 256 is perfectly defensible. should be obvious what knob to twiddle for less or more anyway, admitting either one's trying to make ffa fit into tiny embed or use it for who knows what unforeseen purpose on large machines.
asciilifeform: asmism , i consider a luxury -- ffa is designed to operate reasonably quickly on commonplace iron without it.
asciilifeform: if someone thinks he needs a ~number-theoretical~ knob that 1) is missing in current ffa 2) cannot be efficiently baked out of the primitives -- he had better speak up soon.
asciilifeform: ( to be pedantic -- peh. ffa proper , is imho done, unless a reader finds apeloyee-style 'here's where you could have 2x faster' thing )
asciilifeform: BingoBoingo: ffa is 3 ch away from fieldable beta atm ; so in attempt to avoid ending up like mod6 , i'm currently 100% in it. afterwards will switch for a spell to 100% elbows in piz.
asciilifeform: picture if i had made ffa deal in 32bit words, and then proclaimed 'implement bignum on that'. do you imagine the result would be in any sense 'fits in head' ?
asciilifeform: ( for n00bs/readers -- ffa has fully deterministic memory footprint, by design, and 100% of what it'll use, lives on the stack, e.g. under unixlikes, setbrk() is not invoked )
mircea_popescu: asciilifeform i think 256 is perfectly defensible. should be obvious what knob to twiddle for less or more anyway, admitting either one's trying to make ffa fit into tiny embed or use it for who knows what unforeseen purpose on large machines.
asciilifeform: ( ffa does not deal directly in octets , the smallest access to storage is in unit of bus width. hence endianism-free )
asciilifeform: i'd like to request 5min of mircea_popescu wearing papal regalia . ch17 ffa , as perhaps was clear from http://btcbase.org/log/2019-03-14#1902386 , has a control-transfer stack ( for loops & subroutines . ) it, like errything else, is nonheapistic, therefore has a fixed size. currently set to 256. this constant gotta be nailed down. is 256 enuff? too small? too big ? ☝︎
a111: Logged on 2018-08-04 22:05 asciilifeform: ben_vulpes: iirc i proposed at one time an intermediate item on the way to proper gossipd ( 'serpent'-ciphered tunneler to connect coupla ircd instances to each other, and ditto for users ( get otp cookie a la deedbot, get a key that's good for 1 tcp connect ) but so far instead followed mircea_popescu's advice re not wasting sweat on such a thing, but pushing with ffa so as to get with what to gossipd.
asciilifeform: this is because a n-bit gcd (as appears in ch15 ffa) is simply 2n n-bit subtractions, 4n n-bit shifts, 2n n-bit muxes, plus some small change.
asciilifeform: that being said, gcd is not the bottleneck of anyffin in ffa.
a111: Logged on 2019-03-10 02:44 mircea_popescu: http://bvt-trace.net/2019/03/ffa-chapter-9-homework-comba-in-x86_64-assembly/#selection-15.295-19.176 << why this, specifically ? is there no ada asm calling method besides this ?
lobbesbot: bvt: Sent 22 hours and 22 minutes ago: <asciilifeform> http://bvt-trace.net/2019/03/ffa-chapter-9-homework-comba-in-x86_64-assembly/comment-page-1/#comment-12
asciilifeform: BingoBoingo: currently hands full restarting ffa conveyor; however will be ordering irons in next 2 wks, and scheduling flight when the items with least predictable shipment windows are in hand
asciilifeform: diana_coman: the 'errything on stack' approach has its limits; it is why i wrote the mmap thing (currently stuck in limbo , but i'ma have to revive it and fix, cuz ffa 17 also is hitting against this wall, you can't expect to put 100MB on stack, you gotta mmap it
a111: Logged on 2019-03-10 02:44 mircea_popescu: http://bvt-trace.net/2019/03/ffa-chapter-9-homework-comba-in-x86_64-assembly/#selection-15.295-19.176 << why this, specifically ? is there no ada asm calling method besides this ?
mircea_popescu: http://bvt-trace.net/2019/03/ffa-chapter-9-homework-comba-in-x86_64-assembly/#selection-15.295-19.176 << why this, specifically ? is there no ada asm calling method besides this ?
asciilifeform: ftr an 'iron ffa' cpu does not even require a massive multiplier . even a microcoded ffa-style thing that lets you specify 'and at memory x there is a w-word int, and at y a w word int, add'em' etc , would still massively win over the extant liquishit, it would do the arithm atomically, without invoking branchpredictor, losing cache, etc.
asciilifeform: ftr asciilifeform suspects that 99% of what can be won from asmism in ffa, can be had simply from bvt's existing 64bit mul, plus doing adc for the additions-with-carry instead of the manually-cranked carry calc, and that all 'fancy' instructions will only lead to sad
asciilifeform: !Q later tell bvt http://bvt-trace.net/2019/03/ffa-chapter-9-homework-comba-in-x86_64-assembly/comment-page-1/#comment-12
feedbot: http://bvt-trace.net/2019/03/ffa-chapter-9-homework-comba-in-x86_64-assembly/ << bvt's backtrace -- FFA Chapter 9 Homework: Comba in X86_64 Assembly
asciilifeform bbl : ffa room
mircea_popescu: this is yet another red herring. it is evidently true one needs arbitrary long chunks for arbitrary long tasks, say "to prove m-r i need a weekend alone". but "ffa" IS NOT this. ffa is eminently aditive.
asciilifeform: maybe this is a revelation to mircea_popescu , but 3 noncontiguous 1hr timeslots birth 0 ffa.
mircea_popescu: "the cost to buy this $160`000 item [which really can be had at $8`000 with some regularity, if one's not in a hurry] for $7`750 is $7`750 in cash + dropping the ballo on ffa + whatever else it is.
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 [http://www.loper-os.org/pub/ffa/hypertext/ch16/ffa_rng__adb.htm#27_14][in the FG reader] -- again cuz the underlying i/o routines produce'em )
asciilifeform: ( [http://www.loper-os.org/pub/ffa/hypertext/ch16/ffa_calc__adb.htm][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 [http://www.loper-os.org/pub/ffa/gnatology/ave1gnat/s-taprop-linux__adb.htm][s-taprop-linux.adb] , which implements the pthread mechanics behind the gnat scheduler
asciilifeform: ln. 163 of [http://www.loper-os.org/pub/ffa/gnatology/ave1gnat/s-tasini__adb.htm][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