Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-09-21

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

All times shown according to UTC.

Time Nick Message
00:03 cognome joined #moarvm
00:36 colomon joined #moarvm
01:05 colomon joined #moarvm
01:08 FROGGS_ joined #moarvm
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:27 colomon_ joined #moarvm
08:30 Juerd joined #moarvm
08:32 kjs_ joined #moarvm
08:43 Juerd joined #moarvm
08:52 synopsebot joined #moarvm
08:53 [Coke] joined #moarvm
08:53 masak joined #moarvm
08:53 PerlJam joined #moarvm
08:55 Util joined #moarvm
08:56 leont joined #moarvm
08:57 tadzik joined #moarvm
08:57 pmichaud joined #moarvm
08:59 sergot joined #moarvm
09:02 Ven joined #moarvm
09:04 Juerd joined #moarvm
09:04 dalek joined #moarvm
09:14 kjs_ joined #moarvm
10:34 kjs_ joined #moarvm
11:03 Ven joined #moarvm
11:06 nine .tell brrt about that email banning guy. Why don't you agree with his reasoning?
11:41 FROGGS_ nine: it feels like the beginning of a beautiful tdwtf :o)
11:44 nine FROGGS_: the email thing? I don't know. I'd say the gist is "For some use cases specialized tools are better suited than email." And I tend to agree. Though I would probably not use the hippest cloud services for everything...
11:51 FROGGS_ well, I think it is often better to have as few systems as possible
12:02 nine Sounds like a good rule of thumb. Like the advise to only have one TODO list for work, private and everything. But email is very bad at managing TODOs so this may be a good area to use something more specialized.
12:21 FROGGS[mobile] joined #moarvm
12:22 zakharyas joined #moarvm
12:35 ggoebel11111114 joined #moarvm
13:29 Ven joined #moarvm
13:31 brrt joined #moarvm
13:31 brrt \o
13:33 lizmat brrt o/
13:33 lizmat any chance of you making it to the APW ?
13:33 brrt hi lizmat :-)
13:33 brrt .. no, i don't think so
13:33 lizmat :-(
13:34 brrt yes :-(
13:34 nine brrt: About that email banning guy. Why don't you agree with his reasoning?
13:34 brrt it's a real shame, i really had liked to see everybody again
13:34 brrt nine: i'm so out of context now
13:34 nine brrt: 21:19 < brrt> this dude is going broke real soon: https://medium.com/life-at-primeloop/putting-email-in-its-place-27757946d9fe
13:35 brrt oh
13:35 nine I was afk for a couple days :)
13:35 brrt because basically, e-mail is pretty much ok as a medium
13:35 brrt and you don't fix broken communication patterns by having them go through a california data center
13:36 nine brrt: as I told FROGGS earlier today, I tend to agree with the gist being "For some use cases specialized tools are better suited than email." Though I would probably not use the hippest cloud services for everything...
13:38 brrt but the problem is not that the tools are broken
13:39 nine For some things at least, email is really not a good tool, like managing TODOs.
13:39 brrt i've never encountered a problem where people were communicating badly and tools fixed it
13:39 brrt with that, i'd agree
13:39 nine Though incidentally while thinking about this discussion I found ways to mitigate that mostly ;)
13:39 brrt but most communication boils down to 'i should ask $person $question'
13:39 brrt how? :-)
13:41 brrt todo list managment is another of these hip things that attract much more tooling than could possibly help
13:41 nine Well, what email does not allow is good priorization of tasks and sharing those tasks. But that can be done with one shared IMAP folder for each priority level (we use 5 levels for example in our RT). Done TODOs can be moved to another folder.
13:41 brrt need to know what to do by yourself? write a list
13:41 brrt that's basically going a bit further than e-mail is
13:41 brrt but yeah, you could do that
13:42 nine But I'd probably still prefer using korganizer's TODO list. Synchronized via IMAP cause it stores the TODOs in ical files in an IMAP folder ;)
13:42 brrt it's the same thing with all the people writing specialised data processing tools... while ordinary folks use excel
13:42 nine true
13:43 brrt fwiw, i happen to work (a bit) at a company that buys heavily into these kind of things
13:44 brrt we used to have IRC chat, but now it has been replaced by slack
13:44 brrt before that by hipchat
13:44 brrt and slack will be replaced in due course
13:44 brrt and all the while the same mistakes continue to be made
14:03 timotimo aaw, i won't be seeing brrt at apw? :(
14:04 jnthn timotimo: Will you be making apw?
14:05 * jnthn needs to figure out how he wants to arrive/leave and where to stay, but will be there
14:05 timotimo i think so :)
14:05 timotimo i've booked a hotel room and liz will be picking me up in karlsruhe with her car
14:06 jnthn cool
14:49 kjs_ joined #moarvm
15:12 timotimo i wonder if speshing shift would really give such a big improvement ...
15:12 timotimo shift for iterators, that is
15:12 timotimo maybe we can introduce an op that only moves the iterator ahead and emit an atpos instruction that can then be spesh'd further
15:13 timotimo the shift op for iterators has to do some decisions for boxing etc
15:49 leont joined #moarvm
16:13 kjs_ joined #moarvm
16:43 TimToady timotimo: it would be nice if we could eventually get to a *p++ instruction for batches of known boxhood
16:44 TimToady well, with some test so we don't run off then end of the batch
16:45 TimToady maybe with a bit of loop unrolling to amortize the test some
16:46 TimToady getting away from heavy shift is part of the GLR rethink
16:48 timotimo mhm
16:48 timotimo i shall look into that some more
16:49 timotimo ah. inside spesh, we may keep the object we're iterating over in a regular object register and store the index of the iterator in a native int slot. that'll require escape analysis on the iterator, though
16:49 timotimo otherwise we can store the index in the iterator object and go directly into the array we're iterating over via an atpos_* operation
16:50 TimToady arguably it is the purpose of iterators to not cheat so they can be fast :)
16:51 timotimo mhh
16:51 TimToady anyway, we could probably mark some subset of the iterators as well-behaved, or ill-behaved, if we choose the other default
16:51 TimToady in the absence of escape analysis
16:52 timotimo not exactly sure what you mean by that
16:52 TimToady we can sometimes declare things that we don't want the compiler to have to figure out on its own, is all
16:53 timotimo right. though i kind of think it'd be helpful to still be able to pass around iterators
16:53 timotimo if we have a completely inlined frame and no other ops use that iterator, well, that could be different
16:53 TimToady oh, that kind of escape
16:53 timotimo yes
16:54 TimToady hopefully in the general case our boxed pointers end up not much heavier than Go's slice thingies
16:55 TimToady for things that are not in batches
16:55 TimToady including most of our native arrays and such
16:58 timotimo well, if we turn the shift into a "sp_advancearriter" plus an "atpos_*"
16:59 timotimo that'll directly go to the array index of the iterator (can be jitted well, too) and then directly go at the right position in the array's storage (plus a little bounds check)
16:59 timotimo though ... i think we have sp_ ops for atpos that don't check bounds
16:59 timotimo as the advancearriter does a bounds check anyway
16:59 timotimo that doesn't save us from the user throwing out values from the array in between and us running into possibly a segfault ...
17:02 TimToady certainly we have to track uniformity on some level, and to the extent we do, we can optimize based on that
17:03 cognome joined #moarvm
17:03 TimToady arrays of natives arguably may not be sparse, at least by default
17:04 TimToady we don't have to carry the complete generality of boxed types down into unboxed types, almost by definition
17:05 TimToady if someone goes to the trouble of declaring my int @array[32], then that's exactly what they get
17:05 TimToady well, modulo uncertainty over the meaning of "int" :)
17:06 timotimo right, we have atpos_o that deals with sparse arrays; i don't think our list_i, list_s and list_n can be sparse actually?
17:08 * TimToady hopes, on the one hand, that they are not sparse, but on the other hand, that they are, so we can rip that out and make them faster... :)
17:08 brrt joined #moarvm
17:09 brrt timotimo: atpos_i isn't all that cheap iirc
17:09 brrt oh hadn't seen all of the discussion
17:09 timotimo oh?
17:09 timotimo do we even use nqp::iter on our rakudo-level arrays?
17:10 brrt uhm
17:10 brrt let me see
17:10 TimToady well, as I said, we'd really like to get to the point where we don't have to do multiplcation on every access, but pointer++ most of the time for very low-level stuff
17:11 * brrt nods
17:12 brrt hmm
17:12 brrt doesn't seem like we'e using iter for the for @a -> $x construct
17:13 brrt anyway. atpos for mvmarray isn't quite cheap
17:13 TimToady well, when our iterators get fast, we can undo the loop opt
17:13 timotimo how so?
17:14 timotimo apparently we don't spesh atpos_* for MVMArray yet
17:16 timotimo ah, MVMArray can have a null in one of its slots and that can mean "there's a hole here
17:16 timotimo "
17:16 Ven joined #moarvm
17:16 brrt hey, you can't have safety and convenience and speed at the same time
17:16 timotimo brrt: atpos is probably "not so cheap" because it has to dispatch per array type?
17:16 * brrt nods
17:17 timotimo we should be able to spesh that, no?
17:17 brrt if you know about it, yes
17:18 timotimo if we have list_i, list_o, list_s, or list_n as the creator or if we have a known type, we do know about it
17:19 brrt (:-o new dynasm patch)
17:19 timotimo what's new there?
17:20 brrt added support for an instruction that we didn't use so far (but could use one day)
17:20 timotimo which one is that?
17:21 brrt shld
17:21 brrt shift and rotate
17:21 timotimo ah, we don't have a primitive for that in our instruction set, aye?
17:21 brrt not very relevant usually :-)
17:21 brrt don't think we do
17:22 timotimo do you think i should go ahead with speshing MVMArray's atpos_*?
17:24 timotimo and afterwards implement the sp_advancearriter op i've mentioned above?
17:25 dalek MoarVM: 182085e | (Bart Wiegmans)++ | 3rdparty/dynasm:
17:25 dalek MoarVM: Update DynASM
17:25 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/182085e112
17:26 brrt ... yes, i think that is a good idea
17:27 brrt although the risk here is that we eagerly move everything into specialized structures that we might want to change
17:27 brrt that said, i personally don't have such plans just yet
17:30 timotimo please be more verbose
17:30 timotimo "structures"?
17:33 timotimo you think the duplication of code between MVMIter's shift and sp_advancearriter would be bad?
17:34 brrt no, sp_advancearriter is ok as far as i'm concerned
17:35 brrt hmmm
17:35 brrt i see no problem with speshing atpos for MVMArray
17:35 timotimo great :)
17:35 brrt well.. there's one tiny tiny tiny thing
17:35 timotimo hehe.
17:36 brrt you can probably use sp_get_* to get the value from the poiner
17:36 brrt from the object
17:36 timotimo maybe not
17:36 timotimo the array doesn't only keep a "number of elements" but also an "which index does the first element currently have" number
17:37 timotimo if we can be certain that the array will not be mutated, we can loop-hoist that
17:38 brrt hmmm
17:38 timotimo (another thing for escape analysis)
17:39 timotimo except we'd have to be certain our sub has been called with a clone of the arrary
17:39 timotimo such that no other code still has a reference to that object and could modify it, say in a different thread or callback or something
17:39 brrt the start field is not looked at from atpos, though
17:40 brrt timotimo: don't worry about that
17:40 brrt basically, suppose somebody was concurrently modifying it without proper locks
17:40 brrt then they'd be screwed anyway
17:41 timotimo er, hold on
17:41 brrt (the solution to concurrency / safety issues: dumb users are dumb :-p)
17:41 timotimo atpos does look at the start value
17:41 timotimo look for body->start in MVMArray.p
17:41 timotimo .c*
17:43 brrt oh, you are correct
17:44 brrt hmm
17:45 brrt hmm
17:52 timotimo AFK
17:54 brrt :-)
18:02 dalek MoarVM/spesh-array-access: 90f4251 | (Bart Wiegmans)++ | / (6 files):
18:03 dalek MoarVM/spesh-array-access: Add sp_atpos_arr opcodes
18:03 dalek MoarVM/spesh-array-access:
18:03 dalek MoarVM/spesh-array-access: These are direct access opcodes intended to help spesh array access
18:03 dalek MoarVM/spesh-array-access: review: https://github.com/MoarVM/MoarVM/commit/90f425164c
18:10 kjs_ joined #moarvm
18:14 brrt uhm, how do i get facts?
18:16 brrt MVM_spesh_get_facts, duh
18:20 brrt .. darn, that is all wrong
18:20 brrt ok, thing is, i think we need a dumber array type
18:24 * brrt afk for now
18:24 brrt left #moarvm
18:53 timotimo oh
18:53 timotimo how so?
19:34 leont joined #moarvm
20:29 colomon joined #moarvm
21:33 Util joined #moarvm
21:40 lizmat_ joined #moarvm
22:19 vendethiel joined #moarvm
22:22 [Coke] joined #moarvm
22:23 masak joined #moarvm
22:23 jlaire joined #moarvm
22:24 cxreg joined #moarvm
22:27 tadzik joined #moarvm

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