http://qs321.pair.com?node_id=1218523


in reply to Re^6: It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?
in thread It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?

The only scalability issue with iThreads is the implementation (not the model) of shared memory aggregates.

I'm glad to hear that Perl 5 users are now more interested in the theoretical benefits of Perl 5, rather than the practical ones.

I suggest you try this benchmark by at least mimicking a real application, by e.g. adding a use Moose to your program. The problem with Perl 5 ithreads is not in tests like this. The problem is in real applications that set up a lot of data structures that need to be copied to all 3000 threads in your example. And whose memory will not be shared. I bet it will run a tad over 2 GB by just adding use Moose.

The "steaming pile of abandonware", as you call it, contains forks, which will run your benchmark with use Moose in an acceptable time. And yes, all of my Perl 5 modules are up for adoption. I know some people are still using some of my modules in production, so I won't remove them from CPAN (just yet).

As far as my article from 15 years ago being in error: The use of interpreter-based threads in perl is officially discouraged. What does that mean?

From time to time, we may mark language constructs and features which we consider to have been mistakes as discouraged. Discouraged features aren't currently candidates for removal, but we may later deprecate them if they're found to stand in the way of a significant improvement to the Perl core.

So, to me it seems that at least p5p has learned from its mistake. And that you haven't, I'm really sorry to say. For what it's worth, I would neither recommend Perl 5 ithreads, or the forks module at the current time: MCE - Many-Core Engine for Perl providing parallel processing capabilities seems to cover that niche in Perl 5 nicely. And then there's Mojolicious of course, if you'd like a more event driven approach.

With regards to performance of Perl 6, let's say compared to Perl 5: I would say that at this point in time, Perl 6 is about 7x to 10x as slow as Perl 5. However, we have some very simple benchmarks where Perl 6 is clearly faster than Perl 5. And the number of these benchmarks is growing. To give an example: initializing an integer array with the first 5M positive integer values:

$ time perl -e 'my @a = 0 .. 4_999_999' real 0m0.780s user 0m0.590s sys 0m0.184s $ time perl6 -e 'my int @a = 0 .. 4_999_999' real 0m0.466s user 0m0.485s sys 0m0.096s

If we exclude the startup times (7 msecs / 146 msecs), then you could argue that Perl 6 is (780 - 7) / (466 - 146) = 2.415625x as fast as Perl 5. Even with the startup times disregarded, it's still 780 / 466 = 1.67382x faster as Perl 5 (for this benchmark).

And by the way, I think the term "steaming pile of abandonware" is uncalled for, and I would like you to apologize for that.

EDIT: changed ^5_000_000 to the equivalent 0 .. 4_999_999 as to avoid confusion.