01:10 FROGGS__ joined 02:53 btyler joined
TimToady rosettacode.org/wiki/Category:Perl_6 seems to be leaking at a rate of about 75Mb per minute 04:21
(I changed the ^6 to ^7 to try to find the 7th number, but it's already used 4 gigs of ram in about 50 minutes of runtime 04:22
oops
lue TimToady: did you mean a specific problem? Or are you referring to the rate at which problems are solved for Perl 6? :) 04:23
TimToady rosettacode.org/wiki/Find_palindrom...ses#Perl_6
the resident set is also going up to the same vicinity, which might indicate the GC is revisiting most of the pages 04:27
or maybe it just means I have too much memory :)
ventica_desktop moar backend? 04:28
TimToady yup 04:29
it's actually paging other stuff out, so I think it's probably all being visited 04:30
starting to swap out X windows, so I'm killing it after an hour 04:32
er, 75MB per minute, not Mb :) 04:33
lue realizes he should probably get to know the more sysadminy parts of his system sometime :) 04:34
TimToady so about 1Ā¼ megs per second
actually, in the early stages, it goes up by about 3 megs a second 04:40
that's without a gather/take too
04:48 woolfy joined
TimToady okay, loop { .base(3) } does not leak 04:48
.base(3) for 1..* leaks about 6 megs a second 04:49
04:49 lizmat joined
TimToady 42 for 1..*; # leaks 7 megs a second 04:51
something's obviously not throwing away the used numbers, or something like that 04:52
lizmat # ore like 9 megs / sec for me 04:53
*more
TimToady does not leak on jvm 04:54
lizmat for 1..* { } also leaks
TimToady though jvm starts with 3.5gig :)
yes, the original loop was in that form, and all the stuff inside just served to hide the leak :) 04:55
lizmat FWIW, I seem the same kind of leakage on parrot 04:56
TimToady maybe jvm just hides it by allocating a gig of GC to start with... 04:57
lizmat I wouldn't be surprise
d
lue Right now I'm using 17.9% percent of my ram on ^7, and climbing (I don't know which of the VIRT, RES, or SHR memory counts are relevant here) 05:01
lizmat is exhausted and will probably go to bed soon 05:02
TimToady VIRT mostly 05:07
RES is how much of VIRT is actually resident and presumably active, at least under load 05:08
lue 897M is what htop's telling me right now
TimToady at 17.9% it might not care
took me 50 minutes or so to get up to 4 gig 05:09
lue 4GiB is how much RAM I have at all :P 05:10
TimToady then I'd suggest you not run it quite that far :)
it won't find the 7th in 4 gigs
TimToady is currently running the jvm version to see if it leaks before finding the 7th 05:11
lue yeah, it's never a fun time when the kernel steps in to kill things.
TimToady my jvm's VIRT is nailed to 3482060 for most of the last hour, and hasn't budged 05:12
RES on the jvm is creeping up at about 2 meg a minute; dunno if that means anything 05:27
ventica ok... so looking for guidance on Async IO testing/bugs/code-clean up (this was suggested as a good place to begin contributing)... are there bug reports I should go read? 06:36
Async Socket* IO
06:55 zakharyas joined 06:57 brrt joined 07:04 ventica joined 07:06 ventica_desktop joined
brrt \o 07:16
sergot o/ 07:25
07:26 Ven joined
brrt figured out that it was much simpler to install the mingw32-w64 toolchain than to install a windows vm 07:33
and it is, but the answers are confusing 07:36
07:39 FROGGS joined
brrt it seems mingw64 compiles the full 8 bytes of stack space for every argument, even though they are 32 bits wide 07:53
moritz alignment :-) 07:58
brrt (obviously, posix isn't quite so friendly as it does take the argument size into account) 08:00
ventica_desktop which windows vm? 08:03
brrt any, i guess? 08:14
i can download a trial version of windows 8 or 7
and install this on a vm, but it's just work, you know
and i'm lazy :-)
ventica_desktop :P 08:17
brrt it seems i do the win64 ABI completely wrong 08:19
or, mostly wrong 08:22
moritz that explains the blowups :-)
brrt well, yes 08:23
the rules are a bit more arcane than i had imagined
jnthn heh, so it wasn't a bastion of sanity over the posix one, after all? :) 08:27
I use the MSVC compiler, fwiw. I think you can install Visual Studio Express for C++ to get the toolchain.
ventica_desktop shudders at the thought of MSVC 08:28
jnthn wonders what particular aspect of it causes the shudders 08:29
FROGGS yes, the express does work well, I use that too 08:30
you just have to register at some point me thinks
ventica_desktop jnthn: I guess it's more the whole dll hell thing when you get to linking... the compiler itself generates tight code but compatibility in the windows world is such a headache 08:31
or maybe interoperability is a better word than compatibility 08:32
moritz finds the whole PIC / non-PIC approach of DLLs interesting 08:33
jnthn Perhaps that's why with .Net they went more with the "just copy all the things" approach :)
FROGGS I love how you can compile something on your system, just zip it and ship, and it will work on any other windows system...
ventica_desktop lol
FROGGS try to do that on linux, I've got a debian 3 (!!) here for such things 08:34
jnthn ventica_desktop: Did you manage to dig into the async code at all?
ventica_desktop I looked through the asyncsocket.c (sp?) file, but it's pretty incomprehensible... watched a prez on libuv 08:35
brrt calling conventions are never sane
brrt is now downloading windows 8.1 trial
ventica_desktop incomprehensible *to me* (ramp and all that)
jnthn: After running the tests on my box and they passed, my question was if there's a specific place I need to be looking? 08:36
jnthn Well, the async socket ones only seem to fail under load... :( Typical of race-y issues, I guess. 08:37
ventica_desktop who wrote it? 08:38
the async socket code
jnthn Me
brrt bbi2h
jnthn Doesn't mean the race is obvious to me, though, otherwise I'd have fixed it by now. :) 08:39
ventica_desktop what are the kinds of I/O that asyncsocket.c is responsible for? sockets can connect lots of kinds of things and i can see that there are other files responsible for different kinds of I/O... 08:40
under /src/io that is
jnthn At the moment, asyncsocket.c is just about providing TCP sockets (client and server)
Should really teach it UDP also.
ventica_desktop ok 08:41
and i see the tests are exercising the localhost has the code ever been tested on remote connections?
jnthn Well, when I first wrote it I had it doing non-local web requests at lest. 08:42
*least
ventica_desktop ok, cool
jnthn (And that worked out fine.)
errand; back in 10 mins 08:43
jnthn back 08:55
10:47 Ven joined 11:44 brrt joined
brrt i've looked at the actual calling behaviour of win64, and conclude that the problem is more subtle than it appeared 11:49
also, more generic
to be specific, when i call a function and push parameters on the stack, i don't 'unpush' them, i.e. the stack top keeps on growing
the function epilogue doesn't take this into account
jnthn Oh... 11:50
Well, glad you're figuring it out :)
moritz so, it's not a stack? :-) 11:51
brrt it is a stack
it's... complicated 11:52
it's a good subject for a blog post, too
FROGGS brrt: I'm already leaning back with a coffee in my hand :o) 11:53
brrt know what, i'll just blog about it
:-)
FROGGS :o) 11:54
brrt++
brrt bbiab 12:36
12:53 brrt joined 13:02 jnap joined 13:47 jnap joined 14:04 brrt joined 14:19 jnap joined 14:49 lizmat joined
TimToady jnthn: opinions on our memory leak we noticed last night? 15:06
jnthn TimToady: If it's happening in Parrot *and* MoarVM, my first suspicion would fall on something being held onto for too long somewhere in, perhaps, MapIter 15:08
TimToady but isn't that a case that you optimize away from MapIter? 15:10
jnthn 1..1000000 is 15:12
1..* isn't
It actually uses a native int, so it's bounds-checking the upper bound to fit within that at present. 15:13
15:13 btyler joined
brrt shameless blog plug: brrt-to-the-future.blogspot.nl/2014...-abis.html 15:16
also, apparantly i'm going on a short holiday for the next 4 days, so i'll be afk until tuesday late
(starting tomorrow :-))
jnthn brrt++ # blog post 15:22
Do you expect to get any progress on the Windows JIT explosion today, before leaving?
[Coke] brrt++ 15:23
jnthn On extops - I'm planning to take a look at them this evening to see if I can make things a little easier
brrt ok, nice :-) 15:30
TimToady read abis as 'alibis'
brrt i hope so, but i'm not sure, it's a big change (wrt windows jit explosion)
what the heart is full of 15:31
also, wrt to extops, i planned to change the 'invokish' field into something like 'jittitude' or 'jittivity' and have it have flags for invokish, throwish, branchish
or may_invoke, may_throw, may_branch if you like non-whimsical names 15:32
15:37 woolfy1 joined 15:38 woolfy joined
TimToady has no problem with whimsy, as long as it's also understandable 15:41
jnthn I don't think we have any that branch, fwiw 15:53
brrt i thought so 15:56
that's good, too :-)
brrt dinner & 15:57
16:07 jnap joined 16:19 brrt joined
moritz brrt++ Ā§ blog 16:23
brrt :-) thanks
timotimo brrt++ $ blog 16:24
brrt oh, timotimo, i forgot to note your contributions, as well as a small guide on how to contribute 16:25
timotimo i contributed?
i already forgot :P
ah, you mean the simple ops i hooked up to the respective c functions?
brrt yes, these :-) 16:26
it's fun to see that i'm not the only one who can manipulate the code sucessfully
timotimo well, that's only the part of the code where manipulation doesn't include changing the dynasm code 16:27
because i haven't done any x86 assembly in my life so far and i was hoping i could skip that experience for a long, long time
brrt why? it's fun :-) 16:29
timotimo you mean Ā°FUNĀ°?
the paragraph about type objects being asked for attributes seems like it doesn't explain what actually got returned instead of null ... 16:30
TimToady degree quotes?
brrt good question, i'd have to look at the respective at_key implementations 16:31
timotimo m: say qĀ°FUNĀ°
camelia rakudo-moar 189d1c: OUTPUTĀ«FUNā¤Ā»
timotimo ^- yays!
m: say qƗTATTEREDƗ 16:32
camelia rakudo-moar 189d1c: OUTPUTĀ«TATTEREDā¤Ā»
timotimo m: say q+FINE+
camelia rakudo-moar 189d1c: OUTPUTĀ«FINEā¤Ā»
timotimo m: say q*SUPERIOR*
camelia rakudo-moar 189d1c: OUTPUTĀ«SUPERIORā¤Ā»
TimToady just don't try :
timotimo m: say qā‰”EXCEPTIONALā‰”
camelia rakudo-moar 189d1c: OUTPUTĀ«EXCEPTIONALā¤Ā»
timotimo m: say qĀ°MASTERWORKĀ°
camelia rakudo-moar 189d1c: OUTPUTĀ«MASTERWORKā¤Ā»
timotimo all of those work ā™„ 16:33
m: say qā™„Dwarf Fortressā™„
camelia rakudo-moar 189d1c: OUTPUTĀ«Dwarf Fortressā¤Ā»
TimToady some of the future is unevenly distributed to the past
brrt much wow 16:34
TimToady in fact, those would work in Perl 5 too 16:35
timotimo now it'd be swell if there was a way to have these delimitors mix in a role when they are used
TimToady (given appropriate uses at the top)
timotimo do we have any mechanism specced to do that? i think we really ought to
TimToady well, we used to do things like treat qx'' differently from qx"" in P5, but gave that up as a bad idea 16:36
and I think if you really want such a language tweak, you don't want the q
timotimo yes, i like the q vs qq more
TimToady just write your own quote slang regex 16:37
timotimo but how do i show dwarf fortress fans how awesome perl 6 is for being able to incorporate their memes into the language?
16:39 raiph joined
dalek arVM/moar-jit: 9b3c483 | (Bart Wiegmans)++ | src/jit/emit_ (3 files):
Pre-allocate stack space

