www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Mac Apps That Use Garbage Collection Must Move to ARC

reply "JN" <666total wp.pl> writes:
https://developer.apple.com/news/?id=02202015a

Interesting...

Apple is dropping GC in favor of automatic reference counting. 
What are the benefits of ARC over GC? Is it just about 
predictability of resource freeing? Would ARC make sense in D?
Feb 21 2015
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 21 February 2015 at 19:20:48 UTC, JN wrote:

 https://developer.apple.com/news/?id=02202015a

 Interesting...

 Apple is dropping GC in favor of automatic reference counting. 
 What are the benefits of ARC over GC? Is it just about 
 predictability of resource freeing? Would ARC make sense in D?


Apple never was able to roll out a good GC for ObjC and got back 
to ARC (an overly complex reference counting system that the 
compiler is aware of).

You get the usual tradeof of RC vs GC :
  - RC is more predictable.
  - RC has less floating garbage, so usually a lower memory foot 
print.
  - RC usually increase cache pressure as you need to have 
reference count ready and hot.
  - RC behave (very) poorly when reference are shared across 
cores, as they ill compete for cache lines. It tends to be faster 
in single threaded mode, but that depends on the type of 
application (graph manipulation for instance, tend to behave 
poorly with RC).
  - RC can leak.
  - RC is unsafe without ownership.
Feb 21 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/21/15 12:22 PM, deadalnix wrote:

 On Saturday, 21 February 2015 at 19:20:48 UTC, JN wrote:

 https://developer.apple.com/news/?id=02202015a

 Interesting...

 Apple is dropping GC in favor of automatic reference counting. What
 are the benefits of ARC over GC? Is it just about predictability of
 resource freeing? Would ARC make sense in D?


 Apple never was able to roll out a good GC for ObjC and got back to ARC
 (an overly complex reference counting system that the compiler is aware
 of).

 You get the usual tradeof of RC vs GC :
   - RC is more predictable.
   - RC has less floating garbage, so usually a lower memory foot print.
   - RC usually increase cache pressure as you need to have reference
 count ready and hot.
   - RC behave (very) poorly when reference are shared across cores, as
 they ill compete for cache lines. It tends to be faster in single
 threaded mode, but that depends on the type of application (graph
 manipulation for instance, tend to behave poorly with RC).
   - RC can leak.
   - RC is unsafe without ownership.


Apparently Apple has delivered on a well oiled RC implementation and has 
"won". Most people who develop for both iOS and Android prefer the 
former. -- Andrei
Feb 21 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/21/2015 12:22 PM, deadalnix wrote:

 You get the usual tradeof of RC vs GC :
   - RC is more predictable.
   - RC has less floating garbage, so usually a lower memory foot print.
   - RC usually increase cache pressure as you need to have reference count
ready
 and hot.
   - RC behave (very) poorly when reference are shared across cores, as they ill
 compete for cache lines. It tends to be faster in single threaded mode, but
that
 depends on the type of application (graph manipulation for instance, tend to
 behave poorly with RC).
   - RC can leak.
   - RC is unsafe without ownership.


- RC is slower overall
- RC has further performance and code bloat problems when used with exception 
handling
Feb 21 2015
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-02-22 03:23, Walter Bright wrote:


 - RC has further performance and code bloat problems when used with
 exception handling


Exceptions in Objective-C are basically like Errors in D. Should not be 
caught and should terminate the applications.

Swift doesn't event have exceptions.

-- 
/Jacob Carlborg
Feb 22 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/22/2015 3:19 AM, Jacob Carlborg wrote:

 On 2015-02-22 03:23, Walter Bright wrote:


 - RC has further performance and code bloat problems when used with
 exception handling


 Exceptions in Objective-C are basically like Errors in D. Should not be caught
 and should terminate the applications.

 Swift doesn't event have exceptions.



And I suspect that ARC is why they don't have exceptions.
Feb 22 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-02-22 21:48, Walter Bright wrote:


 And I suspect that ARC is why they don't have exceptions.


Objective-C still has both ARC and exceptions. Although the 
documentation [1] says that ARC is not exception safe by default, but it 
does have a flag to enable it "-fobjc-arc-exceptions".

[1] http://clang.llvm.org/docs/AutomaticReferenceCounting.html#exceptions

-- 
/Jacob Carlborg
Feb 23 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/23/2015 11:57 PM, Jacob Carlborg wrote:

 On 2015-02-22 21:48, Walter Bright wrote:


 And I suspect that ARC is why they don't have exceptions.


 Objective-C still has both ARC and exceptions. Although the documentation [1]
 says that ARC is not exception safe by default, but it does have a flag to
 enable it "-fobjc-arc-exceptions".

 [1] http://clang.llvm.org/docs/AutomaticReferenceCounting.html#exceptions


 From your reference:

"Making code exceptions-safe by default would impose severe runtime and code 
size penalties on code that typically does not actually care about exceptions 
safety. Therefore, ARC-generated code leaks by default on exceptions, which is 
just fine if the process is going to be immediately terminated anyway. Programs 
which do care about recovering from exceptions should enable the option."

Note "severe runtime and code size penalties". Just what I said.
Feb 24 2015
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/22/2015 03:23 AM, Walter Bright wrote:

 - RC is slower overall


This claim isn't true for almost all applications when using a
conservative GC, except for programs that produce a lot of garbage and
have very few long-lived objects. The memory bandwidth consumed to
mark long-lived objects during every collection dominates the GC cost
even for small heaps (say 100MB).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJU8Nu9AAoJELJzgRYSuxk5ONwP/0vfyS4UH4OuyXASpyTRdEYQ
PsAi68S1oSqJaZXGkjVYSsPBASA3qn8Vf/n2002c4NKjGnEbywVyUGijmzyEx94q
Ja8TKtIvw4HJ8xCQEd3NvKwttJhY+K868hAH2YWEiOknad0x7MV3N0GXb7yyEFbt
b5AMJmr5Qs+6wTvOYcwgdJevznaE4LjxtI/iURsjQ7X3tfg6igb3W96Ehx/5URFB
upP5lCswBJ5agz8TbOSVeqk1AjR7dYYgtSDhF+IhkH9Ig5lJ68SECWNG7Ru9ixmK
JqUhyGJXWpK5UWkDE9zggUQ2M1QVXTnX/QzzUGcvnbqC1SgHbd79gTwQWOLSOy8i
5e464zCVe1QcMmDK5vUxcuNCr9XiATV/k9M+SHtkXu2AZvx0mQdWBKPVnQmTzizQ
Tf+yKT84zKz4kZK6cfoP9KsrDlWLcU+L6vmghkqFfkk0mpvkoXEF7mNsPlWw+bvn
GAEJvj+xItFkulaE9X+HWbvRs5YeFOSuV7qXRKoTGRvhnr49XaDLi2jANLBt2SLu
Ku/pjkwl20rHUB3Q8+7qfoqjm/iunujZxqVw+vXzRvp3hrvbMiFW2b6jHzl8WN7n
LceLniG/sk4/hLILlu4CKgiLQRk3PxQEBJHqUaSqNZZS7Wrp/g6b3nKaGzqv2ehM
2RRjU57Ptw6AQsw+QT9E
=ANkN
-----END PGP SIGNATURE-----
Feb 27 2015
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 22 February 2015 at 05:20, JN via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 https://developer.apple.com/news/?id=02202015a

 Interesting...

 Apple is dropping GC in favor of automatic reference counting. What are the
 benefits of ARC over GC? Is it just about predictability of resource
 freeing? Would ARC make sense in D?


D's GC is terrible, and after 6 years hanging out in this place, I
have seen precisely zero development on the GC front. Nobody can even
imagine, let alone successfully implement a GC that covers realtime
use requirements.
On the other hand, if 'scope' is implemented well, D may have some of
the best tools in town for quality ARC implementation. There is a
visible way forward for quality RC in D, and I think we could do
better than Apple.

I personally think ARC in D is the only way forwards. That is an
unpopular opinion however... although I think I'm just being realistic
;)
Feb 21 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/21/2015 4:43 PM, Manu via Digitalmars-d wrote:

 D's GC is terrible, and after 6 years hanging out in this place, I
 have seen precisely zero development on the GC front. Nobody can even
 imagine, let alone successfully implement a GC that covers realtime
 use requirements.


Nobody thinks GC is suitable for hard realtime.



 On the other hand, if 'scope' is implemented well, D may have some of
 the best tools in town for quality ARC implementation. There is a
 visible way forward for quality RC in D, and I think we could do
 better than Apple.


With 'return ref', which is now implemented, you can create a memory safe 
RefCounted type. However, nobody has bothered. Are you up for it? :-)
Feb 21 2015
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 22 February 2015 at 02:14:04 UTC, Walter Bright wrote:

 With 'return ref', which is now implemented, you can create a 
 memory safe RefCounted type. However, nobody has bothered. Are 
 you up for it? :-)


wait what? These things should be on the changelog! You can't 
really complain that people haven't bothered using a secret 
feature that 1) doesn't seem to be out of beta yet and 2) isn't 
listed as a new thing here http://dlang.org/changelog.html
Feb 21 2015
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/21/2015 6:20 PM, Adam D. Ruppe wrote:

 On Sunday, 22 February 2015 at 02:14:04 UTC, Walter Bright wrote:

 With 'return ref', which is now implemented, you can create a memory safe
 RefCounted type. However, nobody has bothered. Are you up for it? :-)


 wait what? These things should be on the changelog! You can't really complain
 that people haven't bothered using a secret feature that 1) doesn't seem to be
 out of beta yet and 2) isn't listed as a new thing here
 http://dlang.org/changelog.html


It's new in 2.067, which is out in beta. It implements DIP25.

http://wiki.dlang.org/DIP25
Feb 21 2015
prev sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Sunday, 22 February 2015 at 02:20:03 UTC, Adam D. Ruppe wrote:

 On Sunday, 22 February 2015 at 02:14:04 UTC, Walter Bright 
 wrote:

 With 'return ref', which is now implemented, you can create a 
 memory safe RefCounted type. However, nobody has bothered. Are 
 you up for it? :-)


 wait what? These things should be on the changelog! You can't 
 really complain that people haven't bothered using a secret 
 feature that 1) doesn't seem to be out of beta yet and 2) isn't 
 listed as a new thing here http://dlang.org/changelog.html


This! What is 'return ref'?
Feb 22 2015
prev sibling next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Sunday, 22 February 2015 at 02:14:04 UTC, Walter Bright wrote:

 On 2/21/2015 4:43 PM, Manu via Digitalmars-d wrote:

 D's GC is terrible, and after 6 years hanging out in this 
 place, I
 have seen precisely zero development on the GC front. Nobody 
 can even
 imagine, let alone successfully implement a GC that covers 
 realtime
 use requirements.


 Nobody thinks GC is suitable for hard realtime.



 On the other hand, if 'scope' is implemented well, D may have 
 some of
 the best tools in town for quality ARC implementation. There 
 is a
 visible way forward for quality RC in D, and I think we could 
 do
 better than Apple.


 With 'return ref', which is now implemented, you can create a 
 memory safe RefCounted type. However, nobody has bothered. Are 
 you up for it? :-)


Excuse my ignorance,(I read the DIP btw)
How does 'return ref' address issues like
http://forum.dlang.org/thread/pagpusgpyhlhoipldofs forum.dlang.org#post-ewuwphzmubtmykfsywuw:40forum.dlang.org
?
Feb 21 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/21/2015 10:07 PM, weaselcat wrote:

 Excuse my ignorance,(I read the DIP btw)
 How does 'return ref' address issues like
 http://forum.dlang.org/thread/pagpusgpyhlhoipldofs forum.dlang.org#post-ewuwphzmubtmykfsywuw:40forum.dlang.org
 ?


The short answer, is your ref types never expose a raw pointer. They do it all 
with ref's.
Feb 21 2015
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 22 February 2015 at 06:37:45 UTC, Walter Bright wrote:

 On 2/21/2015 10:07 PM, weaselcat wrote:

 Excuse my ignorance,(I read the DIP btw)
 How does 'return ref' address issues like
 http://forum.dlang.org/thread/pagpusgpyhlhoipldofs forum.dlang.org#post-ewuwphzmubtmykfsywuw:40forum.dlang.org
 ?


 The short answer, is your ref types never expose a raw pointer. 
 They do it all with ref's.


If you don't plan to use any method on objects, I guess that's 
fine.
Feb 21 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/21/2015 11:06 PM, deadalnix wrote:

 On Sunday, 22 February 2015 at 06:37:45 UTC, Walter Bright wrote:

 On 2/21/2015 10:07 PM, weaselcat wrote:

 Excuse my ignorance,(I read the DIP btw)
 How does 'return ref' address issues like
 http://forum.dlang.org/thread/pagpusgpyhlhoipldofs forum.dlang.org#post-ewuwphzmubtmykfsywuw:40forum.dlang.org

 ?


 The short answer, is your ref types never expose a raw pointer. They do it all
 with ref's.


 If you don't plan to use any method on objects, I guess that's fine.


Structs pass the 'this' pointer by ref.
Feb 21 2015
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 22 February 2015 at 06:37:45 UTC, Walter Bright wrote:

 On 2/21/2015 10:07 PM, weaselcat wrote:

 Excuse my ignorance,(I read the DIP btw)
 How does 'return ref' address issues like
 http://forum.dlang.org/thread/pagpusgpyhlhoipldofs forum.dlang.org#post-ewuwphzmubtmykfsywuw:40forum.dlang.org
 ?


 The short answer, is your ref types never expose a raw pointer. 
 They do it all with ref's.


And a coroutine cannot hold onto a ref?
Feb 22 2015
prev sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Sunday, 22 February 2015 at 06:07:02 UTC, weaselcat wrote:

 On Sunday, 22 February 2015 at 02:14:04 UTC, Walter Bright 
 wrote:

 On 2/21/2015 4:43 PM, Manu via Digitalmars-d wrote:

 D's GC is terrible, and after 6 years hanging out in this 
 place, I
 have seen precisely zero development on the GC front. Nobody 
 can even
 imagine, let alone successfully implement a GC that covers 
 realtime
 use requirements.


 Nobody thinks GC is suitable for hard realtime.



 On the other hand, if 'scope' is implemented well, D may have 
 some of
 the best tools in town for quality ARC implementation. There 
 is a
 visible way forward for quality RC in D, and I think we could 
 do
 better than Apple.


 With 'return ref', which is now implemented, you can create a 
 memory safe RefCounted type. However, nobody has bothered. Are 
 you up for it? :-)


 Excuse my ignorance,(I read the DIP btw)
 How does 'return ref' address issues like
 http://forum.dlang.org/thread/pagpusgpyhlhoipldofs forum.dlang.org#post-ewuwphzmubtmykfsywuw:40forum.dlang.org
 ?


Responding to myself, I don't think this actually touches on the 
issue deadalnix wanted at all.

So I think the

 With 'return ref', which is now implemented, you can create a 
 memory safe RefCounted type.




is not quite correct... in his usage, anyways. I think this would 
require DIP69, no?
Feb 21 2015
prev sibling next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 22.02.2015 um 03:13 schrieb Walter Bright:

 Nobody thinks GC is suitable for hard realtime.


I think you should know manu good enough by now that you know he is not 
talking about hard realtime but soft realtime instead. (e.g. games) 
There are GCs which handle this situation pretty well but D's GC is not 
one of them.
Feb 22 2015
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 2015-02-22 at 10:21 +0100, Benjamin Thaut via Digitalmars-d
wrote:

 Am 22.02.2015 um 03:13 schrieb Walter Bright:

 Nobody thinks GC is suitable for hard realtime.


=20
 I think you should know manu good enough by now that you know he is not=


=20

 talking about hard realtime but soft realtime instead. (e.g. games)=20
 There are GCs which handle this situation pretty well but D's GC is not=


=20

 one of them.


If the D GC really is quite so bad, why hasn't a cabal formed to create
a new GC that is precise, fast and efficient?

I suspect Python's RC/GC approach is one architecture, whilst Java G1 is
another. (Ignore all previous GCs in OpenJDK, they "suck". Sadly the GCs
other than G1 that are interesting on the JVM are proprietary.)

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Feb 22 2015
next sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Sunday, 22 February 2015 at 09:48:16 UTC, Russel Winder wrote:

 On Sun, 2015-02-22 at 10:21 +0100, Benjamin Thaut via 
 Digitalmars-d
 wrote:

 Am 22.02.2015 um 03:13 schrieb Walter Bright:

 Nobody thinks GC is suitable for hard realtime.


 
 I think you should know manu good enough by now that you know 
 he is not talking about hard realtime but soft realtime 
 instead. (e.g. games) There are GCs which handle this 
 situation pretty well but D's GC is not one of them.


 If the D GC really is quite so bad, why hasn't a cabal formed 
 to create
 a new GC that is precise, fast and efficient?

 I suspect Python's RC/GC approach is one architecture, whilst 
 Java G1 is
 another. (Ignore all previous GCs in OpenJDK, they "suck". 
 Sadly the GCs
 other than G1 that are interesting on the JVM are proprietary.)


GCs are difficult.

I don't think they're as bad for soft realtime as some people 
would lead you to believe though. A nice advantage of GCs is that 
you can hold off all collections, and soft realtime(games) 
frequently have pauses long enough for collections.

The issue I found with D's GC by default is that it runs far too 
often and it's _much_ more efficient to do large collections 
infrequently than frequent small collections. IIRC this is 
completely adjustable in 2.067.

Just my 2 cents.

Also, .NET's GC is under MIT now AFAIK(?). I don't even know what 
the quality of it is, but .NET is and has been Microsoft's 
darling.
Feb 22 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-02-22 10:48, Russel Winder via Digitalmars-d wrote:


 If the D GC really is quite so bad, why hasn't a cabal formed to create
 a new GC that is precise, fast and efficient?


It's like with everything else that hasn't been done. No one has cared 
enough do to something about it.

There are some issues that makes it harder to implement a good GC in D:

* D allows to do unsafe operations like unions, casts, pointer arithmetic

* D needs to be able to interface with C

