bartolin oops, yesterday a typo managed to sneak into jvm specific code: github.com/rakudo/rakudo/pull/784 05:29
dalek kudo/nom: f060da0 | bartolin++ | src/core/control.pm:
Fix typo in JVM specific code
 07:39
kudo/nom: 7fabb57 | niner++ | src/core/control.pm:
Merge pull request #784 from usev6/patch-1

Fix typo in JVM specific code
[Tux] O...M...G... !!! 09:35
This is Rakudo version 2016.05-103-g7fabb57 built on MoarVM version 2016.05-18-g1339332
test 17.581
test-t 9.785
csv-parser 21.295
Who is to receive some beer? 09:36
nine It is really happening! 09:37
bartolin wow, lizmat++ 09:49
tadzik :o 09:58
lizmat++
RabidGravy Ooooog 10:01
nine @s@s@s @s1qa23x44444444@s.@sp@s[@s;}" 10:02
Ooops...sorry, cleaning keyboard
RabidGravy so the 25% speed-up is nice to have in the back pocket, I think I'd better be testing all the modules against this 10:07
stmuk_ I might have to rewrite my YAPC talk "Lying with Benchmarks - Perl 6 is Faster!" :-( 10:28
lizmat sorry stmuk_ :-) 10:35
[Tux] stmuk_, you could do as I did: make the performance slide dynamic, so hitting that slide is always up-to-date :) 10:51
dalek kudo/nom: 6e62c40 | lizmat++ | src/core/Mu.pm:
Give Mu.BUILD_LEAST_DERIVED the same treatment

Not sure how this will affect performance, but it seemed like the right thing to do in light of the performance gain that the Mu.BUILDALL work gave us.		 11:24
jnthn lizmat: It'll make mixins faster, if you're looking for how to exercise it ;) 11:43
lizmat runtime mixins you mean ?
jnthn Yes 11:45
.oO( there are others? :))
lizmat ok, I'll try some
jnthn (I call `class Foo does Bar { }` composition rather than mixing it, because the semantics are rather different.)
lizmat jnthn: why is BUILDALL taking *@ and not doing anything with it ? 12:09
is this some interface thing I don't know about ?
actually, same for bless ?
dalek kudo/nom: c6faf9b | lizmat++ | src/core/Iterable.pm:
Streamline Iterator.flat
 12:15
jnthn Yeah, that Parent{ ... } interface we're not supporting yet 12:20
Will need to do that at some point...
lizmat until then, I can take it out of bless and BUILDALL ? 12:21
or perhaps turn bless into a multi ? 12:22
[Tux] This is Rakudo version 2016.05-104-g6e62c40 built on MoarVM version 2016.05-18-g1339332 12:23
test 17.559
test-t 9.734
csv-parser 20.887
just for continuous feedback 12:24
RabidGravy well I've just tested 55 modules with the latest and it all works :) (probably covers about 10% of the ecosystem with dependencies) 12:30
lizmat *phew* 12:31
RabidGravy though it hasn't made any difference to the length of time that takes (however I can't remember how many new modules and what changes to the numbers of tests since I last ran it) 12:34
dalek kudo/nom: d76c3fb | lizmat++ | src/core/DateTime.pm:
Fix positional in call to bless: it should be named
 12:45
kudo/nom: 4179bdc | lizmat++ | src/core/Mu.pm:
Make object construction again 1.8x faster

It turns out that Mu.bless and Mu.BUILDALL were taking positional parameters that were never actually given (apart from one arguably faulty spectest). This in turn caused flattening on an empty array to be performed. And then get passed to BUILDALL, which in turn didn't do anything with it. According to spec, bless should take autovivifying type objects, but this has not been implemented.
Until that happens, it would seem we can use the performance boost of not allowing positionals towards Mu.bless and Mu.BUILDALL, instead of silently eating them and not doing anything with them.		 12:59
lizmat [Tux]: ^^^ :-)
probably won't make it below 9 yet, but there's hope :-) 13:00
dalek ast: f1dcc25 | lizmat++ | S12-construction/construction.t:
Fix faulty test of .bless
 13:01
