Printable View
i was just wondering what takes more cpu cycles accessing a variable trough a class pointer or a 'scoped' variable...
Code:struct XD
{
int VAL;
XD(const int CPY/*, XD* this*/)
{
/*this->*/VAL = CPY;
//from now on shuld either use CPY or VAL.
printf("%i", /*this->*/VAL); // does this use more cpu cycles
printf("%i", CPY); // than this?
}
};
im asking becus logicly the CPY will be in the registers while VAL needs to be dereferenced?
Well, in your example it probably doesn't matter whether you use
orCode:printf("%i", VAL); // does this use more cpu cycles
because the compiler knows that this->VAL equals CPY and will try to use that information the best way it can (it might use CPY instead of VAL even if your code says VAL).Code:printf("%i", CPY); // than this?
- petter
As Petter has indicated, the compiler will be just as efficient using the assigned pointer.
Please recall that the call to printf will absolutely dominate the run-time of your code sequences no matter how the print information is defined.
Sincerely, Chris. :thumb:
what if the compiler doesnt know ??Quote:
Originally Posted by wildfrog
If you mean those 2 diff. variables of same type.Quote:
what if the compiler doesnt know ??
The below is going to take somewhat less cycyle in some cases
But how much less is going to depend upon some other factors & implementation detailsCode:printf("%i", CPY);
Like what kind of variable? Whether compiler decide to store local variable in CPU register or not? How the C++ class structure implemented by compiler?
Here code generated by VC compiler.
It generating following code for local variable
& Its generating below code for class member accessCode:00411AEA mov eax,dword ptr [CPY]
00411AED push eax
Note its doing one extra move to get first memberCode:00411AFB mov eax,dword ptr [this]
00411AFE mov ecx,dword ptr [eax]
00411B00 push ecx
Some aggressive optimized compiler might give you same cycles for both
Vinod
so i still think its wiser to use the locale..
Nope. It's wiser to compile in RELEASE mode (i.e. full optimization). One, the compiler (Dev Studio 7) inlines the constructor, so there is no 'call' statement. Two, both calls to printf are (almost) exactly the same:
ViggyCode:XD someXD(42);
00403981 push 2Ah
00403983 push 4111F4h
00403988 call printf (406246h)
0040398D push 2Ah
0040398F push 4111F8h
00403994 call printf (406246h)
but you cannot rely on the compiler to much, and there is no down side using CPY instead of VAL, you never know how the compiler will optimiseQuote:
Originally Posted by MrViggy
To be honest, Mitsukai, you're asking a rather pointless question.
There's only a tiny, insignificant difference in performance... if any at all. The performance difference is so small that it's not even worth thinking about unless you've already used a profiler and it's shown that a lot of time has been spent doing that kind of thing.
Since this kind of code happens a lot, a lot of time has been spent making optimisers deal with it well. This makes it all very unpredictable: your optimiser might decide it's all so trivial that it'll just inline the lot and then optimise that... in which case it will take different amounts of time depending on context.
Don't sweat the small stuff. Use algorithms and data structures which make sense for the job at hand, and if it's too slow use a profiler to find where the program is spending it's time.
If /that/ is your biggest bottleneck, I'd say that you had a program as optimised as it's every likely to get!
Ian W
i dont see how its pointless. Alot of software engineers are probally thinking like you, and are infact right now unnecesarily decreasing my cpu's life time...Quote:
Originally Posted by Noddon
the issue is, as a single program it might not be make any diffrence in speed but, the speed will decrease as the cpu is busy. And with other applications become busier. Maybe it will unnecesarily occupy cpu cycles when your doing a huge data transfer wich will take longer...Quote:
Originally Posted by Noddon
Its also to know what happens behind the scene... Though i do not see any harm of using the local variable wich is restored in the register directly. Instead of using the class member and possibly waste a cpu cycle or less becus the compiler possibly dint optimize it.
you sayd my axact point... its unpredictable if the compiler will optimize it or not. Why not easily forget about it and use the local preferbely?Quote:
Originally Posted by Noddon
currently im in no big bussiness and got all the time on my hands to "waste", learning on how compilers work and what could possibly optimise your code.Quote:
Originally Posted by Noddon
if all programmers did... my pc might have worked and booted faster...Quote:
Originally Posted by Noddon
Software engineers worthy of the name know when to optimise.Quote:
Originally Posted by Mitsukai
Optimisers are very good at mico-optimisation, picking the right instructions to get the best local performance. Software engineers let the optimisers do their job and instead perform the optimisations the optimiser cannot do: picking good algorithms and data structures. Only when they know they can do a better job than the optimiser do software engineers worry about micro-optimisation.
It's unpredictable as to the exact output the optimiser will produce for some arbitrary input. What it will do though is /optimise/! The reason why it will produce different results in different contexts is because it's trying to pick the most optimal output.Quote:
you sayd my axact point... its unpredictable if the compiler will optimize it or not. Why not easily forget about it and use the local preferbely?
In other words, it produces different output that is as "good" as it knows how to produce. Something as trivially different as using an automatic variable rather than a member variable will just be lost when the optimiser makes it as fast as possible within the context it is used.
It might if they used optimisers. If I ran an optimiser on your example, I'd get results something like the following:Quote:
if all programmers did... my pc might have worked and booted faster...
EDIT: Of course, I mean profiler... PROFILER. Gah... sleepy brain=silly mistakes.
1 call to XD(), Total time spent in XD(): 18 cycles (0.01%)
2 calls to printf(), Total time spent in printf(): 180,000 cycles(99.99%)
Reducing the time that printf() takes would be an optimisation. Shaving cycle or two from XD() is rather pointless.
Trying to shave a cycle or two from XD() when the optimiser, a piece of code very very good at optimising, has already done it's work is also rather pointless: you're unlikely to do better than the optimiser.
However, using "cout" instead of "printf()" may be a huge optimisation (comparatively). By using "cout" and the overloaded "<<" operator, the compiler can simply call the appropriate function to display an integer. On the other hand, "printf()" has to parse the format string to know it's going to be outputing an integer. You can save a whole load of runtime processing!
Micro-optimisations like picking the instructions to use for XD() are what optimisers are good at. Let them do it. Only when micro-optimisation is not enough is it time to consider changing the code.
No, what those software engineers are doing wrong is using inefficent algorithms, and not that they are or are not using a register here and there.Quote:
Originally Posted by Mitsukai
Honestly, if you were to work on a project with other programmers, they are not looking for these types of micro-optimizations that seem to concern you. What they are looking for are more efficient ways of allocating memory, sorting, organizing data, etc. That is where the speed gains come into play.Have you ever used a profiler? If you have, you will see that what you are worried about takes no time. What takes time, again, is the algorithm that you've used and other things such as calling new 100,000 times when you can get by calling it once or twice, passing or returning big objects by value, etc. These are the things that bring a CPU to its knees.Quote:
the issue is, as a single program it might not be make any diffrence in speed but, the speed will decrease as the cpu is busy. And with other applications become busier. Maybe it will unnecesarily occupy cpu cycles when your doing a huge data transfer wich will take longer...
And you mention "what if the compiler doesn't optimize"? OK, I'll ask the opposite question -- what if the compiler did optimize?
I'll ask another -- what if the compiler didn't optimize, you wrote code, and then on another compiler, the code you wrote didn't allow the compiler to make optimizations, effectively making the code inefficent? So are you going to rewrite the code again? And for what gain (or possible loss)? A few nanoseconds?
Compiler optimization is something that is a basic part of compiler technology. If you've ever taken a course on compilers, and if it is a two semester course, the second semester is usually dedicated to compiler optimizations -- that shows you how important it is. From what you've posted, you seem to think that compiler optimization is a "throwaway" piece that compiler writers don't care about, so they do a sloppy or in extreme cases, no job on optimization. You couldn't be more wrong.
Regards,
Paul McKenzie
First, you should NEVER EVER evaluate the code of the speed in Visual C++ without optimizations.
The default code is FAR WORST than the code produced by Turbo C++ 1.0.
Without optimizations, benchmarks have no meaning... You must at least turn on the very very basic optimizations. For instance, simply use the worst compiler on your platform, and compile with optimizations.
Otherwise very often, you'll see things like:
code A is 1.5 times faster than code B without optimizations.
code A is 5 times slower than code B with optimizations, which is itself 3 times faster than code B without optimizations.
You forget one thing.Quote:
Originally Posted by Mitsukai
access to automatic variables may be SLOWER than access to member variables.
For instance, if you use the __thiscall calling convention or any __fastcall calling convention, there will not be any additional level of indirection.
And, for instance, if you use automatic variables, your compiler may have a lack of registers and need to install a stack frame.
Write things that make sense.
If you want to optimize a critical routine, you should not use such stupid tricks... You should write it in assembly code... The benefit can be really noticeable (from 0% to more than 50% sometimes, with all intermediate speed gains).
A general rule is that an artificial code which says about the same thing that the natural code is less likely to produce efficient code, because compilers have been created to optimize "common" code.
You must also profile your code.
And, instead of using printf, you should use cout (with Borland C++ 5.0 it is MUCH faster)... And if it is critical, you may try to code your own displaying routine... And see if it is faster.
Anyway, you'll see that micro-optimizations are completely stupid most of the time, because even when profiling, if it is a too small micro-optimization, for memory usage or other considerations, the 0.001% performance gain may turn to a 0.01% performance lost with other data set, or on another computer.
Mitsukai:
Note also that the extra level of indirection of member access is only required ONCE in the function.
And that this level of indirection is not even required if the function uses a not-too-bad calling convention (thiscall, fastcall, or simply, an inline function).
Furthermore if you pass data as parameter, you'll have extra code on the callee side.
And since this extra code increases the code size (and slow down the program) proportionally to the number of calls, it will be LESS efficient than using a member variable.
Futhermore, if you don't pass the parameter as argument, but extract it in the function, like:
I claim that, for a correct compiler, it won't make any difference.Code:void MemberFunc() {
int i=member;
// do work on i
}
But for a bad optimizer (or even for a good compiler if the code of the function is large enough and that i can't be put in a register), it will be SLOWER.
Because, i will not be put into a register, which will require to extra dependent mov operations:
And if it is the first non-register automatic variable, it will require at least a stack frame (with at least two instructions).Code:; assume that ecx contains this
mov eax,[ecx+offset]
mov [ebp-4],eax
While using directly the member would be better, because the this pointer would be used a lot (and put in the register), and all accesses to all member variables would be done via this register.
Guideline : especially on machines which have few registers, avoid having aliases of variables.
And, of course, this method seems obviously stupid when there are a lot of members:
Code:struct {
int a,b,c,d,e,f,g;
};
int func() {
int la=a,lb=b,lc=c,ld=d,le=e,lf=f,lg=g; // You reinvented pass-by-value with extra overhead ?
}