00:15 pyrimidine joined 01:13 pyrimidine joined 01:26 agentzh joined 01:46 geekosaur joined 02:11 agentzh joined 02:39 pyrimidine joined 02:48 ilbot3 joined 03:31 agentzh joined 03:56 pyrimidine joined 04:29 agentzh joined 04:51 geekosaur joined 04:53 njmurphy joined 05:00 agentzh joined 05:23 agentzh joined 06:12 stmuk_ joined 06:14 japhb joined, sivoais joined 06:35 domidumont joined 06:42 domidumont joined 07:03 brrt joined 07:26 KDr2 joined 07:49 domidumont joined 08:12 brrt joined 08:21 zakharyas joined 09:39 pyrimidi_ joined 09:57 agentzh joined
samcv any clue how we handle binding the same hash object to multiple keys of another hash object? 10:41
we don't replicate the hash do we?
jnthn It's binding, so they all point to the same thing 10:42
samcv hmm
jnthn It's assignment that copies
samcv so nqp::bindkey shouldn't do any copying 10:43
but %hash{$var} = %hash; might copy the hash?
jnthn It may depending on what's at %hash{$var}
samcv nothing is there yet
i need to bind a single hash to the keys of 65,000 keys of a different hash. quickly 10:44
jnthn Then you'll just assign into a Scalar, so it'll point to the existing %hash
samcv it's taking so long
like 9 minutes 10:45
jnthn m: my @keys = ^65000 .map(*.Str); my %h2 = a => 1; my %h; %h{@keys} = %h2 xx *; say now - INIT now
camelia rakudo-moar 18e6f0: OUTPUT«0.74697460␤»
samcv hmm i made some changes and now it's much faster 10:46
made it go through one less sub
jnthn hmm
samcv maybe that was causing the slowness
jnthn Maybe...anything special about the sub? 10:47
samcv jnthn, is %h{@keys} faster than doing nqp::bindkey ?
not really
jnthn No, though it's likely a good bit faster than writing for @keys { %h{$_} = %h2 }
samcv the sub just does `for Range.new($first-cp, $second-cp) { apply-hash-to-cp($_, %hash)}
and just did that same code instead in the slow sub and it seems to have made it much faster 10:48
and by much faster i mean taking 17.731817 seconds instead of like 20 minutes
jnthn o.O
Got it somewhere I can look at? 10:49
I'm busy with $other-work at the moment, but would be curious to look into why that makes such a huge difference.
samcv github.com/samcv/UCD/blob/master/U...en.p6#L479
moved this code into the routine i linked in my last irc message github.com/samcv/UCD/blob/master/U...#L537-L539 10:50
\o/ though. now i can get the whole UCD on perl 6
witnhout taknig hours 10:51
after doing loads of other improvements to the speed, making the other parts of the function over 10x faster as well by nqping it
O.o i'm using 21% of my memory atm :P
16GB
looks like in the code that turns all the unicode names at once into base 40 10:52
13:10 lizmat_ joined 13:34 ggoebel joined 13:56 ggoebel joined 13:59 agentzh joined 14:00 lucasb joined
lucasb o/ 14:01
brokenchicken \o 14:02
lucasb I noticed this struct named MVMNGFTrieNodeEntry in src/strings/nfg.{c,h}
brrt good hi, lucasb, brokenchicken, *
lucasb I guess the intention was to have named it with "NFG" instead of "NGF"
brrt heh, that looks well possible
lucasb so, just s/NGF/NFG/g :) 14:03
brrt PR pls :-P
14:03 KDr2 joined
brrt (not that I don't agree that this is a really easy change, it's just that I'm trying to distribute the workload as broad as possible, if only for the secondary effect that more people will have seen/be confident in editinng MoarVM source code) 14:04
lucasb ok, I can change it later today and submit a PR :)
brrt i eagerly await it :-) 14:05
jnthn Heh, nice catch 14:18
brrt speaking of PRs, have you had the chance to look at the JIT-data-section bit? 14:21
jnthn Not yet; been tied up in some $other-task all yesterday/today 14:45
Which I just got done with :)
Geth MoarVM: lucasbuchala++ created pull request #517:
Correct typo in struct name (s/NGF/NFG/)		 14:57
16:07 brrt joined 16:10 pyrimidine joined 16:26 agentzh joined
brrt lucasb++ looks good to me, will merge 16:30
Geth MoarVM: 625f70fdc4 | (Lucas Buchala)++ | 3 files
Correct typo in struct name
 16:31
MoarVM: 66961d88a8 | (Bart Wiegmans)++ | 3 files
Merge pull request #517 from lucasbuchala/nfg-typo

Correct typo in struct name (s/NGF/NFG/)
16:58 pyrimidine joined 17:13 FROGGS joined 17:39 domidumont joined 17:40 domidumont joined 18:03 domidumont joined 18:46 agentzh joined
brokenchicken nqp ops like div_i are in src/core/interp.c ? 19:05
jnthn Their interpretation is 19:06
Such an op will also be JIT-compiled
brokenchicken Does MVM_JIT_DISABLE=1 disable that? 19:07
Like there's a bug but I see nothing wrong in src/core/interp.c Where else should I look?
Oh, I see some stuff in src/jit/emit_x64.dasc 19:10
19:10 pyrimidine joined
timotimo yeah, jit disabling disables just that 19:10
brokenchicken oh, so if the bug is still present then it's not in emit_x64.dasc? hmmmm 19:11
timotimo also try disabling spesh, just to be sure 19:12
brokenchicken bug still there 19:13
jnthn Note if you're dealing in big ints, not hative ints, then it's div_I 19:18
uh, native
timotimo i assume it also happens with a high-level operator? 19:19
brokenchicken jnthn: well, isbig_I tells me is it big, but it's only like 50 bits. And JVM gives correct result.
jnthn Oh, if it's a boxed object you're working on it'll use div_I though 19:20
brokenchicken no, I can repro in just nqp
jnthn Ah
Example?
brokenchicken Not yet :) I wanna try to solve on my own :) 19:21
[Coke] chuckles at hative ints.
nwc10 "like 50 bits"? Like 53? 19:22
brokenchicken nwc10: 51.15 19:23
nwc10 oh :-(
brokenchicken nwc10: why? What happens with 53?
nwc10 size of mantissa on a 64 bit double
timotimo hm. 19:24
i think the is_big logic isn't right
it looks at the bigint's "used" stat, and sees if it's bigger than one
but libtommath can be configured to have one of many different kinds of storage formats 19:25
what buffoon wrote that code? oh, it was me! okay!
brokenchicken oh ok. `int` is 32 bits and that's where the problem comes from 19:37
how can I make it use 64-bits on 64-bit boxes? 19:38
And well, I guess I don't know what I'm doing :) .. It's rt.perl.org/Ticket/Display.html?id...et-history 19:39
And the problem boils down to:
m: use nqp; say(nqp::div_i(10000000000000000, 4))
camelia rakudo-moar f2894d: OUTPUT«468729856␤»
brokenchicken j: use nqp; say(nqp::div_i(10000000000000000, 4))
camelia rakudo-jvm fb4f16: OUTPUT«2500000000000000␤»
brokenchicken And on moarvm div_i stores those values in a `int` that's 32bit so it overflows and has wrong value
timotimo MVMint64 or MVMuint64 19:40
huh, why does it do that? that's very wrong :)
brokenchicken Oh cool! Then I can even fix this :D 19:41
brokenchicken tries
timotimo what buffoon wrote that code? oh. it was me... okay ...
brokenchicken :)
geekosaur heh
timotimo well, that was in there since 2014-01-11 19:42
and nobody complained
brokenchicken heh
timotimo so ... am i off the hook? maybe? :S
brokenchicken github.com/MoarVM/MoarVM/pull/518 19:52
moritz timotimo: your current self is off the hook, while we viciously blame your past self :-)
brokenchicken Fixes the bug and passes rakudo's stresstest
timotimo :)
brokenchicken: can you try what happens if you run that in a big loop and have it jitted? 19:53
i.e. does the jit use the proper register size? i.e. 64bit for each part of the result?
brokenchicken cpan@perlbuild2~/CPANPRC/rakudo (nom)$ ./perl6 -e 'use nqp; my $x; for ^1000000 { $x = nqp::div_i(10000000000000000, 4) }; say $x' 19:55
2500000000000000
Like that?
Geth MoarVM: zoffixznet++ created pull request #518:
Fix overflow in div_i op		 19:58
brokenchicken this also gives the right result at the end: use nqp; my $x; for ^100000000 { $x = nqp::div_i(10000000000000000, 4) }; say $x 19:59
21:10 agentzh joined 21:13 pyrimidine joined 21:23 zakharyas joined
samcv brokenchicken++ 21:32
jnthn Travis didn't even *start* any of the builds. 21:34
21:37 domidumont joined
brokenchicken samcv: ? 21:59
samcv hmm?
22:02 geekosaur joined
samcv brokenchicken, ? 22:08
brokenchicken 1632 samcv │ brokenchicken++ 22:09
samcv oh 22:10
the PR
<brokenchicken> this also gives the right result at the end: use nqp; my $x; for ^100000000 { $x = nqp::div_i(10000000000000000, 4) }; say $x
22:14 MasterDuke joined 22:21 pyrimidine joined 22:49 pyrimidine joined 23:21 pyrimidine joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!