Re^8: Hockey Sticks

[raiph]

What the Parrot, Rakudo and niecza teams ship is what wikipedia defines as a "software release".

The Rakudo compiler release process is indeed much less formal than Perl 5's, but there is much more to it than you suggest. Patrick is currently rewriting the release management document; visit #perl6 if you're interested in more details.

> I see some problems in marketing and talking about Perl 6.

Oh boy, me too! Forget marketing. Just talking about P6 where it is ostensibly supposed to be discussed, eg in this meditation, or announcing releases using the Perl reddit tag, routinely attracts trolls.

> Firstly you need to come up with something solid and then announce, or you shouldn't announce at all.

Which announcements are you talking about? The monthly releases (or whatever you wish to call them)? Would you call this meditation an announcement?

> the words 'Production release' , '1.0.0', 'ready', 'done' have semantics beyond their dictionary meanings in the software world.

Right. I'm unaware of anyone applying those words to Perl 6 as it currently stands. Perhaps the closest is that Larry has recently begun to talk about productizing Perl 6 over the "next year or two".

> For most Perl 5 developers, 'Production ready', 'complete', 'done' or any other equivalent word means software at least as much ready and usable as Perl 5 is. Therefore if you ever want Perl 6 to be 'complete', its likely to never be- considering the scope and breadth of the work.

I agree. It would be a mistake to only ship P6 when it's "complete" in that extreme sense.

> I seriously doubt if the current path will lead to anything usable in coming years either.

Several users have P6 solutions currently in use in production settings; how could they if it's not usable?

[BrowserUk]

routinely attracts trolls

I won't ask you to define troll in this instance, but I do have a question.

Has anyone performed even rudimentary benchmarking of the various implementations of P6?

I'm still attracted to (what I remember of) the P6 syntax, but for the type of applications I mostly write -- generally cpu-bound -- cool syntax isn't sufficient justification for taking a 10x or even 5x performance hit over P5.

A simple benchmark -- as a minimalistic start I'd suggest: a) a non-trick, non-caching implementation of Ackermann; b) Stirling's series; c) the string handling benchmark from here; -- would give a somewhat real-world measurement of how the implementations are progressing from that point of view against P5, each other, and against themselves over time.

[raiph]

> Has anyone performed even rudimentary benchmarking of the various implementations of P6?

To give a sense of #perl6 awareness and use of benchmarking, you could browse this search for "benchmark" mentions on #perl6. Nearly 300 days in the last 7 years include at least a mention. From the most recent page of results, 7 of the 13 matches involving 8 folk relate to benchmarking improvements or benchmark results rather than mere discussion. Imo the mandelbrot script is particularly interesting.

From another angle, here's a slideshow about the performance of Rakudo (a P6 compiler).

> I'm still attracted to (what I remember of) the P6 syntax, but for the type of applications I mostly write -- generally cpu-bound -- cool syntax isn't sufficient justification for taking a 10x or even 5x performance hit over P5.

Right. Speedwise, in some ways current P6 implementations are in a position analogous to Python or Ruby, especially earlier versions. It's entirely possible that no current P6 implementation is yet in the same planetary system, let alone ballpark, for what it sounds like you need.

That said, in theory, @Larry have tackled the issue of speed in P6, including at the cpu level, from the start. For example, in theory, P6 autothreading is supposed to automatically distribute a lot of computation over the multiple CPUs in multicore hardware. However, following good dev practice, a lot of P6 optimization has been left till "the last mile" -- ie hasn't happened yet.

as a minimalistic start I'd suggest...

Perl6 needs contributors much more than it needs ideas. That's why I posted this comment. It would be awesome if you visited #perl6 on freenode with an open mind and volunteered to try to set up one of the benchmarks you mention for one compiler and then post about your experience here. Maybe using japhb++'s perl6-bench project, a P6 workbench for doing comparative benchmarking?

[BrowserUk]

For example, in theory, P6 autothreading is supposed to automatically distribute a lot of computation over the multiple CPUs in multicore hardware. However, following good dev practice, a lot of P6 optimization has been left till "the last mile" -- which is where I think things are at now.

Okay, thanks. The above, combined with slideshow, told me -- albeit rather verbosely in the latter case -- everythng I needed to know.

[Anonymous Monk]

Beyond the Perl 6 IRC channel, mailing lists and people attending hackathons. The software world has some 'perceptions' and defaulted semantics of terms release, production ready, complete, stable, usable etc. You can argue against it, but that is beyond the point. And explains my point regarding 'Marketing problems' we have. Lets say you go to a county, where they interchangeably call milk as water and water as milk. You know that is not true. You try to explain the whole country to correct themselves. But they are so much throughout generations trained to perceive them as such. The only option you have is to endlessly go on and correct the whole country(And they will never change) or 'change yourself'. The second option is better, because when you do that you begin to understand that they were actually right.

So lets try for a production ready release, which is as much production ready as much as Perl 5 is. Which I am pretty sure Perl 6 isn't today. Any thing other than that, and you are now going on a different plane. Moving the goal post, to ensure your goal counts is not how it should be done

Regarding Perl 6 being ready in an 'year or two', I take it for face value. Because reading the feature completion matrix once shows very few '-'s and there I believe 'its almost complete'. Regarding how much time remaining '-'s will take, we don't know. And even if they take little time, how many re writes it will take to get there is another question. And how many backends to which it will ported before those few '-'s are implemented is an another question.

So even though there are a few features left to complete, I doubt if rewrites, multiple backends and other stuff will allow you to get there in 2 years. Having said that even two years is a long time, and lot of things change in two years.