Optimiser question

[Dave S]

Hi All,
I have been given some code to wok on. It relies heavily on the
optimiser to run at the correct speed. With this in mind I have been
loking through it to see if I can help it out a bit. I have limitied
knowledge of how compilers works, but I understand that some
constructs optimise easier / better. We are using a variant of gcc
(3.4.1 I think) on Nios II platform, if that makes a difference.
The question I have is are these 2 snippets functionally the same( I
think they are), and would the optimiser prefer the second one:
First snippet, as it is now:

while(count-->0)
{
*pDest++=nPatte rn;
}

how I propose to 'improve' the code:

while(count>0)
{
*pDest=nPattern ;
++pDest;
--count;
}

There are numerous bits a bit like this, so this would probably be a
big help overall if I am correct.

cheers

Dave

[Johannes Bauer]

Dave S schrieb:

The question I have is are these 2 snippets functionally the same( I
think they are), and would the optimiser prefer the second one:

Seriously, why don't you just try it out? Compile both pieces of code,
do an objdump -d on them as take a look at the assembly output. Nobody
but you will be able to give you a precise answer considering that
you're using unusual-platform-3.4.1-i-think-gcc as a compiler.

Greetings,
Johannes

--
"Viele der Theorien der Mathematiker sind falsch und klar
Gotteslästerli ch. Ich vermute, dass diese falschen Theorien genau
deshalb so geliebt werden." -- Prophet und Visionär Hans Joss aka
HJP in de.sci.mathemat ik <47************ **********@news .sunrise.ch>

[Mark Bluemel]

Dave S wrote:

Hi All,
I have been given some code to wok on. It relies heavily on the
optimiser to run at the correct speed. With this in mind I have been
loking through it to see if I can help it out a bit. I have limitied
knowledge of how compilers works, but I understand that some
constructs optimise easier / better. We are using a variant of gcc
(3.4.1 I think) on Nios II platform, if that makes a difference.
The question I have is are these 2 snippets functionally the same( I
think they are), and would the optimiser prefer the second one:
First snippet, as it is now:

while(count-->0)
{
*pDest++=nPatte rn;
}

how I propose to 'improve' the code:

while(count>0)
{
*pDest=nPattern ;
++pDest;
--count;
}

The two ways you could investigate this are
a) measuring
or
b) examining the generated code

I'm no expert, but I doubt that you will find that such simple changes
would reap significant benefits.

In general, I would suspect you'd be better off looking at
a) using a higher optimisation level on the compiler
b) seeing if a recent compiler build has better optimisation
c) looking at your algorithms (rather than your code)

[Chris Dollin]

Dave S wrote:

Hi All,
I have been given some code to wok on. It relies heavily on the
optimiser to run at the correct speed. With this in mind I have been
loking through it to see if I can help it out a bit. I have limitied
knowledge of how compilers works, but I understand that some
constructs optimise easier / better. We are using a variant of gcc
(3.4.1 I think) on Nios II platform, if that makes a difference.
The question I have is are these 2 snippets functionally the same( I
think they are), and would the optimiser prefer the second one:
First snippet, as it is now:

while(count-->0)
{
*pDest++=nPatte rn;
}

how I propose to 'improve' the code:

while(count>0)
{
*pDest=nPattern ;
++pDest;
--count;
}

The first snippet is more idiomatically C and so no less likely to
be optimised than the second.

If the program isn't running fast enough, and you wish to make it
go faster, the first thing you /must/ do is /find out where the
time goes/. For the gods sake don't just trawl through the program
looking for bits you think you can help with: /find out/ which bits
are eating the time using whatever profiling tools the platform
has available. Finding out which are the slow bits and doing an
/algorithmic/ improvement will get much better results. Even just
finding the slow bits and improving the code will help.

You don't say what the program does, so it's hard to guess what
might be cycle-sinks, but if it does any string-hacking, remember
that `strlen` and `strcat` (as examples) are not constant-time
operations ...

--
Chris "who knows where the time goes?" Dollin

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

[Ben Bacarisse]

Dave S <da************ *@bem.fki-et.comwrites:

I have been given some code to wok on. It relies heavily on the
optimiser to run at the correct speed. With this in mind I have been
loking through it to see if I can help it out a bit. I have limitied
knowledge of how compilers works, but I understand that some
constructs optimise easier / better. We are using a variant of gcc
(3.4.1 I think) on Nios II platform, if that makes a difference.
The question I have is are these 2 snippets functionally the same( I
think they are),

No. See below.

and would the optimiser prefer the second one:

I can't see why, but there are real compiler experts here how may know
better.

First snippet, as it is now:

while(count-->0)
{
*pDest++=nPatte rn;
}

how I propose to 'improve' the code:

while(count>0)
{
*pDest=nPattern ;
++pDest;
--count;
}

The original decrements 'count' even when the condition is false so they
terminate with different values in 'count'.

If 'sizeof *pDest' == 1 (i.e. if 'pDest' it is some form of 'char *')
consider using memset.

--
Ben.

[Dave S]

On Dec 13, 3:01 pm, Chris Dollin <chris.dol...@h p.comwrote:

Dave S wrote:

Hi All,
I have been given some code to wok on. It relies heavily on the
optimiser to run at the correct speed. With this in mind I have been
loking through it to see if I can help it out a bit. I have limitied
knowledge of how compilers works, but I understand that some
constructs optimise easier / better. We are using a variant of gcc
(3.4.1 I think) on Nios II platform, if that makes a difference.
The question I have is are these 2 snippets functionally the same( I
think they are), and would the optimiser prefer the second one:
First snippet, as it is now:

