log☇︎
18000+ entries in 0.152s
asciilifeform: i haven't seen with own eyes tho ( and would rather not ) the biznis-end of that.
mircea_popescu: i have nfi.
asciilifeform: on a few occasions i had to go to where it was done. power supply cable as thick as my thigh.
mircea_popescu: i tell you honestly, if i ran a lab where such a compound was seriously important, i'd spend the 100k or w/e it is to have a model welded out of steel balls and rods, and place it in the lab gym.
asciilifeform: i had a 30k$ sgi 3d viewer thing, worked ok ( 1 part 50kg crt, other part went on yer head. ) point is that nao you can get ~same thing for 100. not that there's much in the way of people who are still doing any of this afaik. ☟︎
asciilifeform: i used to do this for a living, tho. ( and no it aint a great biz to be in, the models just barely work )
asciilifeform: mircea_popescu: funnily enuff, decent quality konsoomer '3d visor' appeared , i got one as a gift not long ago. but i dun do chemical models any moar, and so no constructive use for it any moar
asciilifeform: re nn in general -- i vaguely suspect that a quality rng might actually cure the http://btcbase.org/log/2017-07-20#1687624 problem. but again i dun have any pigs, so haven't had occasion to try. ☝︎
mircea_popescu: (frosi, teh magazine of teh ddr's own pionierorganisation iirc, included a pair in one of the editions i got. i even played with them.
asciilifeform: i simply can't bring myself to buy any to test, i dun have any pigs that need autoclassifying
mircea_popescu: was all the rage when i was in school. alongside the period "GREAT DISCOVERY" of "3d glasses".
mircea_popescu: i know, i know.
asciilifeform: mircea_popescu: y'know, neural net, the thing that classifies pig as 'porn' etc. i'm even willing to believe that the chip worx to spec. not magic by any means, 1970s tech sitting on modern ic
asciilifeform: intel for instance sells 1 , for about 20bux in qty. what is actually on the die , i have nfi, and it only worx with their oddball closed compiler thing.
mircea_popescu: ~same utility as quantum computers, as far as i know.
mircea_popescu: w/e, perhaps i do not see teh future.
asciilifeform: ( and again will note, i haven't tried the various irons, may well be snake oils. )
asciilifeform: (e.g. the recent fad for 'face recognizer' even revived 1980s item, neural network processor. i haven't personally tried'em for anyffin , of yet )
asciilifeform: mircea_popescu: it's alive, in a sense (various image processing junk) but not sumthing you'd want anyffin to do with i suspect
a111: Logged on 2019-01-20 19:12 bvt: are such machines even build these days? i.e. for dsp, or other use-cases?
asciilifeform: the algo for this, i described coupla yrs ago here.
asciilifeform: in asciilifeform's o(1) tx indexer ( will be welded to an experimental bdb once i get the mmap thing resolved ) there's a 2-level storage -- a 'write-once' o(1) index for blox of age N ( N can be 100-500 in practice ), and a much smaller rewritable one kept strictly in ram ( for 'recent' blox, where the longest chain is potentially movable ) ☟︎
asciilifeform: i'd look at the realloc counter on the disk, betcha it's started to turn.
asciilifeform: mircea_popescu: that's the interesting imho part. ftr i have yet to witness a corrupted-but-openable bdb on machine other than where ssd was found to have rotted.
asciilifeform: i'll add , for completeness of thread, that if yer ~sending~, rather than receiving, rsa packets, your bottleneck will be ~rng~ long before it could ever be the arithmetron per se
asciilifeform: not having used gcc5+ , i never saw this bug
bvt: aha, i see. this would also involve lots function call inlining as well
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: i found last yr, for instance, that unrolled comba ( still in ada ) gives 20-25% speedup.
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: 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: 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.
bvt: are such machines even build these days? i.e. for dsp, or other use-cases? ☟︎
asciilifeform: bvt: i found a buncha these, when digging
bvt: i wonder how this is a valid argument even there. if nothing reads the flag, there are no pipeline dependecies.
asciilifeform: i find it interesting that -- afaik -- nobody's ever built iron that was specifically optimized for bignum
asciilifeform: ( ada standard btw trivially allows for types where this holds true automatically , i.e. throws exception for overflow. but this is not only massively unconstanttime but the overhead is gigantic )
a111: Logged on 2019-01-20 16:30 bvt: http://p.bvulpes.com/pastes/q0ffh/?raw=true - some things can be done with gcc specific features, but i guess asming is cleaner
asciilifeform: btw, must also add to bvt's http://btcbase.org/log/2019-01-20#1888517 >> https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html admits that : 'The compiler will attempt to use hardware instructions to implement these built-in functions where possible, like conditional jump on overflow after addition, conditional jump on carry etc.' , i.e. there is not a guarantee that the thing dun introduce cond jumps. ☝︎
asciilifeform: chances are that it wouldn't, tho, given how the table still has to be indexed via fz_mux in order to prevent variant (i.e. nonconstanttime) memory indexing
asciilifeform: possibly i'ma do a writeup on the subj, once errything else is fielded.
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: i prolly oughta add to the http://btcbase.org/log/2019-01-20#1888508 thing : 1 of the items which seemed like a speedup, but in actual practice sucked, was the use of (constant-time) 2 (ditto 4) -bit windows for modexp ( iirc apeloyee suggested ) ☝︎
asciilifeform: ( the 64x64 iron multer in amd/intel, possibly surprisingly, is in fact constant time, in all boxes i've tested to date )
asciilifeform: mircea_popescu: it is conceivable that the ones currently sold are constant time , i simply haven't tried'em.
bvt: i'll be afk an hour or two
bvt: i.e. W_Borrow/W_Carry still cause the overhead?
mircea_popescu: i suspect double-wide mul might be implemented by lookup tables.
asciilifeform: recent pc irons offer 128x128bit iron mul. but i have not investigated it, and it specifically gotta be tested for constancy of time
asciilifeform: bvt: i'd prefer asmisms to c imports ( which not only ugly and compiler-dependent, but i suspect destroy performance with overhead )
asciilifeform: but i dun currently have such a thing.
bvt: http://p.bvulpes.com/pastes/q0ffh/?raw=true - some things can be done with gcc specific features, but i guess asming is cleaner ☟︎
asciilifeform: ( and even presuming 100% correctness, bounds checks still give added 'cosmic ray resistance'. i ~like~ having'em )
asciilifeform: the other 'secret' speed boost is if one were to turn off the bounds checks; this gives ~2x speedup across the board. but i dun expect to do this for my personal uses for years , if ever -- it requires 100% certainty of correctness of the program under all possible input
bvt: my understanding is that asmism would go only for lower-level ffa code, i.e. barret/modexp will remain as-is.
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 ☟︎
bvt: will do. so far i had a very brief look at it
asciilifeform: sorta why, when i first started preparing the thing for publication, wound it back to the simplest known ('egyptian') variant, and walked from there.
mircea_popescu: there's that old joke re "i read good books twice but bad books i don't read at all" which very much applies : if only one knew before looking whether an algo is fast or slow!
mircea_popescu: anyway, nothing wrong with it, i enjoyed reading.
bvt: no, i mean that particular paper. i initially wanted to implement a fft-like multiplication algorithm, but got interested in this karatsuba/toom when reading the paper.
asciilifeform: 'i built atomic dirigible but fughet why!111'
bvt: nope, but there were a few mentions of other algorithms in the logs, so i decided to have a look. don't remember how i arrived at this particular one
asciilifeform: i assumed bvt knew of a use, given that he dug out the ru materials on subj
asciilifeform: bvt: i don't, which is why never bothered with fft
bvt: re fft: i would wait until a use-case appears, to at least understand what are the requirements. do you have something in mind?
asciilifeform: i saw. and imho would be interesting to have a constant-spacetime, no-floats fft
bvt: also, the linked pdf contains one FFT-like algorithm i considered to implement (using walsh transform for convolution instead of fft). but it'd be even more complex
bvt: i would not be surprised it was 20% slower, but 2x was surprising for me
asciilifeform: mircea_popescu: i'm not surprised, considering that bounds check overhead (in ada with all safeties switched on) magnifies the 'losing' of a losing (for particular width) algo
mircea_popescu: i suppose you might say "it shouldn't be x2, my expectation would be it's x2^1/2", but w/e.
asciilifeform: bvt: ty for reading, signing, and publishing experiment -- i will include your seals in ch16 article
mircea_popescu: i don't think so.
bvt: yes, and it's also true for memory accesses. however the number of executed instructions also increased a lot, which makes me suspect that there is something i missed
bvt: will provide more seals after i work with chapters 7-9 more.
bvt: as far as code speed is concerned, i still don't know whether i fucked up something, or the algorithm is fundamentally slow after some bignum size
bvt: re math, i found that htmling it would be unreadable, so decided to use images.
BingoBoingo: https://twitter.com/BBoingo/status/1086854906055741440 << mircea_popescu Seems I have yet to get twatter banned
BingoBoingo: ^ Yes I raised the alarm. Efforts to convince me to lower it are welcome. If you are outside my L1 you need to offer a stake and odds for your petition to be considered.
BingoBoingo: I suspect USG.NSA.JAVAGURLZ is auditioning for sandbag duty
asciilifeform: when he ran outta juice for that, i quit reading, there was literally 0 else worth even passing look
asciilifeform: lol i had nfi tardstalk were still around
mircea_popescu: far as cuckold itself, it seems to be more niche than it was say 5 years ago. Why is that? I'm seeing this stag/vixen thing being mentioned a lot more when I read websites. I didn't even know that was a thing?").
mircea_popescu: meanwhile in sad lulz, https://www.blacktowhite.net/threads/moving-away-from-cuckold-into-stag-vixen.146933/ ("Are people moving away? I'm noticing a shift in ads, profiles and websites that I browse. No one is really looking for a cuckold thing anymore. I got enthralled with the cuckold fantasy and I would love to meet a couple that was for it. But Cuckolds couples are hard to find. Couples, single females are easier but as ☟︎
mircea_popescu: i wonder if they know this.
mircea_popescu: i imagine they're just cheap.
mircea_popescu: i expect something in the vein of https://pbs.twimg.com/media/DQp94hcW0AAwFYQ.jpg
mircea_popescu: meanwhile @reddit, https://www.reddit.com/r/BlackWorldOrder/comments/6b6l12/what_can_i_as_a_pussyfree_virgin_whiteboi_do_to/
asciilifeform: quite likely they have an eventual capitulation to llvm ( and 'unification of the churches'(tm) ) planned as well, but i have nfi what's the holdup there
asciilifeform: mircea_popescu: his last , near as i can tell, act as a human, was to try & keep this liquishit out of his signed kernel tree. for which he was 'retired'.
asciilifeform: mircea_popescu: it's a google-submitted patch, and it got eaten by the new, 'improved' torvalds, near as i can tell
mircea_popescu: i guess so.
asciilifeform: (i.e. kludges introduced so that winblowz will run in slightly less geological time, 1990s-current)
asciilifeform: yea i get
mircea_popescu: not ffa ; the "lfence" bs i mean.
asciilifeform: mircea_popescu: i dug, and , unsurprisingly, a google production
a111: Logged on 2019-01-14 03:53 mircea_popescu: in other arcana : i have here a copy of trb that has died a mysterious death on dec 31st. the process itself hasn't returned, ps aux lists it as expected, however the last time it touched any files was two weeks ago, nor does a call to getinfo ever return.
BingoBoingo: I've encountered quite a bit of it in my spam traps as well as searching for life various all comers spam traps.
asciilifeform: BingoBoingo: i was doing the annoying but occasionally inescapable chore of sweeping out a spamola-encrusted mailbox, and ~100% of the spams were for something nominally smokable/pillable/etc
asciilifeform: ( and near as i can tell, ~100% of usg 'dope policy' is simply own competition for dope konsoomers. but i'm not particularly qualified to opine, nao if only gabriel_laddel were around... )