in reply to Re: CPU cycles DO NOT MATTER!
in thread CPU cycles DO NOT MATTER!

There are still the odd applications for which a few CPU cycles per computation can add up to a rather significant difference, but these tend to be written in C, C++, or Fortran, not Perl
And there is a reason for that: if you need that kind of tiny optimization, you've already switched that part of the code to C or C++ or some other high-performance language weeks or months ago - those languages can easily give you a 1000% performance boost over perl with no changes in the algorithm whatsoever. Just compare the cost of a perl method call to one in C++.

But since perl integrates pretty nicely with C and C++ and is so much easier to code in, in general it's still much better to start out with pure perl, and only re-write the stuff that really does need to be fast in C/C++.

Update: that's to say that I generally agree with the OP, but I'm also working on a project that's already spending about as much on hardware as on programmers. Spending another man/month or two to decimate (literally) the hardware cost can certainly be worth it.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Replies are listed 'Best First'.
Re^3: CPU cycles DO NOT MATTER!
by BrowserUk (Patriarch) on Apr 19, 2008 at 22:17 UTC
    and only re-write the stuff that really does need to be fast in C/C++.

    So, you are optimising your project, but "generally agree with the OP," when he says :" CPU cycles DO NOT MATTER!"...?

    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 generally agree with the OP that in perl CPU cycles do not matter. What matters much more in perl is algorithm changes; usually memory/IO related.

      If you really want to optimize your CPU usage (assuming CPU usage, instead of network or other IO speed, is in fact the bottleneck) don't use perl. Perl's pretty damn fast for an interpreter but it's certainly not the best choice for using your CPU power.

      "What should it profit a man, if he should win a flame war, yet lose his cool?"
[reply]

        Agreed. But even choosing or changing your algorithm to reduce memory cycling is optimising for cpu cycles.

        It's the blanket statement I object to most. Followed by the idea that the short term hardware fix is economic in the long term.

        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]

In Section Meditations