* Most good GC implementations need some kind of barrier (read or write, 
don't remember which). If I recall there are several people against this 
in the community

-- 
/Jacob Carlborg
Feb 22 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/22/2015 3:25 AM, Jacob Carlborg wrote:

 * Most good GC implementations need some kind of barrier (read or write, don't
 remember which). If I recall there are several people against this in the
community


Count me among those.

In Java, write barriers make sense because Java uses the GC for everything. 
Pretty much every indirection is a GC reference.

This is not at all true with D code. But since the compiler can't know that, it 
has to insert write barriers for all those dereferences regardless. I suspect
it 
would be a terrible performance hit.
Feb 23 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-02-23 21:30, Walter Bright wrote:


 Count me among those.

 In Java, write barriers make sense because Java uses the GC for
 everything. Pretty much every indirection is a GC reference.

 This is not at all true with D code. But since the compiler can't know
 that, it has to insert write barriers for all those dereferences
 regardless.


The alternative would be to have two kind of pointers, one for GC 
allocated data and one for other kind of data. But I know you don't like 
that either.

We kind of already have this, class references and regular pointers. But 
that would tie classes to the GC.


 I suspect it would be a terrible performance hit.


It would be nice to have some numbers backing this up.

-- 
/Jacob Carlborg
Feb 23 2015
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 24 February 2015 at 07:53:52 UTC, Jacob Carlborg 
wrote:

 On 2015-02-23 21:30, Walter Bright wrote:


 Count me among those.

 In Java, write barriers make sense because Java uses the GC for
 everything. Pretty much every indirection is a GC reference.

 This is not at all true with D code. But since the compiler 
 can't know
 that, it has to insert write barriers for all those 
 dereferences
 regardless.


 The alternative would be to have two kind of pointers, one for 
 GC allocated data and one for other kind of data. But I know 
 you don't like that either.

 We kind of already have this, class references and regular 
 pointers. But that would tie classes to the GC.


 I suspect it would be a terrible performance hit.


 It would be nice to have some numbers backing this up.



This the approach taken by Active Oberon and Modula-3.

Pointers are GC by default, but can be declared as untraced 
pointers in code considered  system like in D.

--
Paulo
Feb 24 2015
parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
 I suspect it would be a terrible performance hit.


 It would be nice to have some numbers backing this up.



 This the approach taken by Active Oberon and Modula-3.

 Pointers are GC by default, but can be declared as untraced 
 pointers in code considered  system like in D.


Do they have concurrent gc and emit barriers for each write to a
default pointer? Do they have precise scanning and don't scan the
untraced pointers? Are the meaningful performance comparisons
between the two pointer types that would enable us to estimate
how costly emitting those barriers in D would be?
Feb 24 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/24/2015 1:30 AM, Tobias Pankrath wrote:

 Are the meaningful performance comparisons
 between the two pointer types that would enable us to estimate
 how costly emitting those barriers in D would be?


Even 10% makes it a no-go. Even 1%.

D has to be competitive in the most demanding environments. If you've got a 
server farm, 1% speedup means 1% fewer servers, and that can add up to millions 
of dollars.
Feb 24 2015
next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Tuesday, 24 February 2015 at 09:53:19 UTC, Walter Bright wrote:

 D has to be competitive in the most demanding environments.


But isn't that exactly the point?  Garbage collected D is NOT 
competitive in demanding environments.

-Wyatt
Feb 24 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/24/2015 5:28 AM, Wyatt wrote:

 On Tuesday, 24 February 2015 at 09:53:19 UTC, Walter Bright wrote:

 D has to be competitive in the most demanding environments.


 But isn't that exactly the point?  Garbage collected D is NOT competitive in
 demanding environments.


Write barriers are not the answer.
Feb 24 2015
prev sibling next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 24.02.2015 um 10:53 schrieb Walter Bright:

 On 2/24/2015 1:30 AM, Tobias Pankrath wrote:

 Are the meaningful performance comparisons
 between the two pointer types that would enable us to estimate
 how costly emitting those barriers in D would be?


 Even 10% makes it a no-go. Even 1%.

 D has to be competitive in the most demanding environments. If you've
 got a server farm, 1% speedup means 1% fewer servers, and that can add
 up to millions of dollars.


You seeing this completely one sided. Even if write barries make code 
slower by 10% its a non issue if the GC collections get faster by 10% as 
well. Then in average the program will run at the same speed.
Feb 25 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/25/15 1:27 PM, Benjamin Thaut wrote:

 Am 24.02.2015 um 10:53 schrieb Walter Bright:

 On 2/24/2015 1:30 AM, Tobias Pankrath wrote:

 Are the meaningful performance comparisons
 between the two pointer types that would enable us to estimate
 how costly emitting those barriers in D would be?


 Even 10% makes it a no-go. Even 1%.

 D has to be competitive in the most demanding environments. If you've
 got a server farm, 1% speedup means 1% fewer servers, and that can add
 up to millions of dollars.


 You seeing this completely one sided. Even if write barries make code
 slower by 10% its a non issue if the GC collections get faster by 10% as
 well. Then in average the program will run at the same speed.


Hmmmm... not sure the math works out that way. -- Andrei
Feb 25 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 25 February 2015 at 21:44:05 UTC, Andrei 
Alexandrescu wrote:

 You seeing this completely one sided. Even if write barries 
 make code
 slower by 10% its a non issue if the GC collections get faster 
 by 10% as
 well. Then in average the program will run at the same speed.


 Hmmmm... not sure the math works out that way. -- Andrei


Yeah the math are wrong, but the general idea remains.

I don't think it make sens to completely discard the idea of 
barriers, especially when it come to write barrier on the 
immutable heap. At least that should certainly pay off.
Feb 25 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2015 1:50 PM, deadalnix wrote:

 On Wednesday, 25 February 2015 at 21:44:05 UTC, Andrei Alexandrescu wrote:

 You seeing this completely one sided. Even if write barries make code
 slower by 10% its a non issue if the GC collections get faster by 10% as
 well. Then in average the program will run at the same speed.


 Hmmmm... not sure the math works out that way. -- Andrei


 Yeah the math are wrong, but the general idea remains.

 I don't think it make sens to completely discard the idea of barriers,
 especially when it come to write barrier on the immutable heap. At least that
 should certainly pay off.


Part of the equation is D simply does not use GC anywhere near as pervasively
as 
Java does, so the benefit/cost is greatly reduced for D.
Feb 25 2015
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Feb 25, 2015 at 04:36:22PM -0800, Walter Bright via Digitalmars-d wrote:

 On 2/25/2015 1:50 PM, deadalnix wrote:

On Wednesday, 25 February 2015 at 21:44:05 UTC, Andrei Alexandrescu wrote:

You seeing this completely one sided. Even if write barries make
code slower by 10% its a non issue if the GC collections get faster
by 10% as well. Then in average the program will run at the same
speed.


Hmmmm... not sure the math works out that way. -- Andrei


Yeah the math are wrong, but the general idea remains.

I don't think it make sens to completely discard the idea of
barriers, especially when it come to write barrier on the immutable
heap. At least that should certainly pay off.


 
 Part of the equation is D simply does not use GC anywhere near as
 pervasively as Java does, so the benefit/cost is greatly reduced for
 D.


Do you have data to back that up?

I don't know how typical this is, but in my own D code I tend to use
arrays a lot, and they do tend to add significant GC load. A recent
performance improvement attempt in one of my projects found that
collection cycles take up to 40% of total running time (it's a CPU-bound
process). Turning off GC collections and manually triggering them at
strategic points with lower frequency gave me huge performance
improvements, even though the collection cycles are still pretty slow.

I'm not sure how write barriers would play into this scenario, though.
The overall performance outside of GC collections would probably suffer
a bit, but it might be more than made up for by more accurate collection
cycles that take only a fraction of the time -- most of the scanned data
is live, only a small subset needs to be collected. A generational GC
would also greatly improve this particular use case, but that seems
really remote in D right now. In any case, a bit more investigation into
the actual costs/benefits of write barriers might give us more concrete
data to base decisions on, instead of just a blanket dismissal of the
whole idea.


T

-- 
It always amuses me that Windows has a Safe Mode during bootup. Does that mean
that Windows is normally unsafe?
Feb 25 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2015 4:50 PM, H. S. Teoh via Digitalmars-d wrote:

 On Wed, Feb 25, 2015 at 04:36:22PM -0800, Walter Bright via Digitalmars-d
wrote:

 On 2/25/2015 1:50 PM, deadalnix wrote:

 On Wednesday, 25 February 2015 at 21:44:05 UTC, Andrei Alexandrescu wrote:

 You seeing this completely one sided. Even if write barries make
 code slower by 10% its a non issue if the GC collections get faster
 by 10% as well. Then in average the program will run at the same
 speed.


 Hmmmm... not sure the math works out that way. -- Andrei


 Yeah the math are wrong, but the general idea remains.

 I don't think it make sens to completely discard the idea of
 barriers, especially when it come to write barrier on the immutable
 heap. At least that should certainly pay off.


 Part of the equation is D simply does not use GC anywhere near as
 pervasively as Java does, so the benefit/cost is greatly reduced for
 D.


 Do you have data to back that up?


I've written a Java compiler and and a GC for the Java VM (for Symantec, back
in 
the 90's.). I'm familiar with the code generated for Java, and the code 
generated for D.

Yes, I'm pretty comfortable with the assessment of how often pointers are GC 
pointers and how often they are not.



 I don't know how typical this is, but in my own D code I tend to use
 arrays a lot, and they do tend to add significant GC load. A recent
 performance improvement attempt in one of my projects found that
 collection cycles take up to 40% of total running time (it's a CPU-bound
 process). Turning off GC collections and manually triggering them at
 strategic points with lower frequency gave me huge performance
 improvements, even though the collection cycles are still pretty slow.


Note that you didn't need write barriers for that.



 I'm not sure how write barriers would play into this scenario, though.
 The overall performance outside of GC collections would probably suffer
 a bit, but it might be more than made up for by more accurate collection
 cycles that take only a fraction of the time -- most of the scanned data
 is live, only a small subset needs to be collected. A generational GC
 would also greatly improve this particular use case, but that seems
 really remote in D right now.


Writing a generational collector for D is possible right now with no language 
changes, it's just that nobody has bothered to do it. Don't need write barriers 
for it, either.



 In any case, a bit more investigation into
 the actual costs/benefits of write barriers might give us more concrete
 data to base decisions on, instead of just a blanket dismissal of the
 whole idea.


Except that I've actually written GCs that used write barriers.

I've been there, done that. Of course, I might still be wrong. If you want to 
prove me wrong, do the work. You don't need compiler changes to prove yourself 
right, you can code in the write barriers explicitly.
Feb 25 2015
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 26 February 2015 at 02:48:15 UTC, Walter Bright 
wrote:

 Writing a generational collector for D is possible right now 
 with no language changes, it's just that nobody has bothered to 
 do it. Don't need write barriers for it, either.


How are you planning to track assignment a pointer to the young 
generation in the old generation ? Because if you plan to rescan 
the whole old generation, this is not exactly a generational GC.
Feb 25 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2015 7:27 PM, deadalnix wrote:

 On Thursday, 26 February 2015 at 02:48:15 UTC, Walter Bright wrote:

 Writing a generational collector for D is possible right now with no language
 changes, it's just that nobody has bothered to do it. Don't need write
 barriers for it, either.


 How are you planning to track assignment a pointer to the young generation in
 the old generation ? Because if you plan to rescan the whole old generation,
 this is not exactly a generational GC.


A lot of benefit simply came from compacting all the remaining used allocations 
together, essentially defragging the memory.
Feb 25 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Thursday, 26 February 2015 at 04:08:32 UTC, Walter Bright 
wrote:

 On 2/25/2015 7:27 PM, deadalnix wrote:

 On Thursday, 26 February 2015 at 02:48:15 UTC, Walter Bright 
 wrote:

 Writing a generational collector for D is possible right now 
 with no language
 changes, it's just that nobody has bothered to do it. Don't 
 need write
 barriers for it, either.


 How are you planning to track assignment a pointer to the 
 young generation in
 the old generation ? Because if you plan to rescan the whole 
 old generation,
 this is not exactly a generational GC.


 A lot of benefit simply came from compacting all the remaining 
 used allocations together, essentially defragging the memory.


Is this implying you've begun work on a compacting D collector, 
or are you relating to your Java experiences?
Feb 25 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2015 8:51 PM, weaselcat wrote:

 Is this implying you've begun work on a compacting D collector,


No.


 or are you relating to your Java experiences?


Yes.
Feb 26 2015
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 26 February 2015 at 04:08:32 UTC, Walter Bright 
wrote:

 On 2/25/2015 7:27 PM, deadalnix wrote:

 On Thursday, 26 February 2015 at 02:48:15 UTC, Walter Bright 
 wrote:

 Writing a generational collector for D is possible right now 
 with no language
 changes, it's just that nobody has bothered to do it. Don't 
 need write
 barriers for it, either.


 How are you planning to track assignment a pointer to the 
 young generation in
 the old generation ? Because if you plan to rescan the whole 
 old generation,
 this is not exactly a generational GC.


 A lot of benefit simply came from compacting all the remaining 
 used allocations together, essentially defragging the memory.


That's is not answering the question at all.
Feb 25 2015
prev sibling next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 26.02.2015 um 05:08 schrieb Walter Bright:

 On 2/25/2015 7:27 PM, deadalnix wrote:

 On Thursday, 26 February 2015 at 02:48:15 UTC, Walter Bright wrote:

 Writing a generational collector for D is possible right now with no
 language
 changes, it's just that nobody has bothered to do it. Don't need write
 barriers for it, either.


 How are you planning to track assignment a pointer to the young
 generation in
 the old generation ? Because if you plan to rescan the whole old
 generation,
 this is not exactly a generational GC.


 A lot of benefit simply came from compacting all the remaining used
 allocations together, essentially defragging the memory.


What you are describing is a compacting GC and not a generational GC. 
Please just describe in words how you would do a generational GC without 
write barriers. Because just as deadalnix wrote, the problem is tracking 
pointers within the old generation that point to the new generation.
Feb 25 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2015 11:01 PM, Benjamin Thaut wrote:

 What you are describing is a compacting GC and not a generational GC. Please
 just describe in words how you would do a generational GC without write
 barriers. Because just as deadalnix wrote, the problem is tracking pointers
 within the old generation that point to the new generation.


It was a generational gc, I described earlier how it used page faults instead
of 
write barriers. I eventually removed the page fault system because it was
faster 
without it.
Feb 26 2015
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 26 February 2015 at 19:58:56 UTC, Walter Bright 
wrote:

 On 2/25/2015 11:01 PM, Benjamin Thaut wrote:

 What you are describing is a compacting GC and not a 
 generational GC. Please
 just describe in words how you would do a generational GC 
 without write
 barriers. Because just as deadalnix wrote, the problem is 
 tracking pointers
 within the old generation that point to the new generation.


 It was a generational gc, I described earlier how it used page 
 faults instead of write barriers. I eventually removed the page 
 fault system because it was faster without it.


Page fault ARE write barrier.
Feb 26 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/26/2015 12:29 PM, deadalnix wrote:

 Page fault ARE write barrier.


When we all start debating what the meaning of "is" is, it's time for me to 
check out.
Feb 26 2015
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 26 February 2015 at 20:56:25 UTC, Walter Bright 
wrote:

 On 2/26/2015 12:29 PM, deadalnix wrote:

 Page fault ARE write barrier.


 When we all start debating what the meaning of "is" is, it's 
 time for me to check out.


You are the one playing that game. You said earlier you used MMU 
as write barrier for a GC in Java, and now you are deciding that 
this is not a write barrier anymore.

But indeed, that settle the debate. If you are down to redefining 
things as not write barriers as to pretend you can implement what 
you redefine as a generational GC (which the rest of the world 
call a compacting GC) then what is there to discuss ? You don't 
seems to be up to date about recent GC technologies and/or 
terminology used in the area.
Feb 26 2015
prev sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/26/2015 09:29 PM, deadalnix wrote:

 Page fault ARE write barrier.


If done at kernel mode, it's too expensive anyhow.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJU8PBSAAoJELJzgRYSuxk58EgP/1ZJMTJ4srl8A+67dr1jpKwv
vqZlsKvbZ0ZpPZwO754TnWoaekgqPumvqmdjjHpOiV5fyu8mHBq81Jg9tJB9K3Yc
fedTM/xQtj+MTuARedyAqDAlzS7WBhc0Emx9QCBJJWwIuXu6aMvLZ9UO25eG0S/I
qXJ+/gIF6pfzmvn1/vsMzEkIeK75PslR8FQA9lGw30R9cN8vIeR5ZrOdyLv3w/Az
BbvjKg1086e7a9Gyxfo9ZXGmaoippxzx3jIAaqS9Gy6KZwNIrWqBX3fww+P3qqxZ
DstYPPp5b57xGjEt+e1vRDydW4OEHcQ1wEw7Ozfi/s6qCTRBj5xD9l+8idffyYYp
d76PcJGq3rByyP9ag1AxurEBVyIpPIPQNCy2/kwYET6s8aLc4FQsWtuI2oOp8fRs
m0k4pp9F8n62/PHjkbkUaHgFZOKedFeXfunT/21Be+pUhdFBwg438C70WerQt2Uy
UtiERO/2BhCCyq3+SFFtsfbCAFxPTNWCPbCnDhlPscrwl2YPCzYH1XvrdV0lWAG/
cI32lj7IdXWbO5otuO1qOPwbDVgLMTnpx2/wXrCriubTvBQTCeasJDlAcZYBAVyb
yQ1PZtbIN6Woa/6DJmR67YsuW3ag998oEXXP/LBo76rxE969OvcDi6Kh01MzweGb
i+QKVhgLT57Yw1urIwlY
=gVgL
-----END PGP SIGNATURE-----
Feb 27 2015
parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 27 February 2015 at 22:32:06 UTC, Martin Nowak wrote:

 On 02/26/2015 09:29 PM, deadalnix wrote:

 Page fault ARE write barrier.


 If done at kernel mode, it's too expensive anyhow.


As mentioned, it is not for the immutable part of the heap, for 
obvious reasons.
Feb 27 2015
prev sibling next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 26.02.2015 um 20:58 schrieb Walter Bright:

 It was a generational gc, I described earlier how it used page faults
 instead of write barriers. I eventually removed the page fault system
 because it was faster without it.


Page faults are inferrior to compiler generated write barriers. Because 
with a page fault startegy you pay for every write. Even if the write 
does not write a pointer. Compiler generated write barriers only apply 
to pointers written through another pointer.
Feb 26 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 26 February 2015 at 21:17:57 UTC, Benjamin Thaut 
wrote:

 Am 26.02.2015 um 20:58 schrieb Walter Bright:

 It was a generational gc, I described earlier how it used page 
 faults
 instead of write barriers. I eventually removed the page fault 
 system
 because it was faster without it.


 Page faults are inferrior to compiler generated write barriers. 
 Because with a page fault startegy you pay for every write. 
 Even if the write does not write a pointer. Compiler generated 
 write barriers only apply to pointers written through another 
 pointer.


It is a tradeof.

You can implement write barrier in the codegen. In which case you 
check them every time, but only for pointers. The check is cheap 
but creeping.

You can implemented them using memory protection. In which case 
it is WAY more expensive and will trap all the write, but ONLY 
when needed (it can be turned on and off) and usually you trap 
once per page.

Note that in D, you have union and all kind of crap like that, so 
what is writing a pointer is non obvious and so the tradeof is 
very different than it is in other languages.
Feb 26 2015
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 27.02.2015 um 00:05 schrieb deadalnix:

 Note that in D, you have union and all kind of crap like that, so what
 is writing a pointer is non obvious and so the tradeof is very different
 than it is in other languages.


To have any chance of implementing a better GC in D I would simly start 
of with assuming all code is  safe. For code that is not  safe the user 
would have to make sure it plays nice with the GC. This would also apply 
to unions which contain pointer types. If you wan't to write a good GC 
that does support non  safe features without user input you don't even 
have to start in my opinion.
Feb 26 2015
parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 27 February 2015 at 07:09:20 UTC, Benjamin Thaut wrote:

 Am 27.02.2015 um 00:05 schrieb deadalnix:

 Note that in D, you have union and all kind of crap like that, 
 so what
 is writing a pointer is non obvious and so the tradeof is very 
 different
 than it is in other languages.


 To have any chance of implementing a better GC in D I would 
 simly start of with assuming all code is  safe. For code that 
 is not  safe the user would have to make sure it plays nice 
 with the GC. This would also apply to unions which contain 
 pointer types. If you wan't to write a good GC that does 
 support non  safe features without user input you don't even 
 have to start in my opinion.


That is a reasonable approach (and indeed, I would assume that 
 system code have to ensure that it does not do something that 
will confuse the GC).

Still, what you can do when compiling AOT is different than what 
you can do when you JIT. For instance, when you JIT, you can add 
write barrier and remove them on the fly when you need to. When 
doing AOT, they must be always on or always of.
Feb 27 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-02-26 20:58, Walter Bright wrote:


 It was a generational gc, I described earlier how it used page faults
 instead of write barriers. I eventually removed the page fault system
 because it was faster without it.


Instead you used?

-- 
/Jacob Carlborg
Feb 26 2015
prev sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 02/26/2015 05:08 AM, Walter Bright wrote:

 
 A lot of benefit simply came from compacting all the remaining used
 allocations together, essentially defragging the memory.


Compacting is indeed easy once we have a precise GC, and can be done
partially, i.e. objects pointed to by the stack/register are pinned.
Mar 02 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/2/2015 11:38 AM, Martin Nowak wrote:

 Compacting is indeed easy once we have a precise GC, and can be done
 partially, i.e. objects pointed to by the stack/register are pinned.


Also unions.
Mar 02 2015
parent "Martin Nowak" <code dawg.eu> writes:
On Tuesday, 3 March 2015 at 02:05:08 UTC, Walter Bright wrote:

 On 3/2/2015 11:38 AM, Martin Nowak wrote:

 Compacting is indeed easy once we have a precise GC, and can 
 be done
 partially, i.e. objects pointed to by the stack/register are 
 pinned.


 Also unions.


Compacting doesn't solve the inherent performance problem of a 
conservative GC though. It's the capability to run small 
incremental collections that make modern GCs fast. With a 
conservative GC you always have to mark the complete heap to even 
free a single object. Shoveling a 1GB heap from main memory 
through your CPU already takes 250ms, and on top of that comes 
memory latency for non-sequential traversing and the actual 
marking.
Mar 03 2015
prev sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2015-02-25 at 18:48 -0800, Walter Bright via Digitalmars-d
wrote:

 On 2/25/2015 4:50 PM, H. S. Teoh via Digitalmars-d wrote:

 […]

 Do you have data to back that up?


 
 I've written a Java compiler and and a GC for the Java VM (for Symantec, back
in 
 the 90's.). I'm familiar with the code generated for Java, and the code 
 generated for D.


Have you studied the G1 GC? Any "data" from the 1990 regarding Java, and
indeed any other programming language with a lifespan of 20+years, is
suspect, to say the least. Also what is said above is not data, it is
opinion.

All too often in these mailing lists, performance issues are argued with
pure opinion and handwaving, not to mention mud-slinging. There should
be a rule saying that no-one, but no-one, is allowed to make any claims
about anything to do with performance without first having actually done
a proper experiment and presented actual real data with statistical
analysis.

Nigh on every GC-related comment in this thread has been a waste of time
reading. It must therefore have been a waste of time writing. Time that
could have been used doing something constructive. Perhaps the benchmark
module now has a lot of resource able to move it to being a tool for
making experiments to answer the questions with data rather than
unfounded opinion.


-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Feb 25 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 26 February 2015 at 07:05:56 UTC, Russel Winder 
wrote:

 pure opinion and handwaving, not to mention mud-slinging. There 
 should
 be a rule saying that no-one, but no-one, is allowed to make 
 any claims
 about anything to do with performance without first having 
 actually done
 a proper experiment and presented actual real data with 
 statistical
 analysis.


I agree in general, but one can argue the theoretical best 
performance based on computer architecture and language features. 
The fact is to get good performance you need cache-line friendly 
layout. D is stuck with:

1. Fixed C struct layout

2. Separate compilation units that leaves the compiler blind.

3. C backends that are less GC friendly than Java/Javascript.

4. No compiler control over multi-threading.

5. Generic programming without compiler optimized data layout 
(that hurts).

It is possible to do "atomic writes" cheaply on x86 if you stick 
everything on the same cache line, and schedule instructions 
around the SFENCE in a clever manner to prevent pipeline stalls.

It is possible to avoid pointers and use indexes thus limiting 
the extent of a precise scan.

So surely you can create an experiment that gets good performance 
close to the theoretical limit, but it does not tell you how it 
will work out with a complicated generic programming based 
program based on D semantics and "monkey programming".

Computer architecture is also moving. AFAIK, on Intel MIC you get 
fast RAM close to the core (multi layered on top) and slower 
shared RAM. There is also a big difference on memory bus 
throughput  ranging from ~5 - 30 GB/s peak on desktop CPUs.

But before you measure anything you need to agree on what you 
want measured. You need a baseline.  IMO, the only acceptable 
baseline is carefully hand crafted data layout and manual memory 
management...
Feb 26 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2015 11:05 PM, Russel Winder via Digitalmars-d wrote:

 Have you studied the G1 GC?


Nope.


 Any "data" from the 1990 regarding Java,


1998 or so. I wrote D's GC some years later.


 and indeed any other programming language with a lifespan of 20+years, is
 suspect, to say the least. Also what is said above is not data, it is
 opinion.


The day C++ compilers routinely generate write barriers is the day I believe 
they don't have runtime cost.
Feb 26 2015
prev sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/26/2015 01:50 AM, H. S. Teoh via Digitalmars-d wrote:

 I don't know how typical this is, but in my own D code I tend to
 use arrays a lot, and they do tend to add significant GC load. A
 recent performance improvement attempt in one of my projects found
 that collection cycles take up to 40% of total running time (it's a
 CPU-bound process).


Is this project public? I'd like to benchmark it with the new GC
growth strategy.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJU8PAQAAoJELJzgRYSuxk5yCcP/0lsmrM66SjwyxPfYzJmAsIA
mSCBogIoWpvL7R4uaZNvnYFBg50O1ddiLIIYaon4tX/b40UC6R36bFjx4A6j9WSr
PepNp0RFp8lFfXmeozPkJfEL3cVBFR70rrOySk2DNnFK/5heHXcR6gCyZ4xZaggi
gT5HtwhI/lZ5MKxpGk8sZpFDjaLHcGTHebjRV/sL+ItHAULcU8qgEm29yzlekgUY
v96EN0w83bwhjf2KZ97oKCWF6wW4tFKH+AXi2WoKjt/54xYyBS4tyXgtkMY9YmJ2
U8OQ03ASIP+tLlqJfexCwWxgHd8U9oUiHJoM9kCRw3XxwnlLIV1h/R9TBPrRcQFu
8DVQgniHiGab0tvhX9pD9q7blILsEPArSIIXFCTEU534dhjSplYu4Fu3Os7dGR5+
/ughG/ZyzLOJWI2iaI7H0hL2UVcO69pnTToOZYEHlZhFGHTxjPuesDsJUIv7ZjDN
iOWYgLVk3pFHDctIhhFJoqyHSz4pbadmU2bCksrT3S1feHyadmitE2eA5OwCpz9Z
Iz5jCGpN4QxF38PTg9OT3h5xRZvS2S3NvfzKdRzCfEzFBq7dUy1q34ir86Cw4OmE
4vRRxIjNCwpeju17FWOnR11WLXIvNJYQqznXwKyPEZX9HvPK01GmgsfutBOHKOez
YvgGhDqNJIi5VGGZZAju
=1GfD
-----END PGP SIGNATURE-----
Feb 27 2015
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Feb 27, 2015 at 11:30:40PM +0100, Martin Nowak via Digitalmars-d wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 On 02/26/2015 01:50 AM, H. S. Teoh via Digitalmars-d wrote:

 I don't know how typical this is, but in my own D code I tend to
 use arrays a lot, and they do tend to add significant GC load. A
 recent performance improvement attempt in one of my projects found
 that collection cycles take up to 40% of total running time (it's a
 CPU-bound process).


 
 Is this project public? I'd like to benchmark it with the new GC
 growth strategy.


[...]

I haven't posted the code anywhere so far, though I probably will in the
future. If you like, though, I could send you a tarball for you to play
around with.


T

-- 
The day Microsoft makes something that doesn't suck is probably the day they
start making vacuum cleaners... -- Slashdotter
Feb 27 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 26 February 2015 at 00:36:26 UTC, Walter Bright 
wrote:

 On 2/25/2015 1:50 PM, deadalnix wrote:

 On Wednesday, 25 February 2015 at 21:44:05 UTC, Andrei 
 Alexandrescu wrote:

 You seeing this completely one sided. Even if write barries 
 make code
 slower by 10% its a non issue if the GC collections get 
 faster by 10% as
 well. Then in average the program will run at the same speed.


 Hmmmm... not sure the math works out that way. -- Andrei


 Yeah the math are wrong, but the general idea remains.

 I don't think it make sens to completely discard the idea of 
 barriers,
 especially when it come to write barrier on the immutable 
 heap. At least that
 should certainly pay off.


 Part of the equation is D simply does not use GC anywhere near 
 as pervasively as Java does, so the benefit/cost is greatly 
 reduced for D.


You seems to avoid the important part of my message : write 
barrier tend to be very cheap on immutable data. Because, as a 
matter of fact, you don't write immutable data (in fact you do to 
some extent, but the amount of write is minimal.

There is no reason not to leverage this for D, and java 
comparison are irrelevant on the subject as java does not have 
the concept of immutability.

The same way, we can use the fact that TL data are not supposed 
to refers to each others.
Feb 25 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2015 6:57 PM, deadalnix wrote:

 You seems to avoid the important part of my message : write barrier tend to be
 very cheap on immutable data. Because, as a matter of fact, you don't write
 immutable data (in fact you do to some extent, but the amount of write is
minimal.

 There is no reason not to leverage this for D, and java comparison are
 irrelevant on the subject as java does not have the concept of immutability.

 The same way, we can use the fact that TL data are not supposed to refers to
 each others.


Of course, you don't pay a write barrier cost when you don't write to data, 
whether it is immutable or not is irrelevant.
Feb 25 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 26 February 2015 at 04:11:42 UTC, Walter Bright 
wrote:

 On 2/25/2015 6:57 PM, deadalnix wrote:

 You seems to avoid the important part of my message : write 
 barrier tend to be
 very cheap on immutable data. Because, as a matter of fact, 
 you don't write
 immutable data (in fact you do to some extent, but the amount 
 of write is minimal.

 There is no reason not to leverage this for D, and java 
 comparison are
 irrelevant on the subject as java does not have the concept of 
 immutability.

 The same way, we can use the fact that TL data are not 
 supposed to refers to
 each others.


 Of course, you don't pay a write barrier cost when you don't 
 write to data, whether it is immutable or not is irrelevant.


It DOES matter as user tends to write way more mutable data than 
immutable ones. Pretending otherwise is ridiculous.
Feb 25 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2015 9:01 PM, deadalnix wrote:

 On Thursday, 26 February 2015 at 04:11:42 UTC, Walter Bright wrote:

 On 2/25/2015 6:57 PM, deadalnix wrote:

 You seems to avoid the important part of my message : write barrier tend to be
 very cheap on immutable data. Because, as a matter of fact, you don't write
 immutable data (in fact you do to some extent, but the amount of write is
 minimal.

 There is no reason not to leverage this for D, and java comparison are
 irrelevant on the subject as java does not have the concept of immutability.

 The same way, we can use the fact that TL data are not supposed to refers to
 each others.


 Of course, you don't pay a write barrier cost when you don't write to data,
 whether it is immutable or not is irrelevant.


 It DOES matter as user tends to write way more mutable data than immutable
ones.
 Pretending otherwise is ridiculous.


I don't really understand your point. Write barriers are emitted for code that 
is doing a write. This doesn't happen for code that doesn't do writes. For
example:

    x = 3: // write barrier emitted for write to x!
    y = x + 5; // no write barrier emitted for read of x!

How would making x immutable make (x + 5) faster?
Feb 26 2015
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 26 February 2015 at 20:15:37 UTC, Walter Bright 
wrote:

 I don't really understand your point. Write barriers are 
 emitted for code that is doing a write.


That is exactly the point? When you don't write, you don't pay 
for write barriers. It is fairly straightforward that the 
argument that write barrier are expensive and undesirable does 
not follow for immutable heap.
Feb 26 2015
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 02/25/2015 10:50 PM, deadalnix wrote:

 
 I don't think it make sens to completely discard the idea of barriers,
 especially when it come to write barrier on the immutable heap. At least
 that should certainly pay off.


Before the argument gets lost.
http://forum.dlang.org/post/mcqr3s$cmf$1 digitalmars.com


 Write barriers would cost a low single digit, e.g. 3-4%.
 While searching for ways to avoid the cost I found an interesting


alternative to generational GCs.



https://github.com/D-Programming-Language/druntime/pull/1081#issuecomment-69151660



 Mar 02 2015



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 2/25/2015 1:27 PM, Benjamin Thaut wrote:

 You seeing this completely one sided. Even if write barries make code slower by
 10% its a non issue if the GC collections get faster by 10% as well. Then in
 average the program will run at the same speed.


You'll be paying that 10% penalty for every write access, not just for GC data. 
D is not Java in that D has a lot of objects that are not on the GC heap. 
Tradeoffs appropriate for Java are not necessarily appropriate for D.



 Feb 26 2015



  parent reply Benjamin Thaut <code benjamin-thaut.de>  writes:


Am 26.02.2015 um 21:39 schrieb Walter Bright:

 On 2/25/2015 1:27 PM, Benjamin Thaut wrote:

 You seeing this completely one sided. Even if write barries make code
 slower by
 10% its a non issue if the GC collections get faster by 10% as well.
 Then in
 average the program will run at the same speed.


 You'll be paying that 10% penalty for every write access, not just for
 GC data. D is not Java in that D has a lot of objects that are not on
 the GC heap. Tradeoffs appropriate for Java are not necessarily
 appropriate for D.


Write barries only have to be generated for writes to pointers through 
pointers. So you are not paying a penality for every write.

class Bar
{
   int x;
   Bar other;

   void method()
   {
     x = 5; // no write barrier
     other = this; // write barrier
   }
}

Also the following code will not generate a single write barrier:

void someFunc(uint[] ar)
{
   for(uint* it = someArray.ptr; it < ar.ptr + ar.length; it++)
   {
     *it = 5;
   }
}



 Feb 26 2015



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 2/26/2015 1:15 PM, Benjamin Thaut wrote:

 Am 26.02.2015 um 21:39 schrieb Walter Bright:

 You'll be paying that 10% penalty for every write access, not just for
 GC data. D is not Java in that D has a lot of objects that are not on
 the GC heap. Tradeoffs appropriate for Java are not necessarily
 appropriate for D.


 Write barries only have to be generated for writes to pointers through
pointers.


Of course.


 So you are not paying a penality for every write.


Sigh. That does not change the point of what I wrote.



 Feb 26 2015



prev sibling  parent  Martin Nowak <code+news.digitalmars dawg.eu>  writes:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/24/2015 10:53 AM, Walter Bright wrote:

 
 Even 10% makes it a no-go. Even 1%.


Write barriers would cost a low single digit, e.g. 3-4%.
While searching for ways to avoid the cost I found an interesting
alternative to generational GCs.

https://github.com/D-Programming-Language/druntime/pull/1081#issuecomment-69151660
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJU8O+kAAoJELJzgRYSuxk5dbIP/2+BWeTD8nWzxFwoUugwD7k3
+JqfKi3BFOpY+bQbg/ct+hlDcVcVMUvz/pqyMqll1v/axZasWjtNd/wydepRovv+
FU9xHyS5dSJHb/5TU6OJDHYsFBDg3a+CS1OfGXpIdpWyVAWE5ZojU916DhddxOfB
Mb4cxoLUe7spRHVQ+eiXttYG97O7vVmmy7zY1/h5CUxgWLAoJe9DD4HpbgR4BaDS
zmIsNMJf8rooZhIxbWiy0WJu6YFesSR8amVqiw3+Zd1ijeOyT6Pe5EC4gyvjXhoC
BwvfnM0s0c3VlbWxtXdHqnJ0A8V1/XJCQ3DXSUD2D4AY2rhwkC5bLIPPyrpm86xg
oGhXWwYJax9lVJCSEjJnL4p1lj+MoUpjrUMS/vEqk37p4VHcWGj6jspkq0MEVWJE
wSUD/hrihzzpOHRjBxQLZWUo+JnvS+xZL/PN2sK7T1dhsZujGYIUZodmS+3915dQ
kjsXXSAT0/vL+kM1WgTlDe/vxZ+toS/tuOVrRLHGktvXAKEJWUpulNKKj/bvaNUZ
HNG41R+LLcOyGM0QP4TH0opUtro09EWQoT+1wIuKtZA1Ect9vCJfFmz2a8YE3MWu
Q4DzY7WTQ6mCG4Kh63Ya1uJA+DKS4Abyfsu0TGfbR0GpKHer8f5Ni+kZTKM69IZn
NLB9QRBtFxFSNZhZH10Y
=aDb/
-----END PGP SIGNATURE-----



 Feb 27 2015



prev sibling  parent reply "Paulo  Pinto" <pjmlp progtools.org>  writes:


On Tuesday, 24 February 2015 at 09:30:33 UTC, Tobias Pankrath 
wrote:

 I suspect it would be a terrible performance hit.


 It would be nice to have some numbers backing this up.



 This the approach taken by Active Oberon and Modula-3.

 Pointers are GC by default, but can be declared as untraced 
 pointers in code considered  system like in D.


 Do they have concurrent gc and emit barriers for each write to a
 default pointer? Do they have precise scanning and don't scan 
 the
 untraced pointers? Are the meaningful performance comparisons
 between the two pointer types that would enable us to estimate
 how costly emitting those barriers in D would be?


Both Active Oberon and Modula-3 support threading at language 
level, so multi-threading is a presence on their runtimes.

The latest documentation available for Active Oberon is from 2002.

http://e-collection.library.ethz.ch/view/eth:26082

Originally it was a concurrent mark-and-sweep GC, with stop the 
world phase for collection.

Other algorithms are discussed on the paper. Sadly ETHZ is done 
with Oberon as their startup failed to pick up steam in the 
industry (selling Component Pascal, an evolution of Oberon-2).

As for Modula-3, due to the way the the whole DEC, Olivetti, 
Compaq, HP process went, it isn't easy to find much documentation 
online. I had a few books.

The latest implementation had a concurrent incremental 
generational GC.

https://modula3.elegosoft.com/cm3/doc/help/cm3/gc.html

2002 is also around the same time that Modula-3 developed was 
stopped.

Dylan, which I just remembered while writing this, used the MPS 
collector.

http://www.ravenbrook.com/project/mps/doc/2002-01-30/ismm2002-paper/ismm2002.html

Sadly the industry went JVM/CLR instead, and only now we are 
getting back to native systems programming with GC languages.

If those languages had been picked up by the industry instead of 
JVM/CLR, the situation could be quite different.

As always, it is a matter where the money for research gets 
pumped into.

--
Paulo



 Feb 24 2015



  parent reply "Tobias Pankrath" <tobias pankrath.net>  writes:


 The latest implementation had a concurrent incremental 
 generational GC.

 https://modula3.elegosoft.com/cm3/doc/help/cm3/gc.html


According to this they never had a concurrent or incremental GC 
on x86.



 Feb 24 2015



  parent reply "Paulo  Pinto" <pjmlp progtools.org>  writes:


On Tuesday, 24 February 2015 at 11:08:59 UTC, Tobias Pankrath 
wrote:

 The latest implementation had a concurrent incremental 
 generational GC.

 https://modula3.elegosoft.com/cm3/doc/help/cm3/gc.html


 According to this they never had a concurrent or incremental GC 
 on x86.


Sorry about the caps, couldn't find a better way to emphasis. Not 
sure where you found out the information about x86, or why it 
should matter.

"The current collector is, by default, INCREMENTAL and 
GENERATIONAL. The interruptions of service should be very small, 
and the overall performance should be better than with the 
previous collectors."

"Note that the new optional BACKGROUND collection THREAD is not 
on by default; this may change in the future."

I take this to understand that the latest collector was 
incremental, with the ability to work concurrently when the 
background collection was enabled, on some CPU architecture, 
regardless which one.

Modula-3 died when its team kept changing hands between DEC, 
Olivetti, Compaq and HP.

It hardly had any new development since 2000, its GC would surely 
look differently if development hadn't stopped and maybe even be 
quite good on x86.

--
Paulo



 Feb 24 2015



  parent reply "Tobias Pankrath" <tobias pankrath.net>  writes:


On Tuesday, 24 February 2015 at 12:31:06 UTC, Paulo  Pinto wrote:

 Sorry about the caps, couldn't find a better way to emphasis. 
 Not sure where you found out the information about x86, or why 
 it should matter.


I found an (apparently older) version of the documentation 
earlier that looked exactly the same, so I didn't mind to read 
your link carefully enough.


 "The current collector is, by default, INCREMENTAL and 
 GENERATIONAL. The interruptions of service should be very 
 small, and the overall performance should be better than with 
 the previous collectors."


Yes, however from your page now:


 Now  M3novm is the default.


And if you follow the link:


  M3novm implies  M3noincremental and  M3nogenerational.


Maybe, that's an documentation error. This was the place where 
the other version
mentioned that x86 is not supported.

While I like that you constantly remind us about achievements of 
older programming languages, you'll often do it with a "that 
problem was solved in Language X 20 years ago"-attitude, but 
almost never elaborate how that solution could be applied to D. 
When taking a closer look, I often find that those languages 
solved an similar but different problem and the solution do not 
apply to D at all. For example the last time in the discussion on 
separate compilation, templates and object files you blamed the C 
tool chain and pointed to pascal/delphi. But they didn't solved 
the problem, because they didn't faced it in the first place, 
because they didn't had the template and meta-programming 
capabilities of D.

At the problem at hand: I don't see how Module3's distinction 
between system and default pointer types or the lessons they 
learned help in any way to improve the current D GC.



 Feb 24 2015



  parent  "Paulo  Pinto" <pjmlp progtools.org>  writes:


On Tuesday, 24 February 2015 at 13:07:38 UTC, Tobias Pankrath 
wrote:

 On Tuesday, 24 February 2015 at 12:31:06 UTC, Paulo  Pinto 
 wrote:

 Sorry about the caps, couldn't find a better way to emphasis. 
 Not sure where you found out the information about x86, or why 
 it should matter.


 I found an (apparently older) version of the documentation 
 earlier that looked exactly the same, so I didn't mind to read 
 your link carefully enough.


 "The current collector is, by default, INCREMENTAL and 
 GENERATIONAL. The interruptions of service should be very 
 small, and the overall performance should be better than with 
 the previous collectors."


 Yes, however from your page now:


 Now  M3novm is the default.


 And if you follow the link:


  M3novm implies  M3noincremental and  M3nogenerational.


 Maybe, that's an documentation error. This was the place where 
 the other version
 mentioned that x86 is not supported.

 While I like that you constantly remind us about achievements 
 of older programming languages, you'll often do it with a "that 
 problem was solved in Language X 20 years ago"-attitude, but 
 almost never elaborate how that solution could be applied to D. 
 When taking a closer look, I often find that those languages 
 solved an similar but different problem and the solution do not 
 apply to D at all. For example the last time in the discussion 
 on separate compilation, templates and object files you blamed 
 the C tool chain and pointed to pascal/delphi. But they didn't 
 solved the problem, because they didn't faced it in the first 
 place, because they didn't had the template and 
 meta-programming capabilities of D.


Yes I agree with you, it is just that I would like to see a 
language like D being adopted at large, so as a language geek 
that has spent too much time in language research during the 
compiler design classes, I like to pull this information out of 
the attic.

When knowledge goes away people get other understanding of the 
reality, for example, many young developers think C was the very 
first systems programming language, which isn't the case given 
the research going on outside AT&T.

I am well aware that those solutions don't cover 100% D's use 
cases, but maybe they have enough juice to provide ideas in D 
context.

It is always a matter of research and funding for the said ideas.

If I was at academia, applying these ideas to improve D would be 
a good source for papers and thesis. As such, I cannot do much 
more than throw them over the wall and see if they can inspire 
someone.


 At the problem at hand: I don't see how Module3's distinction 
 between system and default pointer types or the lessons they 
 learned help in any way to improve the current D GC.


It helps reduce the pressure in the GC allocated memory, and also 
allows for giving pointers straight to external code.

Maybe given the type of implicit allocations in D vs Modula-3, it 
doesn't help.

But yeah, too much noise from a D dabbler I guess.

--
Paulo



 Feb 24 2015



prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 2/23/2015 11:53 PM, Jacob Carlborg wrote:

 On 2015-02-23 21:30, Walter Bright wrote:


 Count me among those.

 In Java, write barriers make sense because Java uses the GC for
 everything. Pretty much every indirection is a GC reference.

 This is not at all true with D code. But since the compiler can't know
 that, it has to insert write barriers for all those dereferences
 regardless.


 The alternative would be to have two kind of pointers, one for GC allocated
data
 and one for other kind of data. But I know you don't like that either.


That kinda defeats much of the point to having a GC.



 I suspect it would be a terrible performance hit.


 It would be nice to have some numbers backing this up.


I've seen enough benchmarks that purport to show that Java is just as fast as 
C++, as long as only primitive types are being used and not pointers.

I've done enough benchmarks to know that inserting even one extra instruction
in 
a tight loop has significant consequences. If you don't believe that, feel free 
to try it and see.

D is not going to have competitive performance with systems programming 
languages if write barriers are added.



 Feb 24 2015



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 2/24/2015 1:50 AM, Walter Bright wrote:

 On 2/23/2015 11:53 PM, Jacob Carlborg wrote:

 On 2015-02-23 21:30, Walter Bright wrote:

 I suspect it would be a terrible performance hit.


 It would be nice to have some numbers backing this up.


 I've seen enough benchmarks that purport to show that Java is just as fast as
 C++, as long as only primitive types are being used and not pointers.


Let me put it another way. You don't believe me about the performance hit. My 
experience with people who don't believe me is they won't believe any
benchmarks 
I produce, either. They'll say I didn't do the benchmark right, it is not 
representative, the data is cherry-picked, nobody would write code that way,
etc.

I quit writing benchmarks for public consumption for that reason years ago.

It shouldn't be hard for you to put together a benchmark you can believe in.



 Feb 24 2015



prev sibling  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Tuesday, 24 February 2015 at 07:53:52 UTC, Jacob Carlborg 
wrote:

 On 2015-02-23 21:30, Walter Bright wrote:


 Count me among those.

 In Java, write barriers make sense because Java uses the GC for
 everything. Pretty much every indirection is a GC reference.

 This is not at all true with D code. But since the compiler 
 can't know
 that, it has to insert write barriers for all those 
 dereferences
 regardless.


 The alternative would be to have two kind of pointers, one for 
 GC allocated data and one for other kind of data. But I know 
 you don't like that either.

 We kind of already have this, class references and regular 
 pointers. But that would tie classes to the GC.


 I suspect it would be a terrible performance hit.


 It would be nice to have some numbers backing this up.


The page fault strategy is used by ML family language's GC and 
they get really good performance out of it. That being said, in 
ML like language most things are immutable, so they are a



 Feb 24 2015



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 2/24/2015 11:07 AM, deadalnix wrote:

 The page fault strategy is used by ML family language's GC and they get really
 good performance out of it. That being said, in ML like language most things
are
 immutable, so they are a


I wrote a gc for Java that used the page fault strategy. It was slower and so I 
went with another strategy.



 Feb 24 2015



  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Tuesday, 24 February 2015 at 23:49:21 UTC, Walter Bright wrote:

 On 2/24/2015 11:07 AM, deadalnix wrote:

 The page fault strategy is used by ML family language's GC and 
 they get really
 good performance out of it. That being said, in ML like 
 language most things are
 immutable, so they are a


 I wrote a gc for Java that used the page fault strategy. It was 
 slower and so I went with another strategy.


That is fairly obvious. Java is not exactly putting emphasis on 
immutability...



 Feb 24 2015



prev sibling  parent reply Benjamin Thaut <code benjamin-thaut.de>  writes:


Am 22.02.2015 um 10:48 schrieb Russel Winder via Digitalmars-d:

 On Sun, 2015-02-22 at 10:21 +0100, Benjamin Thaut via Digitalmars-d
 wrote:

 Am 22.02.2015 um 03:13 schrieb Walter Bright:

 Nobody thinks GC is suitable for hard realtime.


 I think you should know manu good enough by now that you know he is not
 talking about hard realtime but soft realtime instead. (e.g. games)
 There are GCs which handle this situation pretty well but D's GC is not
 one of them.


 If the D GC really is quite so bad, why hasn't a cabal formed to create
 a new GC that is precise, fast and efficient?


There have been countless dicussions about D's GC and how bad it is, and 
how to improve it. But it always turns out that it would be a ton of 
work or someone doesn't like the consequences. The key points always are:

1) We need full percise pointer discovery, even for pointers on the stack.
2) We need write barriers.

1) Is a really complex task for a language like D. There is a reason why 
java has so a small feature set.
2) For some reason nobody likes write barries because the general fear 
is, that they will cost performance, so it was decided to not implement 
them. (Without actually measuring performance impact vs GC improvement)

