Jump to page: 1 27  
Page
Thread overview
D performance compared with other languages
May 11, 2004
Andy Friesen
May 11, 2004
Walter
May 11, 2004
Helmut Leitner
May 11, 2004
Ben Hinkle
May 11, 2004
Walter
May 11, 2004
Daniel Horn
May 11, 2004
Walter
May 12, 2004
-scooter-
May 12, 2004
Kevin Bealer
May 13, 2004
Scott Michel
May 13, 2004
Kevin Bealer
May 17, 2004
-scooter-
May 18, 2004
Kevin Bealer
May 20, 2004
-scooter-
May 20, 2004
Kevin Bealer
May 13, 2004
Walter
May 11, 2004
Walter
May 12, 2004
Jan-Eric Duden
May 12, 2004
Walter
May 12, 2004
Jan-Eric Duden
May 12, 2004
Stewart Gordon
May 12, 2004
Jan-Eric Duden
May 12, 2004
Stewart Gordon
May 13, 2004
Kevin Bealer
May 13, 2004
Stewart Gordon
May 13, 2004
J Anderson
May 13, 2004
Walter
May 14, 2004
J Anderson
May 14, 2004
Walter
May 13, 2004
J Anderson
May 13, 2004
Stewart Gordon
May 13, 2004
J Anderson
May 12, 2004
Sean Kelly
May 12, 2004
J Anderson
May 12, 2004
Stewart Gordon
May 12, 2004
C
May 13, 2004
J Anderson
May 13, 2004
Stewart Gordon
May 13, 2004
J Anderson
Re: D performance compared with other languages - test.d
May 12, 2004
Knud Sørensen
May 13, 2004
Walter
May 12, 2004
Jörg Rüppel
May 13, 2004
Walter
May 13, 2004
Jörg Rüppel
May 11, 2004
Kevin Bealer
May 11, 2004
Kevin Bealer
May 12, 2004
Walter
May 11, 2004
Andy Friesen
May 11, 2004
Matthew
May 11, 2004
Walter
May 11, 2004
C
May 11, 2004
I have written an object oriented Heapsort in D at http://www.heron-language.com/benchmarks/heapsort-d.html to compare the performance of object oriented code in several languages. The results were somewhat disappointing, when compared with C++, Delphi, Java, and Heron. I was hoping that there might be some suggestions from members of this group about how I might improve the code I wrote while keeping the overall algorithm and design the same.

Please note that the program is a port of the program at http://www.heron-language.com/benchmarks/heapsort-heron.html and is discussed further at http://www.heron-language.com/benchmarks/index.html

TIA
-- 
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com


May 11, 2004
christopher diggins wrote:
> I have written an object oriented Heapsort in D at
> http://www.heron-language.com/benchmarks/heapsort-d.html to compare the
> performance of object oriented code in several languages. The results were
> somewhat disappointing, when compared with C++, Delphi, Java, and Heron. I
> was hoping that there might be some suggestions from members of this group
> about how I might improve the code I wrote while keeping the overall
> algorithm and design the same.
> 
> Please note that the program is a port of the program at
> http://www.heron-language.com/benchmarks/heapsort-heron.html and is
> discussed further at http://www.heron-language.com/benchmarks/index.html

The time decreases significantly if you use both -O and -release.

 -- andy
May 11, 2004
Make sure to compile with:
    -release -O -inline

"christopher diggins" <cdiggins@users.sourceforge.net> wrote in message news:c7qvo6$1256$1@digitaldaemon.com...
> I have written an object oriented Heapsort in D at http://www.heron-language.com/benchmarks/heapsort-d.html to compare the performance of object oriented code in several languages. The results were somewhat disappointing, when compared with C++, Delphi, Java, and Heron. I was hoping that there might be some suggestions from members of this group about how I might improve the code I wrote while keeping the overall algorithm and design the same.
>
> Please note that the program is a port of the program at http://www.heron-language.com/benchmarks/heapsort-heron.html and is discussed further at http://www.heron-language.com/benchmarks/index.html
>
> TIA
> -- 
> Christopher Diggins
> http://www.cdiggins.com
> http://www.heron-language.com
>
>


May 11, 2004
christopher diggins wrote:

> I have written an object oriented Heapsort in D at
> http://www.heron-language.com/benchmarks/heapsort-d.html to compare the
> performance of object oriented code in several languages. The results were
> somewhat disappointing, when compared with C++, Delphi, Java, and Heron. I
> was hoping that there might be some suggestions from members of this group
> about how I might improve the code I wrote while keeping the overall
> algorithm and design the same.
> 
> Please note that the program is a port of the program at
> http://www.heron-language.com/benchmarks/heapsort-heron.html and is
> discussed further at http://www.heron-language.com/benchmarks/index.html

This is completely tangental, but Microsoft's C++ compiler completes the heapsort in 235ms. (Athlon XP 1600+ with 512MB of RAM, using /O2)

 -- andy
May 11, 2004
Thanks for the feedback, Walter. I had only used -O but not -inline
and -release which sped up the execution to 703 msec and the memory usage
dropped to 2MB on my system. I have now updated the web page as a result.
There is still 4 bytes per object that I can't account for. I count 8 bytes
for the vector data, 4 bytes for the pointer to the object, 4 bytes for the
vtable in the object, which only brings me to 16 bytes per object, what is
the other 4 bytes for? Is there a way to allocate 100,000 objects at once
rather then one by one?

-- 
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com


May 11, 2004

