www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bottom line re GC in D

reply "Adrian" <adrian777 on-vol-dot.net> writes:
Hi all,

I know there's been quite some discussion about the GC in D, but 
I've been busy doing other things and haven't been following that 
closely.

So I'd appreciate it if someone could fill me in about 
proceedings/decisions in this regard...

  + Has the GC been dropped?
  + If not, can it be disabled entirely/completely?

D has always greatly impressed me, but I need a systems language 
without garbage collection; has D become that now?

Thanks in advance for any responses.
Adrian.
Jul 07 2014
next sibling parent reply "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Tuesday, 8 July 2014 at 03:37:51 UTC, Adrian wrote:

  + Has the GC been dropped?


Nope, still there and probably always will be. I think I read on 
the forums that people are working on a better/more precise GC 
though. From what I understand the current one could stand a lot 
of improvement.


  + If not, can it be disabled entirely/completely?


It can be, but you would also lose some features, though I'm not 
entirely sure which things exactly. I remember that slices was 
one thing you would no longer have if you disable the GC, but I 
can't think of any others.


The GC isn't really something you would need to disable though. I 
have never had any issues with it, and unless you're doing 
something that might have it run a lot, it shouldn't affect you 
in any way.
Jul 07 2014
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 8 July 2014 at 06:23:13 UTC, Jeremy DeHaan wrote:


 I remember that slices was one thing you would no longer have 
 if you disable the GC, but I can't think of any others.


You can definitely use slices without the GC and they are still 
awesome without the GC.
What you cannot do is create them with `new` or call the builtin 
~ or ~= (concatenate and append respectively) operators on 
slices. Slice literals may also cause allocations, but not always:

enum ctA = [3, 4];

void main()  nogc // nogc is transitive, marking main as  nogc
                   //enforces no GC activity in the entire program.
{
     //these statements are all guaranteed not to GC-allocate
     int[2] a = [1, 2];
     assert(a[0] == 1 && a[1] == 2);
     a = ctA;
     assert(a[0] == 3 && a[1] == 4);
     assert(a == [3,4]);

     import core.stdc.stdlib;
     auto data = cast(int*)calloc(100_000, int.sizeof);
     auto callocedSlice = data[0 .. 100_000];
     auto subSlice = callocedSlice[40 .. $ - 600];

     //these cause GC allocation and as such
     //will not compile in an  nogc function.
//    int[] s0 = [1, 2];
//    auto s1 = [3,4];
}
Jul 08 2014
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 8 July 2014 at 11:22:42 UTC, John Colvin wrote:

 On Tuesday, 8 July 2014 at 06:23:13 UTC, Jeremy DeHaan wrote:


 I remember that slices was one thing you would no longer have 
 if you disable the GC, but I can't think of any others.


 You can definitely use slices without the GC and they are still 
 awesome without the GC.
 What you cannot do is create them with `new` or call the 
 builtin ~ or ~= (concatenate and append respectively) operators 
 on slices. Slice literals may also cause allocations, but not 
 always:

 enum ctA = [3, 4];

 void main()  nogc // nogc is transitive, marking main as  nogc
                   //enforces no GC activity in the entire 
 program.
 {
     //these statements are all guaranteed not to GC-allocate
     int[2] a = [1, 2];
     assert(a[0] == 1 && a[1] == 2);
     a = ctA;
     assert(a[0] == 3 && a[1] == 4);
     assert(a == [3,4]);

     import core.stdc.stdlib;
     auto data = cast(int*)calloc(100_000, int.sizeof);
     auto callocedSlice = data[0 .. 100_000];
     auto subSlice = callocedSlice[40 .. $ - 600];

     //these cause GC allocation and as such
     //will not compile in an  nogc function.
 //    int[] s0 = [1, 2];
 //    auto s1 = [3,4];
 }


I should also include this example:

