D - Performance questions
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
"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
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
"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