And if your last status is from 2011 then you should certainly watch the 2019 videos and comment on them.
Sure, my information is a little out of date, but it seems like the argument has been consistent since 2011. "Performance improvements are inevitable and imminent". That wasn't obviously true to me in 2011, and it's not obviously true to me in 2019.
I've written elsewhere a little bit about the architectural differences between Parrot and Moar and my concerns that Moar has made some of the same mistakes that Parrot did (and ignoring some of the experiment and design work that Parrot was working on). Nothing I've seen since then has made me think that Rakudo can get the order-of-magnitude speed improvements in the large that it needs to outperform Perl reliably overall or that it can get the multiple order-of-magnitude speed improvements in the large it would need to outperform JavaScript or other well optimized JIT/AOT language implementations.
But, as always, I could be wrong.
| [reply] |
> But, as always, I could be wrong.
Even worse, now you need to elaborate why you're sure that it's a lost cause and add arguments to your critic.
Of course you could watch the videos first and tell us afterwards where the logical fallacies are. This might be easier.
This whole underdetailed "nothing I've seen till 2011" routine is little convincing and won't help you getting detailed answers to your (rhetorical?) question. :)
| [reply] |
Even worse, now you need to elaborate why you're sure that it's a lost cause and add arguments to your critic.
That's not my argument, but why do I need to elaborate? What's unclear about "this has been promised since 2011, and it hasn't happened yet, so why should I believe it's right around the corner"?
Of course you could watch the videos first and tell us afterwards where the logical fallacies are. This might be easier.
Why? What's changed in the design since 2011-2013?
When I profiled Rakudo, I proposed a simple grammar change to freeze the definition of .ws to a well-understood character class so that every grammar rule wouldn't have to go through a method lookup between tokens. Larry said no. (I can't remember if that was a 30% or 40% speed improvement in the Rakudo test suite.)
NQP is pretty speedy. It's not bad for a dynamic language. Rakudo isn't speedy. Last time I looked, that was inherent to the design.
Furthermore, the reason we wanted to get as much Parrot code out of C as possible in Lorito is to learn the lessons of JavaScript implementations: the more code written in JavaScript, the faster it can go. Nothing I've seen in Moar suggests it's taken that approach. Maybe it can, but until it does, I don't expect it will improve performance in the large by orders of magnitude.
| [reply]
[d/l] |