exectution speed and debugging output

[Giff]

Hi again,

I need a suggestion.

Right now I am developing an application and I want to be able to
output on screen some variables. Anyway, I want to remove these output
operations when passing on the implementation of another function or
finiship up the program etc.. Still I whish to be able to have the
output again in case I will need to do some debugging in the future
(very likely!).

Now I pass to each function a bool parameter "show" and then, inside
the function:

if(show) output some stuff.

I suppose that this if-statement slows down the code a lot (and the
program MUST be fast), for instance because the compiler cannot
optimize not knowing the value of the show flag at runtime. Is that
correct?

What is the best way then to have this control over debugging output?
Should I use the preprocessor with a #define and then #ifdef /
#ifndef?

I'm happy to learn

 

[red floyd]

Hi again,

[redacted]

Now I pass to each function a bool parameter "show" and then, inside
the function:

if(show) output some stuff.

I suppose that this if-statement slows down the code a lot

Why do you suppose this? Have you benchmarked and profiled?

(and the program MUST be fast),

Why? What are your requirements? Have you benchmarked and tested to
see if you meet your requirements?

Hoare's Law (also attributed to Knuth): "Premature optimization is the
root of all evil".

 

[Giff]

Why do you suppose this?

well I thought that whenever there is an if, the compiler will have a
bit harder life to optimize the code

Have you benchmarked and profiled?
No


Why? What are your requirements?

interactivity


Have you benchmarked and tested to

see if you meet your requirements?

I am in the middle of it, too early to check.

Hoare's Law (also attributed to Knuth): "Premature optimization is the
root of all evil".

Well I think "premature" is quite a flexible word, maybe it is
premature in my case, but consider my question as general.

 

[Jim Langston]

Hi again,

I need a suggestion.

Right now I am developing an application and I want to be able to
output on screen some variables. Anyway, I want to remove these output
operations when passing on the implementation of another function or
finiship up the program etc.. Still I whish to be able to have the
output again in case I will need to do some debugging in the future
(very likely!).

Now I pass to each function a bool parameter "show" and then, inside
the function:

if(show) output some stuff.

I suppose that this if-statement slows down the code a lot (and the
program MUST be fast), for instance because the compiler cannot
optimize not knowing the value of the show flag at runtime. Is that
correct?

I would suspect that the if statment would execute as 2 machine
instructions, something like:

MOV AX, [show]
JNZ AX,[someaddress]

This should execute fairly fast. Even if it was some other type of
comparison,

if ( a > b )

it would only be 3 assemtly instructions or so, something like:

MOV AX,[a]
MOV BX,
JGT [someaddress]

The JGT may be more like
JGT AX,BX,[someaddress]

or something. I haven't looked at assembly language isntructions since the
386 days.

In other words, I wouldn't worry about the execution speed.

What is the best way then to have this control over debugging output?
Should I use the preprocessor with a #define and then #ifdef /
#ifndef?

Some people do that.

 

[James Kanze]

Right now I am developing an application and I want to be able to
output on screen some variables. Anyway, I want to remove these output
operations when passing on the implementation of another function or
finiship up the program etc.. Still I whish to be able to have the
output again in case I will need to do some debugging in the future
(very likely!).

Now I pass to each function a bool parameter "show" and then, inside
the function:

if(show) output some stuff.

This sort of thing is more often handled by a global variable.
(It's one of the rare cases where a global variable is
appropriate.)

I suppose that this if-statement slows down the code a lot (and the
program MUST be fast), for instance because the compiler cannot
optimize not knowing the value of the show flag at runtime. Is that
correct?

No. The difference in speed is hardly noticeable.

What is the best way then to have this control over debugging output?
Should I use the preprocessor with a #define and then #ifdef /
#ifndef?

In general, I find some sort of logging class, invoked via
macros, to be preferable. Historically, I'd try to design the
macros so that they could be replaced with an empty string, if
performance issues required. In practice, they never did, and I
don't worry about it today.

 

[Giff]

James Kanze ha scritto:

This sort of thing is more often handled by a global variable.
(It's one of the rare cases where a global variable is
appropriate.)

That's right.

No. The difference in speed is hardly noticeable.

Ok. My supposition was that with a if statement it would not be possible
to use the pipeline of the processor since the next operation depends by
the current one. Where am I wrong?

