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

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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^4: CPU cycles DO NOT MATTER!
by Joost (Canon) on Apr 19, 2008 at 22:21 UTC
    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]
        It's the blanket statement I object to most.
        Yes the title is a bit confrontational. And wrong :-) But I assume that was deliberate.

        The gist of it is right, though: people spend way too much time optimizing stuff for hours that doesn't make even a minute of difference a year.

        Followed by the idea that the short term hardware fix is economic in the long term.
        That depends. But the OP might consider that once hardware is bought, it's not generally upgraded every year and a half to take advantage of Moor's law (even if that would be economical by itself), and that many servers these days are placed in rented spaces, which means you pay for the size of your server farm and its power consumption each month, not just once.

        "What should it profit a man, if he should win a flame war, yet lose his cool?"
[reply]
        The blanket statement was meant to start a conversation, hopefully amongst many monks. To that end, my OP has been, by and large, successful. I also hope it has gotten some people to reconsider their priorities from a purely coding perspective to taking the larger picture of the business into account.

        And, hopefully, to realize that optimizing for CPU cycles in a language running in a 10-year old VM is rather silly.

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

In Section Meditations