www.digitalmars.com         C & C++   DMDScript  

D - Performance questions

reply Bill Cox <bill viasic.com> writes:
Hi.

I've read all the documentation on the main D web site about D.  I've 
got some questions about the compiler implementation that relate to the 
performace of executables it creates.

In particular:

1) If there are no virtual functions left in a class, dose the VFT 
pointer go away?

2) By default, does the memory allocator allocate objects of each class 
together as much as possible?  This is a cache and paging optimization 
thing.  Or, are they scattered all over (trashing my cache performance)?

3) Do I get free-list performace by default?  I need the smallest number 
of machine cycles possible when creating and deleting objects in my 
inner loops.  If not, would it help if I manually built free lists?

Thanks,
Bill Cox
Jan 26 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Bill Cox" <bill viasic.com> wrote in message
news:3E3404B4.5010505 viasic.com...
 Hi.

 I've read all the documentation on the main D web site about D.  I've
 got some questions about the compiler implementation that relate to the
 performace of executables it creates.

 In particular:

 1) If there are no virtual functions left in a class, dose the VFT
 pointer go away?
No, it's always there, both because it inherits from Object which has virtual functions, and because many features rely on the first entry in the VFT being a pointer to the ClassInfo. But, structs do not have VFT's at all.
 2) By default, does the memory allocator allocate objects of each class
 together as much as possible?  This is a cache and paging optimization
 thing.  Or, are they scattered all over (trashing my cache performance)?
That's up to the designer of the GC, which isn't part of the language spec. But the GC I wrote does try to keep objects of the same size on the same page, which has a similar affect to what you're asking for.
 3) Do I get free-list performace by default?  I need the smallest number
 of machine cycles possible when creating and deleting objects in my
 inner loops.  If not, would it help if I manually built free lists?
Yes, it will help if you used your own free list. Allocate by first checking the free list for any available, otherwise allocate one with new. When done, add the object to your free list. I use that technique all the time.
Jan 26 2003
parent reply Bill Cox <bill viasic.com> writes:
Hi, Walter.

Thanks for the reply.  How do you manage to work on D during weekends 
and still have a life ;-) ?  I hope they pay you well...

D's memory sub-system does sound advanced.  However, I think I could 
beat it's speed using C on problems using many megabytes worth of class 
data (which unfortunately describes most of the problems I work on). 
I'd expect to mostly gain from improved cache performance.

Would you have any interest in a speed test of D on large object sets? 
I could write the test in C and in D and post results, or we could talk 
about it first, and you or I (or someone else) could do the D 
implementation.

I share you're view that D is potentially faster than C.  The 
optimization potential is much higher.

Thanks,
Bill Cox
Jan 26 2003
parent "Walter" <walter digitalmars.com> writes:
"Bill Cox" <bill viasic.com> wrote in message
news:3E34BE71.4040309 viasic.com...
 Thanks for the reply.  How do you manage to work on D during weekends
 and still have a life ;-) ?  I hope they pay you well...
Digital Mars is my full time job.
 D's memory sub-system does sound advanced.  However, I think I could
 beat it's speed using C on problems using many megabytes worth of class
 data (which unfortunately describes most of the problems I work on).
 I'd expect to mostly gain from improved cache performance.
I could beat that using assembler <g>. Joking aside, I have benchmarks that run faster in D than in C - like the dhrystone benchmark.
 Would you have any interest in a speed test of D on large object sets?
 I could write the test in C and in D and post results, or we could talk
 about it first, and you or I (or someone else) could do the D
 implementation.
Feel free!
 I share you're view that D is potentially faster than C.  The
 optimization potential is much higher.
Keep in mind that the current D compiler is an early implementation, with an emphasis on simply generating correct code. Exploring the optimization potential comes later. Contrast that with C++ compilers, which have been undergoing attempts at optimization for 15 years.
Jan 26 2003