Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
00:07 Zoffix joined, p6bannerbot sets mode: +v Zoffix
Zoffix ZOFVM: Files=1310, Tests=153194, 150 wallclock secs (21.55 usr 3.11 sys + 3179.34 cusr 168.19 csys = 3372.19 CPU) 00:07
possibly the lowest ZOFVM time I've seen :)
Geth nqp: 58011e6a9c | (Zoffix Znet)++ | tools/build/MOAR_REVISION
[MoarVM Bump] Brings 2 commits

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...5-gad3a80c ad3a80c Fix coredump with mul_I -> div_I ops 08675c0 spesh comments: de-typed guards, lex_known, spesh plugins
00:16
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...5-gad3a80c
rakudo: b96f60ff71 | (Zoffix Znet)++ | tools/build/NQP_REVISION
[NQP Bump] 58011e6 [MoarVM Bump] Brings 2 commits

NQP bump brought: github.com/perl6/nqp/compare/2018....3-g58011e6
MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...5-gad3a80c ad3a80c Fix coredump with mul_I -> div_I ops 08675c0 spesh comments: de-typed guards, lex_known, spesh plugins
¦ rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....3-g58011e6
00:17 ZofBot joined, ChanServ sets mode: +v ZofBot, fsadfdsgsd joined, p6bannerbot sets mode: +v fsadfdsgsd
fsadfdsgsd Zoffix: test 00:17
00:17 ZofBot left
Geth roast: 22c59edd71 | (Zoffix Znet)++ | MISC/bug-coverage.t
Cover coredump in math

