April 08, 2012
On 4/8/12 5:57 PM, Manu wrote:
> On 8 April 2012 23:44, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@erdani.org>>
> wrote:
>     Anyhow, the recent discussions on Go clarify that we need to improve
>     our collector's precision, and pronto. The only thing that didn't
>     yet make the problem more painful in D is that D programs create a
>     lot less garbage.
>
>
> What do you base that statistic on?

"A lot less" is hardly a statistic :o).

> I'm not arguing that fact, just that
> I haven't seen any evidence one way or the other. What causes Go to
> create significantly more garbage than D?

As Walter mentioned, Go uses indirection and implicit allocation for its fundamental abstraction mechanisms. D has elaborate value types, the scope statement, and pass-by-alias, all of which drastically reduce the amount of garbage created.


Andrei
April 09, 2012
On 9 April 2012 02:24, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/8/2012 3:57 PM, Manu wrote:
>
>> What do you base that statistic on? I'm not arguing that fact, just that I
>> haven't seen any evidence one way or the other. What causes Go to create
>> significantly more garbage than D? Are there benchmarks or test cases I
>> should
>> be aware of on the topic?
>>
>
> The first ycombinator reference is a person who didn't run out of memory using D. That implies far less pressure on the gc.
>
> My understanding of Go is that when it does structural conformance, it builds some of the necessary data at runtime on the gc heap.
>
> Anyhow, D has a lot of facilities for putting things on the stack rather than the heap, immutable data doesn't need to get copied, and slices allow lots of reuse of existing objects.
>

"optimized D was slightly faster than Go at almost anything and consumed up
to 70% less memory"
Interesting... I don't know enough about Go to reason that finding, I guess
I assumed it has most of the same possibilities available to D. (no
immutable data? no stack structs? no references/pointers/slices? crazy...)

The only D program I have significant experience with is VisualD, and it
hogs 1-2gb of ram for me under general usage, and eventually crashes, after
paging heavily and bringing my computer to a crawl. Not a good sign from
the first and only productive D app I've run yet ;)
This seems a lot like his experience with Go... but comparisons aside, D
still clearly isn't there yet when it comes to the GC either, and I'm
amazed Google thing Go is production ready if that guys findings are true!


April 09, 2012
On 4/9/12, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> and pass-by-alias

Speaking of alias, one killer feature would be to enable using alias for expressions. E.g.:

struct Window { struct Point { int x, y; } Point point; }
void test() {
    Window window;
    alias window.point.x x;
    // use 'x' here which is really window.point.x
}

It makes it simpler to manipulate nested structs and their fields by reference without involving pointers or using with statements. AFAIK C++ can use references for this purpose (ala &int x = window.point.x;), but I guess this isn't very efficient unless the compiler can optimize it.

Besides myself I've also seen other people request it (I think Nick S.
wanted the feature).
April 09, 2012
On 09-04-2012 02:18, Manu wrote:
> On 9 April 2012 02:24, Walter Bright <newshound2@digitalmars.com
> <mailto:newshound2@digitalmars.com>> wrote:
>
>     On 4/8/2012 3:57 PM, Manu wrote:
>
>         What do you base that statistic on? I'm not arguing that fact,
>         just that I
>         haven't seen any evidence one way or the other. What causes Go
>         to create
>         significantly more garbage than D? Are there benchmarks or test
>         cases I should
>         be aware of on the topic?
>
>
>     The first ycombinator reference is a person who didn't run out of
>     memory using D. That implies far less pressure on the gc.
>
>     My understanding of Go is that when it does structural conformance,
>     it builds some of the necessary data at runtime on the gc heap.
>
>     Anyhow, D has a lot of facilities for putting things on the stack
>     rather than the heap, immutable data doesn't need to get copied, and
>     slices allow lots of reuse of existing objects.
>
>
> "optimized D was slightly faster than Go at almost anything and consumed
> up to 70% less memory"
> Interesting... I don't know enough about Go to reason that finding, I
> guess I assumed it has most of the same possibilities available to D.
> (no immutable data? no stack structs? no references/pointers/slices?
> crazy...)
>
> The only D program I have significant experience with is VisualD, and it
> hogs 1-2gb of ram for me under general usage, and eventually crashes,
> after paging heavily and bringing my computer to a crawl. Not a good
> sign from the first and only productive D app I've run yet ;)
> This seems a lot like his experience with Go... but comparisons aside, D
> still clearly isn't there yet when it comes to the GC either, and I'm
> amazed Google thing Go is production ready if that guys findings are true!

Google likes to invent random useless languages. See: Dart. Both languages are solutions looking for problems. ;)

And yes, precise GC is more essential than most people think.

-- 
- Alex
April 09, 2012
On 4/8/12 7:21 PM, Andrej Mitrovic wrote:
> On 4/9/12, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
>> and pass-by-alias
>
> Speaking of alias, one killer feature would be to enable using alias
> for expressions. E.g.:
>
> struct Window { struct Point { int x, y; } Point point; }
> void test() {
>      Window window;
>      alias window.point.x x;
>      // use 'x' here which is really window.point.x
> }

Yah, we should add that at some point. Walter and I discussed about it and it's virtually approved. But to be on the conservative side, it's not for expressions but for mere pointer-chasing chains.

