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]

Re: exectution speed and debugging output

Giff wrote:

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]

Re: exectution speed and debugging output

On 1 Apr, 16:38, red floyd <no.s...@here.d udewrote:

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

>
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

>

(and the program MUST be fast),

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

Re: exectution speed and debugging output

"Giff" <Giffnews@gmail .comwrote in message
news:1175435322 .703690.217010@ e65g2000hsc.goo glegroups.com.. .

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,[b]
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.

I'm happy to learn :)
>

[James Kanze]

Re: exectution speed and debugging output

On Apr 1, 3:48 pm, "Giff" <Giffn...@gmail .comwrote:

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.

--
James Kanze (Gabi Software) email: james.kanze@gma il.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[Giff]

Re: exectution speed and debugging output

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]

Re: exectution speed and debugging output

Jim Langston ha scritto:

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

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

[Giff]

Re: exectution speed and debugging output


Giff wrote:

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

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

[Scott McPhillips [MVP]]

Re: exectution speed and debugging output

Giff wrote:

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

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.

--
Scott McPhillips [VC++ MVP]

[Jim Langston]

Re: exectution speed and debugging output

"Giff" <giffnews@gmail .com.invalidwro te in message
news:eup1li$s98 $1@aioe.org...

Jim Langston ha scritto:
>

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

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

JGT Jump if Greater Than

[Mike Wahler]

Re: exectution speed and debugging output


"Giff" <giffnews@gmail .com.invalidwro te in message
news:eup1li$s98 $1@aioe.org...

Jim Langston ha scritto:
>

>>
>if ( a b )
>>
>it would only be 3 assemtly instructions or so, something like:
>>
>MOV AX,[a]
>MOV BX,[b]
>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]

Re: exectution speed and debugging output

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]

Re: exectution speed and debugging output

Jim Langston ha scritto:

>
JGT Jump if Greater Than

thanks

[peter koch]

Re: exectution speed and debugging output

On 1 Apr., 22:12, "Mike Wahler" <mkwah...@mkwah ler.netwrote:

"Giff" <giffn...@gmail .com.invalidwro te in message
>
news:eup1li$s98 $1@aioe.org...
>

Jim Langston ha scritto:

>

if ( a b )

>

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

>

MOV AX,[a]
MOV BX,[b]
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,[b]
JGT [someaddress]

(but this is off-topic)

/Peter

[James Kanze]

Re: exectution speed and debugging output

On Apr 1, 9:35 pm, Giff <giffn...@gmail .com.invalidwro te:

James Kanze ha scritto:

[...]

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?

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

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.

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 (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34