Closes github.com/rakudo/rakudo/issues/2280 R#2280 MVM Fix: github.com/MoarVM/MoarVM/commit/ad...0a4a2d3f12 NQP Bump: github.com/perl6/nqp/commit/58011e6a9c Rak Bump: github.com/rakudo/rakudo/commit/b96f60ff71
00:20
synopsebot R#2280 [open]: github.com/rakudo/rakudo/issues/2280 [math][regression] Core dump when dividing some Rats with denominator 2**30 by -2
MasterDuke Zoffix++ 00:22
00:22 ZofBot joined, ChanServ sets mode: +v ZofBot
fsadfdsgsd Zoffix: test 00:22
00:23 p6bannerbot sets mode: +v ZofBot, ZofBot left, ZofBot joined, ChanServ sets mode: +v ZofBot
fsadfdsgsd Zoffix: test 00:23
Zoffix grr 00:24
00:24 ZofBot left
Zoffix (Twitter killed API the bot used to use... trying to fix my spy) 00:24
00:25 plankers joined 00:26 plankers left 00:28 ZofBot joined, ChanServ sets mode: +v ZofBot 00:29 ZofBot left, Zoffix is now known as ZofBot, ZofBot is now known as ZofBot_, ZofBot_ is now known as Zoffix, ZofBot joined, ChanServ sets mode: +v ZofBot, p6bannerbot sets mode: +v ZofBot
fsadfdsgsd Zoffix: test 00:29
00:29 Zoffix left, fsadfdsgsd left 01:02 edgars_ joined, edgars_ left 01:19 fake_space_whale joined 01:20 p6bannerbot sets mode: +v fake_space_whale 01:45 kcnickerson11 joined 01:53 kcnickerson11 left 02:06 ZzZombo joined, p6bannerbot sets mode: +v ZzZombo 02:53 ZzZombo left 02:54 Remy^19 joined 02:56 gothos4 joined 02:57 gothos4 left 02:59 Remy^19 left 03:04 ZzZombo joined, p6bannerbot sets mode: +v ZzZombo 03:32 epony joined, p6bannerbot sets mode: +v epony 04:01 stmuk joined 04:02 p6bannerbot sets mode: +v stmuk 04:38 stmuk_ joined, p6bannerbot sets mode: +v stmuk_ 04:40 stmuk left 05:27 mun_ joined 05:31 mun_ left 05:39 Ven` joined 05:40 p6bannerbot sets mode: +v Ven` 05:44 Ven` left 05:57 fake_space_whale left 06:10 fake_space_whale joined 06:11 p6bannerbot sets mode: +v fake_space_whale 06:15 xniega27 joined 06:16 xniega27 left 06:19 fake_space_whale left 06:39 robertle joined 06:40 p6bannerbot sets mode: +v robertle 06:50 patrickb joined, p6bannerbot sets mode: +v patrickb 07:16 lizmat joined, p6bannerbot sets mode: +v lizmat 07:21 tardyp25 joined
lizmat Files=1254, Tests=76139, 339 wallclock secs (15.58 usr 5.33 sys + 2363.97 cusr 255.54 csys = 2640.42 CPU) 07:23
07:24 tardyp25 left 07:37 dequeues joined 07:38 p6bannerbot sets mode: +v dequeues 07:39 dequeues left 07:54 robertle left 07:57 brrt joined 07:58 p6bannerbot sets mode: +v brrt 08:13 applegal29 joined 08:14 applegal29 left 08:15 Ven` joined 08:16 p6bannerbot sets mode: +v Ven` 08:17 lizmat left 08:19 robertle joined, p6bannerbot sets mode: +v robertle 08:20 epony left
Geth nqp/truffle: 8ca4e9fdd8 | (Paweł Murias)++ | 11 files
[truffle] Add a @Global annotation to remove boilerplate

Inject things from the GlobalContext into deserializers
08:29
08:35 lizmat joined, p6bannerbot sets mode: +v lizmat 08:39 pmurias joined, p6bannerbot sets mode: +v pmurias 08:42 epony joined, p6bannerbot sets mode: +v epony 08:53 paradoxspiral20 joined 08:57 paradoxspiral20 left 09:16 xace joined 09:17 xace left 09:28 pmurias left 09:32 pmurias joined, p6bannerbot sets mode: +v pmurias 09:50 brrt left 09:56 ZzZombo left
|Tux| Rakudo version 2018.09-31-gb96f60ff7 - MoarVM version 2018.09-85-gad3a80cb6
csv-ip5xs0.936 - 0.966
csv-ip5xs-207.299 - 7.463
csv-parser21.104 - 21.480
csv-test-xs-200.422 - 0.425
test7.908 - 8.796
test-t1.832 - 1.906
test-t --race0.791 - 0.846
test-t-2031.568 - 32.424
test-t-20 --race10.923 - 11.953
10:17
10:17 ethfci_ joined
2018-09-24 15:53:41 test-t 1.997
2018-09-20 11:10:24 test-t 1.972
2018-09-18 11:16:48 test-t 1.971
2018-09-25 12:05:14 test-t 1.906
2018-09-25 12:08:28 test-t 1.832
|Tux| whistles
pompomtiepom
10:18 ethfci_ left
tyil noice 10:18
lizmat is disappointed... I was betting on below 1.8 10:19
still, not bad :-)
--race below .8 as well :-)
m: say 1971 / 1832 10:20
camelia 1.075873
|Tux| tyil that is a nice combination of noise and nice. #januskop
tyil |Tux|: its a certain way of pronouncing "nice", no intent to call the output noise :) 10:21
10:22 wraeth14 joined
AlexDaniel . 10:25
yoleaux 06:08Z <jmerelo> AlexDaniel: I would be interested.
10:26 wraeth14 left 10:59 brrt joined 11:00 p6bannerbot sets mode: +v brrt 11:38 ZzZombo joined, p6bannerbot sets mode: +v ZzZombo 11:42 ZzZombo_ joined, p6bannerbot sets mode: +v ZzZombo_ 11:43 pcdummy7 joined, ZzZombo left, ZzZombo_ is now known as ZzZombo 11:49 pcdummy7 left 11:51 davic26 joined 11:52 p6bannerbot sets mode: +v davic26 11:56 davic26 left 12:03 Ven` left 12:04 Ven` joined 12:05 p6bannerbot sets mode: +v Ven`
jnthn lizmat: I think the degree of benefit varies between machines; probably CPU cache size counts for a reasonable bit. 12:32
yoleaux 21 Sep 2018 15:13Z <Zoffix> jnthn: FYI: I took a crack at sunk `start`. github.com/rakudo/rakudo/commit/6ee5f75778 spec: github.com/perl6/roast/commit/7a426fb4a3 docs: github.com/perl6/6.d-prep/commit/c4016d2d79 `sub { start die }(); sleep ⅓` doesn't die which sucks, but I don't know how to make that work. Also I didn't use any `uncaught_handler` mentioned in 6.d-prep. Dunno if it's good or bad.
21 Sep 2018 18:25Z <Zoffix> jnthn: oops, gave wrong link to docs commit. It's github.com/perl6/doc/commit/df0b71d8d6
21 Sep 2018 22:15Z <lizmat> jnthn: what are your feelings to adding a sub ord(str $s) { nqp::ord($s) } candidate ? Looks like it makes it 1.8x as fast
21 Sep 2018 22:16Z <lizmat> jnthn: also: I would like to add a "pos" parameter to ord(), so we can pass that on directly to nqp::ordat
jnthn .tell Zoffix I was originally thinking of doing it by tweaking the call to Promise.start to pass some extra named arg that'd then cause it to set up the handler. About uncaught_handler, that's a property of a Scheduler; thus, we'd respect the scheduler-level handler that was set (if any). 12:36
yoleaux jnthn: I'll pass your message to Zoffix.
jnthn .tell Zoffix Or alternatively a `start-foo` method (never found a good "foo" word yet; "unsupervised" isn't quite it...) 12:37
yoleaux jnthn: I'll pass your message to Zoffix.
jnthn .tell Zoffix Anyway, we already look up the scheduler inside of .start so we have it handy in there, plus it's less QAST generation required :) 12:38
yoleaux jnthn: I'll pass your message to Zoffix.
jnthn m: say ord("") 12:39
camelia Nil
jnthn .tell lizmat How did you get the speedup, and are you sure it's not 'cus the empty string check is missing? :) I'm a bit concerned about ord with a position because what are the units? 12:40
yoleaux jnthn: I'll pass your message to lizmat.
lizmat . 12:48
yoleaux 12:40Z <jnthn> lizmat: How did you get the speedup, and are you sure it's not 'cus the empty string check is missing? :) I'm a bit concerned about ord with a position because what are the units?
lizmat jnthn: yeah that could well be: share your concern about units in 'ord'
12:49 orionstein19 joined 12:50 p6bannerbot sets mode: +v orionstein19 12:52 orionstein19 left
brrt jnthn: any idea how I can get myself into a state wherein MVMInstance->threads points to an out-of-date pointer 12:58
(that ought to be forwarded but isn't) 13:01
13:08 sab110- joined 13:09 sab110- left
jnthn brrt: I'm pretty sure there's a mutex you better hold if you're dealing with it... :) 13:18
yoleaux 12:46Z <Zoffix> jnthn: feel free to revert my start-in-sink work. It just a fun experiment. I won't shed tears seeing it gone
dogbert11 jnthn: have you forgotten to merge github.com/rakudo/rakudo/commit/5f...6432b610a8 or am I just totally confused? 13:26
jnthn lizmat: ord is a codepoint level operation 13:27
lizmat: I think ordat takes a grapheme index; I'm not sure if this is generally very sane as a think to expose 13:28
*thing
lizmat yeah, I realized that after I asked the question :-)
13:29 iclon13 joined, iclon13 left
Geth nqp: 89c8de7987 | (Paweł Murias)++ | src/vm/js/nqp-runtime/runtime.js
[js] Accept modules in the libpath for relative loading
13:34
nqp: 5d11d7d1f5 | (Paweł Murias)++ | 2 files
[js] Bump package.json versions to what we released
nqp: 3794970971 | (Paweł Murias)++ | src/vm/js/nqp-runtime/runtime.js
[js] Make perl6-runtime loading work better in the browser
brrt hmm, thing is, I think the gc is holding that mutex... 13:57
jnthn dogbert11: Didn't forget, just didn't get around to it 14:06
oh, it looks like somebody else might have done it? 14:13
Hmm, odd, it doesn't apply cleanly... 14:16
Yeah, somebody seems to have folded that change into another change 14:20
oh, not quite...hmm 14:21
oh...I see 14:22
dogbert11 is confused :) 14:25
jnthn So was I; so it turns out there was a refactor around that code that did something my change did :) 14:26
Anyway, fixed/merged and verified it speeds up new a tad and spectesting now
dogbert11 coool
Geth rakudo: 464a86b185 | (Jonathan Worthington)++ | src/Perl6/World.nqp
Use a simple atkey in generated BUILDALL

