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.982211910286156ā¤0.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.00531496062992ā¤0.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
and now I can't reach the hotel web site :-/ 18:46
I think I'll have to try again later
jnthn pmichaud: [email@hidden.address]
pmichaud jnthn: thanks
email sent 18:49
japhb jnthn: Most of the use cases I've seen recently for additional FDs to children involve various security enhancements (sandboxing I/O, avoiding writing to FS, getting a third write channel (aside from stdin and argv) to the subprocess, etc.)
pmichaud I have to go do some other tasks for a while... bbl
jnthn o/ 18:51
18:57 mj41 joined
timotimo there's also (on linux (only?)) a way to send opened FDs to other processes via a socket 18:58
mj41 brrt++, jnthn++, timotimo++, ... Congratulations guys, you all rock! gist.github.com/mj41/cb457de4ae7a53b2ccde 18:59
nwc10 if you mean passing file descriptors over Unix domain sockets - I think it's been around for at least 20 years. It's in first edition Stevens 19:00
timotimo yeah, that :) 19:01
nwc10 mj41: that's not quite a fair comparison. Could you also try
time perl -e 'use integer; my $i = 0; while (($i = $i + 1) <= 100000000) { }'
I have an idea what the result will look like :-)
timotimo i tried to do it once via socketpair i think 19:02
but it was kind of not working properly %)
mj41 nwc10: gist.github.com/mj41/cb457de4ae7a53b2ccde 19:04
also nwc10++
nwc10 mj41: cool. thanks. which shows that even integer operations aren't much of a win in Perl 5 19:05
diakopter it's type systems all the way downer 19:06
19:16 FROGGS[mobile] joined
mj41 lizmat: github.com/rakudo/rakudo/commit/e8...361648b241 19:25
timotimo good day, diakopter! :)
how are you?
mj41 lizmat: thx :-) 19:28
lizmat nwc10: $ time perl -e 'use integer; my $i = 0; while (($i = $i + 1) <= 100000000) { 1 }' 19:30
real0m5.434s
$ time perl -e 'my $i = 0; while (($i = $i + 1) <= 100000000) { 1 }'
real0m4.751s
looks like use integer only makes things slower? 19:31
19:34 rurban joined
timotimo i've just been shown the "red zone" that you can have on x86_64 19:37
lizmat
.oO( that's not red lights, is it ? )
 19:39
timotimo throughout the nqp compilation process, param_rp_o is the second-most bailing op in the jit with 180 bails 19:41
paramnamesused gets 481 bails under its belt
nwc10 lizmat: it was faster for me. but not much
jnthn Smell of electrical smoke considered ungood... :S 20:03
nwc10 no. 20:04
yesterday we managed a bang that took out all the power in the room
dodgy inherited wiring on a freestanding lamp
jnthn Wow.
nwc10 well, given how it was done, ultimately it was not surprising that it failed
jnthn I thought it was the wireless router, but now I ain't so fure...
*sure 20:05
nwc10 we were not previously aware
jnthn: at a guess, it's the power supply
I've had a couple fail
jnthn Not coming from there.
nwc10 OK. bang goes my theory
[oops :-)]
jnthn oh, you mean the power supply for the router?
nwc10 yes.
jnthn Hmm
that'd meaning switching the thing off may not have cut it... 20:06
nwc10 the power brick
jnthn yeah, I'd better shut stuff down and find it. :/
FROGGS it is actually hard to locate it when you are not a dog 20:08
because that smell will be everywhere very fast
lizmat is fetching perl 5.20.0 for benchmarking 20:11
20:17 brrt joined 20:22 jnap1 joined
lizmat nwc10: with 5.20.0, the "use integer" case is faster, but not much: 3.9 vs 4.4 wallclock 20:22
versus the perl 6 case (with / without MVM_SPESH_DISABLE): 0.7 vs 2.8 20:23
so the non optimized Perl 6 case is still faster
taking into account that starting perl6 is .3, it sorta becomes .4 vs 2.5, aka 6 times faster 20:24
brrt yay for super simple benchmarks :-D
lizmat and Perl 6 for that loop (without startup) is looking at 10 times faster :-)
brrt (that we can win)
lizmat lies, damn lies and statistics :-) 20:25
fwiw, super simple benchmarks are only the shape of things to come 20:27
brrt fwiw, the red zone is the 128 bytes down from the stack pointer that are 'safe to use'
jnthn Hmm 20:28
jnthn thinks he found it 20:29
brrt but only on the posix abi, not on windows
jnthn 10+ year old power brick for the speakers...
lizmat *phew* :-) 20:31
lizmat fell in love with a small USB powered bluetooth tethered box with built in battery 20:32
I'm taking it with me whenever I travel: love the sound of it, compared to pad / notebook speakers 20:33
brrt uh, i had one of those things, and sold it because didn't have a bluetooth-capable player :-) 20:39
i use a direct analog headphone-to-stereo-aux cable 20:40
lizmat uses iPhone or iPad as player :-) 20:42
brrt well, you have to have one of these then :-) 20:44
[Coke] how can I tell if I have a jit enabled moar? I reupped, and the config output didn't say one way or the other. 20:47
lizmat MVM_JIT_LOG=jit_log perl6 -e "say 42" 20:49
if the jit_log is not empty, you have JIT
[Coke] \o/ 20:50
would it be helpful to have both moar and moar-jit in the daily runs? 20:51
timotimo gist.github.com/timo/7204c6cda63e528f1ac1 ā† brrt, combined rakudo build jitlog
brrt such wow 20:52
[Coke] timotimo: presumably, each time you implement one, that changes the list potentially dramatically?
brrt unless_n, i want to do that one
[Coke] Unless_n is in that list 2x.
brrt well, yeah, that's true 20:58
oh ah
i see what you mean
hmm MoarVM doesn't quite build on haiku 21:02
21:02 cognome joined
jnthn so disappointment 21:04
insufficiently ported
plz fix before fall
brrt something wrong with probe 21:11
can't really tell why it won't work 21:13
[Coke] . o O (ugh, this failing rakudo-moar make on os x is annoying. :|) 21:14
japhb lizmat: Just have perl6-bench build you all the perl5 versions that you want, and then you can run your tests from those. I've provisionally declared that perl6-bench tests can require 5.010, but I think it will happily *build* a perl5 from way back. 21:26
timotimo [Coke]: that's the "write error" one? 21:40
jnthn: is moarvm in a state where we can just ignore argconst_s? 21:41
jnthn No, if you remove it we'll fail 21:42
timotimo but that's what we want to get to with the "named parameters in callsites" thing, aye? 21:43
[Coke] timotimo: yes, that one. 21:46
timotimo >:(
[Coke] wonder if we can get mdiep to take a look. :) 21:51
jnthn timotimo: Yeah, though it's not a huge priority :) 22:11
timotimo: It'll make the bytecode a bit smaller
[Coke] jnthn: I'm adding moar-jit to the daily runs. cool? 22:16
brrt afk 22:20
22:21 brrt left
jnthn [Coke]: Yes, cool :) 22:25
[Coke] lots of failures, btw 22:28
jnthn Oh?
Odd. It was as clean as non-jit for me. 22:29
timotimo jnthn: smaller bytecode means less ram usage ... hopefully 22:30
[Coke] jnthn: I'm not running -master -master. Might that matter? 22:59
japhb timotimo: re: your old request for being able to specify particular revisions/branches of nqp/moar when building r-m, is it sufficient if I just provide the ability to specify extra arguments for the configure stage of a build? It occurs to me that the more generic concept may be slightly wordier but simpler to implement and more useful in the long run (such as by being able to specify a JIT build) 23:02
timotimo japhb: SGTM, though it'd be nice to then have the ability to give that "thing" a particular name, too :) 23:09
jnthn [Coke]: We bumped revisions quite recently; shouldn't. 23:13
japhb timotimo: 'that "thing"'? 23:39
timotimo a given combination of a commit shasum and a bunch of options passed at build-time 23:42
jnthn 'night o/ 23:43
TimToady time perl -e 'use integer; my $i = 0; while (($i = $i + 1) <= 100000000) { 1 }' 23:44
real0m3.647s
user0m3.641s
sys0m0.002s
time perl -e 'use integer; my $i = 0; while (++$i <= 100000000) { 1 }' 23:45
real0m2.900s
user0m2.896s
sys0m0.002s
just because rakudo can't do ++$i on an int doesn't mean p5 can't :P
japhb timotimo: Hmmm, good point. 23:47
TimToady: I'm somewhat surprised that the perl5 peephole optimizer doesn't turn the first into the second anyway. 23:48
TimToady the peephole optimizer is not optimized for turning stupid code into smart code 23:49
japhb Fair enough.
TimToady p5 always has to compile and run, so only had time to turn smart code into smarter code
japhb What is it optimized for? I mean, I know it optimizes 'for (1..1000000)' into a simpler loop, rather than generating the list, but I'm not sure where that dividing line was intended to be drawn 23:50
nodnod
TimToady optimized for things that you couldn't really express
though there are a few of the others too
japhb Does it do $i++ in void context --> ++$i?
TimToady turns $i++ into ++$i in void context, for instance 23:51
japhb heh
TimToady yes
I think peephole deals with a branch to a branch 23:52
removes ops that got nulled by some other optimizations too
don't remember if that's where it substitutes specialize opcodes for $foo[1] where 1 is a literal... 23:53
most such optimizations are in the compiler proper, like substituting a join for a bunch of concats 23:54
timotimo brrt, in your blog post it says "seems to take slightly longer while using JIT than while." which should end in "without"
TimToady but as you can see from the performance graphs, a lot of work went into making sure strings, arrays, and hashes all scaled well 23:55
japhb TimToady: Yeah, which is much of why I was able to use perl5 for so much over the years. So thanks for that. :-) 23:57
TimToady p5 also relies pretty heavily on the notion that if you allocated something once, you'll probably do it again
so it caches a lot of allocations and conversions for you 23:59

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!