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.
Geth roast: 8fdad7f0dc | (Zoffix Znet)++ | S17-procasync/bind-handles.t
[v6.d REVIEW] Use standard temp file routines in Proc::Async

Orig: github.com/perl6/roast/commit/ebac29a7e		 00:41
[Coke] tony-o: but why? if it has to be doing something exactly like core, shouldn't there be a core way to do it so it's not got to be duplicative? 01:25
timotimo we don't really want to specify a json parser and serializer to be in the perl6 language, though? 01:26
[Coke] I would prefer we didn't do that, yes. 01:27
timotimo though we could also just not specify the whole compunit repo format either 01:31
on the other hand, the meta6.json format is also already json
timotimo on the third hand, we could perhaps say "there must be some serialization format" and the ecosystem api would offer whatever the implementation likes … 01:34
...
this is dumb :) :) :) 01:37
we should invent our own format, designed explicitly for being as dumb as possible, and only to support what we actually need
let's take a page out of klingon's design and mix together properties that are as foreign to each other as we possibly can 01:39
every string begins with a BOM and ends in a particular emoji
every new element must be on a new line starting with as many spaces as the file had characters up to that point, as determined by twitter's character counting algorithm 01:40
the beginning five bytes of the file must be the first five bytes of the sha256 of the entire file
array entries are actually written top-to-bottom in the file 01:42
geekosaur ...first system is intercal, second system syndrome still gives you xml >.> 01:52
timotimo since array elements have to go vertically, files with insufficiently many lines must be padded with at least the first 50 words of "lorem ipsum". typos or wrong words must result in a memory access violation via accessing the address 0x00 + position of first wrong character 02:05
nine Ok, on the JSON discussion: what is keeping us from just swapping out our code with that from JSON::Fast? Looks like the easiest win to me. 07:45
lizmat FWIW, I have no special love for the quick parser that I wrote... so it can be removed at any time afaic 07:52
yoleaux 19 Sep 2018 22:47Z <AlexDaniel> lizmat: I think you should try that parser on these files: raw.githubusercontent.com/ugexe/Pe.../cpan.json ecosystem-api.p6c.org/projects.json
06:18Z <El_Che> lizmat: You have a comment on your second p5-6 article opensource.com/article/18/8/garbag...ion-perl-6
06:19Z <El_Che> lizmat: And an error in the 3rd (p5: say @bar[1]) opensource.com/article/18/8/containers-perl-6
lizmat .tell El_Che those pseky P6isms keep creeping in :-( alas, I cannot correct the artical afaik 07:54
yoleaux lizmat: I'll pass your message to El_Che.
patrickb What files is the rakudo internal json parser parsing? Exclusively the META6.json files? I bet one could tune JSON::Fast a lot to only serve this file... 08:02
nine patrickb: yes, it's about META6.json files - which can become a lot more complex than most of them are now. Take e.g. github.com/niner/Inline-Python/blo...META6.json 08:05
But anyway, even an "untuned" JSON::Fast is a hell of a lot faster than our current parser.
lizmat ok, so I got parsing of projects.json down from 2.2 seconds on my machine down to 0.3 08:47
that's with the new quick-parser installed
without it, it goes down to only 1 second or so 08:48
nine cool :)
lizmat the change would be in zef, specific to parsing the projects.json file
so you would benefit from it both on older and newer rakudos 08:49
lizmat github.com/ugexe/zef/issues/273 09:12
|Tux| timotimo, look 09:16
Rakudo version 2018.08-119-g16ce9c89a - MoarVM version 2018.08-92-g3e94a68f6
csv-ip5xs0.933 - 0.963
csv-ip5xs-207.107 - 7.376
csv-parser21.499 - 22.109
csv-test-xs-200.425 - 0.426
test8.539 - 8.855
test-t1.972 - 2.071
test-t --race0.890 - 0.891
test-t-2035.993 - 36.834
test-t-20 --race11.607 - 11.820
2018-09-14 17:13:45 test-t 2.025
2018-08-30 17:35:38 test-t 2.015
2018-09-18 11:13:20 test-t 2.006
2018-09-20 11:10:24 test-t 1.972
2018-09-18 11:16:48 test-t 1.971
AlexDaniel nine: re “what is keeping us from just swapping out our code” that's exactly my point and I hope that is the plan 10:43
and it doesn't matter if we then end up hiding to-json/from-json behind serialize/deserialize, or if we end up implementing a quick-from-json or whatever 10:45
lizmat twitter.com/alteholzDD/status/1042...4718555136 11:49
AlexDaniel: the main (and also scalability) issue, is that currently there's a giant JSON file that is growing 11:50
github.com/ugexe/zef/issues/273 # should at least parallelize the parsing of that file
AlexDaniel lizmat: I disagree with the solution though 11:53
AlexDaniel lizmat: so, basically there are already two files, not one 11:53
and zef already parallelizes that
so maybe these json files should be split into chunks
but not when the file is already there 11:54
lizmat ah? But how come my solution brings down the parsing of projects.json from 2.3 to .3 ?
AlexDaniel I mean, we should change the generation of the file, not how it's parsed
lizmat perhaps
AlexDaniel lizmat: from 2.2 seconds to 1 second, you're just utilizing more cores
and zef will already use at least 2 11:55
because there are two files
lizmat so? if you have more cores it will be faster
that's the future reality
anyways, people were asking for a quick win: I provided that 11:56
AlexDaniel lizmat: yes, so let's change this: github.com/ugexe/Perl6-App--ecogen
lizmat: so that it generates multiple proper json files
lizmat doesn't install for me :-( 11:57
looks like faulty hash-order dependent tests
lizmat ah, no, there really is a problem 11:59
AlexDaniel lizmat: fwiw we should keep back compat in mind when changing the generation (i.e. older zef installations should still be able to work) 12:00
so maybe that's a point against my solution :) 12:01
lizmat yeah, that's why I'm not so sure we should change it
AlexDaniel well, it just means that there should be one big file and also chunkified ones 12:03
looking at your ticket, what is “IO.lines”? 12:13
what does that do again
in terms of \r \r\n \n and unicode newlines
lizmat AlexDaniel: lines always auto-chomps unless told otherwise 12:16
AlexDaniel I guess it's fine, it just feels fragile and I'm scared :)
lizmat reading lines from a file feels fragile ?
AlexDaniel expecting the json to be in some particular format 12:16
lizmat ah, yes, well, if it's not, it should fall back to the grammar based one 12:17
AlexDaniel lizmat: I was just thinking what if a module has “\r” in one of the fields, or something like that, but I guess that will be escaped and there's no problem. Nevermind :) 12:18
Geth rakudo: abbbd2a5c0 | (Elizabeth Mattijsen)++ | src/core/Rakudo/Internals/JSON.pm6
Revert "Introducing the ultra-fast braindead JSON parser"

