The Parrot is dead. Long live the Parrot?

Reini Urban rurban at
Tue Feb 12 16:39:13 UTC 2013

FWIW: I already said it on #parrot

We barely survived similar axing out `unneeded bloat` from parrot previously.
If you want to get rid of stuff you don't understand and rakudo does not need,
rather leave it in. None of this code made parrot or rakudo slower, it
rather helped
parrot to be faster and to target more HLLs.

removing support for invokecc, multiple return values and adding
6model on the other hand is good. this is a unbearable slowdown,
but the calling convention, nci design, method calls via nci, and vm
design is much worse than that. strings in imcc vs vm?? hell.
self-made sprintf's orgies in constructing function calls?? hell. nci
parses the sig string at ever single call?? where am I?

nqp is needed for bacek's jit compiler, which I slowly brought in.

imcc -O1 removal was nonsense, only -O2 was broken, and it was trivial
to fix for me in one hour. but since someone just removed the whole
imcc optimization infrastructure I was hesitant and horrified to bring
it back in. parrot is a compiler, how would you argument that removing
compiler optimizations on pir level helps the product? it only helps
the managers who do not understand compiler optimizations.

jit removal was non-sense and almost killed us. it should have been
easy to fix. it was not just disabled, it was completely removed,
without any chance to bring back in.

parrot made significant progress last year, just lorito not.
you are destroying it now in shere suicidal tendencies again just because a
few outsiders badmouthed it? threads and the generational non-blocking
gc were a dramatic progress and the endresult is that people now
believe our threads are broken and jvm threads are better??? hell

I'm all for fixing the management problems, which led to disgust at perl6.
killing all the languages, adding strange anti-perl6 policies, killing
bytecompat, ...

you cannot just say, let's do it the naive way first, we can optimize later.
if you design a vm, you have to know the limitations of your design beforehand

but you enter again the the stage of killing the supporting codebase
for no technical reason.
let the devs do this and stay behind please.

rakudo will be happy, if they have a feature veto, a policy veto and
if they see
maintainance and performance improvements in parrot.

ripping out 'unneeded' ops and pmcs will not lead to this, rather
annoys everyone else. (those silent people who just went away without
telling anyone)
rather fix the problems, which were already identified.

I can only fix stuff which I am allowed to fix. if managers above me rather
act suicidal I stay away from this mess.

francois went to lua, I went to lua. lua has its limitations (no
arrays, just hashes, limited int size, limited code size), but in the
end it's easier to work around those limitations there
than deal with the deoptimized design here.
Almost every good lisp compiler I know uses the same design. The fast
scripting languages out there just copied it.
Reini Urban

More information about the parrot-dev mailing list