We're already using the existskey op, so may as well go the whole hog and have simpler, faster code here.
14:31
lizmat argh: should have noticed that when I did that refactor 14:43
jnthn :)
Spesh is making quite a meal of .new calls...so hpoeful I can get some more speedups in this area. 14:44
14:44 bs33817 joined
diakopter giggles at "quite a meal" 14:45
14:45 p6bannerbot sets mode: +v bs33817
jnthn Anyone who knows Perl 5 as well as Perl 6: are the two in gist.github.com/jnthn/67e390cbb7ab...f28684240c a reasonably fair comparison? 14:46
14:47 bs33817 left
|Tux| why not $total += …? 14:47
otherwise, I'd say yes, quite comparable 14:48
jnthn Dunno, but it's the same in both :) 14:49
|Tux| as a perl5 author, I would replace the for with a while to prevent range allocation in older perls
jnthn Yeah, I'm going for "the thing the typical developer without knowledge of performance tricks might write" :) 14:50
14:50 brrt left
jnthn Anyway, reason I asked for a check is that I was expecting Rakudo to run this code quite a lot slower than Perl 5. Turns out it's 0.96 (Perl 5) vs 1.43 (Perl 6), which is a factor of about 1.4 14:51
|Tux| which perl5? 14:52
jnthn Whatever my systme as
5.22
*system has
That's a bit newer than I expected :)
14:53 Zoffix joined, p6bannerbot sets mode: +v Zoffix
Zoffix jnthn: I doubt many Perl 5 programmers would write it like that tho. They'd use Moo/Mew/Mojo::Base/Class::Accessors (forget the exact name for the last one) 14:54
So I'd argue that bench gives Perl 5 too much leaway :)
jnthn Zoffix: I've seen plenty like that in the wild. :-) 14:55
But yes, point taken. 14:56
|Tux| jnthn, I'd change «package MAIN;» to «package main;»
jnthn haha...apparently I speak Perl 5 with a thick Perl 6 dialect by now :) 14:57
Thanks :)
Makes no significant difference to the time, though :)
Zoffix jnthn: cpanm -vn Mojolicious; Then gist.github.com/zoffixznet/cef32c3...149f649a47
Is it slower/faster?
|Tux| my perl5.28.0 is about 1.88 times faster than perl6
Zoffix I guess I can measure myself on HEAD-ish commit 14:58
|Tux| this was the perl6 checkout I used for the timings this morning
dogbert11 |Tux| then you missed out on an opt jnthn merged a few minutes ago 14:59
jnthn Zoffix: Around 1.12s
So, between the two
Though easier for me to beat ("on my machine") :P
|Tux| I'll pull
Zoffix I get Perl 5 2.11x as fast than P6 with 2018.08-125-g38b198c and 5.26 15:00
(with Mojo::Base version of p5 script)
15:00 argusbr joined
jnthn Maybe 5.26 has some nice speedups :) 15:01
15:01 argusbr left
dogbert11 Zoffix: and with 2018.09-32-g464a86b18 ? 15:02
jnthn Zoffix: Ohh...I misread the date, that means you don't have the postrelease-opts merge in MoarVM, I guess
Zoffix Right
jnthn And that'll make a difference :) 15:03
Zoffix dogbert11: don't have anything that recent and g2g too :)
15:03 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci Rakudo build failed. Jonathan Worthington 'Use a simple atkey in generated BUILDALL 15:03
travis-ci.org/rakudo/rakudo/builds/432983869 github.com/rakudo/rakudo/compare/b...4a86b185fa
15:03 travis-ci left, Zoffix left
jnthn Anyway, thanks all :) 15:03
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
jnthn goes to figure out why spesh is doing LTA things on this code
|Tux| Rakudo version 2018.09-32-g464a86b18 - MoarVM version 2018.09-85-gad3a80cb6
csv-ip5xs0.945 - 0.963
csv-ip5xs-207.412 - 7.695
csv-parser20.819 - 21.081
csv-test-xs-200.423 - 0.431
test7.672 - 8.718
test-t1.770 - 1.824
test-t --race0.822 - 0.831
test-t-2030.061 - 31.339
test-t-20 --race11.835 - 12.080
15:11
diakopter lizmat: u were right
jnthn Hm, is 1.770 a new low again? :) 15:12
|Tux| yep
diakopter lizmat predicted 0.8
dogbert11 very impressive numbers 15:13
|Tux| my perl5.28.0 is 1.72715 x faster than this perl6 15:14
on those two o.pl examples
my perl5.22.0 is 1.52656 x faster than this perl6 15:15
I ran all tests 4 times 15:16
my perl5.10.1 is 1.06242 x faster than this perl6 ← that should be an easy target then 15:18
15:25 Zoffix joined, p6bannerbot sets mode: +v Zoffix
Zoffix With HEAD rakudo, I get P5 1.27x as fast as P6 15:25
15:28 fake_space_whale joined 15:29 p6bannerbot sets mode: +v fake_space_whale 15:30 robertle left 15:31 patrickb left
Geth tap-harness6: 5009aed9bc | (Leon Timmermans)++ | META6.json
Bump version to 0.0.4 for coloring
15:32
15:32 lizmat left
|Tux| perl6 0.00 0.00 18.47 0.22 1.0000 15:35
perl5.8.8 0.00 0.00 18.95 0.02 1.0260
perl5.10.1 0.00 0.00 17.31 0.01 0.9372
perl5.12.2 0.00 0.00 14.98 0.00 0.8110
perl5.14.1 0.00 0.00 14.69 0.03 0.7953
perl5.16.2 0.00 0.01 16.15 0.02 0.8744
perl5.18.2 0.00 0.00 13.52 0.01 0.7320
perl5.20.0 0.00 0.00 13.56 0.01 0.7342
perl5.22.0 0.00 0.00 12.07 0.00 0.6535
perl5.24.1 0.00 0.00 10.66 0.01 0.5772
perl5.26.2 0.01 0.00 9.96 0.01 0.5393
perl5.28.0 0.00 0.00 10.57 0.01 0.5723
so, on o.pl perl6 is already faster than perl5.8.8 :) 15:36
|Tux| applies grains of salt
Zoffix :D
<Marketing> Perl 6 is faster than Perl 5 at object creation!!! 15:37
jnthn Well, give me a chance to make this more indisputably true :P 15:39
Zoffix jnthn++
|Tux| script is still there, I can run it again 15:40
jnthn m: say 1.22 / 1.43
camelia 0.853147
jnthn Already found 15% off it, provided the change survives spectest etc.
Zoffix \o/ 15:41
15:41 Zoffix left 15:50 Ven` left
|Tux| commutes 15:55
15:58 Ven` joined, fake_space_whale left 15:59 p6bannerbot sets mode: +v Ven` 16:01 brrt joined 16:02 p6bannerbot sets mode: +v brrt 16:07 lizmat joined, p6bannerbot sets mode: +v lizmat 16:09 Ven` left 16:34 robertle joined 16:35 p6bannerbot sets mode: +v robertle 16:57 flyback3 joined 16:58 p6bannerbot sets mode: +v flyback3 17:00 flyback3 left
jnthn Darn...about 2% off equality. Though guess that means I'm handily beating the Mojo::Base one :P 17:24
Geth rakudo: f989b26282 | (Jonathan Worthington)++ | src/vm/moar/ops/perl6_ops.c
Don't use _DECONTED spesh fact