This reverts commit 16ce9c89ad0ca242906f026a72da5b369f928e55.
Prevent fragility		 12:19
roast: 44e89c1d4b | (Zoffix Znet)++ | MISC/misc-6.d.t
Swap to new group-of test helper
 12:20
lizmat in any case, I've reverted it, as it broke App::ecogen's tests 12:22
AlexDaniel lizmat: but I agree that splitting the json file is probably a great idea 12:23
lizmat fwiw, I don't think it needs to be split: feels file like it is
the only thing that might break it if an included JSON file would have a line consisting of ',' or ']' 12:24
but the generator can prevent that by generating with an extra space at the start of each included line
Zoffix AlexDaniel: are we still pushing to master or a post-release branch? 12:51
ZOFVM: Files=1309, Tests=153185, 156 wallclock secs (22.06 usr 3.31 sys + 3323.82 cusr 170.28 csys = 3519.47 CPU)
AlexDaniel Zoffix: master 12:52
Zoffix k
AlexDaniel but not “still”, I'll be cutting the release from a release branch instead 12:53
so changes pushed to master now won't go into the release
Geth rakudo: bb88a0324e | (Zoffix Znet)++ | src/Perl6/Actions.nqp
[6.d] 🧙‍♂️ Cast a spell of silence on $()/@()/%()