ast/6.c-errata: 93f6013 | lizmat++ | S12-construction/construction.t:
Fix faulty .bless test
 13:02
[Tux] This is Rakudo version 2016.05-107-g4179bdc built on MoarVM version 2016.05-18-g1339332 13:10
test 17.101
test-t 9.734
csv-parser 20.817
lizmat hmmm... that's eh, disappointing ? 13:14
[Tux] timotimo, I realized after I counted my return statements, that the returns are most likely not the hot-spots that are still causing a slowdown: it is much more likely my "next" statements are the cause of slowness 13:18
psch nine: from the looks of it, the way i'm stuffing the J::Class into $*W doesn't carry into the EVALs 13:45
which i take it means we get a new World with each EVAL
dalek kudo/nom: 51e1a27 | lizmat++ | src/core/List.pm:
Make List.from-slurpy-flat about 10% faster

Which directly translates to the same efficiency gain for any call to a sub/method with a slurpy array.		 13:52
psch also of note, the LinkageError apparently happens due to the second EVAL 14:44
probably because we've finished writing the J::Class for the first one already and loaded it afterwards
which means putting the different EVALs into the same class can't work with the current structure at all, unless i'm missing something 14:45
nine psch: yes, every compilation unit (including EVALs) gets its own world. Part of my EVAL fix was to share specific data between those worlds 14:54
psch right, yeah, i remember bits of that 14:56
ah, so that'd also be the peg to hang the JCLASS on, assuming i'm wrong and stuffing multiple EVALs into the same JCLASS works
timotimo [Tux]: you are right. my over-simplified test with and without a useless next give a difference from 10s to 17s 15:05
er, i mean, you could be right; next is slow, but i can't know if that's your bottleneck or not 15:06
[Tux] his is Rakudo version 2016.05-108-g51e1a27 built on MoarVM version 2016.05-18-g1339332 15:11
test 17.157
test-t 9.584
csv-parser 21.411
timotimo, I'm sure it is
timotimo it's probably not possible to rewrite your code to use if/else instead of skipping with else? 15:12
just for performance test, i mean 15:13
lizmat timotimo: I looked at doing that, but it's not simple :-( 15:28
timotimo yeah, i feared that
dalek kudo/nom: 6bcf4dd | lizmat++ | src/core/Junction.pm:
Make Junction grok completely empty List states

While attempting to reduce allocations for empty Lists, I found that the Junction code could not cope very well with an unallocated
  $!reified in its states List. This is now a thing of the past.		 15:31
