log☇︎
9300+ entries in 0.066s
asciilifeform was given 'mk61' at same age i think diana_coman's kid is nao ☟︎
asciilifeform: ( before mircea_popescu answers 'holy mother of fuck, this is chemically-pure wankery' -- yes, it was. but imho still beats shit out of redditism. )
mircea_popescu: diana_coman was there, even!
asciilifeform: mircea_popescu: it's a stateful box of ??? ( rumour is, not even orig vendor can fully describe the phase space )
asciilifeform: mircea_popescu: manual is silent, for the most part, on subj.
asciilifeform: mircea_popescu: the 'test' vs 'cmp' thing is microscopic , so arguably red herring here
asciilifeform: ( based strictly on diana_coman's output )
a111: Logged on 2019-02-14 21:53 diana_coman: mircea_popescu and anyone else following along, here's the data from a set of runs with handlers from 0 to 3: http://p.bvulpes.com/pastes/9Cstd/?raw=true
asciilifeform: mircea_popescu: do i misread the http://btcbase.org/log/2019-02-14#1896636 run ? ☝︎
asciilifeform: diana_coman does seem to have crafted a testism where it does
asciilifeform: mircea_popescu: opposite. cmp is ~3x slower than 'test'
mircea_popescu: yet zcx does cmp rdx, 3 ; jz loc_50C
asciilifeform: mircea_popescu: it's what gcc does for small (i dun recall threshhold) computed switch
mircea_popescu: are you basically saying this sub eax, 1 ; test eax, eax ; jz loc_601 is optimal approach ?
asciilifeform: they're diana_coman's exception handlers.
asciilifeform: 490 is various mechanics, ends with _Unwind_SjLj_Resume .
asciilifeform: var_B8 contains some flag. valid values are 0, 1, 2, 3. if 0, we go to loc_490. if 1, loc_601. if 2, loc_62d. if 3, loc_659. if above 4, program dies, cpu executes ud2 (guaranteed bomb) .
asciilifeform: i suspect mircea_popescu dun habitually read gcc barf
mircea_popescu: loc_44E: << this entire thing\
asciilifeform: yw mircea_popescu
asciilifeform: http://www.loper-os.org/pub/misc/zcx_procs.asm http://www.loper-os.org/pub/misc/ljmp_procs.asm ☟︎
asciilifeform: mircea_popescu: the stack frame.
asciilifeform: i was discussing diana_coman's much earlier empirical find, that on ljmp stack fills faster per same # of calls. this here is why.
mircea_popescu: procs_a vs procs_a
asciilifeform: mircea_popescu: where 50 and 60 ?
asciilifeform: for thread-completeness : http://www.loper-os.org/pub/misc/zcx_proc_flow.png http://www.loper-os.org/pub/misc/ljmp_proc_flow.png
asciilifeform: 0000000000000000 <procs__a>:
asciilifeform: 0000000000000000 <procs__a>:
asciilifeform: diana_coman: btw your 'lick the 9v' intuitive observation earlier was correct, on ljmp variant the default stack frame indeed longer, 184byte vs 40
asciilifeform: diana_coman: the 'zcx' tarball contains a 'ljmp_calls' dir, same as other 1. which is correct ?
asciilifeform: ty diana_coman ! i'ma look
diana_coman: asciilifeform, here are the latest aka proc calls with 3 handlers per proc: ossasepia.com/available_resources/bins_calls_sjlj_adacoregnat.tar.gz and ossasepia.com/available_resources/bins_calls_zcx_adacoregnat.tar.gz ; let me know if you want anything else
a111: Logged on 2019-02-11 01:33 hanbot: diana_coman fwiw i ran into a few broken internal links on ossasepia today on account of their still pointing to dianacoman.com, see http://ossasepia.com/2018/03/08/eucrypt-compilation-sheet/ fo' instance.
diana_coman: mircea_popescu and anyone else following along, here's the data from a set of runs with handlers from 0 to 3: http://p.bvulpes.com/pastes/9Cstd/?raw=true ☟︎
lobbesbot: mircea_popescu: 7.10251150028e-06
mircea_popescu: diana_coman can we do with 2 and 3 extra handlers as a bonus plox ?
mircea_popescu: diana_coman wait wait, so it's in fact a HUGE penalty to use zcx is you have no extra handlers ?
mircea_popescu: diana_coman but they're parametrically related.
diana_coman: mircea_popescu, just to make sure you get this straight: Max is one thing, the final X is another i.e. the final X really counts how many times procs got entered; the max value means procs stop calling others (but note that the x=x+1 is done before the check precisely because I wanted to know how many calls)
mircea_popescu: diana_coman i don't get it, so it crashed with 16mn but worked with 22mn ?
diana_coman: mircea_popescu, ^
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 )
mircea_popescu: diana_coman possibly have to alter the linux config alf was mentioning it, blows out the 2mb stack max default.
asciilifeform: diana_coman: fwiw the noise floor on e.g my test box, is 0.003 (i.e. a proggy with empty main)
mircea_popescu: diana_coman try with 16777216 then.
diana_coman: <diana_coman> oh, no serpent in there ? it'll run VERY fast though i.e. 0.039s sort of thing -> darn, that's 0.0039
mircea_popescu: diana_coman well, that's what the x knob is for.
asciilifeform: mircea_popescu: i cannot resist to ask, is it 'ragassa' and not 'ragazza' ? ( was it a sicilianism or wat )
mircea_popescu: diana_coman take out the Encrypt(KS, Plain, Encr); line, this is just empty procedure calls.
asciilifeform: diana_coman: ideally when you do this, tar up not only the final bin but the contents of obj dir
asciilifeform: aite, i'ma do it to the variant mircea_popescu goes with
diana_coman: right; as soon as mircea_popescu confirms the code is what he wanted, will do
a111: Logged on 2019-02-14 16:05 asciilifeform: btw , to go with http://trilema.com/2019/so-what-is-the-man-saying , really oughta disasm a zcx variant and longjmp side by side and see what actually changes. ( when diana_coman comes back with working bins, i'ma set this up , for thread-co)
asciilifeform: diana_coman: if you have time, plox post a pair of bins so that i can http://btcbase.org/log/2019-02-14#1896414 tonight ☝︎
diana_coman: mircea_popescu, let me know if that's the sort of thing you had in mind or not
asciilifeform: diana_coman: how quickly is 'very' ? ( can haz numeric ? e.g. 'zxc eats 1kb per level of depth, sjlj - 2kb' )
a111: Logged on 2019-02-14 07:55 mircea_popescu: diana_coman : btw, here's my current model for the calling timing harness : write three procedures, A B C. have each of these 1. increment a global counter, X ; 2. check if X is over a max value ; 3. if it is not, have each call either one or the other of the other two randomly ; 4. if X is over max value, have them simply return.
a111: Logged on 2019-02-14 07:40 diana_coman: http://btcbase.org/log/2019-02-14#1896320 -> hm, trinque, do you suspect it's really just down to V version? I can easily re-run the thing with a V pressed to same node as yours to rule that out, if that's the case
asciilifeform briefly wondered if ben_vulpes
asciilifeform: !!down drunk_foxx
asciilifeform: drunk_foxx: better be quick
deedbot: drunk_foxx voiced for 30 minutes.
asciilifeform: !!up drunk_foxx
asciilifeform: mircea_popescu: could even say nao is 'bitcoin winter', the sorts of folx inclined to stuff head up arse are stuffing deeper than ever and boasting
asciilifeform: mircea_popescu do you think we oughta be making tiles ?
asciilifeform: right. so hypothesis requires then that it is viable commercially, i.e. someone other than mircea_popescu give enuff damn to bake'em into tiles.
asciilifeform: if actually 'don't care what costs', why not yet paid to have boatload of 5yo asics actually baked into tiles and installed in castle mircea_popescustein ?
a111: Logged on 2019-02-14 16:54 asciilifeform: ( i'ma take mircea_popescu's word for 'they are available to konsoomer' , evidently currently worth slightly moar as chump bait than as ore )
asciilifeform: ( i'ma take mircea_popescu's word for 'they are available to konsoomer' , evidently currently worth slightly moar as chump bait than as ore ) ☟︎
asciilifeform: mircea_popescu: recall your hypothesis re 'folx will heat house with miner' ?
a111: Logged on 2019-02-10 15:40 mircea_popescu: in other news, bitcoin difficulty looks like it's finally come out of the crazy and into economic coupling, check it out, past six months it's been evidently kept in place by fiat exchange rates.
asciilifeform: btw , to go with http://trilema.com/2019/so-what-is-the-man-saying , really oughta disasm a zcx variant and longjmp side by side and see what actually changes. ( when diana_coman comes back with working bins, i'ma set this up , for thread-co) ☟︎
asciilifeform: mircea_popescu: depending on your irons, page can be 4MB
a111: Logged on 2019-02-14 07:49 diana_coman: according to docs, the mere presence of a handler of exception slows the whole things down when lj
mircea_popescu: "random" doesn't need to be strong, just enough to fuck the optimiser. mt_rand or anything works really.
mircea_popescu: diana_coman : btw, here's my current model for the calling timing harness : write three procedures, A B C. have each of these 1. increment a global counter, X ; 2. check if X is over a max value ; 3. if it is not, have each call either one or the other of the other two randomly ; 4. if X is over max value, have them simply return. ☟︎
mircea_popescu: diana_coman but nobody's ever adding MORE handlers. so if this is so, it still is moot.
mircea_popescu: diana_coman do you mean risen exceptions ?
diana_coman: mircea_popescu, the thing there is: it's true we don't care about it if the server crashes but is it also true we don't care about an overall slowdown at all times because of each and any exception actually handled in the code?
a111: Logged on 2019-02-14 04:05 trinque: mod6: the curious thing is that you have full paths in just *part* of your genesis.vpatch, in the same exact way diana_coman did
a111: Logged on 2019-02-14 02:01 mircea_popescu: http://btcbase.org/log/2019-02-13#1895868 << we don't so much care, seeing how we don't intend to have exceptions but exceptionally. if the thing crashes ever, your problems will be in excess of 99, but none of them that "it took one half milisecond extra for burning relic to make it back to earth"
mod6: http://p.bvulpes.com/pastes/zHUbI/?raw=true << vdiff info, built with the gnat '16 blob, and starter_v.zip
trinque: yep, whereas I pressed mine to bvt's patch http://btcbase.org/patches/vtools_tempfile_standalone_notmp
mod6: I'm 98% sure that I got my vdiff out of diana_coman's starter_v.zip, lemme double check.
trinque: mod6: the curious thing is that you have full paths in just *part* of your genesis.vpatch, in the same exact way diana_coman did ☟︎
mod6: I suppose there's some good wisdom in that. I wouldn't want mircea_popescu torch his trb if it does weird shit on a 'getinfo' either.
a111: Logged on 2019-02-14 01:42 mod6: So I went to build one, but that was barfing on me. Which lead me to find this kernel option 'CONFIG_FIRMWARE_IN_KERNEL=y'. Which would help me complete the build of the initramfs. http://www.mod6.net/cuntoo-blog-1/genkern/genkern.jpg
a111: Logged on 2019-02-14 01:56 mod6: it's like, fuck this, I want a "GIVE_ME_EVERYTHING_YOUVE_GOT_WHORE" flag that build every driver known.
a111: Logged on 2019-02-13 21:59 diana_coman: at least there are no more surprises of huge differences in timings; but I'd still test also with some exception handling since that's supposed to slow sjlj down
asciilifeform: mircea_popescu: failure to init caused by 'i have nfi what is this chip' is silent on linux.
mod6: it's like, fuck this, I want a "GIVE_ME_EVERYTHING_YOUVE_GOT_WHORE" flag that build every driver known. ☟︎
BingoBoingo: mircea_popescu: ty, will try lightening up the payload copy for mass distribution
asciilifeform: mircea_popescu: it'll do it , supposing that kernel actually sees the disk ( whether it does, is not obv, observe that it dun come up in the kernel barfola )
mod6: mircea_popescu: It's SATA.
mod6: So I went to build one, but that was barfing on me. Which lead me to find this kernel option 'CONFIG_FIRMWARE_IN_KERNEL=y'. Which would help me complete the build of the initramfs. http://www.mod6.net/cuntoo-blog-1/genkern/genkern.jpg ☟︎
asciilifeform: mircea_popescu: ffa built with inlining switched off is actually ok test for ~that~ imho
asciilifeform: mircea_popescu: correct
asciilifeform: mircea_popescu: calls dump register snapshot liquishit on the stack, and inevitably ding the cache, whereas loops not
a111: Logged on 2019-02-12 18:59 mircea_popescu: basically idea is, a markov chain of callings.
a111: Logged on 2019-02-12 13:14 mircea_popescu: wasn't the long jump thing slower ~generally~ ?