Per 6.d-prep[^1], remove all magick from $()/@()/%() and make them mean the same thing as $( )/@( )/%( ) (that is, contextualizers that call .item/.list/.hash respectively on an empty list).
Closes RT#131392 and R#1946
  [1] github.com/perl6/6.d-prep/blob/dff...from--and-
  [2] rt.perl.org/Public/Bug/Display.html?id=131392
  [3] github.com/rakudo/rakudo/issues/1946		 13:00
synopsebot RT#131392 [resolved]: rt.perl.org/Ticket/Display.html?id=131392 [@LARRY] Remove magic $/ shortcuts %() and @()
R#1946 [open]: github.com/rakudo/rakudo/issues/1946 %(), @(), $() are evil/weird
Geth roast: 79e86e5f14 | (Zoffix Znet)++ | MISC/misc-6.d.t
Spec $()/@()/%() are not magical in 6.d

Per 6.d-prep: github.com/perl6/6.d-prep/blob/dff...from--and- POV: github.com/rakudo/rakudo/commit/bb88a0324e		 13:01
roast: dbb3a98661 | (Zoffix Znet)++ | S03-operators/context.t
Remove trailing whitespace
roast: e37341a973 | (Zoffix Znet)++ | 2 files
Remove spec of magick in $()/@() from 6.d spec

Do NOT backport this commit to 6.c spec. These features still exist in 6.c language.		 13:02
AlexDaniel nice 13:03
Zoffix++
Geth 6.d-prep: 435d2203aa | (Zoffix Znet)++ | 2 files
Mark $()/@()/%() demagicalization as complete

Propspec: github.com/perl6/roast/commit/79e86e5f14 POV: github.com/rakudo/rakudo/commit/bb88a0324e Docs: github.com/perl6/doc/commit/f55804fc62		 13:05
lizmat commute to NR.pm& 14:00
Geth rakudo: 58592bd0de | (Elizabeth Mattijsen)++ | src/core/Rakudo/Internals/JSON.pm6
We only need the Actions class, no instace
 14:59
tony-o lizmat++ 15:26
Geth rakudo: c9432c2072 | (Elizabeth Mattijsen)++ | src/core/Rakudo/Internals/JSON.pm6
Attempt #2 at making R:I:JSON.from-json faster

