00:03 cognome joined 00:36 colomon joined 01:05 colomon joined 01:08 FROGGS_ joined 01:48 ilbot3 joined 02:27 colomon_ joined 08:30 Juerd joined 08:32 kjs_ joined 08:43 Juerd joined 08:52 synopsebot joined 08:53 [Coke] joined, masak joined, PerlJam joined 08:55 Util joined 08:56 leont joined 08:57 tadzik joined, pmichaud joined 08:59 sergot joined 09:02 Ven joined 09:04 Juerd joined, dalek joined 09:14 kjs_ joined 10:34 kjs_ joined 11:03 Ven joined
nine .tell brrt about that email banning guy. Why don't you agree with his reasoning? 11:06
FROGGS_ nine: it feels like the beginning of a beautiful tdwtf :o) 11:41
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:44
FROGGS_ well, I think it is often better to have as few systems as possible 11:51
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:02
12:21 FROGGS[mobile] joined 12:22 zakharyas joined 12:35 ggoebel11111114 joined 13:29 Ven joined 13:31 brrt joined
brrt \o 13:31
lizmat brrt o/ 13:33
any chance of you making it to the APW ?
brrt hi lizmat :-)
.. no, i don't think so
lizmat :-(
brrt yes :-( 13:34
nine brrt: About that email banning guy. Why don't you agree with his reasoning?
brrt it's a real shame, i really had liked to see everybody again
nine: i'm so out of context now
nine brrt: 21:19 < brrt> this dude is going broke real soon: medium.com/life-at-primeloop/putti...757946d9fe
brrt oh 13:35
nine I was afk for a couple days :)
brrt because basically, e-mail is pretty much ok as a medium
and you don't fix broken communication patterns by having them go through a california data center
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:36
brrt but the problem is not that the tools are broken 13:38
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
with that, i'd agree
nine Though incidentally while thinking about this discussion I found ways to mitigate that mostly ;)
brrt but most communication boils down to 'i should ask $person $question'
how? :-)
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.
brrt need to know what to do by yourself? write a list
that's basically going a bit further than e-mail is
but yeah, you could do that
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
nine true
brrt fwiw, i happen to work (a bit) at a company that buys heavily into these kind of things 13:43
we used to have IRC chat, but now it has been replaced by slack 13:44
before that by hipchat
and slack will be replaced in due course
and all the while the same mistakes continue to be made
timotimo aaw, i won't be seeing brrt at apw? :( 14:03
jnthn timotimo: Will you be making apw? 14:04
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 :)
i've booked a hotel room and liz will be picking me up in karlsruhe with her car
jnthn cool 14:06
14:49 kjs_ joined
timotimo i wonder if speshing shift would really give such a big improvement ... 15:12
shift for iterators, that is
maybe we can introduce an op that only moves the iterator ahead and emit an atpos instruction that can then be spesh'd further
the shift op for iterators has to do some decisions for boxing etc 15:13
15:49 leont joined 16:13 kjs_ joined
TimToady timotimo: it would be nice if we could eventually get to a *p++ instruction for batches of known boxhood 16:43
well, with some test so we don't run off then end of the batch 16:44
maybe with a bit of loop unrolling to amortize the test some 16:45
getting away from heavy shift is part of the GLR rethink 16:46
timotimo mhm 16:48
i shall look into that some more
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
otherwise we can store the index in the iterator object and go directly into the array we're iterating over via an atpos_* operation
TimToady arguably it is the purpose of iterators to not cheat so they can be fast :) 16:50
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
in the absence of escape analysis
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
timotimo right. though i kind of think it'd be helpful to still be able to pass around iterators 16:53
if we have a completely inlined frame and no other ops use that iterator, well, that could be different
TimToady oh, that kind of escape
timotimo yes
TimToady hopefully in the general case our boxed pointers end up not much heavier than Go's slice thingies 16:54
for things that are not in batches 16:55
including most of our native arrays and such
timotimo well, if we turn the shift into a "sp_advancearriter" plus an "atpos_*" 16:58
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
though ... i think we have sp_ ops for atpos that don't check bounds
as the advancearriter does a bounds check anyway
that doesn't save us from the user throwing out values from the array in between and us running into possibly a segfault ...
TimToady certainly we have to track uniformity on some level, and to the extent we do, we can optimize based on that 17:02
17:03 cognome joined
TimToady arrays of natives arguably may not be sparse, at least by default 17:03
we don't have to carry the complete generality of boxed types down into unboxed types, almost by definition 17:04
if someone goes to the trouble of declaring my int @array[32], then that's exactly what they get 17:05
well, modulo uncertainty over the meaning of "int" :)
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:06
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
17:08 brrt joined
brrt timotimo: atpos_i isn't all that cheap iirc 17:09
oh hadn't seen all of the discussion
timotimo oh?
do we even use nqp::iter on our rakudo-level arrays?
brrt uhm 17:10
let me see
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
brrt nods 17:11
hmm 17:12
doesn't seem like we'e using iter for the for @a -> $x construct
anyway. atpos for mvmarray isn't quite cheap 17:13
TimToady well, when our iterators get fast, we can undo the loop opt
timotimo how so?
apparently we don't spesh atpos_* for MVMArray yet 17:14
ah, MVMArray can have a null in one of its slots and that can mean "there's a hole here 17:16
"
17:16 Ven joined
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?
brrt nods
timotimo we should be able to spesh that, no? 17:17
brrt if you know about it, yes
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:18
brrt (:-o new dynasm patch) 17:19
timotimo what's new there?
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?
brrt shld 17:21
shift and rotate
timotimo ah, we don't have a primitive for that in our instruction set, aye?
brrt not very relevant usually :-)
don't think we do
timotimo do you think i should go ahead with speshing MVMArray's atpos_*? 17:22
and afterwards implement the sp_advancearriter op i've mentioned above? 17:24
dalek arVM: 182085e | (Bart Wiegmans)++ | 3rdparty/dynasm:
Update DynASM
 17:25
