Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: CPU cycles DO NOT MATTER!

by Limbic~Region (Chancellor)
on Apr 17, 2008 at 14:19 UTC ( [id://681170]=note: print w/replies, xml ) Need Help??


in reply to CPU cycles DO NOT MATTER!

dragonchild,
I agree with your sentiment but not the conclusions some might draw from it. It could be argued that what you are saying is tantamount to

It does not matter how inefficient the code you write is. It is not necessary to understand the complexities of algorithms, data structures, profiling, or benchmarking. It is only important to write code as fast as possible that does the job because CPU time is less expensive.

In my opinion, it is much better to teach someone to think for themself in determining when and where to spend their time (optimizing or not) than to give them more dogma to follow blindly and mantras to chant to bring more into the fold.

Cheers - L~R

Update: s/sloppy/inefficient/ as sloppy has meanings other than I intended. I asked in the CB if the tone of this message seemed inflamatory, which was not my intention. A couple said no and one said yes. I apologize if this is offensive.

Replies are listed 'Best First'.
Re^2: CPU cycles DO NOT MATTER!
by sasdrtx (Friar) on Apr 17, 2008 at 17:11 UTC
    Right on... using an O2 algorithm when a well-known log O algorithm is available on serious amounts of data can easily make CPU cycles matter. However, that could be construed as just knowing what you're doing.

    As Donald Knuth said (paraphrasing Hoare),

    "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."

    So, dragonchild is mostly correct.

    sas
Re^2: CPU cycles DO NOT MATTER!
by dragonchild (Archbishop) on Apr 17, 2008 at 15:57 UTC
    It does not matter how inefficient the code you write is. It is not necessary to understand the complexities of algorithms, data structures, profiling, or benchmarking. It is only important to write code as fast as possible that does the job because CPU time is less expensive.

    Yes, that is exactly what I'm saying as a rule of thumb.

    My mother-in-law writes small programs in VBA for Word and Excel as well as for Crystal Reports. This is as part of her job as a purchasing agent. Which is more important for her - to write code that runs efficiently enough or for her to understand all the algorithms that we, as professional developers, need to know? I would argue that she just needs to do her job. If the code she writes would strike one of us blind, but it runs fast enough on the machines she is given, then what's wrong with that?

    The idea that code needs to be perfect is, itself, dogma. We, as the professionals, need to remember that the majority of all code is now not written by a professional programmer nor is it being written in an enterprise-grade language. It's being written in VBA, Lotus's macro language, and similar tools by business analysts, bankers, and stay-at-home moms. For them, algorithms would just get in the way.

    Why is this important for us? Well, I know that roughly half of all my work tends to be stuff that can take 10x as long to run and still be fine. For that stuff, runtime efficiency is inefficient.


    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?
      dragonchild,
      Hrm - let me try again then.

      It never matters how inefficient the code anyone writes is. It is never necessary to understand the complexities of algorithms, data structures, profiling, or benchmarking. All anyone needs to do is write code as fast as possible that functions correctly. It is never important to ensure your code scales because CPUs are getting faster than everyone's data is getting larger.

      I have already agreed with your sentiment and am not arguing that you are wrong. I am pointing out that what you have said may not come across as a rule of thumb to everyone. In fact, the way you have bolded it, upper cased it, and followed it with an exclamation point - you have made it seem like there is no room for discussion. If you take your argument to one possible logical conclusion, it becomes ridiculous.

      "You're using Perl because it's at that sweet spot between simple and expressive

      That is a bad starting assumption. Why don't you come hang out in #perl on freenode some night. There is no end to the number of people using perl (and PHP) because they do not seem to be competent enough to learn any other language. The task at hand may already be borderline at best for being done in perl. Throw in inexperience and lack of knowledge and it will never accomplish the goal - no matter how long you let the CPU spin.

      Cheers - L~R

        Never use absolutes, my friend. Never ever. :-)

        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?
        "There is no end to the number of people using perl (and PHP) because they do not seem to be competent enough to learn any other language."

        Hey! I resemble that remark.

        You brought up the point I wanted to address, though. The original post assumes that you know every programming language and they're all available for the project, but you chose Perl. I could theoretically program a CGI script in assembly, but 1: I don't know assembly, and 2: It'd be a little difficult to find a host that allows it.

      Unfortunately, this “rule of thumb” of yours only applies when the task in question is on-the-order-of what your mother-in-law (i.e. a human being) deals with.

      The fundamental fallacy of your argument rests in the fact that nearly all of the “hard” problems that a business-oriented computer must deal with are I/O-bound, not CPU-bound. Therefore, the justification that “CPU time is less expensive” becomes entirely specious since “the CPU” is barely even used.

      The ruling constraint (to the hardware) is ... always is ... I/O and nothing else. Any strategy must necessarily focus upon the reasonably-efficient utilization of that resource, at least insofar as the entire computer-system is concerned.

      The goal therefore must be to devote “only a reasonable amount of frighteningly-expensive human time” toward a strategy that efficiently avoids the hardware-constraint of I/O, even at the expense of (generally quite throw-away...) CPU resources.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others perusing the Monastery: (8)
As of 2024-03-28 12:20 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found