log☇︎
1243 entries in 0.871s
asciilifeform: relatedly, asciilifeform sawed ffa into independent subunits ( e.g. mults, bitops, divides, etc. ) for smooth compilation, reading, and blogomatics.
a111: Logged on 2017-11-21 18:36 asciilifeform: in other noose, ffa elf on x86-64 with no inlinings and stripped .a , is ~50kB
asciilifeform: in other noose, ffa elf on x86-64 with no inlinings and stripped .a , is ~50kB ☟︎☟︎
asciilifeform: ... pretty depressing, and just about obscene, you could just about fit msdos mega-game DIGGER.COM in the space taken by gcc's notion of ffa_mul_comba !
a111: 336 results for "ffa", http://btcbase.org/log-search?q=ffa
asciilifeform: !#s ffa
asciilifeform: http://btcbase.org/log/2017-11-16#1739930 << this was probably the most frequent logical mistake asciilifeform made when writing first draft of ffa ( in particular, the shifts ) ☝︎
asciilifeform: if you remove the div0 trap from ffa, you end up likewise with a reg full of 1s. it's what knuth division produces when given a 0 divisor.
asciilifeform: the only way to detect overflow on risc-v is the algo i used in ffa. ☟︎
asciilifeform: http://btcbase.org/log/2017-11-16#1739561 << possibly i mentioned this, i am making an asm ffa in parallel with the ada item ☝︎
asciilifeform: returning to http://btcbase.org/log/2017-11-16#1739533 , i will point out that inline asm is ~likewise~ a gcc-specific syntax. so if you're marrying gcc you may as well use the existing ( as seen in ffa ) rotate intrinsic. ☝︎
asciilifeform: result is a 4x slower ffa.
asciilifeform: because ffa.
asciilifeform: not to mention that 2^4097 cannot be represented AT ALL in a 4096bit ffa
mircea_popescu: but yes, the alternative is to genesis it and then link downstream from ffa.
asciilifeform: prior to realizing that ffa is the troo path, asciilifeform actually planned to entirely re-do the mpi item
mircea_popescu: And in this here FFa post we will be taking Comba Mult version x from y date and together with last week's X, Y and Z, and make this pile
asciilifeform: i was just thinking about this, this morning, during the 'declare' thread -- wanted to link to a particular item in ffa, and realized that i couldn't
asciilifeform: neither did modular types of arbitrary bitness, and several other minor nuts and bolts of ffa, that i cannot immediately recall.
asciilifeform: ada ( even asciilifeform's 'fascist' ada subset ) is not exactly pascal. imho the most notable departure is the array slice abstraction, which makes for a 90% moar compact ffa ( and applies to almost anything else dealing in bitstrings, for that matter )
asciilifeform: ( see also http://www.adaic.org/resources/add_content/standards/05rm/html/RM-5-6.html , and ffa )
asciilifeform: in n-bit ffa arithm.
asciilifeform: http://btcbase.org/log/2017-11-14#1737525 << this is therightthing. but note that not only is http://btcbase.org/log/2017-11-14#1737533 not a problem, but the behaviour is fundamental to ffa. in ada a structure is considered nondynamic if its size doesn't change at run time. not if 'magic number' size, like in overflowlang. ☝︎☝︎
phf: well, i'm thinking in terms of a TMSR MACHINE. scheme.adb linked against ffa linked against that com1 hack you posted some time ago :p
asciilifeform: indices. as seen in ffa.
asciilifeform: and for that matter of the ada std lib - using part ( once the debuggery put_line's in ffa are done away with )
asciilifeform: spyked: it's ok to post it 1 routine at a time ( as i do with ffa )
spyked: I'm also keeping the idea of potentially embedding in other ada projects (e.g. adacoin?) in mind. but so far wrestling the ffa aspects were enough of a challenge. oh, and there's no gc yet, the thing leaks memory like hell. but that's not its biggest problem.
spyked: in other news, I've been using most of my spare cycles lisping in ada. should be able to wrap up a blog post sharing a very minimal prototype (sane implem. of repl doing nothing but basic ops) in a few weeks. what I've got now adheres to most of ffa constraints. the current version isn't very clean, but getting there... ☟︎
a111: Logged on 2017-11-10 14:12 asciilifeform: when i sit to play a game, it feels like dereliction of duty, with, e.g., ffa yet undone, dulap not yet replaces, scintollator rng not complete, 9000 other processes
asciilifeform: when i sit to play a game, it feels like dereliction of duty, with, e.g., ffa yet undone, dulap not yet replaces, scintollator rng not complete, 9000 other processes ☟︎
asciilifeform: after bath (ffa) is built, i have 0 intention of continuing to rub against tree trunk to clean.
asciilifeform: this echoes the ffa 'omfg slow' discussions.
asciilifeform: and yes i am in fact allergic to any algo that i do not immediately understand, because entire objective of ffa is to be correct-via-obviousness.
asciilifeform: no reason to. not on ffa, at any rate.
apeloyee: the division in ffa is slow
asciilifeform: asciilifeform did not touch ffa/p at all other than on airplane, in past wk
asciilifeform: ( incidentally there will be no crtism in ffa . )
asciilifeform: ( other than the basic cost of using ffa )
asciilifeform: mircea_popescu: in ffa world, you don't lose anything by using a W-bit prime for the public exponent.
asciilifeform: we weren't comparing gpgmpi to ffa ; but gpg.publicmodexp vs gpg.privatemodexp
BingoBoingo: If math was fair, Elloit would have already had an ffa for asciilifeform
asciilifeform: 1+ sec is moar in ffa ballpark than heathentron's
asciilifeform: ( ffa work resulted in many hours deep in knuth )
mod6: with comba, for instance, as with others (ex. karatsuba): i tend to go and read the papers on it, then review the code and see how ffa is doing it. etc.
mod6: been studying ffa most of the month.
asciilifeform: http://btcbase.org/log/2017-10-27#1730047 << i sat down to write something quite similar, and then realized that i can milk a remote node for its rsa privkey via timing , lol. but fast forward to today. ffa still on track for release for end of nov. btw. ☝︎
asciilifeform: mircea_popescu: ffa is example of very painful to write, but intended to be a breeze to read, workpiece
a111: Logged on 2017-10-14 18:57 apeloyee: still, left-to-right exp (as inhttp://btcbase.org/log/2017-10-14#1725202 ) uses one FZ-sized temporary less than current ffa's right-to-left. (the indexing of E can be reverted to what ffa currently has).
apeloyee: still, left-to-right exp (as inhttp://btcbase.org/log/2017-10-14#1725202 ) uses one FZ-sized temporary less than current ffa's right-to-left. (the indexing of E can be reverted to what ffa currently has). ☝︎☟︎
asciilifeform: canonical ffa will never contain asm.
a111: Logged on 2017-08-10 02:43 asciilifeform: for simplicity, tested the case that actually happens in practice: on a 64bit box, any ffa width over 512 bits gives a strictly 8-wide comba mult ocurrence
a111: Logged on 2017-10-08 00:20 asciilifeform: http://btcbase.org/log/2017-10-07#1722411 << 1 ) ffa is closed form. i.e. it CAN be written as a number of nand gates, with a 'funnel' at the top, to which you present a,b,c, e.g. 4096bit, numbers, and at the bottom in a little cup you get a^b mod c , and with NO UPWARDS FEEDBACK FLOW of information , i.e. answer comes after same interval of time always, and with strictly downwards signals.
asciilifeform: http://btcbase.org/log/2017-10-14#1725197 << this is so. idea of quoted thread was, i'd like to get ffa to where it uses strictly 2 machine types, 'Word' (whatever that is on whatever machine) and, say, 'Index', which is guaranteed to be mod 2**16 or larger. and get rid of all conversions. ☝︎
asciilifeform: this is not bad time to ask the tuned-in folx, what parts of ffa they would like to see explained in moardetail.
mod6: i do also think there could be paragraphs even written around certain procedures in ffa. but not sure if that belongs in the code, or as a corresponding document outside of the code.
asciilifeform: in the end you will have 'written ffa' nearly same as asciilifeform had.
a111: Logged on 2017-10-13 15:14 asciilifeform: keep in mind that ffa ( esp. the more recent items ) will change.
asciilifeform: mod6: current ffa has no problem building and running with 32bit word; but it will not do useful work in 8/16bit msdos, and this needs fix ( i described simple fix above. my priority atm tho is barrettron and practical rsa demo )
asciilifeform: keep in mind that ffa ( esp. the more recent items ) will change. ☟︎
mod6: i believe there to be a lot of merit to having unit tests around the specific procedures and functions in ffa.
asciilifeform: mod6: the key imho re a ffa tester, is that it gotta exist ~outside~ of ffa, and use a traditional, known-to-produce-correct-numberz ( and ideally, more than one ) arithm stack
mod6: probably won't even start until we're closer to a finalized version of ffa.
mod6: again, these are unit tests, not functional, integration, or performance tests. meaning: i simply call a (so far public) procedure/function within ffa with specific parameters, and expect specific outputs.
mod6: ive been writing unit test for ffa
asciilifeform: in very other lulz, at most recent count 'p' stands at 3.2kloc, of which 2k is ffa ( this is inclusive of comments, tests, and commented alt-incarnations of certain routines, as discussed in l0gz )
asciilifeform: the supposition that ideally-correct ffa could possibly run slower than the current one (supposing these 2 differ) i see as quite fantastic.
asciilifeform: trinque: i won't recommend to take current ffa and put in battlefield . but proposed to calculate a bandwidth assuming current degree of ughslow
asciilifeform: i'd concur with mircea_popescu that one ought not connect ffa to, e.g., icbm, until it comes with proofs for all of the components, etc. -- but we do have a working modexp, from which can extrapolate pessimal speed ( it will get faster, but let's assume for said calculation that it will not )
asciilifeform: ( this is quite attainable using the ffa we have ~today~, supposing one allows karatsuba to split 3way on 3 cores of whatever chip you have )
a111: Logged on 2017-10-02 19:52 mircea_popescu: so what is the idea here, if i wish to review the state of this, other than asking you, i could also what ? !#s ffa ?
asciilifeform: is all you get. ( see current ffa src, it is illustrative )
asciilifeform: but this would weigh more than all of ffa to date !
asciilifeform: remember that ffa is not strictly for rsa.
mircea_popescu: incidentally, since we're on m-r : do we actually pick 4096 bit bases to avoid the arnault number problem ? to leverage the ffa flatness, as in http://btcbase.org/log/2017-10-07#1722376 ? ☝︎
apeloyee: if you have N ffa-eligible tests, bailing early out after one of them failed is not a problem.as per above.
apeloyee: http://btcbase.org/log/2017-10-07#1722397 << I was unclear. Let A be the number to be reduced mod N, R the approximate reciprocal, K the ffa bitness fitting the modulus, then we know that 0<A - N*floor(A*R/4^K) < 2*N <2^(K+1). So might as well calculate A - N*floor(A*R/4^K) modulo 2^(K+1). ☝︎
asciilifeform: ( karatsuba, i will note for n00bz, parallelizes , but i deliberately omitted parallelization logic because i want ffa buildable on msdos and for machines with 1 cpu )
asciilifeform: if ffa can be made to do 4096b modexp in 0.5s on typical comp, that gives ~1byte/msec purersa payload. which is enough for many purposes, e.g. voice.
asciilifeform: neato spyked . keep in mind that you gotta use the ada subset displayed in ffa.
asciilifeform: http://btcbase.org/log/2017-10-07#1722411 << 1 ) ffa is closed form. i.e. it CAN be written as a number of nand gates, with a 'funnel' at the top, to which you present a,b,c, e.g. 4096bit, numbers, and at the bottom in a little cup you get a^b mod c , and with NO UPWARDS FEEDBACK FLOW of information , i.e. answer comes after same interval of time always, and with strictly downwards signals. ☝︎☟︎☟︎
a111: Logged on 2017-10-07 22:39 phf: http://btcbase.org/log/2017-10-07#1722379 << this is probably true but only because ffa mutates an array of bigits, where's any language level bignum system produces a whole new one for each operation
a111: Logged on 2017-10-07 21:53 apeloyee: the primorial has to be, say, 2^32 times less than the ffa maxint. then you can add randomnumber*primorial, and such a number is equally likely to any prime from some interval
asciilifeform: http://btcbase.org/log/2017-10-07#1722405 << in no case can the 'cheap initial primality test' primorial exceed the size of current ffa width. thinkaboutit. ☝︎
asciilifeform: http://btcbase.org/log/2017-10-07#1722400 << bernstein's gcd method is neither here nor there, i certainly don't need anything of the kind in ffa, and quite likely it fundamentally does not ffaize ☝︎
a111: Logged on 2017-10-07 21:09 apeloyee: asciilifeform: turns out a simple, ffa-suitable O(N^2) algorithm exists for GCD. This is adapted from GMP docs with one extra operation in the loop: http://p.bvulpes.com/pastes/oupUJ/?raw=true . Note: the code as posted is likely wrong, but I'm sure the idea can be made to work.
a111: Logged on 2017-10-07 21:53 apeloyee: the primorial has to be, say, 2^32 times less than the ffa maxint. then you can add randomnumber*primorial, and such a number is equally likely to any prime from some interval
a111: Logged on 2017-10-07 19:30 asciilifeform: i also suspect that they are in fact slower for maxhammingweight case of exponentiation and modulus, vs ffa.
phf: http://btcbase.org/log/2017-10-07#1722379 << this is probably true but only because ffa mutates an array of bigits, where's any language level bignum system produces a whole new one for each operation ☝︎☟︎
apeloyee: the primorial has to be, say, 2^32 times less than the ffa maxint. then you can add randomnumber*primorial, and such a number is equally likely to any prime from some interval ☟︎☟︎
apeloyee: asciilifeform: turns out a simple, ffa-suitable O(N^2) algorithm exists for GCD. This is adapted from GMP docs with one extra operation in the loop: http://p.bvulpes.com/pastes/oupUJ/?raw=true . Note: the code as posted is likely wrong, but I'm sure the idea can be made to work. ☟︎
asciilifeform: i also suspect that they are in fact slower for maxhammingweight case of exponentiation and modulus, vs ffa. ☟︎
phf: i suspect that ffa's take on expmod is to iterate over every bigit of the exponent, which will have to perform base operations no matter what the numeric size is, but that's a guess.
phf: mircea_popescu: well he either has a constant time algorithm in ffa, in which case if the goal is to compare speed specifically we should be comparing fixtime ffa and fixtime something else. otherwise he has a variable time algorithm running at worst case constant time, in which case the comparison is between base operation speed, which is still going to come out on top
asciilifeform: in ffa, unlike in the python example, elongating the 0x10001 to full ffawidth will not change the required time.
mod6: (other than the ffa-fact, which i use sometimes to try new, whole, ffa parts out)
mod6: ah, ok. and yah, no need to let p out of the garage until ffa is pretty much "there".
asciilifeform: considering that it only wins vs euclid because 'fast comparison' , while ALL ffa comparisons are always and forever mercilessly O(N).
asciilifeform: it was made from the modulus finder from the prev ffa post ( http://wotpaste.cascadianhacker.com/pastes/KAZki/?raw=true )
a111: Logged on 2017-10-02 19:30 asciilifeform: trinque: http://wotpaste.cascadianhacker.com/pastes/lHtia/?raw=true << unofficial ffa.ads ; http://wotpaste.cascadianhacker.com/pastes/MqgKb/?raw=true << ffa.adb