Brad Anderson wrote:

> 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 site crushed my browser.  I also got the FF2 "runaway script, debug or stop" dialog.
> 
> A second visit once everything would theoretically be cached was no
> better. The google pageads were pretty slow, but things were crushed
> enough that even
> Firebug didn't respond very well.  So I couldn't tell if it was a bunch of
> Ajax calls or what was running so slowly.
> 
> BA

It works in mine FF2, but Konqueror only shows the background color, and says nothing about errors. Personally I would never bother to read that page, it was way too busy, I almost thought it was badly rendered at first.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Sean Kelly wrote:

> There is no debating the fact that C++ has been an incredible success, and it still has very little competition in many core markets. Personally, my only real problems with the language are that its popularity has driven it to be used in projects and by people where another language would be more suitable, and the language supports such a wide array of programming styles that it is extremely difficult to maintain any kind of design coherence in large team projects.  Also, its age is such that many projects contain code written before templates even existed, and so a substantial codebase follows "old style C++" which is heavy with raw pointers, casts, etc.  In fact, I'm continually amazed at how little new code I see even today that is written using STL components.  IMO this is a strong argument for D's built-in dynamic array support and other features, as there is no doubt in my mind that one of the major problems with C++ is that the language was standardized and in use before the library was up to snuff.  By integrating these features into the core language, Walter has neatly sidestepped this problem and provided a nice, clean syntax for some of the most commonly used programming constructs.

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.

Zz
> 
> Sean

zz wrote:
> 
> 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.

How long are these tests?  Could they be put online somewhere?  I'd be interested in trying these out for myself and see if I can close the gap a bit.


Sean

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.

-- 
- EricAnderton at yahoo

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.


Sean

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.

Sean, I'm pretty sure you've seen this before.  But just in case:

http://svn.dsource.org/projects/ddl/trunk/ddl/ExpContainer.d

It might give you (or others) a head-start along that path.


-- 
- EricAnderton at yahoo

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

Sean Kelly wrote:
> zz wrote:
> 
> How long are these tests?  Could they be put online somewhere?  I'd be interested in trying these out for myself and see if I can close the gap a bit.

The test were run about 20 times with the average taken.

The test was very simplistic and I'll send them to you tomorrow (I'm out of the office until tomorrow).

Generally it's a structure with three strings, and it's newed filled in and pushed back into the vector 1,000,000 times (we have higher).

I also did the same test in C using talloc which is a hierarchical pool based memory allocator using VS2003 and DMC and if I recall correctly these are the numbers:
VS2003 = 4.0 - 4.5
VS2003 with nedmalloc = 2.0 - 2.5
DMC = 6.5 - 7.5

Zz
> 
> Sean

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/

Wow.  Well that explains it then.

Sean, you should seriously check this thing out.  Maybe this could be adapted to be used in Ares?

-- 
- EricAnderton at yahoo

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/

Wow.  Well that explains it then.

Sean, you should seriously check this thing out.  Maybe this could be
adapted to be used in Ares?

[Edit:] The freshmeat article I found for nedmalloc calls it an "alternative malloc implementation for multiple threads without lock contention based on dlmalloc 2.8.3."  Suddenly, the speed increase is makes a lot more sense.

-- 
- EricAnderton at yahoo