timotimo yeah 00:00
we do have a VMString we're dealing with, though
so not immediately trivial, but not difficult, either 00:01
01:49 ilbot3 joined 03:40 AlexDaniel joined
samcv timotimo, i mean how big are these logs? 04:32
MB
05:58 domidumont joined 06:00 brrt joined
brrt good * #moarvm 06:00
i've been doing moar thinking about the whole set question 06:01
i've considered using binary heaps - not such a good idea, have worst-case O(N) search, and O(log N) add/remove
oh, and O(N log N) merge, which isn't too hot 06:02
sorted arrays - which have the benefits of being cheap, usually, albeit at high algorithmic cost for pretty much every operation, except merge 06:03
06:04 domidumont joined
brrt hash tables - they do pretty well, but i don't like the memory cost of them, and merge is relatively expensive for most implementations 06:04
i'd use a hash table without doubt if this were perl
balancing binary tree also a good possibility, but they're pretty complex, and in terms of algorithmic complexity they don't buy you much in compared to the binary heap 06:11
anyway, because there is a point to this story;
bitmaps look pretty good all of a sudden
the numbers they hold, we never need to enumerate them, but we do need to merge them, and check for existence 06:12
we use consecutive numbers for the live ranges (i.e. or keys), so for most of our code the bitmap is (probably) going to be smallish
i can put that exactly, though 06:13
06:20 domidumont joined
brrt i use 1 bit per bitmap key; i use 32 bytes to represent one as a number (which is admittedly overkill) 06:32
meaning if i 'fill' my sets with 1 key out of 32, i 'win' 06:46
i could reduce the live range number size to 16 bits, probably with impunity, but then i still need to fill on 1/16 06:49
and obviously, bitmaps have O(1) read/update/delete operations, and O(N) union, which is pretty good altogether 06:53
07:13 brrt joined 07:17 brrt joined
stmuk ARM needs --no-telemeh to build 07:18
07:20 brrt1 joined 07:21 brrt joined
stmuk ah that's turned off by default anyway 07:22
samcv stmuk, what ARM platforms has MVM been tested on? 07:52
08:08 zakharyas joined
stmuk well I tried it on a PI3 08:30
in fact the process OOMed right at the end of the build which it didn't previousily so I probably have to add more swap 08:31
(with 2017.04.3 .. I'll try rakudobrew later)
but it looked like it would have completed :)
dogbert17 is building the latest rakudo (with rakudobrew) on an RPi2 atm 08:36
08:37 robertle joined
samcv fun :) 08:52
09:44 zakharyas joined
dogbert17 'This is Rakudo version 2017.04.3-172-gf2af3db built on MoarVM version 2017.04-56-g8ad18b8', now running on my RPi2 10:12
samcv \o/ 10:30
10:36 AlexDaniel joined 10:49 dogbert11 joined 11:01 geekosaur joined 11:07 geekosaur joined
timotimo stmuk: arm shouldn't need --no-telemeh, i'm checking for _WIN32 and _X86 or _X86_64 11:30
stmuk: or is that check wrong?
11:33 ggoebel joined
stmuk it needs it with 2017.04.3 otherwise there is an error 12:15
timotimo what is the error?
stmuk I saw the same as parrot raiser in rt.perl.org/Public/Bug/Display.html?id=131255 12:16
its in the attachement 12:17
timotimo why would --no-telemeh fix that error?
this is about dyncall 12:18
stmuk I don't know .. but it does
timotimo wtf wtf wtf wtf wtf wtf
brrt yeah, it's weird timotimo
timotimo we shouldn't be using the -Werror on our 3rdparty dependencies 12:19
brrt no, but that's a separate problem, innit
timotimo yeah, but that's what's causing the compile failure
brrt although, i guess that's what *would* happen if we make them in the same makefile
i'm thinking, 3rd party dependencies are a pretty good reason for a recursive makefile? 12:20
timotimo i'd advocate only activating -Werror=declaration-after-statement when you pass something like --developer
Zoffix
.oO( developers! developers! developers! developers! )
 12:21
