Tips on comparing programming languages' performance

[Thaddy]

At least C is sane in that it does not allow it.

You probably haven't used GCC much then.

The C99 standard does allow it, for sure

[munair]

In a language that doesn't support nested functions/procedures, the programmer has to wonder for every function/procedure where it is used.  Programs like that are not programs, they are jigsaw puzzles.

That is not true, especially with objects these days, even simple ones, programs can be highly structured. Not in 35 years have I ever used nested procedures, not once! Why? Because such a hidden procedure might do something that will later be copied by another procedure because the programmer/maintainer is completely oblivious of its presence, whereas procedures limited to module level give an excellent overview of all of a program's building blocks.

[Thaddy]

the programmers at MS implemented more capable optimizing algorithms (in that specific area) than did the programmers who implemented g++.

No they take more risks... msvc is notorious for having uncertain optimizations enabled as default.
FreePascal's compiler avoids uncertain optimizations and is extremely conservative with its defaults.

Anyway we broadly agree, except you still mention languages in the context of speed, which is wrong.

[440bx]

That is not true, especially with object, even simple ones, programs can be highly structured. Not in 35 years have I ever used nested procedures, not once! Why? Because such a hidden procedure might do something that will later be copied by another procedure because the programmer/maintainer is completely oblivious of its presence, whereas procedures limited to module level give an excellent overview of all of a program's building blocks.

That is terrible!.

... such a hidden procedure...

The procedure isn't "hidden".  Its location makes it clear that it is used in only _one_ place.  Something which is very desirable to know when looking at source code.

... because the programmer/maintainer is completely oblivious of its presence,...

I must be a demanding person... I fully _expect_ the programmer to read the code before he/she puts his $0.05 (that's 5 lines of code) in there.  If the programmer is oblivious of the function/procedure then, he/she, has not performed their job to the lowest acceptable standards of performance.

... whereas procedures limited to module level give an excellent overview of all of a program's building blocks.

OOP is just a very deficient way of replicating the locality of nested functions and procedures.  The methods in a class/object are simply nested functions/procedures in a non-OOP program.

Not in 35 years have I ever used nested procedures, not once!

The good news is.. .it's not too late... it's never too late to learn to do it right


ETA:

No they take more risks... msvc is notorious for having uncertain optimizations enabled as default.

Not true.  You have to enable optimizations for MSVC to eliminate empty loops.  The same is true of other optimizations.

FreePascal's compiler avoids uncertain optimizations and is extremely conservative with its defaults.

Nice sugar coating there but, I do believe you are correct when stating that FPC is conservative.

... except you still mention languages in the context of speed, which is wrong.

Yes, I do because the grammar makes a _big_ difference.  Here is another example: if the language does not support pointers, the optimizer doesn't have to worry that a pointer may be aliasing some variable that is the target of its optimization algorithm.  That's a very common source of problems when doing optimizations.

[marcov]

I wonder if GCC implements optimizations to simplify/flatten nested procedures. Optimize both as a whole I mean, not optimizing the outer and the inner independent of each other.

Nested functions can be a blessing if access to a global variable is relatively complex, e.g. in segmented memory models with multiple static data segments.

Then nesting function saves on global variables, and the access via frames is offset by the need to load the right static data segment first (and the preserving of the old value etc, though usually that is only needed for e.g. lodsb)

If you didn't have multiple static data segments it was even worse, since you wanted to avoid excess state in global variables at any cost since you only had 64kb.


I still use nested procedures, every time I need to factor a small part out that accesses relatively many variables, e.g. because it is needed twice.

[munair]

The procedure isn't "hidden".  It's location makes it clear that it is used in only _one_ place.  Something which is very desirable to know when looking at source code.
[..]
I must be a demanding person... I fully _expect_ the programmer to read the code before he/she puts his $0.05 (that's 5 lines of code) in there.  If the programmer is oblivious of the function/procedure then, he/she, has not performed their job to the lowest acceptable standards of performance.

Your reasoning goes against your own argument that:

In a language that doesn't support nested functions/procedures, the programmer has to wonder for every function/procedure where it is used.  Programs like that are not programs, they are jigsaw puzzles.

which, as I pointed out, is not a valid reason, not even an excuse.

The good news is.. .it's not too late... it's never too late to learn to do it right

There is no such thing as 'doing it right'. Programming techniques are largely a matter of preference.

[440bx]

Your reasoning goes against your own argument that:

It doesn't.  A function/procedure that is nested means it is exclusively used in that scope and nowhere else.  (though I think FPC has a mechanism to call such functions/procedures through pointers - I'm not sure, I would _never_ do something like that.)

There is no such thing as 'doing it right'. Programming techniques are largely a matter of preference.

And spaghetti code is a programming technique too.  A program isn't supposed to be a jumbled bag of functions and procedures.  It's supposed to be organized, not scattered all over the place.

Every time I read a C program, I can't help thinking... 2 pounds of parentheses... 1.5 pounds of asterisks... 14oz of commas... random sprinklings of # ... shake (don't stir) and, my name is C, K&R C.  wonderful !!.

[munair]

This argument:

the programmer has to wonder for every function/procedure where it is used

goes against this argument:

I fully _expect_ the programmer to read the code

... which has nothing to do with the advantage/disadvantage of certain techniques.

