May 11, 2004
In article <c7r63p$1bv1$1@digitaldaemon.com>, christopher diggins says...
>
>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?

If I have a container of objects that implement interface Printable(), how does Heron determine which are type Circle and which are type Square, without the use of a vtable?

If the language cannot determine which type is which, then you should remove the word "virtual" from the C++ version, and put "final" in the Java (and D?) versions:  if the container can only have one type of object, then C++ does not need the virtual keyword, and including it kind of "rigs" the demo, right?

Kevin


May 11, 2004

-- 
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com
"Walter" <newshound@digitalmars.com> wrote in message
news:c7r9ku$1h7b$1@digitaldaemon.com...
>
> "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).

Done and done. The final keywords sped it up even more from 710 to 610 msec.

> > 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.

What about the 4 bytes on top of that for the interfaces what are they for? Any plans on changing this in the future, or making a compile switch?

> > 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.

I won't be including that in the example then, it seems like too much of a roundabout way to do things for the scope of the program I included.

Thanks again Walter!

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



May 11, 2004
Why have you not used DMC++ for the Heron and C++? That way the comparison would be truer

"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
"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:c7rboo$1kqs$1@digitaldaemon.com...
> In article <c7r63p$1bv1$1@digitaldaemon.com>, christopher diggins says...
> >
> >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?
>
> If I have a container of objects that implement interface Printable(), how
does
> Heron determine which are type Circle and which are type Square, without
the use
> of a vtable?

Interface references contain an extra pointer to a dispatch table. So the dynamic dispatching is done when needed. The compiler ignores the interface references when it can deduce the concrete types.

> If the language cannot determine which type is which, then you should
remove the
> word "virtual" from the C++ version, and put "final" in the Java (and D?)

I do agree with you about the final keyword and I have done that to the D version, and I am going to do it in the Java version.

> versions:  if the container can only have one type of object, then C++
does not
> need the virtual keyword, and including it kind of "rigs" the demo, right?

You are correct, but Vector2D is used to demonstrate a class that is run-time polymorphic but happens to be used in a non-polymorphic manner. I could easily add to the demo a modification that forces the issue of polymorphism, but I thought it would complicate things too much. Do you recommend that I change the demo to make this more explicit?

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


May 11, 2004
Impressive speeds on Heron!  Id like to see so more benchmarks :).

C

On Tue, 11 May 2004 12:41:34 -0400, christopher diggins <cdiggins@users.sourceforge.net> 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
>
> TIA
May 11, 2004
"christopher diggins" <cdiggins@users.sourceforge.net> wrote in message news:c7rfbm$1q4l$1@digitaldaemon.com...
> Done and done. The final keywords sped it up even more from 710 to 610
msec.
>
> > > 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.
>
> What about the 4 bytes on top of that for the interfaces what are they
for?

Each interface derived from has a vptr allocated for it.

> Any plans on changing this in the future, or making a compile switch?

No, it's needed to get reasonable performance out of interfaces.

> > > 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.
>
> I won't be including that in the example then, it seems like too much of a roundabout way to do things for the scope of the program I included.
>
> Thanks again Walter!

You're welcome. You should also note that arrays have a built-in sort property, which uses quicksort. It'll blow away heapsort <g>. Doing that cuts the sort time on my machine from 453 ms to 63 ms. Source attached.




May 11, 2004
In article <c7rhdv$1t4h$1@digitaldaemon.com>, christopher diggins says... ..
>You are correct, but Vector2D is used to demonstrate a class that is run-time polymorphic but happens to be used in a non-polymorphic manner. I could easily add to the demo a modification that forces the issue of polymorphism, but I thought it would complicate things too much. Do you recommend that I change the demo to make this more explicit?

Heron's approach of non-inheritance binding is interesting;  I take it there is a global dispatch table with pointers to all methods appearing in non-deduceable cases?

I think the demo you have is good as far as it goes.  But I would be more interested to know what happens in both cases for both languages: i.e. C++ run-time and compile-time and Heron run-time and compile-time.  If Heron can outperform in *both* cases, that would be much more impressive.

But in (performance oriented code) in a language like C++, virtual-ness is usually used only when compile time binding is difficult to achieve.

Kevin


May 11, 2004
"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c7rgk8$1s1l$1@digitaldaemon.com...
> Why have you not used DMC++ for the Heron and C++? That way the comparison
would
> be truer


If all that would happen is make the heron and C++ code run slower (or faster) I don't really see the point. I am simply using the best compilers I have at my disposal. I also don't think it would make any difference to the whole point of the comparison which is that Heron implements more efficient object oriented code the other languages which support object oriented techniques.

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


May 11, 2004
"christopher diggins" <cdiggins@users.sourceforge.net> wrote in message news:c7rl11$22nr$1@digitaldaemon.com...
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c7rgk8$1s1l$1@digitaldaemon.com...
> > Why have you not used DMC++ for the Heron and C++? That way the
comparison
> would
> > be truer
>
>
> If all that would happen is make the heron and C++ code run slower (or faster) I don't really see the point. I am simply using the best compilers
I
> have at my disposal. I also don't think it would make any difference to
the
> whole point of the comparison which is that Heron implements more
efficient
> object oriented code the other languages which support object oriented techniques.

That depends on if point is really to compare inherent efficiency of the language, not the relative implementation vagaries of different compilers. DMD and DMC++ share a common optimizer and code generator.



May 12, 2004
> You're welcome. You should also note that arrays have a built-in sort property, which uses quicksort. It'll blow away heapsort <g>. Doing that cuts the sort time on my machine from 453 ms to 63 ms. Source attached.
>
I am wondering if the difference of execution time is the result of using different algorithms (quicksort or heapsort). Or can the code for the sort property be better optimized than a "normal" implementation of a sort algorithm?