|Don't ask to ask, just ask|
Re^3: [Perl6] just got an itsy-bitsy, teeny-weeny bit fasterby BrowserUk (Pope)
|on Aug 07, 2017 at 10:10 UTC||Need Help??|
I think 10% speed gain is seriously faster.
Sorry, but a 10% improvement, when by your own admission an order of magnitude is required, doesn't come close to "serious" IMO.
If perl6 will be able to optimize next and last to end a loop other that through an exception,
I think you've hit the nail on the head.
if you also look at what the language offers, you might conclude that once you master the basic constructs, development-time in perl6 weighs up to solving problems in other languages.... scripts for complex tasks that ... but require serious thought in other languages, just write themselves in perl6.
P6 has a seriously powerful and interesting syntax; but unless that syntax can be converted into runtime code that runs efficiently, without resorting to requiring complex XS code, called via the P5 runtime, it means that whatever develop-time gains might be available are swamped by the need to also learn and use XS to achieve performance.
There are several features of the P6 language that are simply too complex to ever allow the language to be interpreted efficiently. Any one of: generics, OO-exception handling, MOP, incremental regex, hypotheticals, junctions, lazy evaluation, macros, user-define operators, active metadata, introspection; preclude conversion to an efficient bytecode format.
Just as the possibilities of overloading and tying & magic, impose constant runtime performance penalties on every Perl5 opcode, each of those P6 features adds the requirement for a runtime decision point and branch or an indirection. Any two or three combined would make the tasks of compile time and runtime (JIT) optimisation very, very tough.
With all of them, the task is simply impossible in an interpreted language. With that number of permutations of decision points and indirections, the time taken to select and generate the optimised code paths, will be greater than the time required to run the unoptimised code.
The fact that even when just calling P5/XS code from P6 to do the bulk of the benchmarked task, imposes an 2 orders of magnitude performance penalty, and that is lorded as a breakthrough...
The only way P6 will ever run efficiently is if it is compiled; and that would require a multi-pass, iteratively refining compiler of the complexity of GHC, and that will have been under constant development by a well-funded succession of seriously clever professors and a nearly unlimited supply of cheap and enthusiastic undergrads and grads for thirty years in two years time!
It's taken the last 15 years (my time with perl) for P6 to get to the point where being only 200x slower is a newsworthy event; I simply don't have the lifespan nor enthusiasm to wait another 15. I've got too much doddering and pottering and bitching loudly about the youth of today to do before I kick it, to even consider it.
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". The enemy of (IT) success is complexity.
In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit