github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 24 May 2018.
01:39 Kaiepi joined 01:40 MasterDuke joined 01:56 ilbot3 joined
moderator github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
04:20 AlexDaniel`` joined 05:54 domidumont joined 05:59 domidumont joined 06:49 robertle joined 09:25 brrt joined
brrt good * 09:31
11:15 brrt joined 11:18 domidumont joined 11:20 squashable6 joined
samcv good * 13:39
yoleaux 24 May 2018 22:39Z <tbrowder_> samcv: should unicode chars 0x2000 and 0x2001 rountrip. they don’t appear to (both are space chars) and AlexDaniel thinks that may be normalization.
Geth MoarVM/jit-stack-walker: 91cac7f934 | (Bart Wiegmans)++ | tools/jit-bisect.pl
[Tools] I was wrong about MVM_SPESH_LIMIT in jit-bisect.pl

Even with 1-based offsets, we still return the last-good-frame, not the first-bad one.		 14:12
MoarVM/jit-stack-walker: 16 commits pushed by (Bart Wiegmans)++
review: github.com/MoarVM/MoarVM/compare/9...b8120d4b44		 14:13
14:38 AlexDaniel` left
tbrowder_ late to the dance, but has there been any thought to converting the whole c code base to c++? after a conversion, which should be fairly painless, lots of advantages for many improving ease of maintenance. 14:44
s/many // 15:08
jnthn No, I've interest in seeing that happen. We don't really have maint problems; for a system of this kind, things are fairly well decoupled already. That's a function of design, not of language choice. Even if we did have such problems, I don't know C++ well enough to make decent design calls, so it'd put the current design quality at risk. 15:25
timotimo templates all of the datastructures 15:26
jnthn Uh, s/interest/no interest/ 15:36
:)
Wow, that totally changes the answer :P
tbrowder_ i understand, jnthn, thnx! 15:46
samcv i don't know C++ either :) 15:47
i kind of wish I did though
i see templates and weird things happening in code and freak out currently
jnthn: oh while you're here 15:48
MVM_NO_RETURN is not set to anything on gcc or clang, only on msvc 15:50
i would like to set it to noreturnspecifier => '__attribute__((noreturn))'
which should get rid of some compiler warnings 15:51
unless you know any reason otherwise
jnthn Sounds fine to me 15:55
Probably just an oversight
Or was put in body somebody primarily using MSVC and figuring gcc would come later :)
samcv also we have MVM_NO_RETURN_GCC which does work 15:56
dunno if that should just be changed to MVM_NO_RETURN or if there was some specific reason we didn't want to use it for MSVC or something
jnthn I don't see why they can't be just one name defiend to the two things 16:01
Whichever is applicable for the compiler
samcv k
16:25 Kaiepi joined 16:28 Kaiepi joined 16:29 Kaiepi joined
samcv jnthn: ok i see one is an attribute and one is a specifier and i renamed MVM_NO_RETURN_GCC to MVM_NO_RETURN_ATTRIBUTE 16:35
and i think the solution is just to make sure we use both
Geth MoarVM: 5a9bdf8b12 | (Samantha McVey)++ | src/debug/debugserver.c
Fix two compiler warnings in debugserver.c

Fix type mismatch and a warning about dangling else.		 16:57
MoarVM: a68b1493e8 | (Samantha McVey)++ | 13 files
Rename MVM_NO_RETURN_GCC to MVM_NO_RETURN_ATTRIBUTE

Rename it to be more accurate since we also do this on clang. Add MVM_NO_RETURN_ATTRIBUTE a few places it was missing so clang does not give us warnings that a function does not return.
samcv ok i've fixed the issue now :)
Geth MoarVM: 51b72c2267 | (Samantha McVey)++ | src/debug/debugserver.c
Fix another compiler warning of type mismatch in debugserver

All the things we end up using `result` for are unsigned so just use the MVMuint64 type here.		 16:59
17:20 domidumont joined 18:16 Zoffix joined, Zoffix left 18:17 Zoffix joined
mst note: this channel was accessible only to diakopter so I've stolen ownership of it and given Zoffix and jnthn basic chanserv permissions 18:18
notable6 mst, Noted!
Zoffix heh
botsnack
moderator github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today and colabti.org/irclogger/irclogger_logs/moarvm 18:20
Zoffix left 18:30 Kaiepi joined
samcv i'm converting many of the uthash macros into MVM_STATIC_INLINE 18:52
18:53 feb joined
samcv which should let us see in a profiler actually what is using cpu 18:53
plus prevents macro hell where changing one thing causes hard to figure out errors due to things going through 5 macros
18:55 ilogger2 joined
jnthn samcv: Sounds good :-) 19:28
samcv: I did some amount of refactoring and got rid of stuff we weren't using over time, but there's certainly mroe worth doing
19:32 feb left 19:59 MasterDuke joined
samcv jnthn: i think i may have made MVM_string_gi_get_grapheme 8x faster. it was 8% of this hash test i made. but now it's only 1% 20:05
20:06 travis-ci joined
travis-ci MoarVM build failed. Samantha McVey 'Convert HASH_DEL_IN_BKT and HASH_EXPAND_BUCKETS from macros to inlines' 20:06
travis-ci.org/samcv/MoarVM/builds/383863824 github.com/samcv/MoarVM/compare/ad...4d2c3f8563
20:06 travis-ci left
timotimo i just looked at how the holes in SCRefs are spread out and it doesn't really lend itself to a sparse array scheme, as the holes tend to be mostly small 20:32
135974 total holes out of 177935
145 holes bigger than 128
m: say 135974 / 177935
camelia 0.7641779
timotimo some of those holes are actually rather big, but for example a two-level approach wouldn't make that much sense here 20:34
there's a very big stretch of 1 entry, one hole, 2 entries, 1 hole, repeat
i wonder what that might be 20:35
jnthn samcv: Wow, nice :)
Geth MoarVM/master: 4 commits pushed by (Samantha McVey)++ 20:37
20:51 Kaiepi joined
samcv at least i think i did make it faster... 21:50
well need to do some stuff to try and confirm
actually being annoying to test for it because i've put in fast paths many places like collapse_strands and indexing branches 21:58
timotimo oof :) 22:13
samcv i have made some unicode stuff faster tho 22:19
timotimo can never have enough of that 22:20
jnthn expects to have a decent bit of "making MoarVM faster" time over the summer :)
Geth MoarVM: a84b607bd0 | (Samantha McVey)++ | 2 files
Add branch predictor hints macros

MVM_LIKELY and MVM_UNLIKELY are meant to be used in if conditionals MVM_EXPECT is can be used on things like switches that don't just expect true or false type values.		 22:21
jnthn ooh
samcv :)
got like 10% boost on find_cclass
which much of it is querying the unicode properties 22:22
jnthn Wow, that's pretty good going
Bet there's quite a few places we can use that
timotimo i wonder if having find_cclass contain "the" loop 22:23
jnthn Is expection expectation or exception? :)
timotimo rather than calling is_cclass over and over? is that what we are doing?
samcv it can make a pretty big difference 22:24
timotimo: also yes that would be better 22:25
i was thinking about doing that later
timotimo is that a big difference though?
samcv oh i mean the branch predictor hints
can make a big difference
timotimo in some cases we might be able to say "oh this only contains ascii, we can make far fewer checks"
samcv though you should make sure you only use them with benchmarking. because otherwise it can have unexpected results
timotimo oh, i somehow didn't even see that commit up there
samcv heh 22:26
timotimo i bet we can put UNLIKELY in a whole bunch of places with error handling
like reprid checks and such
samcv yeah
i was playing around in MVM_string_gi_get_grapheme. and like if i put MVM_UNLIKELY in gi->repetitions, it makes repetitions a fair amount slower, but has minimal impact on other code (though that may occur more often) i could try things with many short strands. but yeah 22:27
decided not to add it there because i didn't see any improvement or barely any. but it is neat 22:28
Geth MoarVM: f94b029721 | (Samantha McVey)++ | 4 files
Use new branch predictor hints to unicode_db and prop query

Gives about 10% speedup generally. We query general category the most so this can have a fair impact.
Some hot codepaths were also streamlined a bit as well.
samcv was able to use the branch predictor to make it faster to get things in plane 0 of the unicode database
and expect General_Category more likely than the other conditions 22:29
i'm curious about what will happen if i take MVM_string_check_arg and make it unlikely that it'll throw 22:31
if we see any significant changes since it's used a lot? dunno
tbrowder_ another thought about c++: after "converting" to using the c++ compiler you can continue to use C pretty much as usual, but it would allow gradually moving to C++isms, and maybe help others start helping out...just saying. take a look at brlcad.org (over 30 years C but gradually moving to C++) 23:35
japhb tbrowder_: Recently someone posted a video by a Google engineer talking about building a fast hash table in C++, and the last few minutes consisted roughly of "How many geniuses does it take to get a C++ compiler to produce good code?" culminating in admitting that one of these people did nothing but run the compiler to produce assembly code, think really hard about why it was producing the wrong code, and 23:52
tweak the source until it compiled the way they expected. This is *not* the kind of thing you want when writing a language VM. There's a reason C has not disappeared from the world of large complex performance-dependent projects like OS kernels and VMs.
Not saying by any means that it's impossible to write performant code in C++, many people do, just that it's not a clear win to convert a relatively understood C codebase into a C++ one. 23:53
jnthn Furthermore, if we're going to port (parts of) MoarVM to anything, it should probably be to NQP, and head in a self-host direction, like e.g. the Graal folks have. 23:56
(That's a decidedly long-term aim)

Powered by Cro and the Raku® Programming Language.

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

Thank you!