log
500+ entries in 0.057s
a111: Logged on 2019-04-18 22:27 asciilifeform: ( i'll add : imho, an 'ffa graduate' oughta be able to write own correct arithmetron in his asm of choice, in coupla weeks , if feels like it. )
diana_coman: asciilifeform: the text helps esp. in conveying your intention/focus as it were; it's true that one could understand FFA just with the code but that doesn't mean that the posts don't help.
asciilifeform: ( i'll add : imho, an 'ffa graduate' oughta be able to write own correct arithmetron in his asm of choice, in coupla weeks , if feels like it. ) ☟︎
mod6: Well, fwiw, I'm trying to not load in any Cisms or other pantsuit liquidshit into my understanding of FFA. So when reading it, I'm trying to approach it somewhat like a babe. And I thought that I had it at least, mentally fitting in my head the way it is today.
asciilifeform: i'll add, however, that ffa does not use byte-addressing or bit-addressing, if you were to build a machine where either is in whatever direction, and write a (standard-compliant) ada for it, ffa will work same way.
asciilifeform: ( as it is , it looks like this )
a111: Logged on 2019-04-17 20:20 asciilifeform: mod6 ^ + other ffa-eating folx, i suspect will find diana_coman's piece quite handy
diana_coman: asciilifeform: updated with the .dia files http://ossasepia.com/2019/04/17/reading-notes-on-ffa-ch1-ch4/#selection-209.1-225.1
asciilifeform: diana_coman: what didja use to make the flow graph in http://ossasepia.com/2019/04/17/reading-notes-on-ffa-ch1-ch4/ ?
asciilifeform: diana_coman: re 'Natural' type -- this is one of asciilifeform's persistent headaches -- the lang forces certain things to be indexed by 'Natural', and i optimized for minimal # of casts ( i fucking hate casts, and imho the fact that one cannot write a proggy ENTIRELY without'em, is a language bug )
asciilifeform: http://ossasepia.com/2019/04/17/reading-notes-on-ffa-ch1-ch4/#selection-219.321-219.445 << y'know, there isn't any harm in 'looking ahead in the textbook', when you feel like doing so
asciilifeform: http://ossasepia.com/2019/04/17/reading-notes-on-ffa-ch1-ch4/#selection-161.412-161.519 << measurable penalty. which is why the 'range-independent' thing is in some ops but not others. i headached over this extensively when 1st wrote.
asciilifeform: mod6 ^ + other ffa-eating folx, i suspect will find diana_coman's piece quite handy ☟︎
feedbot: http://ossasepia.com/2019/04/17/reading-notes-on-ffa-ch1-ch4/ << Ossa Sepia -- Reading Notes on FFA Ch1 - Ch4
asciilifeform: currently looks like bvt is the champ ffa eater.
asciilifeform: unrelatedly : phf , iirc you signed a coupla ch of ffa prior to the keccak regrind. didja ever sign the reground chs ?
mod6: Did build keccak vtools on cuntoo, whole ffa tree verifies there. pressed just through chapter 1, did a gprbuild on that first chapter, no errors, works great.
asciilifeform: ty for update, mod6 . re ffa -- dun hesitate to ask q if you found anyffin to be unclear
mod6: Read through and digested the first chapter of ffa, just need to add my seal to your blog when I have a spare few minutes. Regarding the irc stuffs, I've one time, stood up a ircd-hybrid and connected it to a friends of the same as a "peer".
a111: Logged on 2019-01-05 15:58 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 )
asciilifeform confronts the fact that he's prolly doomed to pen a ffa-style vlsi tutorial 1 day..
mp_en_viaje: much like you'd break into alf's ffa and read some lines. same reason.
asciilifeform: asciilifeform would find it interesting to read the 1980s ada that's running on boeing etc. , but so far never found any leaked pieces thereof. would be interesting to see if resembles e.g. ffa style.
asciilifeform: http://btcbase.org/patches/ffa_ch18_subroutines.kv/tree/ffa/ffacalc/ffa_calc.adb#L553 << for thread-completeness, illustration of matching such 'strings'
asciilifeform: re config txt parsers, i dun grasp why it would need heapism, rather than simple http://btcbase.org/patches/ffa_ch18_subroutines.kv/tree/ffa/ffacalc/ffa_calc.adb#L99 -style offsets into the read-only text
asciilifeform: ( e.g. ffa, is none-endian )
asciilifeform: ( observe, earlier linked fg, ffa , distributed strictly as vpatches )
BingoBoingo: http://www.loper-os.org/?cat=49 << FFA, the author asciilifeform is dealing with a fever, but he is usually around
bvt: started pizarro isp (http://pizarroisp.net/), and wrote FFA crypto library, in case you wondered what 'FFA style' from my investigation report was: http://www.loper-os.org/?p=3141 - vpatch + a write-up for helping fitting-in-head the code
asciilifeform: http://btcbase.org/patches/ffa_ch18_subroutines.kv << loox a++ . also ty phf.
asciilifeform: meanwhile, http://www.loper-os.org/pub/ffa/hypertext/ch18/ffa_calc__adb.htm << final ch18 ; still working on the accompanying text
asciilifeform: would be mighty great use case for hypothetical 'ffa cpu' (i.e. arithmetizer with wide bus)
asciilifeform: http://www.loper-os.org/pub/ffa/2048bit_prime_demo_hist.png << histogram.
asciilifeform is almost surprised none of'em left comment in ffa series, 'bbbut didntcha read in schneier, you oughtnt homebrew crypto!11'
asciilifeform: ( for n00bz -- prime gen parallelizes, obv., over as many cpu as you have. but ffa per se does not use threads, tho it can be run inside threads with no added headache )
asciilifeform: fwiw 'speed of ffa' for applications involving modexp ( rsa keygen & enc/dec ) hinges ~entirely on speed of the multiplier unit in $iron .
asciilifeform: i expect that as moar folx eat ffa, we will have moar empirical figs to compare.
asciilifeform: ftr rk is effectively 2x, as measured, slower than this gauge box , on ffa.
asciilifeform deliberately uses oldest opteron in the torture room as 'standard ffa gauge' , if wasn't obv.
asciilifeform: ( mine, used as ref for all ffa figs, is opteron 2393SE @ 3.1G )
diana_coman: asciilifeform: timings sounds good to me; I have it on the list to get some timings for comparison when I get to eat full FFA, yes; atm though I can tell for sure that 10 minutes for generating key is both fine and rather fast even.
asciilifeform: ( when 1st started ffa, was quite ready to live with 'keygen takes hour+' ftr )
asciilifeform: on current ffa ( i.e. no asmisms )
asciilifeform: ffa_calc.adb : 1665 loc .
asciilifeform: ( in fact ada per se has a fascism knob that, if set, prevents early return from subroutines . i have not thus far used, cuz in ffa per se this is already the case, nuffin gets to terminate early when 'constant time' algo )
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 )