Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-10-25

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:41 FROGGS_ joined #moarvm
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:41 jackc2 joined #moarvm
04:28 FROGGS_ btw, nqp just works using debian++'s libatomoic_ops!!
04:30 vendethiel joined #moarvm
04:51 nwc10 good **, FROGGS_
04:57 FROGGS_ aye
04:58 FROGGS_ (all tests pass)
05:08 FROGGS_ which is a relief
05:08 FROGGS_ now rakudo has to build, and I'm happy :o)
05:10 FROGGS_ I've got a ppc64 machine now, but network isnt working yet...
05:16 vendethiel- joined #moarvm
07:13 domidumont joined #moarvm
07:18 domidumont joined #moarvm
08:14 FROGGS joined #moarvm
09:03 jnthn morning, #moarvm
09:04 nwc10 good *, jnthn
09:04 nwc10 I guess you have fewer FROGGSlets than FROGGS does :-)
09:04 jnthn Indeed
09:04 nwc10 this morning we had a bonus alarm clock that was requesting Cherios from about 06:20 onwards
09:04 jnthn Also probably less capable of making coffee
09:04 nwc10 or was it 06:00
09:04 arnsholt Tadpoles, surely, not FROGGSlets? =)
09:04 nwc10 I forget
09:05 arnsholt Those twenty minutes make little difference, in my recent experience =)
09:05 * jnthn only managed to get half the spoon of ground coffee into the machine's basket
09:05 nwc10 bootstrapping problems again?
09:05 jnthn Indeed
09:06 arnsholt That's a particularly gnarly bootstrapping problem
09:08 jnthn .oO( particularly granually )
09:11 arnsholt Point. In that case, I guess using a French press is better than an espresso machine, seeing how it lets you use a much coarser-grained approach
09:11 arnsholt Both in inputs and execution, come to think of it
09:50 jnthn http://www.brendangregg.com/linuxperf.html is nice
09:53 timotimo quite
09:53 timotimo last night before bed i was playing around with having a probe in malloc again
09:53 timotimo but for some reason the report only showed addresses, not function names for the stack traces
09:56 timotimo at first i tried running the whole recording thing with sudo (so i didn't have to attach it to a running process) and i thought that was the reason for missing symbols, but it turned out even when i gave every user on my system (that's not dangerous at all!) permission to use the debug/tracing stuff it still wouldn't show
09:57 jnthn Won't something like perf or callgrind be able to tell you all the top malloc callers?
09:58 timotimo yup
09:58 timotimo even with a read-out of the size parameter
09:59 timotimo you can insert a trace point into any library and output any parameters you like - in this case i had to use the name of the register that the calling convention would associate with the parameter i wanted because for some reason the name wasn't in there
10:01 jnthn Maybe we mark the function as a static inline or so
10:02 timotimo a stackoverflow post says i might have to give perf report a "-g dwarf" parameter
10:02 timotimo oh, i actually put a probe into libc, not into libmoar
10:06 timotimo okay, adding the probe to libmoar for "MVM_malloc size" also gives "sorry, we don't support this variable location yet."
10:07 timotimo it'd be helpful if it told what kind of variable location it's getting, but oh well
10:08 timotimo Too many( > 128) probe point found.
10:08 timotimo Failed to find symbol MVM_malloc in /home/timo/perl6/install/lib/libmoar.so
10:08 timotimo so much for our static inline :)
10:22 timotimo in any case, the malloc results are: 29.3% size=0x18, 9.19% size=0x8, 8.7% size=0x10, 8.3% size=0x30, 5.91% 0x28, 4.04% size=0x38, 3.77% 0x40, 3.11% 0x20, 2.42% 0xc
10:23 timotimo after that there's 0x2, 0x4, 0x1c, 0x6, 0x60, 0x68, 0x24, 0xa, 0x78, 0x2c
10:23 timotimo the last of those was 0.51%
10:23 timotimo this is for perl6 -e '' basically
10:24 jnthn m: say 0x18
10:24 camelia rakudo-moar 84b4c8: OUTPUT«24␤»
10:25 jnthn Hm, that could be many things :)
10:26 timotimo right, without a stack trace, it's not easy to say
10:31 timotimo oh, whoops :)
10:31 timotimo seems like --call-graph dwarf is the flag you actually have to use, but now it's saying it lost "10 chunks" when processing the events
10:32 timotimo so, looks like too much data on the callstack
10:32 timotimo given it "processed 195984 events" that could be a lot. record_size is described as "if record_mode is 'dwarf', max size of stack recording (<bytes>) default: 8192 (bytes)"
10:33 timotimo m: say (195984 * 8) / (1024 * 1024)
10:33 camelia rakudo-moar 84b4c8: OUTPUT«1.495239␤»
10:33 timotimo my system is now screaming about the full hard drive
10:34 moritz get a gag order for your system :-)
10:37 timotimo i have stacks now! i lost some data again, but oh well ...
10:39 timotimo https://gist.github.com/timo/7b985bbd50a93da38e4a633d8ad65887
10:43 timotimo i'm not sure what those symbols "deserialize" are about
10:55 timotimo impressive, we apparently call MVM_malloc with a size of 1 a few times even
10:56 nwc10 there was a reason that Devel::NYTProf got compressed file output *before* Test::Harness got refactored...
10:57 nwc10 (even one profile file written out uncompressed was larger than my laptop's drive)
10:59 timotimo :D
11:01 arnsholt timotimo: malloc(1) sounds like the malloc(size_to_allocate > 0 ? size_to_allocate : 1) hack that is (was?) in CStruct
11:01 arnsholt Come to think of it, that might be copied from P6opaque
11:03 timotimo haha, ugh :D
11:03 timotimo but i thought malloc(0) gives you a valid pointer?
11:03 timotimo or rather
11:03 arnsholt Nope
11:03 timotimo a pointer that is valid to call free on
11:03 arnsholt malloc(0) is undefined behaviour
11:03 arnsholt =)
11:05 arnsholt If it's purely MoarVM-internal, it might be possible to replace it with size_to_allocate > 0 ? malloc(size_to_allocate) : NULL
11:05 arnsholt Given that there's nothing to allocate memory for, it should never be accessed either
11:05 timotimo doesn't crash on perl6 -e '' at least
11:18 cygx joined #moarvm
11:18 cygx arnsholt: malloc(0) is implementation-defined, not undefined
11:19 cygx it may return NULL or a valid pointer
11:19 cygx either way, you're fine to call free() on it
11:19 arnsholt Oh, right
11:19 arnsholt ISTR it causing a crash though
11:19 cygx at last, that's how it's supposed to work
11:19 cygx *at least
11:20 arnsholt Hmm
11:20 arnsholt I remember there being a good reason for this, but now that I reread the manpage I'm not sure anymore what it was
11:25 cygx well, according to the C99 rationale, not that good a reason (a combination of existing practice/implementation and the decision not to introduce zero-length objects for this purpose alone)
11:27 arnsholt Oh, maybe it's a MSVC-affordance?
11:27 arnsholt That being C89, not C99
11:57 zakharyas joined #moarvm
13:55 colomon joined #moarvm
14:03 brrt joined #moarvm
14:40 brrt good * #moarvm
15:21 FROGGS[mobile] joined #moarvm
15:22 FROGGS[mobile] lol, building the setting only took 5.44 hours on my ppc64 qemu machine /o\
15:31 diakopter o_O
15:31 diakopter FROGGS[mobile]: did the libatomicops patches help the other thing?
15:34 FROGGS[mobile] the debian lib (including said patches) makes moarvm work
15:35 FROGGS[mobile] dang, the timings before were for mips, not ppc64
15:35 FROGGS[mobile] diakopter: dunno what thing you are talking about
15:36 FROGGS[mobile] it fixes the nqp segfault I posted the other day
15:37 diakopter yes, that's the thing
15:37 FROGGS[mobile] then the answer is yes
15:37 diakopter oh, your mention of ppc64 instead of mips is what confused me
15:38 FROGGS[mobile] yeah, sorry for that
15:38 FROGGS[mobile] I keep loosing track of my machines
17:43 domidumont joined #moarvm
18:27 FROGGS joined #moarvm
19:48 brrt joined #moarvm
20:25 dalek joined #moarvm
20:55 timotimo i wonder if we should make the smallest bin for our fixedsize allocator 4 byte on an arch with 32bit pointers
20:56 timotimo as far as i can tell the biggest reason to have the smallest bin 8 bytes big is that it has to fit a pointer for the free list to work
21:16 FROGGS .tell nebuchadnezzar nqp and rakudo pass their tests on mips64el, it just takes ages to build and test
21:16 yoleaux2 FROGGS: I'll pass your message to nebuchadnezzar.
21:38 colomon_ joined #moarvm
21:56 colomon joined #moarvm
22:16 colomon joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary