May 13, 2004
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
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
"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
"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
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
"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
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
"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
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
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