cpanm git://github.com/mrallen1/perl-Tombala
:)
]]>A benefit of this approach is a better separation between data ("what") and code ("how"): Makefile.PL and Build.PL is code how to do the build process. cpanfile is data to specify what dependencies exist.
due to disk space I installed it somewhere else, and the build process littered $HOME
$ perl6 -e 'say "Hello, World"' Hello, World
]]>I appreciate that this wasn't the main point of your post, but: Perl 5 is "the fastest dynamic language"? That's quite a surprising assertion - what's it based on?
For some tasks, JS is up to 30x faster:
http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=perl&lang2=v8&data=u32
This means an order of magnitude still isn't all that impressive.
Even Lua beats perl5:
http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=perl&lang2=lua&data=u32
Perl is convenient, rather than fast. If you're lucky enough to have a task involving the right set of opcodes then sure, there's some great code in the perl core (and various XS modules) that'll give amazing results. But if you take into account object construction, method calls, 'my $self = shift', refcounting... the overhead adds up quickly: in my experience a typical application tends to be slower than the JS equivalent. Perl only starts to gain an edge if you compare things like _.map vs. perl's built-in map, which isn't really fair.
]]>That's quite a surprising assertion – what's it based on?
It used to be true some while ago – and some of the basis for that still applies: Perl is still faster than CPython and PHP. It beat the pants off the old Ruby runtime but I have no idea how the new one stacks up. It also used to be faster than Javascript before that one hitched a ride on the JIT rocket. Lua was entirely off the map at the time.
So it’s still more or less “the fastest of the P languages”, at least for now – but no, it has been a while since it was last king of the entire hill.
]]>To be fair, I think that's only the case for micro-benchmarks that compare Perl 6 built-in features with the equivalent features provided by bloated/unoptimized/neglected Perl 5 modules.
For example, Perl 6's built-in Rat
type vs Perl 5's Math::BigRat
.
In macro-benchmarks that use many different language features to achieve something resembling a real-world task, Rakudo Perl 6 still tends to be very slow. Also, start-up time is an issue for command-line scripts (although if you're using Perl 5 + Moose, you'll already be used to that...)
Of course, the performance progress that the Rakudo developers have made over the course of the last 6 months is impressive, and if I understand correctly, the optimization work is far from finished. Like Ovid, I'm hopeful that Winter ahem Christmas is coming... :)
]]>To be fair, I think that's only the case for micro-benchmarks that compare Perl 6 **built-in** features with the equivalent features provided by bloated/unoptimized/neglected Perl 5 **modules**. For example, Perl 6's built-in Rat type vs Perl 5's Math::BigRat.
No, actually, that is no longer true. There are cases where Rakudo/MoarVM keeps up with Perl 5 at built-ins, or beats it handily. At built-ins. Check out the benchmarks and see for yourself. There is a little “[Code]” button next to each benchmark that displays what is being measured; look for the graphs where the Rakudo/MoarVM line overlaps or soars above the Perl5 line.
(Select ones of these benchmarks – without the code – are included in jnthn’s YAPC::EU talk slides.)
The bigger ding here is that these are rather specific micro-benchmarks, and the overall practical performance does still trail Perl 5 by a wide margin.
But do you expect it to stay like this?
(Obviously trend lines ought not be extrapolated linearly, but I invite you to consider how long Java was the butt of many a joke about performance, how its VM is regarded nowadays, how long that transformation took, how much manpower it required, and to then contrast how long it took how much manpower for MoarVM to make the strides shown here.)
]]>I only see 3 kinds of micro-benchmarks on that page where Perl 6 comes in faster or as fast as Perl 5:
This seems like an altogether archaic use-case from a P5 point of view (that is, probably not very meaningful with regards to real-life code).
This is what I was referring to in my previous comment.
This one is interesting; although I'm not entirely convinced that
my ($result) = $s =~ /^\s*(.*?)\s*$/s #P5
is the best way to fairly translate
$s.trim # P6
For one thing, an assignment is happening in the P5 version whereas the P6 one seemingly just discards the result; also, the P5 version could be rewritten using s///r in a way that does not involve constructing a capture group.
As for the macro-benchmarks, P6 is considerably slower for all of them -- except for rc-mandelbrot, which uses complex number arithmetic (P6 built-in "Complex" vs P5 "use Math::Complex;") - again, the kind of thing I was referring to in my last comment.
But do you expect it to stay like this?
No, I hope Rakudo will get similarly fast as perl. But lets not call it before it happens... :)
]]>The way I understand these results is “here is proof positive that it can”: a plausible promise. There are still seasons’ worth of low-hanging fruit ahead, anywhere you look, so the fact that we have these results now is an encouraging indicator of how high the effort might be able to reach.
Before this point, that was always the claim and the idea, and for some people it was the reasonable expectation, but there was no tangible evidence. It remains to be seen if the promise can be fulfilled, but these numbers do mark a new stage.
(FWIW, the results on integer arithmetic are interesting because of low-hanging fruit: many opportunities are still open for the runtime to specialise more generic numeric operations to integer, speeding up math across the board. Also, MoarVM is also already looking good in the concat-based benchmarks – an indication of the attainable string op performance. I’m looking forward to the future.)
]]>