github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth MoarVM/postrelease-opts: 6c6e568451 | (Jonathan Worthington)++ | 6 files
Get specialized bigint ops using the int cache

Thus regaining the performance in some programs the depend heavily on that.		 00:00
jnthn sleep & 00:03
Geth MoarVM: jstuder-gh++ created pull request #945:
Workaround version failure on Travis CI (MacOS)		 02:18
Geth MoarVM: jstuder-gh++ created pull request #946:
A few more exprjit templates (08/14/18)		 05:10
samcv good * 09:08
jnthn o/ 09:17
nwc10 good * samcv, jnthn, lurkers and bots 09:18
samcv waves to the bots o/
masak .oO( haters and losers ) 09:20
sorry, didn't mean to trump the whole discussion
good localtime, #moarvm 09:21
nwc10 is that previous line a political pun, or am I reading into it?
masak nwc10: not reading into it. "haters and losers" is from a tweet somewhere. 09:21
nwc10 ah OK. Not a reference to a prominent twitter user
masak yes, that too
my brain just pattern-matched "lurkers and bots", and again I'm so sorry 09:22
nwc10 I'm not sure how we patch your brain. 09:24
DOS is relatively easy (but probably cheaper in Estonia or Germany than Sweden) but only lasts until the hangover goes. 09:25
jnthn Damn, my JIT patch last night is a loser... 09:27
nwc10 try coffee instead of beer?
jnthn That's pretty much "try morning instead of evening" :P
oh lol, TMP4d ain't caller save, is it... 09:28
nwc10 (fresh head)++
masak be sure to keep three spare heads, and to rotate at least every quarter to even out the wear and tear 09:30
nwc10 gah. One can't get to www.perlfoundation.org/perl-6-deve...-fund.html without JS 09:34
Geth MoarVM/postrelease-opts: 2ca38292f5 | (Jonathan Worthington)++ | src/jit/x64/emit.dasc
TMP4d is callee save, so save it during call
 09:37
