2600+ entries in 0.018s
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 i don't get it, so it crashed with 16mn but worked with 22mn ?
mircea_popescu:
diana_coman possibly have to alter the linux config alf was mentioning it, blows out the 2mb stack max default.
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 take out the Encrypt(KS, Plain, Encr); line, this is just empty procedure calls.
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)
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
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:
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.
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
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
☟︎ 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
a111: Logged on 2019-02-13 18:37
diana_coman: with no optimization (or -O0 iirc) it's ~8s; with -O3 it's 1.25s
a111: Logged on 2019-02-13 18:41
diana_coman: anyways, I'll compile the dataset and publish it in a bit
a111: Logged on 2019-02-13 14:49
diana_coman: wait, what?
mircea_popescu: well now i have to step out ;
diana_coman do some more experiments, get some more data, we gotta figure out wtf this is.
a111: Logged on 2019-02-13 14:24
diana_coman: asciilifeform, one! and look here at times: 1 loop -> 0.000168893 s ; 2 loops -> 0.007213758 s ; 3 loops -> 0.351611073 s ; 4 loops -> 17.74 s ; 5 loops-> 879.95 s
mircea_popescu:
diana_coman the problem is this : on the basis of this last run, we're estimating serpent to take 0.3 microseconds.
mircea_popescu:
diana_coman try whole 23 loops, same 1 to 10 mod 4 plox ?
mircea_popescu:
diana_coman seems it stabilizes after 3 loops or so, if you look, it's within a few % with .007s and pretty much there at 0.35s
mircea_popescu:
diana_coman idea was to go twice per loop, rather than 1nce. 2 will go in too many times still
mircea_popescu:
diana_coman you'll have to abort it, reduce the loops significantly. sorry bout that.
a111: Logged on 2019-02-12 23:41 mircea_popescu: i'm still waiting for
diana_coman to return.
a111: Logged on 2019-02-12 18:29
diana_coman: for added lulz, gnat on macos has only zcx :|
a111: Logged on 2019-02-12 18:27
diana_coman: hence I wanted to actually add some handlers in there and see but atm it's still working on the full run loops-only so will see after that
a111: Logged on 2019-02-12 14:53
diana_coman: about 0.45 secs per run reported (without long jump)
a111: Logged on 2019-02-12 08:00
diana_coman:
http://btcbase.org/log/2019-02-12#1895120 -> yep, that was precisely my ref when looking at Ada multi-threading and what support it offers; it actually reads a bit better than the barnes' progr in 2012 but it's more focused, obv
mircea_popescu:
diana_coman in ~principle~ zero cost exception handling is this thing : ~instead~ of calling code when exceptions arise, you instead unroll all calls in place, where exceptions might arise. this way you don't get a run-time penalty (because you paid for it in code space)
a111: Logged on 2019-02-12 14:05
diana_coman: mircea_popescu, eucrypt's test on Serpent seem good candidates as one can even adjust how many iterations to do if you want some specific time intervals; current full test of the serpent module (including i/o because of using test vectors in file) is reported by time at ~2.3s without sjlj; this has no tasks/exceptions as such;thing is: time is not extremely precise but I could run I suppose some 1k times and see
mircea_popescu: exactly what i had in mind for "hey
diana_coman check this" if you returned true.
mircea_popescu:
diana_coman do you have a non-trivial (non-huge) ada that you could run once with sjlj and once with zcx in a timing harness so we can get some data ? ideally something that takes 100-1000ms or so.
mircea_popescu:
diana_coman what happens if you actually put a pragma Abort_Defer in the loop ?
mircea_popescu:
diana_coman possibly because of how they do that binder table bs
mircea_popescu:
diana_coman this is so fucking retarded, "our thing does not implement the standard". RATIONALE ?
mircea_popescu:
diana_coman it looks like we'll end up with a patched tmsr-gnat.
bvt:
diana_coman: i agree; in the abort signal handler, there is a snippet of code that ignores the signal (given ZXC exception handling model).
mircea_popescu:
diana_coman is this abort-handler something you can define from within your proggy ?
a111: Logged on 2019-02-10 16:03
diana_coman: I also tried asynchronous transfer i.e. supposedly "try this and if timeout then do that" but apparently it's in fact still "oh, but ONLY if abortable"
a111: Logged on 2018-09-04 14:50 mircea_popescu: alright. so basically, we have a july latest-kernel from alf at
http://nosuchlabs.com/pub/conf_current.conf <<
diana_coman trinque erryone else interested read and see if it works for you / comment ?
a111: Logged on 2019-02-10 20:31
diana_coman: asciilifeform, and anyone else interested in testing Ada's failure to abort, minimal test setup: ossasepia.com/available_resources/test_tasks_ada.zip
a111: Logged on 2019-02-10 16:02
diana_coman:
http://btcbase.org/log/2019-02-08#1893804 -> sadly I must say that I failed to find a way to terminate the program if/when one of the tasks is just looping infinitely ; I tried: abort of the looping task -> nothing,because task is "not in an abortable region"; Abort_Task(Current_Task) from the main program -> still stuck because apparently it takes it to mean "will stop AFTER all my dependent tasks stopped too!"; raising an uncaught except
mircea_popescu:
diana_coman the one question lingering here is : as ada actually elaborates an init and an exit, as it must, since it does in fact compile, whether there's a way to use these correctly in lieu of "call C-mommy to change diapers".
a111: Logged on 2019-02-08 18:11
diana_coman:
http://btcbase.org/log/2019-02-08#1893756 -> this makes in fact a lot of sense esp given asciilifeform's observation that indeed, that's an unrecoverable error state; so this sounds good: if child task doesn't die when aborted then kill self (taking the task with self too ofc); I'll experiment with this but afaik so far it should work