5 ms·

> Perl 6 performance has now gotten to the point where it's often comparable to Perl 5 or surpasses it. It still needs some work in this area, but the work is c

> Perl 6 performance has now gotten to the point where it's often comparable to Perl 5 or surpasses it. It still needs some work in this area, but the work is clear, the goals are straightforward, and Perl 6 is going to easily oustrip Perl 5 in terms of performance. If the Perl 6 community wants to rename, it's perhaps the perfect time to do so. It doesn't look like a bad choice if performance is a primary concern. Perl6 has been under development for over a decade at this point, and this equivocating statement is the best that can be said about performance? If the "work is clear, the goals are straightforward" and Perl 6 should easily outstrip Perl 5 on performance, then by gosh they should demonstrate that. Plenty of comments are mentioning slow performance. Not having used Perl 6 myself, I can't comment on it, but the fact that this seems to crop up a lot is really worrying. I've heard varying things - regex/grammar are slower than Perl5, startup time is really slow, etc. And yes - I realize that technically the most popular compiler/VM combination Rakudo+MoarVM hasn't had that full decade of development, and that the spec is "in theory" performant. None of that matters to developers who just want to use the language... If performance is a major blocker to adoption and it's as straightforward to fix as suggested - it should get done. Otherwise, the empty promises will continue to hurt adoption.

bjoli 7y ago
"As fast as Perl 5" means "faster than python and ruby". Every time someone complains about python performance they are usually told that it doesn't matter. If performance was really that important, people that wanted dynamic languages would all be using luajit, SBCL, chez scheme (or any of the other 10 schemes that run laps around python/ruby) and lately also JavaScript.
Ultimatt 7y ago
You might enjoy this talk "Perl 6 performance update" from last week. Assuming you're actually that interested https://www.youtube.com/watch?v=QNeu0wK92NE https://www.youtube.com/watch?v=QNeu0wK92NE
proverbialbunny 7y ago
Perl 5 is quite a speedy language. Getting Perl 6 up to Perl 5 speed is impressive. Part of the reason the language looks scary from a distance is it's $sigils, which speed up the interpreter.
Ovid 7y ago
> Perl6 has been under development for over a decade at this point, and this equivocating statement is the best that can be said about performance? If the "work is clear, the goals are straightforward" and Perl 6 should easily outstrip Perl 5 on performance, then by gosh they should demonstrate that. As the other of the post in question, I refer you to this presentation: https://www.youtube.com/watch?v=QNeu0wK92NE https://www.youtube.com/watch?v=QNeu0wK92NE It's fairly decent, but there's still a huge amount of backstory left out of it. In short: in many areas Perl 6 is pretty close to on par with most dynamic languages today. In other areas, performance is still an issue. > If performance is a major blocker to adoption and it's as straightforward to fix as suggested - it should get done. (Disclaimer: I'm not the one doing the work mentioned below) It's being done, but there's a lot of work. There's compile-time analysis with constant folding, eliminating unnecessary scopes, inlining native ops, code rewriting to faster equivalents, etc. But that can only take you so far. The run time optimizer is hard work, but that's where the good stuff is at. There's a very lightweight optimizer that builds a statistical model of the program and that's very helpful. For example, we can tell if a codepath is hot or not and that model than lets us do all sorts interesting stuff, such as realizing that a hot method is always getting called with an int, so we can skip multi-dispatch lookups, assume an int, and just have a fast guard in place. We can inline code where appropriate. We can do more escape analysis. We can reoptimize code that's inlined at runtime. We can see an int->int and realize that we might not need to box and unbox those as objects. See also: https://jnthn.net/papers/2019-gpw-ea.pdf https://jnthn.net/papers/2019-gpw-ea.pdf In short, there's a ton of stuff to do and it's being done.
- Ovid 7y ago
  "author of the post in question" God, what a horrible typo :)

bjoli 7y ago

"As fast as Perl 5" means "faster than python and ruby". Every time someone complains about python performance they are usually told that it doesn't matter. If performance was really that important, people that wanted dynamic languages would all be using luajit, SBCL, chez scheme (or any of the other 10 schemes that run laps around python/ruby) and lately also JavaScript.

Ultimatt 7y ago

You might enjoy this talk "Perl 6 performance update" from last week. Assuming you're actually that interested https://www.youtube.com/watch?v=QNeu0wK92NE https://www.youtube.com/watch?v=QNeu0wK92NE

proverbialbunny 7y ago

Perl 5 is quite a speedy language. Getting Perl 6 up to Perl 5 speed is impressive. Part of the reason the language looks scary from a distance is it's $sigils, which speed up the interpreter.

Ovid 7y ago

> Perl6 has been under development for over a decade at this point, and this equivocating statement is the best that can be said about performance? If the "work is clear, the goals are straightforward" and Perl 6 should easily outstrip Perl 5 on performance, then by gosh they should demonstrate that. As the other of the post in question, I refer you to this presentation: https://www.youtube.com/watch?v=QNeu0wK92NE https://www.youtube.com/watch?v=QNeu0wK92NE It's fairly decent, but there's still a huge amount of backstory left out of it. In short: in many areas Perl 6 is pretty close to on par with most dynamic languages today. In other areas, performance is still an issue. > If performance is a major blocker to adoption and it's as straightforward to fix as suggested - it should get done. (Disclaimer: I'm not the one doing the work mentioned below) It's being done, but there's a lot of work. There's compile-time analysis with constant folding, eliminating unnecessary scopes, inlining native ops, code rewriting to faster equivalents, etc. But that can only take you so far. The run time optimizer is hard work, but that's where the good stuff is at. There's a very lightweight optimizer that builds a statistical model of the program and that's very helpful. For example, we can tell if a codepath is hot or not and that model than lets us do all sorts interesting stuff, such as realizing that a hot method is always getting called with an int, so we can skip multi-dispatch lookups, assume an int, and just have a fast guard in place. We can inline code where appropriate. We can do more escape analysis. We can reoptimize code that's inlined at runtime. We can see an int->int and realize that we might not need to box and unbox those as objects. See also: https://jnthn.net/papers/2019-gpw-ea.pdf https://jnthn.net/papers/2019-gpw-ea.pdf In short, there's a ton of stuff to do and it's being done.

Ovid 7y ago
"author of the post in question" God, what a horrible typo :)