Hacker News Reader

Comment by aduitsis | Hacker News Reader

Read the article, very informative. Pleasantly surprised to find out that it doesn't mention at all language traits like syntax, but focuses on the features of Perl6's underlying VM, specifically MoarVM.

View on HN

Indeed, a GILless bytecode VM is worth a look.

GIL less yes, but not lockless. The previous perl6 VM, parrot, had lockless threads, scaling linearly per native core. MoarVM even needs to lock on hash or array accesses, which is certainly not state of the art.

How did parrot write arrays from multiple threads without a lock somewhere in there?

The parrot threads didn't communicate with each other and you could wait until all of them finished. They provided a tiny subset of the functionality real threads offer but in a more efficient way.

You deferred updates to the owner via scheduler, with high prio, and continue. parrot threads are lock free but not wait free. The NQP compiler needed to know about threaded writes and schedule the update, with a semaphore, while the other threads continue.

What MoarVM got better was everything else. The GC, the calling convention, the OO (6model), the jit. I was on my way to fix all the parrot damage done from the previous decade, because this would have enabled all architectures and proper threading for perl6, but then perl6 decided to kill it and go with Moar. And spread a lot of lies on threads.

I fail to see how using a semaphore to schedule work in another thread is "lock-free."

Because you wait but you don't lock. And the wait is not 100x of an instruction, normally it's the same time as for one single instruction. Writes are fast and atomic, because there's no lock. Only the writer needs to wait a bit, not any other thread.

Google for lock-free vs wait-free

Well, it should have mentioned Perl6 uses rational number math instead of floating point. I think this is a big advantage, since you can do more precise calculations using just the core language.

Reply on news.ycombinator.com