It's going away in an upcoming MoarVM change.
17:28
rakudo: 74ca05f284 | (Jonathan Worthington)++ | src/core/Mu.pm6
Don't use nqp::usecapture in `new`

It prevents argument optimization, which in turn prevents lots of specializations that might take place in the normal path of `new` where `bless` is not overloaded (which will be nearly all the time). With this change, plus upcoming MoarVM changes, a specialized `new` will be possible to inline.
rakudo: 2fd8ffe56a | (Jonathan Worthington)++ | src/Perl6/World.nqp
Avoid repeated hash access in BUILDALL

We never have an nqp::null at Perl 6 level, so it's reliable to use null testing here, getting us down to a single hash lookup.
nqp: fd17098d60 | (Bart Wiegmans)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
Add 'fork' opcode for MoarVM
17:38
17:45 brrt left
pmurias jnthn: comparing to Perl 5 OO frameworks doesn't seem fair ;) 17:47
OTOH they are a baseline of super slow but still acceptable to someone ;) 17:48
jnthn pmurias: My original benchmark uses no framework :)
17:48 Zoffix joined, p6bannerbot sets mode: +v Zoffix
Zoffix pmurias: why? Who the hell writes manual attribute accesses these days? 17:48
jnthn And at least for the example considered, the framework overhead wasn't much 17:49
(The one Zoffix++ provided, I mean)
Zoffix jnthn: confirming: P5 with M::B is now slower! And P6 version is now 1.04x as fast
jnthn :) 17:50
Zoffix jnthn++
jnthn Still quite a bit more optimization to be had, but higher hanging fruit than today. :)
Zoffix jnthn: BTW, people keep asking: why were special operators made for atomicint instead of compiler automagically converting, say, postfix:<++> on atomicint to an atomic operation? 17:51
dogbert11 huh, some of my bencharks see a massive improvement 17:53
jnthn Zoffix: Because atomic operations should stand out in the code, and because in Perl 6 we give different semantics different operators (== vs eq for example) and an atomic increment seems sufficiently different. 17:56
Zoffix Thanks.
jnthn Zoffix: Oh...
Zoffix: But you *can't* write an overload on native types also :P
Zoffix yeah :) 17:57
jnthn But still, even if we found some way to make that happen for the container case, I think the two previous reasons will still stand :)
Zoffix Also, it'd be easy to make a mistake to assume something like *= would also be atomic, just because += is
jnthn Atomic ops are usually used in high performance code; having things that cause a memory barrier stand out is also worthwhile. 17:58
Dinner time; I'm done for today, so if anyone wants to bump, feel free :)
o/
Zoffix \o
I'll bump 17:59
dogbert11 jnthn+++ some of my programs are more than twice as fast!!! 18:00
it seems to have been one of the MoarVM changes which accomplished that 18:01
Zoffix woo :) 18:02
18:02 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci Rakudo build passed. Jonathan Worthington 'Avoid repeated hash access in BUILDALL 18:02
travis-ci.org/rakudo/rakudo/builds/433066505 github.com/rakudo/rakudo/compare/4...d8ffe56ad1
18:02 travis-ci left
Geth rakudo/js: 7865d36c29 | (Paweł Murias)++ | src/vm/js/perl6-runtime/package.json
[js] Update perl6-runtime version
18:02
[Coke] yay
Geth nqp: 3ac7f23e54 | (Zoffix Znet)++ | tools/build/MOAR_REVISION
[MoarVM Bump] Brings 5 commits

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...0-gb5eb48c b5eb48c [fork] Fix corruption in threads list 8501e2e Fix off-by-one in multi cache spesh lookup 5103e9f Simplify/improve optimization of decont 196fa22 Optimize eqaddr into a constant if possible 3893a6c Perform parameter logging at entry time
18:10
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...0-gb5eb48c
rakudo: ace87cb5d9 | (Zoffix Znet)++ | tools/build/NQP_REVISION
[NQP Bump] Brings 5 commits

