github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
timotimo m: say (100 * 100 * 500) / 2.7 00:10
camelia 1851851.851852
timotimo m: say (80 * 80 * 500) / 11.25 00:11
camelia 284444.444444
timotimo m: say 1851851.851852 / 284444.444444
camelia 6.510416666677
timotimo i turned off the graphics output and put nqp stuff into the innermost loop
also i found that i accidentally had one + too many in a row that made performance much worse just by existing 00:12
MasterDuke what do you mean just by existing? 00:20
timotimo something somewhere got slightly confused because i had a prefix:<+> in there in the row of infix:<+> 00:29
MasterDuke huh 00:32
timotimo m: say (100 * 100 * 500) / 2.14 00:34
camelia 2336448.598131
timotimo removed just a tiny bit more overhead 00:35
m: say (100 * 100 * 500) / 1.54 00:39
camelia 3246753.246753
timotimo using a loop(;;) instead of a for with a range
MasterDuke the for+range wasn't getting converted to a while?? 00:43
timotimo m: say (100 * 100 * 500) / 1.35
camelia 3703703.703704
timotimo no, the end values weren't constant
or do we have that now?
^- i changed the other loop that does things into a loop(;;), too 00:44
it used to actually be two loops, just because i wrote the code lazily
but it only ever took 0.3 seconds in total
which wasn't much when the total time was still above 10 seconds
MasterDuke well, my PR hasn't been merged, but it still requires things to be literal/constant 00:45
and is only about offsets to ranges 00:46
timotimo OK 00:47
well, it was based on a variable, though a very rarely changing one
i.e. it only changes at the beginning of the program when it comes from the commandline arguments
hum. our current MAIN can't handle native ints, eh? 00:49
perl6 -e 'sub MAIN(int $a) { say $a }' 99
Usage:
-e '...' <a>
m: say (100 * 100 * 500) / 0.9 00:50
camelia 5555555.555556
timotimo what a beautiful number
m: say (200 * 200 * 500) / 2.2 00:51
camelia 9090909.090909
timotimo jesus
needless to say, this is somewhat fast now
MasterDuke but hm, any reason `my $a = 3; .say for ^$a { <...> }` couldn't be turned into `my int $counter = -1; while(++$counter < $a; <...>)`?
timotimo +/- freezing $a in place 00:52
MasterDuke ?
timotimo well, it can only read $a once 00:53
also, it can't just use int there
unless $a is known to be native int
MasterDuke ok, use Int if not native
but $a gets read through every iteration of the while, right? hm, that could be different if $a is modified in the body 00:55
timotimo right, the ^$a version will only read $a once, then $a is free to be modified without changing how the loop behaves
MasterDuke well, you could just create a new variable to be checked against that just gets the value of $a initially 00:56
timotimo that's what we should do
m: say (200 * 200 * 500) / 2 01:02
camelia 10000000
timotimo because i needed a good big round number at the end of the day
the code doesn't look pretty now.
japhb timotimo: The trick is to do all the work to make it super fast, damn the consequences ... then given what you learned, see where you can optimize for readability again without losing too much speed. You're already over 35x faster than when you started. Can you get back to good looking code that is only, say, 30x faster? 02:46
nine japhb: the real trick is to do all the optimizations to make it super fast manually like timotimo and then teaching rakudo/MoarVM to do those automatically ;) 06:47
timotimo you know ... and this is going to sound bad ... if chrome and firefox fail at the gigantic html files the profiler spits out because the json literal is either too long or nested too deep ... 18:01
we could, like, tear it apart into pieces and structurally concatenate it later on
ooh, sqlite actually has a json extension that might allow me to remove some JSON::Fast overhead in the profiler backend 18:05
japhb nine: Granted. But the thing I'm talking about is a good skill to have when making codebases (such as Rakudo and Moarvm, say) both clean and fast. Because if the optimizations make the code totally unreadable, it gets progressively harder to add more of them. :-) 19:00
nine japhb: yes, of course :) 19:08
Geth MoarVM/master: 7 commits pushed by (Stefan Seifert)++ 20:06
timotimo ooh, we have hllbool now? 20:22
Kaiepi what does hll do? 20:39
timotimo HLLs are a way for us to differentiate code that was compiled by the nqp compiler and code that was compiled by the rakudo compiler; both have different semantics, but more importantly different types for many things 22:11
masak the term "HLL" seems to be borrowed from Parrot 22:54
geekosaur "high(er) level language" isn't that uncommon a term 23:16
timotimo yes, but having individual settings for supporting different ones at the same time in a VM is a bit less common :) 23:19

Powered by Cro and the Raku® Programming Language.

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

Thank you!