The problem is that, to implement a non stop-the-world-GC you need 2) 


So until there is no implementation for any of the both mentioned 
points, there will be no better GC in D. You can fake 2) with fork on 
linux, thats what the CDGC did (see the DConf talk). This works because 
fork has copy on write semantics, but there is no equivalent on Windows. 
Experiments by Rainer Schuetze to implement similar copy on write 
semantics on Windows have shown to have major overhead which is most 
likely even worse then implementing write barries themselfs. Experiments 
implementing a Heap-percise GC, again by Rainer Schuetze, have schon 
that percicse heap scanning is slower compared to impercise scanning.

In my opinion the key problem is, that D was designed in a way that 
requires a GC but D was not designed in a way to propperly support a GC. 
(shared, immutable and other things basically prevent thread local pools).

Kind Regards
Benjamin



 Feb 22 2015



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Sunday, 22 February 2015 at 12:55:17 UTC, Benjamin Thaut wrote:

 1) We need full percise pointer discovery, even for pointers on 
 the stack.
 2) We need write barriers.

 1) Is a really complex task for a language like D. There is a 
 reason why java has so a small feature set.


Worse than complex, you need a strongly typed language. D's type 
system is ad hoc, aka broken.


 2) For some reason nobody likes write barries because the 
 general fear is, that they will cost performance, so it was 
 decided to not implement them. (Without actually measuring 
 performance impact vs GC improvement)


