Thanks for the answers that's very helpful and the talk was pretty interesting. One thing that concerns me a bit is he mentions parallel but not concurrent collectors (the kind MoarVM has) may stop scaling around ~16 threads. Seeing as a new desktop these days will come with a 12 core Broadwell that seems just around the corner for even the average user, and for big iron we've been there for a long time now.
On Oct 5, 2016 1:50 PM, "Timo Paulssen" <[email protected]> wrote: > Hi there, let me answer a few of your questions real quick: > > > On 05/10/16 20:38, Joseph Garvin wrote: > > > What is the state of multithreading in Perl 6 (MoarVM)? > > Specifically: > > * Can two threads preempt one another? > MoarVM has threads that map to operating system level threads. Rakudo > exposes those directly as the Thread object, but normally you'll be using > ThreadPoolScheduler, which is provided right from the start in $*SCHEDULER. > It will only start operating system threads up to a given parameter. > > > * Is there a GIL? (Think I asked around before and the answer is no) > There is no GIL. > > * Can two threads allocate at the same time? > Yes, they can. Each Thread has its own Nursery where allocations happen. > > * Does a GC stop all threads? > Yes, it does. > > * Are there any other common operations, besides allocation, that > > trigger locks? > If you mean operations that lock up all threads and prevent them from > doing anything, then no. There are a few instance-level data structures > that have locks on them, though. > > * If allocation triggers a lock, how feasible is it to write in an > > allocation free style? > At the moment, it's almost impossible. Normally, you'd be able to use > native ints, nums and strings to never allocate stuff while doing maths, > but MoarVM isn't yet good at eliminating references, so passing native ints > as read-writable to subs (like operators, ++ for example) is currently > pessimized in that way. > > Hyper operators and junctions and future promises of autothreading > are > great, but without answers to these it's hard to know whether the > > threading is or will be actually worth taking advantage of. I've > noticed > nobody outside the CLR and the JVM seems to actually > implement real > multithreaded GC so I'm a bit skeptical. It seems like > a common > implementation stumbling block and a genuinely hard > problem. > Multithreaded GCs can be defined along at least two axis: Concurrent (with > the program's execution) and Parallel. MoarVM has a parallel GC, which > means that each thread does GCing on its own and there's some cross-thread > communication. Building a Concurrent GC is a crazy amount of work and is > *very* hard to get right, if i understand correctly. > > Joe G. > > > Lastly, here's a presentation by Jonathan on GCs which uses MoarVM's GC as > an example: https://www.infoq.com/presentations/terminology- > garbage-collector > > Please feel free to ask more questions > - Timo >
