Re^7: sort +*, @array

[raiph]

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.

[BrowserUk]

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.

[raiph]

I agree that what's said can cause damage. I don't want to cause harm.

In the hope it helps me cause less confusion in future discussions of P6's sort builtin, please consider putting the +* snippet and ST aside for a moment and answering the following questions. Simple yes answers would be ideal. If your answer is no, then elaboration would be helpful.

1. You posted something that can be seen as a simple coding challenge. That is, a solution either does or does not get the same results as your P5 code. Did you understand enough of the P6 code I posted to conclude it might get the same results?

2. Did you catch the point that a key extractor closure (eg { ~days(.day-of-week) }), if not explicitly coupled with an arbitrary comparator closure, is automatically coupled with a generated { $^a cmp $^b } comparator closure?

3. Did you see how { ~days(.day-of-week) }, { ~months(.month) } directly corresponds to substr(scalar localtime($_),0,3), substr(scalar localtime($_),+5,3)?

4. Did you understand how having two key extractor closures leads to an equivalent of the || construct in your P5 comparator closure?

5. Did you understand that ~days(*.day-of-week) is shorthand for { ~days(.day-of-week) }?

Thank you for helping me straighten this out.

[BrowserUk]

In the hope it helps me cause less confusion in future discussions of P6's sort built-in, please consider putting the +* snippet and ST aside for a moment and answering the following questions.

First. There was no confusion. +* does not constitute an ST.

Second. The "simple coding challenge" was purposed (solely) to demonstrate that +* could not be "a direct equivalent which retains the ST's generality and efficiency and substantially improves on its elegance.". Any and all discussion of some other syntax that might be able to meet that challenge is irrelevant to that purpose.

Third. You appear to be angling to make the case that any exposure is good exposure. It's not.

If your knowledge does not allow you to discern good claims from bad in your promotion of P6; run them by someone who has that experience before you go public.