zz wrote:
> I agree with everything you mention above but there are cases where C++ will just be a better due to performance and nothing else.
> 
> I did some work in D recently that is being used at a client's place and it took about 2 hours to design and write (it's was not something that was performance critical), one of my work mates got interested in D and for the sake of curiosity we ran some test comparing D's built in arrays with boost::ptr_vector which we use quite a lot and the results were as follows:
> VS2003 = ~3.75 secs
> VS2003 with NedMalloc = ~1.35 secs
> DMD = ~ 7 secs
> We could not get DMC to compile Nedmalloc so we dropped testing DMC with c++.
> 
> While he liked that language and said the he might actually use it to prototype idea's, he will not use it in production code due to the performance.
> 
> Conclusions:
> D is great, but DMD will have to do something about it's performance for some applications.

There are many possible explanations for this, and not all of them are because C++ has better performance. We need to see the code and the compiler switches used.

Here's a case where D is substantially faster than C++: http://www.digitalmars.com/d/cppbench.html

zz wrote:
> Pragma wrote:
>> zz wrote:
>>
>>
>> While I'm no STL guru, I have to ask: which allocator were you using with ptr_vector?
>>
> For the first number we used VS2003 SMT CRT (Default allocator)
> With the other test we used nedmalloc as the allocator (just over load new and delete in C++ (it's a c library).
> 
> http://www.nedprod.com/programs/portable/nedmalloc/
> 
> Zz

I was going to ask why he didn't compare his algorithm with dlmalloc, but I see it actually is based on dlmalloc.  So I wonder what exactly the differences is between this and dlmalloc.

Incidentally I know this guy from his posts on the FOX mailing lists. He's been working on this thing called Tn[1] for about 10 years.  He's either insane or brilliant I can't really tell.  :-) Read the description of "What is Tn" to see what I mean.

[1] http://www.nedprod.com/Tn/index.html

--bb

> 
> Here's a case where D is substantially faster than C++: http://www.digitalmars.com/d/cppbench.html

bad link

Walter Bright wrote:
> 
> There are many possible explanations for this, and not all of them are because C++ has better performance. We need to see the code and the compiler switches used.

Walter, it's not a C++ vs D issue (I preffer D) it's a compiler/library issue.

I don't claim C++ has better performance, but that VS2003 does a better job than DMC/DMD when there lot of memory allocations and even better when combined with nedmalloc.

> Here's a case where D is substantially faster than C++: http://www.digitalmars.com/d/cppbench.html

I'll have to run it under VS2003 or VS2005.

I'll post the trivial test we did tommorow, but in another test in C using VS2003 default allocator, the same code was much faster in VS2003 under release then in DMC -o.

In the test we are doing new is called 1,000,000 times and the result put into a boost::ptr_vector in c++.

Zz

BCS wrote:
>>
>> Here's a case where D is substantially faster than C++: http://www.digitalmars.com/d/cppbench.html
> 
> 
> bad link
http://www.digitalmars.com//d/cppstrings.html

Zz

Bill Baxter wrote:
> I was going to ask why he didn't compare his algorithm with dlmalloc, but I see it actually is based on dlmalloc.  So I wonder what exactly the differences is between this and dlmalloc.

nedmalloc actually uses dlmalloc underneath.

> Incidentally I know this guy from his posts on the FOX mailing lists. He's been working on this thing called Tn[1] for about 10 years.  He's either insane or brilliant I can't really tell.  :-) Read the description of "What is Tn" to see what I mean.

It's a very thin line between the two, but we use nedmalloc internally and at least there I would have to claim that he is brilliant.

Zz

> [1] http://www.nedprod.com/Tn/index.html
> 
> --bb

John Reimer wrote:
> On Tue, 05 Dec 2006 08:55:09 -0800, Pragma <ericanderton@yahoo.removeme.com> wrote:
> 
>> Something I ran into that the group might enjoy:
>>
>> From: http://www.techreview.com/InfoTech/17831/
>>
> 
> Off-topic observation:
> 
> I love the way the threading works in the comments section of this article!  You just click on the comment and it immediatly shows the comment text.  Clicking it again collapses it. You can do that for each comment. Now that's a great system!  To bad the D newsgroup couldn't do something like that for its web interface.
> 
> -JJR
> 

AJAX ruulz baby!!

Pragma wrote:
> John Reimer wrote:
>> On Tue, 05 Dec 2006 08:55:09 -0800, Pragma <ericanderton@yahoo.removeme.com> wrote:
>>
>>> Something I ran into that the group might enjoy:
>>>
>>> From: http://www.techreview.com/InfoTech/17831/
>>>
>>
>> Off-topic observation:
>>
>> I love the way the threading works in the comments section of this article!  You just click on the comment and it immediatly shows the comment text.  Clicking it again collapses it. You can do that for each comment. Now that's a great system!  To bad the D newsgroup couldn't do something like that for its web interface.
>>
>> -JJR
>>
> 
> It's a nice concept, but (IMO) it makes for slow reading if you want to digest an entire thread on-page.  I'd much rather see the posts in full, but have the tree kept for expanding and collapsing threads as I go.
> 
> Kind of like a compromise between a TreeView and Slashdot I suppose.
> 
> Now, if you want to see something *really slick* for commenting, take a look at JackSlocum's site:
> 
> http://www.jackslocum.com/blog/2006/10/09/my-wordpress-comments-system-built-with-yahoo-ui-and-yahooext/ 
> 
> 
> It's pretty script-heavy, but it shows what can be done with AJAX and a solid widget set.  Be sure to check out the "Documentation" section too.
> 

That baby is too slow ... my FF2 had to suffer before opening it ..

Sean Kelly wrote:
> Pragma wrote:
>> zz wrote:
>>>
>>> Conclusions:
>>> D is great, but DMD will have to do something about it's performance for some applications.
>>
>> I tend to agree.  D's array allocation algorithm, as well as it's GC behavior, are great for most cases.  But they can fall flat in certain cases - of course that's true of any algorithm really. :)
>>
>> While I'm no STL guru, I have to ask: which allocator were you using with ptr_vector?
>>
>> I know that with D, pre-allocating data for arrays can make a big difference if you expect to perform a lot of concatenations - especially with atomic elements like pointers or references.
> 
> I still find this confusing.  The GC uses "power of two" sized blocks up to page size where the grow strategy kicks in, so it should already be using "double my current size" allocation behind the scenes.  But I suppose I should really spend some time testing this to see if it can be improved.  One slightly crazy idea that's been kicked around is to allow the user to override the default grow strategy, but that only seems useful if the default one really isn't appropriate for most situations, and I'm hoping that testing plus perhaps some tweaks to the algorithm will obviate the need for this.
> 

If concatenating to the vector is the bottleneck, they may have been concatenating to the D 'vector' with arr = arr ~ elem; instead of arr ~= elem;? In that case it wouldn't be preallocating, but creating a bunch of temporaries.

Just a guess.

If that's the case, wouldn't if be pretty 'easy' and safe to optimize the built-in?

> 
> Sean

I don't see why D doesn't use nedmalloc for its non-GC malloc implementation.  This would allow expert developers that avoid GC in certain situations glean the best performance possible.

-Craig

"zz" <zz@zz.com> wrote in message news:el51rm$2cth$1@digitaldaemon.com...
> Walter Bright wrote:
>>
>> There are many possible explanations for this, and not all of them are because C++ has better performance. We need to see the code and the compiler switches used.
>
> Walter, it's not a C++ vs D issue (I preffer D) it's a compiler/library issue.
>
> I don't claim C++ has better performance, but that VS2003 does a better job than DMC/DMD when there lot of memory allocations and even better when combined with nedmalloc.
>
>> Here's a case where D is substantially faster than C++: http://www.digitalmars.com/d/cppbench.html
>
> I'll have to run it under VS2003 or VS2005.
>
> I'll post the trivial test we did tommorow, but in another test in C using VS2003 default allocator, the same code was much faster in VS2003 under release then in DMC -o.
>
> In the test we are doing new is called 1,000,000 times and the result put into a boost::ptr_vector in c++.
>
> Zz