|
in reply to Re^4: sort +*, @array
in thread sort +*, @array
Yeah on the only real problem being speed(*). Larry thinks speed is the #1 impediment to broad interest and many of us agree. Unfortunately we also agree that the core hackers should focus on creating the right design, getting it working, making it work right, speeding it up -- in that order. So Rakudo has sped up a lot this year (I hope to report on that in January), but most realization of known potential optimizations is yet to come (I anticipate a lot more speed up again in 2014). Btw, if anyone reading this enjoys optimizing, it doesn't require C chops, but just Perl (mostly NQP, a small subset of P6).
(*) Yeah on hyperbole and broken promises. I think I'm generally avoiding them but I grant both that there's been a lot of this over P6's history and that, perhaps because of this history, folk routinely manage to interpret my statements as being hyperbole and/or promises.
|
Re^6: sort +*, @array
by BrowserUk (Patriarch) on Dec 11, 2013 at 20:34 UTC
|
we also agree that the core hackers should focus on creating the right design, getting it working, making it work right, speeding it up -- in that order.
All I can say is: wrong call. As with pounds and pennies, take care of the microseconds and the seconds will take care of themselves.
You can't build a fast car if the tyres are restricted to 50 miles an hour, or the bearing to 1000rpm. Nor if you build the infrastructure using Victorian cast-iron (over) engineering.
Build a small, flexible, fast core and then see what nice-to-have features it will stand. There is no need for full MOP-style introspection -- no program needs it -- and the penalties it imposes are clear to see...
(I anticipate a lot more speed up again in 2014)
Based upon what?
Btw, if anyone reading this enjoys optimizing, it doesn't require C chops, but just Perl (mostly NQP, a small subset of P6).
This just doesn't ring true. If the C code that implements/underlies NQP is not efficient -- and especially if the design & architecture of the language runtime is such that it cannot be made efficient -- titivating the the code that runs atop it isn't going to yield the kind of gains that are required to bring it into the realms of real-world usability.
folk routinely manage to interpret my statements as being hyperbole and/or promises.
Your parenthetical -- carefully worded as it is -- sounds like a promise; or wild speculation; or dumb over enthusiasm.
Equally, claiming that +* is "a direct equivalent which retains the ST's generality and efficiency and substantially improves on its elegance." is hyperbole. Which does more harm than good.
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".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
I anticipate a lot more speed up again in 2014
Based upon what?
First, most optimization is yet to come (at all four levels of the compiler toolchain -- Rakudo, NQP, codegen, VM). As I said, rightly or wrongly, they've left most actual optimization (as against designing for optimization capacity) till the last mile.
Second, I see increasing focus on this. For example jnthn landed a commit about a week ago to optimize an aspect of JVM codegen that made the Rakudo/JVM spectest suite run about 10% faster.
If the C code that implements/underlies NQP is not efficient...
NQP is written in NQP so you're talking about the VMs it runs on. I agree that it's important for the long term prospects of Rakudo that one or more of these fairly efficiently runs NQP. (This was one of the reasons for creating MoarVM.)
Your parenthetical ... sounds like a promise; or wild speculation; or dumb over enthusiasm.
A key justification for having the NQP layer of the Rakudo architecture was enabling those with just high level language chops and comfort with Perl syntax to start usefully hacking on the compiler toolchain, including optimization.
For example, timotimo (who was focused on python before he bumped in to P6) recently dropped some boyer-moore logic into the regex engine (which is written in NQP).
For anyone interested in NQP, check out these excellent materials from a weekend workshop introducing NQP.
Equally, claiming that +* is "a direct equivalent which retains the ST's generality and efficiency and substantially improves on its elegance." is hyperbole. Which does more harm than good.
I agree the way I wrote that up was confusing and hope to do better next time.
That said, I can accept monks disliking my poor communication, but I don't want that to lead to misunderstanding of the P6 sort builtin design (not yet fully implemented). Please carefully read the latter half of my response to BrowserUK's example to see its correspondence to ST.
| [reply] |
|
|
Please carefully read the latter half of my response to BrowserUK's example to see its correspondence to ST.
You mean the bit that doesn't use +* and claim it is an ST. THERE IS NO POINT!
My example was never a challenge to what P6 sort was capable of, I've written my own key-caching front end to the Crt qsort on more than one occasion. It's not hard.
It was a challenge to your patently absurd claim. And the damage such claims can have.
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".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
|
|
|
|
|
