github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
MasterDuke github.com/rakudo/rakudo/issues/1955 00:00
timotimo so we can pull the gcd up front (if we need it any more at all) and immediately check to see if the result would fit or not
woww
there has already been exactly all the discussion here
niner already came to the conclusion i was asking about 00:01
japhb is trying to think if there's any way that x ** n == y ** m for x and y relatively prime, just in case his brain has leaked
Heh, there we go, I'm not the only one then 00:02
:-)
timotimo fortunately m and n would have to be the same in this specific case
japhb timotimo: I was thinking of partial cancellation.
And ignoring the trivial m == n == 0 case.
But yeah, I think my original statement is true. 00:03
timotimo right, negative numbers are also a concern, right?
00:05 Voldenet joined, Voldenet left, Voldenet joined
japhb timotimo: yeah, then you'd care about the size of the exponentiated numerator, I suppose. 00:06
timotimo i can't just immediately implement this because currently rats can have non-reduced nudes 00:08
so the code would have to become slightly nontrivially bigger
MasterDuke i thought zoffix fixed that? 00:15
timotimo was that merged? in that ticket it says "unmerged" 00:16
MasterDuke that was a month ago, i thought that did actually happen 00:17
zoffix: ^^^ ?
01:17 Kaiepi left 01:18 Kaiepi joined 01:20 Kaiepi left, Kaiepi joined 03:08 Kaiepi left 03:09 Kaiepi joined 06:15 diakopter left 06:38 robertle joined 06:43 lizmat left 07:20 domidumont joined 07:27 domidumont left 07:28 domidumont joined 08:06 lizmat joined 09:28 brrt joined
brrt \o 09:28
09:36 zakharyas joined 09:45 domidumont left 10:24 robertle left 10:26 brrt left 10:53 brrt joined 11:07 Zoffix joined
Zoffix Patience! Use the force! 11:08
Why is everyone obsessed with my Rat example now? I regret making that talk.
Weren't you guys working on something, like the tooling grant and graal stuff or something?
the unreduce branch has other crap in it like reducing zero-denominator rationals and that needs more thought. 11:10
lizmat Zoffix: don't worry about it... there's medium.com/@jcoterhals/perl-6-smal...6d0addb46f
that shows it's better to be correct than fast
Zoffix And like the grant cancelation blog said, there are more important things to do right now and the rat stuff will be done eventually.
lizmat indeed 11:11
some people will just continue making their point, however repetitive it is 11:12
and we'll just do the same :-)
11:13 domidumont joined 11:15 brrt left, brrt joined
brrt Zoffix: regardless of the Rat example, what struck me was that your code was nearly entirely container-free 11:23
Zoffix brrt: why is that striking?
brrt because.... 11:24
because containers are Terrible For Performance, and I think that rakudo core developers know this very well 11:25
Zoffix And doesn't look like ** can be optimized much anyway. The slowness comes from raising numerator/denominator to huge power, not due to reduction, and you still have to do the raising even when producing a Num result 'cause otherwise you don't get the correct Num (e.g. in the talk's example, $numerator.Num gives Inf)
brrt: ah :)
brrt So from my perspective, I want to get rid of them 11:26
Zoffix brrt: yeah, when I started with Perl 6, I couldn't understand why some people used binding all over the place. Now, I bind or use raw params any time I can 11:27
brrt Zoffix: so, from my PoV, that is a Problem, and a rather large one
especially as mixing binding and assignment creates maddeningly confusing behaviour
Zoffix brrt: I don't think containers are *that* Terrible For Performance
brrt they kind of are 11:28
Zoffix And isn't that what rescallar branch that landed was about? To not create a Scalar when can get away with it?
brrt it's an improvement, but nowhere near where we could go if we got rid of them altogether
Zoffix heh 11:29
brrt Let me try and make this point, as best as I can on IRC, anyway 11:30
In many respects, perl6 is a vast improvement on the state-of-the-art in dynamic languages 11:31
Zoffix Let me make mine first: tiny examples from a talk written by someone who avoids containers on purpose aren't a good argument for claiming a feature to be useless enough to get rid of it altogether
brrt Agreed, but don't worry about that; It's a straw-breaking-camels-back 11:32
This has been a long time coming
Zoffix Sure, let's redesign the language from the ground up, two and a half years after it stabilized after a decade and a half of design, on an off chance we make a 5% improvement to performance. 11:33
11:33 Zoffix left
brrt Perl6 has: - native multiple threads - builtin async io *and* synchronous IO - a usable type system - native numeric types - a powerful object system - dynamic specialization and JIT compilation 11:34
Perl6 is an awesome language, it is just Too Damn Slow
lizmat brrt: fwiw, I think getting rid of scalars in Perl 6 feels, eh, something that should have been designed earlier ? 11:35
brrt oh, absolutely
lizmat so I'm not sure what you're getting at ?
brrt I'm getting at - we're paying a fantastic performance penalty in making assingments into method calls *by default*, and there is a component to that that we *cannot*, by the best known means, reliably eliminate 11:37
and even if we can eliminate in some cases - and I'm sure jnthn++ has a few tricks up his sleeve yet - what we get is deeply unintuitive performance behaviour 11:38
lizmat "making assingments into method calls *by default*" what level of the stack are you getting at here ? 11:39
nqp::assign? or .STORE ?
brrt .STORE
lizmat yeah, but that doesn't happen by default, only for Array / Hash and Proxy
you can't Scalar.STORE 11:40
afaik
brrt true; the REPR op does a STORE still, though, so the point still kinda stands
and it's not just the fact that it is a (potentially multi) method call, but also that there's a box arround it, and that box needs setup and gc and dereference etc 11:41
(this reminds me of when I was in university and we found out that the packaging of e.g. a refrigerator was responsible for a significant part of the total environmental impact) 11:42
lizmat so what are you suggesting? Banning "=" from the language ? 11:43
brrt I'm not even starting about the totally confusing behaviour you can get from mixing them. Although that's an interesting discussion in it's own right 11:44
Making '=' and ':=' the same thing. Introducing explicit Refrences, with syntax, for the rare case that this behaviour is needed 11:45
lizmat feels to me you don't like to be tortured on behalf of the users :)
brrt :-) 11:46
If this was something that I could actually see benefitting users, then I'd be happy to; but I don't
ok, consider this: 11:48
m: my $l = (1,2,3); $l[1] = 3; 11:49
camelia Cannot modify an immutable List ((1 2 3))
in block <unit> at <tmp> line 1
brrt m: my $x = 2; my $l = (1,$x,3); $l[1]=4; say $l
camelia (1 4 3)
brrt > m: my $x = 2; my $l = (1,$x,3); $l[1]=4; say $l, $x
m: my $x = 2; my $l = (1,$x,3); $l[1]=4; say $l, $x 11:50
camelia (1 4 3)4
lizmat so, yeah, that's a peculiarity of List that I don't particularly like either, that's why I made modules.perl6.org/dist/Tuple:cpan:ELIZABETH
brrt :-) 11:53
anyway, this would never happen if the reference semantics of list where explicit and part of the syntax 11:54
because I'd never be confused that way
anyway, this is obviously not just up to me 11:55
masak is not a fan of mutability in general :)
but I also recognize that we live in a world of compromises, and Perl 6 is already a compromised language in that sense ;) 11:56
brrt is a fan of explicit syntax, obvious semantics, and a consistent mental model of the runtime 11:57
masak by the way, it's interesting the success something like Redux has had in the JS world. it's essentially a way to close your eyes to reality and pretend that JavaScript is a laregly side-effect-free language, like Haskell.
brrt: amen to that.
brrt I haven't used anything related to javascript in a long time
masak heh. the above is not meant to disparage Redux in any way; it's a fine library. 11:58
I just mean with enough effort you can forget that mutations are there.
brrt :-) 11:59
speaking of which, have you read 'Designing data-intensive applications' by... whatshisname
I liked that a lot.
masak this one? www.amazon.com/Designing-Data-Inte...1449373321 12:07
I had not. now added to my never-shrinking wishlist
12:09 domidumont left
brrt I would recommend it 12:11
12:17 robertle joined 12:21 domidumont joined
brrt also, in general; I hope it is never too late to reconsider design decisions 12:22
12:31 domidumont left 12:32 Zoffix joined
Zoffix brrt: yeah, if you want Perl 6 to be forever called an experimental toy language. If we want to get more than 200 users, we' 12:32
d have to stop making them change their code all the time.
And your examples with lists breaks `my ($x, $y, $z) = ...` 12:33
brrt: and not only code, but educational materials as well. For example the containers article I wrote last year now requires a change about Proxy. 12:34
With your proposal, it'd need an entire rewrite.
And we have half a dozen books out already. 12:35
lizmat Zoffix++
12:35 brrt left, domidumont joined 12:36 diakopter joined
timotimo once our escape analysis is a bit better, we'll be making a whole lot fewer scalars, though of course scalars inside of datastructures such as arrays will remain 12:38
rescalar will cheapen scalars even more once we get better at removing redundant guards, too
lizmat timotimo++ 12:39
timotimo and moving deopt targets earlier, i.e. daring to re-execute a few instructions after deopt, ought to let us eliminate a couple more instructions in typical bytecode segments
i've got a positive outlook on this 12:40
Zoffix timotimo++
lizmat timotimo: in the for ^100 loop optimization 12:41
it looks like it is generating an nqp::while with 3 statements
isn't a nqp::stmts needed there ? 12:42
nqp::while( nqp::isle_i($i,$max), nqp::call(), nqp::bind($i,nqp::add_i($i,1)) ) 12:43
timotimo: shouldn't the call / bind be inside an nqp::stmts ?
timotimo could be
lizmat or am I misunderstanding something ?
12:43 domidumont left, Zoffix left
lizmat hmmm.. guess not 12:45
so nqp::while is variadic in its parameters ? 12:46
timotimo perhaps it is
lizmat m: use nqp; my int $i; nqp::while( nqp::isle_i(($i = nqp::add_i($i,1)),10), nqp::say("foo"), nqp::say("bar") )
camelia foo
bar
foo
bar
foo
bar
foo
bar
foo
bar
foo
bar
foo
bar
foo
bar
foo
bar
foo
bar
lizmat ah no, that's the pst block
use nqp; my int $i; nqp::while( nqp::isle_i(($i = nqp::add_i($i,1)),10), nqp::say("foo"), nqp::say("bar") )
evalable6 foo
bar
foo
bar
foo
bar
foo
bar
foo
bar
foo
bar
foo
bar
foo
bar
foo
bar
foo
bar
lizmat github.com/perl6/nqp/blob/master/d...down#while 12:47
TIL nqp::while has a post block :-)
looks like the nqp::while without the post block is about 9% faster 12:59
timotimo that sounds good 13:00
zoffix, but 90% of the time from that rat example is spent in gcd, but we know that we don't have to reduce the rat after raising it to the power, so it should become at least 10x faster from that change alone. possibly also wins to be had inside DIVIDE_NUMBERS, which is at 9.88% 13:07
13:09 domidumont joined 13:12 Zoffix joined
Zoffix timotimo: ah, I measured wrong. In the code I used for measurement I had `say $denominator` so it was trying to stringify a huge integer which made me think the power operation on Ints themselves was super slow 13:13
I'll look into cherry-picking stuff from unreduce branch
timotimo ah!
13:14 domidumont left 13:15 domidumont joined
Zoffix m: say 26.2/4.4 13:16
camelia 5.954545
Zoffix So it can be at least ^ that much faster.
timotimo huh, only that much, eh? 13:17
that doesn't seem right
Zoffix m: sub calc (\n) { my $r := (1 + .123/n); $r.nude; my $nu := $r.numerator ** n; my $de := $r.denominator ** n; use nqp; nqp::div_In($nu, $de) }; calc 50_000; say now - ENTER now 13:18
camelia 1.9609962
Zoffix m: sub calc (\n) { my $r := (1 + .123/n)**n }; calc 50_000; say now - ENTER now
timotimo OK, dividing the one huge number by the other huge number still takes a bunch of time, then?
camelia 21.38466
Zoffix m: say 21.38/1.96
camelia 10.908163
Zoffix I guess it depends on what sort of box you use too
timotimo ok, how about this 13:19
we figure out the point where we'd reach the overflow point
at that point we turn into num
and then do the rest of the exponentiation
Zoffix Then you end up with Inf in the denominator, and you get wrong answer
(with the example above)
timotimo not if we switch over early enough perhaps? 13:20
this reminds me of the thing where re-ordering the entries in a list you want to sum can give drastically different results because of floats
Zoffix Num can only go up to ~1.78e308... 50000000**50_000 is ~3.16e384948 13:23
timotimo but the nominator grows along with it, right? 13:24
Zoffix numerator. Yeah 13:25
timotimo so i was thinking we keep it Int, but reduce the power before we divide both numbers to a num
and then continue the exponentiation with the single num
so i'd expect we end up at the right result after all 13:26
Zoffix Would it still equal to those two integers being just divided? Like, would it give a correct Num? (hard to measure now, since nqp::div_In doesn't give a closest Num ATM) 13:27
timotimo m: sub calc (\n) { my $r := (1 + .123/n)**n }; say calc 50_000 13:28
Zoffix m: sub calc (\n) { my $r := (1 + .123/n); $r.nude; my $nu := $r.numerator ** 50; my $de := $r.denominator ** 50; use nqp; dd nqp::div_In($nu, $de)**(n-50) }; calc 50_000; say now - ENTER now
camelia 1.1308842498562788
465.84010040842134e0
0.00243249
timotimo m: sub calc (\n) { my $r := (1 + .123/n)**n }; say calc(10_000) * calc(10_000) * calc(10_000) * calc(10_000) * calc(10_000)
camelia 1.8496496037652481
timotimo damn.
that's not right 13:29
Zoffix m: sub calc (\n) { my $r := (1 + .123/n); $r.nude; my $nu := $r.numerator ** 50; my $de := $r.denominator ** 50; use nqp; dd nqp::div_In($nu, $de)**(n/50) }; calc 50_000; say now - ENTER now
camelia 1.1308842498561582e0
0.00244834
Zoffix j: sub calc (\n) { my $r := (1 + .123/n); $r.nude; my $nu := $r.numerator ** 50; my $de := $r.denominator ** 50; use nqp; dd nqp::div_In($nu, $de)**(n/50) }; calc 50_000; say now - ENTER now 13:30
camelia 1.1308842498561582e0
0.045
Zoffix j: sub calc (\n) { my $r := (1 + .123/n)**n }; say calc 50_000
camelia ( no output )
Zoffix j: sub calc (\n) { my $r := (1 + .123/n)**n }; say calc 50_000
camelia
(timeout)
Zoffix grr
j: sub calc (\n) { my $r := (1 + .123/n); $r.nude; my $nu := $r.numerator ** 10; my $de := $r.denominator ** 10; use nqp; dd nqp::div_In($nu, $de)**(n/10) }; calc 50_000; say now - ENTER now 13:31
camelia 1.1308842498567593e0
0.078
Zoffix not the same result
.oO( powers of 2? )
 13:32
no, still differs 13:33
vOv
"since nqp::div_In doesn't give a closest Num ATM" <-- that's only in MoarVM AFAIK R#1782 13:36
synopsebot R#1782 [open]: github.com/rakudo/rakudo/issues/1782 Rat.Num does not choose the closest representable Num
13:36 Zoffix left 13:37 brrt joined
lizmat on that matter: www.reddit.com/r/perl/comments/93d...cobol_nor/ 13:41
I guess that's because it switches to float there as well
timotimo yeah, you need FatRat for that 13:42
i can write that there
lizmat timotimo: What kind of QAST::Var do I need to make to be able to do a nqp::assign_i on it ? 13:44
timotimo needs to be :scope<lexicalref> or :scope<localref> if that exists 13:45
lizmat would that make sense to use instead of nqp::bind in the for ^100 loop optimization ?
timotimo you'd have to be careful that it only allocates the lexicalref once and assigns into it over and over 13:46
rather than building a new one every time
lizmat so not specify scope<localref> all the time ?
timotimo i don't remember if localref actually exists %) 13:47
lizmat will find out soon enough :-) 13:48
timotimo there's tests for this stuff in the nqp repository, they are based on QAST trees directly, so you can perhaps steal a bit from there
lizmat there is no localref
timotimo OK! 13:49
brrt Zoffix: I know that all to be true. I would not be saying this lightly 13:59
timotimo we're screwed for sure?
brrt and fwiw; I was very much thinking of things like a container in every data structure, moreso than containers for every scalars
those are impossible to eliminate 14:00
timotimo ah
brrt Frankly, I understand Zoffix's point fully
timotimo i'd say, if you want more performance, you can replace hashes with objects, and then you don't have scalars there any more
brrt I don't *have* to have scalars anymore, no
but i'd better be very vigilant lest they are introduced by accident 14:02
14:11 zakharyas left, zakharyas joined 14:16 zakharyas left
brrt fwiw, I'm not trying to be negative here 14:17
lizmat brrt: it does come across that way :-( 14:24
brrt Hmm 14:37
I want to apologize for that. It was my aim to be productive 14:38
timotimo always possible to write a slang that automatically makes every code written in it use binding and not produce scalars
at least i think that could be possible?
brrt what happens when that slang encounters code written that does not use this?
lizmat or something that would export a macro that would do that ?
brrt There is a bit much in the way of semantic differences to safely do that 14:39
Anyway, I'm fully aware that what I'd propose would be a Breaking Change. So the benefit would have to be great enough to overcome that objection 14:41
And obviously I can't prove that the benefit would be that great
Not without first implementing it
On the other hand, we do have NQP, and we know that NQP programs are considerably faster than perl6 programs 14:42
NQP can go head-to-head with virtually all dynamic programming languages and come out well, performance wise 14:44
well, maybe not against luajit or v8, but you get what I mean
*especially* when we do get to use native types, which *just work* in nqp 14:52
lizmat fwiw, if we could get the startup time of Rakudo down to ~ 20 msecs, that would also be of great help 14:58
it's now 130+ msecs on my machine
14:59 brrt left
diakopter I didn't follow what brrt's Breaking Change proposal was 15:29
lizmat getting rid of = in favour of := 15:31
or: get rid of containers
15:33 Kaiepi left, Kaiepi joined
diakopter I'd be curious if anyone could actually notice any meaningful difference in the semantics of the language's major features if that was enacted... or, more practically, what kinds of typical programming idioms would look different or would be thereafter impossible 15:36
mst I experimented with using := for everything but that made many things read-only 15:37
15:37 mst sets mode: -o mst
mst since I was explicitly trying to get single-assignment, that was fine for me 15:37
diakopter ah yes, the readonly-ness sometimes uses non-containerness 15:40
15:42 ChanServ sets mode: +o diakopter, diakopter sets mode: -o diakopter 15:50 domidumont left 15:59 brrt joined
brrt .tell mst you can always still rebind 16:04
yoleaux brrt: I'll pass your message to mst.
brrt m: my $x := 42; $x := "Foo"; say $x;
camelia Foo
16:05 Ven`` joined
brrt so not so much readonly, but non-containerised 16:05
16:06 zakharyas joined
lizmat brrt: how would you handle auto-vivification ? 16:07
m: my $a; dd $a; $a<foo> = 1; dd $a
camelia Any $a = Any
Hash $a = ${:foo(1)}
brrt not entirely sure yet 16:08
maybe by compiler help
lizmat m: my %h; %h<foo><bar><baz> = 42; dd %h
camelia Hash %h = {:foo(${:bar(${:baz(42)})})}
brrt that is actually the easy one, the other one is harder :-) 16:09
lizmat m: my %h; my $a := %h<foo><bar><baz>; dd %h; $a = 42; dd %h 16:10
camelia Hash %h = {}
Hash %h = {:foo(${:bar(${:baz(42)})})}
16:13 Zoffix joined
Zoffix m: my @a = <a b c>, <y z y>; for @a { say .[1] ~ .[2] ~ .[0] } 16:13
camelia bca
zyy
Zoffix How would you handle this?
lizmat m: my $a = 42; my $b = 666; ($b,$a) = ($a,$b); dd $a, $b 16:14
camelia Int $a = 666
Int $b = 42
Zoffix m: my @a = <a b c>, <y z y>; for @a[0] { say .[1] ~ .[2] ~ .[0] } # this rather
camelia bca
Zoffix m: my @a = <a b c>, <y z y>; for flat @a { say .[1] ~ .[2] ~ .[0] } # or this
camelia bca
zyy
Zoffix Or this: 16:16
m: sub foo (\z) { z = 42 }; foo my $x = 100; say $x
camelia 42
Zoffix vs.
m: sub foo (\z) { z = 42 }; foo my $x := 100; say $x
camelia Cannot modify an immutable Int (100)
in sub foo at <tmp> line 1
in block <unit> at <tmp> line 1
brrt that would get new syntax, and we wouldn't be passing bound containers, because by default you'd pass-by-value
and so that would look like: 16:17
sub foo (\$z) { \$z = 42; }
or maybe with a star:
Zoffix ?
brrt sub foo($fz) { *$z = 42; }
Zoffix The control of whether write happens is at the callsite
I don't get what the new syntax inside the sub solve with respect to that 16:18
brrt sub foo(\$z) { \$z = 42; } ; foo my \$x = 100; say $x;
the point is; you'd get a new syntax for explicit references; you'd use that syntax wherever you'd otherwise use the implicit container-ness to write-by-reference 16:19
Zoffix So basically invent a new language? 16:20
brrt I'm suggesting a hard fork, yes
Zoffix The `my $x =` was just a short example, it can easily be just a variable coming from elsewhere
brrt yes, and that's fine
well, imho, having reference-assignment explicit and nondefault is a language win compared to the current situation 16:21
Zoffix And your hard fork will be what? Beta for the next 3 years until all the semantics are ironed out?
I'm really shocked people are still proposing these pivotal changes.
Changes to the very core of the language.
lizmat brrt: "I'm suggesting a hard fork, yes" seriously ??? 16:22
brrt I am. So sue me
I'm not shocked, I'm too old and jaded for that., but I am disappointed at the intensity of the reaction here
Zoffix Well, I'm not here to endlessly fuck around with the language just for the fun of it. I want people to use it.
brrt I want to use it as well. But I can't. Because it is too slow 16:23
lizmat and that goes for me as well
(and that was to Zoffix's answer)
brrt: then maybe you should use another language that isn't too slow ? 16:24
brrt My experience is that whatever clever optimization that we do, we can improve performance by Nx (where N sits usually between 1 and 2, and sometimes between 1 and 10) for some common idiom
16:24 robertle left
brrt I can and will have to, won't I? 16:24
lizmat brrt: well, I'm not sure...
timotimo i think maybe we're working with different definitions of "hard fork" here? 16:25
lizmat are you saying that the basic premise of being able to spesh / JIT / OSR the hell out of Perl 6 code, is flawed ?
brrt I do mean a change to the core language that would break existing programming languages, yes
No, but I am saying that I believe - and would be happy to be proven wrong, don't get me wrong here, please - there are issues in the core language design, containers being the prime example I know of, that are nigh impossible to eliminate by downstream cleverness 16:26
timotimo it could be interesting to have some experimentation on the side 16:27
kind of like 007
how do you deal with reference-taking functions/methods and multi-ness?
brrt timotimo: example?
timotimo for multi subs you'll have everything available at the call site, usually, but not with methods
well, you won't know whether a parameter will be taken as a reference by the callee or not
will the caller mark that? 16:28
brrt there would be explicit syntax and a class
e.g. there could be a multi sub foo(Reference $x) { ... }
or 'Ref $x'
timotimo mhm
Zoffix brrt: as for intensity of the reaction: so far, I've seen jnthn, TimToady, and timotimo (above) being optimistic we can get decent performance. Now, the chief JIT architect is saying we have to renege on our promise of a "stable language" and essentially redesign the entire language, because it's impossible for us to get decent performance otherwise. 16:29
brrt Hmmm
So there's at least one point of difference between your perception and mine 16:30
timotimo how about we first build a suite of datastructures that do without containers at the cost of slightly different API
brrt I see myself as holding no authority whatever :-)
timotimo: that's actually a nice idea
timotimo i.e. we won't be doing @foo[1] = 10, for example?
lizmat brrt: and they're, I think, you're giving yourself too little credit
timotimo instead, ask the user to do something akin to .ASSIGN-POS
except prettier
lizmat *there
brrt hmm. I see. Then I want to stress that my pproposal was meant experimentally :-) 16:31
I like the idea of having a 'containerless' data structure API as a testing ground 16:32
timotimo you know, we're not terribly far from being able to inline the fetch and store methods of proxy objects into code that uses them
i assume spesh plugins can do that
brrt Which will help; but there will still be the boxing, gc, dereference, etc. And those are still costly 16:33
timotimo right, spesh will have to learn to eliminate these things
i.e. we'll know that the proxy is being created and doesn't escape, so we'll only be calling the method, no more proxy allocation needed 16:34
not sure what boxing and dereference you're refering to, i'd have to see code for that
brrt for a completely eliminated proxy, then yes, that will work 16:35
timotimo oh, there'll have to be some cleverness around closures, though 16:36
we have some smarts for when the inlined code had a closure of the containing code; perhaps that can be generalized far enough here
brrt so, part of the reason i'm relatively pessimistic about that is, such optimization tend to work for 90% of the cases
if we have a second optimizatoin that will only work if the first one works, it'll work on 81% of cases 16:37
annd that multiplication is not in our favour
timotimo i've seen follow-up optimizations that tend to work in more than 90% of cases :P
Zoffix "brrt │ I want to use it as well. But I can't. Because it is too slow" 16:38
brrt: what would be considered not too slow?
brrt true enough
perl5 would be acceptable.
timotimo to be fair, our regexps are really, really slow :) 16:39
i've been meaning to give JSON::Fast another performance pass 16:42
brrt my main worry is that the perl6 core devs are essentially writing another language than the users are supposed to use 16:43
timotimo ah, you mean core devs are okay with knowing all the nooks and crannies that give better performance? 16:45
brrt not only that; we rely on them 16:46
16:48 bisectable6 left 16:49 bisectable6 joined 16:51 zakharyas left 17:15 robertle joined 17:38 Ven`` left 17:47 brrt left 17:49 domidumont joined 17:54 domidumont left 18:18 Zoffix left 19:17 dogbert17 joined 19:19 zakharyas joined 20:29 Ven`` joined 20:33 zakharyas left 20:52 Ven`` left 20:58 Ven`` joined 21:16 robertle left
timotimo oh, interesting 21:20
so i was wondering why my simple Proxy example didn't trigger the assign spesh plugin
since there wasn't a $ sigil to be found (i had code like makesproxy() = 5) it used p6store, which is more complex than p6assign, as it handles more different cases
wouldn't terribly surprise me if we could win something by giving p6store a spesh plugin as well that sometimes just resolves to using the p6assign spesh plugin, too 21:21
until then, i at least know how to trigger the spesh plugin for the proxy case, and maybe find out how to optimize that
21:32 Ven` joined 21:35 Ven`` left 23:02 Ven` left

Powered by Cro and the Raku® Programming Language.

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

Thank you!