while(count-->0)
{
*pDest++=nPatte rn;
}

how I propose to 'improve' the code:

while(count>0)
{
*pDest=nPattern ;
++pDest;
--count;
}

The first snippet is more idiomatically C and so no less likely to
be optimised than the second.

If the program isn't running fast enough, and you wish to make it
go faster, the first thing you /must/ do is /find out where the
time goes/. For the gods sake don't just trawl through the program
looking for bits you think you can help with: /find out/ which bits
are eating the time using whatever profiling tools the platform
has available. Finding out which are the slow bits and doing an
/algorithmic/ improvement will get much better results. Even just
finding the slow bits and improving the code will help.

You don't say what the program does, so it's hard to guess what
might be cycle-sinks, but if it does any string-hacking, remember
that `strlen` and `strcat` (as examples) are not constant-time
operations ...

--
Chris "who knows where the time goes?" Dollin

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England- Hide quoted text -

- Show quoted text -

Thanks all,
The code is used for embedded real time control. It runs fast enough,
but only with the compiler optimisations turned up to maximum and no
debug info (although I dont think debug info and optimisations mix
anyway?). The algorithms have already been tweaked,and the
hardware(FPGA) is also similarly optimised. Im at a slight loose end
whilst I wait for the finalised target hardware (actual circuit
board), so I thought I would go and 'tidy up' and see if I could help
the compiler out any. The tidy up was provoked by an article in the
IET Electronics magazine where ++i is esier to optimise than i++ due
to the need to store i and then increment it. (think I got that
correct). As I dont know really how optimsers work I thought Id ask
the question.

cheers
Dave

[Dave S]

On Dec 13, 3:11 pm, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

Dave S <david.sander.. [e-mail]:

I have been given some code to wok on. It relies heavily on the
optimiser to run at the correct speed. With this in mind I have been
loking through it to see if I can help it out a bit. I have limitied
knowledge of how compilers works, but I understand that some
constructs optimise easier / better. We are using a variant of gcc
(3.4.1 I think) on Nios II platform, if that makes a difference.
The question I have is are these 2 snippets functionally the same( I
think they are),

No. See below.

and would the optimiser prefer the second one:

I can't see why, but there are real compiler experts here how may know
better.

First snippet, as it is now:

while(count-->0)
{
*pDest++=nPatte rn;
}

how I propose to 'improve' the code:

while(count>0)
{
*pDest=nPattern ;
++pDest;
--count;
}

The original decrements 'count' even when the condition is false so they
terminate with different values in 'count'.

Yes, in this instance it makes no odds, but in another it could.

If 'sizeof *pDest' == 1 (i.e. if 'pDest' it is some form of 'char *')
consider using memset.

I might normally use a bzero or similar, but this is a set of
structures and pointers to structures.

Dave

[Chris Dollin]

Dave S wrote:

Thanks all,
The code is used for embedded real time control. It runs fast enough,
but only with the compiler optimisations turned up to maximum and no
debug info (although I dont think debug info and optimisations mix
anyway?). The algorithms have already been tweaked,and the
hardware(FPGA) is also similarly optimised.

You need measurements (and, perhaps, well-grounded estimates) to find
out what's taking the time. Really. Otherwise you're just whistling
in the dark. If performance is important to you, some investment in
measurement seems worthwhile.

If you can't instrument the embedded application, is it /possible/ to
compile on say an x86 desktop and use that platform's profiling tools
to get an idea of where to look? Clearly you'd have to fake out the
FPGA stuff, and that might make a nonsense of the results; I don't do
embedded, so I don't have a feel for it, but some here do and might
be able to advise.

The tidy up was provoked by an article in the
IET Electronics magazine where ++i is esier to optimise than i++ due
to the need to store i and then increment it.

It may be "easier" to optimise, but that doesn't matter; C compilers
that can't generate the "best" output just because you've used `i++`
rather than `++i` have learned nothing from the past twenty years.

[In C++, where `i` might be some big class instance, I understand that
it can make rather more difference. But in C? Unlikely. Not impossible;
just unlikely, given that you're using a gcc variant.]

--
Chris "i += 1" Dollin

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[Philip Potter]

Dave S wrote:

The tidy up was provoked by an article in the
IET Electronics magazine where ++i is esier to optimise than i++ due
to the need to store i and then increment it. (think I got that
correct).

This is often said, but mainly by people who are talking about C++, and
even then only when i is a class type rather than a POD (plain old
data). If i is an int, then i++; and ++i; are equivalent statements, and
any compiler worth its salt knows this.

Your compiler may not know this optimization, but unless you can prove
that it doesn't, I will assume that it does. Similarly for any other
common peephole optimization trick.

[Ben Bacarisse]

Dave S <da************ *@bem.fki-et.comwrites:

On Dec 13, 3:11 pm, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

>Dave S <david.sander.. [e-mail]:

I have been given some code to wok on. It relies heavily on the
optimiser to run at the correct speed.

<snip>

First snippet, as it is now:

while(count-->0)
{
*pDest++=nPatte rn;
}

how I propose to 'improve' the code:

while(count>0)
{
*pDest=nPattern ;
++pDest;
--count;
}

<snip>

I might normally use a bzero or similar, but this is a set of
structures and pointers to structures.

Then you might consider Duff's device:

http://www.lysator.liu.se/c/duffs-device.html

(view on an empty stomach if it is new to you) but, as always, measure
before investing any effort in tricksy code changes.

--
Ben.