github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 11:21
pamplemousse \o 11:58
timotimo o/ 11:59
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2019/06/03/...e-a-given/ 15:20
pamplemousse Out of curiosity, is there anything in the compiler or maybe done during the configuration script that would store the endianness, the operating system, and the architecture of the system? If so, how can I access that information? If it's not being stored somewhere, I can definitely find it, but if there isn't a need to reinvent the wheel, I figure a solution that uses the already found information would be better. 15:33
jnthn pamplemousse: Yes; if the info you want is in `nqp --show-config` then it's available 15:36
jnthn I forget exactly how, but you can chase it down from how that option is implemented 15:36
pamplemousse jnthn: Thanks! I'll take a look at it. 15:37
pamplemousse Unfortunately, that info wasn't included in 'nqp --show-config' 17:45
pamplemousse I can find it another way though! Thank you again for the suggestion 18:06
patrickb o/ 20:23
Any chance to get M#1108 merged today?
synopsebot M#1108 [open]: github.com/MoarVM/MoarVM/pull/1108 Default to doing a non-relocatable build
lizmat patrickb: perhaps jnthn is still around 20:42
jnthn patrickb: Did the defaulting to a relocatable one appear in a release previously, ooc? 20:56
Left a comment on it also 20:58
I guess we even if that flag did appear in one release, it's not that likely much will have come to depend on it... 20:59
patrickb jnthn: There was a MoarVM release, but no Rakudo release. 21:15
That's why I'd like to get the change in before 2019.06, so we don't change the behavior in a rakudo release, where it really matters.
jnthn: Good point about the silent override. I changed the PR accordingly. 21:25
Geth MoarVM: b5172363be | (Patrick Böker)++ | Configure.pl
Default to doing a non-relocatable build

Non relocatability is the more common case with less caveats. Remove the --no-relocatable config, add --relocatable instead.
21:41
MoarVM: 5f29b094f0 | (Patrick Böker)++ | Configure.pl
Fail when being requested to do a relocatable build and we can't

That's the case on AIX and OpenBSD at the moment.
MoarVM: e865f43df0 | (Jonathan Worthington)++ (committed using GitHub Web editor) | Configure.pl
Merge pull request #1108 from patzim/no-no-reloc

Default to doing a non-relocatable build
patrickb Thanks!
travis-ci MoarVM build failed. Jonathan Worthington 'Merge pull request #1108 from patzim/no-no-reloc 21:53
travis-ci.org/MoarVM/MoarVM/builds/540964784 github.com/MoarVM/MoarVM/compare/c...65f43df0ae
MasterDuke timotimo: how much of an effect do you think removing the profiling overhead would have on the resulting profile? 22:42
timotimo the more very small routines there are, the stronger the effect would be, i guess 22:53
well, the very small routines would also have to be called a lot, of course 22:55
but tbh "identity" is by far the worst offender, and that ought to be fixed by spesh making it completely disappear and throwing out the enter/leave stuff as well 22:56
MasterDuke timotimo: yeah, i was expecting a big difference in identity, but i'm not seeing it (big difference) 23:00
did you look at the most recent patch? does it look reasonable?
timotimo "last active 2 days ago", that's the right one? 23:02
MasterDuke yep 23:04
timotimo what kinds of values do you get in the profiling overhead variable?
MasterDuke i think it was something like 170 23:05
timotimo that doesn't seem like much 23:10
that's not off by a thousand, is it?
i.e. microseconds vs milliseconds or something? 23:11
MasterDuke i don't think so. i do a thousand iterations, then divide the time they all took by a thousand 23:12
timotimo i wonder if the C compiler does any silly optimizations inside that loop 23:15
MasterDuke guess i could add an fprintf or something just to see if that makes a difference 23:18
timotimo well, it's allowed to reorder instructions across function boundaries i'd expect, after inlining, that is 23:19
how exactly do you check to see if it made a difference? 23:20
MasterDuke if the number is much much higher?
timotimo what number?
MasterDuke overhead
timotimo oh, i was refering to the whole thing, not just the e - s part 23:21
like, in the final profile
MasterDuke oh, what in the final profile?
timotimo yeah 23:22
MasterDuke ah, you mean how exactly do i see if removing the overhead makes a difference? 23:23
timotimo that's it
MasterDuke i was just eyeballing it. nothing seemed to change much. identity in particular had a pretty similar number
i don't know of a way to get deterministic profiling results 23:24
timotimo ok, so looking at the routines list to see if its inclusive/exclusive times change
MasterDuke hm...maybe if i did a profile while running under callgrind it would be more deterministic?
yeah
huh, the profiles under callgrind are vastly different 23:32
but not in any way that makes sense 23:33
timotimo may be a good idea to turn spesh off or at least set it to blocking
since valgrind emulates a single-core cpu
MasterDuke yeah, just realized i forgot to do that
now not so wildly different, in fact, not very different at all... 23:37
timotimo: hm, should i really be leaving this else branch untouched? github.com/MoarVM/MoarVM/blob/mast...#L411-L414 23:42
making it `box_i(tcpds->tc, (pcn->total_time - (pcn->total_entries * tcpds->tc->instance->profiling_overhead)) / 1000));` puts some crazy numbers in the exclusive column (identity is 368934881474152.5ms for instance) 23:44
timotimo that'd be an underflow 23:48
identity wouldn't have any successors
but the time spent doing enter and exit isn't 100% on the caller or the callee side
MasterDuke hm, so what should i do instead? 23:50