Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-05-05

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

All times shown according to UTC.

Time Nick Message
00:00 timotimo yeah
00:00 timotimo we do have a VMString we're dealing with, though
00:01 timotimo so not immediately trivial, but not difficult, either
01:49 ilbot3 joined #moarvm
01:49 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:40 AlexDaniel joined #moarvm
04:32 samcv timotimo, i mean how big are these logs?
04:32 samcv MB
05:58 domidumont joined #moarvm
06:00 brrt joined #moarvm
06:00 brrt good * #moarvm
06:01 brrt i've been doing moar thinking about the whole set question
06:01 brrt i've considered using binary heaps - not such a good idea, have worst-case O(N) search, and O(log N) add/remove
06:02 brrt oh, and O(N log N) merge, which isn't too hot
06:03 brrt sorted arrays - which have the benefits of being cheap, usually, albeit at high algorithmic cost for pretty much every operation, except merge
06:04 domidumont joined #moarvm
06:04 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 brrt i'd use a hash table without doubt if this were perl
06:11 brrt 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 brrt anyway, because there is a point to this story;
06:11 brrt bitmaps look pretty good all of a sudden
06:12 brrt the numbers they hold, we never need to enumerate them, but we do need to merge them, and check for existence
06:12 brrt 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
06:13 brrt i can put that exactly, though
06:20 domidumont joined #moarvm
06:32 brrt i use 1 bit per bitmap key; i use 32 bytes to represent one as a number (which is admittedly overkill)
06:46 brrt meaning if i 'fill' my sets with 1 key out of 32, i 'win'
06:49 brrt 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:53 brrt and obviously, bitmaps have O(1) read/update/delete operations, and O(N) union, which is pretty good altogether
07:13 brrt joined #moarvm
07:17 brrt joined #moarvm
07:18 stmuk ARM needs --no-telemeh to build
07:20 brrt1 joined #moarvm
07:21 brrt joined #moarvm
07:22 stmuk ah that's turned off by default anyway
07:52 samcv stmuk, what ARM platforms has MVM been tested on?
08:08 zakharyas joined #moarvm
08:30 stmuk well I tried it on a PI3
08:31 stmuk 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 stmuk (with 2017.04.3 .. I'll try rakudobrew later)
08:31 stmuk but it looked like it would have completed :)
08:36 * dogbert17 is building the latest rakudo (with rakudobrew) on an RPi2 atm
08:37 robertle joined #moarvm
08:52 samcv fun :)
09:44 zakharyas joined #moarvm
10:12 dogbert17 'This is Rakudo version 2017.04.3-172-gf2af3db built on MoarVM version 2017.04-56-g8ad18b8', now running on my RPi2
10:30 samcv \o/
10:36 AlexDaniel joined #moarvm
10:49 dogbert11 joined #moarvm
11:01 geekosaur joined #moarvm
11:07 geekosaur joined #moarvm
11:30 timotimo stmuk: arm shouldn't need --no-telemeh, i'm checking for _WIN32 and _X86 or _X86_64
11:30 timotimo stmuk: or is that check wrong?
11:33 ggoebel joined #moarvm
12:15 stmuk it needs it with 2017.04.3 otherwise there is an error
12:15 timotimo what is the error?
12:16 stmuk I saw the same as parrot raiser in https://rt.perl.org/Public/Bug/Display.html?id=131255
12:17 stmuk its in the attachement
12:17 timotimo why would --no-telemeh fix that error?
12:18 timotimo this is about dyncall
12:18 stmuk I don't know .. but it does
12:18 timotimo wtf wtf wtf wtf wtf wtf
12:18 brrt yeah, it's weird timotimo
12:19 timotimo we shouldn't be using the -Werror on our 3rdparty dependencies
12:19 brrt no, but that's a separate problem, innit
12:19 timotimo yeah, but that's what's causing the compile failure
12:19 brrt although, i guess that's what *would* happen if we make them in the same makefile
12:20 brrt 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
12:21 Zoffix .oO( developers! developers! developers! developers! )
12:21 jnthn I thought we did delegate to the dyncall makefile to build dyncall?
12:22 jnthn Yes
12:22 jnthn $(CMD)cd 3rdparty/dyncall &&  ./configure && CC='$(CC)' CFLAGS='$(CFLAGS)' $(MAKE) -f Makefile  $(NOOUT)
12:23 jnthn Oh, but we pass on our CFLAGS
12:23 timotimo that's a bad miss :)
12:23 timotimo let me see about that
12:24 timotimo how about CFLAGS for moarvms sourcecode, and THIRDPARTY_CFLAGS for the rest?
12:25 jnthn Given dyncall runs its own configure anyway, why are we doing this at all?
12:25 jnthn *that* should pick the appropraite flags, no?
12:26 timotimo oh
12:26 timotimo probably, yeah
12:54 timotimo 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
12:55 jnthn It is worth looking at the history though
12:56 jpg51 joined #moarvm
12:57 timotimo it was pulled in in 2014 by gerdr
12:57 timotimo "import new build system"
12:57 timotimo do you know where that came from?
12:58 jnthn No, 'fraid not
12:58 jnthn Means we've had it that way for a long, long, time though
12:58 timotimo aye
12:58 timotimo and i'm absolutely puzzled why --no-telemeh would change anything about this
13:01 * timotimo diffs makefiles to be sure
13:01 eviltwin_b joined #moarvm
13:03 timotimo okay, the HAVE_TELEMEH symbol really should start with MVM for purity reasons, but that shouldn't change a thing?
13:10 ggoebel joined #moarvm
13:14 stmuk joined #moarvm
13:14 hoelzro joined #moarvm
13:26 hoelzro joined #moarvm
13:26 stmuk joined #moarvm
14:18 Geth ¦ MoarVM: samcv++ created pull request #591: Add can_fit_into_8bit funct, put logic used many places into one funct
14:18 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/591
14:34 brrt joined #moarvm
16:02 MasterDuke_ when can you use MVM_fixed_size_alloc vs MVM_malloc?
16:03 MasterDuke_ 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
16:03 jnthn That also
16:04 jnthn Also it's only really useful when the things you're allocating are fairly small
16:04 jnthn Over a certain size it just calls malloc
16:06 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:07 jnthn Well, in theory you could
16:07 jnthn But you couldn't use realloc
16:08 jnthn 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 jnthn (Currently you can cause a nasty crash by mis-using VMArray from multiple threads)
16:09 MasterDuke_ ah ha, if you're going to work on it i won't bother
16:12 MasterDuke_ 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:14 jnthn Yeah which in turn is from deserializing huge arrays that form NFAs
16:15 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:16 jnthn Yeah
16:16 jnthn Well, we sometimes need the other forms, like if you derive the grammar
16:16 jnthn But we can get them from the NFA packed form
16:16 jnthn In that (uncommon) case
16:16 jnthn And let the common case enjoy less memory use and faster startup
16:16 timotimo yup, i wrote an op that does that
16:17 timotimo 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:33 robertle joined #moarvm
16:51 domidumont joined #moarvm
17:53 brrt joined #moarvm
18:31 AlexDaniel joined #moarvm
18:36 avar joined #moarvm
18:36 avar joined #moarvm
19:10 zakharyas joined #moarvm
20:23 AlexDani` joined #moarvm
22:25 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 https://docs.perl6.org/routine/..%5E is a 404 (that's ..^ op)

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