On 18 Mar, 02:20, Jack Klein <jackkl...@spam cop.netwrote:
On Mon, 17 Mar 2008 06:24:27 -0700 (PDT), Spiros Bousbouras
<spi...@gmail.c omwrote in comp.lang.c:
>
Has anyone found that declaring variables register affected
speed of execution ? If yes on what hardware and around
which year ?
>
On quite a few embedded architectures, 8 to 32 bit.
>
The last time was this morning.
How do you choose which variables to declare register ?
Is it on a general feel on which gets used the most or
do you keep precise statistics or a different method ?
Is it possible at all that, variables declared to be register located
might confuse the compiler's optimisation methods and actually reduce
the efficiency of the overall code?
On 18 Mar, 02:20, Jack Klein <jackkl...@spam cop.netwrote:
>On Mon, 17 Mar 2008 06:24:27 -0700 (PDT), Spiros Bousbouras
><spi...@gmail. comwrote in comp.lang.c:
>>
Has anyone found that declaring variables register affected
speed of execution ? If yes on what hardware and around
which year ?
>>
>On quite a few embedded architectures, 8 to 32 bit.
>>
>The last time was this morning.
[ ... ]
Is it possible at all that, variables declared to be register located
might confuse the compiler's optimisation methods and actually reduce
the efficiency of the overall code?
It is certainly *possible,* but I would be surprised if any actual
implementation' s optimisers were so affected, since register is mostly
taken as a mild hint and nothing more under most extant
implementations .
>
Is it possible at all that, variables declared to be register located
might confuse the compiler's optimisation methods and actually reduce
the efficiency of the overall code?
>
Nick
register is a hint, not a requirement. So the compiler is free to
ignore it.
You have control over the compiler via its optimization options.
In article <9de5fe72-43ac-4797-a47b-4656475ee4e4@s8 g2000prg.google groups.compolas <nick@helpforce .comwrites:
....
Is it possible at all that, variables declared to be register located
might confuse the compiler's optimisation methods and actually reduce
the efficiency of the overall code?
O, certainly. When the compiler honours the register statement, and you
are putting the least used variables in registers, for instance.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
In article
<9de5fe72-43ac-4797-a47b-4656475ee4e4@s8 g2000prg.google groups.com>
polas <nick@helpforce .comwrites: ...
Is it possible at all that, variables declared to be register
located might confuse the compiler's optimisation methods and
actually reduce the efficiency of the overall code?
>
O, certainly. When the compiler honours the register statement, and
you are putting the least used variables in registers, for instance.
I wonder how much suboptimal register allocation would matter with
modern processors with huge L1 and L2 caches.
Is it possible at all that, variables declared to be register located
might confuse the compiler's optimisation methods and actually reduce
the efficiency of the overall code?
>
It is certainly *possible,* but I would be surprised if any actual
implementation' s optimisers were so affected, since register is mostly
taken as a mild hint and nothing more under most extant
implementations .
Not these days, probably, but it used to be true for some MS-DOS
implementations that you could register the wrong variable and the
compiler would merrily do as you told it.
Has anyone found that declaring variables register affected
speed of execution ? If yes on what hardware and around
which year ?
Yes. It also affected the size of the generated code. This was using the
3bcc cross compiler for the AT&T 3B20D processor. The year was about
1980. I put pointer variables into registers as that seemed to help the
most. The optimizer wasn't as powerful as one could hope for back then.
I believe newer versions of the 3bcc compiler/optimizer did a better job
so using the register keyword wasn't as critical later.
On Mar 18, 3:14 pm, santosh <santosh....@gm ail.comwrote:
I wonder how much suboptimal register allocation would matter with
modern processors with huge L1 and L2 caches.
The size of the L1 cache doesn't make any difference to this problem,
and the L2 cache most certainly doesn't.
A typical x86 system can perform three or four micro operations per
cycle. Operations between registers are one micro operation;
operations using one memory variable use at least three micro
operations (calculate address, load, process) which means throughput
is reduced by a factor of three, you get much bigger latencies which
is a killer with long dependency chains, you run out of resources for
checking memory dependencies, so all in all using memory instead of
registers is awfully bad for your code's performance.
On Mar 18, 3:37 pm, r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
Not these days, probably, but it used to be true for some MS-DOS
implementations that you could register the wrong variable and the
compiler would merrily do as you told it.
If you write code like
for (i = 0; i < n; ++i) use (x);
for (i = 0; i < m; ++j) use (y);
and the compiler can put either x or y into a register, but not both,
then I would expect it to use the variable that was declared as a
"register" variable. And if n = 10, m = 1000000000, and the compiler
doesn't know this, then using the wrong declaration will still make
your code slower. (Of course a compiler could just ignore "register"
completely except for giving an error if you take the address of a
variable, giving you a 50:50 chance of picking the right variable).
On Mar 17, 3:40 pm, Kenneth Brody <kenbr...@spamc op.netwrote:
There were other "tricks" I learned way back then which are no longer
relevant as well. For example, rewriting a for-loop properly could
make a big improvement on 680x0-based systems, as the compiler would
then take advantage of the 680x0's "decrement and branch on non-zero"
instruction.
That was a very nice thing about the CodeWarrior C compiler: It
produced faster code if you wrote for-loops in the most readable way,
like
for (i = start; i < end; ++i) ...
which was deserved punishment for all those who thought
while (i--) ...
or something similar unreadable would produce faster code.
Unfortunately later compiler versions did all kinds of loop with fast
code :-(
>>Has anyone found that declaring variables register affected
>>speed of execution ? If yes on what hardware and around
>>which year ?
>>
>On quite a few embedded architectures, 8 to 32 bit.
>>
>The last time was this morning.
>
Is it possible at all that, variables declared to be register
located might confuse the compiler's optimisation methods and
actually reduce the efficiency of the overall code?
If it does and the code you wrote meets the requirements of the C
standard, the compiler is buggy. The odds are that your code is
the buggy componenet.
Please do not quote signatures. Those are anything that follows
the "-- " sig marker in the original message.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.
>>Spiros Bousbouras <spi...@gmail.c omwrote:
>>>
>>>Has anyone found that declaring variables register affected
>>>speed of execution ? If yes on what hardware and around
>>>which year ?
>>On quite a few embedded architectures, 8 to 32 bit.
>>>
>>The last time was this morning.
>Is it possible at all that, variables declared to be register
>located might confuse the compiler's optimisation methods and
>actually reduce the efficiency of the overall code?
>
If it does and the code you wrote meets the requirements of the C
standard, the compiler is buggy. The odds are that your code is
the buggy componenet.
In what way exactly is the compiler buggy? The C standard does not
guarantee that if you use "register" then your code will run faster.
Comment