Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re^4: CPU cycles DO NOT MATTER!

by Joost (Canon)
on Apr 19, 2008 at 22:21 UTC ( [id://681714]=note: print w/replies, xml ) Need Help??


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

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.

Replies are listed 'Best First'.
Re^5: CPU cycles DO NOT MATTER!
by BrowserUk (Patriarch) on Apr 19, 2008 at 22:25 UTC

    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.
      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.

        I factored that into my TCO. The actual cost for a decent server nowadays is about $4000. The other $6000 is the money spent on that server over 2 years. I'm assuming a sysadmin at $100k/year maintaining 50 servers, so that adds $4000. The other $2000 is power, rackspace, and other incidentals. That comes out to, roughly, $85/month which is rather high. I'm also assuming all free software (Linux, Apache, Pg/MySQL, etc).

        Does that work out better?


        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?
      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?
        And, hopefully, to realize that optimizing for CPU cycles in a language running in a 10-year old VM is rather silly.

        And yet, every time someone comes around asking how do I search my array for a given value, the standard answer is "use a hash". I'm pretty sure that we could dig up a post of yours offering the same advice. Of course, we could also suggest grep, but mostly we don't unless duplicate values must be maintained, because the hash solution is quicker. It can lead to duplication of memory usage, and some additional complexity, but for most purposes, it's a more optimal solution.

        And then there's the case of the small business running a web site on a rented server. For 95% of what he needs, his current installation works perfectly, but there's that one dratted cgi that just takes too darn long and he's getting complaints. Options:

        1. Rent a better server.

          Means making a wholesale move to a different hoster because he's already using their most powerful offering.

          Maybe moving to a dedicated server rather than a virtually hosted one.

          Either involves costs that go beyond just the costs of better hardware.

        2. Or spreading his load across 2 machines.

          But that doesn't work because the slow part of the process is cpu bound, and the second machine is the same spec as the first. Splitting the slow process across two machines means huge complication and expense for clustering software.

          Not to mention the requirement to purchase expertise he doesn't have.

          Not to mention that doubling his hardware costs would cut directly into his profit margins.

        3. Profile the errant code and see what he can do to speed it up.

        Or the case of the hobbyists, college kids, and guys developing programs for friends, or aimed at the home market.

        Requiring C/C++ compilers, and the skills to use them, isn't an option.

        Requiring a $4000 high end server to run their programs isn't an option either.

        If it doesn't run effectively on a reasonably configured typical home system, it won't be usable.

        The corporate world is not the only world. And far from all the people that come to PM seeking solutions to their problems live in that world. In fact, I would suggest that those that have the option of throwing hardware at performance issues are probably in the minority.

        So the next time you see someone seeking to eek out the performance of the hardware they have, by improving the performance of the software they write in that language they know. The language that specifically sets out to not being the exclusive preserve of professional programmers. By all means sit back and feel smug that you have that option, and by all means feel free to move quickly on to posts dealing with more professional matters.

        But please, don't berate them for not having the option, or for seeking to spend their time, optimising their code, to make best possible use of the hardware that they have.


        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://681714]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (4)
As of 2024-03-29 14:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found