github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:39 sena_kun left 00:54 ggoebel joined 04:03 ggoebel left 04:42 MasterDuke left 05:14 robertle left 05:44 domidumont joined 05:50 domidumont left 06:18 patrickb joined 06:23 domidumont joined 07:36 Woodi left, Woodi joined 07:41 nativecallable6 left, undersightable6 left, releasable6 left, reportable6 left, yoleaux left 07:45 Geth left 07:46 Geth joined 07:47 kawaii left, eater left 07:50 Geth left 07:51 Geth joined 07:52 kawaii joined, eater joined 07:53 nativecallable6 joined, releasable6 joined, undersightable6 joined, reportable6 joined, yoleaux joined 08:54 BinGOs left 09:05 BinGOs joined 10:22 zakharyas joined, domidumont left
nwc10 good *, #moarvm 11:21
11:32 zakharyas left 11:57 pamplemousse joined
pamplemousse \o 11:58
timotimo o/ 11:59
12:20 domidumont joined 12:25 domidumont1 joined 12:28 domidumont left 12:34 domidumont joined 12:37 domidumont1 left 12:42 kawaii left 12:45 kawaii joined 12:50 patrickb left 12:52 patrickb joined 13:00 patrickb left 13:08 patrickb joined 14:06 sena_kun joined 14:17 patrickb left 14:21 harrow joined 14:35 pamplemousse left 15:00 pamplemousse joined
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
15:36 robertle_ left
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
17:07 robertle joined 17:22 pamplemousse_ joined 17:25 pamplemousse left 17:41 domidumont left 17:44 pamplemousse_ is now known as pamplemousse
pamplemousse Unfortunately, that info wasn't included in 'nqp --show-config' 17:45
18:04 AlexDaniel joined
pamplemousse I can find it another way though! Thank you again for the suggestion 18:06
20:15 nativecallable6 left, undersightable6 left, releasable6 left, reportable6 left, yoleaux left 20:22 patrickb joined
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
20:46 patrickb left 20:53 patrickb joined
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
21:00 patrickb left 21:01 pamplemousse left 21:02 pamplemousse joined 21:06 nativecallable6 joined, pamplemousse left 21:07 pamplemousse joined 21:08 reportable6 joined, releasable6 joined 21:09 undersightable6 joined 21:14 patrickb joined
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
21:29 pamplemousse left
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!
21:53 travis-ci joined
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
21:53 travis-ci left 22:04 yoleaux joined 22:29 MasterDuke joined, MasterDuke left, MasterDuke joined
MasterDuke timotimo: how much of an effect do you think removing the profiling overhead would have on the resulting profile? 22:42
22:52 patrickb left
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
23:56 sena_kun left

Powered by Cro and the Raku® Programming Language.

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

Thank you!