|
Friends i need to know about the overhead involved in a function call w.r.t Visual C++ compiler.
Actually i am writing a server based aplication in which speed and efficiency are the primary requirements. There is a function in my program which makes some complex calculations. This function is called by a for loop about 150 times. I also make this function inline function, but i've read in number of C++ docs that making a function inline is of no guarantee that compiler really makes it inline and it depends on a compiler to decide whether to "paste" the code or to keep it a separate function.
So i am in confusion that in my application, a loop is calling the function 150 times and if too many clients send request and i call this function 150 times for each request then there will be lots of CPU cycles required which decreases the efficiency of my application.
So what do you people suggest me to do? Please also tell me the cost involved in calling a function and also tell me how can i judge that the compiler really makes my function inline or not ??
Thanks
|
|
|
|
|
Don't worry about it. From your description, the process of setting up a new stack and calling a subroutine isn't the bottleneck. Removing those steps would not gain any significant time compared to the big complex function.
--Mike--
Eh! Steve!
Homepage | RightClick-Encrypt | 1ClickPicGrabber
"You have Erica on the brain" - Jon Sagara to me
|
|
|
|
|
A function call will take up CPU time, however it is very minimal as compared to what you are doing inside the function.
Bringing the function inline could actually make the operation slower under certain circumstances since it could change the optimization.
All this is mostly irrelevant since optimizations shouldn't be based on theory but on measurable results always keeping in mind the adage that 90% of your time is spent in 10% of your code. Also, the algorithm itself is more important than the implementation.
(By chance I was doing some optimizing this morning. So I modified the test a little and found that making an intermediate function call added about 8 CPU cycles per call on a Celeron 900. The result with the new algorithm was still 4x faster than the original algorithm.)
PS. You could use the keyword __forceinline if your test show that this will improve performance.
|
|
|
|
|
Well, I know someone who makes a 3D-graphics engine, it really does matter pushing things on the stack or not. So I think a compiler should just inline when you want it to inline. Which doesn't gain much over complex calculations, but simple calculations, at the other hand, do matter.
LPCTSTR Dutch = TEXT("Double Dutch  ");
|
|
|
|
|
S van Leent wrote:
it really does matter pushing things on the stack or not
It MAY matter, performance wise. If speed is of most importance, a developer may choose to use the __fastcall modifier on functions. However, if speed is that important, you should always test your code, not simply presume it is faster one way over the other.
S van Leent wrote:
So I think a compiler should just inline when you want it to inline.
I totally disagree. The standard is quite correct in this regard. For convenience, or when using templates, developers may implement a member function in the header, either explicitly inline or within the body of the class definition. If all of those are automatically inlined, it will result in bloated code and may very well result in slower code. (Beyond CPU cycle counts, bloated code will result in more paging which will have a devastating effect on performance.)
In general, unless you really understand the CPU architecture, you should just write clean C/C++ code and let the compiler do it's thing.
Again, most performance bottlenecks are in a tiny part of the code and can often be fixed by using a better algorithm and in understanding and leveraging the OS better.
|
|
|
|
|
Joe Woodbury wrote:
In general, unless you really understand the CPU architecture, you should just write clean C/C++ code and let the compiler do it's thing.
I agree with that, also, I think Inlining is sometimes a lazy way of writing a macro, which is (the macro) sometimes much better.
LPCTSTR Dutch = TEXT("Double Dutch ");
|
|
|
|
|
Joe Woodbury wrote:
By chance I was doing some optimizing this morning. So I modified the test a little and found that making an intermediate function call added about 8 CPU cycles per call on a Celeron 900.
Can you please tell me what method you normally use to find out the number of CPU cycles involved in a function call ???
|
|
|
|
|
At the core, you use the rdtsc x86 instruction. The actual sequence is:
ULARGE_INTEGER cycles;
if (!m_onNT)
_asm cli
_asm
{
pushad
cpuid
rdtsc
mov cycles.HighPart,edx
mov cycles.LowPart,eax
popad
}
if (!m_onNT)
_asm sti
You then calculate the overhead of the base test and then time the tests and do analysis (I throw away the top and bottom 20% of the results and average the rest.) You can also calculate the actual speed of the CPU and convert the cycles into seconds. I only do this if I really need to know the time in seconds, otherwise, I just compare cycles.
There are classes posted in CodeProject to help with all this, though I use my own.
|
|
|
|
|
Shah Shehpori wrote:
but i've read in number of C++ docs that making a function inline is of no guarantee that compiler really makes it inline and it depends on a compiler..
In Visual C++ you can use the __forceinline keyword (which is a Visual C++ specific keyword as the double underscore suggests) to force the compiler to compile it as an inline function, again there are restrictions to this but I don't think that'll be the case for you. You can read further in MSDN.
Edit: Oops sorry it was already suggested above. I guess the force is not with me then.
|
|
|
|
|
What caused WSAECONNRESET error?I'm trying to send some data(jpeg file) to my SMTP server,but at the middle of sending this error happend.Any idea?
Mazy
No sig. available now.
|
|
|
|
|
The SMTP server has disconnected the client.
Kuphryn
|
|
|
|
|
Yes,but why?
Mazy
No sig. available now.
|
|
|
|
|
It means that the server closed the connection.
Maybe the mail was too big...
Lot of servers have restrictions on the size of mails they can receive...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Anders Molin wrote:
Maybe the mail was too big...
Lot of servers have restrictions on the size of mails they can receive...
I don't think so,it happend with small data too. Do you have any other suggestion?
Mazy
No sig. available now.
|
|
|
|
|
Whan does the server tell you just before it hangs up....
it gives you an errorcode lige 505 or something...
And when du you send the data, are you in the right state, and have the server accepted that state?
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Anders Molin wrote:
And when du you send the data, are you in the right state, and have the server accepted that state?
I don't knwo what do you mean by this,If I send some .txt data there is no problem,and there is no problem with how much of it,so I don't think there is problem with state.
Anders Molin wrote:
Whan does the server tell you just before it hangs up....
it gives you an errorcode lige 505 or something...
No,Before this error theere is no other error.
Mazy
No sig. available now.
|
|
|
|
|
Is ++i statement in the for loop better than i++?
I have heard so many people said that. They said
it is good for memory management. Could someone
gives me a better explanation?
|
|
|
|
|
The theory is that with a post increment you have to make a copy of the object, increment the original, and then return the copy of the object. With a pre increment, you increment the object and then return it. Thus pre increment saves the need to make a copy of the object.
The good news is that 99.9% of the time, it makes no difference at all. However, the more complicated the objects are (i.e. real objects and not just simple data types), then you can see a performance increase by using pre increment.
It all boils down to this: Unless you have a specific need to use post increment, you should use pre increment. It won't buy you anything most of the time, but once you get in the habit of using it, you don't have to worry about the cases where it does buy you something.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
[quote]It all boils down to this: Unless you have a specific need to use post increment, you should use pre increment. It won't buy you anything most of the time, but once you get in the habit of using it, you don't have to worry about the cases where it does buy you something.[/quote]
Does the above statement applies to all application? or just
when you are using for loop? How about in while loop and all
other situation?
In what situation do we have to use post increment(i++)?
Thanks.
|
|
|
|
|
VW_Red_Jetta wrote:
In what situation do we have to use post increment(i++)?
None. You don't have to use a post (or pre) increment anywhere, but for convenience a common place is when indexing arrays:
char ch = pStr[offset++];
This is functionally the same as:
char ch = pStr[offset];<br />
++offset;
And results in exactly the same code for simple objects.
|
|
|
|
|
I highly recommend ++i over i++.
Kuphryn
|
|
|
|
|
To answer your original question, there is no difference at all. The compiler will optimize away the copy of i that normally gets made in the expression i++, because it sees that the copy isn't being used.
--Mike--
Eh! Steve!
Homepage | RightClick-Encrypt | 1ClickPicGrabber
"You have Erica on the brain" - Jon Sagara to me
|
|
|
|
|
OK, but if you don't use optimization (it can be useful for something), it does matter
LPCTSTR Dutch = TEXT("Double Dutch  ");
|
|
|
|
|
Not for a simple loop and/or case such as this.
|
|
|
|
|
Hello,
I have a problem with using DLLs...
My main project is written in MSVC++, the DLLs are written in Dev-C++/GCC. Loading the DLLs works fine, as well as calling void functions of the DLLs. Now my problem is that when I try to call a function which doesn't return void (so, for example, an unsigned long), the main program crashes after the call to the DLL...
I tried to make the functions in the DLL and the function prototypes in the main app __stdcall but it doesn't change anything.
The functions are exported in C format (the DLL gets loaded correctly...).
Do you have any idea why a non-void function of a DLL crashes my app? I never hat this problem when making DLLs with MSVC++, only now when compiling them with Dev-C++/GNU-GCC...
-Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do?? 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