int[10] a = [0,1,2,3,4,5,6,7,8,9]; //a static array, on the stack
auto s = a[]; //a normal slice, backed by stack memory*
auto s1 = a[3 .. 5]; //ditto
Jul 08 2014
parent reply "Oluca" <oluca olu.ca> writes:
On Tuesday, 8 July 2014 at 11:26:55 UTC, John Colvin wrote:

 On Tuesday, 8 July 2014 at 11:22:42 UTC, John Colvin wrote:

 On Tuesday, 8 July 2014 at 06:23:13 UTC, Jeremy DeHaan wrote:


 I remember that slices was one thing you would no longer have 
 if you disable the GC, but I can't think of any others.


 You can definitely use slices without the GC and they are 
 still awesome without the GC.
 What you cannot do is create them with `new` or call the 
 builtin ~ or ~= (concatenate and append respectively) 
 operators on slices. Slice literals may also cause 
 allocations, but not always:

 enum ctA = [3, 4];

 void main()  nogc // nogc is transitive, marking main as  nogc
                  //enforces no GC activity in the entire 
 program.
 {
    //these statements are all guaranteed not to GC-allocate
    int[2] a = [1, 2];
    assert(a[0] == 1 && a[1] == 2);
    a = ctA;
    assert(a[0] == 3 && a[1] == 4);
    assert(a == [3,4]);

    import core.stdc.stdlib;
    auto data = cast(int*)calloc(100_000, int.sizeof);
    auto callocedSlice = data[0 .. 100_000];
    auto subSlice = callocedSlice[40 .. $ - 600];

    //these cause GC allocation and as such
    //will not compile in an  nogc function.
 //    int[] s0 = [1, 2];
 //    auto s1 = [3,4];
 }


 I should also include this example:

 int[10] a = [0,1,2,3,4,5,6,7,8,9]; //a static array, on the 
 stack
 auto s = a[]; //a normal slice, backed by stack memory*
 auto s1 = a[3 .. 5]; //ditto


I see. Thanks for the examples. What about strings? Do they 
depend on GC?
Jul 08 2014
next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
 int[10] a = [0,1,2,3,4,5,6,7,8,9]; //a static array, on the 
 stack
 auto s = a[]; //a normal slice, backed by stack memory*
 auto s1 = a[3 .. 5]; //ditto


 I see. Thanks for the examples. What about strings? Do they 
 depend on GC?


They are just slices / arrays.
Jul 08 2014
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 8 July 2014 at 11:31:49 UTC, Oluca wrote:

 On Tuesday, 8 July 2014 at 11:26:55 UTC, John Colvin wrote:

 On Tuesday, 8 July 2014 at 11:22:42 UTC, John Colvin wrote:

 On Tuesday, 8 July 2014 at 06:23:13 UTC, Jeremy DeHaan wrote:


 I remember that slices was one thing you would no longer 
 have if you disable the GC, but I can't think of any others.


 You can definitely use slices without the GC and they are 
 still awesome without the GC.
 What you cannot do is create them with `new` or call the 
 builtin ~ or ~= (concatenate and append respectively) 
 operators on slices. Slice literals may also cause 
 allocations, but not always:

 enum ctA = [3, 4];

 void main()  nogc // nogc is transitive, marking main as  nogc
                 //enforces no GC activity in the entire 
 program.
 {
   //these statements are all guaranteed not to GC-allocate
   int[2] a = [1, 2];
   assert(a[0] == 1 && a[1] == 2);
   a = ctA;
   assert(a[0] == 3 && a[1] == 4);
   assert(a == [3,4]);

   import core.stdc.stdlib;
   auto data = cast(int*)calloc(100_000, int.sizeof);
   auto callocedSlice = data[0 .. 100_000];
   auto subSlice = callocedSlice[40 .. $ - 600];

   //these cause GC allocation and as such
   //will not compile in an  nogc function.
 //    int[] s0 = [1, 2];
 //    auto s1 = [3,4];
 }


 I should also include this example:

 int[10] a = [0,1,2,3,4,5,6,7,8,9]; //a static array, on the 
 stack
 auto s = a[]; //a normal slice, backed by stack memory*
 auto s1 = a[3 .. 5]; //ditto


 I see. Thanks for the examples. What about strings? Do they 
 depend on GC?


`string` is just an alias to `immutable(char)[]` so the situation 
is (almost) the same*.

Be aware that the compiler will happily let you pass immutable 
data to another thread and will assume that it will always be 
available and never change (GCs are really useful :p ). Using 
immutable data that has been freed (e.g. by exiting the stack it 
was allocate on, or calling free on a malloced array) will cause 
all sorts of madness, quite possibly worse than in the 
non-immutable case. The compiler can make a lot of assumptions 
about the immutable memory that it cannot about mutable, which 
will all be broken if you free that memory while still holding 
references to it elsewhere.


