• Era Scarecrow <rtcvb32 yahoo.com> Jul 19 2008

Era Scarecrow <rtcvb32 yahoo.com> writes:

 JAnderson wrote:
 bobef wrote:
 This has probably been asked many times before. If




 such discussion please paste me a link. Why not an




 We all know that the compiler can be stupid some




 is not people may want to inline something that is




 appropriate for inlining. Auto inlining is fine,




 have control over such kind of things I believe.

 Regards, bobef


 May C++ compilers ignore the inline attribute because


 handle on when to inline.  There have been some


 have the links to these) where they've shown that


 compiler can make a more intelligent guess then the


 
 But that's C++.  D does this automatic


 to say whether the compiler can always make a good


 
 -Joel


 I was working with MSVC++ the other day and found a couple
 of places 
 where it wasn't inlining the code and was running slow.
  So I placed a 
 few inlines around and *bam* that code started running
 faster.  Then I 
 profiled the code as a whole to see how much of an
 improvement I'd 
 gained.  However the game was actually running slower.  It
 turned out 
 that inlining had simply shifted the bottneck into memory
 and the 
 program file size had got bigger, so the program cache was
 stalling all 
 the time.
 
 I'm not against inlining, I just think that you have to
 be really 
 careful when using it and understand its implications (ie
 use a 
 profiler), otherwise you could be making things worse.


 A good point.

 Recently i've stepped away from C and trying to get away from ultra-optimizing
code (which has made my best project look sloppy and i notice is ridden with
extra code, in order to get gains that i am not sure i'm actually getting)

 Could we, for instance use a profiler to comment and pull information from a
running program, and than use that to get optimizations that it might otherwise
have not noted?

 I recall something like this, but i don't want to look it up. bare with me.

(not exactly as before, but close)
 if (b)
   a = something;
 else
   a = somethingElse;


 Then say b had a 90% chance of being positive or negative, the running
profiler seeing that would then take the needed steps on a re-compiling stage
using that profiling in order to optimize, without worrying about portability
and readability problems?

We see the above code, the compiler does...

 (if b is greater for being positive)
a=something;
if (!b)
  a=somethingElse;

  Course, unless there's something big or slow in the calls, or SomethingElse
takes longer than something (besides a simple type), i don't think there's much
of a speed gain. If for example the opposite was true..


 (if b is greater for being positive)
char []buffer;  //what for i'm not sure.

buffer=something;
if (!someflag)
  buffer=new char[xxx];

  Then the speed gains from not having to initialize the memory for some flag
is still true, although it wouldn't be much speed gains honestly. hmm..

(Assembly would say, 1 compare, 1 jump, 1 assignment/call, regardless)

 Oh well. Thoughts on an external profiler to assist with the compiler with
optimization?

 Era