View mode: basic / threaded / horizontal-split · Log in · Help
May 13, 2004
Re: D performance compared with other languages
Stewart Gordon wrote:

> J Anderson wrote:
> <snip>
>
>> If your talking
>
>
> My talking?
>
>> about the website I provided, did you read that shell sort was 
>> slightly broken?
>
>
> No.  I still don't.  Where's that little bit of info buried then?
>
> Stewart.
>
Whoops, your right.  Its the swap sort that is broken.

-- 
-Anderson: http://badmama.com.au/~anderson/
May 13, 2004
Re: D performance compared with other languages
Kevin Bealer wrote:
> In a GC program, you can avoid GC overhead by keeping free lists of
> anything you
> allocate.  The garbage collector won't run because you aren't calling
> new().
> This was a tip for "real time" programming.  Note that you are avoiding
> benefit
> #1 of a garbage collector: not having to manage delete[] yourself.  You
> #also run
> the risk of old pointers to supposedly "new" objects, if it wasn't ready
> to be
> deleted.  On the plus side, if you are not sure its garbage, dont put it
> on the list: the GC will eventually hunt it down if you are, in fact,
> leaking.

Any "modern" general-purpose allocator already does this since the late 80s.
Preventing free space fragmentation turns out to be the bigger problem.

Besides, if you keep a free list, then you're into having to play "God" with
object ctor and dtor. :-)
May 13, 2004
Re: D performance compared with other languages
"Walter" <newshound@digitalmars.com> wrote in message
news:c7u37p$2m0t$1@digitaldaemon.com...
>
> "christopher diggins" <cdiggins@users.sourceforge.net> wrote in message
> news:c7t5qi$19oe$1@digitaldaemon.com...
> > In retrospect, I am starting to be of the opinion that the example may
> fact
> > rigged as you mentioned. There is no way that I can justify a design
that
> > uses ICompare as a class with virtual functions.
>
> I'd also be careful about the GetMagnitude() function. The time spent in
the
> two multiplies may swamp other effects. I've seen many benchmark programs
> that purport to measure X, when they actually are measuring Y that the
> benchmark writer thought was innocuous. Compiler vendors have been known
to
> exploit these naive benchmarks by optimizing the heck out of Y (which may
be
> much easier than optimizing X), and letting the benchmark reporter
> misinterpret it into saying that X was optimized.
>
> I've even seen crafty vendors create benchmarks specifically to mislead
> people into thinking X was being optimized when it was actually Y. (This
is
> why I tend to not bother creating benchmarks for any but my own use, I
like
> to use benchmarks written by people not affiliated with DM to avoid even
the
> appearance of impropriety.)
>
> In your benchmark, I'd check the multiplies, I'd also check to see if
maybe
> one compiler does a better job of function inlining or register allocation
> before concluding that the speed difference is due to virtual dispatch.
> Running a disassembler over the generated code and being familiar with
> performance assembler coding is essential. The results can be quite
> surprising.


You make some excellent points. I have written a brand new benchmark, which
only has increments, decrements, == and function calls. Hopefully this is
more accurate. Unfortunately I am too slow and clumsy with assembler to be
able to do any disassembly, hopefully someone else will come along and do
it.

-- 
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com
May 13, 2004
Re: D performance compared with other languages
"Walter" <newshound@digitalmars.com> wrote in message
news:c7rn04$25r5$1@digitaldaemon.com...
>
> "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.


I am now convinced and the new example (
http://www.heron-language.com/benchmarks/index.html ) uses only the Digital
mars compilers.

-- 
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com
May 13, 2004
Re: D performance compared with other languages
In article <c8075s$1ff$1@digitaldaemon.com>, Scott Michel says...
>
>Kevin Bealer wrote:
>> In a GC program, you can avoid GC overhead by keeping free lists of
>> anything you
>> allocate.  The garbage collector won't run because you aren't calling
>> new().
>> This was a tip for "real time" programming.  Note that you are avoiding
>> benefit
>> #1 of a garbage collector: not having to manage delete[] yourself.  You
>> #also run
>> the risk of old pointers to supposedly "new" objects, if it wasn't ready
>> to be
>> deleted.  On the plus side, if you are not sure its garbage, dont put it
>> on the list: the GC will eventually hunt it down if you are, in fact,
>> leaking.
>
>Any "modern" general-purpose allocator already does this since the late 80s.
>Preventing free space fragmentation turns out to be the bigger problem.
>
>Besides, if you keep a free list, then you're into having to play "God" with
>object ctor and dtor. :-)

I've usually heard that phrase when talking about cloning or life/death
issues... I'm not sure what rights are reserved to God when talking about
writing software...  If you mean that the free list can run very large and hog
memory, you can of course provide a size bound.  If it gets over N elements,
clear the "top" pointer, or selectively drop elements down to N.

Regarding fragmentation: does the D collector actually copy collect, or does it
need to be conservative?  I would suspect that using C pointers and copy
collection are two great tastes that don't taste great together.