This time the quick version looks at whether the outer part is an array, and if so, parses the JSON for outer { } pairs, and then let's those be parsed in parallel in batches of 32.
This makes parsing of the project.json about 2x as fast, *regardless* of any special formatting of the JSON.		 15:27
japhb lizmat: What made you pick batches of 32? 15:39
Geth nqp/truffle: 5 commits pushed by (Paweł Murias)++ 15:42
AlexDaniel japhb: doesn't sound like a bad choice. FWIW that's not how many threads you'll get, this number can be anything really 15:43
japhb AlexDaniel: Well IIRC the default batch size for hyper is 64, so I'm curious if lizmat found there was a significant performance difference, or wanted to avoid performance loss if the default changed, or somesuch 15:45
AlexDaniel ah ok
IMO both should work just fine
AlexDaniel so what's the logic in that last commit? 15:55
I fail to understand how could it possibly be valid
I mean, correct
so it searches for { 15:56
and checks that it's not \{
so what if my name is "Alex{Daniel}" ? 15:57
is that invalid json or something?
m: say to-json %(foo => ‘Alex{Daniel}’) 15:58
camelia {
"foo" : "Alex{Daniel}"
}
AlexDaniel ok that's obviously not a problem, but 15:59
m: say to-json %(foo => ‘Alex{Daniel’)
camelia {
"foo" : "Alex{Daniel"
}
AlexDaniel that is, right?
Zoffix Sanity check for R#1493 `my Int:D @a; dd @a[^3]` gives `(Int, Int, Int)` in 6.d. Does that make sense? These values don't pass the type constraint. 16:05
synopsebot R#1493 [open]: github.com/rakudo/rakudo/issues/1493 [6.d] .= call on DefiniteHOW tries to create an instance of DefiniteHOW
Zoffix FWIW currently it gives `(Int:D, Int:D, Int:D)` which doesn't pass type constraint either 16:06
Same goes for unset keys in hashes
timotimo yeah, to me it makes no sense to use that construct without an "is default"
Zoffix crap and the error with assignment of Nil is LTA in 6.d 16:07
$ ./perl6 -e 'use v6.d.PREVIEW; my Int:D @a; @a[3] = Nil'
Type check failed in assignment to @a; expected Int:D but got Int (Int)
in block <unit> at -e line 1 16:08
$ ./perl6 -e 'my Int:D @a; @a[3] = Nil'
Type check failed in assignment to @a; expected type Int:D cannot be itself (perhaps Nil was assigned to a :D which had no default?)
in block <unit> at -e line 1
looks fairly straightforward to fix that tho 16:10
AlexDaniel .tell lizmat 1 question from japhb and 1 from me: colabti.org/irclogger/irclogger_log...09-20#l300 16:15
yoleaux AlexDaniel: I'll pass your message to lizmat.
Zoffix lizmat gets all the questions :)
AlexDaniel: bot ded? 16:16
commitagble
AlexDaniel :barjavel.freenode.net 465 committable6test You are banned from this server- Your irc client seems broken and is flooding lots of channels. Banned for 240 min, if in error, please contact [email@hidden.address] (2018/9/20 15.39)
diakopter heh
Zoffix <Zoffix-2016> why don't you make a single bot with many features instead of many bots with a single feature each? 16:17
diakopter the old p6eval bot (written in Perl 5) could reload its modules dynamically when they were updated so it didn't have to disconnect 16:19
AlexDaniel well, very often people want to just say “bisectable: … … …” without trying to figure out what's the right command to trigger what
but yeah, things can be improved, I agree
diakopter bots can respond to something: other than their names 16:20
AlexDaniel diakopter: yeah but how would you know that “something”
diakopter it's programmed in, as in camelia 16:20
AlexDaniel for those who use them often it's not an issue, of course
AlexDaniel eventually I'll rewrite them to use Matrix::Client or something like that 16:23
diakopter the very meaning of the word "bisectable" is tied to knowledge of the bot's existence :D
lizmat japhb: without :32batch, project.json parses at 1.06, with it at .93 16:26
yoleaux 16:15Z <AlexDaniel> lizmat: 1 question from japhb and 1 from me: colabti.org/irclogger/irclogger_log...09-20#l300
AlexDaniel btw anyone should feel free to take over whateverable project 16:27
especially if they want to improve things like this :)
lizmat AlexDaniel: re "Alex {Daniel}" : it counts the number of matching { } that are not escaped/ 16:28
AlexDaniel lizmat: so what if there's a { in a string? 16:29
lizmat once it sees the outer matching }, it produces a chunk
AlexDaniel unclosed one, for example
lizmat then it would break and it would fall back to the normal one, serialized
Zoffix lizmat: what do you think of `my Int:D @a; dd @a[^3]` giving `(Int, Int, Int)`? Is there anything better it could give? 16:30
I guess even a `Nil` won't be assignable back to it... hm 16:31
m: my Int:D @a; @a = @a[^3]
camelia Type check failed in assignment to @a; expected type Int:D cannot be itself (perhaps Nil was assigned to a :D which had no default?)
in block <unit> at <tmp> line 1
Zoffix m: (my Int:D @values)[3] = 42; say [+] @values 16:32
camelia 42
Zoffix huh
m: dd Int:D + 42 16:33
camelia Invocant of method 'Bridge' must be an object instance of type 'Int', not a type object of type 'Int:D'. Did you forget a '.new'?
in block <unit> at <tmp> line 1
Zoffix How does `[+]` skip the Int:Ds at the head? :S
lizmat no idea
Zoffix Ah, it's optimized to call sum
m: (my Int:D @values)[3] = 42; sub infix:<+> { &CORE::infix:<+>(|@_) }; say [+] @values 16:35
camelia Invocant of method 'Bridge' must be an object instance of type 'Int', not a type object of type 'Int:D'. Did you forget a '.new'?
in sub infix:<+> at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat Zoffix: yeah, we cheat sometimes :-) 16:36
Geth nqp/truffle: c3247c7ff7 | (Paweł Murias)++ | 2 files
[truffle] Add missing files
 16:42
