PCC reordering idea (and probably branch)

[Allison Randal]

On 03/16/2012 02:47 AM, Vasily Chekalkin wrote:
> 
> Reaaally bad example. I can point on at least 5 flows in this
> statement. For the beginning:
> 1. Erlang VM is not "generic vm" to support variety of dynamically
> typed languages.
> 2. Erlang is immutable language with Message Passing architecture.
> It's _always_ safe to split
> execution into different thread, process, server in this case.
> 3. Erlang doesn't support multi-dispatch. Pattern matching happen
> inside subroutine.
> 4. Erlang is not "modern concurrent implementation". Till mid-2000 it
> didn't support multicore CPU properly.
> 5. "STM" is "modern concurrent implementation" for mutable world. FSVO "modern".
> 6. Catering PCC for "always possible multithreaded execution" is
> semantically same error as
> "catering PCC for both internal and external calls". Least Common
> Denominator. It is _slow_.

Um... none of that is relevant to the question of encapsulated dispatch.
The fact that Erlang has some good features doesn't mean I'm elevating
it to superlanguage status.

> Yes, rakudo/nqp uses current PCC to pass arguments. Not Parrot
> multidispatch though.

Cool. I'd like to propose ripping it out. With a suitable delay, of
course, to make sure there aren't any other languages using it, and to
talk through what they do need and if there's a better way to provide it.

>> Based on what profiling results?
> 
> valgrind --tool=callgrind.
> 
> https://github.com/parrot/parrot/commit/12b59772e3146e5055e57f963236bfb700bbd48b
> 
> git log src/call/args.c, search for "%"

Oh, I wasn't asking about profiling 2 years ago, I was asking about
profiling today. The code has changed quite a bit.

> And redesigning Parrot to be heavily multi-threaded VM is really
> interesting task. But I wouldn't call it "Parrot". Just because it
> will be easy to do it from clean start. Or use Erlang if it's matter.

Building a multi-threaded VM is one of the key reasons Parrot was started.

Allison