Barriers in a loop is not good...

3. you need to get rid of destructors et al from GC.


 The problem is that, to implement a non stop-the-world-GC you 

 you need 1).


Fortunately you can make do with "stop the GC threads" and still 
have good real time responsiveness. But that requires:

1. minimal scanning (implies significant language and compiler 
changes)

2. non-polluting cache friendly scanning (implies tunable or slow 
scan in favour of real time non-gc threads)



 Feb 22 2015



prev sibling  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 22 February 2015 at 12:13, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 2/21/2015 4:43 PM, Manu via Digitalmars-d wrote:

 D's GC is terrible, and after 6 years hanging out in this place, I
 have seen precisely zero development on the GC front. Nobody can even
 imagine, let alone successfully implement a GC that covers realtime
 use requirements.



 Nobody thinks GC is suitable for hard realtime.



 On the other hand, if 'scope' is implemented well, D may have some of
 the best tools in town for quality ARC implementation. There is a
 visible way forward for quality RC in D, and I think we could do
 better than Apple.



 With 'return ref', which is now implemented, you can create a memory safe
 RefCounted type. However, nobody has bothered. Are you up for it? :-)


I can't overload on 'scope'. How can I create a scope
constructor/destructor/postblit that doesn't perform the ref fiddling?

On a tangent, can I pass rvalues to ref args now? That will massively
sanitise linear algebra (matrix/vector) code big time!



 Feb 22 2015



 next sibling parent  "deadalnix" <deadalnix gmail.com>  writes:


On Sunday, 22 February 2015 at 16:15:44 UTC, Manu wrote:

 I can't overload on 'scope'. How can I create a scope
 constructor/destructor/postblit that doesn't perform the ref 
 fiddling?

 On a tangent, can I pass rvalues to ref args now? That will 
 massively
 sanitise linear algebra (matrix/vector) code big time!


The return ref thing is a feature that do not pay for itself.



 Feb 22 2015



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 2/22/2015 8:15 AM, Manu via Digitalmars-d wrote:

 I can't overload on 'scope'. How can I create a scope
 constructor/destructor/postblit that doesn't perform the ref fiddling?


I don't understand what you're trying to do.



 Feb 22 2015



  parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 23 February 2015 at 06:49, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 2/22/2015 8:15 AM, Manu via Digitalmars-d wrote:

 I can't overload on 'scope'. How can I create a scope
 constructor/destructor/postblit that doesn't perform the ref fiddling?



 I don't understand what you're trying to do.


struct RCThing
{
  RefType *instance;

  this(this) { IncRef(instance); }
  ~this() { DecRef(instance); }

  this(this) scope {} // <- scope instances don't need ref fiddling
  ~this() scope {}
}

Or various permutations along those lines.
Ie, library types may eliminate their ref fiddling when they are scope.



 Feb 22 2015



prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Manu via Digitalmars-d"  wrote in message 
news:mailman.7037.1424565826.9932.digitalmars-d puremagic.com...


 I personally think ARC in D is the only way forwards. That is an
 unpopular opinion however... although I think I'm just being realistic
 ;)


A big part of why it's unpopular is that nobody, including you, wants to 
implement it to see if it's viable. 



 Feb 21 2015



  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 22 February 2015 at 13:53, Daniel Murphy via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 "Manu via Digitalmars-d"  wrote in message
 news:mailman.7037.1424565826.9932.digitalmars-d puremagic.com...


 I personally think ARC in D is the only way forwards. That is an
 unpopular opinion however... although I think I'm just being realistic
 ;)



 A big part of why it's unpopular is that nobody, including you, wants to
 implement it to see if it's viable.


I have no idea where to start. But I think there's a more significant
inhibiting factor; even if I were to spend months learning how to have
a go at such a thing, I'm already convinced it would be rejected in
principle. Why would anyone waste the time while it's so clearly off
the table?



 Feb 22 2015



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 2/22/15 8:36 AM, Manu via Digitalmars-d wrote:

 On 22 February 2015 at 13:53, Daniel Murphy via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 "Manu via Digitalmars-d"  wrote in message
 news:mailman.7037.1424565826.9932.digitalmars-d puremagic.com...


 I personally think ARC in D is the only way forwards. That is an
 unpopular opinion however... although I think I'm just being realistic
 ;)



 A big part of why it's unpopular is that nobody, including you, wants to
 implement it to see if it's viable.


 I have no idea where to start.


Simple approaches to reference counting are accessible to any software 
engineer. The right starting point is "I used reference counting in this 
project, and here are my findings".

A position such as the following makes the dialog very difficult:

1. One solution is deemed the only viable.

2. Details and difficulties are unknown to the proposer.

3. It must be implemented by others, not the proposer.

4. It must be part of the language; any experimentation outside the 
language is considered an unnecessary waste of time.


Andrei



 Feb 22 2015



  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 23 February 2015 at 03:13, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 2/22/15 8:36 AM, Manu via Digitalmars-d wrote:

 On 22 February 2015 at 13:53, Daniel Murphy via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 "Manu via Digitalmars-d"  wrote in message
 news:mailman.7037.1424565826.9932.digitalmars-d puremagic.com...


 I personally think ARC in D is the only way forwards. That is an
 unpopular opinion however... although I think I'm just being realistic
 ;)




 A big part of why it's unpopular is that nobody, including you, wants to
 implement it to see if it's viable.



 I have no idea where to start.



 Simple approaches to reference counting are accessible to any software
 engineer. The right starting point is "I used reference counting in this
 project, and here are my findings".

 A position such as the following makes the dialog very difficult:

 1. One solution is deemed the only viable.


Propose how GC will ever be a success?
I honestly don't care, I just want a solution that's acceptable. I
tried to convince myself that GC would be fine for half a decade now,
but I've run out of patience.
I've been sitting around waiting for years for someone to say how GC
will ever be an acceptable solution. How long do I have to wait?

Evidence suggests, there IS only one viable solution. Granted, that's
not proven viable; it has barely been explored. (on account of
borderline religious opposition)
I can see why GC will never work in D, I can not see why ARC will never work.


 2. Details and difficulties are unknown to the proposer.


I'm proposing that the *conversation* needs to be taken seriously.
Every time I've raised it in the past it's been immediately dismissed
and swiped off the table.

I'm not an expert on garbage collection, I have practically nothing to
add. I'm also not particularly interested in garbage collection (of
any form); I just want it to work.
But it doesn't take an expert to recognise that in 6 years, nobody has
presented any forward momentum on the GC front, no matter how
fantastical.
I can easily visualise a way forward with RC. There's plenty of room
for exploration. Sure it's not trivial, but maybe it's *possible*, as
it certainly seems that GC is not.


 3. It must be implemented by others, not the proposer.


It must be discussed before we even think about implementing it.
And that is predicated by not being dismissed on impact.


 4. It must be part of the language; any experimentation outside the language
 is considered an unnecessary waste of time.


RC performance in a lib depends a lot on scope overloads of
constructor/destructor/postblit to eliminate ref fiddling code.
Scope proposals were butchered. I'm disappointed with where that went.



 Feb 22 2015



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 2/22/15 5:57 PM, Manu via Digitalmars-d wrote:

 I can easily visualise a way forward with RC.


Then do it. Frankly it seems to me you're doing anything you possibly 
can to talk yourself out of doing work.

Andrei



 Feb 22 2015



  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 23 February 2015 at 14:11, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 2/22/15 5:57 PM, Manu via Digitalmars-d wrote:

 I can easily visualise a way forward with RC.



 Then do it. Frankly it seems to me you're doing anything you possibly can to
 talk yourself out of doing work.


Excellent technique to immediately invalidate everything someone says.
Thanks for that.
You dismissed absolutely everything I said, and then imply that I have
no right to comment unless I do it myself.
It's got nothing to do with doing work. ARC (or something like it) is
almost religiously opposed. We can't even have a reasonable
conversation about it, or really explore it's implications before
someone (that ideally know's what they're doing) thinks about writing
code. There's no room for progress in this environment.

What do you want me to do? I use manual RC throughout my code, but the
experience in D today is identical to C++. I can confirm that it's
equally terrible to any C++ implementation I've used. We have no tools
to improve on it.
And whatever, if it's the same as C++, I can live with it. I've had
that my whole career (although it's sad, because we could do much
better).
The problem, as always, is implicit allocations, and allocations from
3rd party libraries. While the default allocator remains incompatible
with workloads I care about, that isolates us from virtually every
library that's not explicitly written to care about my use cases.
That's the situation in C++ forever. We're familiar with it, and it's
shit. I have long hoped we would move beyond that situation in D

but it's a massive up-hill battle to even gain mindshare, regardless
of actual implementation. There's no shared vision on this matter, the
word is basically "GC is great, everyone loves it, use an RC lib".

How long do we wait for someone to invent a fantastical GC that solves
our problems and works in D? I think it's practically agreed that no
known design can work, but nobody wants to bite the bullet and accept
the fact.
We need to admit we have an impassable problem, and then maybe we can
consider alternatives openly. Obviously, it would be disruptive, but
it might actually work... which is better than where we seem to be
heading (with a velocity of zero).

The fact is, people who are capable of approaching this problem in
terms of actual code will never even attempt it until there's
resounding consensus that it's worth exploring.



 Feb 22 2015



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 2/22/2015 9:53 PM, Manu via Digitalmars-d wrote:

 It's got nothing to do with doing work. ARC (or something like it) is
 almost religiously opposed. We can't even have a reasonable
 conversation about it, or really explore it's implications before
 someone (that ideally know's what they're doing) thinks about writing
 code.


I participated in a very technical thread here on implementing ARC in D. I 
wanted to make it work - nothing was off the table, language changes, special 
features, etc.

http://www.digitalmars.com/d/archives/digitalmars/D/draft_proposal_for_ref_counting_in_D_211885.html

It was just unworkable, and nobody who participated in that thread had workable 
ideas on moving forward with it. Nothing since has come up that changes that.
If 
you've got some ideas, please present them taking into account the issues 
brought up in that thread.

Also, please take into account; proposals will not get much of a reception if 
they ignore these points:

1. Increment and decrement, ESPECIALLY DECREMENT, is EXPENSIVE in time and
bloat 
because of exceptions. Swift does it by NOT HAVING EXCEPTIONS. This is not an 
option for D.

2. As far as I can tell, the idea of flipping a compiler switch and the GC 
switches to ref counting is a pipe dream fantasy. You can probably make such a 
scheme work with a very limited language like Javascript, but it is never going 
to work with D's support for low level programming. The way RC and GC work is 
different enough that different user coding techniques will be used for them.

3. Memory safety is a requirement for any ARC proposal for D. Swift ignores 
memory safety concerns.

4. DIP25, now implemented, is a way to address memory safety in D while using 
reference counting. Any proposal for ARC needs to, at least, understand that 
proposal.

http://wiki.dlang.org/DIP25



 Feb 22 2015



 next sibling parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Monday, 23 February 2015 at 06:51:21 UTC, Walter Bright wrote:

 4. DIP25, now implemented, is a way to address memory safety in 
 D while using reference counting. Any proposal for ARC needs 
 to, at least, understand that proposal.


I asked further up in the thread if coroutines can hold onto 
"return ref", e.g. does the compiler prevent a yield?

It would be nice if you and Andrei admitted that you are in the 
land of complicated linear typing with "return ref".



 Feb 23 2015



prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 23 February 2015 at 16:50, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 2/22/2015 9:53 PM, Manu via Digitalmars-d wrote:

 It's got nothing to do with doing work. ARC (or something like it) is
 almost religiously opposed. We can't even have a reasonable
 conversation about it, or really explore it's implications before
 someone (that ideally know's what they're doing) thinks about writing
 code.



 I participated in a very technical thread here on implementing ARC in D. I
 wanted to make it work - nothing was off the table, language changes,
 special features, etc.

 http://www.digitalmars.com/d/archives/digitalmars/D/draft_proposal_for_ref_counting_in_D_211885.html

 It was just unworkable, and nobody who participated in that thread had
 workable ideas on moving forward with it. Nothing since has come up that
 changes that. If you've got some ideas, please present them taking into
 account the issues brought up in that thread.


Wow, I missed that one it seems.
I'll catch up.



 Also, please take into account; proposals will not get much of a reception
 if they ignore these points:

 1. Increment and decrement, ESPECIALLY DECREMENT, is EXPENSIVE in time and
 bloat because of exceptions. Swift does it by NOT HAVING EXCEPTIONS. This is
 not an option for D.


This is going to sound really stupid... but do people actually use
exceptions regularly?
I've never used one. When I encounter code that does, I just find it
really annoying to debug. I've never 'gotten' exceptions. I'm not sure
why error codes are insufficient, other than the obvious fact that
they hog the one sacred return value.
D is just a whisker short of practical multiple-return-values. If we
cracked that, we could use alternative (superior?) error state return
mechanisms. I'd be really into that.

I'll agree though that this can't be changed at this point in the game.
You say that's a terminal case? Generating code to properly implement
a decrement chain during unwind impacts on the non-exceptional code
path?



 2. As far as I can tell, the idea of flipping a compiler switch and the GC
 switches to ref counting is a pipe dream fantasy. You can probably make such
 a scheme work with a very limited language like Javascript, but it is never
 going to work with D's support for low level programming. The way RC and GC
 work is different enough that different user coding techniques will be used
 for them.


I agree. I would suggest if ARC were proven possible, we would like, switch.



 3. Memory safety is a requirement for any ARC proposal for D. Swift ignores
 memory safety concerns.


What makes RC implicitly unsafe?



 Feb 23 2015



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 2/23/2015 1:50 AM, Manu via Digitalmars-d wrote:

 1. Increment and decrement, ESPECIALLY DECREMENT, is EXPENSIVE in time and
 bloat because of exceptions. Swift does it by NOT HAVING EXCEPTIONS. This is
 not an option for D.


 This is going to sound really stupid... but do people actually use
 exceptions regularly?


It doesn't matter if they do or not. It's a feature of D, and has to be 
supported. The only time it won't matter is if the intervening code is all 
'nothrow'.



 You say that's a terminal case? Generating code to properly implement
 a decrement chain during unwind impacts on the non-exceptional code
 path?


