I have read people getting 37% speed improvement using only a combined mocule (a huge .c file) in gcc compiler in place of multiple .c files. Is that acceptable? how can this happend?
any tips for how to use modules for better speed?
Printable View
I have read people getting 37% speed improvement using only a combined mocule (a huge .c file) in gcc compiler in place of multiple .c files. Is that acceptable? how can this happend?
any tips for how to use modules for better speed?
It probably depends on how many function calls you make. The more function calls, the less the speed. Being in different files or not doesn't matter.
What people I read claim they get different result with the same program and data. Using the same data an the same number of function calls, they get 37% faster with one module version.Quote:
Originally Posted by Elysia
I am not an expert, and maybe I am wrong, but haveing a huge module, cache and function calls are done in the same address space. For the multiple modules, differents caches ways and differents address spaces are used. That sounds logical to me. am I correct?
The thing is that all "modules" are just pieces of a whole. When linking, they're all inserted together, so it doesn't matter if it's one or thousands.
There's most likely something else at work.
I would suspect that kempelen's claim is based on compiler inlining functions when they are in one source file, and not inlining when they are separate. That can, under some circumstances lead to HUGE benefits, and at other times it makes absolutely no difference at all (because the overhead of calling a function isn't much in comparison to the actual work done by the function).
The RIGHT solution is to profile the application, find out if there's any (smallish) function that appears near the top of the profile histogram. If there are smallish functions near the top, then those are candidates to make inline - that would be done by adding the inline keyword (and perhaps also add static) and moving the function to a header file rather than a source file [or, if it's just an arbitrarily placed function, move it to the code that calls this function].
If we could have the reference where the 37% figure came from, perhaps we can get more detail of what was done.
Certainly, simply splitting an application into multiple source files or merging multiple source files, generally doesn't provide a huge improvement - but in some circumstances, due to for example lack of ability to inline something, the merging can achieve quite a big improvement.
--
Mats
well, maybe the reason is because in a huge module the compiler has the option to inline functions, whereas different modules the compiler can not inline then unless they are declared static inline in .hQuote:
Originally Posted by Elysia
P.S. edit, posted after matsp wrote his post. inline is what I was suspecting. :)
Indeed. It's possible to profile the application and put those functions as inline functions inside headers to get rid of that bottleneck.
[Although, some compilers have the option to actually inline stuff in other modules, even though they not being inline, such as Visual Studio.]
Actually, MS VS 2008 supports "whole program optimization", which essentially means that the entire source code is partially compiled by the compiler, and then finalized at the linking stage, which does the final code-generation and optimization, allowing the application to get inlines from any source that is part of the executable. Some work has been done to gcc to allow something similar, but last time I suggested it was available in gcc, I was told that this is not the case, so I'm now unsure to what extent gcc can do that [the reason I thought it was available was that when I was working with some gcc professionals, I was aware that they were working on it, and I thought it would be available some 3-5 years later].Quote:
Originally Posted by Elysia
--
Mats
Well, it's easy to test if the compiler can.
Create two test files, one function in one with a single line of code that prints out something, so the compiler won't optimize it away, and call it from main.
Visual Studio happily inlined the function even though it was in another source file and not inlined.