log
500+ entries in 0.056s
diana_coman: asciilifeform: for one thing you already have skills he doesn't yet seem to have and for the other thing you constantly say it yourself that at times there is no juice left for ffa /similar.
asciilifeform: http://btcbase.org/log/2019-05-17#1914368 << consider ada. ( ffa series imho makes a decent ada tutorial, and so does diana_coman's series ) ☝︎
asciilifeform: stjohn_piano_2: this sorta thing is almost universal afflication of young folx. i can see why you choked on ffa tho, it has literally no 'parts that can be safely skipped'
asciilifeform: stjohn_piano_2: ever read ffa series ?
asciilifeform: amberglint: once i wrap up ffa, will proceed to bake a probe for the working machine, to get oscillogram of couple minutes of bootup/run ☝︎
asciilifeform: bvt: with straight (no asmisms) 64bit ffa, i found ~exactly 2x slower on x60 than on the 2393
asciilifeform: this is trivially verifiable experimentally : build for 32bit ( 'MachineBitness' in http://www.loper-os.org/pub/ffa/hypertext/ch18/iron__ads.htm ) and get ~exactly 2x slower.
asciilifeform: in the parlance of seymor cray et al, ffa is 'cpu-bound problem'
asciilifeform: speed of ram, interestingly, has ~0 effect on ffa timing, given as the working set ~always fits in cache
asciilifeform: imho you defo wouldn't want to ffa on a post-2013 amd, or any intels etc aha
asciilifeform: mp_en_viaje: pre-barrett ffa , when rsaing, spends most of wallclock time in fz_mod , is all. which dun multiply. in 14+ , i fully expect 2-3x boost from asmism (possibly higher, with massage w/ magnifying glass for pipelineism etc )
asciilifeform: i fully expect that the asmistic branch of ffa will be sewn out of bvt's item
feedbot: http://bvt-trace.net/2019/05/unrolled-assembly-comba/ << bvt's backtrace -- Unrolled x86_64 Assembly Comba for Ch. 11 FFA
asciilifeform: observe that (despite considerable sweat) asciilifeform was not even able to write ffa , on gnat, 'using only what is standard'
asciilifeform: this is sorta the basic idea in e.g. ffa -- 'what's the simplest mechanism that will actually suffice'
a111: Logged on 2019-04-23 23:06 asciilifeform would luvvv to read 'ffa-style' incarnation of such a work, where the chip is 'built up' from empty space in ~hour-long chunks. but prolly this won't exist until asciilifeform writes 1..
asciilifeform would luvvv to read 'ffa-style' incarnation of such a work, where the chip is 'built up' from empty space in ~hour-long chunks. but prolly this won't exist until asciilifeform writes 1.. ☟︎
mp_en_viaje: AND, with all the experience from ffa, you actually got what you need as a basis to actually make that megaspire work.
mp_en_viaje: alright, well, month's not bad -- by the time you're done with ffa you can start a mega-bolix series.
mp_en_viaje: how long you got till ffa series done ?
asciilifeform: ffa text massage , mostly
a111: Logged on 2019-04-17 16:24 asciilifeform: unrelatedly : phf , iirc you signed a coupla ch of ffa prior to the keccak regrind. didja ever sign the reground chs ?
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"