Since you don't believe me :-), write some shared_ptr code in C++ using your 
favorite compiler, compile it, and take a look at the generated assembler. I've 
asked you to do this before.

It's necessary to understand how exception unwinding works in order to 
pontificate about ARC.



 3. Memory safety is a requirement for any ARC proposal for D. Swift ignores
 memory safety concerns.


 What makes RC implicitly unsafe?


You already know the answer - saving pointers to the RC object's payload that 
then outlive the RC'd object.



 Feb 23 2015



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 2/23/15 3:27 AM, Walter Bright wrote:

 On 2/23/2015 1:50 AM, Manu via Digitalmars-d wrote:

 1. Increment and decrement, ESPECIALLY DECREMENT, is EXPENSIVE in
 time and
 bloat because of exceptions. Swift does it by NOT HAVING EXCEPTIONS.
 This is
 not an option for D.


 This is going to sound really stupid... but do people actually use
 exceptions regularly?


 It doesn't matter if they do or not. It's a feature of D, and has to be
 supported. The only time it won't matter is if the intervening code is
 all 'nothrow'.



 You say that's a terminal case? Generating code to properly implement
 a decrement chain during unwind impacts on the non-exceptional code
 path?


 Since you don't believe me :-), write some shared_ptr code in C++ using
 your favorite compiler, compile it, and take a look at the generated
 assembler. I've asked you to do this before.

 It's necessary to understand how exception unwinding works in order to
 pontificate about ARC.


BTW: http://asm.dlang.org

Andrei



 Feb 23 2015



prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Monday, 23 February 2015 at 09:51:07 UTC, Manu wrote:

 This is going to sound really stupid... but do people actually 
 use
 exceptions regularly?


I'd say exception are exceptional in most code. That being said, 
unless the compiler can PROVE that no exception is gonna be 
thrown, you are stuck with having to generate a code path for 
unwinding that decrement the refcount.

It means that you'll have code bloat (not that bad IMO, unless 
you are embeded) but more importantly, it means that most 
increment/decrement can't be optimized away in the regular path, 
as you must get the expected count in the unwinding path.

Moreover, as you get some work to do on the unwind path, it 
becomes impossible to do various optimizations like tail calls.

I think Walter is right when he says that switft dropped 
exception because of ARC.


 I've never used one. When I encounter code that does, I just 
 find it
 really annoying to debug. I've never 'gotten' exceptions. I'm 
 not sure
 why error codes are insufficient, other than the obvious fact 
 that
 they hog the one sacred return value.


Return error code have usually been an usability disaster for the 
simple reason that the do nothing behavior is to ignore the error.

The second major problem is that you usually have no idea how 
where the error check is done, forcing the programmer to bubble 
up the error where it is meaningful to handle it.


 I'll agree though that this can't be changed at this point in 
 the game.
 You say that's a terminal case? Generating code to properly 
 implement
 a decrement chain during unwind impacts on the non-exceptional 
 code
 path?


Yes as you can't remove increment/decrement pairs as there are 2 
decrement path (so there is pair).


 I agree. I would suggest if ARC were proven possible, we would 
 like, switch.


I'd like to see ARC support in D, but I do not think it makes 
sense as a default.


 3. Memory safety is a requirement for any ARC proposal for D. 
 Swift ignores
 memory safety concerns.


 What makes RC implicitly unsafe?


Without ownership, one can leak reference to RCed object that the 
RC system do not see.



 Feb 23 2015



  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 24 February 2015 at 10:36, deadalnix via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, 23 February 2015 at 09:51:07 UTC, Manu wrote:

 This is going to sound really stupid... but do people actually use
 exceptions regularly?



 I'd say exception are exceptional in most code. That being said, unless the
 compiler can PROVE that no exception is gonna be thrown, you are stuck with
 having to generate a code path for unwinding that decrement the refcount.

 It means that you'll have code bloat (not that bad IMO, unless you are
 embeded) but more importantly, it means that most increment/decrement can't
 be optimized away in the regular path, as you must get the expected count in
 the unwinding path.


Can the unwind path not be aware that the non-exceptional path had an
increment optimised away? Surely the unwind only needs to perform
matching decrements where an increment was generated...
I can easily imagine the burden ARC may place on the exceptional path,
but I can't visualise the influence it has on the normal path?



 Moreover, as you get some work to do on the unwind path, it becomes
 impossible to do various optimizations like tail calls.


Tail call is nice, but I don't think I'd lament the loss, especially
when nothrow (which is inferred these days) will give it right back.

Embedded code that can't handle the bloat would be required to use
nothrow to meet requirements. That's fine, it's a known constraint of
embedded programming.
Realtime/hot code may also need to use nothrow to guarantee all
optimisations are possible... which would probably be fine in most
cases? I'd find that perfectly acceptable.



 I think Walter is right when he says that switft dropped exception because
 of ARC.


But what was the definitive deal breaker? Was there one thing, like
it's actually impossible... or was it a matter of cumulative small
things leading them to make a value judgement?
We might make a different value judgement given very different circumstances.



 I've never used one. When I encounter code that does, I just find it
 really annoying to debug. I've never 'gotten' exceptions. I'm not sure
 why error codes are insufficient, other than the obvious fact that
 they hog the one sacred return value.



 Return error code have usually been an usability disaster for the simple
 reason that the do nothing behavior is to ignore the error.


I generally find this preferable to spontaneous crashing. That is,
assuming the do nothing behaviour with exceptions is for it to unwind
all the way to the top, which I think is the comparable 'do nothing'
case.

I've pondered using 'throw' in D, but the thing that usually kills it
for me is that I can't have a free catch() statement, it needs to be
structured with a try.
I just want to write catch() at a random line where I want unwinding
to stop if anything before it went wrong. Ie, implicit try{} around
all the code in the scope that comes before.
I don't know if that would tip me over the line, but it would go a
long way to making it more attractive. I just hate what exceptions do
to your code. But also, debuggers are terrible at handling them.



 The second major problem is that you usually have no idea how where the
 error check is done, forcing the programmer to bubble up the error where it
 is meaningful to handle it.


That's true, but I've never felt like exceptions are a particularly
good solution to that problem.
I don't find they make the code simpler. Infact, I find them to
produce almost the same amount of functional code, except with
additional indentation and brace spam, syntactic baggage, and bonus
allocations.

Consider:
if(tryAndDoThing() == Error.Failed)
  return Error.FailedForSomeReason;

if(tryNextThing() == Error.Failed)
  return Error.FailedForAnotherReason;

Compared to:
try
{
  doThing();
  nextThing();
}
catch(FirstKindOfException e)
{
  throw new Ex(Error.FailedForSomeReason);
}
catch(SecondKindOfException e)
{
  throw new Ex(Error.FailedForAnotherReason);
}

It's long and bloated (4 lines became 13 lines!), it allocates, is not
 nogc, etc.
Sure, it might be that you don't always translate inner exceptions to
high-level concepts like this and just let the inner exception bubble
up... but I often do want to have the meaningful translation of
errors, so this must at least be fairly common.



 I'll agree though that this can't be changed at this point in the game.
 You say that's a terminal case? Generating code to properly implement
 a decrement chain during unwind impacts on the non-exceptional code
 path?


 Yes as you can't remove increment/decrement pairs as there are 2 decrement
 path (so there is pair).


I don't follow. If you remove the increment, then the decrement is
just removed in both places...?
I can't imagine how it's different than making sure struct destructors
are called, which must already work right?



 I agree. I would suggest if ARC were proven possible, we would like,
 switch.


 I'd like to see ARC support in D, but I do not think it makes sense as a
 default.


Then we will have 2 distinct worlds. There will be 2 kinds of D code,
and they will be incompatible... I think that's worse.



 3. Memory safety is a requirement for any ARC proposal for D. Swift
 ignores
 memory safety concerns.



 What makes RC implicitly unsafe?



 Without ownership, one can leak reference to RCed object that the RC system
 do not see.


Obviously, ARC is predicated on addressing ownership. I think that's very clear.



 Feb 25 2015



 next sibling parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Wednesday, 25 February 2015 at 15:55:26 UTC, Manu wrote:

 On 24 February 2015 at 10:36, deadalnix via Digitalmars-d

 I'd like to see ARC support in D, but I do not think it makes 
 sense as a
 default.


 Then we will have 2 distinct worlds. There will be 2 kinds of D 
 code,
 and they will be incompatible... I think that's worse.


There are already at least 2 kinds of D code.  nogc and with gc...

Do you want ARC without regular pointers? I think you will find 
the performance disappointing...

I don't mind replacing the current GC with ARC, but only if ARC 
is used with the same low frequency as shared_ptr in C++...



 Feb 26 2015



prev sibling  parent  Johannes Pfau <nospam example.com>  writes:


Am Thu, 26 Feb 2015 01:55:14 +1000
schrieb Manu via Digitalmars-d <digitalmars-d puremagic.com>:


 I agree. I would suggest if ARC were proven possible, we would
 like, switch.
  


 I'd like to see ARC support in D, but I do not think it makes sense
 as a default.  


 
 Then we will have 2 distinct worlds. There will be 2 kinds of D code,
 and they will be incompatible... I think that's worse.


Excuse my ignorance, but I'm no longer sure what everybody in this
thread is actually arguing about:

Andrei's WIP DIP74 [1] adds compiler-recognized AddRef/Release calls to
classes. The compiler will _automatically_ call these. Of course the
compiler can then also detect and optimize dead AddRef/Release pairs.

All the exception issues Walter described also apply here and they also
apply for structs with destructors in general.

So I'd say DIP74 is basically ARC. Ironically structs which are better
for RC right now won't benefit from optimizations. However, it'd be
simple to also recognize Release/AddRef in structs to gain the
necessary information for optimization. It's not even necessary to call
these automatically, they can be called manually from struct dtor as
usual.

So what exactly is the difference between ARC and DIP74? Simply that
it's not the default memory management method? I do understand that
this makes a huge difference in practice, OTOH switching all D classes
to ARC seems very unrealistic as it could break code in subtle ways
(cycles).

But even if one wants ARC as a default, DIP74 is a huge step forward.
If library maintainers are convinced that ARC works well it will become
a quasi-default. I'd expect most game-related libraries (SFMLD,
derelict) will switch to RC classes.

[1] http://wiki.dlang.org/DIP74



 Feb 26 2015



prev sibling  parent reply "ponce" <contact gam3sfrommars.fr>  writes:


On Monday, 23 February 2015 at 09:51:07 UTC, Manu wrote:

 This is going to sound really stupid... but do people actually 
 use
 exceptions regularly?
 I've never used one. When I encounter code that does, I just 
 find it
 really annoying to debug. I've never 'gotten' exceptions. I'm 
 not sure
 why error codes are insufficient, other than the obvious fact 
 that
 they hog the one sacred return value.



I used to feel like that with exceptions. It's only after a 
position involving lots of legacy code that they revealed their 
value.

One (big) problem about error code is that they do get ignored, 
much too often. It's like manual memory management, everyone 
think they can do it without errors, but mostly everyone fail at 
it (me too, and you too).

Exceptions makes a program crash noisily so errors can't be 
ignored.
More importantly, ignoring an error code is invisible, while 
ignoring exceptions require explicit discarding and some thought.
Simply put, correctly handling error code is more code and more 
ugly.
Ignoring exception is no less code than ignoring error codes, but 
at least it will crash.


Secondly, one real advantage is pure readability improvement. The 
normal path looks clean and isn't cluttered with error code 
check. Almost everything can fail!

writeln("Hello");  // can fail
auto f = File("config.txt"); // can fail

What matter in composite operations is whether all of them 
succeeded or not.
Example: if the sequence of operations A-B-C failed while doing 
B, you are interested by the fact A-B-C has failed but not really 
that B failed specifically. So you would have to translate error 
codes from one formalism to another. What happens next is that 
error codes become conflated in the same namespace and reused in 
other unrelated places. Hence, error codes from library leak into 
code that should be isolated from it.


Lastly, exceptions have a hierarchy and allow to distinguish 
between bugs and input errors by convention.
Eg: Alan just wrote a function in a library that return an error 
code if it fails. The user program by Betty pass it a null 
pointer. This is a logic error as Alan disallowed it by contract. 
As Walter repeatedly said us, logic errors/bugs are not input 
errors and the only sane way to handle them is to crash.
But since this function error interface is an error code, Alan 
return something like ERR_POINTER_IS_NULL_CONTRACT_VIOLATED since 
well, no other choice. Now the logic error code gets conflated 
with error codes corresponding to input errors (ERR_DISK_FAILED), 
and both will be handled similarly by Betty for sure, and the 
earth begin to crackle.


Unfortunately exceptions requires exception safety, they may 
block some optimizations, and they may hamper debugging. That is 
usually a social blocker for more exception adoption in C++ 
circles, but once a group really get it, like RAII, you won't be 
able to take it away from them.



 Feb 24 2015



 next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Tuesday, 24 February 2015 at 23:02:14 UTC, ponce wrote:

 One (big) problem about error code is that they do get ignored, 
 much too often. It's like manual memory management, everyone 
 think they can do it without errors, but mostly everyone fail 
 at it (me too, and you too).


Explicit return values for errors is usually annoying, yes, but 
it is possible to have a language construct that isn't ignorable. 
That means you have to explicitly state that you are ignoring the 
error. E.g.

   open_file("file2")?.write("stuff")  // only write if file is 
ready
   open_file("file1")?.write("ffuts")  // only write if file is 
ready

   if ( error ) log_error() // log if some files were not ready

or:

   f = open_file(…)
   g = open_file(…)
   h = open_file(…)
   if( error(f,g,h) ) log_error


Also with async programming, futures/promises, the errors will be 
delayed, so you might be better off having them as part of the 
object.



 Feb 25 2015



  parent reply "ponce" <contact ga3mesfrommars.fr>  writes:


 or:

   f = open_file(…)
   g = open_file(…)
   h = open_file(…)
   if( error(f,g,h) ) log_error


 Also with async programming, futures/promises, the errors will 
 be delayed,


That's the problem with future/promises, you spent your time 
explaining who waits for what instead of just writing what things 
do.



 so you might be better off having them as part of the object.


No. If I can't open a file I'd better not create a File object in 
an invalid state. Invalid states defeats RAII.

So you can't re-enter that mutex as you asked, so I will grant 
you a scopedLock, but it is in an errored state so you'd better 
check that it is valid!



 Feb 26 2015



  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 26 February 2015 at 11:28:16 UTC, ponce wrote:

 That's the problem with future/promises, you spent your time 
 explaining who waits for what instead of just writing what 
 things do.


There are many ways to do futures, but I don't think it is all 
that complicated for the end user in most cases. E.g.

auto a = request_db1_async();
auto b = request_db2_async();
auto c = request_db3_async();
auto d = compute_stuff_async();
r = wait_for_all(a,b,c,d);
if( has_error(r) ) return failure;


 No. If I can't open a file I'd better not create a File object 
 in an invalid state. Invalid states defeats RAII.


This is the attitude I don't like, because it means that you have 
to use pointers when you could just embed the file-handle. That 
leads to more allocations and more cache misses.


 So you can't re-enter that mutex as you asked, so I will grant 
 you a scopedLock, but it is in an errored state so you'd better 
 check that it is valid!


A file can always enter an errored state. So can OpenGL. That 
doesn't mean you have to react immediately in all cases.

When you mmap a file you write to the file indirectly without any 
function calls. The disk could die... but how do you detect that? 
You wait until you msync() and detect it late. It is more 
efficient.



 Feb 26 2015



  parent reply "ponce" <contact gam3sfrommars.fr>  writes:


On Thursday, 26 February 2015 at 14:22:01 UTC, Ola Fosheim 
Grøstad wrote:

 No. If I can't open a file I'd better not create a File object 
 in an invalid state. Invalid states defeats RAII.


 This is the attitude I don't like, because it means that you 
 have to use pointers when you could just embed the file-handle. 
 That leads to more allocations and more cache misses.


I really don't understand how any of this is related to what we 
were previously discussing: error handling.



 So you can't re-enter that mutex as you asked, so I will grant 
 you a scopedLock, but it is in an errored state so you'd 
 better check that it is valid!


 A file can always enter an errored state. So can OpenGL. That 
 doesn't mean you have to react immediately in all cases.


This is counter to my experience.
It does't make much sense to go on after an error, in any 
software that want some reliability.



 Feb 27 2015



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Friday, 27 February 2015 at 15:53:18 UTC, ponce wrote:

 On Thursday, 26 February 2015 at 14:22:01 UTC, Ola Fosheim 
 Grøstad wrote:

 No. If I can't open a file I'd better not create a File 
 object in an invalid state. Invalid states defeats RAII.


 This is the attitude I don't like, because it means that you 
 have to use pointers when you could just embed the 
 file-handle. That leads to more allocations and more cache 
 misses.


 I really don't understand how any of this is related to what we 
 were previously discussing: error handling.


You wrote:

«No. If I can't open a file I'd better not create a File object in
an invalid state. Invalid states defeats RAII.»

If you embed the File object in other objects you also have to 
deal with the File object being in an invalid state. The 
alternative is to have discrete objects and nullable pointers to 
them. Makes sense for a high level programming language like  
Java, makes no sense for a system programming language.


 It does't make much sense to go on after an error, in any 
 software that want some reliability.


It does, when you do async buffering and want performance, e.g. 
OpenGL.

Often it also makes error-handling simpler. Often you don't care 
about when it failed, you often only care about the 
"transactional unit" as a whole.

It also makes programs more portable. There are big architectural 
differences when it comes to when errors can be reported. E.g. 
you don't want to wait for a networked drive to respond before 
going on. You only want to know if the "closing of the 
transaction" succeeded or not.



 Mar 01 2015



prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 25 February 2015 at 09:02, ponce via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, 23 February 2015 at 09:51:07 UTC, Manu wrote:

 This is going to sound really stupid... but do people actually use
 exceptions regularly?
 I've never used one. When I encounter code that does, I just find it
 really annoying to debug. I've never 'gotten' exceptions. I'm not sure
 why error codes are insufficient, other than the obvious fact that
 they hog the one sacred return value.




 I used to feel like that with exceptions. It's only after a position
 involving lots of legacy code that they revealed their value.

 One (big) problem about error code is that they do get ignored, much too
 often. It's like manual memory management, everyone think they can do it
 without errors, but mostly everyone fail at it (me too, and you too).

 Exceptions makes a program crash noisily so errors can't be ignored.


This is precisely my complaint though. In a production environment
where there are 10's, 100's of people working concurrently, it is
absolutely unworkable that code can be crashing for random reasons
that I don't care about all the time.
I've experienced before these noisy crashes relating to things that I
don't care about at all. It just interrupts my work, and also whoever
else it is that I have to involve to address the problem before I can
continue.

That is a real cost in time and money. I find that situation to be
absolutely unacceptable. I'll take the possibility that an ignored
error code may not result in a hard-crash every time.



 More importantly, ignoring an error code is invisible, while ignoring
 exceptions require explicit discarding and some thought.
 Simply put, correctly handling error code is more code and more ugly.
 Ignoring exception is no less code than ignoring error codes, but at least
 it will crash.


Right, but as above, this is an expense quantifiable in time and
dollars that I just can't find within me to balance by this reasoning.
I also prefer my crashes to occur at the point of failure. Exceptions
tend to hide the problem in my experience.
I find it so ridiculously hard to debug exception laden code. I have
no idea how you're meant to do it, it's really hard to find the source
of the problem!

Only way I know is to use break-on-throw, which never works in
exception laden code since exception-happy code typically throw for
common error cases which happen all the time too.



 Secondly, one real advantage is pure readability improvement. The normal
 path looks clean and isn't cluttered with error code check. Almost
 everything can fail!

 writeln("Hello");  // can fail


This only fails if runtime state is already broken. Problem is
elsewhere. Hard crash is preferred right here.


 auto f = File("config.txt"); // can fail


Opening files is a very infrequent operation, and one of the poster
child examples of where you would always check the error return. I'm
not even slightly upset by checking the return value from fopen.



 What matter in composite operations is whether all of them succeeded or not.
 Example: if the sequence of operations A-B-C failed while doing B, you are
 interested by the fact A-B-C has failed but not really that B failed
 specifically.


Not necessarily true. You often want to report what went wrong, not
just that "it didn't work".



 So you would have to translate error codes from one formalism
 to another. What happens next is that error codes become conflated in the
 same namespace and reused in other unrelated places. Hence, error codes from
 library leak into code that should be isolated from it.


I don't see exceptions are any different in this way. I see internal
exceptions bleed to much higher levels where they've totally lost
context all the time.



 Lastly, exceptions have a hierarchy and allow to distinguish between bugs
 and input errors by convention.
 Eg: Alan just wrote a function in a library that return an error code if it
 fails. The user program by Betty pass it a null pointer. This is a logic
 error as Alan disallowed it by contract. As Walter repeatedly said us, logic
 errors/bugs are not input errors and the only sane way to handle them is to
 crash.
 But since this function error interface is an error code, Alan return
 something like ERR_POINTER_IS_NULL_CONTRACT_VIOLATED since well, no other
 choice. Now the logic error code gets conflated with error codes
 corresponding to input errors (ERR_DISK_FAILED), and both will be handled
 similarly by Betty for sure, and the earth begin to crackle.