nqp/truffle: 3da3fc0e39 | (Paweł Murias)++ | 2 files
[truffle] Print out an error when running NYI stuff at runtime
nqp/truffle: 42f0e1b276 | (Paweł Murias)++ | src/vm/jvm/bin/cross-compile.nqp
[truffle] Add a script to compile to both truffle bytecode and jvm bytecode
Zoffix m: my Int:D &foo; dd &foo.signature 17:01
camelia No such method 'signature' for invocant of type 'Callable'
in block <unit> at <tmp> line 1
Zoffix kinda LTA error
TimToady that .sum cheating is how we get away with [+] 1..100000000000000000000
Zoffix yeah 17:02
m: my Int:D &foo = sub (--> Int:D) {}; dd &foo.signature
camelia :( --> Int:D)
Zoffix m: my Int:D &foo = -> --> Int:D {}; dd &foo.signature
camelia Type check failed in assignment to &foo; expected Callable[Int:D] but got Block (-> --> Int:D { #`(Bl...)
in block <unit> at <tmp> line 1
Zoffix Weird. Why doesn't it like the Block?
m: dd [.^mro, .^roles] given --> Int:D {} 17:03
camelia 5===SORRY!5=== Error while compiling <tmp>
Prefix -- requires an argument, but no valid term found
at <tmp>:1
------> 3dd [.^mro, .^roles] given --7⏏5> Int:D {}
expecting any of:
prefix
Zoffix m: dd [.^mro, .^roles] given -> --> Int:D {}
camelia Array element = [(Block, Code, Any, Mu), (Callable,)]
Zoffix it ain't parametarized
Zoffix R#2296 R#2295 17:09
synopsebot R#2296 [open]: github.com/rakudo/rakudo/issues/2296 [LTA] LTA error when calling methods on undefined Callable variable
R#2295 [open]: github.com/rakudo/rakudo/issues/2295 [consistency] Blocks don't get parametarized with return type
Zoffix And now I forgot what I was doing.... :)
m: my Int enum <a b c>; dd a 17:16
camelia ::a
Zoffix m: my Int:D enum <a b c>; dd a
camelia 5===SORRY!5=== Error while compiling <tmp>
Cannot find method 'mro' on object of type Perl6::Metamodel::DefiniteHOW
at <tmp>:1
japhb timotimo: JSON::Fast's t/04-roundtrip.t seems to be a bit loose about numeric types ('Array of Num' and 'Hash of Num' don't have Nums, for instance). 17:17
Zoffix R##2297
R#2297
synopsebot R#2297 [open]: github.com/rakudo/rakudo/issues/2297 Crash when parametarizing enums with DefiniteHOWs
timotimo japhb: yeah, json simply doesn't do that 17:20
if i'm not misunderstanding
japhb timotimo: Right, I'm saying it might be worth specifying what *is* expected for each of our Numeric types, even if we know that e.g. Num will become Rat on roundtrip, at least we can check that this behavior doesn't change from release to release. 17:27
Actually, we should be able to roundtrip at least those two based on presence or absence of exponent in the JSON. 17:29
timotimo hm, then we'll also interpret data from "outside" as rats even when they were floating point values 17:36
Zoffix m: -> Int:D @v { @v[^3] }(my Int:D @) 17:49
camelia ( no output )
Zoffix m: -> Int:U @v { @v[^3] }(my Int:U @)
camelia Parameter '@v' of routine '<anon>' must be a type object of type 'Positional[Int]', not an object instance of type 'Array[Int:U]'. Did you forget a 'multi'?
in block <unit> at <tmp> line 1
Zoffix man, getting sick of all these bugs :(
Zoffix squints 17:50
Zoffix Looks like it's interpreting the :U to mean the Positional must be a type object instead of its type being a type object 17:50
Zoffix R#2298 17:56
synopsebot R#2298 [open]: github.com/rakudo/rakudo/issues/2298 :U parametarized@,%,& parameters are incorrectly parametarized
Zoffix ZofBot: rant about not writing tests for features leading to these sorts of bugs 17:57
japhb timotimo: Maybe a way to mark wanting to parse Rat similar to requesting parsing of Inf/-Inf/NaN? 17:58
Zoffix really weird. My change that's meant to impact only 6.d is hanging S10-packages/require-and-use.t because it fails to detect circularity :S gist.github.com/zoffixznet/0c6a46a...855fe4412c 18:31
The only non-6.d part is this: gist.github.com/zoffixznet/0c6a46a...ff-L43-L44 18:32
Zoffix (and removing it doesn't fix the issue :S) 18:36
Zoffix Wait, is it my changes even? Does S10-packages/require-and-use.t hang for anyone else? 18:37
I see there's a .to-json call like right after the circularity detecting die statement
guess I can just reset and build HEAD 18:38
AlexDaniel: looks like during 6.d release, you'll dethrone me for the number of consecutive releases :) 18:43
[Coke] wonders how long ago he lost the record.
Zoffix OK, *phew*, the hang ain't due to my smiley work
AlexDaniel time flies 18:44
Zoffix swats
[Coke] 2017.01, when zoffix beat me. Well done. :) 18:45
Zoffix :) 18:46
AlexDaniel btw there's a chance that I will be away for a bit in July next year 18:47
so if there's anyone willing to do some releases they should start preparing mentally :)
Zoffix hm, stresstest is also now 190s 18:51
vs 156s ~8 hours ago
Geth rakudo: 1ff9fa32f0 | (Zoffix Znet)++ | src/Perl6/Actions.nqp
Use actual value in `constant` typecheck error

