github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
04:01
ilogger2 joined
|
|||
nwc10 | good *, #moarvm | 06:26 | |
06:31
domidumont joined
06:36
kawaii joined
07:42
Geth joined
07:55
zakharyas joined
08:10
sena_kun joined
|
|||
dogbert17 | hello nwc10, your name came up yesterday evening | 09:08 | |
nwc10 | what is this "evening" concept of which you speak? :-) | 09:12 | |
dogbert17 | can you backlog a bit in this group, look for some comments from lizmat, alternatively try running 'my %h = "a" .. "e" Z=> 1..5; for %h.keys { %h{$_~$_} = 42 }' | 09:17 | |
jnthn | good * | ||
dogbert17 | hello jnthn, had any coffee yet? | ||
jnthn | About 15% of the current mug has been consumed | 09:19 | |
dogbert17 | so todays outlook is improving then :) | ||
nwc10 | dogbert17: I already ran it under valgrind. It doesn't trigger anything from valgrind. | 09:23 | |
lizmat | nwc10: was the thought I had that a hash iterator would not bomb even if keys get added while it is not exhausted yet, correct ? | 09:24 | |
nwc10 | correct | ||
wait, er, no that's naughty | |||
not correct. I think it's viable to fix this somewhat, but mostly at the level of "spot this and backtrace" | 09:25 | ||
lizmat | well... yeah, I know it's naught, question is will it bomb / segfault / do weird things or not | ||
nwc10 | right now I think it will hit undefined behaviour in C for some cases | ||
lizmat | ok, so when someone does something like that, it's DIHWIDT atm | ||
and they should just use .eager on the iterator to work around it | 09:26 | ||
09:47
evalable6 joined,
linkable6 joined
|
|||
Geth | MoarVM/new-disp: cbb41277f9 | (Jonathan Worthington)++ | src/disp/program.c Fix infinite loop in a GC mark function |
10:33 | |
jnthn | new-disp is the winning kitten again, even before spesh knows what to do with it: gist.github.com/jnthn/5b6802952273...23c61e2989 | 10:34 | |
m: say 11.5 / 31.3 | 10:36 | ||
camelia | 0.367412 | ||
jnthn | Almost runs in a third of the time | ||
lizmat tries to not salivate :-) | 10:37 | ||
jnthn | I had a worried moment while measuring this, though. The new-disp version seemed to be taking forever. Even 10,000 calls had been running for over a minute. Wat? Well, silly infinite loop in the GC :) | 10:38 | |
One open question is still "how will new-disp be in the baseline case of multi-dispatch", because we're replacing a special-case multi cache with a new generic dispatch mechanism. Of course, a simple benchmark of this will end up telling us little useful right now, because spesh doesn't understand new-disp yet, so we miss the whole inlining show. But it is interesting to measure how things are without spesh. | 10:45 | ||
Results: gist.github.com/jnthn/d88bf1561e85...56d9346364 | 10:47 | ||
m: say 0.332 / 0.463 | 10:48 | ||
camelia | 0.717063 | ||
jnthn | So the baseline interpreter performance we see here is better in new-disp. | ||
Knocking off around 30% | |||
It's one synthetic benchmark, so I'd not read too much into it. There's also rather a lot more we might measure. | 10:49 | ||
But it's also a promising result | 10:50 | ||
lizmat | I'd say, very promising :-) | ||
jnthn | One experiment I have just done is making it be only one call in the loop. The timings there are 0.209 (new-disp) vs 0.329 (head). | 10:51 | |
The one with two different calls favors new-disp (though in a reasonable way) in so far as it caches per callsite, not a shared multi lookup cache per proto | 10:52 | ||
But it still wins in this case too | 10:53 | ||
After lunch I'll have a go at getting multis with where clauses working with new-disp, which hopefully will also show a nice improvement. | 10:55 | ||
11:43
zakharyas left
12:58
zakharyas joined
14:48
linkable6 left
14:50
linkable6 joined
16:05
domidumont left
|
|||
Geth | MoarVM/new-disp: 3d452a5774 | (Jonathan Worthington)++ | 17 files Provide a bind failure -> resumption mechanism The assertparamcheck op is used in the binding code emitted by Rakudo, and so far has always triggered a signature binding error handler. This makes it possible to invoke some bytecode such that if there is a binding failure (that is, assertparamcheck is used with a zero value), then instead of calling the bind failure callback, the frame will be ... (20 more lines) |
16:22 | |
timotimo | nice | 16:32 | |
jnthn | Yup, and it actually does work with letting us avoid some of the work with `where` clauses in Rakudo too | 17:00 | |
gist.github.com/jnthn/088f8e3de021...857d5db9d4 | |||
Again with the caveats that spesh doesn't really understand new-disp very well yet | |||
m: say 1.34 / 4.86 | 17:01 | ||
camelia | 0.27572 | ||
jnthn | Nice, runs in almost a quarter of the time. | ||
timotimo | Jesusthon Christington! | 17:05 | |
sena_kun | jnthn, sounds awesome. I wonder if the documentation gist wants some update, plus maybe it wants to belong to the moarvm repo. | 17:07 | |
timotimo | at some point we'll start celebrating Worthingmas instead of Christmas | 17:08 | |
18:10
zakharyas left
18:20
MasterDuke joined
|
|||
MasterDuke | jnthn: on new-disp, is there still a cost to having a `where` multi, even if it's never called? | 18:25 | |
18:31
domidumont joined
|
|||
MasterDuke | oh wait, not sure that question makes a whole lot of sense | 18:31 | |
well, i do actually have an example, though it's not what i meant... | 18:32 | ||
m: multi a(Int $a) { $a + 1 }; multi a(Str $a) { $a ~ "a" }; multi a(Rat $a) { $a - 1 }; my $b; my $s := now; $b := a($_) for ^100_000; say now - $s; say $b | 18:33 | ||
camelia | 0.04212922 100000 |
||
MasterDuke | m: multi a(Int $a) { $a + 1 }; multi a(Str $a) { $a ~ "a" }; multi a(Rat $a where * < 0) { $a - 1 }; my $b; my $s := now; $b := a($_) for ^100_000; say now - $s; say $b | ||
camelia | 0.039810558 100000 |
||
MasterDuke | hm. locally the version with the where is consistently a little bit slower | 18:34 | |
18:57
squashable6 joined
19:26
lucasb joined
19:30
MasterDuke left
|
|||
nwc10 | bother. I've been concentrating so hard on not screwing up the hot beverages that I forgot to refill the beer fridge. | 19:32 | |
19:48
zakharyas joined
19:52
zakharyas left
19:53
zakharyas joined
20:05
domidumont left
20:06
domidumont joined,
domidumont left
|
|||
jnthn | Oh no | 20:23 | |
Mine is well stocked :) | 20:24 | ||
Not quite to the degree it was before Easter, admittedly :) | |||
MasterDuke: I'm not sure why the presence of something with a `where` that is never used would make a difference even on master, and I can't see anything in the new-disp approach that would lead to that. | 20:25 | ||
tellable6 | jnthn, I'll pass your message to MasterDuke | ||
nwc10 | which Easter? :-) | ||
jnthn | This one. The previous Easter I didn't yet own a dedicated beer fridge, and had to remember to regularly stock the regular fridge. | 20:27 | |
This was a bit error prone, and the early binding wasn't ideal either. | 20:28 | ||
nwc10 | I't snot quite "the neighbours exploit Orthodox/Catholic calendar differences to have two Christmasses and up to two Easters" but they do observe both. | 20:32 | |
or the cherry-pick the side effects of both | |||
20:46
zakharyas left
|
|||
jnthn | Ah yes, more excuses to celebrate. :) | 20:57 | |
21:51
rba_ joined
21:52
rba_ is now known as rba
21:56
MasterDuke joined
23:36
lucasb left
|