On 24.04.2009 08:24, dennis luehring wrote:
> dennis luehring schrieb:
>> Andrei Alexandrescu schrieb:
>>> dennis luehring wrote:
>>>> Andrei Alexandrescu schrieb:
> does that also mean that strings are getting template based?
>
> what amount of debug-code will produce this? like with the stl (or
> boost) - zillion megabytes for 9 lines of code? and i can throw away my
> debugger (if D will get a good one)
>
> im always shocked when looking at the stl/boost based assembler code in
> debug releases - does D generate less code?

but i still like the idea of getting more generic at the base :-)
the result will less special cases for the compiler and no that-can-only-the-compiler-do scenarios

but the downside - are the error messages then still that informative
and what is the code bloat in the end - but maybe walter found a way to
code-specialize the Array!/Assoc! (i hope to see better initalizers then - maybe static ones :-]) stuff for the standard datatypes - and then everything is fine ...

still waiting for D 3 - the concurrency wonderland ...

On Fri, 24 Apr 2009 11:57:45 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Christian Kamm wrote:
>> Andrei Alexandrescu Wrote:
>>> 1. Put array definitions in object.d. Have the compiler rewrite "T[]" ->
>>> ".Array!(T)" and "[ a, b, c ]" -> ".Array!(typeof(a))(a, b, c)". I think
>>> superdan suggested that when he wasn't busy cursing :o).
>>  While I'd support such a rewriting of builtin arrays and associative arrays,
>> it comes at a cost: one template instantiation per contained type, which will lead to more code and TypeInfo / ClassInfo initializers than the current
>> implementation requires.
>>  Can you come up with a solution that can seamlessly switch between RTTI
>> based containers and templated containers?
>
> Good question. I don't know how the typeinfo could go away, but right now we're in that boat already - each T[] has its own typeinfo. Implementation-wise, there are techniques to reduce code bloating.

Yes, but each T[] does not have it's own sort routine.  With a template, that would not be the case (I think).  Not that I think the current way is the best, just pointing out a difference.

-Steve

On Thu, 23 Apr 2009 13:58:38 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> [snip]

Yes please. D's GC sometimes just gets in the way, and you end up managing most memory manually.

Just don't forget to have a version(nogc) !

-- 
Best regards,
 Vladimir                          mailto:thecybershadow@gmail.com

dennis luehring wrote:
> On 24.04.2009 08:24, dennis luehring wrote:
>> dennis luehring schrieb:
>>> Andrei Alexandrescu schrieb:
>>>> dennis luehring wrote:
>>>>> Andrei Alexandrescu schrieb:
>> does that also mean that strings are getting template based?
>>
>> what amount of debug-code will produce this? like with the stl (or
>> boost) - zillion megabytes for 9 lines of code? and i can throw away my
>> debugger (if D will get a good one)
>>
>> im always shocked when looking at the stl/boost based assembler code in debug releases - does D generate less code?
> 
> but i still like the idea of getting more generic at the base :-) the result will less special cases for the compiler and no that-can-only-the-compiler-do scenarios
> 
> but the downside - are the error messages then still that informative and what is the code bloat in the end - but maybe walter found a way to code-specialize the Array!/Assoc! (i hope to see better initalizers then - maybe static ones :-]) stuff for the standard datatypes - and then everything is fine ...
> 
> still waiting for D 3 - the concurrency wonderland ...

Let's take an example.  Code for Array!(char) and Array!(ubyte) are probably going to be exactly identical.  Of course, it's very hard for the compiler to know that.  It sees two distinct types.  Simply looking at the template arguments doesn't help thanks to static if.

The real question is: is the generated machine code identical?  If it is, there's probably no benefit in having multiple versions of it.

I know it's been said a bazillion times already, but maybe we should look at replacing OPTLINK, and adding a "collapse identical code sections" option while we're at it.  :P

  -- Daniel

== Quote from Daniel Keep (daniel.keep.lists@gmail.com)'s article
> I know it's been said a bazillion times already, but maybe we should look at replacing OPTLINK, and adding a "collapse identical code sections" option while we're at it.  :P

Fixing optlink is a worthy goal, but that is only one platform. D has to work with linkers on many platforms, and relying on such a solution existing across linkers we have no control over is not practical.

Well, if they're in the same section, the compiler _could_ detect this itself, couldn't it?  I mean, it already does an optimization pass before the codegen, it could theoretically do another collapse pass after that.

I don't know how easy that would be, or if it would be worth it, but it would cover all platforms at that point.

-[Unknown]


Walter Bright wrote:
> == Quote from Daniel Keep (daniel.keep.lists@gmail.com)'s article
>> I know it's been said a bazillion times already, but maybe we should
>> look at replacing OPTLINK, and adding a "collapse identical code
>> sections" option while we're at it.  :P
> 
> Fixing optlink is a worthy goal, but that is only one platform. D has to work with
> linkers on many platforms, and relying on such a solution existing across linkers
> we have no control over is not practical.
> 

Robert Fraser, el 24 de abril a las 07:55 me escribiste:
> Andrei Alexandrescu wrote:
> >There shouldn't be any harm in using Array or AssocArray directly.
> 
> How about __Array or something? I already have a struct Array!()

How about std.array.Array or something?

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Are you such a dreamer?
To put the world to rights?
I'll stay home forever
Where two & two always
makes up five

Andrei Alexandrescu, el 23 de abril a las 13:27 me escribiste:
> Leandro Lucarella wrote:
> >And may I ask what it would happen if I do this with your "-nogc"
> >proposal?
> >class A
> >{
> >	B b;
> >}
> >class B
> >{
> >	A a;
> >}
> >A a = new A;
> >a.b = new B;
> >a.b.a = a;
> >? Wont this leak? Are you planning to make a backup tracing collector to
> >fix cycles maybe? Because I don't think using a naive reference counting
> >will avoid leaks as easy as you put it...
> >RC is not *that* simple.
> 
> Oh I absolutely agree. In short, what happens depends on how Ref is implemented. In essence what I suggest is not (a simplified method of) reference counting, it's a hook that allows various allocation/collection strategies to be implemented by knowledgeable people (hint,  hint) :o).

I think it would be awesome to have some kind of hooks to instrument references read/writes so one can implement RC-based, partition-based GC (like generational) or incremental collectors.

There were a proposal to make that some time ago by Frank Benoit: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=35426

He proposed to add these hooks, with the default implementation being:
___ref_assign( void * trg, void * src ){ trg = src; }
void* ___ref_read( void * src ){ return src; }

I think you proposal of wrapping read/writes into a library defined type is an improvement over the Frank's proposal.

(other proposals in that very same mail are as interesting as the
read/write instrumentation)

> I think WeakRef!T would also have to be part of the offering inside object_whatever.d. Then the example above can be fixed for the refcounting case by making one of the references weak.

I think WeakRef!T should be part of the GC, not object.d. The same goes for Ref!T.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Hey you, with you ear against the wall
Waiting for someone to call out
Would you touch me?