Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-02-14

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

All times shown according to UTC.

Time Nick Message
01:34 jnap joined #moarvm
01:52 woosley joined #moarvm
02:00 lizmat joined #moarvm
02:50 FROGGS_ joined #moarvm
03:46 woosley1 joined #moarvm
03:49 nwc10 joined #moarvm
04:23 eternaleye joined #moarvm
04:35 woosley joined #moarvm
06:50 timotimo https://gist.github.com/timo/1f4fa4bc76b270829382
06:51 timotimo the size bucket 32-39 gets *quite* a lot of filling
06:53 timotimo i'm glad to report, however, that this program i'm running there has a peak rss of only 111 megabytes
06:53 timotimo i ought to try to get some more rest :\
06:54 dalek MoarVM: 4bfc5eb | (Timo Paulssen)++ | src/gc/gen2.c:
06:54 dalek MoarVM: bump the cur_page of MVMGen2SizeClass
06:54 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4bfc5ebc2b
06:54 dalek MoarVM/gdb-support: f0d7fa9 | (Timo Paulssen)++ | moar-gdb.py:
06:54 dalek MoarVM/gdb-support: with the power of hilbert, display page usage
06:54 dalek MoarVM/gdb-support: review: https://github.com/MoarVM/MoarVM/commit/f0d7fa924a
06:56 JimmyZ timotimo++
07:48 woosley joined #moarvm
07:52 FROGGS joined #moarvm
08:05 cognominal joined #moarvm
08:30 lizmat joined #moarvm
08:43 odc joined #moarvm
09:23 woosley joined #moarvm
09:30 woolfy joined #moarvm
09:52 woolfy left #moarvm
14:14 timotimo i'm finding an object that's nulled in one of the pages :\
14:19 timotimo there's actually a whole lot of objects that have their size set to 0 o_O
14:19 timotimo WTH.
14:19 timotimo i must be miscasting or something
14:22 jnthn Or reading freelist objects?
14:23 timotimo no, i made extra sure not to do that
14:23 timotimo even then, why did i sample a few objects that have too large sizes?
14:23 timotimo 24   [================================================== 63        1.512
14:23 timotimo 88   [                                                   1            88
14:23 timotimo 160  [                                                   1           160
14:23 timotimo not terribly unlikely values for sizes, but also unexpected
14:26 FROGGS[mobile] joined #moarvm
14:30 jnap joined #moarvm
15:50 lizmat joined #moarvm
16:06 woolfy joined #moarvm
16:18 tgt joined #moarvm
16:21 lizmat fwiw, it appears nqp on moar has test failures
16:21 lizmat ./nqp t/serialization/01-basic.t
16:21 lizmat *snip*
16:21 lizmat ok 893 - for integers around 2 ** 30, integer -1073741825 serialization round trip (11)
16:21 lizmat Segmentation fault: 11
16:24 jnthn lizmat: Need moar newer moar?
16:24 jnthn lizmat: The tests cover a segfault that (should be) fixed.
16:24 timotimo lizmat: \o
16:25 lizmat fetching newer
16:27 lizmat all tests successful!, sorry for the noise
16:28 timotimo that's all right
16:29 timotimo i made a silly mistake with the size bucket thingie
16:30 jnthn lizmat: phew :)
16:31 timotimo i still do find objects that claim to be 0 bytes big. that's weird.
16:32 timotimo P6int   [================================================== 14033 ← this is the vast majority of what's in the size bucket for 32
16:33 timotimo hm. i may still be stepping wrongly.
16:44 * timotimo is trying to get the data out of the MVMP6int objects, but gets No struct type named MVMP6int. from gdb
16:44 timotimo >_>
16:48 timotimo hm. P6int isn't immutable, is it?
16:50 jnthn It's immutable
16:50 timotimo https://gist.github.com/timo/ecfca78434a844d7c4d5 ← a histogram of sampled P6int's values
16:51 timotimo time for a constant pool? :)
16:51 jnthn timotimo: Hmmm
16:51 jnthn Well, yeah, we could in HLLConfig do that.
16:51 timotimo clearly it would even make a big difference if we limited ourselves to 0-16
16:51 jnthn I was thinking 0..8
16:51 timotimo even that would help
16:52 * timotimo opens up a quest on questhub
16:54 dalek MoarVM/gdb-support: 17997b1 | (Timo Paulssen)++ | src/gc/gen2.c:
16:54 dalek MoarVM/gdb-support: bump the cur_page of MVMGen2SizeClass
16:54 dalek MoarVM/gdb-support: review: https://github.com/MoarVM/MoarVM/commit/17997b172d
16:54 dalek MoarVM/gdb-support: e1998b2 | (Timo Paulssen)++ | moar-gdb.py:
16:54 dalek MoarVM/gdb-support: a whole lot of work on gen2 analysis
16:54 dalek MoarVM/gdb-support: review: https://github.com/MoarVM/MoarVM/commit/e1998b264a
16:56 timotimo i shall make the "bump the cur_page" thing obsolete soon
16:57 timotimo jnthn: i should allocate these constants in the gen2, right?
16:58 jnthn timotimo: That'd be a nice touch, yeah
16:58 jnthn timotimo: Do the creation of them at set_hll_config time
16:59 timotimo thank you, i was just about to ask that
16:59 lizmat joined #moarvm
16:59 jnthn timotimo: Then we'll never have to check for their existence and lazily generate them.
16:59 timotimo yup
16:59 timotimo it's only 0 through 8 (inclusive) anyway
16:59 timotimo that's hardly an overhead
16:59 jnthn yeah
16:59 woolfy joined #moarvm
16:59 jnthn Right, and givnen what it's going to save...
17:00 jnthn That means you'll generate them "for free" for Rakudo also.
17:00 timotimo aye
17:01 timotimo should i refer to these constants from MVM_hll_map?
17:02 jnthn Not sure I follow
17:02 timotimo well, i'll have to grab the ints from the constant pool in some place
17:02 timotimo otherwise it'll just merrily build more and more ints
17:02 jnthn It's set_config and then the places that box that need it
17:02 timotimo all the places, then?
17:03 jnthn Which is box_i in interp.c and then the MVM_repr_box_int
17:03 jnthn I think those are the only two.
17:03 timotimo ah, so i wouldn't skip MVM_repr_box_int in MVM_hll_map, but instead implement the cache in MVM_repr_box_int
17:03 timotimo gotcha
17:03 jnthn Any places doing it manually besides the one in the interp can do so
17:04 jnthn Well, you build the cache in MVM_hll_set_config
17:04 jnthn And then access it from the other places.
17:04 timotimo yes, that part was clear to me
17:05 timotimo what i was wondering about was when exactly to look for values in the cached range
17:05 jnthn Oh, hm.
17:06 jnthn Maybe, looking at this a bit more, HLL ain't the place to hang it...
17:08 timotimo it isn't? because that'd already have the association to the right type object to box with
17:09 jnthn yeah, but box_i doesn't mean "current HLL"...
17:09 jnthn It gets a type object.
17:09 timotimo oh!
17:09 timotimo that it does
17:09 timotimo so obviously the type object for P6int should have the cache :P
17:10 jnthn Well, that won't quite work out either...
17:10 timotimo i feared so
17:10 jnthn But yeah, it is kinda like we want to do something along those lines.
17:11 timotimo how terrible would it be to check if the given type object is the one from the current hll and use the hll's cache in that case? seems pretty darn wonky
17:11 tgt joined #moarvm
17:11 jnthn Yeah, that is a bit off.
17:11 jnthn Would probably work though :)
17:12 timotimo it wouldn't crash, but it wouldn't be nice, either
17:12 timotimo at least these checks are fairly cheap
17:14 tgt_ joined #moarvm
17:15 jnthn It may be the most expedient way. Guess we should just encapsulate it in one place, so if/when we figure a nicer way we can sue that.
17:15 jnthn And the p6box_i has it easy.
17:17 benabik joined #moarvm
17:19 timotimo well, set_hll_config doesn't seem to be the right place; apparently that doesn't get called when we're building NQP at least
17:20 timotimo maybe it ought to go into the if (!entry) inside hll_get_config_for
17:20 jnthn It must do...
17:20 timotimo or, it ought to go there, too
17:20 jnthn NQPCORE.setting uses it.
17:20 tgt joined #moarvm
17:21 timotimo oh. circularity saw problem mayhaps?
17:21 jnthn Nope
17:22 timotimo oh. now i get a null pointer access when i try to get interp->current_cu (because i'm in get_hll_config_for)
17:22 timotimo so that's also wrong
17:22 jnthn Oh, wait
17:22 jnthn NQP doesn't supply its own box types
17:22 timotimo oh
17:22 jnthn It just uses the default BOOTInt.
17:23 timotimo fair enough
17:23 jnthn So yeah, that really tells us that we're hanging it on the wrong peg, I guess...
17:23 timotimo yes.
17:24 timotimo the win is *very* juicy, though :)
17:24 jnthn Well, we can always keep a cache elsewhere...
17:24 jnthn Hang it off tc or something.
17:25 jnthn Or even instance, if we're careful..
17:25 timotimo huh. now i'm getting This representation (P6num) cannot unbox to a native int
17:25 timotimo (i gave it a check for null to skip the cache if it hasn't been initialised, just to see how much it's actually worth)
17:28 timotimo wait. should i be using int_box_type or foreign_type_int in set_config?
17:30 jnthn int_box_type
17:30 jnthn But I really don't think hll_config is the right place after all...
17:31 timotimo fair enough.
17:31 timotimo so if i put it into tc, what's the right place to fill it?
17:31 timotimo could just lazily fill it
17:31 jnthn We could, but there's a better way, I think.
17:32 jnthn The cache can be
17:33 jnthn an array of some struct with an MVMObject *type_object followed by an array MVMObject*[8]
17:34 jnthn And we write a function "MVM_intcache_for(tc, some_type_object)"
17:34 jnthn Which adds a cache entry
17:34 jnthn And then we just scan through the cache.
17:35 timotimo and when we compose something with a repr that can box_int, we can call the intcache from there?
17:35 jnthn In fact, cache-better is to keep an array of 4 type objects, and 4*8 array for the values
17:35 jnthn And then it's one cache line to scan.
17:35 jnthn Right. We just look through the first array to see if any entries match the type we have, and if one does then we look up the value.
17:36 jnthn Note that we make the cache fixed size.
17:36 timotimo that hangs off of the tc then?
17:36 jnthn Off instance, I guess, so all threads can share it.
17:36 timotimo OK
17:36 jnthn The trick is we *never* resize it, or change things we added.
17:37 timotimo yes
17:37 jnthn So we get easy thread safety
17:37 jnthn Maybe a mutex for adding is wise.
17:37 timotimo that ought to be easy.
17:37 jnthn Though unlikely to matter in practice.
17:37 jnthn Yeah, just need to take care with the layout so it's cache-friendly is all :)
17:39 timotimo hm. so if i make it [8], it'd not keep the 8
17:39 timotimo but having 9 is wonky, cache-wise
17:39 jnthn True :)
17:39 jnthn Could make it 15 :)
17:39 timotimo i *suppose* we could cache 0, 1, 2, 4, 8
17:39 jnthn Nah...then the lookup gets costly.
17:39 timotimo since 4 is still more common than 3 is
17:39 timotimo fair enough
17:39 jnthn Remember we'd like to JIT the lookup some day...
17:40 jnthn :)
17:40 timotimo ah, aye
17:40 timotimo do i have to be careful WRT moving if i hold MVMObject * in there for the type objects?
17:45 jnthn Oh, you have the GC mark this.
17:46 jnthn I'd put all the logic related to this in an intcache.c
17:46 timotimo mhm
17:47 timotimo would that be src/core?
17:48 jnthn yeah, can be
17:49 timotimo since the contention is probably crazy-low, should i just make a static mutex in that .c file?
17:50 jnthn No, 'cus that screws up running multiple instances...
17:50 timotimo will it, though?
17:50 timotimo ah well. doesn't hurt to make it.
17:50 jnthn Yes. Aside from totally immutable things like callsites, nothing should be static really.
18:01 * timotimo is taking baby steps
18:06 timotimo okay. i have no cache now, but i'm trying to read from the empty-initialized cache and it doesn't crash
18:06 timotimo that's a good start, methinks
18:06 timotimo should i put the intcache_for call into the hll function again?
18:07 jnthn Yeah
18:07 jnthn And also do it for BOOTInt
18:08 timotimo sure thing.
18:08 timotimo would that be in instance_create or in the hll thing?
18:08 jnthn Neither
18:08 jnthn Probably in bootstrap, after BOOTInt is set up
18:09 timotimo bootstrap, as in ... called from NQP code?
18:10 timotimo oh, i forgot to add any marking whatsoever
18:10 timotimo i suppose instance has a function that marks stuff it likes?
18:10 timotimo or should i just add it to the gen2 roots?
18:10 timotimo wait. if i instantiate it in gen2 anyway, won't it stay put for ever?
18:10 tgt joined #moarvm
18:11 timotimo hm. the cache didn't make a difference yet.
18:12 timotimo ah, haha
18:12 timotimo hm. that wasn't the fix yet :\
18:13 timotimo now i get cache hits, but This representation (VMHash) cannot unbox to a native int ← wtf
18:14 moritz well, sounds sensible to me
18:15 timotimo why does it even try that?
18:15 moritz I have no idea
18:15 moritz probably a bug :-)
18:15 timotimo is that so! :)
18:16 timotimo trying to build nqp's QRegex now gives me This representation (P6num) cannot unbox to a native int
18:16 timotimo ... again
18:20 timotimo perhaps the values of the ints i have in the cache don't correspond to the values that ought to be in there?
18:20 timotimo and it runs into a problem where P6num is in some list that it indexes into with a wrong int?
18:22 FROGGS[mobile] joined #moarvm
18:22 jnthn timotimo: I hope you are GC marking the cache?
18:22 timotimo oops, yikes :)
18:22 jnthn timotimo: So the memory doesn't end up pointing to other objects later?
18:22 timotimo i'm not, but i've done something quite dumb :)
18:22 timotimo hm, actually, that shouldn't have exploded
18:22 jnthn s/something/two things/, sounds like :P
18:23 timotimo yeah.
18:23 jnthn OK, nom time...then Moar hacking time... :)
18:24 timotimo \o/
18:26 timotimo i don't see a place from which to mark the pool cache
18:26 timotimo doesn't seem like instance gets a mark function at all?
18:28 timotimo you were right. it was gc trouble ... of course
18:28 jnthn See roots.c
18:28 timotimo now i have the cached ints as permanent roots, which isn't that much better
18:28 jnthn That also works
18:28 timotimo ah, there!
18:29 timotimo it would probably be more memory efficient if i implemented it in the add_instance_roots function, eh?
18:29 jnthn yeah
18:29 timotimo that's my next step, then
18:29 timotimo i'll have a look at the memory usage of -e 'say 1' again
18:29 timotimo maybe there's a tiny improvement :3
18:29 jnthn Yeah. I suspect it'll be a time improvement though as less GC churn.
18:30 timotimo hm. now we have a bunch of P6opaques in the cache; those aren't immutable, though
18:30 timotimo that could be trouble, eh?
18:31 timotimo aaw. no memory usage improvement? :(
18:31 timotimo still at 92 megabytes of ram usage for -e 'say 1'
18:31 jnthn huh, where'd the P6opaques come from?
18:31 jnthn Oh, Rakudo's Ints
18:32 jnthn but yeah, Int is immutable too
18:32 timotimo what if someone builds their own class with an int box target? how do we handle that?
18:34 timotimo ah, there's still lots of P6ints in the gen2 with values that ought to be cached
18:37 jnthn timotimo: We won't register their type as one to cache, though?
18:37 jnthn At the moment we're only doing BOOTInt and anything you set_hll_config on?
18:37 timotimo oh, that's right
18:37 timotimo (well, BOOTInt is still missing)
18:37 timotimo (because i didn't understand where you wanted me to put it; is bootstrap actually a moarvm thing?)
18:38 jnthn Yes
18:38 jnthn src/6model/bootstrap.c is where BOOTInt is set up
18:39 timotimo oh, great!
18:39 jnthn bbi20
18:53 * timotimo forgot to fix up interp.c until now
18:53 tgt joined #moarvm
18:56 timotimo oh, hm. i may be mistakenly clearing the "allocate in gen2" bit after creating the cache
18:56 timotimo the memory usage has now ... gotten more :\
18:57 timotimo still a whole bunch of low-value integers >:(
18:58 timotimo though when i still had debug output, i saw lots and lots of "cache hit" messages
19:04 jnthn timotimo: Yeah, don't put the gen2 allocation on/off in the cache logic itself
19:04 benabik joined #moarvm
19:05 jnthn timotimo: I can take a look at the patch, if you like
19:05 timotimo sure, gimme a sec :)
19:07 timotimo https://gist.github.com/timo/64ccbdb18bdf11b705cf
19:07 timotimo maybe i have to teach rakudo about it, too?
19:09 timotimo accidentally got some hunks from the gdb script in there
19:12 timotimo hm. perhaps those come from deserialization or something?
19:13 timotimo indeed, it needs to learn about that, oto.
19:13 timotimo too*
19:13 jnthn +    res = MVM_intcache_get(tc, type, val);
19:13 jnthn +    if (res == 0) {
19:14 jnthn == NULL will get rid of a warning
19:14 jnthn Or just if (!res)
19:14 jnthn +    /* By far the most common integers are between 0 and 8, but we cache up to 16
19:14 jnthn 15, no? :)
19:15 timotimo er, yes.
19:16 jnthn In MVM_intcache_for it seems you never set right_slot?
19:17 jnthn Again, == NULL is better in the loop there too
19:17 timotimo er, i do? maybe you have an out of date patch >_<
19:18 jnthn +    int right_slot = -1;
19:18 jnthn +    for (type_index = 0; type_index < 4; type_index++) {
19:18 jnthn +        if (tc->instance->int_const_cache->types[type_index] == 0) {
19:18 jnthn +        }
19:18 jnthn +        else if (tc->instance->int_const_cache->types[type_index] == type) {
19:18 jnthn +            return;
19:18 jnthn +        }
19:18 jnthn +    }
19:18 jnthn +    if (right_slot != -1) {
19:18 timotimo how the ...
19:18 timotimo there was a right_slot=type_index; break; in there
19:18 timotimo i'll get the code to you via git in a jiffy
19:19 jnthn Some -/NULL confusion.
19:19 jnthn 0/NULl I mean
19:19 dalek MoarVM/gdb-support: f1d1511 | (Timo Paulssen)++ | / (12 files):
19:19 dalek MoarVM/gdb-support: implement a constant cache for ints 0 to 16
19:19 dalek MoarVM/gdb-support: review: https://github.com/MoarVM/MoarVM/commit/f1d15119ad
19:19 dalek MoarVM/gdb-support: d881070 | (Timo Paulssen)++ | src/6model/serialization.c:
19:19 dalek MoarVM/gdb-support: teach serialization about the int cache
19:19 dalek MoarVM/gdb-support: review: https://github.com/MoarVM/MoarVM/commit/d881070a94
19:19 dalek MoarVM/gdb-support: 269193a | (Timo Paulssen)++ | src/core/intcache.c:
19:19 dalek MoarVM/gdb-support: avoid a warning comparing == 0
19:19 dalek MoarVM/gdb-support: review: https://github.com/MoarVM/MoarVM/commit/269193a7ae
19:19 benabik timotimo: You appear to have a very slow timer, if a jiffy is that long.  ;-)
19:20 timotimo benabik: line delay :)
19:20 * timotimo replaces more 0 with NULL
19:21 timotimo oh. now i b0rked it completely it seems
19:21 timotimo haha, silly me.
19:21 jnthn Also it seems the type objct entry in the cache ain't marked, in the last version I saw...maybe you fixed it already
19:22 dalek MoarVM/gdb-support: 55ca81d | (Timo Paulssen)++ | src/ (2 files):
19:22 dalek MoarVM/gdb-support: oops in serialization, more 0/NULL
19:22 dalek MoarVM/gdb-support: review: https://github.com/MoarVM/MoarVM/commit/55ca81d03a
19:22 timotimo i had that problem long ago
19:22 timotimo oh, wait
19:22 timotimo the *type* object. good catch!
19:22 timotimo also i was inconditionally adding the root in that same function
19:22 timotimo rather than only if we found a slot
19:23 dalek MoarVM/gdb-support: 5a8fe6d | (Timo Paulssen)++ | src/core/intcache.c:
19:23 dalek MoarVM/gdb-support: add type object to roots.
19:23 dalek MoarVM/gdb-support: review: https://github.com/MoarVM/MoarVM/commit/5a8fe6df34
19:25 timotimo it occurs to me that this ought to help startup time, too. since the deserializer will not have to allocate as much stuff
19:25 jnthn timotimo: In serialization.c you coulda probably called the REPR convenience function
19:25 jnthn timotimo: Meaning the intcache needs to be mentioned in one less place, and we get shorter code
19:26 timotimo 0.20user 0.02system 0:00.23elapsed 98%CPU (0avgtext+0avgdata 89916maxresident)k
19:26 timotimo finally a visible change!
19:26 timotimo but only like 3 megabytes saved :(
19:27 jnthn Uh, 3MB is quite a bit!
19:27 timotimo the most common integers in the gen2 are now 95 and 58
19:27 timotimo (and 675 completely filled pages) (and 2 empty pages) (freelist with 1 entries out of an allocd 1 )
19:27 timotimo REPRs (sampled):
19:27 timotimo P6num         [================================================== 5471
19:27 timotimo P6int         [======================                             2479
19:27 timotimo time to analyze what nums we have lying around :D
19:27 jnthn if (right_slot != -1) {
19:28 jnthn You have two conditionals like that one below the other in MVM_intcache_for that can be made into one.
19:28 timotimo OK
19:28 jnthn intcache.h wants adding to le makefile too
19:28 timotimo will do.
19:29 timotimo are you on the very newest code? because i only see one of those conditionals there
19:29 jnthn oh, maybe you pushed again while I was reading the diff...
19:29 jnthn No, it says all up to date here...
19:30 timotimo ... weird o_O
19:30 jnthn oh, it is gone
19:30 jnthn Hm, huh :)
19:30 FROGGS[mobile] joined #moarvm
19:30 jnthn anyway, looks pretty good now
19:30 timotimo well, i'm happy :)
19:31 timotimo kind of surprised to see absolutely no negative values in the gen2
19:35 dalek MoarVM/gdb-support: 64e92cf | (Timo Paulssen)++ | build/Makefile.in:
19:35 dalek MoarVM/gdb-support: add the intcache header to the makefile
19:35 dalek MoarVM/gdb-support: review: https://github.com/MoarVM/MoarVM/commit/64e92cfaf9
19:35 dalek MoarVM/gdb-support: 69529ee | (Timo Paulssen)++ | src/6model/serialization.c:
19:35 dalek MoarVM/gdb-support: serializer uses convenience MVM_repr_box_int function now
19:35 dalek MoarVM/gdb-support: review: https://github.com/MoarVM/MoarVM/commit/69529ee245
19:40 timotimo my delusions of grandeur regarding the int cache benefits are shattered ;(
19:41 timotimo haha. how fitting! :)
19:41 timotimo the most common double value is 6.0     [================================================== 252
19:41 timotimo 4.0     [=====================================              191
19:41 timotimo 1.0     [================                                   85
19:41 tgt joined #moarvm
19:42 timotimo very, very, very, very many double values that could just as well be integers. huh.
19:43 timotimo i must be measuring wrong?!
19:44 timotimo haven't hit a single P6num in my sampling that doesn't end in .0
19:45 timotimo P6num   [================================================== 5494
19:45 timotimo more than twice as many as P6int
19:46 jnthn timotimo: remember that NQP does a lot of stuff with _n ops
19:46 timotimo hm. oh well.
19:46 timotimo i suppose so.
19:47 timotimo i shall squash the commits
19:47 timotimo are you OK with merging it into master?
19:48 timotimo (though i'll keep the gdb stuff in my branch for a bit longer)
19:50 jnthn timotimo: Yes, provided it passes spectest
19:50 jnthn (and nqp test)
19:50 jnthn un, well, doesn't regress spectest :)
19:50 timotimo i should test that, aye.
19:51 timotimo hmm. i wonder, though
19:51 timotimo how did all these many many double values make it into gen2?
19:52 jnthn Not sure.
19:52 timotimo probably harmless.
19:52 jnthn Possibly by being closure-captured...
19:53 timotimo oh, that could definitely be a thing
19:53 jnthn We don't lower any lexicals right now.
19:53 timotimo lower lexicals to locals, you mean?
19:53 jnthn yeah
19:53 jnthn It's not just a speed thing, and a block flattening thing, but also an object lifetime thing.
19:53 timotimo i'll put it back onto my long-term goals list :)
19:55 timotimo the *hash tests are known to fail on rakudo-m?
19:57 jnthn Which ones, specifically?
19:58 jnthn baghash fails 2 tests for me.
20:01 timotimo they all abort here :\
20:01 timotimo waiting for the socket tests to finish being dumb before i get the summar
20:01 timotimo summary
20:04 dalek MoarVM/eieio: 305df11 | jnthn++ | / (7 files):
20:04 dalek MoarVM/eieio: Correct Latin-1; add Windows-1252.
20:04 dalek MoarVM/eieio:
20:04 dalek MoarVM/eieio: The Latin-1 implementation we had actually did Windows-1252. We're not
20:04 dalek MoarVM/eieio: HTML 5, so should actually Latin-1 when asked to. Keep the original
20:04 dalek MoarVM/eieio: code around as a Windows-1252 implementation.
20:04 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/305df119a2
20:05 benabik ...  Why is the branch eieio?  Just to get Old McDonald stuck in my head?
20:06 jnthn Yes. :)
20:06 moritz benabik: try to get http://www.youtube.com/watch?v=SQfMg0ejewk into your head instead :-)
20:06 benabik moritz: Well, it displaced http://www.youtube.com/watch?v=StTqXEQ2l-Y
20:09 timotimo the *hash tests abort on master, too
20:09 timotimo perhaps i have an out-of-date master.
20:12 timotimo enhanced implementation of ephemeral input/output ← eieio
20:12 timotimo ephermal* apparently
20:12 benabik Backronyms are fun.
20:14 jnthn eradicating irrationalities encumbering IO
20:15 timotimo :D
20:15 moritz enraged, idiotic, essential IO
20:16 moritz my backronyms have been better before :-)
20:16 moritz time for some sleep&
20:16 timotimo gnite moritz!
20:17 timotimo jnthn: no spectest regressions, the maxrss of a 4-test-job spectest run has gone down by about 5 megabytes
20:17 timotimo also like 7 seconds less time, which may be a measuring error
20:18 jnthn \o/
20:21 timotimo so ... add the mutex before merging it onto master?
20:21 timotimo that mutex shoud reside in MVMIntConstCache, yes?
20:22 jnthn Yeah, it can do.
20:22 jnthn Oh
20:22 jnthn Well, convention so far is mutexes for things in instance hang off instance
20:22 jnthn So maybe follow that convention.
20:22 timotimo that's okay
20:22 jnthn Not it's only for changing.
20:22 jnthn *note
20:22 timotimo aye.
20:23 timotimo since putting the type object itself into place is the last thing i do, it shouldn't race, i *hope*
20:23 jnthn Yeah, in thory.
20:23 jnthn In practice, we may want a volatile in there.
20:23 jnthn And/or a memory barrier.
20:23 timotimo well  ... maybe someone who's already worked with this kind of thing could do that :)
20:23 jnthn k
20:24 dalek MoarVM/eieio: 9ab2194 | jnthn++ | src/strings/ (6 files):
20:24 dalek MoarVM/eieio: Implement streaming decode for Latin-1 and ASCII.
20:24 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/9ab21941df
20:24 FROGGS joined #moarvm
20:27 dalek MoarVM: 96e7aaf | (Timo Paulssen)++ | / (12 files):
20:27 dalek MoarVM: implement a constant cache for ints 0 to 16
20:27 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/96e7aaf5d4
20:27 dalek MoarVM: fdf7c35 | (Timo Paulssen)++ | src/ (3 files):
20:27 dalek MoarVM: protect adding new types to int cache with mutex
20:27 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fdf7c35c3c
20:27 timotimo merged \o/
20:31 jnthn \o/
20:32 jnap joined #moarvm
20:33 dalek MoarVM/gdb-support: e7f378c | (Timo Paulssen)++ | moar-gdb.py:
20:33 dalek MoarVM/gdb-support: look at doubles
20:33 dalek MoarVM/gdb-support: review: https://github.com/MoarVM/MoarVM/commit/e7f378c933
20:33 timotimo gdb-support branch cleared of int cache stuff
20:37 FROGGS good evening
20:48 benabik joined #moarvm
20:52 timotimo jnthn: should i kill the check that verifies that the int object we got ouf of the cache actually does have the right value?
20:53 jnthn timotimo: Oh, yes
20:53 jnthn timotimo: I thought that was just for debuggering while you built it
20:53 jnthn uh, debugging.
20:53 timotimo yeah. i forgot about it for a little bit ;)
20:54 dalek MoarVM: 761a00a | (Timo Paulssen)++ | src/core/intcache.c:
20:54 dalek MoarVM: remove unnecessary safety check/debugging thingie
20:54 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/761a00a08f
21:08 dalek MoarVM/eieio: 3f65a5b | jnthn++ | src/strings/ (4 files):
21:08 dalek MoarVM/eieio: Assorted DecodeStream fixes and tweaks.
21:08 dalek MoarVM/eieio:
21:08 dalek MoarVM/eieio: With this, we're back to no regressed spectests in Rakudo for this
21:08 dalek MoarVM/eieio: branch.
21:08 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/3f65a5b9d1
21:09 timotimo yay! :D
21:09 benabik \o/
21:09 jnthn Now everything's fixed, time to break more stuff :)
21:10 benabik "If it ain't broke, fix it anyway."
21:11 timotimo "if it ain't broke, break it so you can fix it"
21:16 FROGGS \o/
21:16 FROGGS jnthn++
21:23 dalek MoarVM/eieio: 349d789 | jnthn++ | src/6model/reprs/MVMOSHandle.h:
21:23 dalek MoarVM/eieio: Toss an unused constant.
21:23 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/349d7897ef
21:23 dalek MoarVM/eieio: f75c631 | jnthn++ | src/io/fileops.c:
21:23 dalek MoarVM/eieio: Toss code too wrong to have ever worked.
21:23 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/f75c63109c
21:26 jnap joined #moarvm
21:31 timotimo is REPR an acronym for something?
21:34 jnthn No
21:34 jnthn Just means "representation"
21:34 timotimo i should stop spelling it that way then :)
21:41 timotimo hey, it seems like string constants on the string heap are sometimes in there a whole bunch of times
21:43 jnthn They're only interned per compilation unit at the moment.
21:43 jnthn So yeah, if two compilation units have the same string...
21:43 jnthn It'll appear twice.
21:43 jnthn Interning is a cost too, of course...
21:44 jnthn Any way you can calculate the benefit?
21:44 jnthn It complicates memory management too, I suspect.
21:44 jnthn So I'm not really in a hurry to implement it...
21:47 timotimo hm.
21:47 timotimo i don't think i can.
21:48 timotimo right now i'm talking about the section with constant strings in the .moarvm files, btw
21:48 timotimo we may have miscommunicated there
21:48 jnthn Oh...
21:48 timotimo in that case, interning should be much cheaper and memory management less of a problem
21:49 jnthn Yeah, but they shouldn't be duplicated within the constant strings section in the MoarVM file
21:49 timotimo in that case i must be looking wrong
21:49 jnthn Well, the de-dupe may be wrong too
21:49 timotimo ah, there's already de-dupe code, then?
21:49 jnthn See src/mast/compiler.c:get_string_heap_index
21:50 timotimo thanks
21:50 jnthn That hsould mean a string only appears once in a given .moarvm file
21:50 jnthn However, two .moarvm files may end up mentioning the same constant string.
21:50 timotimo hmm.
21:50 jnthn We do nothing about that.
21:51 timotimo i see at least &infix:<...> at least 5 times
21:51 jnthn If you're seeing the same one twice in the same .moarvm, then that de-dupe is busted...
21:51 jnthn On the heap, or in the .moarvm?
21:51 timotimo 10 times? 20 times?
21:51 timotimo in the .moarvm
21:51 jnthn o.O
21:51 timotimo at first i thought the cuids were in there multiple times, but they differ at the beginning rather than at the end
21:52 jnthn Worth looking into
21:53 timotimo ← le tired
21:53 timotimo ← le sniffy nose
21:54 jnthn :(
21:54 jnthn You seem to have not been well for a while :(
21:55 timotimo only a few days
21:55 timotimo i'll be fine in a bit. though the timing of my flu or whatever it is is kind of unfortunate
21:56 timotimo anyway
21:56 timotimo good luck with eieio :)
21:56 jnthn Thanks :)
21:56 timotimo hoping to wake up to some cool commits in the morning :3
21:56 jnthn Get well!
21:56 timotimo aye aye
22:27 colomon joined #moarvm
22:28 dalek MoarVM/eieio: 928fe39 | jnthn++ | src/ (3 files):
22:28 dalek MoarVM/eieio: Shuffle bytes reads over to DecodeStream too.
22:28 dalek MoarVM/eieio:
22:28 dalek MoarVM/eieio: This means we won't get out of sync if doing mixed string/bytes reads,
22:28 dalek MoarVM/eieio: but additionally lets us remove another place we directly call libuv
22:28 dalek MoarVM/eieio: to read data.
22:28 dalek MoarVM/eieio: review: https://github.com/MoarVM/MoarVM/commit/928fe39005
23:33 tgt joined #moarvm

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