samcv now to work on release. somehow my update changelog helper is broken 09:40
can't generate NQP anymore.
in sub get-log at ./tools/update-changelog.p6 line 32
ah. i was going crazy looking for that text in my script. i think it's from the git log 09:41
jnthn That's better. Now for initializing a million element array with 0s and then going over it 10 times doing ++ on each element, we're a shade over 1s
samcv: I think there's still one regression to hunt before we can actually release, fwiw
I'll try and get to it later today, though I'm really meant to be doing something else right now rather than playing with the JIT :P
samcv yeah. i wanted to at least get my changelog script working though :)
jnthn Yes :-) 09:42
dogbert2 is that the Audio::Sndfile SEGV regression?
yoleaux 13 Aug 2018 22:48Z <AlexDaniel> dogbert2: GH#2210
17 Aug 2018 00:30Z <AlexDaniel> dogbert2: commit title could've been better here: github.com/rakudo/rakudo/commit/8f807fc4
17 Aug 2018 00:32Z <AlexDaniel> dogbert2: especially given that there are two commits with the same title :) github.com/rakudo/rakudo/commit/ecd899c9
dogbert2 oops
jnthn Ah, and for perspective, Python does the same benchmark in 0.8362, so I "only" need to find another 30% or so to win... :P 09:43
(Perl 5 manages to win it by rather more, alas)
samcv though i really need to throw out my script. since it's horrible 09:44
samcv checks for perl 6 modules that can get me the log in a non-hacky way
well i found this gist.github.com/textarcana/1306223 09:46
brrt \o 11:00
timotimo o/ 12:32
timotimo hey brrt, apart from /tmp/pid.map for perf, what do we have to do so that gdb can just "disassemble" frames the jit made? 12:34
at the moment is complains there's no symbol or something
pmurias I get a src/moar.h:23:10: fatal error: atomic_ops.h: No such file or directory 12:38
yoleaux 06:33Z <nine> pmurias: just waiting for after release
pmurias error when trying to build MoarVM from source
timotimo did the submodule checkout break? 12:39
jnthn I though Configure updated those, or at least tries 12:41
timotimo it tries, yes
not sure how it handles failure
jnthn iirc, it mentions it but continues to produce the makefile
timotimo it's kind of annoying that there isn't a generally accepted primitive for "output this as an initial problem that gets automatically repeated at the very end" 12:42
i did gentoo beginner support for a long while and the number of occurences where people pasted only the very last line of package compilation, which was usually "make: Errors: 1" was a little infuriating 12:43
brrt timotimo: a lot 12:58
(re: how-much-work-for-gdb-support) 12:59
timotimo damn it :( 13:00
brrt well, last I checked
timotimo and i assume making "up" work properly, at least allowing you to get back to the interpreter, is also a hairy business?
brrt may be easier, actually
Hmmm
let me check for a second 13:01
check this out:sourceware.org/gdb/current/onlined...-Interface 13:06
ah, I see what the problem is 13:07
gdb requires that you write a complete object file
with debugging information
(in memory, but still...) 13:08
timotimo i think it'd be fine to implement that well-known-symbol function and after-the-fact, i.e. when the user manually calls something specific, like create-jit-symbols, we'd call that function a bunch to register everything 13:09
so we don't have to pay for this all the time
hm, since it's a linked list, why not make the node for the linked lists just be a part of the JitCode struct 13:13
timotimo oh, we'd have to generate a full object file, eh? :\ 13:19
not sure what that entails
Generating debug information in platform-native file formats (like ELF or COFF) may be an overkill for JIT compilers; especially if all the debug info is used for is displaying a meaningful backtrace. The issue can be resolved by having the JIT writers decide on a debug info format and also provide a reader that parses the debug info generated by the JIT compiler.
well isn't that convenient! 13:20
BBIAB
brrt that could potentially make things cheaper, yes 13:26
timotimo well, don't make it a priority just because i asked for it 14:11
there's lots more interesting bits and bobs to work on :) 14:12
i ran pahole over libmoar.so again and there isn't really significant savings any more
MVMInstance could save 32 bytes, but why bother when there's only one
MVMThreadContext would have 24 bytes to save, but there's only few of those in programs normally 14:13
so better to have the class definition in an order that makes sense
MVMSpeshGraph, MVMSpeshCandidate, MVMStaticFrameBody, MVMDebugServerData, MVMNormalizer, MVMCArrayREPRData, and MVMJitInvoke could all save 8 bytes 14:14
jnthn MVMStaticFrameBody would be probably worth it
timotimo but as long as a bare rakudo-m starts at 80 megs, we have bigger fish to fry perhaps
jnthn There can be rather a lot of MVMStaticFrame :)
timotimo let me have a look what reordering would look like
jnthn As for the rest, yeah, I agree, not much worth it 14:15
timotimo gist.github.com/timo/006fa069d16c9...f35e4cb3bf
nine Quite a lot of MVMStaticFrameBody's fields are just flags 14:18
timotimo you mean has_state_vars could become a uint8, too? 14:18
nine Oh, that, too. But maybe moving a lot of those uint8's into a "flags" field might be worth a shot? 14:21
timotimo perhaps
making has_state_vars a uint8 gets us to "saved 16 bytes!"
let me see about flags fields
so 208 size instead of what it could have become before: 216 or so? 14:22
looks like even with 1 bit wide flags it won't save more space 14:23
timotimo 8 bits per flag: 14:25
/* sum members: 207, holes: 1, sum holes: 1 */
1 bit per flag:
/* sum members: 202, holes: 2, sum holes: 6 */
can be worth it when another flag gets added i suppose 14:26
nwc10 if you can get from 202 to 200 that's 1 fewer cache lines
(I think)
nine The 1 bit per flag thing was a "MVMuint64 flags;"? 14:29
timotimo no, it was using the :1 syntax
/* size: 208, cachelines: 4, members: 37 */
/* sum members: 207, holes: 1, sum holes: 1 */
/* last cacheline: 16 bytes */
so it looks like we'd have to lose 16 bytes to get to 3 cache lines
nwc10 :-( 14:30
its maths is better than mine
:2, :3 etc are also "available" if there are other fields that are small
but this is micro-optimising
timotimo i prefered your maths
nwc10 so might really not be worth thinking
unless there are structures that we make an awful lot of 14:31
and we've run out of other fun stuff do to
timotimo a little more important than cache line sizes is size in our gen2, since we have size buckets that can have a bit of wasted space at the end
nwc10 and we aren't going to meet jnthn at a conference any time soon :-)
timotimo oh 14:32
also, there's the MVMCollectable header in front of the MVMStaticFrameBody
nwc10 but the gen2 comment likely is relevant
timotimo /* size: 232, cachelines: 4, members: 2 */
/* last cacheline: 40 bytes */
timotimo object header's 24 bytes big 14:32
nwc10 IIRC there was a bunch of fun with that one and getting the alignment assumptions "right" for x86_64, i386 and ARM 14:33
timotimo i think the problem is in the nursery, not the gen2?
nwc10 (and possibly onwards from that to other architectures, but those 3 were the 3 that I knew that I fought with) 14:34
timotimo the one i mean was for doubles
jnthn nwc10: Anyone coming to the Swiss Perl Workshop in Bern this year gets to meet me :) 14:36
Geth MoarVM/postrelease-opts: da8bd3d1c0 | (Timo Paulssen)++ | src/6model/reprs/MVMStaticFrame.h
save 16 bytes in MVMStaticFrameBody according to pahole
 14:37
