Re^6: Perl 6 and performance

Was the buggy, slow Parrot VM "state of the art?"

Nope; it was basically a rewrite of the Perl 5.6 VM with more sanity.

Was its pathetic JIT compiler (to which I contributed) even vaguely informed by IBM's Jikes RVM or Sun's Java VM?

Somewhat, but those approaches are still wrong for the types of languages intended to run on Parrot. Better examples are Slang and Dis.

Did the implementors consider Greg Wilson's surveys of garbage collection techniques?

Yes, in fact.

The biggest problems with Parrot were:

Its first several years dug a huge hole of technical debt in the form of poorly written code written to do the wrong things while exposing far too much of the internals under the guise of an API. (When normal control flow is a mixture of C calling conventions and Parrot calling conventions and HLL calling conventions, you have a mess, and nothing will run quickly.)
It's no fun to fix that and no one wants to do that.
Even if you find people who want to fix that, it takes forever to fix that when you have to support great wads of buggy, awful C code written as proofs of concept and somehow covered under a poorly conceived deprecation policy, which happens to be self-reinforcing behavior, because if you can't fix things fast enough to support downstream users, they'll write even more buggy and awful C code to poke in the internals, and you have to support that too.

Comment on Re^6: Perl 6 and performance

Replies are listed 'Best First'.
Re^7: Perl 6 and performance by cjfields (Novice) on Feb 09, 2012 at 20:16 UTC
Even if you find people who want to fix that, it takes forever to fix that when you have to support great wads of buggy, awful C code written as proofs of concept and somehow covered under a poorly conceived deprecation policy, which happens to be self-reinforcing behavior, because if you can't fix things fast enough to support downstream users, they'll write even more buggy and awful C code to poke in the internals, and you have to support that too. Hasn't the deprecation policy problem been addressed? Namely, that fixes that need to be in can get in faster now?	[reply]
Re^8: Perl 6 and performance by chromatic (Archbishop) on Feb 09, 2012 at 20:23 UTC
I'll believe that when I see it. I don't know of any upcoming Parrot changes that'll affect Rakudo in any dramatic way, but I don't follow either project in detail.	[reply]
Re^7: Perl 6 and performance by educated_foo (Vicar) on Feb 09, 2012 at 20:32 UTC
I often and vehemently disagree with you, but I think we have some common ground here. We've both been burned by the Perl 6 farce. But I have one quibble: the Boehm conservative GC has long been a baseline for GC performance, and so long as whatever the Parrot folks have cooked up is worse, they only show their ignorance.	[reply]
Re^8: Perl 6 and performance by Anonymous Monk on Feb 09, 2012 at 20:54 UTC
Been there, done that -- gerdr	[reply]