TLDR: beware immutability and non-GC memory. Extra care is 
needed. I would either use const(char)[] for my strings or be 
very wary of impure functions that might store a reference.



*make sure you've got the length right, unicode means a single 
visual character may be bigger than one char. See here:

import std.exception : assumeUnique;

alias stackString(size_t len) = immutable(char)[len];
enum stackString(string s) = cast(immutable(char)[s.length])s;

void main()  nogc
{
     stackString!5 str0 = "hello"; //ASCII, length is easy to see
     auto str1 = stackString!"héllo͂"; //UTF-8, best to let the 
compiler
                                      //work out the length for you
}

There was talk of something like immutable(char)[$] = "héllo͂"; 
working, but I don't know where that went.
Jul 08 2014
parent reply "Meta" <jared771 gmail.com> writes:
On Tuesday, 8 July 2014 at 12:24:32 UTC, John Colvin wrote:

 There was talk of something like immutable(char)[$] = 
 "héllo͂"; working, but I don't know where that went.


https://github.com/D-Programming-Language/dmd/pull/3615
Jul 08 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Meta:


 https://github.com/D-Programming-Language/dmd/pull/3615


D is in beta release, so that pull request has to wait for 2.067+.

Bye,
bearophile
Jul 08 2014
parent "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 8 July 2014 at 16:55:54 UTC, bearophile wrote:

 D is in beta release, so that pull request has to wait for 
 2.067+.


We use release branches now. There is no reason for development 
activity to decline during the beta period – other than people 
being busy with addressing beta tester feedback and fixing 
regressions, of course.

David
Jul 08 2014
prev sibling next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Tuesday, 8 July 2014 at 03:37:51 UTC, Adrian wrote:

  + Has the GC been dropped?


No, and no matter what exactly will be done, it surely will 
always stay at least as an option, and most probably will be 
enabled by default.


  + If not, can it be disabled entirely/completely?


This is already possible for a long time. Normally it's only 
called when the memory allocator runs out of free memory, i.e. 
only on allocation, and you can call `GC.disable` to disable it 
completely.

For the upcoming release 2.066 (currently in beta), there will be 
a function attribute ` nogc` which makes the compiler error out 
if a function allocates GC memory (either directly, or by calling 
other non- nogc functions). Parts of the standard library have 
already been marked as  nogc, so they can be used inside such 
functions, though this is still ongoing work. Other parts have 
been changed to avoid allocations, at least where possible. There 
are now also some alternatives to functions that return allocated 
data to accept a sink delegate instead, so that the caller can 
decides whether they want to allocate, and how.


 D has always greatly impressed me, but I need a systems 
 language without garbage collection; has D become that now?


Well, yes and no, see above ;-)

I guess more work in this direction will be enabled once we have 
`std.allocator`, which Andrei Alexandrescu is working on 
currently. There might also be other changes necessary, some kind 
of ownership tracking / borrowing for example, to make this safe. 
(Manual memory management without help from the language can 
easily lead to all kinds of bugs.)
Jul 08 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Marc Schütz:


 There might also be other changes necessary, some kind of 
 ownership tracking / borrowing for example, to make this safe. 
 (Manual memory management without help from the language can 
 easily lead to all kinds of bugs.)


In the end Bartoz could be right.

Bye,
bearophile
Jul 08 2014
prev sibling next sibling parent reply "Oluca" <oluca olu.ca> writes:
On Tuesday, 8 July 2014 at 03:37:51 UTC, Adrian wrote:

 Hi all,

 I know there's been quite some discussion about the GC in D, 
 but I've been busy doing other things and haven't been 
 following that closely.

 So I'd appreciate it if someone could fill me in about 
 proceedings/decisions in this regard...

  + Has the GC been dropped?
  + If not, can it be disabled entirely/completely?

 D has always greatly impressed me, but I need a systems 
 language without garbage collection; has D become that now?

 Thanks in advance for any responses.
 Adrian.


- No, D is a fully garbage collected language.
- No, it can't be disabled if you want to keep using "impressive
features" of the language.
Long story short, if you prefer to manage your own god-damn
memory manually, D isn't the way to go. No sir, you are stuck
with an inefficient GC. They've been improving the GC for years,
but it's still not good enough. I suggest Rust, or something like
that.
Jul 08 2014
parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Tuesday, 8 July 2014 at 09:57:15 UTC, Oluca wrote:

 - No, it can't be disabled if you want to keep using "impressive
 features" of the language.


