Well this was just an ideia of mine. I can''t confirm that it works, as I''ve never played much with macros. When calling an inline function, theoretically it should have some overhead, mainly due to the function call. When using a macro, the precompiler just substitutes the macro call with the actual code (if I remember carrectly this part)... If this is correct, then why don''t we (and MS) just use macros for some of those extremely repetitive short functions like vector sums and so on. If we have some small code that manipulates (moving based on another object) 100 objects every frame, and we have some 60 frames per sec, then a vector subtraction function will be called at least 6000 times every sec and there will still be other stuff to do. If we can cut just a bit on that small function then we should get a few more cycles for something else, right? (cut deeply on large, slow and infrequent functions and skim lightly on small, fast, frequent functions, that moto has worked quite a lot for me already...). My question is: Is this a viable solution (taking in consideration that I would theoretically "macromize" a substancial collection of such functions) to squeeze a bit more performance? (I haven''t seen any implementation of this kind of idea, so I guess I''m probably forgetting something I shouldn''t...) Will I encounter any limitations or downfalls? DW-za Being punctual is only making your mistake on time... Murphy

quote: Original post by DW-za
When calling an inline function, theoretically it should have some overhead, mainly due to the function call. When using a macro, the precompiler just substitutes the macro call with the actual code (if I remember carrectly this part)...

No. An inlined function means that the function''s code replaces the call. There is no function call overhead, because it''s no longer a function. Think of an inlined function as a type-safe macro.

What you should keep in mind is that the C++ keyword "inline" is not the final word in whether a function gets inlined. Check your compiler documentation and settings. The keyword "inline" is often just a suggestion to the compiler; if the compiler decides the function is too complex to inline, it won''t do it. Likewise, depending on your compiler settings, there may be other functions that are inlined that you didn''t specifically mark as such.




---- --- -- -
Blue programmer needs food badly. Blue programmer is about to die!

Honestly, no offense to the original poster, but:

DON''T OPTIMIZE WITHOUT FIRST PROFILING. I''M SURE IF YOU OR THE XX,XXXth FACELESS MAD OPTIMIZER EVER BOTHERED TO PROFILE YOUR CODE, YOU WOULD SEE GROSS INEFFICENCIES AT AN ALGORITHMIC LEVEL OR AT LOWEST LEVEL, DUE TO MEMORY ACCESS PATTERNS. STOP WORRYING ABOUT "OPTIMIZING" LIKE A HAX0R AND START READING YOUR ALGORITHM BOOKS (CORMEN, LEISERSON, AND RIVEST IS A GOOD PLACE TO START!!!), BECAUSE IF YOU HAVE TO ASK ABOUT THIS KIND OF STUFF, YOU PROBABLY HAVE NO CLUE HOW TO CHOOSE/CONSTRUCT AN ALGORITHM, WHICH MEANS YOUR PSEUDO-OPTIMIZATIONS DON''T STAND A CHANCE AT SPEEDING UP YOUR O(N^7) TECHNIQUES. IF YOU DON''T UNDERSTAND THIS, AGAIN, I BEG OF YOU TO TRY CRACKING OPEN A REAL COMPUTER SCIENCE BOOK!!

I''m just sick of these threads popping up ALL THE TIME.

Sorry for yelling (in advance).

PS: Your plan won''t work because macroing all that code will blow your cache coherency.

Allright, time to quote Bjarne Stroustrup (the creator of C++):

quote:
The first rule of macros is: Don't use them unless you have to. Almost every macro demonstrates a flaw in the programming language, in the program, or in the programmer.
...
If you must use macros, please read the reference manual of your own implementation of the C++ preprocessor carefully and try not to be too clever.

If you still want to use macros, be my guest...

-Neophyte

Edited by - Neophyte on September 26, 2000 11:15:15 AM

