00:22
zakharyas joined
|
|||
timotimo | weird. | 00:51 | |
these blocks that the optimizer creates | |||
they have loc_0_str, loc_1_obj and loc_2_obj | |||
but their body is just: | |||
00002 const_s loc_0_str, 'INTERNAL ERROR: Execution of block eliminated by optimizer' | |||
00003 die loc_1_obj, loc_0_str | |||
00004 return_o loc_1_obj | |||
so where does that third register get allocated? | |||
gist.github.com/timo/db2770106e0dc58748ab - fun! | 00:54 | ||
00:55
jnap joined
01:28
FROGGS_ joined
04:12
lue joined
|
|||
diakopter | timotimo: heh. | 04:34 | |
04:41
brrt joined
04:50
zakharyas joined
|
|||
nwc10 | jnthn: pass. Except t/spec/S32-list/uniq.t failed during the spectest. Can't reproduce | 05:54 | |
06:12
brrt joined
|
|||
brrt | jnthn: i have a reasonable theory on why the thing crashes, but i'm not sure | 06:15 | |
the exception itself seems to be normal | |||
as in, it's also thrown from the exact same spot in interpreted code | 06:16 | ||
nwc10 | m: say 5.588e+01/5.6892e+01; say 5.588e+01/6.597e+01 | 06:45 | |
camelia | rakudo-moar 40748b: OUTPUT«0.9822119102861560.847051690162195» | ||
brrt | uhm, when is a spesh frame actually compiled | 06:53 | |
brrt has a sneaking suspicion | 06:55 | ||
ok, much amaze, i've fixed it | 06:59 | ||
dalek | arVM/moar-jit: 76f76b8 | (Bart Wiegmans)++ | src/ (5 files): Fix bug in handlers When a frame is JITted, the exception handling logic must search for JIT handlers rather than regular handlers because the interpreter bytecode offset. Except that this is again meaningless if that code has never ran, such as when the frame was compiled but has not been entered yet. So we must check for that, as well. I've also added code to automatically load the right label to the interpreter whenever we cross a frame handler barrier, so that adhoc exceptions should Just Work. |
07:06 | |
arVM/moar-jit: e5dd370 | (Bart Wiegmans)++ | src/jit/graph.c: Add ne_s by appending not_i |
07:19 | ||
07:25
odc joined
07:50
brrt joined
|
|||
brrt | fwiw, i think we can now delete the output files from dynasm from the repository? | 08:09 | |
they no longer serve a purpose now i can build them pretty much always | |||
FROGGS_ | cool :o) | 08:12 | |
dalek | arVM/moar-jit: 3e7eda7 | (Bart Wiegmans)++ | src/jit/ (4 files): Add binary operators and integer negation |
||
arVM/moar-jit: 71e35f3 | (Bart Wiegmans)++ | / (3 files): Remove DynASM output files These are no longer necessary because we now ship minilua and can always build them again. |
08:15 | ||
FROGGS | brrt: hmmm, would it make sense to generate these files into src/gen/ ? | 08:19 | |
nwc10 | brrt: for generated files, either build them *every* time as part of the build process | 08:20 | |
or have a well defined way to rebuild them | |||
and preferably a test that they are current | |||
if you don't enforce policy one way or the other, it inevtiably ends up with them being stale | 08:21 | ||
and then bugs | |||
brrt: are you able to make it to the hackathon in October? | 08:22 | ||
act.useperl.at/apw2014/talk/5565 act.useperl.at/apw2014/talk/5566 | |||
FROGGS | I hope Larry can come :/ | 08:27 | |
but I guess that this is slightly unrealistic | |||
brrt | FROGGS: i'm okay with moving them into src/gen | 08:29 | |
nwc10: they're... supposed to be kept up-to-date using make | |||
much like .o files | |||
that usually works for me; more importantly i've added a line to .gitignore so they'll be never be included in the repo again | 08:30 | ||
if they go stale it'd be weird | |||
also, wrt, to hackaton | |||
let me see :-) | |||
FROGGS | ( src/gen/ is already in .gitignore of course ) | ||
brrt | this in austria? | 08:31 | |
i'm perfectly ok with moving them to gen | |||
i think make clean will also remove them then? | |||
FROGGS | hmmm | ||
brrt: yes, Salzburg | |||
brrt: only distclean would do that if you list your files | 08:33 | ||
brrt | uh, i can already tell you that i'd like too, but i have no idea right now if i'll be studying, if i'll have work, if i'll have any money :-) | ||
nwc10 | I forget the magic not to get logged, so I'm not going to answer that | ||
brrt | my next month's planning is a bit vague | ||
nwc10 | brrt: make, good | 08:37 | |
brrt: Salzburg is in Austria. Just | |||
it's about 4km from the German border. We can tip you over into Germany if you get ill, if that makes travel insurance easier | |||
brrt | travel insurance? what is that thing i've never heard of? :-p | 08:38 | |
FROGGS | *g* | 08:39 | |
nwc10 | it's probably not a problem, if you don't mind the off chance of being stuck in a hospital in Austria | ||
brrt | but yeah, that would be quite a bit cheaper, there are these very cheap cross-qountry germany tickets | ||
jnthn | morning o/ | ||
brrt | morning | ||
nwc10 | jnthn: well spotted :-) | 08:40 | |
FROGGS | "morning" jnthn :o) | ||
jnthn | brrt++ # fixing the JIT | ||
brrt | :-) | ||
jnthn should build it :) | |||
FROGGS | Stage parse : 35.065 | 08:41 | |
that's the lowest I've ever seen on my box | |||
brrt | you should | ||
hmm, i've seen 25s i think, but only with jit disabled | |||
jnthn | hmmmm | 08:43 | |
brrt | hmm? | ||
jnthn tried to merge in master and it's produced a broken build | |||
brrt | uh | ||
and.. without master? | |||
jnthn | Probably woulda been OK | 08:44 | |
Looks like a mis-merge | |||
yeah, fine now | |||
brrt | oh, ok :-) | 08:45 | |
FROGGS | brrt: I should mention that this was without jit | 08:47 | |
yesterday with jit I had about 53s | |||
and that's a core i5 laptop | |||
nwc10 | JIT seems to make my setting build a little bit slower | 08:48 | |
brrt | yeah, mine too | 08:50 | |
everybodies | |||
:-) | |||
much sad, but i think the only solution is to start profiling | |||
jnthn: you can push the merged master if it works | 08:52 | ||
jnthn | brrt: Yes, was just checking it did | 08:55 | |
Get through the setting build here. | |||
FROGGS | brrt: just make it not explode... because the chance that the design is off is pretty non existent me thinks | 08:56 | |
brrt | FROGGS: because of hunger, i'm stupid today. i'll try to not make it explode, but i'm not sure what you mean with the design being off :-) | 08:57 | |
FROGGS | brrt: I just wanted to say that you should not worry about the slowness right now | 08:59 | |
jnthn | brrt: One thing to note: I guess we're still generating the specialized bytecode as well as the JITted output? | ||
brrt | oh yes | ||
FROGGS | just carry on | ||
brrt | jnthn: indeed | ||
jnthn | brrt: For frames below the inlining size limit we still want it. | 09:00 | |
For anything larger than that, I think we could drop that step? | |||
brrt | could potentially, yes | ||
but codegen also fixes up handlers and all the rest | |||
and deopt indices, and that would have to be moved | 09:01 | ||
and that is annoying in a way | |||
jnthn | hmmm | 09:03 | |
Except...it's fixing up handlers and deopt indexes relative to specialized bytecode, rather than JITted code... | 09:04 | ||
brrt | true, but for example the jit handlers are just a bunch of labels, and the action to be performed is still in the interprted handler | 09:06 | |
is this a hack? yes | |||
could we fix it? also yes | |||
could we fix it without duplicating work? hmmm | |||
but i agree, we should fix it one day or another | 09:07 | ||
jnthn | *nod* | 09:08 | |
Yeah, not suggesting it for now | |||
Given that things now work with JIT, and that you still have to --enable-jit anyway, would now be a sane time for a merge to master? | |||
brrt | ehm, yes, i think so | ||
FROGGS | +1 +1 +1 | ||
brrt | i suppose i'd like to remove the test files, i have a local repository for them anyway | 09:09 | |
but otherwise | |||
dalek | arVM/moar-jit: ec09497 | jnthn++ | src/core/ (5 files): Fix --dump when there are state variables. |
||
arVM/moar-jit: d0c50da | jnthn++ | src/6model/serialization. (2 files): Provide a way to force-deserialize an STable. Sometimes, we get ordering dependencies with deserializing REPR data. Now that we deserialize lazily, this can get us into trouble. Enable fixing this by providing a mechanism for enforcing the dependency. |
|||
arVM/moar-jit: 693a628 | jnthn++ | src/6model/reprs/MVMArray.c: VMArray types depend on their element type. Remove test files, they don't belong here |
|||
jnthn | That was the (fixed) merge | ||
(Of mater into moar-jit) | |||
uh, master | |||
brrt | dura mater | 09:13 | |
ok, i'll remove the test files, and then i think we can merge? or is there something you want me to clean up first? | |||
(here 'you' was plural, btw :-)) | 09:14 | ||
jnthn | No, I'm happy | ||
FROGGS | then we all are happy :o) | ||
FROGGS | brrt: if you would convert your test files so that they output TAP you could add them to nqp/t/jit | 09:16 | |
brrt | yes, i'll do that next | ||
FROGGS | though you probably cannot test that something really git JITted | ||
brrt | hmm. no | ||
except if you'd have reified access to the frame, the spesh candidate, and the jitcode | 09:17 | ||
dalek | arVM/moar-jit: 79d3e89 | jnthn++ | src/core/op (2 files): Mark can and can_s as invokish. |
09:18 | |
jnthn | uh, I probably should wait for the merge, shouldn't I :) | ||
brrt | well, yeah, but it'll be easy enough to merge that back too | 09:19 | |
nwc10 | cation, these goalposts are moving. | ||
jnthn | :) | ||
cation, spelling hard :P | |||
nwc10 | aye. :-) | ||
dalek | Heuristic branch merge: pushed 238 commits to MoarVM by bdw | ||
jnthn | 238 :D | 09:20 | |
brrt | muhahaha! | ||
your project has been irrevocably changed | |||
jnthn | brrt++ \o/ | ||
brrt | feel the wrath! | ||
jnthn | ah, my commit did get lost :) | 09:21 | |
brrt | yes, hadn't merged that in yet | ||
will do just now | |||
jnthn | OK | 09:22 | |
Or I can rescue it, but if you're doing it anyway... :) | |||
dalek | arVM: 79d3e89 | jnthn++ | src/core/op (2 files): Mark can and can_s as invokish. |
||
jnthn | \o/ | ||
brrt | i'm wondering what will blow up because of can_s and can, but we'll see | 09:25 | |
jnthn | BAIL: op <const_i64_32> | 09:27 | |
srsly? | |||
brrt | lol | 09:28 | |
jnthn | hah, emit_x64.dasc knows it, but graph.c doesn't :) | ||
brrt | look unlikely something will blow up because of it :-) | 09:29 | |
jnthn | hopefully | 09:32 | |
I may have something nice to show you in a few minutes :) | |||
brrt | nice | ||
but... i'll be off for lunch right now :-) | |||
bye! | 09:33 | ||
jnthn | yay, my changes don't break nqp and rakudo builds | 09:39 | |
dalek | arVM: e26355e | jnthn++ | src/jit/graph.c: JIT can and can_s. |
09:41 | |
arVM: ca6ee1a | jnthn++ | src/jit/graph.c: Add const_i64_32 to list of ops we can JIT. The emitter already knew how, just not the JIT graph builder. |
|||
jnthn | Without JIT: | 09:58 | |
timecmd perl6-m -e "my int $i = 0; while ($i = $i + 1) <= 100000000 { }; 'ok'.say" | 09:59 | ||
ok | |||
With JIT: | |||
command took 0:0:2.35 (2.35s total) | |||
C:\consulting\rakudo>timecmd perl6-m -e "my int $i = 0; while ($i = $i + 1) <= 100000000 { }; 'ok'.say" | |||
ok | |||
command took 0:0:0.74 (0.74s total) | |||
timotimo | that's cute :) | ||
we don't have _I ops in the jit yet, do we? | |||
jnthn | No | ||
timotimo | gist.github.com/timo/db2770106e0dc58748ab - did you see this? %) | 10:00 | |
jnthn | Just gonna check my patch for hllize won't blow stuff up | ||
timotimo: Apart from the set that could probably go away, looks like it's making some job of register re-use :) | 10:02 | ||
10:03
brrt joined
|
|||
timotimo | at least that, yeah | 10:04 | |
but spesh will end up with three set operations in a row from code like this %) | |||
dalek | arVM: 7671558 | jnthn++ | src/ (3 files): JIT hllize. Also mark hllizefor as invokish, for future JITting. |
10:05 | |
jnthn | Yeah, I know. The set elimination problem needs tackling at some point :) | ||
timotimo | maybe it'll fall out naturally from register allocation on the jit side of things? | 10:06 | |
but not necessarily on spesh ... | |||
jnthn | I think we probably can deal with it more naturally in spesh | ||
timotimo | mhm | 10:07 | |
jnthn: any idea why the "block eliminated by optimizer" frames end up with an unused register? | 10:22 | ||
jnthn | 'fraid not | 10:23 | |
brrt | timotimo: it actually something that has to be done at all levels, it seems | 10:24 | |
timotimo | what, superfluous set removal? | 10:25 | |
jnthn: perhaps the mast compiler allocates a register for the "return value" of the raw block and expects something inside to make use of it, but nothing does? | 10:26 | ||
brrt | yes, set removal | ||
basically, if you do it in spesh, you'll have to make a map for when deopting, right? | 10:27 | ||
jnthn | timotimo: Perhaps | ||
brrt: Not really. When I looked into patch it, I was looking for a set with a single usage | |||
brrt | but you'll also have to make the same in the JIT if you're trying to eliminate stores and fetches | ||
ah, ok | |||
jnthn | brrt: Using a register the other side of a deopt boundary gives it a bonus usage | ||
timotimo | here i see a line that looks at the .blocktype and if it's "raw", it'll create an InstructionList with MAST::VOID, $MVM_reg_void | 10:28 | |
jnthn | So it never gets eliminated | ||
timotimo | jnthn: how impossible would it be to have something like "hot code swapping" supported by moarvm semi-directly? | 10:30 | |
that's something that's pretty cool in the java world - i guess CLR has something similar as well? | |||
brrt | hot code swapping seems a bit similar to on-stack-replacement? and we do that | 10:37 | |
timotimo | except the java people replace methods of classes in their IDE and have the change reflected directly in the running VM | 10:39 | |
that's a bit more "advanced" because you're not working from having a quasi-direct mapping between the bytecodes | |||
jnthn | Aye. It'd be nice to support edit-and-continue debugging some day | 10:41 | |
brrt | ooh in that sense | ||
well, you'll have to have IDE support too | |||
nwc10 | jnthn: PASS (except for sin) | 10:42 | |
brrt | awesum | 10:43 | |
brrt is blogging away, btw | |||
jnthn | Cool | 10:44 | |
jnthn is going to nom something, then look at async things a bit | |||
timotimo | nice :) | 10:47 | |
11:26
cognome joined
|
|||
nwc10 | m: say 5.6177e+01/5.588e+01; say 5.6177e+01/6.597e+01 | 11:30 | |
camelia | rakudo-moar 40748b: OUTPUT«1.005314960629920.851553736546915» | ||
nwc10 | JIT setting is slightly slower than JIT-free setting | 11:31 | |
timotimo | glad to hear it's only a slight change | 11:34 | |
... what exactly are these two numbers? | |||
nwc10 | first pair are "this run divided by previous run" | 11:39 | |
timotimo | ah | ||
nwc10 | second pair are "this run devided by a run a couple of weeks ago when I started counting | ||
roughly xkcd.com/363/ | |||
lizmat | so, how can I tell whether I have a jit enabled moar ? | 11:43 | |
$ install/bin/moar --version | 11:44 | ||
This is MoarVM version 2014.07-358-g7671558 | |||
jnthn | lizmat: MVM_JIT_LOG=jit_log perl6-m -e "say 42" # and see if jit_log is created and non-empty | 11:45 | |
lizmat | jit_log created but empty | 11:46 | |
jnthn | empty? Hm | ||
That'd probably mean you didn't get one | |||
We may want to include it in --version | |||
lizmat | that explains the lack of difference in spectest timing | 11:47 | |
perl Configure.pl --gen-moar=master --moar-option=--enable-jit --gen-nqp --backends=moar | |||
is what I did after rm -rf install | |||
carlin | moar-option in rakudo's configure doesn't work | ||
github.com/rakudo/rakudo/pull/300 | 11:48 | ||
lizmat | --moar-options is not recognize, --moar-option is | ||
merged, and rebuilding | 11:50 | ||
timotimo | the moar jit will likely increase the spec test time | 12:07 | |
jnthn | Here it comes out almost even. | 12:08 | |
timotimo | that is very good | 12:23 | |
compared to spesh only, yes? | |||
jnthn | Yes | ||
timotimo | if we can get the time we spend jitting back that is a good start | ||
would be terrible if we were jvm-slow until the jit kicks in | 12:24 | ||
I prefer the trade - off this way | |||
12:31
jnap joined
13:04
cognome joined
|
|||
dalek | arVM: a811334 | jnthn++ | / (6 files): Initial work on async process spawning. With this, it actually does spawn a process, though the result or any errors are not yet handed back, and there's no I/O with the process yet. |
13:52 | |
jnthn | bbiab | ||
14:17
brrt joined
|
|||
[Coke] also has no jit on 64bit mac | 14:22 | ||
is this a moar config issue? | |||
timotimo | it mostly means we didn't implement(/activate?) code-gen for mac yet | 14:25 | |
carlin | does it not Just Work(tm) if the Configure script is edited? | 14:26 | |
[Coke] | ok. let me know if we need testers or some config stuff going on the mac. | ||
timotimo | carlin: i have no intimate knowledge of dynasm | ||
carlin | the configure script checks for darwin-2level but the OS X's where it's not working have an archname of something like darwin-thread-multi-2level | 14:28 | |
on OpenBSD I just edited Configure and it there's stuff going into the jit_log so it seems to be doing something... not sure what that something is though | 14:32 | ||
brrt | \o | 14:36 | |
no explicit knowledge of dynasm is necessary, fortunately | |||
basically i hardcoded the check for suppoted platforms like an evil man | |||
i have no idea how to check for x64 support otherwise | |||
jnthn back | 14:39 | ||
14:42
ggoebel1111114 joined
|
|||
brrt | \o jnthn | 15:11 | |
dalek | arVM: 7aed82d | jnthn++ | src/ (3 files): Schedule async proc exit and error callbacks. |
15:20 | |
jnthn | Now it's vaguely useful... | 15:21 | |
16:09
brrt joined
|
|||
dalek | arVM: e034339 | Carlin++ | Configure.pl: Some platforms use amd64 to refer to x86_64 |
16:16 | |
arVM: a213518 | lizmat++ | Configure.pl: Merge pull request #124 from carbin/bsd-users-are-people-too Some platforms use amd64 to refer to x86_64 |
|||
lizmat | odd that I'm called lizmat here, and on rakudo Elizabeth Mattijsen ? | ||
jnthn | Some channels just don't give you the respect you deserve... :) | 16:17 | |
Really though, no idea why :) | |||
japhb | lizmat: There's a translation table somewhere. Trying to remember where ... moritz++ might remember. | 16:18 | |
jnthn | Or is it that this was a pull request merged at the web UI, rather than a push from yourlocal machine? | ||
lizmat | web UI | ||
japhb | bus stop & | ||
lizmat | ah, that could be it | ||
hmmm. after carlin's patch, I still get: | 16:19 | ||
Configuring native build environment ................... JIT isn't supported on darwin-thread-multi-2level yet. | |||
jnthn | Did carlin's patch make it match that string? | 16:21 | |
lizmat looks | |||
brrt | nah, doesn't | ||
timotimo | the "-thread" piece is missing from that regex | 16:22 | |
but "darwin-2level" is | |||
lizmat | $ perl -V | grep archname | ||
osname=darwin, osvers=13.1.0, archname=darwin-thread-multi-2level | |||
timotimo | er, and the -multi is also missing | ||
no clue what it means | |||
lizmat | maybe I got a wonky perl5 | ||
5.10.1 | |||
hmmm... | |||
lee_ | i believe that means you have a perl with support for threads | 16:23 | |
lizmat | indeed | ||
lee_ | gist.github.com/leedo/86975efa5f47b7e8344d | 16:24 | |
dalek | arVM: dbc6cac | (Bart Wiegmans)++ | Configure.pl: Another attempt at Mac OS X support I'd say there has to be a better way to detect x64 support, but I don't know it yet. |
16:25 | |
lizmat | pulled and compiling | 16:29 | |
brrt | let's hope | 16:32 | |
brrt wants this: imgs.xkcd.com/comics/universal_converter_box.png | 16:35 | ||
carlin | Sorry, my patch was just to make *BSDs work, not Mac, but it looks like brrt++ got that covered | 16:37 | |
dalek | arVM: 6eea4f8 | jnthn++ | src/ (3 files): Preparation for async read from stdout/stderr. |
||
jnthn | Uh, for async processes, that is | ||
timotimo | async read from async processes stdout/stderr? :) | 16:38 | |
jnthn | Yes | 16:39 | |
my $proc = Proc::Async.new(path => 'ping', args => ['www.jnthn.net']); | |||
$proc.stdout_chars.tap(&print); | |||
say await $proc.start; | |||
That's the thingy I'm playing with getting working :) | |||
lizmat | Success!: $ ls -ls jit_log | 16:40 | |
760 -rw-r--r-- 1 liz 501 385987 Aug 11 18:40 jit_log | |||
jnthn | So JIT! | ||
brrt++ | |||
lizmat | indeed, brrt++ | 16:41 | |
brrt | yay | ||
lizmat | would something like 'my $a = 1000000; my int $b; for ^$a { $b = $b + 1 }' be jittable? | 17:01 | |
jnthn | Potentially | 17:02 | |
Well | |||
That'll probably hit MapIter | |||
lizmat | I'm not seeing it :-) | ||
jnthn | And I've no idea how well that works out | ||
for ^1000000 { ... } is the form that'll get turned into a while loop | 17:03 | ||
lizmat | $ time MVM_SPESH_DISABLE=1 perl6 -e 'my $a = 10000000; my int $b = 0; while $a-- { $b = $b + 1 }' | 17:06 | |
real0m5.313s | |||
$ time perl6 -e 'my $a = 10000000; my int $b = 0; while $a-- { $b = $b + 1 }' | 17:07 | ||
real0m2.526s | |||
the for ^x version is *much* slower | |||
$ time perl6 -e 'my int $b = 0; for ^10000000 { $b = $b + 1 }' | |||
real0m3.667s | |||
$ time MVM_SPESH_DISABLE=1 perl6 -e 'my int $b = 0; for ^10000000 { $b = $b + 1 }' | 17:08 | ||
real0m3.441s | |||
so, even though apparently for ^x is turned into a while, it's slower than a written out while | |||
jnthn | It can't inline that block at present. | 17:09 | |
Whereas in the while loop the static optimizer does away with it. | |||
lizmat | so not jitting at all there yet ? | 17:10 | |
jnthn | Well, we probably are jitting at least the inner block | ||
17:10
cognome_ joined
|
|||
jnthn | The trouble is, it's swamped by the invocation. | 17:11 | |
Which spesh isn't smart enough to know it can remove yet | |||
And it's not only that it can't inline, it's that it can't even eliminate the guards on the inner thing yet | 17:13 | ||
lizmat | well... it's a start.... | 17:18 | |
:-) | 17:19 | ||
I find the while $a-- difference quite impressive | |||
jnthn | lizmat: To see another notable difference, maybe try: my int $i = 0; while ($i = $i + 1) <= 100000000 { } | 17:21 | |
dalek | arVM: 29d2e7b | jnthn++ | src/ (3 files): Async process stdout/stderr async reads. This means tapping either (or both) output stream will now work out. |
||
lizmat | $ time perl -e 'my $i = 0; while (($i = $i + 1) <= 100000000) { }' | 17:22 | |
real0m4.728s | |||
note, that's Perl *5* | 17:23 | ||
$ time perl6 -e 'my int $i = 0; while ($i = $i + 1) <= 100000000 { }' | |||
real0m0.658s | |||
this particular piece of code is ~ 7 times as fast in Perl 6 than it is in Perl 5 | 17:24 | ||
$ time MVM_SPESH_DISABLE=1 perl6 -e 'my int $i = 0; while ($i = $i + 1) <= 100000000 { }' | |||
real0m2.819s | |||
even without JIT, perl 6 is faster! | |||
lizmat likes where this is going :-) | 17:25 | ||
jnthn | Still plenty of hard work yet :) | ||
But yes, nice to see such numbers :) | |||
lizmat | should we put in spectests to make sure the optimization kicks in ? | 17:26 | |
like the above code ? | |||
jnthn | Feels more like the kind of thing an automated perl6-bench run could do for us... | 17:27 | |
lizmat | but that wouldn't target any specific optimizations. would it? | 17:29 | |
jnthn | The above example code is straight out of perl6-bench :) | 17:30 | |
lizmat | ah, ok :-) | 17:33 | |
jnthn | Hm, I should probably not forget to have dinner :) | 17:40 | |
bbiab | |||
japhb | lizmat: I've been thinking for a while that we really want a couple more classes of benchmarks in perl6-bench -- and one of those is regression tests for optimizations. Now that we have history view for each test (as well as the summary), we can see when performance gets suddenly worse, and we should have a raft of benchmarks that check for specific optimizations we want to be sure to keep. | ||
jnthn: does your async proc code support *synchronous* writes to the spawned process, or does it not support writes to the subprocess at all? | 17:42 | ||
jnthn: Also, is/will it be possible to communicate on FDs other than 0,1,2? | |||
18:32
pmichaud joined
|
|||
pmichaud | jnthn/masak : where are you staying (hotel) at YAPC::EU ? | 18:33 | |
FROGGS | it is probably dinner time | ||
jnthn | pmichaud: www.hotelexposofia.com/ | 18:38 | |
pmichaud: There's a note on the website about getting a conf discount | |||
japhb: No writes at all yet; will get to it in the next days. | |||
japhb: Just 0/1/2 so far | 18:39 | ||
japhb: I guess the API in libuv supports beyond that? If so and you've a use case, could look into that... | 18:40 | ||
pmichaud | jnthn: I hope it's a significant discount... current rates are around 205EUR per night it seems. | ||
That's pretty hefty. | |||
nwc10 | jnthn: much spectest unhappyness. t/spec/S32-list/first-index.rakudo.moar t/spec/S32-list/grep-index.rakudo.moar t/spec/S32-list/first.rakudo.moar t/spec/S32-list/grep.rakudo.moar t/spec/S32-list/last-index.rakudo.moar t/spec/S32-list/uniq.t | 18:41 | |
in addition to the usual sinners. Sampling them seems to all be "not ok" rather than ASAN explosion | |||
jnthn | lizmat: I guess ^^ is related to what you've been up to? | 18:42 | |
nwc10 | oh, 2 people are moving goalposts? This is going to get confusing | ||
jnthn | pmichaud: Yeah, I have half that a night and that was 'cus I was too late to get a normal room and ended up with a junior suite... | ||
pmichaud | the yapceu site mentions sending email but doesn't provide an address :-/ | 18:43 |