What do CTFE, mixins, Ds powerful template mechanism, immutable +
slices, sane operator overloading, opDispatch, alias this and
UFCS, RAII + scope statements to do with the GC?


 Long story short, if you prefer to manage your own god-damn
 memory manually, D isn't the way to go. No sir, you are stuck
 with an inefficient GC.
 They've been improving the GC for years,
 but it's still not good enough.


How does the quality of the GC even matter if you're not going to 
use it?
Jul 08 2014
parent reply "Oluca" <oluca olu.ca> writes:
On Tuesday, 8 July 2014 at 10:07:18 UTC, Tobias Pankrath wrote:

 On Tuesday, 8 July 2014 at 09:57:15 UTC, Oluca wrote:

 - No, it can't be disabled if you want to keep using 
 "impressive
 features" of the language.


 What do CTFE, mixins, Ds powerful template mechanism, immutable 
 +
 slices, sane operator overloading, opDispatch, alias this and
 UFCS, RAII + scope statements to do with the GC?


 Long story short, if you prefer to manage your own god-damn
 memory manually, D isn't the way to go. No sir, you are stuck
 with an inefficient GC.
 They've been improving the GC for years,
 but it's still not good enough.


 How does the quality of the GC even matter if you're not going 
 to use it?


- You can't use slices. You can't make use of most of the 
Standard Library functionality.
- It matters, because you can't manually manage life-time of the 
objects. See, you have to keep a reference to a C-String that you 
send to a C function, otherwise GC will eat it up, because it 
can't know better than you, yet tries to do your job. GC will 
always stand in the way, and if you want to turn it off, as I 
stated above, D becomes a less useful language.
Jul 08 2014
next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
On Tuesday, 8 July 2014 at 10:25:17 UTC, Oluca wrote:

 - You can't use slices. You can't make use of most of the 
 Standard Library functionality.


You just cannot append to them.


 - It matters, because you can't manually manage life-time of 
 the objects. See, you have to keep a reference to a C-String 
 that you send to a C function, otherwise GC will eat it up, 
 because it can't know better than you, yet tries to do your 
 job. GC will always stand in the way, and if you want to turn 
 it off, as I stated above, D becomes a less useful language.


It's still very useful, as I stated above.
Jul 08 2014
prev sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 8 July 2014 at 10:25:17 UTC, Oluca wrote:

 On Tuesday, 8 July 2014 at 10:07:18 UTC, Tobias Pankrath wrote:

 On Tuesday, 8 July 2014 at 09:57:15 UTC, Oluca wrote:

 - No, it can't be disabled if you want to keep using 
 "impressive
 features" of the language.


 What do CTFE, mixins, Ds powerful template mechanism, 
 immutable +
 slices, sane operator overloading, opDispatch, alias this and
 UFCS, RAII + scope statements to do with the GC?


 Long story short, if you prefer to manage your own god-damn
 memory manually, D isn't the way to go. No sir, you are stuck
 with an inefficient GC.
 They've been improving the GC for years,
 but it's still not good enough.


 How does the quality of the GC even matter if you're not going 
 to use it?


 - You can't use slices.


See my other post. This is not true. They aren't quite as 
powerful or convenient without the GC, but you definitely can use 
them.
Jul 08 2014
prev sibling next sibling parent reply "Adrian" <adrian777 on-vol-dot.net> writes:
Hi folks,

Thank you all for your very informative answers - much 
appreciated.
Great to see such an active community there.

To summarise what you said:

+ No, the GC can't be taken out, but with careful attention one 
can - relatively easily - bypass it. This can come at a price of 
some great features of the language, but then if the requirement 
is to not use the GC one can do so. This is perhaps flexibility 
no?

+ The current GC will be improved, but it's taking some time for 
that to happen - which is a shame, for if the GC is stumbling 
block for some people (such as myself), an inefficient/weak one 
does not help in convincing GC sceptics to accept it.

+ The  nogc stuff and work you mentioned with the standard 
library is also encouraging.

Now, going forward, is there a comprehensive and precise set of 
instructions available that one could follow in order to write D 
programs entirely devoid of the GC? That would be most helpful if 
available.