jnthn It's just the Wein - Zurich night train + a 1 hour ride + a 15 minute walk away ;) 14:38
uh, *Wien :)
timotimo no reason to wein about that :) 14:39
nwc10 act.perl-workshop.ch/spw2018/talk/7460 act.perl-workshop.ch/spw2018/talk/7462 14:40
jnthn Those're the ones
Might do a lightning talk with some benchmark results too, if they're looking nice enough... :)
timotimo hum, i haven't prepared anything for bern, not sure if i'll go actually 14:41
jnthn Hmm, I think my travel to Switzerland actually goes through or close to where you are :) 14:43
Though I've work there before the conf, so going nearly a week before it
timotimo oh, interesting :)
nine Would love to attend but I'm at a seminar on the 7th, all day :( 14:44
pmurias nine: I'm working on adding a nqp::decodelocaltime op to all the backends to remove the native call to libc 15:02
timotimo not a problem, though. the QAST compiler can just emit the native call as a desugar on moarvm 15:06
pmurias timotimo: are native calls easily done as desugars? 15:08
nine What's the problem with the native call? 15:11
pmurias nine: it's not portable 15:13
it assumes we are running on something that has callable libc symbols underneath 15:15
timotimo hm, actually 15:19
since desugars are set up from nqp code, you can't just "is native" that
pmurias hmm, what could be wrong with this op: paste.debian.net/1038770/ 15:21
defined as "decodelocaltime w(obj) r(int64)" 15:22
timotimo i think the MVMROOT isn't necessary 15:24
pmurias could it be causing decodelocaltime returning a nqp::null? 15:27
timotimo shouldn't, all object registers are already rooted 15:29
and decodelocaltime doesn't do any allocation right?
what kind of problem do you see?
jnthn GET_REG(tc, 0).o = result; 15:30
That's reading...uh...I have no idea
Should be GET_REG(cur_op, 0).o = result
Ditto a line or so down
timotimo ooh! 15:31
haha
how did i not realize that
jnthn I read it like 4 times before I spotted it :P
pmurias jnthn: thanks a lot 15:32
Geth MoarVM: pmurias++ created pull request #947:
Add decodelocaltime op		 16:04
pmurias I have made a PR to add the decodelocaltime op to MoarVM 16:05
I'm not sure how we can test it
pmurias is it possible to tell anything what thee localtime should be without knowing the locale? 16:29
nine decodelocaltime's sole usage is in finding out what time zone offset local time has. Is the way rakudo does it really the simplest way? 16:38
geekosaur there are very few simple ways that work for all timezones 16:39
nine The whole "let the C lib assemble a structure with date and time fields which we then use to create a full DateTime object which we then turn back into a single number to do create an Instance object to do calculations with" just seems absurd
brrt 'JIT readers would need to be emitted under a GPL license' there's the end of that idea 16:41
geekosaur if you want to guarantee compatibility with C and/or take advantage of existing update mechanisms instead of having to make your own, there's not a lot to be elided there 16:42
especially since most of the shortcuts do things like assume that the offsets are fixed or are on hour boundaries or etc
and, well, no.
nine At the very least, we could cut out a lot of Perl 6 machinery and just have an op that returns the offset 16:45
Javascript seems to have a getTimezoneOffset() method, so that would at least be trivial to implement there :D 16:48
robertle does anything really assume offsets are on one-hour boundaries? would be surprising given that there are actual timezones that are not, e.g. IST 16:51
nine robertle: yes, there's broken code out there, indeed: www.linuxquestions.org/questions/p...ost5051857 16:53
Oh: According to POSIX.1-2004, localtime() is required to behave as though tzset() was called, while localtime_r() does not have this requirement. For portable code tzset() should be called before localtime_r() 16:56
geekosaur robertle, look for "falsehoods people believe about time" 16:58
which is more or less a compendium of such assumptions found in real code, including commercial applications
robertle oh my 17:06
pmurias didn't north korea have a half-hour timezone difference in the past 17:10
brrt: which idea ends that way? 17:13
pmurias brrt: if you want to write a jit reader for gdb doesn't it have to be GPL compatible, rather then GPLed? 17:34
masak does the static compiler replace lexical lookups to things in the setting with just a direct access to a memory location? 18:28
oh; I guess since those are exclusively reads, they could even be replaced by the value itself 18:30
timotimo masak: i believe the static compiler just emits a getlexstatic and the dynamic optimizer substitutes the value in when it gets speshed? 18:34
masak timotimo: ah, ok -- so not until spesh. 19:31
timotimo you could probably find out with --stage=optimize, does it have a QAST::WVal where you expected the thing? 19:37
i think for calls we have "callstatic" if we believe it's from the core setting or otherwise for some reason good to get 19:38
timotimo though of course it could make a difference in the QASTOperationsMAST or *Compiler* 19:39
timotimo i.e. be a desugar to something simple 19:39
pmurias nine: re seems absurd isn't the calculation itself straightforward? 19:44
pmurias nine: the way it's done is complicated but almost anything in Perl 6 is super absurd if you thing how it's really done 19:45
timotimo ... but then we compile it down to a single assembly instruction and it's no longer so absurd %) 19:46
pmurias timotimo: we do the timezone calculation once so the way it's done doesn't really matter 19:51
pmurias ;) 19:51
timotimo we do want rakudo to start up faster, though 19:52
timotimo so maybe not do it with a network request for example 19:52
Geth MoarVM: 919e78ab1b | (Jonathan Worthington)++ | 7 files
Fix race in setting the type debug name

As part of that, add a "free at safepoint" mechanism to help with solving similar problems we might encounter in the future.		 22:46
travis-ci MoarVM build failed. Jonathan Worthington 'Fix race in setting the type debug name 23:06
travis-ci.org/MoarVM/MoarVM/builds/418929070 github.com/MoarVM/MoarVM/compare/0...9e78ab1b36

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!