The only reason to nest a procedure is when it is used only once in a project (which in most of my projects doesn't happen often) and even then there are ways to make the association obvious, e.g. using obvious naming.

Well organized code with procedures at the module level is by no means spaghetti. You make it sound like procedures are similar to the goto-statement to stress the importance / necessity of nested procedure support, which in my opinion is greatly exaggerated.

[munair]

... except you still mention languages in the context of speed, which is wrong.

Yes, I do because the grammar makes a _big_ difference.  Here is another example: if the language does not support pointers, the optimizer doesn't have to worry that a pointer may be aliasing some variable that is the target of its optimization algorithm.  That's a very common source of problems when doing optimizations.

I agree with Thaddy that grammar has little influence on a compiler's ability to generate/optimize code. Much more important is how the compiler itself is structured, which allows/disallows it to see the wider context of specific code targeted for optimization.

[440bx]

This argument:

the programmer has to wonder for every function/procedure where it is used

goes against this argument:

I fully _expect_ the programmer to read the code

There is no contradiction there.  If the function/procedure is _not_ nested then the programmer - who is supposed to read the source program - has to _count_ and _remember_ if each and every function is called once or more.   If the function/procedure is nested, it's obvious it is invoked in only one place and it is also obvious which function/procedure uses it. 

... which has nothing to do with the advantage/disadvantage of certain techniques.

It does because, some programming "techniques" burden the programmer with having to remember details a programmer shouldn't have to. 

The only reason to nest a procedure is when it is used only once in a project (which in most of my projects doesn't happen often) and even then there are ways to make the association obvious, e.g. using obvious naming.

That's not the only reason.  A good reason, one that should be used as often as possible, is to group statements into functions/procedures so that the group of statements can be given a name that reflects its purpose.  It is also an excellent method of having a function/procedure "mainline" that reads like pseudo-code because all the code sequences are logically grouped and appropriately named.

Well organized code with procedures at the module level is by no means spaghetti. You make it sound like procedures are similar to the goto-statement to stress the importance / necessity of nested procedure support, which in my opinion is greatly exaggerated.

The essence of spaghetti code is not being able to easily determine what causes the code to be executed.  A program that is just a large bag of functions/procedures without any evident/obvious execution connections between them is spaghetti code.  Bagging code into functions/procedures does not avoid the essential spaghetti code problem.

When functions/procedures are nested into the function/procedure that uses them, where they are used is _obvious_ and how/when they are used is, more often than not, easily established by inspecting the mainline of the root function.

ETA:

I agree with Thaddy that grammar has little influence on a compiler's ability to generate/optimize code. Much more important is how the compiler itself is structured, which allows/disallows it to see the wider context of specific code targeted for optimization.

In that case, I disagree with you both.

[munair]

If the function/procedure is _not_ nested then the programmer - who is supposed to read the source program - has to _count_ and _remember_ if each and every function is called once or more.

You still haven't convinced me. The compiler can easily do that job and even hint if certain identifiers are not used.

Going by my own experience, after one or two years it usually takes me a bit of time to figure out what exactly certain parts of the code do. Heavy commenting helps a lot and I make much use of that just to remind myself later on what task is performed and why. I even comment to certain code where it is used, as this actual example demonstrates:

Code: Text  [Select][+][-]

1.   // expression identifier tracker
2.   eitr            as titr
3.  
4.   // preserved values after evaluation (see -> eval_result)
5.   eitrv           as titrv

I stand by my claim that there is no good reason to implement support for nested procedures. The complexity outweighs the gained advantage by leaps and bounds.

[440bx]

You still haven't convinced me. The compiler can easily do that job and even hint if certain identifiers are not used.

Yes, the compiler can easily do that job _but_ when it is _you_ who has to maintain or add features to a program then _you_ have to keep track of when and where functions/procedures are called.  It's much simpler and much easier when the function/procedure is nested because then you _know_ for a fact that it is used in _only_ that function/procedure.

Going by my own experience, after one or two years it usually takes me a bit of time to figure out what exactly certain parts of the code do.

And time is the point.  How much _time_ does the programmer have to dedicate to visualize the logical structure of the program.  When functions/procedures are nested in the functions/procedures that use them, it's not just easy, it is trivial and basically instantaneous.

Heavy commenting helps a lot and I make much use of that just to remind myself later on what task is performed and why.

Heavy commenting is always a good thing _but_ comments have a way of going stale.  After some changes to the code due to bug fixes or addition of features, the comments may no longer be correct.  Comments are good but, it is wise to ensure they _still_ accurately reflect what the code actually does.  Structure is fact, comments are programmer wishes.

[marcov]

Your reasoning goes against your own argument that:

It doesn't.  A function/procedure that is nested means it is exclusively used in that scope and nowhere else.  (though I think FPC has a mechanism to call such functions/procedures through pointers - I'm not sure, I would _never_ do something like that.)

In TP mode it is done in a very few places (in objects unit + fv mostly), and this is mostly a hack.

In ISO and macpas mode it is simply allowed and the procedures are afaik double pointers like method pointers (one pointer frameptr, one address of the procedure). Of course it can only be legally called while the original frame is still in scope.

Mostly used for visitor "foreach" like patterns on collections etc.

Afaik you can pass global functions to functions declared with such procvar (... is nested, just like .. of object for methods), the frameptr will then be nil.

[marcov]

(From two separate messages):

There is no such thing as 'doing it right'. Programming techniques are largely a matter of preference.

I stand by my claim that there is no good reason to implement support for nested procedures. The complexity outweighs the gained advantage by leaps and bounds.

The weighing here is obviously a matter of preference 

[munair]

It's much simpler and much easier when the function/procedure is nested because then you _know_ for a fact that it is used in _only_ that function/procedure.

There is really nothing to be gained from that knowledge, because it is non-essential how often a procedure is used, not counting recursion of course. This is primarily about code aesthetics and programmer preference. From a machine language point of view, higher language structuring is often being elevated to a form of art that overshoots its primary goal.

In addition, the more complex a compiler becomes, the harder it will be to maintain and extend it without introducing bugs.