This is the first step in fixing the ABI for windows compatibility. The frame was 'walking upwards' with every C call that used any stack space; as a result gibberish was inserted in the place of the callee-save registers.		 16:58
17:10 ggoebel111116 joined 17:43 brrt joined
brrt jnthn, timotimo: ping? 17:44
i'm wondering if it's an acceptable tradeoff to move all call arguments into a scratch register before putting them in their final place 17:47
jnthn brrrt: pong
brrt it makes dealing with the different call conventions greatly simpler
jnthn Well, I'll choose working over broken any day ;)
brrt no longer will i need the addarg and addarg_f macro
but it is twice as slow for simple cases 17:48
jnthn Will it make a big performance impact?
Hmm
brrt probably not
i don't think you'll feel register-to-register moves
(which is worst case what will happen for the most of these)
jnthn *nod*
Well, simple, working code first
brrt ok
jnthn We can always optimize it later
brrt very well, i 17:49
'll get to it
18:15 Ven joined 18:28 btyler joined
brrt gcc-mingw32-w64 makes weeeird code 18:41
18:48 ggoebel111116 joined, vendethiel- joined
brrt also, it seems that win64 puts stack arguments in right-to-left order, as well 18:59
jnthn oh... 19:01
brrt which is good, because that's what posix does as well 19:02
i.e. leftmost order is topmost (or actually, bottommost) on stack 19:03
rurban BTW: beware of icc, this is backwards 19:04
brrt if icc doesn't abide by an ABI then it is my professional opinoin that this is ICC's problem :-) 19:05
rurban Well, in the rare case if someones wants to use it, you should know. But I forgot the details. icc generates faster code, so... 19:06
brrt its actually a bit strange so few people use ICC, no? 19:07
but then again, if faster code = broken code (as seen from POV from developers)
19:25 raiph joined 20:03 woolfy left 20:05 raiph joined
timotimo brrt, assembly - or machine code - is actually more like a declarative language 20:12
these register switches are probably going to disappear while running
20:17 woolfy joined 20:18 woolfy left 20:42 brrt joined
brrt register switches? 21:04
timotimo?
timotimo shuffling data between registers 21:05
brrt oh, right
i see :-)
very well
timotimo you know how values can overtake each other inside the pipeline and stuff like that? :)
brrt well, i think that's something i don't want to know too much about 21:06
timotimo :D
TimToady another leak: :3('1201212') while 1 21:10
(I suspect, but let me run it a while to see if it stabilizes) 21:12
it does stabilize in parrot at about half a gig
what's the incantation to limit heap memory? 21:14
dalek arVM/moar-jit: 3d979c6 | (Bart Wiegmans)++ | src/jit/ (5 files):
Fix stack argument passing.