This way we can report value correctly for :U = 42 messges, for example.		 18:53
Zoffix I wonder if that's all the new language version checking for every damn container :S
or variable/constant rather
and parameters
Zoffix hm, nope 18:56
a file with 4000 variables get run a bit faster on my HEAD than on 2018.06-289-g38de1e5
Geth rakudo: 38b198c992 | (Zoffix Znet)++ | 3 files
[6.d] Set non-DefiniteHOW default default for DefiniteHOWs

Per 6.d-prep[^1]: On :U/:D type constrained variables, params, attributes, and parametarized Arrays/Hashes, use the base type as the default default in 6.d instead of continuing to use the uninitializeable DefiniteHOW as the type, which prevents use of `.=` and other constructs.
... (5 more lines)		 19:00
roast: 8c8e8f55bb | (Zoffix Znet)++ | MISC/misc-6.d.t
Spec DefiniteHOW's default defaults

They are now base types instead of DefiniteHOW typeobjects.
Per 6.d-prep: github.com/perl6/6.d-prep/blob/dff...rmal-types POV: github.com/rakudo/rakudo/commit/38b198c992 Enum POV is blocked by R#2297 github.com/rakudo/rakudo/issues/2297 and is not specced.		 19:02
synopsebot R#2297 [open]: github.com/rakudo/rakudo/issues/2297 Crash when parametarizing enums with DefiniteHOWs
6.d-prep: a0bc5390fc | (Zoffix Znet)++ | 2 files
Make DefiniteHOW's default defaults as completed

POV: github.com/rakudo/rakudo/commit/38b198c992 Propspec: github.com/perl6/roast/commit/8c8e8f55bb Docs: github.com/perl6/doc/commit/44ac0f916d		 19:07
Zoffix m: dd from-json '["A", "B"]' 19:11
camelia Array element = []
Zoffix I think I see it. 19:17
ZofBot: ready the sandwich bread! 19:18
geekosaur release the crackin' ? 19:21
Geth ¦ rakudo: zoffixznet assigned to lizmat Issue t/spec/S10-packages/require-and-use.t hangs github.com/rakudo/rakudo/issues/2299 19:22
travis-ci Rakudo build passed. Zoffix Znet 'Use actual value in `constant` typecheck error 19:25
travis-ci.org/rakudo/rakudo/builds/431171251 github.com/rakudo/rakudo/compare/c...f9fa32f020
timotimo they sell a kitkat knock-off here that they call "crack'n'snack" 19:29
Geth 6.d-prep: 5ff4072f24 | (Zoffix Znet)++ (committed using GitHub Web editor) | TODO/FEATURES.md
Don't set the date for 6.e