christopher diggins wrote:
> 
> Thanks for the feedback, Walter. I had only used -O but not -inline
> and -release which sped up the execution to 703 msec and the memory usage
> dropped to 2MB on my system. I have now updated the web page as a result.
> There is still 4 bytes per object that I can't account for. I count 8 bytes
> for the vector data, 4 bytes for the pointer to the object, 4 bytes for the
> vtable in the object, which only brings me to 16 bytes per object, what is
> the other 4 bytes for?

Each interface has a 4 byte/object cost.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com
May 11, 2004
Every D object has a synchronized monitor that is right after the vtable.
That is a pointer to a platform-specific mutex of some sort.
Structs don't have any vtable or monitor so they would be the most efficient
memory-wise but wouldn't support any dynamic binding or synchronization.

"christopher diggins" <cdiggins@users.sourceforge.net> wrote in message news:c7r63p$1bv1$1@digitaldaemon.com...
> Thanks for the feedback, Walter. I had only used -O but not -inline
> and -release which sped up the execution to 703 msec and the memory usage
> dropped to 2MB on my system. I have now updated the web page as a result.
> There is still 4 bytes per object that I can't account for. I count 8
bytes
> for the vector data, 4 bytes for the pointer to the object, 4 bytes for
the
> vtable in the object, which only brings me to 16 bytes per object, what is the other 4 bytes for? Is there a way to allocate 100,000 objects at once rather then one by one?
>
> -- 
> Christopher Diggins
> http://www.cdiggins.com
> http://www.heron-language.com
>
>


May 11, 2004
"christopher diggins" <cdiggins@users.sourceforge.net> wrote in message news:c7r63p$1bv1$1@digitaldaemon.com...
> Thanks for the feedback, Walter. I had only used -O but not -inline
> and -release which sped up the execution to 703 msec and the memory usage
> dropped to 2MB on my system. I have now updated the web page as a result.

Thanks! Could you also please hyperlink the "Digital Mars Compiler" to www.digitalmars.com/d/ ? You'll also get faster results if you use 'final' on all member functions that are not overrided (essentially all the functions you don't mark as 'virtual' in the C++ version).

> There is still 4 bytes per object that I can't account for. I count 8
bytes
> for the vector data, 4 bytes for the pointer to the object, 4 bytes for
the
> vtable in the object, which only brings me to 16 bytes per object, what is the other 4 bytes for?

It's for the monitor.

> Is there a way to allocate 100,000 objects at once
> rather then one by one?

Yes. Implement a new() function for the class, and have it parcel out bits
from a preallocated array.



May 11, 2004
Walter wrote:
> "christopher diggins" <cdiggins@users.sourceforge.net> wrote in message
> news:c7r63p$1bv1$1@digitaldaemon.com...
> 
>>Thanks for the feedback, Walter. I had only used -O but not -inline
>>and -release which sped up the execution to 703 msec and the memory usage
>>dropped to 2MB on my system. I have now updated the web page as a result.
> 
> 
> Thanks! Could you also please hyperlink the "Digital Mars Compiler" to
> www.digitalmars.com/d/ ? You'll also get faster results if you use 'final'
> on all member functions that are not overrided (essentially all the
> functions you don't mark as 'virtual' in the C++ version).
> 
> 
>>There is still 4 bytes per object that I can't account for. I count 8
> 
> bytes
> 
>>for the vector data, 4 bytes for the pointer to the object, 4 bytes for
> 
> the
> 
>>vtable in the object, which only brings me to 16 bytes per object, what is
>>the other 4 bytes for?
> 
> 
> It's for the monitor.
> 
> 
>>Is there a way to allocate 100,000 objects at once
>>rather then one by one?
> 
> 
> Yes. Implement a new() function for the class, and have it parcel out bits
> from a preallocated array.
> 
> 
> 
That's a bit tedius, especially if your class may or may not need to be in an array (or you may wish to have the same class in 3 different packed arrays)
clearly you could make some sort of template class that inherits and make that have a "new" operator that does the parceling...
but it's a hack that only lets me have a single stack per template class
(what if I want to have many stacks of said objects) I could have a global "current stack" pointer and set it to my next available stack, but this is beginning to sound more and more contrived.

why not just do a structure then--

Do structs support static inheritance (I guess they will with mixins?)
May 11, 2004
"Daniel Horn" <hellcatv@hotmail.com> wrote in message news:c7ra0p$1hr4$1@digitaldaemon.com...
> >>Is there a way to allocate 100,000 objects at once
> >>rather then one by one?
> > Yes. Implement a new() function for the class, and have it parcel out
bits
> > from a preallocated array.
> That's a bit tedius, especially if your class may or may not need to be in an array (or you may wish to have the same class in 3 different packed arrays)

I do the same sorts of optimizations in C++ when I want performance. Storage allocation is always a ripe target for performance tuning.

> clearly you could make some sort of template class that inherits and
> make that have a "new" operator that does the parceling...
> but it's a hack that only lets me have a single stack per template class
> (what if I want to have many stacks of said objects) I could have a
> global "current stack" pointer and set it to my next available stack,
> but this is beginning to sound more and more contrived.

That's why the general purpose storage allocator is the default solution. But when speed is your master, writing custom allocators can yield big benefits, and that's why D supports doing it.

> why not just do a structure then--

Structs can't inherit from an interface.

> Do structs support static inheritance (I guess they will with mixins?)

Mixins have the potential to do this. Stay tuned!


« First   ‹ Prev
1 2 3 4 5 6 7