This should mean JIT on win64 lives again. NB that I cannot find it documented what the proper size for stack arguments should be, but I assume it is 8 bytes for all arguments.		 21:23
brrt jnthn: please review ^^, see if it works now :-)
brrt afk
21:23 brrt left
jnthn TimToady: Limit heap memory at what level? 21:43
FROGGS when we're leaking we are leaking in C land I suppose 21:44
do we need to free any of these? github.com/MoarVM/MoarVM/blob/mast...ops.c#L861 21:53
jnthn store_bigint_result stores them inside an Int or so, iirc 21:54
FROGGS hmmm, almost thought so 21:55
jnthn brrt: Sadly, no luck; we SEGV much more now, and my debugger is incredibly confused about the stack, which looks rather corrupted. 22:00
brrt: 9b3c483 seems to be to blame, as if I try that one, it will explode in just the same way 22:03
(and it failed differently before that one)
FROGGS here is a valgrind output of :3("111") while... paste.scsys.co.uk/409598 22:07
(cannot create gists for some reason since a few days)
==12728== 432,954 (432,064 direct, 890 indirect) bytes in 6,751 blocks are definitely lost in loss record 1,718 of 1,763 22:08
==12728== at 0x4C2A2DB: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12728== by 0x4C2C74F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12728== by 0x4FA43DB: initialize_ssa_var_info (graph.c:810)
jnthn Hmm 22:11
But that wouldn't explain a leak over time; it'll only spesh stuff once...
FROGGS hopefully :P 22:12
jnthn Well, think I can fix that one easy enough :) 22:13
FROGGS I'm dumping all reachables now too 22:14
==12997== 4,646,152 bytes in 112,982 blocks are still reachable in loss record 1,768 of 1,772 22:15
==12997== at 0x4C2A2DB: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12997== by 0x4F8590C: deserialize (MVMArray.c:1098)
timotimo does valgrind cope with out "just crash" exit style? 22:16
FROGGS timotimo: no, that would surprise me :o)
would make sense to do the "slow shutdown" for a valgrind run... 22:17
jnthn Well, insead of doing 1000 iterations of that loop, do 100,000
It should amplify whatever it is that's leaking
timotimo i'm not sure we can even do the slow shutdown without crashing there, too :P
hasn't been active and probably not tried for a long time
FROGGS that fits the iteration count:
==12997== 929,566 bytes in 999 blocks are still reachable in loss record 1,742 of 1,772
==12997== at 0x4C2C494: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12997== by 0x4F67A74: MVM_validate_static_frame (validation.c:588)
jnthn: okay, but when I do that, I'll go to bed :o) 22:18
because slow valgrind is slow
jnthn oh 22:19
Well, maybe 10,000 is enough :)
dalek arVM: b2e3884 | jnthn++ | src/spesh/graph.c:
Fix a number of SSA/dominance memory leaks.

Found by FROGGS++ using Valgrind.		 22:21
jnthn That should clear up a number of things 22:22
FROGGS nice!
timotimo .o( also, less memory use :P ) 22:23
FROGGS okay, valgrind is running now 22:24
22:26 Ven joined 22:28 ventica joined
dalek arVM: 895bcc8 | jnthn++ | src/spesh/inline.c:
Fix memory leak in inlining.

Found by FROGGS++ using Valgrind.		 22:28
jnthn That's all the spesh ones at least :) 22:33
23:19 ggoebel111117 joined 23:22 [Coke]_ joined
dalek arVM: 6753df5 | jnthn++ | src/core/interp.c:
Detect frame change in extop call.

This means we'll be able to remove the nasty cur_op fiddling in the Rakudo ext-ops that invoke.		 23:41
timotimo could i emit a method call in spesh without allocating new registers? 23:44
jnthn Don't think so 23:47
But the new register thing is really near the top of my spesh todo list now. 23:48
timotimo good :) 23:49
i forgot what the other thing was that i wasn't able to do so far due to that :\
i wonder what'll happen next before register stuff happens :) 23:58

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!