Andrei

April 09, 2012
On 9 April 2012 03:21, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 4/9/12, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> > and pass-by-alias
>
> Speaking of alias, one killer feature would be to enable using alias for expressions. E.g.:
>
> struct Window { struct Point { int x, y; } Point point; }
> void test() {
>    Window window;
>    alias window.point.x x;
>    // use 'x' here which is really window.point.x
> }
>
> It makes it simpler to manipulate nested structs and their fields by reference without involving pointers or using with statements. AFAIK C++ can use references for this purpose (ala &int x = window.point.x;), but I guess this isn't very efficient unless the compiler can optimize it.
>

I can't think of many cases where the compiler can't optimise it when used in the context you describe.


Besides myself I've also seen other people request it (I think Nick S.
> wanted the feature).
>

I probably wouldn't have thought to use alias in that way, I probably would
have asked to be able to use 'ref' on any declaration...
I do also get a little annoyed having to use pointers in this situation. At
least they don't suffer a different dereference syntax like C, but it does
seem a bit flimsy that they can be reassigned, can also be null, and I have
to involve the & operator, which can often lead to parentheses spam.

(...why can't you use 'ref' in regular declarations? I frequently find myself wanting to use ref locally for this exact reason.)


April 09, 2012
On 9 April 2012 03:25, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>wrote:

> On 4/8/12 7:21 PM, Andrej Mitrovic wrote:
>
>> On 4/9/12, Andrei Alexandrescu<SeeWebsiteForEmai**l@erdani.org<SeeWebsiteForEmail@erdani.org>>
>>  wrote:
>>
>>> and pass-by-alias
>>>
>>
>> Speaking of alias, one killer feature would be to enable using alias for expressions. E.g.:
>>
>> struct Window { struct Point { int x, y; } Point point; }
>> void test() {
>>     Window window;
>>     alias window.point.x x;
>>     // use 'x' here which is really window.point.x
>> }
>>
>
> Yah, we should add that at some point. Walter and I discussed about it and it's virtually approved. But to be on the conservative side, it's not for expressions but for mere pointer-chasing chains.


Why use alias, instead of allowing 'ref' on local declarations?
The alias approach suffers from complications when referencing a complex
expression. Particularly if that expression involves a non-pure function
call. A local ref would seem less problematic to me?


April 09, 2012
On 4/9/12, Manu <turkeyman@gmail.com> wrote:
> (...why can't you use 'ref' in regular declarations? I frequently find myself wanting to use ref locally for this exact reason.)

I think the reason for this was because references are supposed to be hidden from the user.

But if you look it from a safety angle you can escape a reference to a
local variable (ends up being garbage after function exit), but you
can't escape an alias declaration (I think so anywho).
April 09, 2012
Am Mon, 9 Apr 2012 03:38:15 +0300
schrieb Manu <turkeyman@gmail.com>:

> On 9 April 2012 03:25, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>wrote:
> 
> > On 4/8/12 7:21 PM, Andrej Mitrovic wrote:
> >
> >> On 4/9/12, Andrei Alexandrescu<SeeWebsiteForEmai**l@erdani.org<SeeWebsiteForEmail@erdani.org>>
> >>  wrote:
> >>
> >>> and pass-by-alias
> >>>
> >>
> >> Speaking of alias, one killer feature would be to enable using alias for expressions. E.g.:
> >>
> >> struct Window { struct Point { int x, y; } Point point; }
> >> void test() {
> >>     Window window;
> >>     alias window.point.x x;
> >>     // use 'x' here which is really window.point.x
> >> }
> >>
> >
> > Yah, we should add that at some point. Walter and I discussed about it and it's virtually approved. But to be on the conservative side, it's not for expressions but for mere pointer-chasing chains.
> 
> 
> Why use alias, instead of allowing 'ref' on local declarations?
> The alias approach suffers from complications when referencing a complex
> expression. Particularly if that expression involves a non-pure function
> call. A local ref would seem less problematic to me?

This is a valid concern. I remember the discussion from a while back. alias makes it _look_ shorter and right, but you get what Manu said. Here is another look on it:

MyClass a = foo();
MyClass x = bar();
alias a.c c1;
ref c2 = a.c;
a = x;
c1 = 5; // <- oops, using x instead of a
c2 = 5; // <- more what I expect

Not to say alias for 'moving' targets is a no-go, but I'd rather proper refs. :)

-- 
Marco

April 09, 2012
On 9 April 2012 04:09, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 4/9/12, Manu <turkeyman@gmail.com> wrote:
> > I don't follow. Can you give an example that shows this insecurity?
>
> I mean escaping references to locals:
>
> ref int xref;
> void foo() {
>   int x;
>   xref = x;
> }
>
> or
>
> ref int foo() {
>   int x;
>   ref int xref = x;
>   return xref;
> }
>
> I mean a ref would basically be a pointer with some syntax sugar, no? It would have the same drawbacks as a pointer.
>

Nobody returns a ref to a local from a function, and the compiler can
easily warn about that.
Sure, but that's all this was ever meant to be right? alias as a sugar to
simplify long expressions... except alias is unsafe too, but in a different
and more subtle way.