View mode: basic / threaded / horizontal-split · Log in · Help
November 30, 2006
Re: Performance of method calls
Daniel Keep wrote:
> Walter Bright wrote:
>> Daniel Keep wrote:
>>
>>> I just recompiled and re-ran with some different flags.  The results 
>>> are... interesting.
>>>
>>> (Numbers are #1/#2 and #3/#2)
>>>
>>> -O: 1.39892 and 3.61384
>>> -O -release: 1.00703 and 1.0163
>>> -O -inline: 1.89054 and 13.4001
>>> -O -release -inline: 1.8257 and 1.00007
>>>
>>> Now I've got *no* idea what to think :P
>>
>>
>> You really need to use obj2asm on the results. It'll make things a lot 
>> more sensible!
> 
> Isn't obj2asm linux only?  I used ndisasm on the object files, but my 
> x86 assembler isn't quite good enough to work out what's going on :P

A Win32 version exists as part of the "extended utilities package" 
available from digitalmars.com.  It's worth the $15 cost all by itself IMO.


Sean
November 30, 2006
Re: Performance of method calls
Daniel Keep wrote:
> Anyway, I was wondering what the difference between three kinds of 
> function calls would be:
> 
> 1. Foo x; x.call(); // Where Foo is a struct
> 2. Foo_call(x); // C-style API
> 3. auto y = new FooClass; y.call(); // Where call is final



	I remember using SmartEiffel a couple of years ago and it used to do 
global analysis and would optimize out polymorphic calls that weren't 
really polymorphic. Normal numbers were 90% of polymorphic calls 
transformed into regular function calls. The performance was amazing.

	Maybe you want to test your code under their compiler as well?

marcio
December 01, 2006
Re: Performance of method calls
Daniel Keep wrote:
> Daniel Keep wrote:
>> Walter Bright wrote:
>>
>>> Daniel Keep wrote:
>>>
>>>> I hooked up a test app which used a loop with 100,000 iterations for 
>>>> each call type, and ran that program 100 times, and averaged the 
>>>> outputs.
>>>
>>>
>>>
>>> What flags did you use to compile it?
>>
>>
>> I didn't use any flags; I was worried about the compiler being "smart" 
>> and inlining the functions calls which would... well, eliminate them 
>> entirely :P
>>
>> If there are any flags you can recommend that would give more 
>> realistic results, I'd love to know.
>>
>>     -- Daniel
>>
> 
> I just recompiled and re-ran with some different flags.  The results 
> are... interesting.
> 
> (Numbers are #1/#2 and #3/#2)
> 
> -O: 1.39892 and 3.61384
> -O -release: 1.00703 and 1.0163
> -O -inline: 1.89054 and 13.4001
> -O -release -inline: 1.8257 and 1.00007
> 
> Now I've got *no* idea what to think :P
> 
>     -- Daniel

I think there's some kind of stack alignment issue going on or something... If you comment out the 
timing code, change the 'scope y' to 'auto y' and run each one at a time [with -O -release -inline] 
you get very close to the same results for each (as expected).
December 01, 2006
Re: Performance of method calls
Daniel Keep wrote:

> Hi.
> 
> I'm currently working on a research project as part of my Honours, and
> one of the requirements is speed--the code I'm writing has to be very
> efficient.
> 
> Before I started, my supervisor warned me about object-oriented
> programming and that it seems to be much slower than just flat function
> calls.
> 
> Anyway, I was wondering what the difference between three kinds of
> function calls would be:
> 
> 1. Foo x; x.call(); // Where Foo is a struct
> 2. Foo_call(x); // C-style API
> 3. auto y = new FooClass; y.call(); // Where call is final
> 
> I hooked up a test app which used a loop with 100,000 iterations for
> each call type, and ran that program 100 times, and averaged the outputs.
> 
> #1 was 2.84 times slower than #2, and #3 was 3.15 times slower than #2.
>   Are those numbers right??  Is it really that much slower?  I would
> have thought that they should have been about the same since each one
> needs to pass only one thing: a pointer.  I've attached the test
> programs I used; if anyone can offer any insight or even corrections,
> I'd be very grateful.
> 
> Incidentally, any other insights regarding performance differences
> between OO-style and flat procedural-style would be very welcome.
> 
> -- Daniel

D's advantages over C are far more than just OO.  Write equivalent test
programs in C and D and test them with DMC and DMD.  I'd bet that they'll
be about the same.  This being the case, you can use D but avoid OO calls
if they turn out to be too heavy weight.  For a program of any size in C,
I'd kill for features like dynamic arrays, templates, and the like.

Of course, I suspect that even if DMD's OO performance isn't top notch right
now, it will become so.  I've heard Walter mention that he hasn't yet tuned
the backend optimizer for OO code- I don't know if this is still true, but
it's probably a safe bet that DMD's performance a few months from now will
be significantly better than now.

-- 
~John Demme
me@teqdruid.com
http://www.teqdruid.com/
December 01, 2006
Re: Performance of method calls
John Demme wrote:
> Daniel Keep wrote:
> 
> 
>>Hi.
>>
>>I'm currently working on a research project as part of my Honours, and
>>one of the requirements is speed--the code I'm writing has to be very
>>efficient.
>>
>>Before I started, my supervisor warned me about object-oriented
>>programming and that it seems to be much slower than just flat function
>>calls.
>>
>>Anyway, I was wondering what the difference between three kinds of
>>function calls would be:
>>
>>1. Foo x; x.call(); // Where Foo is a struct
>>2. Foo_call(x); // C-style API
>>3. auto y = new FooClass; y.call(); // Where call is final
>>
>>I hooked up a test app which used a loop with 100,000 iterations for
>>each call type, and ran that program 100 times, and averaged the outputs.
>>
>>#1 was 2.84 times slower than #2, and #3 was 3.15 times slower than #2.
>>  Are those numbers right??  Is it really that much slower?  I would
>>have thought that they should have been about the same since each one
>>needs to pass only one thing: a pointer.  I've attached the test
>>programs I used; if anyone can offer any insight or even corrections,
>>I'd be very grateful.
>>
>>Incidentally, any other insights regarding performance differences
>>between OO-style and flat procedural-style would be very welcome.
>>
>>-- Daniel
> 
> 
> D's advantages over C are far more than just OO.  Write equivalent test
> programs in C and D and test them with DMC and DMD.  I'd bet that they'll
> be about the same.  This being the case, you can use D but avoid OO calls
> if they turn out to be too heavy weight.  For a program of any size in C,
> I'd kill for features like dynamic arrays, templates, and the like.

Damn straight.  Very first thing I wrote involved templated structs, 
simply because it allowed me to write much cleaner, safer code.  I now 
have a literate library module with contracts and unit tests.

> Of course, I suspect that even if DMD's OO performance isn't top notch right
> now, it will become so.  I've heard Walter mention that he hasn't yet tuned
> the backend optimizer for OO code- I don't know if this is still true, but
> it's probably a safe bet that DMD's performance a few months from now will
> be significantly better than now.

Lamentably, I can't go back to my supervisor and say "but this guy said 
that Walter said that it'll totally get faster!"

Incidentally, I wrote up a much larger test program, compiled with about 
five different sets of compiler switches and then disassembled the whole 
shtick and started reading through it.

It's really annoying to write test applications and then discover the 
compiler's elided half of it :P  Damn optimisations...  at least it 
explains the performance increases!

I've decided that I'll try to stick to structures with member functions 
wherever possible.  The main difference in performance appears to be 
creation and destruction of classes vs. structs.  I still want to get 
the newest DMD and see what difference stack allocation makes (silly me 
for doing this without checking to make sure I had the newest compiler...)

The only thing I really miss when using structures are constructors and 
destructors.  Any reason why we can't have them, Walter?  Pwetty pweese? 
 You can make it my Christmas Pressy...

	-- Daniel
December 01, 2006
Re: Performance of method calls
== Quote from Daniel Keep (daniel.keep+lists@gmail.com)'s article

> The only thing I really miss when using structures are constructors and
> destructors.  Any reason why we can't have them, Walter?  Pwetty pweese?

I think most people use static opCall as a workaround for the lack of struct
ctors. It's not a perfect substitute (in particular, you don't get invariant
checks on 'construction') but it's liveable.

I doubt very much whether Walter will ever add struct dtors - it requires a bunch
of extra code to be generated, and with "scope" there's no great need for them.

cheers
Mike
December 01, 2006
Re: Performance of method calls
Mike Capp wrote:
> == Quote from Daniel Keep (daniel.keep+lists@gmail.com)'s article
> 
> 
>>The only thing I really miss when using structures are constructors and
>>destructors.  Any reason why we can't have them, Walter?  Pwetty pweese?
> 
> 
> I think most people use static opCall as a workaround for the lack of struct
> ctors. It's not a perfect substitute (in particular, you don't get invariant
> checks on 'construction') but it's liveable.

True.  What I'm worried about is the performance difference between

> Foo x = Foo();

and

> Foo x; x.init();

Ah well.  It's only one extra statement :)

> I doubt very much whether Walter will ever add struct dtors - it requires a bunch
> of extra code to be generated, and with "scope" there's no great need for them.
> 
> cheers
> Mike

I know, I know.  I just wish I could omit `foo.init(); scope(exit) 
foo.cleanup()` every time I make a Foo.  Then again, it would only be 
worse in C :3

*sigh*  This is what happens when someone says "It has to be efficient": 
I go nuts over every little instruction...

	-- Daniel
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home