Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-08-04

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:52 ilbot3 joined #moarvm
01:52 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:44 http_GK1wmSU joined #moarvm
02:47 http_GK1wmSU left #moarvm
04:12 vendethiel joined #moarvm
04:56 lizmat joined #moarvm
06:01 brrt joined #moarvm
07:11 brrt joined #moarvm
08:06 brrt good * #moarvm
08:13 zakharyas joined #moarvm
08:30 vendethiel- joined #moarvm
08:33 harrow joined #moarvm
08:48 vendethiel joined #moarvm
08:57 edehont joined #moarvm
08:59 brrt interestingly, my bug is insensitive to gc debugging
08:59 brrt so i think i'm adding a pointer somewhere
08:59 brrt to garbage
09:10 jnthn moarning o/
09:13 jnthn Second to last day of the heatwave...
09:20 brrt moarning jnthn
09:20 jnthn o/ brrt
09:20 jnthn How's your pointer to garbage hunt going?
09:21 brrt not super good
09:22 brrt my second bisect had a slightly different frame (without ASAN) that is responsible for breakage
09:22 brrt although, it might arguably still be the same frame, given that the bb numbers match up
09:23 brrt yeah, it's the same frame after all
09:23 brrt but it has a different frame number
09:23 brrt i wonder if i changed something silly
09:24 brrt i'm going to run a third bisect, and if it comes up the same, then i'm happy
09:24 brrt (i tried installing gc debugging, but it made virtually no difference)
09:40 vendethiel joined #moarvm
09:54 Geth ¦ MoarVM: 25419ccf97 | (Jonathan Worthington)++ | 7 files
09:54 Geth ¦ MoarVM: When logging invokes, don't store closures.
09:54 Geth ¦ MoarVM:
09:54 Geth ¦ MoarVM: This can, in some cases, seriously extend the lifetimes of objects
09:54 Geth ¦ MoarVM: that were closed over. Instead, just log what we'll really want: the
09:54 Geth ¦ MoarVM: static frame of the invocation target (which actually simplifies the
09:54 Geth ¦ MoarVM: handling in the stats code) and whether the caller was its outer (this
09:54 Geth ¦ MoarVM: will be useful for future optimizations).
09:54 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/25419ccf97
09:58 jnthn Nice. In the read a million lines benchmark that wins us a bit back by meaning we no longer do 2 full GC runs due to things getting promoted
10:14 brrt well, third bisect agrees with first
11:23 jnthn lunch; bbiab
11:28 markmont joined #moarvm
11:34 TimToady joined #moarvm
11:52 AlexDani` joined #moarvm
11:57 * jnthn back
12:16 brrt joined #moarvm
12:18 dogbert17 joined #moarvm
12:22 AlexDani` joined #moarvm
13:00 brrt joined #moarvm
13:06 zakharyas joined #moarvm
13:53 Geth ¦ MoarVM: f66c82641a | (Jonathan Worthington)++ | 3 files
13:53 Geth ¦ MoarVM: Move stack simulation types into header.
13:53 Geth ¦ MoarVM:
13:53 Geth ¦ MoarVM: So we'll be able to refer to them outside of the spesh stats source
13:53 Geth ¦ MoarVM: file.
13:53 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f66c82641a
13:53 Geth ¦ MoarVM: e354d1f901 | (Jonathan Worthington)++ | 4 files
13:53 Geth ¦ MoarVM: Start keeping simulated stack around between logs.
13:53 Geth ¦ MoarVM:
13:53 Geth ¦ MoarVM: So we can continue incrementing OSR points and accumulating data in
13:53 Geth ¦ MoarVM: long-lived frames. At least, that's the theory; it doesn't seem to
13:53 Geth ¦ MoarVM: quite manage that yet. It does, however, seem to avoid various bad
13:53 Geth ¦ MoarVM: stack depth values, so the ordering of specializations works out
13:54 Geth ¦ MoarVM: looking more like it should.
13:54 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e354d1f901
14:13 Geth ¦ MoarVM: e12d52c251 | (Jonathan Worthington)++ | 4 files
14:13 Geth ¦ MoarVM: Record and insert rw-ness into type tuples.
14:13 Geth ¦ MoarVM:
14:13 Geth ¦ MoarVM: Gets us able to resolve more multis and do more inlining again.
14:13 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e12d52c251
14:15 zakharyas joined #moarvm
14:31 brrt joined #moarvm
14:35 Geth ¦ MoarVM: d865eb5172 | (Jonathan Worthington)++ | src/spesh/optimize.c
14:35 Geth ¦ MoarVM: Fix "close enough to inline" check.
14:35 Geth ¦ MoarVM:
14:35 Geth ¦ MoarVM: 99% was meant to be sufficient, but never was due to > instead of >=.
14:35 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d865eb5172
14:35 Geth ¦ MoarVM: 9f9c4b4673 | (Jonathan Worthington)++ | src/spesh/stats.c
14:35 Geth ¦ MoarVM: Fix accounting error in callsite stats.
14:35 Geth ¦ MoarVM:
14:35 Geth ¦ MoarVM: Led to spurious planning of unrequired certain specializations.
14:35 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9f9c4b4673
14:49 Slaash joined #moarvm
14:51 Slaash left #moarvm
14:56 travis-ci joined #moarvm
14:56 travis-ci MoarVM build errored. Jonathan Worthington 'Fix accounting error in callsite stats.
14:56 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/261031926 https://github.com/MoarVM/MoarVM/compare/e12d52c25131...9f9c4b4673f2
14:56 travis-ci left #moarvm
14:58 lizmat just as I was about to do a version bump
15:01 Zoffix github error
15:01 * Zoffix is getting angry unicorns in the browser too
15:07 brrt joined #moarvm
15:16 jnthn ah, just a git clone error
15:18 * japhb wonders from what source data (if any) https://github.com/status is computed from
15:18 brrt okay, i may have found the source of my weird, weird bug
15:19 brrt ???? and it may be embarassing
15:19 japhb brrt: Congrats on finding it nonetheless!
15:19 brrt maybe :-P
15:19 jnthn brrt: haha, can't beat my d865eb5172 in terms of embarassing find today :P
15:20 brrt anyway, turns out, carg will put arguments on the stack for anything that isn't a int or a ptr
15:20 brrt which is ehm, surprising
15:30 Geth ¦ MoarVM/even-moar-jit: 82ca7faf91 | (Bart Wiegmans)++ | 3 files
15:30 Geth ¦ MoarVM/even-moar-jit: ARGLIST on should not be fussy about type
15:30 Geth ¦ MoarVM/even-moar-jit:
15:30 Geth ¦ MoarVM/even-moar-jit: I think a casual user could be forgiven for not caring about the
15:30 Geth ¦ MoarVM/even-moar-jit: difference about int and ptr and reg (although if portability is a
15:30 Geth ¦ MoarVM/even-moar-jit: concern, it is a real difference). So the code for selecting arg
15:30 Geth ¦ MoarVM/even-moar-jit: locations should not be fussy about that difference (the ABI isn't).
15:30 Geth ¦ MoarVM/even-moar-jit:
15:30 Geth ¦ MoarVM/even-moar-jit: This appears to fix the bugs in CORE.setting compilation reported
15:30 Geth ¦ MoarVM/even-moar-jit: by nwc10++, but I'm not 100% positive since ASAN on OS X does not
15:30 Geth ¦ MoarVM/even-moar-jit: quite meet my expectations.
15:30 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/82ca7faf91
15:34 japhb brrt: Is it ready for merge after that fix?
15:35 brrt if it passes ASAN, then i'd hope so
15:35 brrt strictly speaking that was a template bug, not a compiler bug, but the unfussing should help a bit
15:37 brrt but i mean, we've got to draw the line somewhere :-)
15:38 japhb Indeed!
15:41 jnthn m: say 1741 / 349
15:41 camelia rakudo-moar 5d200f: OUTPUT: «4.988539?»
15:41 jnthn m: say 1741 / 351
15:41 camelia rakudo-moar 5d200f: OUTPUT: «4.960114?»
15:41 jnthn Hmm
15:41 jnthn A bit of dodgy arithmetic somewhere in the stats, methinks...
15:42 lizmat .oO( off by two )
15:44 jnthn Off by a fator of 5 actually
15:46 lizmat 349 vs 351  :-)
15:46 jnthn Oh, I was trying to see if 1741 was an exact multiple of the other two
15:53 brrt (351 is 3^3*13, 349 is prime
15:56 Geth ¦ MoarVM: 8153063fa0 | (Jonathan Worthington)++ | src/spesh/stats.c
15:56 Geth ¦ MoarVM: Bump spesh stats version on updates.
15:56 Geth ¦ MoarVM:
15:56 Geth ¦ MoarVM: Otherwise we'll never do planning for them, and so never produce new
15:56 Geth ¦ MoarVM: specializations. This was the final issue blocking OSR of long-lived
15:56 Geth ¦ MoarVM: frames that are hot loops, but highly costly on their first call (by,
15:56 Geth ¦ MoarVM: for example, spending time in the multi-dispatch slow path for some
15:56 Geth ¦ MoarVM: calls).
15:56 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8153063fa0
15:58 jnthn Hmmm
16:00 jnthn Well, weekends pondering: can we do a better job of exception handler representation in the CFG than anchoring them all from the entry block?
16:01 sivoais joined #moarvm
16:05 jnthn I think we surely can
16:05 jnthn Though at a cost
16:05 jnthn We'd need to insert actual BB breaks at all invokish/throwish (which arguably we should anyway)
16:05 timotimo those are a lot of ops
16:05 jnthn Then when we're in the region of a handler, we make all such BBs have the exception handler as a successor
16:06 jnthn timotimo: It is, but this is just a graph representation, so the only real cost is at spesh time
16:06 timotimo i'm not sure how many of our optimizations require there to be no bb break between things
16:06 timotimo right
16:06 jnthn Well, and for us reading the graph
16:06 jnthn I don't think many of them do
16:06 jnthn Because we have an SSA representation
16:06 jnthn The problem is that if you consider something like
16:06 jnthn my $iterator := $seq.iterator;
16:07 jnthn while (my $val := $iterator.pull-one) !=:= IterationEnd { ...stuff... }
16:07 jnthn We'd really like to be able to spesh that pull-one call
16:08 jnthn But we can't
16:08 jnthn Because $iterator isn't known because of a PHI merge from the 0 node
16:08 jnthn Because "redo" exceptions take you to the start of the loop
16:08 jnthn But we don't have a precise representation of such things
16:08 timotimo ah, redo, right
16:08 lizmat jnthn: and $iterator, aka a lexical ?
16:08 lizmat ah, eyes  :-(
16:09 jnthn lizmat: Actually they're not lexicals in the code I'm considering here :)
16:10 jnthn (Lowered to registers)
16:10 jnthn Anyway, because we stick an edge from 0 from all handlers, we conservatively figure we don't know what's in the register
16:11 jnthn So we can't do anything about that findmethod op except the usual monomorphic cache trick
16:12 jnthn Which of course means we don't know the coderef so we can't sp_fastinvoke_o it (or inline it were it small enough)
16:15 Geth ¦ MoarVM: 8325f0117b | (Jonathan Worthington)++ | src/spesh/stats.c
16:15 Geth ¦ MoarVM: Better no-arg and no-object-arg callsite handling.
16:15 Geth ¦ MoarVM:
16:15 Geth ¦ MoarVM: Give these all a single type specialization. This means that we can
16:15 Geth ¦ MoarVM: now use logged information in performing the optimization of them.
16:15 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8325f0117b
16:16 TimToady joined #moarvm
16:19 jnthn Well, tests seem happy and stuff :)
16:21 jnthn So, I think that's my spesh hackery for this week.
16:24 jnthn Overall status now is that we have (a) a much better data set to work on, (b) a LOT less spesh bugs and various historical workarounds cleared up, (c) the ability to inline/fastinvoke more things already (and potential for a bunch more), (d) are doing the work on a background thread
16:25 travis-ci joined #moarvm
16:25 travis-ci MoarVM build passed. Jonathan Worthington 'Bump spesh stats version on updates.
16:25 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/261063197 https://github.com/MoarVM/MoarVM/compare/9f9c4b4673f2...8153063fa0b2
16:25 travis-ci left #moarvm
16:25 nwc10 so even single threaded "traditional" code can exploit both cores of one's smartwatch...
16:25 Zoffix \o/
16:25 jnthn This has been...a lot of work.
16:25 Zoffix jnthn++
16:25 nwc10 jnthn++
16:26 nwc10 I hope that past jnthn has rewared future jnthn with a suitably filled beer fridge
16:26 timotimo nwc10: not terribly likely that the usage of the second processor will go up very far
16:26 timotimo unless we make our spesh optimizer do a whole lot more stuff
16:27 nwc10 which is now a more sensible option to choose/explore, because it's not a direct slowdown on (under loaded) multi-core machines
16:28 nwc10 but "make the CPU hot because we can" isn't an end in itself :-)
16:29 nwc10 We could make the spesh thread mine bitcoin when it would otherwise be idle, and donate to http://www.perlfoundation.org/perl_6_core_development_fund
16:29 nwc10 this is neither cost effective nor ethical
16:30 jnthn Talking of TPF...
16:30 jnthn Well, or said fund
16:31 jnthn Around 4 weeks ago I was told the grant was approved, at which point I put aside all other work so I could focus full time on getting this spesh stuff done, which it really needed. Then a couple of days after I'd dug in, I was told they would announce it after completing one internal legal procedure.
16:32 jnthn So anyway, I've actually been working for about 4 weeks full time before TPF put up the announcement.
16:32 jnthn Which means there's rather *less* than 200 hours left by this point.
16:32 nwc10 "yay"
16:36 Zoffix Understandable.
16:36 Zoffix We need to get jnthn++ more money \o/
16:37 Zoffix I think I know of a way to get a bit, actually. Gonna think about it over the weekend.
16:37 Zoffix like 1-2 grand
16:41 edehont joined #moarvm
16:41 jnthn :)
16:42 * jnthn wonders how many weeks escape analysis and related opts would need...
16:43 nwc10 1) what would be the estimated benefit
16:43 nwc10 2) does most of the benefit only happen near the end of the work, or is some of it incremental?
16:43 nwc10 and i guess even
16:43 nwc10 3) does it open up more stuff that other folks could do
16:44 jnthn Good question. My guess on (1) is "fairly high" for Perl 6 in that at the moment:
16:44 nwc10 (not that it's obvious who might be other folks)
16:44 jnthn my $a = foo(); bar($a);
16:44 jnthn Where bar is sub bar($b) { }
16:44 jnthn GC allocates a Scalar container
16:45 jnthn That kind of thing is very common
16:45 nwc10 .tell brrt 'works on "my" machine' - ie ASAN views origin/even-moar-jit as boring.
16:45 jnthn So I suspect a *lot* of Scalars would be possible to avoid allocating using the GC
16:46 jnthn Probably a number of temporary box/unbox too
16:46 jnthn 2 - probably partly incremental in that you can do the inter-procedural bit later, but given nearly eveyrthing in Perl 6 is a procedure call... :)
16:47 jnthn (Before inlining)
16:47 jnthn Granted you'd do this after inlining
16:47 timotimo well, we already do inlining :)
16:49 jnthn Right :)
16:49 jnthn I mean you'd inline *then* perform the analysis
16:49 timotimo oh, yes indeed
16:50 travis-ci joined #moarvm
16:50 travis-ci MoarVM build passed. Jonathan Worthington 'Better no-arg and no-object-arg callsite handling.
16:50 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/261069689 https://github.com/MoarVM/MoarVM/compare/8153063fa0b2...8325f0117b78
16:50 travis-ci left #moarvm
16:50 timotimo the spvm author wrote a post "spvm is now 6x faster than perl 5.26" and says that'll go up to 20x when a jit is implemented
16:50 brrt joined #moarvm
16:51 timotimo i'm hoping to see the actual code they used to get to that number
16:52 jnthn Yeah, I was curious about the claim, but figured I can wait for the results :)
16:52 timotimo i see moarvm.org/measurements has entries for recent days, too. they are all 0 bytes big, though
16:53 nwc10 I think that it might be "6x faster than Perl 5.26 for the things that spvm can do" but this part is unclear
16:54 jnthn I figured it was "for a very specific set of benchmarks"
16:54 timotimo yeah, spvm is "for fast computations", which i assume means arithmetic and such
16:55 brrt nwc10: thats good news
16:55 timotimo i wonder if there's anything we can do to get faster random numbers
16:55 nwc10 the impression I got (not sure if I read this, inferred it, or plain got it wrong) was that the intent was to work outwards and increase the scope of the things that spvm can do
16:55 timotimo building a list from ^100 .roll(1_000_000) takes us about 6.3 seconds on my machine
16:56 timotimo running [+] on that afterwards takes only 0.8s which is nice, but not stellar
16:56 brrt i did see some broken spectests when runn
16:57 timotimo aha, 67% time spent in a push-all inside range.pm, which is osr'd + speshed, but not jitted
16:57 brrt on even-moar-jit
16:59 timotimo hah, we don't jit rand_I
16:59 timotimo that's easy!
17:01 jnthn nwc10: Yeah, keeping the speed up while adding features is the tricky part :)
17:01 jnthn nwc10: I glanced at how scope handling worked and it looked like it'd need a good re-work for closures, for example.
17:03 timotimo i wonder if we should have a specific non-bigint rand function that can do completely without Int
17:04 jnthn Righty, I'm off to cook
17:04 jnthn bbl
17:04 timotimo good cookin'
17:04 nwc10 that's a lot more thorough than my level of inspection. (clearly I slack)
17:06 timotimo actually, "just" a special case inside bigint_rand for smallbigint would be a big win already
17:06 timotimo oh, we use mp_rand, though
17:17 timotimo jitting this made hardly a difference, clearly because it spends most of its time doing other stuff
17:19 timotimo fascinating. even though $!min is 0, adding that to the result of rand_I takes about 16.8% of the total time inside push-all
17:21 timotimo it's probably rather bad that we force the bigint to full big int before every single rand_I
17:36 timotimo hum. we're using mp_mod to get a number in the range that the user was asking for
17:36 timotimo isn't that a bad idea for distributions of random numbers?
17:41 timotimo gtg, but i'll continue making rand_I faster inside moarvm
17:42 hoelzro joined #moarvm
17:42 Geth ¦ MoarVM: MasterDuke17++ created pull request #624: Fix spelling in comments
17:42 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/624
17:43 Geth ¦ MoarVM: d1951981ef | MasterDuke17++ (committed using GitHub Web editor) | src/math/bigintops.c
17:43 Geth ¦ MoarVM: Fix spelling in comments
17:43 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d1951981ef
17:43 Geth ¦ MoarVM: 604da4d062 | lizmat++ (committed using GitHub Web editor) | src/math/bigintops.c
17:43 Geth ¦ MoarVM: Merge pull request #624 from MasterDuke17/patch-2
17:43 Geth ¦ MoarVM:
17:43 Geth ¦ MoarVM: Fix spelling in comments
17:43 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/604da4d062
18:13 nwc10 jnthn: ASAN does not wish to comment on MoarVM at this time. (neither master nor even-moar-jit generate any excitement)
18:35 * lizmat wonders if this is a good moment to bump
18:35 nwc10 while jnthn is eating? :-)
18:35 [Coke] GO GO GO GO
18:38 brrt joined #moarvm
18:43 japhb lizmat: Given that jnthn++ called it a week, I'd say go for it.
18:56 brrt if you bump, i'll merge master, and create a pull request
19:00 jnthn OMG. even-moar-jit time? :D
19:00 robertle joined #moarvm
19:03 timotimo \o/
19:03 brrt uhuh
19:03 brrt i can't promise a completely clean spectest
19:05 jnthn Is it dirtier than before? :)
19:07 Zoffix :o
19:07 Zoffix wow cool :D
19:08 brrt to be honest, i don't run master so often :-)
19:08 Geth ¦ MoarVM/even-moar-jit: 26 commits pushed by MasterDuke17++, (Jonathan Worthington)++, lizmat++, (Bart Wiegmans)++
19:08 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/compare/82ca7faf91...14c3f6820a
19:09 jnthn 2017.06 did a huge I/O overhaul. 2017.07 did a ton of string/Unicode stuff. 2017.08 will be huge amount of spesh changes + huge amount of JIT changes + re-implemented GC sync up :P
19:10 jnthn Crazy times ;)
19:10 Zoffix :)
19:13 timotimo so ... with my changes to sidestep bigint arithmetic for small rand_I max values i get different numbers for the same srand initialization value
19:13 timotimo should i bother trying to make that compatible?
19:14 timotimo jnthn: opinions?
19:15 timotimo i mean, you can switch tommath between rand and arc4random with a define flag
19:15 jnthn Hmmm
19:16 jnthn I guess it behaves predictably still, just different values?
19:16 timotimo yeah
19:17 jnthn Probably it's OK
19:17 timotimo thanks, let me measure the speedup now
19:19 timotimo huh, i thought this was faster before
19:19 timotimo oh, because of the .say
19:19 timotimo ah, yes
19:20 Geth ¦ MoarVM: bdw++ created pull request #625: Merge new 'expression' JIT backend
19:20 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/625
19:21 timotimo m: say 1.5 / 5.5
19:21 camelia rakudo-moar 5d200f: OUTPUT: «0.272727?»
19:21 timotimo almost but not quite 4x
19:22 timotimo m: say (87512 + 87472 + 94660 + 94552 + 94692) / (103676 + 103752 + 103564 + 104184 + 104068)
19:22 camelia rakudo-moar 5d200f: OUTPUT: «0.8837618?»
19:23 timotimo that's the memory usage difference
19:23 [Coke] timotimo: between what and what?
19:24 timotimo srand(1); say [+] ^1000 .roll(1_000_000)
19:25 brrt okay, weekend for me
19:25 Geth ¦ MoarVM/speed_up_rand_I: db4997d87c | (Timo Paulssen)++ | 4 files
19:25 Geth ¦ MoarVM/speed_up_rand_I: jit rand_I and also give it a smallbigint path
19:25 Geth ¦ MoarVM/speed_up_rand_I:
19:25 Geth ¦ MoarVM/speed_up_rand_I: almost 4x faster for max values that fit in 32bit
19:25 Geth ¦ MoarVM/speed_up_rand_I: review: https://github.com/MoarVM/MoarVM/commit/db4997d87c
19:26 timotimo [Coke]: ^- this is the patch; the jitting itself made hardly a difference
19:30 jnthn brrt++ # now I've got my weekend reading, I guess :)
19:36 timotimo huh, infix:<+> is 50% interped, 50% jitted
19:36 timotimo how does that happen
19:36 Zoffix brrt, how long have you worked on that branch? (github shows earliest as Jan 2016, but says it's showing only latest 250 commits)
19:40 timotimo no bails in the jitlog at least
19:45 brrt joined #moarvm
19:45 brrt Zoffix: June 2015 iirc
19:45 brrt jnthn: have fun :-)
19:47 Zoffix wow. brrt++
19:47 brrt and its been over 300 commits for sure
20:39 AlexDaniel joined #moarvm
21:44 nwc10 ASAN considers origin/even-moar-jit to be unworthy of comment
21:44 nwc10 (we do not live in interesting times)
21:44 markmont joined #moarvm
21:59 japhb Speak for yourself, nwc10.  ;-)
22:05 yoleaux joined #moarvm
22:09 timotimo my branch survives spectests
22:09 timotimo but i haven't tried asan
22:11 timotimo trying now
22:11 timotimo oh
22:11 timotimo nwc10: you turn off the leak detecto, right?
22:31 timotimo cool, it's appy
22:33 Geth ¦ MoarVM: db4997d87c | (Timo Paulssen)++ | 4 files
22:33 Geth ¦ MoarVM: jit rand_I and also give it a smallbigint path
22:33 Geth ¦ MoarVM:
22:33 Geth ¦ MoarVM: almost 4x faster for max values that fit in 32bit
22:33 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/db4997d87c
22:33 Geth ¦ MoarVM: 600c2e9cf2 | (Timo Paulssen)++ | 4 files
22:33 Geth ¦ MoarVM: Merge branch 'speed_up_rand_I'
22:33 Geth ¦ MoarVM:
22:33 Geth ¦ MoarVM: adds a smallbigint path to MVM_bigint_rand so we can get around
22:33 Geth ¦ MoarVM: allocating an mp_int to hold the max value as real bigint and doing
22:33 Geth ¦ MoarVM: a mod on the mp_int to get the real value.
22:33 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/600c2e9cf2
22:37 MasterDuke timotimo, brrt: is this something that the jit could do directly in assembly? https://github.com/MoarVM/MoarVM/blob/master/src/core/interp.c#L620-L639
22:38 timotimo the expr jit can surely do this
22:38 timotimo is pow_i currently just unjitted and thus breaks some jit compilation?
22:39 MasterDuke currently unjitted, haven't checked any jit logs

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary