Personal computing discussed

Moderators: SecretSquirrel, just brew it!

Are register variables any use?

They have specialised uses
6 (75%)
They can only be used in smaller programs...
1 (13%)
They have little use
1 (13%)
They have no use
No votes
 
Total votes: 8
 
IntelMole
Grand Gerbil Poohbah
Topic Author
Posts: 3505
Joined: Sat Dec 29, 2001 7:00 pm
Location: The nearest pub
Contact:

Register Variables

Tue Jul 01, 2003 4:08 pm

Reading my little ANSI C book (well, huge ANSI C book :D ) and I've just come across register variable types...

From the definition in the book, these ones are those that are intended to "stay" in the registers more often that the ints etc...

But do any of you lot actually use them for any meaningful task?

By meaningful task, I don't mean a simple program like:

main(register int count)
{
for(count = 0; ++count < 1000; )
;
}


Sort of thing... I mean the big complex programs where you're switching from function to function in separate files etc...

And if you do use them, do you ever run into hardware level problems e.g. say you are running a 32-bit variable in a 16-bit program? Although with that you may just split it over two registers...

Any uses? PS Excuse any errors in the syntax :D, I think it's okay...
IntelMole
Living proof of John Gabriel's theorem
 
just brew it!
Gold subscriber
Administrator
Posts: 44201
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Tue Jul 01, 2003 4:37 pm

Even in a large program, optimizing register usage for the lowest-level loops (where the program spends most of its time) can have tangible benefits.

The register keyword is merely a hint to the compiler that the variable will be frequently accessed; the compiler can heed or ignore the keyword as it sees fit (or subject to hardware constraints). Most modern compilers are "smart" enough that they'll put frequently accessed variables (e.g. loop index counters) in a register anyway, so in many cases the keyword will have absolutely no effect.
 
Buub
Maximum Gerbil
Posts: 4366
Joined: Sat Nov 09, 2002 11:59 pm
Location: Seattle, WA
Contact:

Tue Jul 01, 2003 5:52 pm

Heh I was just about to type what just brew it! said.

Register is an indication you want to "register-ize" the variable, but the compiler doesn't have to honor it. This becomes particularly difficult with multiple variables on x86 architectures because the chip has so few general-purpose registers. A lot of RISC chips could do this more freely because they had stacks of general-purpose registers.

Incidentally, AMD-64 doubles the number of registers if you're running in 64-bit native mode, which may be a big boost for some applications.

Yes, use register sparingly for tight loops. Try to stick to only one, or at most two register variables per function. But also take this advice:

Beware premature optimization.

If you don't know it's a bottleneck, it's generally best not to start optimizing it. Write code "well" first, optimize it after.
 
Yahoolian
Grand Gerbil Poohbah
Posts: 3577
Joined: Sun Feb 16, 2003 3:43 pm
Location: MD
Contact:

Tue Jul 01, 2003 6:09 pm

Most modern, optimizing compilers will automatically decide which variables to put in the registers.
 
IntelMole
Grand Gerbil Poohbah
Topic Author
Posts: 3505
Joined: Sat Dec 29, 2001 7:00 pm
Location: The nearest pub
Contact:

Wed Jul 02, 2003 10:24 am

Yeah, I was wondering about the possible lack of x86 registers, and the x86-64 thing... anyway:

Would there ever be any problems with 32-bit/16-bit compilers and processors... like using twice the number of registers?

Anyone come across anything like this...

The only reason I was thinking about this was because I was looking at it WRT that sieve of Eratosthenes program that was posted in the other thread... I was thinking that it might take a little strain off the memory channel...

Although having thought of it I reckon that there would be too many variables involved and it might slow the process down...
IntelMole
Living proof of John Gabriel's theorem
 
just brew it!
Gold subscriber
Administrator
Posts: 44201
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Wed Jul 02, 2003 10:45 am

I doubt that register variables would help the sieve program much, if at all. Even if the compiler is too "dumb" to registerize frequently used variables (e.g. loop index) on its own, the loop index would always be in cache anyway, since it is accessed repeatedly. So the effect on memory bandwidth would be essentially nil.
 
Revenent
Gerbil
Posts: 98
Joined: Thu Jun 19, 2003 6:25 pm

Fri Jul 04, 2003 6:29 pm

If I remember the x86 hardware architecture correctly, I think even a cache hit is still quite a bit slower than a register hit.

As for memory bandwidth - that's not really true - you still have a write-behind cache, so you'll have to write back. And for SMP computers, you'll probably have a bus lock as well - which might slow other processors down.
 
just brew it!
Gold subscriber
Administrator
Posts: 44201
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Sat Jul 05, 2003 12:08 am

My point was that the sieve is already pretty much completely constrained by memory bandwidth. So speeding up the access to the loop index probably won't help much.
 
muyuubyou
Grand Gerbil Poohbah
Posts: 3222
Joined: Wed Aug 28, 2002 6:19 am
Location: London, UK or Tokyo/Yokohama, Japan or Madrid, Spain

Mon Jul 07, 2003 2:28 pm

Try using registers for 2, 3 and the current number. Depending on your compiler, that may cause some difference.
no sig
 
Craig P.
Gerbil Team Leader
Posts: 285
Joined: Tue Dec 31, 2002 3:12 am
Location: South Bend, IN

Tue Jul 08, 2003 10:35 pm

VC will completely ignore the register attribute, as I recall.

Addendum - here's the MSDN quote for VC7.1:
MSDN wrote:
The compiler does not accept user requests for register variables; instead, it makes its own register choices when global register-allocation optimization (/Oe option) is on. However, all other semantics associated with the register keyword are honored.

Who is online

Users browsing this forum: No registered users and 1 guest