brrt ... yes, i think that is a good idea 17:26
although the risk here is that we eagerly move everything into specialized structures that we might want to change 17:27
that said, i personally don't have such plans just yet
timotimo please be more verbose 17:30
"structures"?
you think the duplication of code between MVMIter's shift and sp_advancearriter would be bad? 17:33
brrt no, sp_advancearriter is ok as far as i'm concerned 17:34
hmmm 17:35
i see no problem with speshing atpos for MVMArray
timotimo great :)
brrt well.. there's one tiny tiny tiny thing
timotimo hehe.
brrt you can probably use sp_get_* to get the value from the poiner 17:36
from the object
timotimo maybe not
the array doesn't only keep a "number of elements" but also an "which index does the first element currently have" number
if we can be certain that the array will not be mutated, we can loop-hoist that 17:37
brrt hmmm 17:38
timotimo (another thing for escape analysis)
except we'd have to be certain our sub has been called with a clone of the arrary 17:39
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
brrt the start field is not looked at from atpos, though
timotimo: don't worry about that 17:40
basically, suppose somebody was concurrently modifying it without proper locks
then they'd be screwed anyway
timotimo er, hold on 17:41
brrt (the solution to concurrency / safety issues: dumb users are dumb :-p)
timotimo atpos does look at the start value
look for body->start in MVMArray.p
.c*
brrt oh, you are correct 17:43
hmm 17:44
hmm 17:45
timotimo AFK 17:52
brrt :-) 17:54
dalek arVM/spesh-array-access: 90f4251 | (Bart Wiegmans)++ | / (6 files):
Add sp_atpos_arr opcodes

These are direct access opcodes intended to help spesh array access		 18:02
18:10 kjs_ joined
brrt uhm, how do i get facts? 18:14
MVM_spesh_get_facts, duh 18:16
.. darn, that is all wrong 18:20
ok, thing is, i think we need a dumber array type
brrt afk for now 18:24
18:24 brrt left
timotimo oh 18:53
how so?
19:34 leont joined 20:29 colomon joined 21:33 Util joined 21:40 lizmat_ joined 22:19 vendethiel joined 22:22 [Coke] joined 22:23 masak joined, jlaire joined 22:24 cxreg joined 22:27 tadzik 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!