In general, I find some sort of logging class, invoked via
macros, to be preferable. Historically, I'd try to design the
macros so that they could be replaced with an empty string, if
performance issues required. In practice, they never did, and I
don't worry about it today.

Thanks for the tips, I however try to not use macros at all.

 

[Giff]

Jim Langston ha scritto:

if ( a > b )

it would only be 3 assemtly instructions or so, something like:

MOV AX,[a]
MOV BX,
JGT [someaddress]

Sorry, my knowledge of assembly is very limited, but where is the
condition checked?

 

[Giff]

Ok. My supposition was that with a if statement it would not be possible
to use the pipeline of the processor since the next operation depends by
the current one. Where am I wrong?

I'll reply to myself: the next operation IS known at compile time!!

 

[Scott McPhillips [MVP]]

Ok. My supposition was that with a if statement it would not be possible
to use the pipeline of the processor since the next operation depends by
the current one. Where am I wrong?

User interactions are required to occur in milliseconds. 'if'
operations occur in nanoseconds. So you're not wrong, only a factor of
a million or so from being relevant.

 

[Jim Langston]

Jim Langston ha scritto:

if ( a > b )

it would only be 3 assemtly instructions or so, something like:

MOV AX,[a]
MOV BX,
JGT [someaddress]

Sorry, my knowledge of assembly is very limited, but where is the
condition checked?

JGT Jump if Greater Than

 

[Mike Wahler]

Jim Langston ha scritto:

if ( a > b )

it would only be 3 assemtly instructions or so, something like:

MOV AX,[a]
MOV BX,
JGT [someaddress]

Sorry, my knowledge of assembly is very limited, but where is the
condition checked?

The 'check' statement is the 'JGT' instruction
(presumably means something like "Jump if Greater than".)

-Mike

 

[Giff]

Scott McPhillips [MVP] ha scritto:

User interactions are required to occur in milliseconds. 'if'
operations occur in nanoseconds. So you're not wrong, only a factor of
a million or so from being relevant.

somehow I thought that that bool would have been set at runtime, but it
isn't, silly me

 

[Giff]

Jim Langston ha scritto:

JGT Jump if Greater Than

thanks

 

[peter koch]

Jim Langston ha scritto:

if ( a > b )
it would only be 3 assemtly instructions or so, something like:
MOV AX,[a]
MOV BX,
JGT [someaddress]

Sorry, my knowledge of assembly is very limited, but where is the
condition checked?

The 'check' statement is the 'JGT' instruction
(presumably means something like "Jump if Greater than".)

-Mike

The problem is the comparison was forgotten. The relevant instruction
is CMP AX,BX.
Probably the code would be implemented soemthing like

MOV AX,[a]
CMP ax,
JGT [someaddress]

(but this is off-topic)

/Peter

 

[James Kanze]

James Kanze ha scritto:

[...]

Ok. My supposition was that with a if statement it would not be possible
to use the pipeline of the processor since the next operation depends by
the current one. Where am I wrong?

Most processors today have some form of branch prediction, and
will avoid flushing the pipeline in the msot frequent case
(where tracing is turned off). Even on an old 8086, the
"pipeline" was only flushed if the jump was taken, and compilers
rearranged the code so that the most frequent (or the fastest)
case didn't take the branch.

(Obviously, when tracing is on, the formatting and output take
several orders of magnitude more time than that lost in loosing
the pipeline.)

Thanks for the tips, I however try to not use macros at all.

Logging is one place where they are almost always the rule.
Amongst other things, you want to get __FILE__ and __LINE__ in
the log, automatically, and you can only do that with a macro.

 

[James Kanze]

Scott McPhillips [MVP] ha scritto:

somehow I thought that that bool would have been set at runtime, but it
isn't, silly me

But it is, normally. Somewhere at the beginning of the program,
you will test if the option -D has been given, or if some
specific environment variable has been set, or in larger
projects, read a configuration file. And it is important that
the condition be relatively rapid if tracing is turned off (and
there is no user output). Relatively---you're still doing a lot
of other things in the code. So, for example, my code can even
support multiple if's in a single trace statement, but it would
not be acceptable to format the complete output into a string,
and just not write it.