01:41 FROGGS_ joined 01:48 ilbot3 joined 03:41 jackc2 joined
FROGGS_ btw, nqp just works using debian++'s libatomoic_ops!! 04:28
04:30 vendethiel joined
nwc10 good **, FROGGS_ 04:51
FROGGS_ aye 04:57
(all tests pass) 04:58
which is a relief 05:08
now rakudo has to build, and I'm happy :o)
I've got a ppc64 machine now, but network isnt working yet... 05:10
05:16 vendethiel- joined 07:13 domidumont joined 07:18 domidumont joined 08:14 FROGGS joined
jnthn morning, #moarvm 09:03
nwc10 good *, jnthn 09:04
I guess you have fewer FROGGSlets than FROGGS does :-)
jnthn Indeed
nwc10 this morning we had a bonus alarm clock that was requesting Cherios from about 06:20 onwards
jnthn Also probably less capable of making coffee
nwc10 or was it 06:00
arnsholt Tadpoles, surely, not FROGGSlets? =)
nwc10 I forget
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
nwc10 bootstrapping problems again?
jnthn Indeed
arnsholt That's a particularly gnarly bootstrapping problem 09:06
jnthn
.oO( particularly granually )
 09:08
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
Both in inputs and execution, come to think of it
jnthn www.brendangregg.com/linuxperf.html is nice 09:50
timotimo quite 09:53
last night before bed i was playing around with having a probe in malloc again
but for some reason the report only showed addresses, not function names for the stack traces
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:56
jnthn Won't something like perf or callgrind be able to tell you all the top malloc callers? 09:57
timotimo yup 09:58
even with a read-out of the size parameter
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 09:59
jnthn Maybe we mark the function as a static inline or so 10:01
timotimo a stackoverflow post says i might have to give perf report a "-g dwarf" parameter 10:02
oh, i actually put a probe into libc, not into libmoar
okay, adding the probe to libmoar for "MVM_malloc size" also gives "sorry, we don't support this variable location yet." 10:06
it'd be helpful if it told what kind of variable location it's getting, but oh well 10:07
Too many( > 128) probe point found. 10:08
Failed to find symbol MVM_malloc in /home/timo/perl6/install/lib/libmoar.so
so much for our static inline :)
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:22
after that there's 0x2, 0x4, 0x1c, 0x6, 0x60, 0x68, 0x24, 0xa, 0x78, 0x2c 10:23
the last of those was 0.51%
this is for perl6 -e '' basically
jnthn m: say 0x18 10:24
camelia rakudo-moar 84b4c8: OUTPUTĀ«24ā¤Ā»
jnthn Hm, that could be many things :) 10:25
timotimo right, without a stack trace, it's not easy to say 10:26
oh, whoops :) 10:31
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
so, looks like too much data on the callstack 10:32
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)"
m: say (195984 * 8) / (1024 * 1024) 10:33
camelia rakudo-moar 84b4c8: OUTPUTĀ«1.495239ā¤Ā»
timotimo my system is now screaming about the full hard drive
moritz get a gag order for your system :-) 10:34
timotimo i have stacks now! i lost some data again, but oh well ... 10:37
gist.github.com/timo/7b985bbd50a93...3d8ad65887 10:39
i'm not sure what those symbols "deserialize" are about 10:43
impressive, we apparently call MVM_malloc with a size of 1 a few times even 10:55
nwc10 there was a reason that Devel::NYTProf got compressed file output *before* Test::Harness got refactored... 10:56
(even one profile file written out uncompressed was larger than my laptop's drive) 10:57
timotimo :D 10:59
arnsholt timotimo: malloc(1) sounds like the malloc(size_to_allocate > 0 ? size_to_allocate : 1) hack that is (was?) in CStruct 11:01
Come to think of it, that might be copied from P6opaque
timotimo haha, ugh :D 11:03
but i thought malloc(0) gives you a valid pointer?
or rather
arnsholt Nope
timotimo a pointer that is valid to call free on
arnsholt malloc(0) is undefined behaviour
=)
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
Given that there's nothing to allocate memory for, it should never be accessed either
timotimo doesn't crash on perl6 -e '' at least
11:18 cygx joined
cygx arnsholt: malloc(0) is implementation-defined, not undefined 11:18
it may return NULL or a valid pointer 11:19
either way, you're fine to call free() on it
arnsholt Oh, right
ISTR it causing a crash though
cygx at last, that's how it's supposed to work
*at least
arnsholt Hmm 11:20
I remember there being a good reason for this, but now that I reread the manpage I'm not sure anymore what it was
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:25
arnsholt Oh, maybe it's a MSVC-affordance? 11:27
That being C89, not C99
11:57 zakharyas joined 13:55 colomon joined 14:03 brrt joined
brrt good * #moarvm 14:40
15:21 FROGGS[mobile] joined
FROGGS[mobile] lol, building the setting only took 5.44 hours on my ppc64 qemu machine /o\ 15:22
diakopter o_O 15:31
FROGGS[mobile]: did the libatomicops patches help the other thing?
FROGGS[mobile] the debian lib (including said patches) makes moarvm work 15:34
dang, the timings before were for mips, not ppc64 15:35
diakopter: dunno what thing you are talking about
it fixes the nqp segfault I posted the other day 15:36
diakopter yes, that's the thing 15:37
FROGGS[mobile] then the answer is yes
diakopter oh, your mention of ppc64 instead of mips is what confused me
FROGGS[mobile] yeah, sorry for that 15:38
I keep loosing track of my machines
17:43 domidumont joined 18:27 FROGGS joined 19:48 brrt joined 20:25 dalek joined
timotimo i wonder if we should make the smallest bin for our fixedsize allocator 4 byte on an arch with 32bit pointers 20:55
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 20:56
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 21:56 colomon joined 22:16 colomon joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!