I'm thinking we might go for 2-year cycles instead of 1 year.		 19:42
travis-ci Rakudo build passed. Zoffix Znet '[6.d] Set non-DefiniteHOW default default for DefiniteHOWs 19:56
travis-ci.org/rakudo/rakudo/builds/431174180 github.com/rakudo/rakudo/compare/1...b198c99285
Geth nqp/truffle: 7bbcb7bcd5 | (Paweł Murias)++ | src/vm/jvm/runtime/org/perl6/nqp/truffle/runtime/NQPCodeRef.java
[truffle] Fix setting of outer in declaration_static blocks
 20:18
nqp/truffle: fc0e8de647 | (Paweł Murias)++ | 2 files
[truffle] Stub nqp::decont
japhb This seems very fishy: gist.github.com/japhb/eb81ecc106fb...be0e988ed4 20:57
Anyone else able to replicate that? (Same loop taking either 5.8 seconds or 42-45 seconds, seemingly on the flip of a coin.)
jnthn japhb: That's interesting... 21:17
japhb: If you MVM_SPESH_DISABLE=1 does it consistently run at the slower time? Ditto for MVM_SPESH_OSR_DISABLE=1 21:18
timotimo did you mean ..._INLINE_...?
jnthn No :P 21:20
...I wondered if I'd typed into google instead of IRC for a moment then, though :P
I don't think there's anything to inline by runtime on that one
timotimo OK
jnthn I think the static optimizer gets it all
OSR is the thing that moves us from an interpreted hot loop to a spesh'd/jit'd one 21:21
And, I'm guessing, what might be reliably triggering here
japhb Trying with MVM_SPESH_DISABLE=1 ... 21:25
timotimo i didn't actually look at the code until right now 21:26
:S
surely that's just the repl being silly? :)
japhb Yes, consistently slow with MVM_SPESH_DISABLE=1 (after 4 runs). Now trying with MVM_SPESH_OSR_DISABLE=1 ... 21:28
jnthn m: say "spesh/jit make it {43.1 / 5.81}x as fast" 21:30
camelia spesh/jit make it 7.418244x as fast
diakopter to a billion and beyond! 21:31
japhb Yep, consistently slow with MVM_SPESH_OSR_DISABLE=1 as well. In fact, even slower. Instead of 42-45 seconds, more like 44-49 seconds (over 5 runs). 21:33
jnthn How about MVM_SPESH_BLOCKING=1 ? 21:35
japhb Giving it a try ... 21:36
Consistently fast, and nice tight clustering too (5.82-5.86 seconds) 21:37
timotimo ooh
you remember that time i told you about code being OSR'd, but the check for an OSR'd result was coming back empty? 21:38
because the callsite wasn't matching up with what was being logged?
it could very well be this
diakopter I sense a big opportunity 21:40
jnthn Yeah, I'm wondering if it is 21:41
But this is a very nice small example :)
japhb :-)
jnthn japhb++
japhb That was the result of a couple hours of WTH ...?
jnthn I can't look at it right now, but if you've a moment to make a MoarVM ticket... :)
japhb Sure, will do. 21:42
diakopter can you bisect to find the lowest 1_000_000_000 at which it happens
is it bimodal at 100_000 21:45
japhb diakopter: The loop is fast enough that I had to use a big number to get above the noise floor on my machine. 21:46
(*sufficiently* above the noise floor, I mean)
Doesn't spesh kick in at loop counts in the low hundreds these days? 21:47
Oh, forgot to link: github.com/MoarVM/MoarVM/issues/968 21:48
jnthn japhb: Yes, but it does its work on a background thread 21:53
During which time such a hot loop will interpret quite a few more iterations
timotimo at some point we need to put in loop unrolling so that absurdly short loops like these get just a tiny bit faster 21:54
lizmat . 22:29

Powered by Cro and the Raku® Programming Language.

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

Thank you!