Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re: CPU cycles DO NOT MATTER!

by swampyankee (Parson)
on Apr 17, 2008 at 16:44 UTC ( #681234=note: print w/replies, xml ) Need Help??


in reply to 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. Interestingly, these are largely written by people whose college diplomas have words like "physics" or "aerospace engineering" on them, and are in application domains such as numerical relativity, n-body problems where n>>106, computational fluid mechanics, 4d climate models, etc, where the problems have to be radically simplified to run on teraflop machines.

But, yes, for the vast bulk of applications, it is foolish to shave a few CPU cycles.


Information about American English usage here and here. Floating point issues? Please read this before posting. — emc

Replies are listed 'Best First'.
Re^2: CPU cycles DO NOT MATTER!
by Joost (Canon) on Apr 19, 2008 at 21:43 UTC
    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.

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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (1)
As of 2021-06-19 11:54 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What does the "s" stand for in "perls"? (Whence perls)












    Results (92 votes). Check out past polls.

    Notices?