I'm not sure quite what you're saying here, but I agree with Walter.
In case of hard logic error, the sane thing to do is crash (ie,
assert), not throw...
I want my crash at the point of failure, not somewhere else.



 Unfortunately exceptions requires exception safety, they may block some
 optimizations, and they may hamper debugging. That is usually a social
 blocker for more exception adoption in C++ circles, but once a group really
 get it, like RAII, you won't be able to take it away from them.


Performance inhibition is a factor in considering that I've never used
exceptions, but it's certainly not the decisive reason.



 Feb 25 2015



 next sibling parent  "ponce" <contact gam3sfrommars.fr>  writes:


On Wednesday, 25 February 2015 at 16:39:38 UTC, Manu wrote:

 This is precisely my complaint though. In a production 
 environment
 where there are 10's, 100's of people working concurrently, it 
 is
 absolutely unworkable that code can be crashing for random 
 reasons
 that I don't care about all the time.
 I've experienced before these noisy crashes relating to things 
 that I
 don't care about at all. It just interrupts my work, and also 
 whoever
 else it is that I have to involve to address the problem before 
 I can
 continue.


I see what the problem can be. My feeling is that it is in part a 
workplace/codebase problem. Bugs that prevent other people from 
working aren't usually high on the roadmap. This also happen with 
assertions, and we have to disable them to do work then ; though 
assertions create no debate.

If the alternative is ignoring error codes, I'm not sure it's 
better. Anything could happen and then the database must be 
cleaned up.


 That is a real cost in time and money. I find that situation to 
 be
 absolutely unacceptable. I'll take the possibility that an 
 ignored
 error code may not result in a hard-crash every time.


True eg. you can ignore every OpenGL error it's kind of hardened.


 Right, but as above, this is an expense quantifiable in time and
 dollars that I just can't find within me to balance by this 
 reasoning.


To be fair, this cost has to be balanced with the cost of not 
finding a defect before sending it to the customer.



 I also prefer my crashes to occur at the point of failure. 
 Exceptions
 tend to hide the problem in my experience.


I would just put a breakpoint on the offending throw. THen it's 
no different.


 I find it so ridiculously hard to debug exception laden code. I 
 have
 no idea how you're meant to do it, it's really hard to find the 
 source
 of the problem!


I've seen this and this is true with things that need to retry 
something periodically with a giant try/catch.
try/catch at the wrong levels to "recover" too much things can 
also make it harder. Some (most?) things should really fail hard 
rather than resist errors.

I think gamedev is more of an exception since "continue anyway" 
might be a successful strategy in some capacity. Games are 
supposed to be "finished" at release which is something customers 
thankfully don't ask of most software.



 Only way I know is to use break-on-throw, which never works in
 exception laden code since exception-happy code typically throw 
 for
 common error cases which happen all the time too.


What I do is break-on-uncatched. Break-on-throw is moreoften than 
not hopelessly noisy like you said.

But I only deal with mostly reproducible bugs.


 Opening files is a very infrequent operation, and one of the 
 poster
 child examples of where you would always check the error 
 return. I'm
 not even slightly upset by checking the return value from fopen.


But how happy are you to bubble up the error condition up to call 
stack?

I'm of mixed opinion on that, seeing error code _feels_ nice and 
we can say to ourselves "I'm treating the error carefully". Much 
like we can say to ourselves "I'm carefully managing memory" when 
we manage memory manually. Somehow I like pedestrian work that 
really feels like work.

But that doesn't mean we do it efficiently or even in the right 
way, just that we _think_ it's done right.



 What matter in composite operations is whether all of them 
 succeeded or not.
 Example: if the sequence of operations A-B-C failed while 
 doing B, you are
 interested by the fact A-B-C has failed but not really that B 
 failed
 specifically.


 Not necessarily true. You often want to report what went wrong, 
 not
 just that "it didn't work".


Fortunately exceptions allows to bring up any information about 
what went wrong.

We often see on the Internet that "errors are best dealed with 
where they happen".

I could not disagree more.
Where "fopen" fails, I have no context to know I'm here because I 
was trying to save the game.

Error codes force to bubble up the error to be able to say 
"saving the game has failed", and then since you have used error 
codes without error strings you cannot even say "saving the game 
has failed because fopen has failed to open <filename>".

Now instead of just bubbling up error codes I must bubble up 
error messages too (I've done it). Great!

Errors-should-be-dealed-with-where-they-happen is a complete 
fallacy.


 I don't see exceptions are any different in this way. I see 
 internal
 exceptions bleed to much higher levels where they've totally 
 lost
 context all the time.


In my experience this is often due to sub-systems saving the ass 
of others by ignoring errors in the first place instead of either 
crashing of rebooting the faulty sub-system.



 I'm not sure quite what you're saying here, but I agree with 
 Walter.
 In case of hard logic error, the sane thing to do is crash (ie,
 assert), not throw...


assert throw Error for this purpose.


 Performance inhibition is a factor in considering that I've 
 never used
 exceptions, but it's certainly not the decisive reason.


And it's a valid concern. Some program parts also seldom need 
exceptions since mostly dealing with memory and few I/O.



 Feb 25 2015



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 2/25/2015 8:39 AM, Manu via Digitalmars-d wrote:

 I'll take the possibility that an ignored
 error code may not result in a hard-crash every time.


If you want some fun, take any system and fill up the disk drive to just short 
of capacity. Now go about your work using the system.

You'll experience all kinds of delightful, erratic behavior, because real world 
C code tends to ignore write failures and just carries on.



 Feb 26 2015



  parent  Jacob Carlborg <doob me.com>  writes:


On 2015-02-26 21:45, Walter Bright wrote:


 If you want some fun, take any system and fill up the disk drive to just
 short of capacity. Now go about your work using the system.

 You'll experience all kinds of delightful, erratic behavior, because
 real world C code tends to ignore write failures and just carries on.


It has happened to me quite often. It's usually no problem. Just 
(re)move some data an continue.

-- 
/Jacob Carlborg



 Feb 26 2015



prev sibling  parent  "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Thu, Feb 26, 2015 at 02:39:28AM +1000, Manu via Digitalmars-d wrote:

 On 25 February 2015 at 09:02, ponce via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Monday, 23 February 2015 at 09:51:07 UTC, Manu wrote:

 This is going to sound really stupid... but do people actually use
 exceptions regularly?






I wouldn't say I use them *all* the time, but I do use them. In
properly-designed code, they should be pretty rare, so I only really
have to deal with them in strategic places, not sprinkled throughout the
code.



 I've never used one. When I encounter code that does, I just find
 it really annoying to debug. I've never 'gotten' exceptions. I'm
 not sure why error codes are insufficient, other than the obvious
 fact that they hog the one sacred return value.


 I used to feel like that with exceptions. It's only after a position
 involving lots of legacy code that they revealed their value.

 One (big) problem about error code is that they do get ignored, much
 too often. It's like manual memory management, everyone think they
 can do it without errors, but mostly everyone fail at it (me too,
 and you too).

 Exceptions makes a program crash noisily so errors can't be ignored.


 
 This is precisely my complaint though. In a production environment
 where there are 10's, 100's of people working concurrently, it is
 absolutely unworkable that code can be crashing for random reasons
 that I don't care about all the time.


It doesn't have to crash if the main loop catches them and logs them to
a file where the relevant people can monitor for signs of malfunction.



 I've experienced before these noisy crashes relating to things that I
 don't care about at all. It just interrupts my work, and also whoever
 else it is that I have to involve to address the problem before I can
 continue.


Ideally, it should be the person responsible who's seeing the
exceptions, rather than you (if you were not responsible). I see this
more as a sign that something is wrong with the deployment process --
doesn't the person(s) committing the change test his changes before
committing, which should make production-time exceptions a rare
occurrence?



 That is a real cost in time and money. I find that situation to be
 absolutely unacceptable. I'll take the possibility that an ignored
 error code may not result in a hard-crash every time.


And the possibility of malfunction caused by ignored errors leading to
(possibly non-recoverable) data corruption is more acceptable?



 More importantly, ignoring an error code is invisible, while
 ignoring exceptions require explicit discarding and some thought.
 Simply put, correctly handling error code is more code and more
 ugly.  Ignoring exception is no less code than ignoring error codes,
 but at least it will crash.


 
 Right, but as above, this is an expense quantifiable in time and
 dollars that I just can't find within me to balance by this reasoning.
 I also prefer my crashes to occur at the point of failure. Exceptions
 tend to hide the problem in my experience.

 I find it so ridiculously hard to debug exception laden code. I have
 no idea how you're meant to do it, it's really hard to find the source
 of the problem!


Isn't the stacktrace attached to the exception supposed to lead you to
the point of failure?



 Only way I know is to use break-on-throw, which never works in
 exception laden code since exception-happy code typically throw for
 common error cases which happen all the time too.


"Exception-happy" sounds like wrong use of exceptions. No wonder you
have problems with them.



 Secondly, one real advantage is pure readability improvement. The
 normal path looks clean and isn't cluttered with error code check.
 Almost everything can fail!

 writeln("Hello");  // can fail


 
 This only fails if runtime state is already broken. Problem is
 elsewhere. Hard crash is preferred right here.


The problem is, without exceptions, it will NOT crash! If stdout is
full, for example (e.g., the logfile has filled up the disk), it will
just happily move along as if nothing is wrong, and at the end of the
day, the full disk will cause some other part of the code to
malfunction, but half of the relevant logs aren't there because they
were never written to disk in the first place, but the code didn't
notice because error codes were ignored. (And c'mon, when was the last
time you checked the error code of printf()? I never did, and I suspect
you never did either.)



 auto f = File("config.txt"); // can fail


 
 Opening files is a very infrequent operation, and one of the poster
 child examples of where you would always check the error return. I'm
 not even slightly upset by checking the return value from fopen.


I believe that was just a random example; it's unfair to pick on the
specifics. The point is, would you rather write code that looks like
this:

	LibAErr_t a_err;
	LibBErr_t b_err;
	LibCErr_t c_err;
	ResourceA *res_a;
	ResourceB *res_b;
	ResourceC *res_c;

	res_a = acquireResourceA();
	if ((a_err = firstOperation(a, b, c)) != LIB_A_OK)
	{
		freeResourceA();
		goto error;
	}

	res_b = acquireResourceB():

	if ((b_err = secondOperation(x, y, z)) != LIB_B_OK)
	{
		freeResourceB();
		freeResourceA();
		goto error;
	}

	res_c = acquireResourceC();

	if ((c_err = thirdOperation(p, q, r)) != LIB_C_OK)
	{
		freeResourceB();
		freeResourceC(); // oops, subtle bug here
		freeResourceA();
		goto error;
	}
	...
	error:
		// deal with problems here

or this:

	try {
		auto res_a = acquireResourceA();
		scope(failure) freeResourceA();

		firstOperation(a, b, c);

		auto res_b = acquireResourceB();
		scope(failure) freeResourceB();

		secondOperation(x, y, z);

		auto res_c = acquireResourceC();
		scope(failure) freeResourceC();

		thirdOperation(p, q, r);

	} catch (Exception e) {
		// deal with problems here
	}



 What matter in composite operations is whether all of them succeeded
 or not.  Example: if the sequence of operations A-B-C failed while
 doing B, you are interested by the fact A-B-C has failed but not
 really that B failed specifically.


 
 Not necessarily true. You often want to report what went wrong, not
 just that "it didn't work".


Isn't that what Exception.msg is for?

Whereas if func1() calls 3 functions, which respectively returns errors
of types libAErr_t, libBErr_t, libCErr_t, what should func1() return if,
say, the 3rd operation failed? (Keep in mind that if we call functions
from 3 different libraries, they are almost guaranteed to return their
own error code enums which are never compatible with each other.) Should
it return libAErr_t, libBErr_t, or libCErr_t? Or should it do a switch
over possible error codes and translate them to a common type
libABCErr_t?


From my experience, what usually happens is that func1() will just


return a single failure code if *any* of the 3 functions failed -- it's
just too tedious and unmaintainable otherwise -- which means you *can't*
tell what went wrong, only that "it didn't work". My favorite whipping
boy is the "internal error". Almost every module in my work project has
their own error enum, and almost invariably the most common error
returned by any function is the one corresponding with "internal error".
Any time a function calls another module and it fails, "internal error"
is returned -- because people simply don't have the time/energy to
translate error codes from one module to another and return something
meaningful. So whenever there is a problem, all we know is that
"internal error" got returned by some function. As to where the actual
problem is, who knows? There are 500 places where "internal error" might
have originated from, but we can't tell which of them it might be
because almost *everything* returns "internal error".

Whereas with exceptions, .msg tells you exactly what the error message
was. And if the libraries have dedicated exception types, you can even
catch each type separately and deal with them accordingly, as opposed to
getting a libABCErr_t and then having to map that back to the original
error code type in order to understand what the problem was.

I find it hard to believe that you appear to be saying that you have
trouble pinpointing the source of the problem with exceptions, whereas
you find it easy to track down the problem with error codes. IME it's
completely the opposite.



 So you would have to translate error codes from one formalism to
 another. What happens next is that error codes become conflated in
 the same namespace and reused in other unrelated places. Hence,
 error codes from library leak into code that should be isolated from
 it.


 
 I don't see exceptions are any different in this way. I see internal
 exceptions bleed to much higher levels where they've totally lost
 context all the time.


Doesn't the stacktrace give you the context?



 Lastly, exceptions have a hierarchy and allow to distinguish between
 bugs and input errors by convention.

 Eg: Alan just wrote a function in a library that return an error
 code if it fails. The user program by Betty pass it a null pointer.
 This is a logic error as Alan disallowed it by contract. As Walter
 repeatedly said us, logic errors/bugs are not input errors and the
 only sane way to handle them is to crash.

 But since this function error interface is an error code, Alan
 return something like ERR_POINTER_IS_NULL_CONTRACT_VIOLATED since
 well, no other choice. Now the logic error code gets conflated with
 error codes corresponding to input errors (ERR_DISK_FAILED), and
 both will be handled similarly by Betty for sure, and the earth
 begin to crackle.


 
 I'm not sure quite what you're saying here, but I agree with Walter.
 In case of hard logic error, the sane thing to do is crash (ie,
 assert), not throw...

 I want my crash at the point of failure, not somewhere else.


[...]

Again, doesn't the exception stacktrace tell you exactly where the point
of failure is? Whereas an error code that has percolated up the call
stack 20 levels and underwent various mappings (har har, who does that)
or collapsed to generic, non-descript values ("internal error" -- much
more likely), is unlikely to tell you anything more than "it didn't
work". No information about which of the 500 functions 20 calls down the
call graph might have been responsible.


T

-- 
You are only young once, but you can stay immature indefinitely. -- azephrahel



 Feb 25 2015



prev sibling  parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Mon, 2015-02-23 at 19:50 +1000, Manu via Digitalmars-d wrote:

 O[…]
 This is going to sound really stupid... but do people actually use
 exceptions regularly?
 I've never used one. When I encounter code that does, I just find it
 really annoying to debug. I've never 'gotten' exceptions. I'm not sure
 why error codes are insufficient, other than the obvious fact that
 they hog the one sacred return value.
 D is just a whisker short of practical multiple-return-values. If we
 cracked that, we could use alternative (superior?) error state return
 mechanisms. I'd be really into that.


[…]

Return codes for value returning functions only work if the function
returns a pair, the return value and the error code: it is generally
impossible to work with return values that serve the purpose of return
value and error code. C got this fairly wrong, Go gets it fairly right.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Feb 23 2015



 next sibling parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Monday, 23 February 2015 at 12:30:55 UTC, Russel Winder wrote:

 value and error code. C got this fairly wrong, Go gets it 
 fairly right.


It's the one feature about Go that makes Go code look really 
ugly... So I guess this is a very subjective issue. Posix is 
actually pretty consistent by returning "-1", even as a pointer, 
but if you don't write pure Posix code it becomes confusing.



 Feb 23 2015



prev sibling next sibling parent  "Matthias Bentrup" <matthias.bentrup googlemail.com>  writes:


On Monday, 23 February 2015 at 12:30:55 UTC, Russel Winder wrote:

 On Mon, 2015-02-23 at 19:50 +1000, Manu via Digitalmars-d wrote:

 O[…]
 This is going to sound really stupid... but do people actually 
 use
 exceptions regularly?
 I've never used one. When I encounter code that does, I just 
 find it
 really annoying to debug. I've never 'gotten' exceptions. I'm 
 not sure
 why error codes are insufficient, other than the obvious fact 
 that
 they hog the one sacred return value.
 D is just a whisker short of practical multiple-return-values. 
 If we
 cracked that, we could use alternative (superior?) error state 
 return
 mechanisms. I'd be really into that.


 […]

 Return codes for value returning functions only work if the 
 function
 returns a pair, the return value and the error code: it is 
 generally
 impossible to work with return values that serve the purpose of 
 return
 value and error code. C got this fairly wrong, Go gets it 
 fairly right.


You wouldn't need new syntax (though I think multiple returns 
would be a nice addition), I think you can compile try/catch 
exception syntax into error codes internally.



 Feb 23 2015



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 2/23/15 4:30 AM, Russel Winder via Digitalmars-d wrote:

 On Mon, 2015-02-23 at 19:50 +1000, Manu via Digitalmars-d wrote:

 O[…]
 This is going to sound really stupid... but do people actually use
 exceptions regularly?
 I've never used one. When I encounter code that does, I just find it
 really annoying to debug. I've never 'gotten' exceptions. I'm not sure
 why error codes are insufficient, other than the obvious fact that
 they hog the one sacred return value.
 D is just a whisker short of practical multiple-return-values. If we
 cracked that, we could use alternative (superior?) error state return
 mechanisms. I'd be really into that.


 […]

 Return codes for value returning functions only work if the function
 returns a pair, the return value and the error code: it is generally
 impossible to work with return values that serve the purpose of return
 value and error code. C got this fairly wrong, Go gets it fairly right.


Urgh. Product types masquerading as sum types. Give me a break will ya. 
-- Andrei



 Feb 23 2015



 next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Mon, 2015-02-23 at 10:08 -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
[=E2=80=A6]

=20
 Urgh. Product types masquerading as sum types. Give me a break will ya.=


=20

 -- Andrei
=20


Uuurrr=E2=80=A6. no. As of today I program with the stuff and it works. Com=
ing
from Java and Python, I am an exceptions oriented person, but Go has
internal consistency on it's attitude to error reporting and you get
used to it. Actually, the obsession with error handling at the point of
occurrence does lead to getting systems that are less prone to
unexpected errors. This is pragmatism not theory. And being honest most
programmers would not know what product or sum types were. Nor would
they care. Even if perhaps they ought to.

When I worked with C, I abhorred the, to me, dreadful error codes
system. Go really does allow it to work without the same pain.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Feb 23 2015



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 2/23/15 10:50 AM, Russel Winder via Digitalmars-d wrote:

 On Mon, 2015-02-23 at 10:08 -0800, Andrei Alexandrescu via Digitalmars-d
 wrote:
 […]

 Urgh. Product types masquerading as sum types. Give me a break will ya.
 -- Andrei


 Uuurrr…. no. As of today I program with the stuff and it works. Coming
 from Java and Python, I am an exceptions oriented person, but Go has
 internal consistency on it's attitude to error reporting and you get
 used to it. Actually, the obsession with error handling at the point of
 occurrence does lead to getting systems that are less prone to
 unexpected errors. This is pragmatism not theory. And being honest most
 programmers would not know what product or sum types were. Nor would
 they care. Even if perhaps they ought to.

 When I worked with C, I abhorred the, to me, dreadful error codes
 system. Go really does allow it to work without the same pain.


This is a misunderstanding. I was referring to Go's confusion of sum 
types with product types. -- Andrei



 Feb 23 2015



prev sibling  parent  "Tobias Pankrath" <tobias pankrath.net>  writes:


 Urgh. Product types masquerading as sum types. Give me a break 
 will ya. -- Andrei


1. The product solution is more pleasant to work with, if you 
have no sugar for sum types like pattern matching.

2. It's the same as with exception specifications: Product types 
make ignoring the error path easier thus are more popular.



 Feb 23 2015



prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org>  writes:


On Monday, 23 February 2015 at 05:54:06 UTC, Manu wrote:

 On 23 February 2015 at 14:11, Andrei Alexandrescu via 
 Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 2/22/15 5:57 PM, Manu via Digitalmars-d wrote:

 I can easily visualise a way forward with RC.



 Then do it. Frankly it seems to me you're doing anything you 
 possibly can to
 talk yourself out of doing work.


 Excellent technique to immediately invalidate everything 
 someone says.
 Thanks for that.
 You dismissed absolutely everything I said, and then imply that 
 I have
 no right to comment unless I do it myself.
 It's got nothing to do with doing work. ARC (or something like 
 it) is
 almost religiously opposed. We can't even have a reasonable
 conversation about it, or really explore it's implications 
 before
 someone (that ideally know's what they're doing) thinks about 
 writing
 code. There's no room for progress in this environment.

 What do you want me to do? I use manual RC throughout my code, 
 but the
 experience in D today is identical to C++. I can confirm that 
 it's
 equally terrible to any C++ implementation I've used. We have 
 no tools
 to improve on it.
 And whatever, if it's the same as C++, I can live with it. I've 
 had
 that my whole career (although it's sad, because we could do 
 much
 better).
 The problem, as always, is implicit allocations, and 
 allocations from
 3rd party libraries. While the default allocator remains 
 incompatible
 with workloads I care about, that isolates us from virtually 
 every
 library that's not explicitly written to care about my use 
 cases.
 That's the situation in C++ forever. We're familiar with it, 
 and it's
 shit. I have long hoped we would move beyond that situation in D

 back),
 but it's a massive up-hill battle to even gain mindshare, 
 regardless
 of actual implementation. There's no shared vision on this 
 matter, the
 word is basically "GC is great, everyone loves it, use an RC 
 lib".

 How long do we wait for someone to invent a fantastical GC that 
 solves
 our problems and works in D? I think it's practically agreed 
 that no
 known design can work, but nobody wants to bite the bullet and 
 accept
 the fact.
 We need to admit we have an impassable problem, and then maybe 
 we can
 consider alternatives openly. Obviously, it would be 
 disruptive, but
 it might actually work... which is better than where we seem to 
 be
 heading (with a velocity of zero).

 The fact is, people who are capable of approaching this problem 
 in
 terms of actual code will never even attempt it until there's
 resounding consensus that it's worth exploring.


Personally I think what matters is getting D's situation 
regarding memory management sorted out, regardless out it will 
look like in the end.

If I am a bit too quick jumping the gun about GC, is that I have 
embraced GC languages in my line of work, so I tend to be aware 
that not all GCs are made alike and some like the ones from e.g. 
Aonix are good enough for real time situations, the ones someone 
dies if the GC runs on the wrong moment.

Maybe such GC quality is impossible to achieve in D, I don't know.

What I can say is that I cannot use D on my type of work and 
keeping up with everything that happens on the JVM, .NET and 
mobile space already keeps me busy enough.



 Feb 22 2015



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Monday, 23 February 2015 at 07:19:56 UTC, Paulo Pinto wrote:

 Personally I think what matters is getting D's situation 
 regarding memory management sorted out, regardless out it will 
 look like in the end.


This is exactly right, either

1.  The compiler takes care of allocation/deallocations and makes 
refcounting part of the language implementation (but not 
necessarily the semantics).

or

2. If allocation/deallocation is not the compiler's 
responsibility then RC should be a library solution based on 
efficient generally useful counter-semantics build blocks.

A compiler solution for RC and manual allocations is a 
firefighter solution where all similar use cases suffers. I.e. 
when you want something similar to, but not exactly like what the 
compiler provides...


 If I am a bit too quick jumping the gun about GC, is that I 
 have embraced GC languages in my line of work, so I tend to be 
 aware that not all GCs are made alike and some like the ones 
 from e.g. Aonix are good enough for real time situations, the 
 ones someone dies if the GC runs on the wrong moment.

 Maybe such GC quality is impossible to achieve in D, I don't 
 know.


Well, hard real time does not mean fast, it means "bounded 
execution time". GC will is not suitable for a lot of reasons 
when you want to get the most out of the hardware (just memory 
requirements on diskless systems is sufficient to disqualify GC). 
When people use the term "real time" on the forums, they usually 
just mean hardware-efficient and low latency.



 Feb 23 2015



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 2/22/15 9:53 PM, Manu via Digitalmars-d wrote:

 On 23 February 2015 at 14:11, Andrei Alexandrescu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 2/22/15 5:57 PM, Manu via Digitalmars-d wrote:

 I can easily visualise a way forward with RC.



 Then do it. Frankly it seems to me you're doing anything you possibly can to
 talk yourself out of doing work.


 Excellent technique to immediately invalidate everything someone says.
 Thanks for that.


It's not immediate - it's a pattern our dialog has followed for years. 
Essentially I haven't yet managed to communicate with you.


 You dismissed absolutely everything I said, and then imply that I have
 no right to comment unless I do it myself.
 It's got nothing to do with doing work. ARC (or something like it) is
 almost religiously opposed. We can't even have a reasonable
 conversation about it, or really explore it's implications before
 someone (that ideally know's what they're doing) thinks about writing
 code. There's no room for progress in this environment.


I think RC is an important tool on our panoply. More so than Walter. But 
I have to say you'd do good to understand his arguments better; it 
doesn't seem you do.


 What do you want me to do? I use manual RC throughout my code, but the
 experience in D today is identical to C++. I can confirm that it's
 equally terrible to any C++ implementation I've used. We have no tools
 to improve on it.


Surely you have long by now written something similar to std::shared_ptr 
by now. Please paste it somewhere and post a link to it, thanks. That 
would be a fantastic discussion starter.


 And whatever, if it's the same as C++, I can live with it. I've had
 that my whole career (although it's sad, because we could do much
 better).
 The problem, as always, is implicit allocations, and allocations from
 3rd party libraries. While the default allocator remains incompatible
 with workloads I care about, that isolates us from virtually every
 library that's not explicitly written to care about my use cases.
 That's the situation in C++ forever. We're familiar with it, and it's
 shit. I have long hoped we would move beyond that situation in D

 but it's a massive up-hill battle to even gain mindshare, regardless
 of actual implementation. There's no shared vision on this matter, the
 word is basically "GC is great, everyone loves it, use an RC lib".


It doesn't seem that way to me at all. Improving resource management is 
right there on the vision page for H1 2015. Right now people are busy 
fixing regressions for 2.067 (aiming for March 1; probably we won't make 
that deadline). In that context, posturing and stomping the ground that 
others work for you right now is in even more of a stark contrast.


 How long do we wait for someone to invent a fantastical GC that solves
 our problems and works in D?


This elucubration belongs only to you. Nobody's waiting on that. Pleas 
read http://wiki.dlang.org/Vision/2015H1 again.


 I think it's practically agreed that no
 known design can work, but nobody wants to bite the bullet and accept
 the fact.


I don't understand where this perception is coming from.


 We need to admit we have an impassable problem, and then maybe we can
 consider alternatives openly. Obviously, it would be disruptive, but
 it might actually work... which is better than where we seem to be
 heading (with a velocity of zero).


Please forgive people who are working on getting 2.067 out for not 
making things you need their top priority right now.


 The fact is, people who are capable of approaching this problem in
 terms of actual code will never even attempt it until there's
 resounding consensus that it's worth exploring.


Could you please let me know how we can rephrase this paragraph on 
http://wiki.dlang.org/Vision/2015H1:

=============
Memory Management

We aim to improve D's handling of memory. That includes improving the 
garbage collector itself and also making D eminently usable with limited 
or no use of tracing garbage collection. We aim to make the standard 
library usable in its entirety without a garbage collector. Safe code 
should not require the presence of a garbage collector.
=============

Could you please let me know exactly what parts you don't understand or 
agree with so we can change them. Thanks.


Andrei



 Feb 23 2015



  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 24 February 2015 at 04:04, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 I think RC is an important tool on our panoply. More so than Walter. But I
 have to say you'd do good to understand his arguments better; it doesn't
 seem you do.


The only argument I can't/haven't addressed is the exception argument,
which I have granted to Walter on authority. I think the other issues
he's presented (at various times over the years, so I'm not sure what
is the current state) can probably be addressed by the language. Scope
seems like it could win us a lot of the problem cases alone, but we'd
need to experiment with it for a year or so before we'll know.

It does annoy me that I can't comment on the exceptions case, but the
fact is I've never typed 'throw' before, and never scrutinised the
codegen.
I have meant to take some time to familiarise myself with whatever
appears out the other end of the compiler for a long time, but all
compilers seem to be different, architectures are probably different
too, and I just haven't found the time for something that has no use
to me other than to argue this assertion with some authority.
Walter has said I should "just compile some code and look at it",
which probably sounds fine if you have any idea what you're looking
for, or an understanding of the differences between compilers. I
don't, it's a fairly deep and involved process to give myself
comprehensive knowledge of exceptions, and it has no value to me
outside this argument.

That said, I'd still be surprised if it was a terminal argument
though. Is it really a hard impasse? Or is it just a big/awkward
burden on the exceptional path? Surely the performance of the unwind
path is irrelevant? Does it bleed into the normal execution path?

My whole point is; where we seem to have no options for meaningful
progress in GC land as evidenced by years of stagnation, I figure it's
the only practical direction we have.
I recognise there is some GC action recently, but I haven't seen any
activity that changes the fundamental problems?



 What do you want me to do? I use manual RC throughout my code, but the
 experience in D today is identical to C++. I can confirm that it's
 equally terrible to any C++ implementation I've used. We have no tools
 to improve on it.



 Surely you have long by now written something similar to std::shared_ptr by
 now. Please paste it somewhere and post a link to it, thanks. That would be
 a fantastic discussion starter.


Not really. I don't really use C++; we generally switched from C++
back to C about 8 years ago.
Here's something public of the type I am more familiar with:
https://github.com/TurkeyMan/fuji/blob/master/dist/include/d2/fuji/resource.d
It's not an excellent example; it's quick and dirty, hasn't received
much more attention than getting it working, but I think it's fairly
representative of a typical pattern, especially when interacting with
C code.
I'm not aware of any reasonable strategy I could use to eliminate the
ref fiddling. 'scope' overloads would have solved the problem nicely.

COM is also an excellent candidate for consideration. If COM works
well, then I imagine anything should work.
Microsoft's latest C++ presents a model for this that I'm generally
happy with; distinct RC pointer type. We could do better by having
implicit cast to scope(T*) (aka, borrowing) which C++ can't express;
scope(T*) would be to T^ and T* like const(T*) is to T* and
immutable(T*).



 And whatever, if it's the same as C++, I can live with it. I've had
 that my whole career (although it's sad, because we could do much
 better).
 The problem, as always, is implicit allocations, and allocations from
 3rd party libraries. While the default allocator remains incompatible
 with workloads I care about, that isolates us from virtually every
 library that's not explicitly written to care about my use cases.
 That's the situation in C++ forever. We're familiar with it, and it's
 shit. I have long hoped we would move beyond that situation in D

 but it's a massive up-hill battle to even gain mindshare, regardless
 of actual implementation. There's no shared vision on this matter, the
 word is basically "GC is great, everyone loves it, use an RC lib".



 It doesn't seem that way to me at all. Improving resource management is
 right there on the vision page for H1 2015. Right now people are busy fixing
 regressions for 2.067 (aiming for March 1; probably we won't make that
 deadline). In that context, posturing and stomping the ground that others
 work for you right now is in even more of a stark contrast.


I haven't said that. Review my first post, I never made any claims
about what should/shouldn't be done, or make any demands of any sort.
I just don't have any faith that GC can get us where we want to be. I
was cautiously optimistic for some years, but I lost faith.
I'm also critical (disappointed even) of the treatment of scope. I
hope I'm wrong, like I hoped I was wrong about GC...

There have been lots of people come in here and say "I won't use D
because GC", and I've been defensive against those claims, despite
being as high risk of similar tendencies myself. I don't think you can
say I didn't give GC a fair chance to prove me wrong.



 How long do we wait for someone to invent a fantastical GC that solves
 our problems and works in D?



 This elucubration belongs only to you. Nobody's waiting on that. Pleas read
 http://wiki.dlang.org/Vision/2015H1 again.


This is a bit of a red herring, the roadmap has no mention of ARC, or
practical substitution for the GC. This discussion was originally
about ARC over the GC, specifically.

I firmly understand the push for  nogc. I have applauded that effort many times.
I have said in the past though that I'm not actually a strong
supporter of  nogc, and spoke critically of it initially. I'm still
not really thrilled, but I do agree it's a necessary building block
and I'm very happy it's a key focus, but I'm ultimately concerned it
will lead to a place where separation of users into 2 camps (my
primary ongoing criticism) is firmly established, and it will be
justified by the effort expended to achieve that end.
Again, don't get me wrong, I agree we need this, because at this point
I see no other satisfactory outcome, but I'm disappointed that we
failed to achieve something more ambitious in terms of memory
management (garbage collection in whatever form; gc or rc) and  nogc
users will lose a subset of the language.

I'm familiar with the world where some/most libraries aren't available
to me, because people tend to use the most convenient memory
management strategy by default, and that is incompatible with my
environment.
That is the world we will have in D. It's 'satisfactory', ie, it's
workable for me and my people, but it's not ideal; it's a lost
opportunity, and it's disappointing. Perhaps I've just been
unrealistically hopeful for too long?

Perhaps it will fall to the allocator API to save us from this
situation I envision, but I don't have a picture for that in my head.
It feels like it will probably be awkward and complicated to me
however I try and imagine the end product. The likely result of that
will be people not using it (just sticking with default GC allocation)
unless they are compelled by a high level of experience, or by their
intended user base, again suggesting a separation into 2 worlds.

I hope I'm completely wrong. Really!



 The fact is, people who are capable of approaching this problem in
 terms of actual code will never even attempt it until there's
 resounding consensus that it's worth exploring.



 Could you please let me know how we can rephrase this paragraph on
 http://wiki.dlang.org/Vision/2015H1:

 =============
 Memory Management

 We aim to improve D's handling of memory. That includes improving the
 garbage collector itself and also making D eminently usable with limited or
 no use of tracing garbage collection. We aim to make the standard library
 usable in its entirety without a garbage collector. Safe code should not
 require the presence of a garbage collector.
 =============

 Could you please let me know exactly what parts you don't understand or
 agree with so we can change them. Thanks.


I understand what it says, and I generally agree with it.
I agree that  nogc will give us a C-like foundation to work outwards
from, and that is a much better place than where we are today, so I
have come to support the direction.

I wouldn't complain if efficient RC was on the roadmap, but I agree
it's outside the scope for the immediate future.

If it were to be said that I 'disagree' with some part of it, which
isn't true, it would be that it risks leading to an end that I'm not
sure is in our best interest; we will arrive at C vs C++.
As I said above, and many many times in the past, I see the  nogc
effort leading to a place where libraries are firmly divided between 2
worlds. My criticisms of that kind have never been directly addressed.

My suspicion is that this is mainly motivated by the fact it is the
simplest and lowest-level path, it will give the best low-level
building-blocks, and I think that's probably a good thing. But I can
also imagine more ambitious paths, like replacing the GC with
ambitious ARC implementation as the OP raised (if it's workable, I'm
not convinced either way), which would require massive R&D and almost
certainly lead to some radical changes. I think resistance is
predicated mainly on a rejection of such radical changes, and that's
fair enough, but is that rejection of radical change worth dividing D
into 2 worlds like C/C++? I don't know of any discussion on this value
tradeoff... not to mention, the significant loss of language features
to the  nogc camp.

I'm not asking for any changes. I just gave an opinion to the OP. I
can see there is RC work going on now, that's good. I expect (well, am
hopeful) it will eventually lead to some form of ARC. We'll see.


Re-reading my first 8 posts, I still feel they are perfectly
reasonable. I'm not sure where exactly it is that I started 'a thing',
but my feeling is it was only when you gave a long and somewhat
aggressive reply, and then made a cheap attack on my character, that I
tend to reply in kind.
I also feel like I'm forced to reply, to every point, otherwise I
proliferate this caricature you're prescribing to me (where I
disappear when it gets 'hard', or rather, more time consuming than I
have time for). Which is often true; it does become more time
consuming than I have time for... does that mean I'm not entitled to
input on this forum?
I'll return to my hole now.



 Feb 25 2015



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 2/25/2015 7:12 AM, Manu via Digitalmars-d wrote:

 It does annoy me that I can't comment on the exceptions case,


That problem is easily correctable. But if you aren't interested in doing the 
homework, you're stuck with accepting what I say about it :-)



 That said, I'd still be surprised if it was a terminal argument
 though. Is it really a hard impasse? Or is it just a big/awkward
 burden on the exceptional path? Surely the performance of the unwind
 path is irrelevant? Does it bleed into the normal execution path?


I've answered these questions to you already. I've also quoted the ObjectiveC 
compiler document saying the same thing. At some point you're going to either 
have to spend some time investigating it yourself or cede the point.



 I recognise there is some GC action recently, but I haven't seen any
 activity that changes the fundamental problems?


DIP25.



 COM is also an excellent candidate for consideration. If COM works
 well, then I imagine anything should work.
 Microsoft's latest C++ presents a model for this that I'm generally
 happy with; distinct RC pointer type. We could do better by having
 implicit cast to scope(T*) (aka, borrowing) which C++ can't express;
 scope(T*) would be to T^ and T* like const(T*) is to T* and
 immutable(T*).


Microsoft's Managed C++ had two pointer types, and it went over like a lead 
zeppelin.



 There have been lots of people come in here and say "I won't use D
 because GC",


None of those people will be satisfied with improvements to the GC.



 This is a bit of a red herring, the roadmap has no mention of ARC, or
 practical substitution for the GC. This discussion was originally
 about ARC over the GC, specifically.


See the refcounted array thread.



 I hope I'm completely wrong. Really!


I suspect you are hoping for a magic switch:

    dmd foo.d -arc

and voila! Everything will be reference counted rather than GC'd.

This is never going to happen with D. I don't see a path to it that does not 
involve crippling problems and compromises.

However, D will become usable with minimal or no use of the GC, by using 
components that are allocation agnostic, and selection of types that are RC'd.
I 
suspect most programs will wind up using combinations of GC and RC.



 I wouldn't complain if efficient RC was on the roadmap, but I agree
 it's outside the scope for the immediate future.


Refcounted array thread.



 As I said above, and many many times in the past, I see the  nogc
 effort leading to a place where libraries are firmly divided between 2
 worlds. My criticisms of that kind have never been directly addressed.


I don't buy that. The canonical example is std.algorithm, which is highly
useful 
components that are allocation strategy agnostic. I have since added 
splitterLines() which replaces the old GC splitLines() function with a
component 
that is agnostic. This is an example of the way forward.



 Feb 25 2015



 next sibling parent reply "weaselcat" <weaselcat gmail.com>  writes:


On Thursday, 26 February 2015 at 00:54:57 UTC, Walter Bright 
wrote:

 COM is also an excellent candidate for consideration. If COM 
 works
 well, then I imagine anything should work.
 Microsoft's latest C++ presents a model for this that I'm 
 generally
 happy with; distinct RC pointer type. We could do better by 
 having
 implicit cast to scope(T*) (aka, borrowing) which C++ can't 
 express;
 scope(T*) would be to T^ and T* like const(T*) is to T* and
 immutable(T*).


 Microsoft's Managed C++ had two pointer types, and it went over 
 like a lead zeppelin.


Rust currently has four or five pointer types(depending on how 
you define pointer) and it seems to be quite popular.



 Feb 25 2015



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 2/25/2015 5:19 PM, weaselcat wrote:

 Rust currently has four or five pointer types(depending on how you define
 pointer) and it seems to be quite popular.


We'll see. I've already seen some complaints about that aspect.



 Feb 25 2015



prev sibling  parent reply "Paulo  Pinto" <pjmlp progtools.org>  writes:


On Thursday, 26 February 2015 at 00:54:57 UTC, Walter Bright 
wrote:

 On 2/25/2015 7:12 AM, Manu via Digitalmars-d wrote:

 It does annoy me that I can't comment on the exceptions case,


 ...


 COM is also an excellent candidate for consideration. If COM 
 works
 well, then I imagine anything should work.
 Microsoft's latest C++ presents a model for this that I'm 
 generally
 happy with; distinct RC pointer type. We could do better by 
 having
 implicit cast to scope(T*) (aka, borrowing) which C++ can't 
 express;
 scope(T*) would be to T^ and T* like const(T*) is to T* and
 immutable(T*).


 Microsoft's Managed C++ had two pointer types, and it went over 
 like a lead zeppelin.


This is not true for those of us working on Windows.

It just got replaced by C++/CLI, which was an improved version 
based on feedback about Managed C++.

The main difference was the removal of double underscore prefixes 
and making the keywords semantic. The multiple pointer types are 
still there.

https://msdn.microsoft.com/en-us/library/ms379603%28v=vs.80%29.aspx

Maybe it failed the goal of having C++ developers fully embrace 
.NET, but it achieved its goal of providing an easier way to 
integrate existing C++ code into .NET applications, instead of 
the P/Invoke dance.