Kevin
May 13, 2004
Re: D performance compared with other languages
"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
news:c7vnbp$2bvs$1@digitaldaemon.com...
>  I wish D
> templates could accept operators/functions as parameters.

It can accept functions as parameters - both as function pointers, and as
aliases.
May 14, 2004
Re: D performance compared with other languages
Walter wrote:

>"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
>news:c7vnbp$2bvs$1@digitaldaemon.com...
>  
>
>> I wish D
>>templates could accept operators/functions as parameters.
>>    
>>
>
>It can accept functions as parameters - both as function pointers, and as
>aliases.
>  
>
Cool, now for operators....

-- 
-Anderson: http://badmama.com.au/~anderson/
May 14, 2004
Re: D performance compared with other languages
"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
news:c81tqo$2h9g$1@digitaldaemon.com...
> Walter wrote:
>
> >"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
> >news:c7vnbp$2bvs$1@digitaldaemon.com...
> >
> >
> >> I wish D
> >>templates could accept operators/functions as parameters.
> >>
> >>
> >
> >It can accept functions as parameters - both as function pointers, and as
> >aliases.
> >
> >
> Cool, now for operators....

You can use the equivalent name for the operator functions.
May 17, 2004
Re: D performance compared with other languages
Kevin Bealer wrote:

> In article <c8075s$1ff$1@digitaldaemon.com>, Scott Michel says...
> 
>>Any "modern" general-purpose allocator already does this since the late 80s.
>>Preventing free space fragmentation turns out to be the bigger problem.
>>
>>Besides, if you keep a free list, then you're into having to play "God" with
>>object ctor and dtor. :-)
> 
> 
> I've usually heard that phrase when talking about cloning or life/death
> issues... I'm not sure what rights are reserved to God when talking about
> writing software...  If you mean that the free list can run very large and hog
> memory, you can of course provide a size bound.  If it gets over N elements,
> clear the "top" pointer, or selectively drop elements down to N.

My point was that you become responsible for object lifetimes; you're 
responsible for their proper birth and death (and possibly inadvertant 
ressurection... ok, bad pun sequence.) So keeping your own free list means 
that you might have faster allocation, but you now become responsible for a 
lot more than just allocation. But as I pointed out, modern mallocs already 
do this.

> Regarding fragmentation: does the D collector actually copy collect, or does it
> need to be conservative?  I would suspect that using C pointers and copy
> collection are two great tastes that don't taste great together.

Wrong type of fragmentation. :-)

This happens when the allocator doesn't have specifically sized areanas for 
certain sized allocations (usually powers of 2, n > 4). If the allocator 
just tries to find the best fit, breaking up previously allocated blocks 
without coalescing adjacent freespace, you end up with a very fragmented 
memory map.


-scooter
May 18, 2004
Re: D performance compared with other languages
In article <c8bg4j$1a4b$1@digitaldaemon.com>, -scooter- says...
>
>Kevin Bealer wrote:
>
>> In article <c8075s$1ff$1@digitaldaemon.com>, Scott Michel says...
>> 
>>>Any "modern" general-purpose allocator already does this since the late 80s.
>>>Preventing free space fragmentation turns out to be the bigger problem.
>>>
>>>Besides, if you keep a free list, then you're into having to play "God" with
>>>object ctor and dtor. :-)
>> 
>> 
>> I've usually heard that phrase when talking about cloning or life/death
>> issues... I'm not sure what rights are reserved to God when talking about
>> writing software...  If you mean that the free list can run very large and hog
>> memory, you can of course provide a size bound.  If it gets over N elements,
>> clear the "top" pointer, or selectively drop elements down to N.
>
>My point was that you become responsible for object lifetimes; you're 
>responsible for their proper birth and death (and possibly inadvertant 
>ressurection... ok, bad pun sequence.) So keeping your own free list means 
>that you might have faster allocation, but you now become responsible for a 
>lot more than just allocation. But as I pointed out, modern mallocs already 
>do this.

Okay, that makes sense.

>> Regarding fragmentation: does the D collector actually copy collect, or does it
>> need to be conservative?  I would suspect that using C pointers and copy
>> collection are two great tastes that don't taste great together.
>
>Wrong type of fragmentation. :-)
>
>This happens when the allocator doesn't have specifically sized areanas for 
>certain sized allocations (usually powers of 2, n > 4). If the allocator 
>just tries to find the best fit, breaking up previously allocated blocks 
>without coalescing adjacent freespace, you end up with a very fragmented 
>memory map.

I was thinking "locality".  Okay, this makes sense.  Yeah, you can use a large
program allocator that uses a large number of free lists and chops up blocks
(completely unsuitable for small, memory tight, programs), or you can use
small-piece allocators and tolerate fragmentation.  The ugliest way is to tweak
the algorithm to use the same sized object (by making buffers a certain size).

Kevin

>
>-scooter
2 3 4 5 6 7
Top | Discussion index | About this forum | D home