Announcement

Collapse
No announcement yet.

Speed of code

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Michael Mattias
    replied
    I'm saying what I often say....

    When one asks a "What happens if...?" question, the absolute best way to get an answer is to try it; especially when it's as rudimentary a thing as this.


    MCM



    [This message has been edited by Michael Mattias (edited May 12, 2004).]

    Leave a comment:


  • Davide Vecchi
    replied
    This is not a "contribution" so i was not lying .
    There is no such thing as GLOBAL in PB/DOS
    There is; the statement is PUBLIC and it creates globals.

    Change the $OPTIMIZE compiler directive whilst working to see what effect that has.
    I guess it has no effect until one recompiles the code. So, what is this supposed to mean ?

    Lots of work?
    Speak for yourself.

    Bye.

    ------------------
    Davide Vecchi
    [email protected]

    Leave a comment:


  • Michael Mattias
    replied
    take a look at:

    http://www.powerbasic.com/support/pb...ad.php?t=20742

    this "telco challenge" is language-and-compiler agnostic.

    why don't you write a solution for this using pb-dos, post it in the source code forum, and ask for others the comment upon and/or improve?

    better still, write one version using shared (there is no such thing as global in pb/dos) variables, and another with no shared variables; and maybe one with calls to procedures, and one with mostly in-line code?

    change the $optimize compiler directive whilst working to see what effect that has.

    lots of work? welcome to the real world.

    mcm

    Leave a comment:


  • Davide Vecchi
    replied
    Tom, i'm not sure about what triggered your sarcasm here, but i'm sure you could spare it for situations where it is more appropriate. However it's clear that this thread has taken a route that leads nowhere, so this is my last "contribution" to it, just to repeat what i'm saying.

    Automatically optimizing source code is of marginal value
    Automatically optimizing source code is not of marginal value. It depends. Every situation is different and "often" doesn't mean "always". Make a SUB with a tenth of locals and 4-5 passed params, write some math statements in it and call it 10,000,000 times. Of course you can always call this a dubious design choice, however this would mean that it was a bad choice to make a procedure out of an often-repeated block of code.

    The compiler has no way of knowing which parts of your code are important to optimize, or whether you're most concerned with size, possible best speed, or most even latency, on what OSes and with what related software and hardware
    Why should the compiler know that ? Who ever said or just implied that the compiler should do these optimizations ? (except those that it already does by knowing - through the $OPTIMIZE metastatement - whether i'm most concerned with size or speed).

    The best optimizer may be found somewhere between your ears.
    Good one! (But you should confess, you copied it ).

    ------------------
    Davide Vecchi
    [email protected]

    [This message has been edited by Davide Vecchi (edited May 12, 2004).]

    Leave a comment:


  • Tom Hanlin
    replied
    Automatically optimizing source code is of marginal value. The compiler
    has no way of knowing which parts of your code are important to optimize,
    or whether you're most concerned with size, possible best speed, or most
    even latency, on what OSes and with what related software and hardware.

    The best optimizer may be found somewhere between your ears. If it is not
    working to your satisfaction, you will be pleased to know that it may be
    upgraded almost indefinitely through study and practice.

    As far as the overhead of parameter passing is concerned, the overhead is
    still negligible, unless you've made dubious design choices.

    ------------------
    Tom Hanlin
    PowerBASIC Staff

    Leave a comment:


  • Davide Vecchi
    replied
    Sorry, i'm not able to follow you much anymore, especially the very first sentence of your post. I have problems in understanding how to connect your post with mine.

    It is your responsibility as the programmer to balance the competing requirements for performance, maintainability and resource requirements.
    So ? I was simply saying that IMO globals + calls is a more balanced solution than inlining the calls.

    Calling procedures enhances maintainability. The cost is performance. Resources are a wash.
    Inlining enhances performance. The cost is maintainability. Resources are a wash.
    So ? These two possibilities are real, but does this mean that there can't be further ones ? Like calling procedures that use globals so they don't set up any local at each call ?

    Bottom Line: There's no such thing as a free lunch.
    Which free lunch are you talking about ? What are you referring to ? To using globals instead of manually inlining ?

    There was no "click here to optimize your design and source code" button. That took real effort.
    So ?
    BTW, i don't know what "automatically optimizing design" means, but "automatically optimizing source code" is very possible and IMO a very clever practice in time critical applications to preserve code maintainability.

    ------------------
    Davide Vecchi
    [email protected]

    Leave a comment:


  • Michael Mattias
    replied
    >manual inlining is a strange idea if you are concerned about code maintenance

    well, not if performance is an "issue" it isn't.

    it is your responsibility as the programmer to balance the competing requirements for performance, maintainability and resource requirements.

    calling procedures enhances maintainability. the cost is performance. resources are a wash.

    inlining enhances performance. the cost is maintainability. resources are a wash.

    bottom line: there's no such thing as a free lunch.

    here's a recent post of mine on performance tuning:
    http://www.powerbasic.com/support/pb...ad.php?t=20652

    there was no "click here to optimize your design and source code" button. that took real effort. the code is also now less maintainable. my decision, i have to live with it.

    ymmv.


    mcm


    [this message has been edited by michael mattias (edited may 11, 2004).]

    Leave a comment:


  • Davide Vecchi
    replied
    Then it should be equally obvious one can avoid the stack setup by coding in-line rather than calling another procedure.
    In fact it is, but how does this come in the discussion ?
    Anyway, what if a procedure with 20 local vars and 5 passed parameters is called from 10 different places ? Manual inlining is a strange idea if you are concerned about code maintenance. A bunch of globals replacing the locals of that procedure looks like a much better solution to me.

    ------------------
    Davide Vecchi
    [email protected]

    [This message has been edited by Davide Vecchi (edited May 11, 2004).]

    Leave a comment:


  • Michael Mattias
    replied
    >The stack setup required to push the local onto the stack is required exactely because of the scope. Sorry if i didn't mention the whole trip, i thought it was obvious.

    Then it should be equally obvious one can avoid the stack setup by coding in-line rather than calling another procedure.

    It's not the paintbrush, it's the artist.

    MCM


    Leave a comment:


  • Davide Vecchi
    replied
    Originally posted by Tom Hanlin:Oh, never mind.
    Ok .

    ------------------
    Davide Vecchi
    [email protected]

    Leave a comment:


  • Tom Hanlin
    replied
    The speed difference is negligible, unless you're calling an awful lot
    of one-line...

    Oh, never mind.

    ------------------
    Tom Hanlin
    PowerBASIC Staff

    Leave a comment:


  • Davide Vecchi
    replied
    The stack setup required to push the local onto the stack is required exactely because of the scope. Sorry if i didn't mention the whole trip, i thought it was obvious.
    BTW the speed difference isn't necessarily minuscle, it might be very significant, which i think is one of the reasons why PB implemented macros in the Windows compilers.

    ------------------
    Davide Vecchi
    [email protected]

    Leave a comment:


  • Michael Mattias
    replied
    Variable scope per se has precisely zero effect on speed.

    The minisucle performance difference one <U>might</U> encounter using a LOCAL versus a GLOBAL variable results purely from the stack setup required to push the local onto the stack for use by a receiving function.


    Leave a comment:


  • Davide Vecchi
    replied
    Originally posted by Michael Mattias:
    Better to select your variable scope based on application and maintenance concerns.
    ... and execution speed, which is an aspect that definitely can be affected by vars scoping and that the real user often considers important.


    ------------------
    Davide Vecchi
    [email protected]

    Leave a comment:


  • Michael Mattias
    replied
    IMNSHO, any performance difference between SHARED (correct terminology for PB/DOS), STATIC and LOCAL variables is not worth thinking about.

    Better to select your variable scope based on application and maintenance concerns.

    YMMV.


    Leave a comment:


  • Tom Hanlin
    replied
    Passing a value as a parameter does involve some overhead but, it's
    negligible, unless you're calling an awful lot of one-line subs and
    functions; in which case, you might want to reconsider the design.

    Asking how global variables rate compared to arrays is like asking
    how yellow vehicles rate compared to cars... please rephrase.

    ------------------
    Tom Hanlin
    PowerBASIC Staff

    Leave a comment:


  • Dan Symonds
    started a topic Speed of code

    Speed of code

    Purely from the standpoint of speed of execution, how do
    global variables rate versus passing of variables into
    functions or procedures. Also, how do global variables rate
    when compared to arrays.

    Thanks
    Dan Symonds


    ------------------
Working...
X