Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-07-29

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

All times shown according to UTC.

Time Nick Message
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
04:35 vendethiel joined #moarvm
06:12 rurban_ joined #moarvm
06:53 Ven joined #moarvm
06:54 jnthn I wasn't aware there was more than one (common) definition of reentrancy for mutexen either :)
06:56 jnthn But anyway, here goes: if a thread already holding a lock acquires it a second time, it's effectively a no-op, as is that nested lock release
06:56 jnthn Note that this means it's a dynamically scoped property
07:06 Ven joined #moarvm
07:10 FROGGS joined #moarvm
07:14 harrow joined #moarvm
07:22 zakharyas joined #moarvm
07:40 JimmyZ joined #moarvm
07:55 vendethiel joined #moarvm
07:55 brrt joined #moarvm
07:55 brrt \o
07:55 FROGGS o/
07:56 brrt hmm
07:56 brrt it just occured to me that i can use graphiz to represent the code trees for my blog
07:57 brrt that might make some things much more clear
08:01 brrt *graphviz
08:08 FROGGS aye
08:19 jnthn I had to teach so didn't get to finish on the lock thing. :) I suspect that I'll have Lock.protect(...) install a $*AWAITER that dies.
08:20 jnthn To try and catch most cases where people await while holding a lock
08:20 jnthn Because it's basically always wrong.
08:21 jnthn (for one 'cus your code can migrate between OS threads at the point of an "await")
08:21 jnthn (and locks are tied to OS threads, so you'd end up trying to release it on the wrong thread)
08:22 lizmat jnthn: on that note, would you like me to merge your new S17 proposal into the spec, or do you want to do that yourself?
08:24 jnthn lizmat: I don't think it has to be me that does it, though we may want to defer it until I've had chance to work on implementation.
08:24 lizmat ok, deferring is fine with me  :-)
08:25 jnthn Then I can tweak the gist with any findings while I implement :)
08:25 timotimo a better idea to complain on await than on start
08:25 timotimo i like that
08:25 jnthn Complaining on start doesn't make a lot of sesne to me
08:25 jnthn It's not really a problem to schedule some work while holding a lock.
08:26 jnthn It's blocking while you do it
08:26 timotimo yeah
08:26 brrt wait, what, your await can transfer your code to another thread?
08:26 timotimo i just now see that the suggestion last night was to set the $*SCHEDULER to CurrentThreadScheduler
08:26 timotimo rather than complain or something
08:26 jnthn brrt: Yes.
08:26 timotimo brrt: it's supposed to take a continuation that can later be invoked again
08:26 brrt i.e. my $x = start { foo; }; await $x;
08:27 jnthn brrt: I described that in the gist I wrote ;)
08:27 brrt can start on another thread? doesn't just lock and wait?
08:27 brrt which gist was that? if you didn't publish so much interesting stuff, i might be able to renember :-P
08:27 brrt oh
08:27 timotimo https://gist.github.com/jnthn/a56fd4a22e7c43080078
08:27 jnthn bah, timotimo++ can find my gists faster than I can :P
08:27 brrt anyway, yeah, awaiting in a lock is a pretty bad idea
08:30 jnthn In C# they have syntax for lock (for one very particular type of lock...grmbl) and the compiler forbids an await inside of a lock block. We can't do that, but we can do the more dynamic analysis.
08:33 brrt hmm
08:33 brrt java is worse (of course)
08:33 brrt java synchronized blocks are nearly useless
08:34 timotimo is that so? are they anything more than a little monitor?
08:38 brrt hmm yeah, they are reentrant? and they have very funky wait() and notify() semantics
08:38 brrt my point is actually, monitor semantics are not all that useful in trying to make good code
08:39 timotimo it's a very rough primitive that gives you broad exclusion
08:39 timotimo you can get better code by using finer locks or a different kind of primitive altogether, i suppose
08:48 brrt it's not a good primitive (and neither are locks)
08:48 brrt channels / queues, supplies, promises etc are much better
09:03 jnthn Having locks and cond vars to hand is really really useful as building blocks
09:03 jnthn But they're not what you want to work with directly most of the time
09:25 brrt concurrency is weird like that
09:25 brrt nobody thinks anything of using addition, subtraction, function calls as building blocks for larger applications
09:25 brrt but low-level concurrency primitves don't scale at all
09:26 brrt high-level 'pseudoprimitives' like queues/channels/etc are not a problem
10:02 brrt` joined #moarvm
10:15 vendethiel joined #moarvm
11:02 jnthn To be fair, the higher level concurrency abstractiosn are a more recent arrival in mainstream languages.
11:05 zakharyas joined #moarvm
11:13 rurban_ joined #moarvm
12:21 vendethiel joined #moarvm
12:38 Ven joined #moarvm
13:30 Ven joined #moarvm
13:55 nebuchadnezzar joined #moarvm
14:21 flussence joined #moarvm
15:03 hoelzro_ii joined #moarvm
15:20 Ven joined #moarvm
16:00 Ven joined #moarvm
16:52 brrt joined #moarvm
17:04 ggoebel joined #moarvm
17:22 TimToady joined #moarvm
18:04 colomon joined #moarvm
18:20 colomon_ joined #moarvm
18:52 vendethiel joined #moarvm
19:03 rurban_ joined #moarvm
19:04 brrt joined #moarvm
19:19 vendethiel joined #moarvm
19:39 brrt joined #moarvm
20:03 brrt blog: http://brrt-to-the-future.blogspot.nl/2015/07/tiles-and-compiler-compilers.html
20:13 lizmat brrt: do you still take comments about spelling errors ?
20:13 brrt that i do
20:13 brrt :-)
20:13 lizmat expresion: result = LOCAL[8] + 12   "expression"
20:13 brrt ah
20:15 brrt fixed that one
20:15 brrt any more?
20:15 lizmat not yet :-)
20:18 lizmat Fortunately, chichken-and-egg   "chicken-and-egg"
20:18 brrt aye
20:22 TEttinger joined #moarvm
20:22 lizmat that's it...  exciting!
20:23 brrt :-) it's pretty cool stuff, i think
20:23 brrt you know what i find funny
20:23 brrt i was halfway through the work until i realised 'hey, i'm creating a DFA'
20:23 lizmat no?
20:23 lizmat hehe
20:23 lizmat see, I know your CS study would come in handy  :-)
20:24 * jnthn home o/
20:24 brrt \o/
20:24 lizmat jnthn o/
20:24 brrt (i'm not actually a CS student... :-))
20:24 brrt i'm off for tonight
20:25 lizmat good night, brrt!
20:25 brrt good night!
20:28 jnthn .oO( I used to be a CS student, but then I took a bachelor degree )
21:33 jnthn brrt: It seems that in the "naive code", the 12 has gone missing?
21:34 jnthn And also r0 isn't used
21:37 jnthn brrt++ # nice post, and really nice work
21:52 timo joined #moarvm
23:02 raiph joined #moarvm
23:09 raiph This Jan 2015 article might be of interest to at least brrt: Data-reuse Optimizations for Pipelined Tiling with Parametric Tile Sizes # https://hal.inria.fr/hal-01111393/file/main.pdf

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