🔒 Locked

Question on optimising

Started by King of Men Jan 11, 2005 at 1:25 PM 7 replies 700+ views

Original Post

Jan 11, 2005 at 1:25 PM

Yes, I know, it is the root of all evil when premature. Really, I'm not planning to apply this, I promise. I'm just curious. [/disclaimer] I've been reading about caches. Assume you have many methods with different temporary variables in them. Let's say they are all floats, and only one per method. Can you avoid cache misses by declaring a global float, which (I hope) the compiler will then assign a permanent cache address since it is used so often? Or are compilers already smart enough for this, so that they use one or two cache positions for temporary variables? In fact, perhaps declaring a global variable for such use would actually slow down your program, if the compiler felt obliged to write it to memory once in a while? In a somewhat similar vein, if you have two for loops close to each other, could you save yourself a miss by declaring one counter int and reusing it? Or perhaps the compiler will already do this for you?

C-Junkie

Jan 11, 2005 at 1:28 PM

Your floats are (probably) already registers, which is even faster than being in the cache.

_the_phantom_

Jan 11, 2005 at 1:36 PM

the compile doesnt control cache allocation, the CPU deals with that its self, for simple things like ints they are more than likely going to be allocated and used in a register, being bumpped to the cache as needed (saving an expensive memory write-read combo).

The only way you can help with the cache situtaion is be using sane data structures for the right task, so the compile can generate code which will cause the CPU to stream data (for example, if you are itterating over a large amount of data using a contigous block of ram, such as an array or std::vector, will allow the CPU to stream the data in as it knows where the next block is coming from, however if you use something like a linked list then the next address of the block of data could be anywhere in ram, thus the CPU has a harder time with it.)

flangazor

Jan 11, 2005 at 2:23 PM

By making all the floats reference the same variable you may hinder the compiler's optimizer from pipelining the instructions since each operation will be dependent on the previous instructions (because they all want to change the one register).

Anon Mike

Jan 11, 2005 at 3:09 PM

This is micro-optimization at it's finest (or worst depending on your view of such things).

It's impossible to say whether it would be better or not without using a very sophisticated profiler and being very precise on what hardware configuration and code scenario you're talking about. If you breath wrong you've invalidated your previous results basically.

As somebody else mentioned compilers don't allocate items in the cpu cache. Compilers can make certain assumptions to try to improve things but ultimately it's up to the hardware cache controller.

Spoonbender

Jan 11, 2005 at 5:08 PM

Quote:
Original post by King of Men
Can you avoid cache misses by declaring a global float, which (I hope) the compiler will then assign a permanent cache address since it is used so often? Or are compilers already smart enough for this, so that they use one or two cache positions for temporary variables? In fact, perhaps declaring a global variable for such use would actually slow down your program, if the compiler felt obliged to write it to memory once in a while?

Generally, global variables are a bad idea. You even guessed the reason in the last sentence... ;)

The problem with globals is that they're accessible from everywhere. This means they have to be in memory at all times, because otherwise other functions won't be able to access it (at least not with its correct, updated, value)

Quote:

In a somewhat similar vein, if you have two for loops close to each other, could you save yourself a miss by declaring one counter int and reusing it? Or perhaps the compiler will already do this for you?

Nah, that wouldn't gain you anything, other than taking up one register in the code between the loops. (Either that, or spilling the counter to memory, and then re-reading it in the second loop).
Just give them a counter each, which can be declared without having to read anything from memory.

antareus

Jan 11, 2005 at 5:52 PM

Using a global in place of a local would inflict much pain upon you when moving to a concurrent architecture.

risingdragon3

Jan 11, 2005 at 7:53 PM

Quote:
Original post by Spoonbender
Nah, that wouldn't gain you anything, other than taking up one register in the code between the loops. (Either that, or spilling the counter to memory, and then re-reading it in the second loop).

Actually, most compilers will notice the inital assignment at the beginning of the loop and generate two seperate variables for the reused counter variable, so in fact, it doesn't matter at all. The end result is the same: the counter variables being assigned to an register if there are enough registers, or spilled (seperately no matter what) if there aren't and the heuristics say it should.

bani

Jan 12, 2005 at 5:02 AM

different compilers optimize very differently too.

gcc
intel cc
visual c++
borland c++

all have very different optimization schemes. getting to know how your compiler optimizes things often comes down to trying different variations and reading the disassembler output :-x

often the only way to know is to try variations and test test test. rdtsc is your friend.

optimization is also highly architecture sensitive. ia32 code tends to run very differently on a p4/athlon than it will on an amd64... some optimizations which get a small (5-10%) speedup on p4/athlon can sometimes get 50% or more on amd64... often unexpected.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.