First, I don't think that the primary reason that map and sort are implemented in C is because of performance. They were chosen to be added to the language and so they were implemented as part of the language (which is implemented primarily in C).

If you feel that "reduce" is useful enough and the speed difference is important enough, then by all means advocate a patch to the Perl source so that the level of review and maintenance of the code will rise to match the high level of difficulty of writing C code that manipulates Perl structures. Most XS code shares this difficulty but does not share most of the review (of both design and code), testing, maintenance, or even expertise of the Perl source code.

XS code also has a different environment that makes it even more likely to have bugs than Perl source code. XS authors routinely make simplifying assumptions that Perl developers do not (even in the case of a single person playing those two different roles).

I don't find the two subroutines you quoted to be very similar.

As to your restatement of my thesis:

That code should not be optimised as it it harder to get right and that using C (via XS) to code something that can be coded in Perl is an undesirable thing to do for that reason.

It isn't too far off. Might I suggest that in future, when you respond to a reinterpretation of what someone has written (which, really, is always what we do), for each point in your response, compare the point against the original statement. I find that this often helps me to realize when I've over- or mis-interpreted what someone has written (or simply that I'm not sure what they meant in relation to that specific point). Just yesterday and today I've deleted several draft paragraphs as a result of this self-check.

But it is a bit off:

code should not be optimised

I specifically mentioned "enthusiastic" optimization. You appear to have interpreted several of my points as "black-and-white" that I did not (IMHO) express that way. There are certainly good reason to optimize. All too often I see great effort being put toward "optimization" that I consider simply foolish.

This specific case of optimization falls perhaps a bit short of the "foolish" label, but goes beyond what I consider sensible.

using C (via XS) to code something that can be coded in Perl is an undesirable thing to do for [optimization]

That is close. But just a few weeks back I helped someone implement C code to speed up a tree search and just last week I posted Re: checking for overlap (index) which proposes "moving much of the search code into [C]".1 I specifically mentioned Inline::C and not XS, but I don't approve of all Inline::C code nor condemn all XS code.

What I condemn is writing C code that manipulates Perl structures (other than as part of Perl, where the practice is required and properly dealt with). I've seen XS code written by some of the best XS coders around (near as I can tell) and I'm usually impressed with how bad it is.

I've never seen anyone asking for help with bugs in C code written for Perl extensions when that code avoided dealing with Perl structures. Inline::C helps you avoid dealing with Perl structures in your C code more than XS does. But the important point is to avoid it, whichever tool you use.

So, optimizing something that works perfectly well when you have no profiling saying that it takes too long to run by trying to only eliminate the opcode dispatch work by reimplementing it in a particularly buggy form of C code that you hope is mostly the same as the code that gets run in the original case except without all of the review/testing/maintenance infrastructure ... No, it doesn't seem sensible to me.

Maybe the XS code is hundreds of times faster and the huge risk increase is worthwhile. I don't know. That was part of why I had "</soapbox>" and a smiley in the original node.

                - tye

1If I were vain enough to assume that you had noticed these, then I'd suggest you "examine who speaks" ;)

In reply to Re^5: An anomaly with List::Util::reduce and/or eval? (XS) by tye
in thread An anomaly with List::Util::reduce and/or eval? by BrowserUk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.