The same syntax extensions that became the foundation of the 
second coming of COM, aka WinRT and is at the kernel of Windows 8.

Specially because this,

"Creating Windows Runtime Components in C++"
https://msdn.microsoft.com/library/windows/apps/hh441569/

is way simpler than this

"Creating a Basic Windows Runtime Component Using Windows Runtime 
Library"
https://msdn.microsoft.com/en-us/library/jj155856%28v=vs.110%29.aspx

It might happen that with C++14 and Windows 10, C++/CLI and 
C++/CX will become irrelevant, but until then, they have been 
useful integrating C++ code into .NET and Store applications.

--
Paulo



 Feb 25 2015



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 2/25/2015 11:50 PM, Paulo Pinto wrote:

 Maybe it failed the goal of having C++ developers fully embrace .NET, but it
 achieved its goal of providing an easier way to integrate existing C++ code
into
 .NET applications, instead of the P/Invoke dance.


I wasn't referring to technical success. There is no doubt that multiple
pointer 
types technically works. I was referring to acceptance by the community.

Back in the old DOS days, there were multiple pointer types (near and far). 
Programmers put up with that because it was the only way, but they HATED HATED 
HATED it.



 Feb 26 2015



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 2/22/2015 8:36 AM, Manu via Digitalmars-d wrote:

 I have no idea where to start.


Start by making a ref counted type and see what the pain points are.



 Feb 22 2015



  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 23 February 2015 at 07:47, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 2/22/2015 8:36 AM, Manu via Digitalmars-d wrote:

 I have no idea where to start.



 Start by making a ref counted type and see what the pain points are.


All my ref counting types fiddle with the ref in every assignment, or
every function call and return. Unless the language has some sort of
support for ref counting, I don't know how we can do anything about
that.



 Feb 22 2015



 next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Monday, 23 February 2015 at 01:38:35 UTC, Manu wrote:

 All my ref counting types fiddle with the ref in every 
 assignment, or every function call and return.


Hmm, the optimizer could potentially tell "inc X; dec X;" is 
useless and remove it without knowing what it is for.



 Feb 22 2015



 next sibling parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 23 February 2015 at 11:41, Adam D. Ruppe via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, 23 February 2015 at 01:38:35 UTC, Manu wrote:

 All my ref counting types fiddle with the ref in every assignment, or
 every function call and return.



 Hmm, the optimizer could potentially tell "inc X; dec X;" is useless and
 remove it without knowing what it is for.


Yeah, except we're talking about libraries, and in that context I often have:
extern(C) IncRef(T*);
extern(C) DecRef(T*);

Optimiser can't offer anything.



 Feb 22 2015



prev sibling next sibling parent  "deadalnix" <deadalnix gmail.com>  writes:


On Monday, 23 February 2015 at 01:41:17 UTC, Adam D. Ruppe wrote:

 On Monday, 23 February 2015 at 01:38:35 UTC, Manu wrote:

 All my ref counting types fiddle with the ref in every 
 assignment, or every function call and return.


 Hmm, the optimizer could potentially tell "inc X; dec X;" is 
 useless and remove it without knowing what it is for.


It is not that easy. First you need to increment/decrement in an 
atomic manner (unless we finally decide to fix holes in the type 
system) so the optimizer is mostly blind.

But even if it could (we are not far from being able to do it), 
in most scenarios it is still an issue as you get potential 
exception unwinding. The unwind path must find the right 
reference count in there.



 Feb 22 2015



prev sibling  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Monday, 23 February 2015 at 01:41:17 UTC, Adam D. Ruppe wrote:

 On Monday, 23 February 2015 at 01:38:35 UTC, Manu wrote:

 All my ref counting types fiddle with the ref in every 
 assignment, or every function call and return.


 Hmm, the optimizer could potentially tell "inc X; dec X;" is 
 useless and remove it without knowing what it is for.


INPUT:

try{
nonsharedobj._rc++;
…
}
finally {
nonsharedobj._rc--;
if(nonsharedobj._rc==0) destroy…
}

OPTIMIZED:

try{
…
}
finally {
if(nonsharedobj._rc==0) destroy…
}

----
Thanks to the messed up modular arithmetics that D has chosen you 
cannot assume the a non-shared live object does not have a rc==0 
due to wrapping integers, in the general case.



 Feb 23 2015



  parent reply "Tobias Pankrath" <tobias pankrath.net>  writes:


On Monday, 23 February 2015 at 08:27:52 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 23 February 2015 at 01:41:17 UTC, Adam D. Ruppe 
 wrote:

 On Monday, 23 February 2015 at 01:38:35 UTC, Manu wrote:

 All my ref counting types fiddle with the ref in every 
 assignment, or every function call and return.


 Hmm, the optimizer could potentially tell "inc X; dec X;" is 
 useless and remove it without knowing what it is for.


 INPUT:

 try{
 nonsharedobj._rc++;
 …
 }
 finally {
 nonsharedobj._rc--;
 if(nonsharedobj._rc==0) destroy…
 }

 OPTIMIZED:

 try{
 …
 }
 finally {
 if(nonsharedobj._rc==0) destroy…
 }

 ----
 Thanks to the messed up modular arithmetics that D has chosen 
 you cannot assume the a non-shared live object does not have a 
 rc==0 due to wrapping integers, in the general case.


You mean when there are more than 2^64 references to the object?



 Feb 23 2015



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 2/23/2015 12:33 AM, Tobias Pankrath wrote:

 On Monday, 23 February 2015 at 08:27:52 UTC, Ola Fosheim Grøstad wrote:

 Thanks to the messed up modular arithmetics that D has chosen you cannot
 assume the a non-shared live object does not have a rc==0 due to wrapping
 integers, in the general case.


 You mean when there are more than 2^64 references to the object?


Yeah, it'll wrap when there are more references than can even theoretically fit 
in the address space.

I'm not worried about it :-)



 Feb 23 2015



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Monday, 23 February 2015 at 08:50:28 UTC, Walter Bright wrote:

 On 2/23/2015 12:33 AM, Tobias Pankrath wrote:

 On Monday, 23 February 2015 at 08:27:52 UTC, Ola Fosheim 
 Grøstad wrote:

 Thanks to the messed up modular arithmetics that D has chosen 
 you cannot
 assume the a non-shared live object does not have a rc==0 due 
 to wrapping
 integers, in the general case.


 You mean when there are more than 2^64 references to the 
 object?


 Yeah, it'll wrap when there are more references than can even 
 theoretically fit in the address space.

 I'm not worried about it :-)


You don't worry about a lot of things that you ought to worry 
about :-P



 Feb 23 2015



prev sibling  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Monday, 23 February 2015 at 08:33:59 UTC, Tobias Pankrath 
wrote:

 You mean when there are more than 2^64 references to the object?


I mean that the optimizer does not know what _rc is. The 
optimizer can only elide what it can prove, by sound logic, not 
by assumptions.



 Feb 23 2015



  parent reply "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Ola Fosheim Grøstad" " wrote in message 
news:hwwotfmkjvwsempqibla forum.dlang.org...


 I mean that the optimizer does not know what _rc is. The optimizer can 
 only elide what it can prove, by sound logic, not by assumptions.


The whole point of compiler-supported RC is that the optimizer can make 
assumptions. 



 Feb 23 2015



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Monday, 23 February 2015 at 09:01:23 UTC, Daniel Murphy wrote:

 "Ola Fosheim Grøstad" " wrote in message 
 news:hwwotfmkjvwsempqibla forum.dlang.org...


 I mean that the optimizer does not know what _rc is. The 
 optimizer can only elide what it can prove, by sound logic, 
 not by assumptions.


 The whole point of compiler-supported RC is that the optimizer 
 can make assumptions.


Yes, but then it makes no sense to tell Manu that he should use a 
library RC...

It is nice to see at least one person admit that D needs to 
depart from modular arithmetic to solve real world problems... 
Because that is the implication of your statement. ;)



 Feb 23 2015



prev sibling  parent reply "Jakob Ovrum" <jakobovrum gmail.com>  writes:


On Monday, 23 February 2015 at 01:38:35 UTC, Manu wrote:

 On 23 February 2015 at 07:47, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 2/22/2015 8:36 AM, Manu via Digitalmars-d wrote:

 I have no idea where to start.



 Start by making a ref counted type and see what the pain 
 points are.


 All my ref counting types fiddle with the ref in every 
 assignment, or
 every function call and return. Unless the language has some 
 sort of
 support for ref counting, I don't know how we can do anything 
 about
 that.


There's no move constructor in D, so how did you manage that?



 Feb 23 2015



  parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 23 February 2015 at 20:24, Jakob Ovrum via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, 23 February 2015 at 01:38:35 UTC, Manu wrote:

 On 23 February 2015 at 07:47, Walter Bright via Digitalmars-d

 <digitalmars-d puremagic.com> wrote:

 On 2/22/2015 8:36 AM, Manu via Digitalmars-d wrote:

 I have no idea where to start.




 Start by making a ref counted type and see what the pain points are.



 All my ref counting types fiddle with the ref in every assignment, or
 every function call and return. Unless the language has some sort of
 support for ref counting, I don't know how we can do anything about
 that.



 There's no move constructor in D, so how did you manage that?


I wrote it above.

struct Thing
{
  T *instance;

  this(this) { Inc(instance); }
  ~this() { Dec(instance); }

  // this would really assist RC when 'scope' is inferred liberally.
  this(this) scope {}
  ~this() scope {}
}

In this case, rc is part of the instance; no reason to separate it
when RC is not a generalised concept. Of course the structure can be
generalised and fiddled/meta-ed to suit purpose in any number of ways.
Inc's and Dec's galore!

I'm not sure what a move constructor would give me over this.



 Feb 23 2015



prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Sunday, 22 February 2015 at 00:43:47 UTC, Manu wrote:

 I personally think ARC in D is the only way forwards. That is an
 unpopular opinion however... although I think I'm just being 
 realistic
 ;)


I've considered adding support for it in SDC in the future, but 
man, reading the ARC spec fells like a dive into insanity. I've 
rarely seen such an overcomplicated system.



 Feb 21 2015



  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 22 February 2015 at 14:25, deadalnix via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Sunday, 22 February 2015 at 00:43:47 UTC, Manu wrote:

 I personally think ARC in D is the only way forwards. That is an
 unpopular opinion however... although I think I'm just being realistic
 ;)



 I've considered adding support for it in SDC in the future, but man, reading
 the ARC spec fells like a dive into insanity. I've rarely seen such an
 overcomplicated system.


But it IS a way forwards... can you suggest another way forwards using
a sufficiently fancy GC? While there are no visible alternatives (as
has been the case for as long as I've been here), I don't think
complexity can be considered a road block. Would a theoretical
advanced GC be any less complex?

What are the complexities? Can we design to address them elegantly?



 Feb 22 2015



  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Sunday, 22 February 2015 at 16:37:15 UTC, Manu wrote:

 But it IS a way forwards... can you suggest another way 
 forwards using
 a sufficiently fancy GC? While there are no visible 
 alternatives (as
 has been the case for as long as I've been here), I don't think
 complexity can be considered a road block. Would a theoretical
 advanced GC be any less complex?

 What are the complexities? Can we design to address them 
 elegantly?


It is overcomplex to accommodate the historical elements of ObjC.



 Feb 22 2015



prev sibling next sibling parent  "Paulo Pinto" <pjmlp progtools.org>  writes:


On Sunday, 22 February 2015 at 00:43:47 UTC, Manu wrote:

 On 22 February 2015 at 05:20, JN via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 https://developer.apple.com/news/?id=02202015a

 Interesting...

 Apple is dropping GC in favor of automatic reference counting. 
 What are the
 benefits of ARC over GC? Is it just about predictability of 
 resource
 freeing? Would ARC make sense in D?


 D's GC is terrible, and after 6 years hanging out in this 
 place, I
 have seen precisely zero development on the GC front. Nobody 
 can even
 imagine, let alone successfully implement a GC that covers 
 realtime
 use requirements.


I lack the skills to be hired by Aonix, but the military seem to 
think it is ok to put a real time JVM taking care of missile 
systems.

http://www.spacewar.com/reports/Lockheed_Martin_Selects_Aonix_PERC_Virtual_Machine_For_Aegis_Weapon_System_999.html

They surely have considered the situation "GC was called => where 
did the missile go".

It doesn't get more real time than that.



 Feb 21 2015



prev sibling next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com>  writes:


On Sunday, 22 February 2015 at 00:43:47 UTC, Manu wrote:

 D's GC is terrible, and after 6 years hanging out in this 
 place, I
 have seen precisely zero development on the GC front.


You must have missed RTInfo, Rainer's precise heap scanner and 
Sociomantic's concurrent GC.



 Feb 22 2015



  parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 22 February 2015 at 21:31, Jakob Ovrum via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Sunday, 22 February 2015 at 00:43:47 UTC, Manu wrote:

 D's GC is terrible, and after 6 years hanging out in this place, I
 have seen precisely zero development on the GC front.



 You must have missed RTInfo, Rainer's precise heap scanner and Sociomantic's
 concurrent GC.


Rasiner's GC was even slower (at the time it was presented), but it
offers the advantage that it doesn't leak like a seive. FWIW, I am in
favour of migrating to rainer's GC, but it doesn't really address any
problems.
Sociomantic's GC takes advantage of a particular OS, it's not portable.



 Feb 22 2015



prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com>  writes:


On Sunday, 22 February 2015 at 00:43:47 UTC, Manu wrote:

 On 22 February 2015 at 05:20, JN via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 https://developer.apple.com/news/?id=02202015a

 Interesting...

 Apple is dropping GC in favor of automatic reference counting. 
 What are the
 benefits of ARC over GC? Is it just about predictability of 
 resource
 freeing? Would ARC make sense in D?


 D's GC is terrible, and after 6 years hanging out in this 
 place, I
 have seen precisely zero development on the GC front.


There has been a flood of GC improvements in druntime from Martin 
Nowak and Rainer Schuetze over the last few months. Probably 
nothing that would satisfy your requirements, but it looks like 
some sizeable speedups nonetheless.



 Feb 22 2015



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 2/22/15 3:39 AM, John Colvin wrote:

 On Sunday, 22 February 2015 at 00:43:47 UTC, Manu wrote:

 On 22 February 2015 at 05:20, JN via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 https://developer.apple.com/news/?id=02202015a

 Interesting...

 Apple is dropping GC in favor of automatic reference counting. What
 are the
 benefits of ARC over GC? Is it just about predictability of resource
 freeing? Would ARC make sense in D?


 D's GC is terrible, and after 6 years hanging out in this place, I
 have seen precisely zero development on the GC front.


 There has been a flood of GC improvements in druntime from Martin Nowak
 and Rainer Schuetze over the last few months. Probably nothing that
 would satisfy your requirements, but it looks like some sizeable
 speedups nonetheless.


Martin, Rainer - it would be great if you could make public some 
measurements. -- Andrei



 Feb 22 2015



prev sibling  parent  Martin Nowak <code+news.digitalmars dawg.eu>  writes:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/22/2015 01:43 AM, Manu via Digitalmars-d wrote:

 D's GC is terrible, and after 6 years hanging out in this place, I 
 have seen precisely zero development on the GC front. Nobody can
 even imagine, let alone successfully implement a GC that covers
 realtime use requirements.


We have achieved quite some speedup on the GC front (up to 50% faster
allocations) and we work on a few more improvements for the next
release (good for at least another 20% speedup).

There is even a useful idea how to implement an incremental GC.

I might give a talk about the current state at DConf.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJU8N0MAAoJELJzgRYSuxk5/4IP/AzBOzt3jc77vwovtV+J9C5E
D6jE/y1pCkmlQ9Wjb7yl5F0Ul0bQiDXhGH55rkzYO/AHrCZLGZ2TSr+CchCeDR64
7dVmDCLxDN+Tipo3iOZVZzrosDKISRv0H3o82NUqmWF2jqoXdRZJthSigdiKENAW
4wIIfScBqRdATHtFCw2heSScYMxE480WeEQx2rIjLLuDMD2S0uua0cKDBOlMVV+v
t32AnCOyeTL2TGwtO1TTCZVbRH7c4ob1F1dTH6G/nu9K+vTbMJ9FNhBmnwVnYu12
V+RK+WDgogxN9I4hTE/kUKTxbhA6k9u3sG09tql0mIBbLBkVoSsC3ib9WHSOS/ki
KcHDNJAvy3pOR5gBTlR/x24r3G1RGkJcjiFTPaCan4oqrsveY4wQ63wImQqoejXj
8iOvJ88ssYTWkol0nSR4QntOeGNK+ni37U2MpBizKdflaVMN75GhDkGlZ55Rt1BA
L1SpKUC5c9Kyz43Wvf0QZjWoSvB4LZJc9daU1sMIkCn20nKM6G8rY9PtONE9xoQE
2hYW9S5ufrm9YRuKy2qJmsfEw0Ou2S5MiH6brgHhqnmgWpU9mK3AKN0o1JfwxTAK
nHQxrudAB0egpAePUs2wW8jHWXbdtP2GSM575AKr8JMYZkf/K8UoXsibTGPSKb5W
VLL35ZKr8y0oVctWnUEd
=UARS
-----END PGP SIGNATURE-----



 Feb 27 2015



prev sibling next sibling parent  "Paulo Pinto" <pjmlp progtools.org>  writes:


On Saturday, 21 February 2015 at 19:20:48 UTC, JN wrote:

 https://developer.apple.com/news/?id=02202015a

 Interesting...

 Apple is dropping GC in favor of automatic reference counting. 
 What are the benefits of ARC over GC? Is it just about 
 predictability of resource freeing? Would ARC make sense in D?


As one of the GC developers explains at Reddit, the GC never 
worked properly.

http://www.reddit.com/r/programming/comments/2wo18p/mac_apps_that_use_garbage_collection_must_move_to/coss311



 Feb 21 2015



prev sibling  parent reply "Baz" <bb.temp gmx.com>  writes:


On Saturday, 21 February 2015 at 19:20:48 UTC, JN wrote:

 https://developer.apple.com/news/?id=02202015a

 Interesting...

 Apple is dropping GC in favor of automatic reference counting. 
 What are the benefits of ARC over GC? Is it just about 
 predictability of resource freeing? Would ARC make sense in D?


Im not here to be liked so let's throw the bomb:

http://www.codingwisdom.com/codingwisdom/2012/09/reference-counted-smart-pointers-are-for-retards.html

The guy, despite of...well you know, is right, smart ptr are for 
beginner. The more the experience, the more you can manage memory 
by your own.



 Feb 26 2015



 next sibling parent  "Paulo  Pinto" <pjmlp progtools.org>  writes:


On Thursday, 26 February 2015 at 12:06:53 UTC, Baz wrote:

 On Saturday, 21 February 2015 at 19:20:48 UTC, JN wrote:

 https://developer.apple.com/news/?id=02202015a

 Interesting...

 Apple is dropping GC in favor of automatic reference counting. 
 What are the benefits of ARC over GC? Is it just about 
 predictability of resource freeing? Would ARC make sense in D?


 Im not here to be liked so let's throw the bomb:

 http://www.codingwisdom.com/codingwisdom/2012/09/reference-counted-smart-pointers-are-for-retards.html

 The guy, despite of...well you know, is right, smart ptr are 
 for beginner. The more the experience, the more you can manage 
 memory by your own.


I am behind a firewall so I cannot read it, still here goes my 
take on it.

Only people writing on their own, with full control of 100% of 
the application code without any third party libraries can manage 
memory by their own.

Add a third party library without possibility to change the code, 
teams with more than 10 developers, teams that are distributed, 
teams with varied skill set, teams with member rotation, 
overtime, and I don't believe anyone in this context is able to 
have on their head the whole ownership relations of heap 
allocated memory.

I have seen it happen lots of time in enterprise projects.

Besides, the CVE daily exploits notification list is the proof of 
that.


--
Paulo



 Feb 26 2015



prev sibling  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Thursday, 26 February 2015 at 12:06:53 UTC, Baz wrote:

 On Saturday, 21 February 2015 at 19:20:48 UTC, JN wrote:

 https://developer.apple.com/news/?id=02202015a

 Interesting...

 Apple is dropping GC in favor of automatic reference counting. 
 What are the benefits of ARC over GC? Is it just about 
 predictability of resource freeing? Would ARC make sense in D?


 Im not here to be liked so let's throw the bomb:

 http://www.codingwisdom.com/codingwisdom/2012/09/reference-counted-smart-pointers-are-for-retards.html

 The guy, despite of...well you know, is right, smart ptr are 
 for beginner. The more the experience, the more you can manage 
 memory by your own.


Programmer that think they are so smart they handle everything 
are the very first to screw up because of lack of self awareness. 
Good, now that we established the author is the retard here, how 
seriously do we take his rant ?



 Feb 26 2015