Once again, thank you all.
- Adrian.
Jul 09 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Adrian:


 for if the GC is stumbling block for some people (such as 
 myself), an inefficient/weak one does not help in convincing GC 
 sceptics to accept it.
 ...
 is there a comprehensive and precise set of instructions 
 available that one could follow in order to write D programs 
 entirely devoid of the GC?


Have you written enough D code where you have seen the current GC 
is not good enough for you? How much good has to be the D GC for 
you to use it?

Bye,
bearophile
Jul 09 2014
parent reply "Adrian" <adrian777 on-vol-dot.net> writes:
 Have you written enough D code where you have seen the current 
 GC is not good enough for you? How much good has to be the D GC 
 for you to use it?

 Bye,
 bearophile


Hi,

As I said at the start, I have been away a while but I wrote a 
fair amount of code in D about a year ago to test the waters.

 From my experience of those tests, I mainly targeted the GC and 
if I remember well, I had written code that, based on command 
line switches, specified if the incorporated GC is to be used for 
memory allocation/deallocation or whether memory is done entirely 
manually (I managed this through some posts in the forum where 
community members instructed me how to achieve this).

 From my limited tests, the ones which used manual memory 
management ran in roughly half the time; the GC ones took almost 
double the time and in some cases more than that. I don't have 
the code at hand (I might need to dig it out), but I certainly 
can vouch for a significant discrepancy in performance between 
the GC versions and manual versions. So yes, this is a 
significant issue (i.e. the current GC is not good enough for me 
and I cannot overlook it).

As for your second question (i.e. how good the GC needs to be for 
me), I would probably be satisfied with a GC that matches the 
Java one (used in conjunction with D's ability to take over 
memory management completely in the critical parts where needed) 
- but admittedly, I don't know the implications in achieving that 
within D's memory model, etc.

I am embarking on a start-up pretty soon and I have been looking 
at possible languages/frameworks to use; I've looked at Go in 
detail, had a cursory look (so far) at Rust and have also used to 
a fair degree. D is the most natural fit for me and my team 
coming from a mainly C++ and Java background, but I would really 
like to make an informed decision vis-a-vis the GC implications.

Thanks for your help.
- Adrian.
Jul 09 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Adrian:


 As for your second question (i.e. how good the GC needs to be 
 for me), I would probably be satisfied with a GC that matches 
 the Java one


This will not happen even in one hundred years. So if that's what 
you want, you will never be satisfied by D GC.

Bye,
bearophile
Jul 09 2014
next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Wednesday, 9 July 2014 at 11:21:13 UTC, bearophile wrote:

 Adrian:


 As for your second question (i.e. how good the GC needs to be 
 for me), I would probably be satisfied with a GC that matches 
 the Java one


 This will not happen even in one hundred years. So if that's 
 what you want, you will never be satisfied by D GC.


Uhmm... what makes you think so?
Jul 09 2014
next sibling parent "Adrian" <adrian777 on-vol-dot.net> writes:
On Wednesday, 9 July 2014 at 11:44:31 UTC, Marc Schütz wrote:

 This will not happen even in one hundred years. So if that's 
 what you want, you will never be satisfied by D GC.


 Uhmm... what makes you think so?


Good question actually...
Jul 09 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Marc Schütz:


 Uhmm... what makes you think so?


The huge amount of work done on the OracleVM GC that is not easy 
to match.
D need for low-level code (currently user code can't tell the GC 
what are the current actual contents of a union, this includes 
Algebraic), D desire to interface efficiently to C code.

Bye,
bearophile
Jul 09 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 9 July 2014 at 13:01:36 UTC, bearophile wrote:

 The huge amount of work done on the OracleVM GC that is not 
 easy to match.
 D need for low-level code (currently user code can't tell the 
 GC what are the current actual contents of a union, this 
 includes Algebraic), D desire to interface efficiently to C 
 code.


I think it is a pity that there has been no real effort to 
experiment with restricting/extending semantics in a way that 
could lead to cache efficient GC collection.

1. annotate pointers that may point to GC memory (global dataflow 
or explict)
2. ensure that regular memory retain pointers to GC memory when 
it is live in C code
3. do global analysis of possible datastructures to minimize 
scanned fields/structs
4. improve stack traversal speed
5. improve ADTs with GC performance-enhancing features to reduce 
scanning
6. optional fat GC pointer implementations to get faster scanning