Macros are inherently evil. They''re not type-safe and are difficult to watch in the debugger. Furthermore, it''s easy to really mess them up of you''re a novice, and the problems that arise are difficult to track (i.e. assuming macro parameters get evaluated before "passed" to the macro, which they do not).

The only time I''ve seen macros be really appropriate is in application frameworks. In order to abstract the framework (i.e. keep the user from having to worry too much about how the framework is implemented), yet keep functionality, sometimes you resort to macros. A good example is an exception that will pass the filename & linenumber into the exception object; even though you could rely on the user to do it, the application framework designer will probably just create a macro:
#define THROW_EX(str) throw af_runtime_exception (str, __FILE__, __LINE__)

Also, although the anonymous poster was quite rude about it, he does have a point: make sure you''re working on your actual bottleneck when you try these kinds of optimization tricks. Remember the 80/20 precept: 80% of your execution time is spent in 20% of your code. Find that 20%, and if it''s actual function call overhead (highly unlikely), maybe you can unroll those functions. But again, it''s highly unlikely.

It should also be pointed out that inline alone does not guarantee the code will be inserted instead of the call. It''s a hint to the compiler that you would like it inlined.

If you''re using VC you can use the __forceinline to make sure the code is inlined. If the compiler fails to inline a function declared with this it will throw a compilation error.

If you''re not using VC6 I can''t give any extra info other than inline alone does not ''guarantee'' tthe function is inlined (although I would check your manual/help file about compiler specifics).

n!

As far as I''m concered there is NO feature in C/C++ that is evil (not even goto''s). Yes, some features should only be used sparingly but that doesn''t mean they shouldn''t be used. The example that Stoffel gave with the __FILE__ and __LINE__ are perfect examples of how powerful and useful macros can be.

Should you choose inlined functions over macros? Most of the time, yes. Should macros still be used in some instances? Absolutely.

I have a couple of macros that I wrote and would die without. One makes the strcmp() function return true or false (in effect, not implementation) and the other sets the size of DD structures. Doesn''t it every annoy you that you need to memset() the structure to 0, then set the dwSize member? A simple macro used like this: SETUP_STRUCT(ddbltfx);

--------------------


You are not a real programmer until you end all your sentences with semicolons; (c) 2000 ROAD Programming

You are unique. Just like everybody else.

Yanroy@usa.com

Visit the ROAD Programming Website for more programming help.

AHA!!! So there is a good reason not to "macromize" the stuff...

I thought it "was" a good idea, taking in consideration my misconception of the inline function, but basing some code on them seems to be a major error... (besides I program for fun, I don''t have time to go around debugging stuff for weeks, not knowing whats wrong).

To anon and other posters who stress on optimizing in other areas... wellll I don''t have anything to optimize (just a small D3D project, which I''m using more to learn how to use DirectX correctly, C++ efficiently and preparing for DirectX8, if it comes out before the Xbox...) so I don''t have any hassles, at least for now (mind you, I like playing around with profiler tools, but they sometimes cut out an enourmous amount of performance...). But, I''d like to stress that there''s never only one bottle-neck and if we have a function that is called a lot of times (my example was just a simple example it could have been much more complex) and if I had the chance to optimize some function just a bit (in which the results would be felt when used in quantity), then I damn well would do it (then I''d search for the 20%). It''s a bad policy to only persue one problem at a time (you should persue all of them and then handle them one by one). Exprience probably will change my view on this, but anybody will notice that it''s this is important.

So, by what I see, learning Java''s neatness surely wasn''t an error (besides when they kick macros and goto''s out, you tend not to use them)... But we should always thrive to increase our fan of programming options (so that we use the right tool for the right stuff), that''s what arose my curiosity for Macros...

I thank everyone for their participation, which will surely contribut to cleaner programming

Being punctual is only making your mistake on time...

Murphy

The macro''s that really piss me off are those goddamn M$ COM macros. you know that ones STDMETHODIMP and so on.

Head wrecking

"That's not a bug, it's a feature!"
--me