April 08, 2012 Re: Discussion on Go and D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | 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 Re: Discussion on Go and D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright Attachments:
| 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 Re: Discussion on Go and D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 Re: Discussion on Go and D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | 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 Re: Discussion on Go and D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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 Re: Discussion on Go and D | ||||
---|---|---|---|---|
| ||||
Attachments:
| 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 Re: Discussion on Go and D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu Attachments:
| 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 Re: Discussion on Go and D | ||||
---|---|---|---|---|
| ||||
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 Re: Discussion on Go and D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | 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 Re: Discussion on Go and D | ||||
---|---|---|---|---|
| ||||
Attachments:
| 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.
|
Copyright © 1999-2021 by the D Language Foundation