But yeah, if one insists on having C semantics throughout, then 
there is no hope…
Jul 09 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 9 July 2014 at 11:21:13 UTC, bearophile wrote:

 Adrian:


 As for your second question (i.e. how good the GC needs to be 
 for me), I would probably be satisfied with a GC that matches 
 the Java one


 This will not happen even in one hundred years. So if that's 
 what you want, you will never be satisfied by D GC.


Actually, I think we can do better than Java, because we have
type qualifiers and less indirection. That isn't unseen: OCaml's
GC is more performant than Java's. We certainly do not have the
resources java has, but we have a language that is way more GC
friendly.
Jul 10 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 10.07.2014 21:57, schrieb deadalnix:

 On Wednesday, 9 July 2014 at 11:21:13 UTC, bearophile wrote:

 Adrian:


 As for your second question (i.e. how good the GC needs to be for
 me), I would probably be satisfied with a GC that matches the Java one


 This will not happen even in one hundred years. So if that's what you
 want, you will never be satisfied by D GC.


 Actually, I think we can do better than Java, because we have
 type qualifiers and less indirection. That isn't unseen: OCaml's
 GC is more performant than Java's. We certainly do not have the
 resources java has, but we have a language that is way more GC
 friendly.


I agree, given the research OS implemented in GC enabled systems languages.

Sadly I cannot speak for more than Oberon and AOS as experience.

--
Paulo
Jul 10 2014
prev sibling next sibling parent reply "Araq" <rumpf_a web.de> writes:
On Thursday, 10 July 2014 at 19:57:56 UTC, deadalnix wrote:

 On Wednesday, 9 July 2014 at 11:21:13 UTC, bearophile wrote:

 Adrian:


 As for your second question (i.e. how good the GC needs to be 
 for me), I would probably be satisfied with a GC that matches 
 the Java one


 This will not happen even in one hundred years. So if that's 
 what you want, you will never be satisfied by D GC.


 Actually, I think we can do better than Java, because we have
 type qualifiers and less indirection. That isn't unseen: OCaml's
 GC is more performant than Java's. We certainly do not have the
 resources java has, but we have a language that is way more GC
 friendly.


No, you don't. No distinction between GC'ed and non GC'ed 
pointers, interior pointers are everywhere, sharing GC'ed memory 
between threads is unrestricted, casting to const/immutable might 
be officially undefined but in practice abounds so you better 
don't take advantage of that, excellent C interop means that you 
have no chance but to scan the stacks conservatively.
Jul 10 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Araq:


 casting to const/immutable might be officially undefined but in 
 practice abounds so you better don't take advantage of that,


Do you have evidence of this? It's not just "officially 
undefined", it's practically undefined, dmd gives all kind of 
wrong results if you cast away const/immutable and then you 
mutate the data, you don't get far with that habit.

Bye,
bearophile
Jul 10 2014
prev sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 10 July 2014 at 20:18:23 UTC, Araq wrote:

 No, you don't. No distinction between GC'ed and non GC'ed 
 pointers,


This is true.


 interior pointers are everywhere,


This however, I don't think is a problem. It can make a 
non-precise GC more unreliable, but otherwise?


 sharing GC'ed memory between threads is unrestricted,


Yes.
Jul 10 2014
prev sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 10, 2014 at 07:57:55PM +0000, deadalnix via Digitalmars-d wrote:
[...]

 Actually, I think we can do better than Java, because we have
 type qualifiers and less indirection. That isn't unseen: OCaml's
 GC is more performant than Java's. We certainly do not have the
 resources java has, but we have a language that is way more GC
 friendly.


Are you sure about that? Having unions, pointer arithmetic, and passing
things to/from C/C++ constrains possible GC implementations more than in
Java, where you don't have to worry about such things. Although we'd
like to default to  safe, we aren't quite there yet, and besides, you
don't want to have a GC that only works in  safe code when obviously
there's a lot of D code out there that is un- safe.


T

-- 
Real men don't take backups. They put their source on a public FTP-server and
let the world mirror it. -- Linus Torvalds
Jul 10 2014
prev sibling next sibling parent reply "Vlad Levenfeld" <vlevenfeld gmail.com> writes:
I haven't managed to read through these last few pages but I just 
wanted to chime with my noob opinion re: D slices, templates, GC 
and manual allocation, for whatever its worth:

Although I tend to just let the GC do its thing most of the time, 
I've found spots where I needed manual allocation while retaining 
all of the nice features like appending, but at high speed 
(because yes, the speed on GC-supported append is painful).
Between template mixins and operator overloading and the ability 
to drop down to the C level, D absolutely provides you with 
everything you need do handle all of this yourself while 
retaining as many advanced features as you care to implement in 
your specialized memory-management system. With alias this and 
opDispatch, its not even that much work, and with contracts and 
template constraints, can be made quite safe as well.

What I want to emphasize is that you would be doing all of this 
in C++ anyway, but with a much more difficult template system, 
nastier syntax and lots of gotchas and corner-cases. The only 
thing that I miss from C++ is move semantics, but the few times 
I've felt like I needed them (like a struct relying on internal 
references, say, to a containing struct) I was better served by 
mixin template (which take on the local scope, obviating the need 
for internal refs in my use case... YMMV of course).

But what you wouldn't get with C++ is GC by default, which is 
nice when prototyping, need some advanced data structures and 
don't want to waste time worrying about memory layouts and move 
semantics for something that, in all likelihood, will be a 
throwaway (or at least subject to extreme modification).

With D you get flexibility by default, and speed when you need 
it. Even without the support of all the GC'd features, you're 
still left with a wealth of (generally zero runtime overhead) 
metaprogramming options to help safety and readability. You've 
got to know what you're doing, of course, but if you are coming 
from C++ you are already used to being surgical.

tl;dr: If you want to append (to pick out one sugary GC-reliant 
feature) and you find the builtin too slow, define opOpAssign 
(string op: `~`)(ref T that) on a custom slice-like struct that 
forwards ops to a manually allocated backing container. It can't 
imagine it'd be much slower than a push_back on pre-reserved 
std::vector.
Jul 10 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 10, 2014 at 10:20:41PM +0000, Vlad Levenfeld via Digitalmars-d
wrote:

 I haven't managed to read through these last few pages but I just wanted to
 chime with my noob opinion re: D slices, templates, GC and manual
 allocation, for whatever its worth:
 
 Although I tend to just let the GC do its thing most of the time, I've found
 spots where I needed manual allocation while retaining all of the nice
 features like appending, but at high speed (because yes, the speed on
 GC-supported append is painful).


[...]

std.array.appender?


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze
Jul 10 2014
parent reply "Vlad Levenfeld" <vlevenfeld gmail.com> writes:
On Thursday, 10 July 2014 at 22:28:46 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 std.array.appender?


I tried it, it was much better than the default append but still 
several times slower than a manually overload.
Jul 10 2014
next sibling parent "Vlad Levenfeld" <vlevenfeld gmail.com> writes:
** manually overloaded opOpAssign'

(hit send too fast)
Jul 10 2014
prev sibling parent "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 10 July 2014 at 22:31:55 UTC, Vlad Levenfeld wrote:

 On Thursday, 10 July 2014 at 22:28:46 UTC, H. S. Teoh via 
 Digitalmars-d wrote:

 std.array.appender?


 I tried it, it was much better than the default append but 
 still several times slower than a manually overload.


There's also this, which is much faster than std.array.appender:

http://wiki.dlang.org/Std.buffer.scopebuffer

I wrote a blog post on using it:


http://atilanevesoncode.wordpress.com/2014/03/31/increasing-performance-with-static-polymorphism-and-other-neat-tricks/

Atila
Aug 04 2014
prev sibling parent reply "Mike" <none none.com> writes:
On Tuesday, 8 July 2014 at 03:37:51 UTC, Adrian wrote:


  + If not, can it be disabled entirely/completely?


Adrian,

Sorry for the late reply.  You may be interested in this article 
on the wiki (http://wiki.dlang.org/Memory_Management).  It talks 
about different methods one can use to avoid the GC.

Additionally, I want to thank the original author of this (Please 
speak up, you deserve attribution).  I found it quite informative 
when I first started with D, and will likely employ some of the 
techniques mentioned in my future work.

Mike
Jul 10 2014
parent "Adrian" <adrian777 on-vol-dot.net> writes:
Thanks Mike... Looking into that.
Aug 03 2014