jnthn I thought we did delegate to the dyncall makefile to build dyncall?
Yes 12:22
$(CMD)cd 3rdparty/dyncall && ./configure && CC='$(CC)' CFLAGS='$(CFLAGS)' $(MAKE) -f Makefile $(NOOUT)
Oh, but we pass on our CFLAGS 12:23
timotimo that's a bad miss :)
let me see about that
how about CFLAGS for moarvms sourcecode, and THIRDPARTY_CFLAGS for the rest? 12:24
jnthn Given dyncall runs its own configure anyway, why are we doing this at all? 12:25
*that* should pick the appropraite flags, no?
timotimo oh 12:26
probably, yeah
i haven't actually done anything there besides finding out where the stuff comes from, but ... we do keep the CC, right? 12:54
jnthn Yeah, that's probably sensible
It is worth looking at the history though 12:55
12:56 jpg51 joined
timotimo it was pulled in in 2014 by gerdr 12:57
"import new build system"
do you know where that came from?
jnthn No, 'fraid not 12:58
Means we've had it that way for a long, long, time though
timotimo aye
and i'm absolutely puzzled why --no-telemeh would change anything about this
timotimo diffs makefiles to be sure 13:01
13:01 eviltwin_b joined
timotimo okay, the HAVE_TELEMEH symbol really should start with MVM for purity reasons, but that shouldn't change a thing? 13:03
13:10 ggoebel joined 13:14 stmuk joined, hoelzro joined 13:26 hoelzro joined, stmuk joined
Geth MoarVM: samcv++ created pull request #591:
Add can_fit_into_8bit funct, put logic used many places into one funct		 14:18
14:34 brrt joined
MasterDuke_ when can you use MVM_fixed_size_alloc vs MVM_malloc? 16:02
if the thing you're allocing will never need to be resized? 16:03
jnthn When, at the time of free, you have the size available
That also
Also it's only really useful when the things you're allocating are fairly small 16:04
Over a certain size it just calls malloc
MasterDuke_ so you can't use it while deserializing a VMArray because of the possibility that what you've deserialized might get resized? since you would know its size at free, right? 16:06
jnthn Well, in theory you could 16:07
But you couldn't use realloc
Actually I've got a planned VMArray refactor that *would* switch to using the FSA, primarily because if we use the free-at-safepoint mechanism then we can avoid various threading issues. 16:08
(Currently you can cause a nasty crash by mis-using VMArray from multiple threads)
MasterDuke_ ah ha, if you're going to work on it i won't bother 16:09
i was just looking at a heaptrack profile of `-e ''` and the top spot for most allocations (double the next, which itself is quadruple the next) is VMArray.c:1119, which is `body->slots.any = MVM_malloc(body->ssize * repr_data->elem_size);` in deserialize 16:12
jnthn Yeah which in turn is from deserializing huge arrays that form NFAs 16:14
timotimo yup. annoyingly we deserialize both the NFA object (containing all the data) and the arrays that describe the NFA (containing the same data in a slightly different format) 16:15
jnthn Yeah 16:16
Well, we sometimes need the other forms, like if you derive the grammar
But we can get them from the NFA packed form
In that (uncommon) case
And let the common case enjoy less memory use and faster startup
timotimo yup, i wrote an op that does that
but i wasn't able to properly change the code so it removes the arrays at one point and re-instates them from the NFA itself at another 16:17
16:33 robertle joined 16:51 domidumont joined 17:53 brrt joined 18:31 AlexDaniel joined 18:36 avar joined 19:10 zakharyas joined 20:23 AlexDani` joined
samcv i'm gonna try building MoarVM on my android phone 22:25
yoleaux 18:48Z <Zoffix> samcv: is bustitude with some ops on docs site known? Like docs.perl6.org/routine/..%5E is a 404 (that's ..^ op)

Powered by Cro and the Raku® Programming Language.

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

Thank you!