Hm. The Erlang people talk of "Pattern matching in function head and in case and receive clauses are optimized by the compiler." & "the compiler is free to rearrange the clauses. It will generate code similar to this".

Yet, this works in Erlang:

f(1) ->
    io:format("I got one!");
f(X) when X rem 2 == 0 ->
    io:format("I got even!");
f(X) when X rem 2 == 1 ->
    io:format("I got odd! (but not one)").

...

f(random:uniform(1000)).
f("Now eat this!").  %% runtime error
[download]

-module(fns).
-export([run_test/0]).

f(X, Acc) when X rem 2 == 0 ->
    Acc;
f(X, Acc) when X rem 2 == 1 ->
    Acc + 1.

run_test() ->
    TSeq = [random:uniform(10) ||
            _ <- lists:seq(1, 1000000)],
    {Time, Result} = timer:tc(fun() ->
             lists:foldl(fun f/2, 0, TSeq)
                              end),
    io:format("~w microseconds~nResult: ~w~n",
              [Time, Result]).
[download]

93267 microseconds
Result: 500464
[download]

Of course it's optimized. Like you would expect from a language where the only way to loop is recursion.

Sorry. My point was the mentions of "compiler". Whilst not an all-the-way-to-native-code compiler; it is substantially more optimising than Perl's interpreter.

And the fact that it has a strong type system -- as you pointed out -- means that it has far more opportunities for optimising pattern matching than Perl6 ever will have.

With the basic scalar argument being able to contain anything from undef through integers, floats and strings; to array & and hash references; P6 will pretty much always need to inspect every parameter to a function call at runtime in order to determine which multi-sub to invoke.

And there'll be little, if any, opportunity for the interpreter to change (pre-reorder; for performance reasons) the order in which the multi-subs are considered when attempting the runtime match.

I did a lot of playing with Q for a while. A very nice fully dynamic, compiled to bytecode then interpreted, FPL; but boy was it ever slow.

So slow that it had to be replaced by Pure in which "programs run much faster as they are JIT-compiled to native code on the fly".

My overall point is that adding the syntactic convenience of multi-subs to P6 -- which will probably never be able to benefit from such optimisations -- is another nail in its coffin for programming where performance is important.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this

In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

P6 will pretty much always need to inspect every parameter to a function call at runtime in order to determine which multi-sub to invoke.

Aiui P6 by design, and Rakudo in actuality, pretty much always resolve the dispatch target of a call with multisub candidates at compile-time, not run-time. See my previous comment in this thread for more details.

My overall point is that adding the syntactic convenience of multi-subs to P6 -- which will probably never be able to benefit from such optimisations -- is another nail in its coffin for programming where performance is important.

If you've read the comment I linked above you've hopefully switched to accepting that P6 multisubs in general, and as they have been used in P6 code to date, appear to perform roughly the same, speed-wise, as non multi subs in current Rakudo.

You've hopefully also seen why I think a literal parameter is supposed to be considered a singleton value, which in turn is acceptable as a finite set of values, which in turn enables the multisub resolution to stay compile-time. And why this isn't yet the case with Rakudo.

---

Even assuming that most multisub dispatches (in P6) are resolved at compile-time (and are thus no slower than non multi sub dispatches in P6), something about sub dispatching and calling in P6 leads to it being -- at least in my tests in this thread -- one or two orders of magnitude slower than perl (5) sub dispatches. Why?

One reason is missing optimizations. While Rakudo has been getting faster most months for years, the classic optimization phases and mechanisms now built in to Rakudo, NQP and MoarVM only landed last year. Folk have to actually use them to add the thousands of significant optimizations that are possible. Jonathan is wisely leaving these for others to pick off at their leisure while he focuses on stuff that realistically only he can do. Can sub dispatch get a whole lot faster? My guess is yes, way faster, but I'll investigate that guess and report back here on what I hear is possible.

---

Could P6 deliver value for some applications where performance is important? Several P6ers have written video games with Rakudo and I assure you they all think (enough) performance is very important! :) But seriously, I agree that Rakudo doesn't currently look like a strong candidate for writing high performance computing applications. To put it mildly. :)

---

Some news about incremental improvements:

• January's Rakudo is about 20% faster at running the spectests than December's. Mostly because some optimizations that have been left off by default for months/years have now been switched on by default. (To be clear, there's another set of optimizations that are still considered risky and are still left off by default.)

• Jonathan has been making good progress on native arrays, one of the three major guts pieces left to do before a Perl 6 v1.0. Aiui this will speed up some operations by orders of magnitude.

• Patrick has not started hacking on the Great List Refactor. He has said someone may have to do it instead of him. Jonathan has indicated he feels competent to do it, and he'd find the time, but it would come after he lands native arrays (his current focus) and his next task NFG.

• Lizmat has been working on a branch for a few months which she says will have a big positive impact on the speed and RAM efficiency of IO operations. I think it's due to land this month.

• There's a GSoC proposal for automatic SIMD parallelizing of some parallelizable constructs.

• Etc. I know of at least a half dozen P6ers who are having fun working on optimization, adding their speedups to the mix. Does anyone reading this enjoy hacking on an optimizing compiler? :)

»ö« ^{. o O ( "the celebrity tell-all of the Perl-6 cult?" )}