timotimo ooooh
good catch
jnthn Hm, I can likely speed up next during my hacking time next week, given I've been working on return :) 15:32
dalek kudo/nom: 7584139 | lizmat++ | src/core/List.pm:
Make List.from-slurpy not allocate when not needed
jnthn has nearly finished a blog post 15:33
Should get it finalized and posted after making dinner. :)
timotimo speed up next next? 15:34
lizmat ++jnthn
cognominal jnthn++ 15:37
mst (((jnthn)))++ 15:38
[Tux] jnthn++ 15:47
lizmat++
psch i'm thinking that $*CODEREFS is actually what should be shared via mast_frames 15:59
...i'm *not* sure that's fully thought out or sensible, though 16:00
FROGGS o/ 16:04
timotimo o/ 16:07
FROGGS ummm 16:08
what spectest target should I use?
m-spectest m-spectest5 m-spectest6 m-spectest_full5 m-spectest_full6
mst one of those 16:09
probably
</not-helping>
FROGGS heh
timotimo i usually just m-spectest
or rather, spectest
FROGGS k
nine FROGGS: spectest passed, test passed, panda's bootstrap works and panda install Task::Star is going on just fine :) 16:18
timotimo that sounds encouraging 16:19
nine Successfully installed Task::Star 16:20
[Tux] next is -Duselongdouble support? 16:22
FROGGS nine: with my patch?
[Tux] hides
timotimo [Tux]: as i may have said before, it requires that piece of design in moarvm that'll allow things longer than 64bit in registers 16:23
[Tux] someone suggested a plugin might do it
nine FROGGS: yes
FROGGS nine: awesome! thanks for testing :o)
[Tux] module/... whatever
FROGGS nice to have something to commit after several months :o)
nine FROGGS: your patch and merged rt128156_fix_precomp_deps_validation branch which should fix time stamp issues on file systems from the stone age
FROGGS: that patch takes a huge load off my shoulders :) 16:24
timotimo in theory, yeah. you'll have to treat every long double to be placed "behind" a pointer, and have a C function written for every kind of operation you want to do on long doubles
that will work
but it'll also suck :)
dalek kudo/nom: d0a0016 | FROGGS++ | src/core/CompUnit/PrecompilationRepository.pm:
fix content of .precomp/.../*.rev-deps files

These files contained wrong ids, namely several occurrences of the id of the file itself.		 16:28
timotimo i wonder if this has a performance implication, too? like, at all? 16:29
FROGGS hmmm, my imagination is not good enough to guess 16:31
dalek kudo/nom: 491af60 | niner++ | src/core/CompUnit/Precompilation (3 files):
Fix precomp dependency checks on file systems with coarse timestamps.

Replace fragile timestamp check by checksums for deciding whether a precompiled dependency is still the same.
Many thanks to pmurias++ for suggesting using a hash!		 16:34
nine With these two patches, rt128156 should hopefully be history :)
dalek kudo/nom: bca0daa | lizmat++ | src/core/List.pm:
Faster List.from-slurpy-onearg (from 20% upto 4x)

Which directly translates to same performance gains for the
  (+@list) signature: 4x for no parameters, to 20% for exactly 1.
More than one parameter is about 2.5x faster.
  - no longer revert to from-slurpy for cases != 1
   We've already done some of the work, why do it again?
  - no longer need to create a Perl 6 level capture
   Since we don't need to pass it on.
  - return bare List object for no parameters		 16:46
lizmat no idea how this is going to affect test-t, probably not 16:48
timotimo cool! 16:49
dalek kudo/nom: 054a54a | (Daniel Green)++ | src/Perl6/Grammar.nqp:
Fix for RT #128306
 16:54
kudo/nom: 8430f07 | lizmat++ | src/Perl6/Grammar.nqp:
Merge pull request #785 from MasterDuke17/RT128306

Fix for RT #128306
timotimo oh, synopsebot6 should probably hang out here, too
[Tux] This is Rakudo version 2016.05-115-g8430f07 built on MoarVM version 2016.05-18-g1339332 17:02
test 17.425
test-t 9.585
csv-parser 21.475
timotimo that's just 0.001 difference from the previous message
lizmat [Tux] : yeah, no (+list) sigs in Text::CSV 17:03
timotimo fair enough
lizmat should be noticeable in other places, though
timotimo yeah, many things in the setting have those 17:04
lizmat afk& 17:15
dalek ast: 716b94f | FROGGS++ | S10-packages/precompilation.t:
add another test for RT #128156
 17:20
CQ who runs dalek? would be helpful to have RT#s show up as URLs instead of IRC channels ... : ) 17:21
timotimo that's what synopsebot6 can do :) 17:22
also, "showing up as irc channels" is probably your irc clients' fault :) 17:23
CQ timotimo: sure, anything with a #something is a channel...
timotimo i'm not so sure about that :) 17:24
CQ timotimo: I mean on my irc client (chatzilla)
timotimo OK
jnthn finally got around to blogging: 6guts.wordpress.com/2016/06/12/gri...rovements/ 17:56
mst woo
let's see if I can understand one word in three
masak "Do 5 small improvements that win an average of 1% each, and it adds up to a more satisfying 5% improvement." -- only just 18:01
m: say 1 - .99 ** 5
camelia rakudo-moar 8430f0: OUTPUTĀ«0.0490099501ā¤Ā»
masak or "not quite", rather 18:02
jnthn Which rounds up to 5% :P
masak yeah, yeah :) 18:03
actually, it was more the "adds up" part that bothered me ;)
jnthn Maybe "combine" woulda been better :) 18:04
masak "multiply up" :P
jnthn But hey, I'm a compiler hacker, not a statistician :P
masak .oO( you've sped things up significantly -- how *dare* you be off by a factor of .02!? ) :P 18:05
hm, is it `package Main;` in Perl 5, or `package main;`? 18:07
geekosaur the latter 18:09
masak jnthn: though I'm not really sure why you're switching packages at all there -- maybe out of a sense of fair comparison, because the Perl 6 class is block-scoped? 18:11
jnthn masak: Clarity mostly 18:12
masak anyway, it should probably be `main` so as not to needlessly confuse those faithful p5 readers out there ;) 18:13
jnthn Fine, but I'm not going to take the time to re-measrue :) 18:14
mst for clarity 18:16
package A {
...
}
would correspond nicely and save you the second package line
masak .oO( turns out lower-case `m` is 10% faster than upper-case `M`... ) o.O
what mst++ said
but yeah, no need to re-measure
jnthn mst: Hm, is that a recent-ish addition? 18:17
mst jnthn: no
masak 5.18 or so?
mst 5.14 18:18
masak oh wow
jnthn Time flies :)
Anyways, it can stay as it is in the post. 18:19
Took me weeks to find the energy to blog at all :P 18:20
masak jnthn++ # I know how that feels
jnthn And, fwiw, I'm not doing Perl 5 comparisons to see "whose ahead" rather than to give a sense of "is Perl 6 even in the ballpark" 18:22
CQ jnthn: thanks for the blogposts, they're fun and interesting reading, even if sometimes my comprehension levels at 30% if you're off to the depths of an issue : ) 18:25
mst jnthn: that's what I took it as 18:27
masak .oO( "whose alot" ) 18:29
jnthn: thanks for the blog posts. I always understand everything perfectly :P 18:30
masak .oO( that's only 95.09900499% true ) 18:31
jnthn
.oO( I look forward to analizing your next blog post too :P )
 18:34
masak .oO( OH NOES WUT HAV I D... hey wait, that actually sounds rather nice ) 18:35
b2gills Can someone prune some of the branches on the rakudo repository? I mean some have parrot in the name. ( there are over 150 branches ) 18:38
timotimo tbh, i would have liked to see perl6 before, perl6 after and perl5 cycle counts for small, medium, big loops ... but that'd take ages :) 18:43
that should give slightly linear curves where you could easily-ish see startup cost and per-loop cost
masak timotimo: well volunteered! 18:44
timotimo hm. if jnthn gives me exact-ish commit ids for this work in question, that would be very doable 18:45
jnthn timotimo: I linked most of the commits from the post :) 18:47
FROGGS jnthn: a few hours ago CompUnit::PrecompilationRepository.load's return type has changed... (from CU to List) 18:52
jnthn: are we allowed to do that wrt policy?
timotimo oh 18:54
moritz FROGGS: is it tested in roast? used in the ecosystem? 19:21
if not, I think we can
FROGGS used in doc/htmlify.p6
but does not seem to be tested in roast 19:23
moritz I think the build process on hack still uses some older rakudo 19:27
2016.04
star-m: say 'version?' 19:28
camelia star-m 2016.01: OUTPUTĀ«version?ā¤Ā»
FROGGS [20:31] <dogbert17> interesting htmlify.p6 has suddenly stopped working 19:29
that's why I am asking
moritz right 19:30
dogbert17 it was this which made me suspicious: travis-ci.org/perl6/doc/builds/137088856 19:32
moritz if I add [0], it should work with both old and new code, right?
FROGGS most likely, yes 19:33
moritz push'd 19:34
travis will tell me :-)
FROGGS moritz++
dogbert17 moritz++
lizmat hmmm.... looks like something broke Inline::Perl5 19:41
Too many positionals passed; expected 2 arguments but got 3 19:42
in method new at /Users/liz/Github/panda/.panda-work/1465760385_4/lib/Inline/Perl5.pm6 (Inline::Perl5) line 949
ah, looks like *I* broke it 19:43
jnthn FROGGS: If it's not tested in roast, then technically yes it's allowed... Also, the compunit repo stuff is all still a tad up in the air, afaik 19:49
lizmat fixed in Inline::Perl5 19:56
FROGGS nine: this is probably not news to you, but t/spec/S10-packages/precompilation.t fails atm
FROGGS lizmat: this is news to me 20:21
lizmat: head passes here
ohh wait... 20:22
dalek ast: 8f34231 | FROGGS++ | packages/RT128156/ (4 files):
add missing test files
FROGGS facepalms
lizmat aha! :-) 20:23
FROGGS lizmat: now it should pass /o\
lizmat checks
FROGGS: clean now, indeed FROGGS++ 20:28
FROGGS \o/ 20:29
gnight #perl6-* 20:33
lizmat RT #128306 21:02
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128306
jnthn lizmat: There was a proposed MoarVM patch to fix that; I rejected it because it took the wrong approach, but suggested what might be a better way. 21:04
lizmat yeah, and I merged it :-) 21:05
054a54aa22d05554bbc1be to be precise
I started working on the P6W already
jnthn lizmat: ah, I missed that :) 21:08
jnthn blames the football :)
nine lizmat: your Inline::Perl5 fix looks fine :) Tests well and all the examples from my talks seem to continue to work 21:10
lizmat I was wondering if you could take it further, to remove posiitionals from .new as well 21:11
I think it will give a significant performance boost 21:12
if you're creating a lot of objects, that is
nine lizmat: you mean from Mu's .new? 21:13
lizmat no, from Perl5Package.new (line 726)
and Perl5Parent.new, (line 949)
nine No, I need to be able to pass those on to the Perl 5 class' constructor. And those take positionals very often. 21:14
lizmat ok, I figured something like that, that's why I didn't do it right away :-) 21:15
nine If anyone has a better idea for how to structure the code in PrecompilationRepository so .load doesn't have to return ($handle, $checksum), I'm all ears.
lizmat can't $checksum be a method on $handle ? 21:16
nine It could, but it just doesn't feel right. It's not a property of a CompUnit::Handle but of a PrecompilationUnit 21:17
lizmat so perhaps $handle is an attribute of PrecompilationUnit ?
nine which is a precomp file (consisting of bytecode and serialized objects) + its dependency information.
Hmm...having PrecompilationStore.load return a PrecompilationUnit. That suddenly doesn't sound as bad as the first two time I've thought about it. 21:19
jnthn Well, there's always returning some object with handle and checksum properties... :)
But yeah, the thing you load from a PrecompilationStore being a PrecompilationUnit sounds fairly right :) 21:20
nine Thanks :) 21:26
jnthn Sleep time...'night 21:39
lizmat gnight jnthn 21:40
timotimo gnite 21:43
dalek kudo/nom: 5d49498 | lizmat++ | src/core/List.pm:
Fixup List.sum

  - make sure we get a nice fail if it is a lazy list
  - don't allocate if it is and will be an empty list
  - streamline the addition loop		 21:59
timotimo lizmat: do you think a small check of the first value in a list and skipping first-concrete for min and max can enhance performance? 22:10
lizmat no firm idea 22:11
timotimo i have a piece of code where min takes a big chunk of total run time. it spends 63% of time inside cmp, but 10.8% in first-concrete
all in all, min is in second place by exclusive time, with only 9.17%, but its inclusive time is a whopping 49.8%
hm, it could also be min is responsible for find-best-dispatchee calls ... which the profiler sadly can't appropriately place in the call graph :( 22:13
lizmat timotimo: now I'm not sure which min / max you're talking about 22:14
timotimo the method in any-iterable-methods
lizmat would have to benchmark and profile 22:16
which made me just realize I have been hacking way too long today already :-) 22:17
good night, #perl6-dev! 22:18
timotimo gnite!
thanks for your outstanding work today and always :)
hmm. how to output a stacktrace from nqp ... 22:24

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!