Logs for #asciilifeform

Go to: #trilema #pizarro #asciilifeform #trilema-mod6 #chainstate #eulora

2019-6-30 | 2019-8-1

asciilifeform: log test.
shinohai: Afternoon asciilifeform how goes?
asciilifeform: heya
girlattorney: hi
asciilifeform: hey
asciilifeform: girlattorney: didja find the segment of log where last received block ?
girlattorney: nope
girlattorney: too much crap
asciilifeform: grep for SetBestChain
girlattorney: tried
girlattorney: but no particular info
girlattorney: like: SetBestChain: new best=0000000000000000001b height=585026 work=2211427824132530600299547487
asciilifeform: is this the height returned if you call getinfo ?
girlattorney: currently is closed
girlattorney: but yes, that's was the height
asciilifeform: ok, move (or delete) the old log, and start the node going, then after half hr or whenever convenient, paste the log .
girlattorney: ok, will try tomorrow
asciilifeform: thx
girlattorney: hi
girlattorney: tried to compile on the arm board TRB, got this error: https://pastebin.com/0tHKviQ6
girlattorney: the board is an armv7, so no 64bit like rockchip, could this be a problem?
shinohai: Well girlattorney is right there at the top of your paste `Configured for linux-x86_64.`
shinohai: http://www.loper-os.org/?p=3420 <<< I really dig this asciilifeform, very readable and fits-in-head as advertised. A++ item.
asciilifeform: shinohai: don't hesitate to comment as you read
shinohai: Have been interested in mips ever since mats graciously provided spare erl2 to tinker with, managed to build a kernel for it but have always wanted to pare it down some.
asciilifeform: shinohai: updated article.
shinohai: ty asciilifeform, read benchmarks info. Look forward to teh republic making a kernel genesis.
asciilifeform: shinohai: not esp. useful tho, runs, on current-day pc, like a slightly faster 486
shinohai: I like the compact nature tho, certainly could be useful with more polishing I'm sure.
shinohai: As already stated in btcbase log, not useful perhaps for juggernaut like mp-turdpress, but I like.
asciilifeform: shinohai: there's a fundamental problem in re tlb, see today's thrd.
shinohai: Yeah, was already reading the piece on SIMD_and_SWAR_Techniques
asciilifeform: shinohai: http://www.loper-os.org/?p=3433
shinohai: ty asciilifeform ... will review patches. I want to build own kernel at some point as well, will post results.
asciilifeform: shinohai: you'll need the kernel patches
shinohai: http://btcbase.org/log/2019-07-25#1924752 <<< do we get a "TURBO" button? xD
asciilifeform: lol
bvt_away: hi. quick report: 'make dbglnk' still strips debug information from the binary; i can 'perf' m running dhrystone and send you the results if you are interested
bvt_away: perf is available in gentoo as dev-util/perf; may even build on out-of-sync gentoo
asciilifeform: bvt_away: grr, i think i forgot to comment out the strip
asciilifeform: bvt_away: http://p.bvulpes.com/pastes/UwSq0/?raw=true << do like-so.
asciilifeform: bvt_away: re perf -- confirmed that it dun build here.
asciilifeform: (and atm i lack the week or so that it'd prolly take to find why)
bvt_away: i fixed locally already, ty; just reporting to include it in future vpatch
bvt_away: myeah, iirc it does not build in cuntoo out-of-box as well; the tool is handy, but gnarly -- i keep it on antisanitary boxes myself
shinohai: ^ worx, I did `ebuild $(equery w dev-util/perf) fetch unpack` and commented out line in Makefile.
asciilifeform: shinohai, bvt_away : invited to paste output, if you have
asciilifeform: try 'perf' while thing runs the dhrystone etc
bvt_away: bvt-trace.net/src/perf.report bvt-trace.net/src/perf.annotate should it; recorded with 'dhrystone 10000000; halt'; can increase the workload size up to 60x if you consider the results inconclusive
bvt_away: *should be it
asciilifeform: ty bvt_away , will look
asciilifeform: hrm that dun seem to add up to 100% either
bvt_away: in annotate, the costs are per-function; in report, it's meaning to add only 'self' costs
asciilifeform: btw how long did this run on idle before/after dhrystone ? cuz in e.g.,:
asciilifeform: : Flg_Get Waiting ; CF := Waiting Flag
asciilifeform: 51.63 : 40103c: bt $0x2,%edi
asciilifeform: is the idler
bvt_away: i neither time the execution nor looked at the console while it was running, but up to 30 seconds
asciilifeform will brb
bvt_away: dhrystone did print the summary (i.e. considered the results meaningful)
bvt_away: i should perhaps add that 51.63 means that 'bt ETC, ETC' instruction carries 51,63% of the idler execution costs, not that 50% of total execution time was spent in exactly this instruction.
asciilifeform: bvt_away: ah
asciilifeform: bvt_away: still would like to get whole-proggy %'s (minus the slave threads, if possible) if you have idea how
bvt_away: if you look at the 'self' in the report, can see how many cycles were taken by each function; 'children' - cost of function+other functions it called; can use 'self' percentage to normalize the instruction cost in the 'annotate' output;
bvt_away: bvt-trace.net/src/dhrystone-1000000000.report bvt-trace.net/src/dhrystone-1000000000.annotate -- result of a longer run
bvt_away: typically work with perf happens through ncurses ui, so the textual report is a bit unwieldy
spyked: asciilifeform: re "perf" tool, oughta add to the http://btcbase.org/log/2019-07-25#1924804 disclaimer that it requires CONFIG_PERF_EVENTS kernel knob. in principle it's possible to write a measurement/profiling tool using just the calls exposed by the "perf_events" API (e.g. http://man7.org/linux/man-pages/man2/perf_event_open.2.html ), but never tried this myself, so it might be another rabbit hole.
bvt_away: spyked: perf_event_open is easy enough if you are interested only in the number of events (cache misses/cycles/etc.) that happened during a code segment execution (as shown in the manpage example); mmap-based interface - never used directly;
bvt_away: a snippet that i used some years ago: http://wotpaste.cascadianhacker.com/pastes/dIpjd/?raw=true
asciilifeform: bvt_away: ty! will look
asciilifeform: bvt_away: any idea why http://bvt-trace.net/src/dhrystone-1000000000.report doesn't (like last one) add up to 100% ?
bvt_away: tbh i dunno, could be thread-related; i'll redo the recording with per-thread event separation, then will see
asciilifeform: bvt_away: ty
asciilifeform: i also suspect -- thread related
asciilifeform: there are 3 threads ( main, and the clock & uart slaves ) , only the main thread is of interest
asciilifeform: the tricky bit is, if debugger doesn't suspend all 3 at once, clock will do weird things and the os might not even boot
bvt_away: actually, after messing for some time with perf, seems that it does sum up to ~100% : grep '\[\.\]' dhrystone-1000000000.report | cut -c '15-19' | sed -e 's/ //g' | awk 'BEGIN{a=0} {a+=$1} END{print a}'
bvt_away: grep selects top-level symbols, filtering out callees, cut selects 'self' col, sed cleans up whitespace, awk sums
asciilifeform: what are all the 'unknown' addrs ?
asciilifeform: e.g. 6.69% 0.00% m [unknown] [.] 0x0041414c00000000
asciilifeform: given as you built , presumably, with dwarf dbg symbols
bvt_away: those must be artifacts of stack-walking (observe zero 'self' cost, those addrs were never directly sampled, but recovered through unwinder)
asciilifeform: i admit, leave the q of 'where is the slow' quite open
bvt_away: can't really optimize anything without reading the source, so atm i can't help further
asciilifeform: aite.
asciilifeform: bvt , shinohai , et al : http://www.loper-os.org/?p=3440
asciilifeform: http://www.loper-os.org/?p=3440 << updated.

2019-6-30 | 2019-8-1