NQP bump brought: github.com/perl6/nqp/compare/2018....8-g3ac7f23 3ac7f23 [MoarVM Bump] Brings 5 commits fd17098 Add 'fork' opcode for MoarVM 3794970 [js] Make perl6-runtime loading work better in the browser 5d11d7d [js] Bump package.json versions to what we released ... (8 more lines)
rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....8-g3ac7f23
AlexDaniel unassigned from jnthn Issue Series of perf regressions on 2018-07-09 github.com/rakudo/rakudo/issues/2210

Make 1...10 and 10...1 about 75x as fast
for 1...10_000_000 and 10_000_000...1 respectively
Bypass the whole SEQUENCE mechanism by optimizing internally to 1..10 and (1..10).reverse and profit from those optimizations.
Zoffix ZOFVM: Files=1310, Tests=153195, 152 wallclock secs (21.78 usr 3.48 sys + 3228.48 cusr 170.28 csys = 3424.02 CPU)
Files=1310, Tests=153195, 148 wallclock secs (21.69 usr 3.32 sys + 3165.78 cusr 159.03 csys = 3349.82 CPU) 18:14
ZOFVM: Files=1310, Tests=153195, 148 wallclock secs (21.69 usr 3.32 sys + 3165.78 cusr 159.03 csys = 3349.82 CPU)
ZOFVM: Files=1310, Tests=153195, 149 wallclock secs (22.06 usr 3.30 sys + 3191.77 cusr 160.82 csys = 3377.95 CPU) 18:17
18:17 Zoffix left
japhb can't wait to see the *next* test-t run. :-) 18:19
jnthn++ # Excellent improvements today!
[Coke] tries to run pmurias' in-browser example and is foiled by his corporate security. bah 18:21
18:21 AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel
pmurias [Coke]: anything resonable we should do avoid corporate security from cracking down on rakudo.js? 18:24
[Coke]: or is npm install something the problematic part 18:26
[Coke] it's the npm install, and then the cert handshakes.
I'm sure it's eventually fixable, but it means I'll test this out on the home machine first. :)
(totally not your fault/problem) 18:27
[Tux] perl6 13.99 0.22 1.0000 18:30
perl5.8.8 18.98 0.02 1.3371
perl5.10.1 17.35 0.01 1.2217
perl5.12.2 15.19 0.01 1.0697
perl5.14.1 14.71 0.00 1.0352
perl5.16.2 16.70 0.01 1.1759
perl5.18.2 14.29 0.01 1.0063
perl5.20.0 14.13 0.02 0.9958
perl5.22.0 12.26 0.01 0.8635
perl5.24.1 10.69 0.02 0.7537
perl5.26.2 10.29 0.02 0.7255
perl5.28.0 10.69 0.02 0.7537
jnthn, proud? 18:31
lizmat [Tux]: what benchmark is this ? 18:32
18:33 AlexDaniel left, AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel
[Tux] gist.github.com/jnthn/67e390cbb7ab...f28684240c 18:33
lizmat ah, ok 18:34
18:36 undersightable6 joined, ChanServ sets mode: +v undersightable6, reportable6 joined 18:37 p6bannerbot sets mode: +v undersightable6, p6bannerbot sets mode: +v reportable6
lizmat [Tux]: if I run that p6 benchmark, I see 1.3 seconds wallclock, not 13 ? 18:38
perhaps it should be 10_000_000 ?
hmmm... that runs at 10.5 for me
the perl 5 version at 10M runs in 11.3 for me (5.20.0) 18:41
[Tux] tux.nl/Files/o-time.pl
1.3 * 10 = 13, right? :) 18:42
lizmat yeah, but the 10M runs in 10.5 / 11.3 for me
AlexDaniel uplifting stuff found by dogbert11++ 18:43
c: ace87cb5d9^,ace87cb5d9^,ace87cb5d9,ace87cb5d9 gist.githubusercontent.com/AlexDan...stfile1.p6
committable6 AlexDaniel, Successfully fetched the code from the provided URL
AlexDaniel, ¦ace87cb5d9^: «3.3762329␤» ¦ace87cb5d9^: «3.4930701␤» ¦ace87cb: «0.7826624␤» ¦ace87cb: «0.8347201␤» 18:44
AlexDaniel R#2210
synopsebot R#2210 [open]: github.com/rakudo/rakudo/issues/2210 [perf][regression][severe] Series of perf regressions on 2018-07-09
AlexDaniel that's this bump: github.com/rakudo/rakudo/commit/ac...5b952f1093
so that's more than 4x as fast 18:45
although only 2.6x as fast when compared to rakudo 2018.06 18:46
dogbert11 so the perf regression is fixed and then some
lizmat using native ints for the attributes and the total in jnthn's benchmark, makes it go from 10.5 to 8.0 for me 18:48
dogbert11 it will be very interesting to se [Tux] next run tomorrow
lizmat and I think that is a totally valid thing to do
which would make Perl 6 faster than *all* of the Perl 5 versions tested
[Tux] lizmat, I did that too (Int's), but that is unfair 18:52
lizmat [Tux]: why ?
Perl 5's IV's are basically native ints 18:53
[Tux] <jnthn> Yeah, I'm going for "the thing the typical developer without knowledge of performance tricks might write" :) 18:54
that's why
lizmat ok, I guess we need a pragma :-)
that automatically changes my Int $a to my int $a :-) 18:55
pyrimidine lizmat: So, if I'm reading the above correctly, the new benchmarks are saying that (using [Tux]'s gist) that we're about even with perl 5.20? 19:00
lizmat yes 19:01
pyrimidine Um, wow, that's very impressive! jnthn++
lizmat for that particular benchmark, yes
pyrimidine true, but that's a great data point :)
pyrimidine slinks back off to the world of bioinformatics... 19:02
pmurias is the nqp::if stuff in the setting faster then if blocks? 19:15
I should think that over tommorow when I'm less tired 19:18
lizmat pmurias: it might not be anymore :-)
jnthn lizmat: Don't think we need a pragma if we can keep narrowing the difference. :) 19:19
Wow, seems I've improved more than I expected today :)
lizmat yeah... :-) 19:22
samcv jnthn: i've been thinking of how to do the byte order mark. and i've come up with a workable i think solution that shouldn't slow things down in other cases
lizmat looking good !
jnthn samcv: Yeah, it's tricky...what did you come up with?
samcv so i'm thinking we will add more data to moarvm's filehandle's so we can have a BOM y/n setting. and each write it will check if that variable is set. and only then will it check if the handle is seekable and if .tell is at 0 19:23
and in that case it'll write out a BOM before then writing the buffer it was originally asked to do
though it has the issue of what if you did .write and were explicitly writing binary data to a utf16 filehandle..
but otherwise works
[Tux] if you change the yes/no indicator to an int, you kan keep the type of the bom 19:24
jnthn samcv: Hm, but we carefully detangled encoding from I/O handles...I'm not keen to entangle that again
[Tux] github.com/Tux/Text-CSV_XS/blob/ma..._XS.md#bom
jnthn samcv: What was the problem with writing a BOM at file open time, ooc? That seemed like a reasonable solution, provided there was a way to ask not to. 19:25
19:25 AlexDaniel left, AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel
samcv well. what if you open a file and then seek? 19:25
then it will write data without being asked to 19:26
though that could be doable i suppose, and just that be a caveat... but. perl 5 doesn't write the BOM until you write any data
jnthn Can we not just stick self!write-bom() if $!bom-write-needed; into `write` and see if it has any measurable effects? 19:27
I mean, after JIT it can't be *that* much more expensive than having the branch in the C code. 19:28
walk, bbs 19:29
samcv yeah i guess i can try that too
jnthn (Agree with your point on seek, though)
samcv i very much don't want a non-destructive operation to become destructive. as it could cause issues with people assuming an open won't destroy their file 19:30
ttysoon
19:41 AlexDaniel left 19:53 patrickb joined 19:54 p6bannerbot sets mode: +v patrickb
pmurias lizmat: using regular Perl 6 instead of the lovecraftian Lisp/Perl hybrid would be a huge readability/writability win 19:54
lizmat: I'll investigate that more tommorow ;) 19:55
lizmat pmurias: I'm really looking forward to the day that we can rip out all of the lovecraftian abominations I have put in
but only if performance does not suffer (too much, anyway) 19:56
20:16 gfldex joined 20:17 p6bannerbot sets mode: +v gfldex
lizmat seemed like a nice day for YABO (Yet Another Big Optimization) 20:21
patrickb Hi everyone! 20:23
20:24 kou10 joined, POGtastic joined
lizmat patrickb o/ 20:24
20:25 p6bannerbot sets mode: +v kou10, kou10 left, p6bannerbot sets mode: +v POGtastic 20:26 POGtastic left
lizmat jnthn timotimo : sub make now consists of: nqp::bindattr(nqp::decont(nqp::getlexcaller('$/')),Match,'$!made',made) 20:28
I was thinking of having the static optimizer change that to nqp::bindattr($/,Match,'$!made',made) 20:29
which would save a staticcall and a getlexcaller
which would make parsing grammars with actions perhaps a bit faster, like R:I:JSON atm 20:30
Geth rakudo: 5a974cb9ee | (Elizabeth Mattijsen)++ | 6 files
Clean up some trailing whitespace
20:37
20:41 patrickb left 20:48 robertle left
lizmat jnthn timotimo nvm: hacking it manually into R:I:JSON doesn't show any gain 20:52
if there is any, it disappears in the noise 20:53
20:57 HappyLoaf29 joined 20:58 p6bannerbot sets mode: +v HappyLoaf29 21:01 HappyLoaf29 left
jnthn back 21:04
Forgot I had homework to do :)
samcv: tbh, I'd only considered doing it for :w, which I figure is for new files or replacing existing ones. :) 21:05
samcv: I think the "fist write" is the way to go
*first
samcv: I'd do it in Rakudo's handle class and if it's too much slowdown we try and figure out how to solve that. Maybe it'll just be noise though among the I/O itself.
samcv ok :) 21:09
also, if you do .write should it not do the BOM then. only on print/say? 21:10
jnthn Oh, right. :)
Yes, indeed.
samcv also i don't think it checks position each write?
so in this case we'd have to check if it was utf16, and then after check check the tell i guess 21:11
but hopefully only one condition is needed for 99% of cases
jnthn I'd just have an attribute if we should consider writing a bom on the next print/say
samcv also is writing different endianess the right thing to do on different endianess machines
i am not completely sure 21:12
jnthn We can clear that on seek I guess
Hmm, dunno what precedent is there. My intuition would be to write native endian if not given more specific instructions.
But I/O doesn't always follow intuition... :) 21:13
At least, not mine :)
samcv :)
i mean this seems to work alright how i have it. i *think* it works on big endian though i need to actually check that
if we "string".encode('utf16be/le') and it encodes to a DIFFERENT endianess than the host machine, you will get a buffer which has swapped endianess. so Buf.gist will show different numbers from what the unicode codepoints are 21:14
and then when we write to disk we don't have to do anything fancy
though it does result in different output in .gist on different endianess machines, but i think that's OK, unless others think differently 21:16
jnthn I sometimes wonder if buf shoulda just always been bytes... :) 21:22
21:35 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke 21:36 MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke
MasterDuke lizmat: while you're working on Ranges and such, any further thoughts on github.com/rakudo/rakudo/pull/2228 ? fwiw, i'm also in the middle of getting a patch to work that re-writes `for ^$a` into `while(...)` for Int (i.e., non-native) variables 21:39
21:39 e4xit0 joined 21:40 p6bannerbot sets mode: +v e4xit0 21:43 e4xit0 left 21:44 pmurias left 21:47 dyc324 joined 21:48 p6bannerbot sets mode: +v dyc324, dyc324 left 21:52 DarkUranium24 joined, p6bannerbot sets mode: +v DarkUranium24 21:53 DarkUranium24 left 21:57 perlawhirl3 joined 21:58 p6bannerbot sets mode: +v perlawhirl3, perlawhirl3 left 22:04 pmurias joined, p6bannerbot sets mode: +v pmurias 22:12 fakeful joined 22:13 p6bannerbot sets mode: +v fakeful, fakeful left 22:14 clavi19 joined, p6bannerbot sets mode: +v clavi19 22:17 clavi19 left 22:26 ilmostro14 joined 22:27 p6bannerbot sets mode: +v ilmostro14 22:28 engblom22 joined 22:29 engblom22 left, ilmostro14 left 22:47 benoliver99927 joined, bamtan22 joined 22:48 p6bannerbot sets mode: +v benoliver99927, p6bannerbot sets mode: +v bamtan22 22:49 benoliver99927 left 22:52 bamtan22 left 22:53 gema27 joined, gema27 left 22:54 pmurias left
japhb jnthn, samcv: FWIW, my idea was to skip the check per write, and just do the need-BOM check at handle open time -- in Perl 6 open() code, not MoarVM or NQP code -- and only write the BOM at open time on :w (open for write with truncate, which is an explicitly mutating operation) with encoding set to one of the two encodings that needs a BOM. 23:09
Any other case, including opening it binary and .write'ing an encoded buffer, if you want a BOM, you have to do it yourself. 23:10
samcv that is attractive. though i still don't like having the file being altered by just an open operation 23:17
23:18 saul10 joined 23:19 p6bannerbot sets mode: +v saul10 23:20 saul10 left
japhb samcv: But open for truncate already mutates it at open time. 23:22
23:27 sph22 joined, p6bannerbot sets mode: +v sph22 23:31 sph22 left 23:34 pwcjr4 joined, pwcjr4 left 23:38 Gohla21 joined 23:39 p6bannerbot sets mode: +v Gohla21 23:41 Gohla21 left 23:44 Guest64100 joined 23:45 p6bannerbot sets mode: +v Guest64100 23:48 Guest64100 left 23:51 danlentz16 joined, danlentz16 left