www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Swift does away with pointers == pervasive ARC

reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
What say you to that, Walter?

Apple have committed to pervasive ARC, which you consistently argue is
not feasible...
Have I missed something, or is this a demonstration that it is
actually practical?
Jun 16 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 16 June 2014 at 15:16:44 UTC, Manu via Digitalmars-d 
wrote:
 Have I missed something, or is this a demonstration that it is
 actually practical?
All performance tests so far says Swift is slower than Objective-C, which is slow to begin with, but it is still in Beta. I don't think you are supposed to do signal processing in Swift, most apps can be done with higher level/script-like programming and leave the performance sensitive part to the rich iOS frameworks.
Jun 16 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 16 June 2014 at 15:16:44 UTC, Manu via Digitalmars-d 
wrote:
 What say you to that, Walter?

 Apple have committed to pervasive ARC, which you consistently 
 argue is
 not feasible...
 Have I missed something, or is this a demonstration that it is
 actually practical?
Good luck writing games in Swift.
Jun 16 2014
parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Monday, 16 June 2014 at 16:19:55 UTC, Dicebot wrote:
 On Monday, 16 June 2014 at 15:16:44 UTC, Manu via Digitalmars-d 
 wrote:
 What say you to that, Walter?

 Apple have committed to pervasive ARC, which you consistently 
 argue is
 not feasible...
 Have I missed something, or is this a demonstration that it is
 actually practical?
Good luck writing games in Swift.
https://github.com/fullstackio/FlappySwift
Jun 16 2014
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 16.06.2014 18:23, schrieb Namespace:
 On Monday, 16 June 2014 at 16:19:55 UTC, Dicebot wrote:
 On Monday, 16 June 2014 at 15:16:44 UTC, Manu via Digitalmars-d wrote:
 What say you to that, Walter?

 Apple have committed to pervasive ARC, which you consistently argue is
 not feasible...
 Have I missed something, or is this a demonstration that it is
 actually practical?
Good luck writing games in Swift.
https://github.com/fullstackio/FlappySwift
That's not something I would consider a full blown game.
Jun 16 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 16 June 2014 at 17:12:27 UTC, Benjamin Thaut wrote:
 Am 16.06.2014 18:23, schrieb Namespace:
 On Monday, 16 June 2014 at 16:19:55 UTC, Dicebot wrote:
 On Monday, 16 June 2014 at 15:16:44 UTC, Manu via 
 Digitalmars-d wrote:
 What say you to that, Walter?

 Apple have committed to pervasive ARC, which you 
 consistently argue is
 not feasible...
 Have I missed something, or is this a demonstration that it 
 is
 actually practical?
Good luck writing games in Swift.
https://github.com/fullstackio/FlappySwift
That's not something I would consider a full blown game.
And definitely not kind of games Manu usually speaks about.
Jun 16 2014
parent "Namespace" <rswhite4 googlemail.com> writes:
On Monday, 16 June 2014 at 17:21:20 UTC, Dicebot wrote:
 On Monday, 16 June 2014 at 17:12:27 UTC, Benjamin Thaut wrote:
 Am 16.06.2014 18:23, schrieb Namespace:
 On Monday, 16 June 2014 at 16:19:55 UTC, Dicebot wrote:
 On Monday, 16 June 2014 at 15:16:44 UTC, Manu via 
 Digitalmars-d wrote:
 What say you to that, Walter?

 Apple have committed to pervasive ARC, which you 
 consistently argue is
 not feasible...
 Have I missed something, or is this a demonstration that it 
 is
 actually practical?
Good luck writing games in Swift.
https://github.com/fullstackio/FlappySwift
That's not something I would consider a full blown game.
And definitely not kind of games Manu usually speaks about.
You said "game" and it's a game. ;) But I know what you mean.
Jun 16 2014
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Monday, 16 June 2014 at 15:16:44 UTC, Manu via Digitalmars-d 
wrote:
 What say you to that, Walter?

 Apple have committed to pervasive ARC, which you consistently 
 argue is not feasible...
 Have I missed something, or is this a demonstration that it is
 actually practical?
Here's some kindling; a quick and dirty peek at a few performance indicators: http://www.splasmata.com/?p=2798 (Code: http://splasm.com/keithg/Swift%20Tests.zip ) -Wyatt
Jun 16 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2014 8:16 AM, Manu via Digitalmars-d wrote:
 What say you to that, Walter?

 Apple have committed to pervasive ARC, which you consistently argue is
 not feasible...
 Have I missed something, or is this a demonstration that it is
 actually practical?
I know very little about Swift. But I did not say it was "not feasible". I said pervasive ARC in D simply would not deliver the results you wanted. I doubt it delivers them in Swift, either, though of course I don't have experience with Swift. I.e. pervasive ARC in D would not deliver performance unless memory safety was discarded.
Jun 16 2014
next sibling parent "Sean Kelly" <sean invisibleduck.org> writes:
On Monday, 16 June 2014 at 18:12:59 UTC, Walter Bright wrote:
 But I did not say it was "not feasible". I said pervasive ARC 
 in D simply would not deliver the results you wanted. I doubt 
 it delivers them in Swift, either, though of course I don't 
 have experience with Swift.

 I.e. pervasive ARC in D would not deliver performance unless 
 memory safety was discarded.
Swift targets the same VM as ObjC so I think ARC was a foregone conclusion. And for that case it makes sense, as predictable performance is crucial on mobile platforms. Since D has raw pointers and inline assembly I don't see ARC as being terribly practical here however. It's kind of the same issue as having write barriers to support an incremental GC.
Jun 16 2014
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 17 June 2014 04:13, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 6/16/2014 8:16 AM, Manu via Digitalmars-d wrote:
 What say you to that, Walter?

 Apple have committed to pervasive ARC, which you consistently argue is
 not feasible...
 Have I missed something, or is this a demonstration that it is
 actually practical?
I know very little about Swift. But I did not say it was "not feasible". I said pervasive ARC in D simply would not deliver the results you wanted. I doubt it delivers them in Swift, either, though of course I don't have experience with Swift. I.e. pervasive ARC in D would not deliver performance unless memory safety was discarded.
Hmmm, I still don't buy it, but I'm thinking more that it might benefit from something like a Rust borrowed pointer to maintain safety and performance. You like the 'unsafe escape' defense, so we need to address that, and I think Rust gave us the answer.
Jun 16 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2014 5:48 PM, Manu via Digitalmars-d wrote:
 Hmmm, I still don't buy it,
I know, but you also have not responded to my explanation of why. Such as the "dec" being required to be inside an expensive exception handler. Note that Swift seems to not do exceptions (I may be wrong, again, I know little about Swift), which is one way to avoid that problem.
 but I'm thinking more that it might
 benefit from something like a Rust borrowed pointer to maintain safety
 and performance. You like the 'unsafe escape' defense, so we need to
 address that, and I think Rust gave us the answer.
Have you or anyone you know written any non-trivial programs in Rust and tried this out?
Jun 16 2014
next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 17 June 2014 13:18, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 6/16/2014 5:48 PM, Manu via Digitalmars-d wrote:
 Hmmm, I still don't buy it,
I know, but you also have not responded to my explanation of why. Such as the "dec" being required to be inside an expensive exception handler.
Granted. I don't really understand the situation well enough to comment with any authority. What are the conditions that create the requirement, or could relax it? The problem is if something throws, it need an implicit catch to release the ref right? nothrow obviously relaxes this requirement. Also in cases where the ref fiddling was able to be eliminated, which appear to be fairly numerous. I don't know enough about other circumstances, but I can see a few possibilities. Also, just the frequency of pointer copying I see in my own code is very low, and I would NEVER generate that code in hot loops. I find it very hard to convince myself either way without evidence :/ Exceptions are one of my biggest weaknesses. I've never used the exception handler before, in C++ or D (on XBox360 for instance, the exception handler is actually broken, generates bad code, and Microsoft recommend to disable C++ exceptions). I've used scope(exit), but never in hot code or criticised the codegen. I can't imagine exceptions would appear in hot code very often/ever?
 Note that Swift seems to not do exceptions (I may be wrong, again, I know
 little about Swift), which is one way to avoid that problem.
I wonder if that was a deliberate choice based on a reaction to this problem?
 but I'm thinking more that it might
 benefit from something like a Rust borrowed pointer to maintain safety
 and performance. You like the 'unsafe escape' defense, so we need to
 address that, and I think Rust gave us the answer.
Have you or anyone you know written any non-trivial programs in Rust and tried this out?
No, I intend to have a better play with Rust when I get some time. I need to break through the syntax barrier first though! ;) But this is the key innovation in Rust I'm interested to know more about in practise.
Jun 16 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2014 10:02 PM, Manu via Digitalmars-d wrote:
 Granted. I don't really understand the situation well enough to
 comment with any authority. What are the conditions that create the
 requirement, or could relax it?
inc try { ... code that may throw an exception ... } finally { dec; }
 nothrow obviously relaxes this requirement.
Yes, it does.
 I don't know enough about other circumstances, but I can see a few
 possibilities. Also, just the frequency of pointer copying I see in my
 own code is very low, and I would NEVER generate that code in hot
 loops.
 I find it very hard to convince myself either way without evidence :/
I suggest writing some C++ code with shared_ptr<T>, and disassemble the result.
 I can't imagine exceptions would appear in hot code very often/ever?
I've tried to explain this to you for months. You don't believe my explanations, we just go round in circles. I strongly suggest you write some code with shared_ptr<T> and try it out. Disassemble the result. Benchmark it. Use Microsoft C++, so I won't be sabotaging your results and it won't be because I write crappy compilers :-)
Jun 17 2014
next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 17 June 2014 18:18, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 6/16/2014 10:02 PM, Manu via Digitalmars-d wrote:

 I can't imagine exceptions would appear in hot code very often/ever?
I've tried to explain this to you for months. You don't believe my explanations, we just go round in circles. I strongly suggest you write some code with shared_ptr<T> and try it out. Disassemble the result. Benchmark it. Use Microsoft C++, so I won't be sabotaging your results and it won't be because I write crappy compilers :-)
ARC is useless without compiler support. If we can't experiment with the compiler's ability to eliminate redundant RC related work, then we aren't 'experimenting' with anything of interest. We agree ARC isn't acceptable without compiler support. That's never been on debate. I have no way of testing whether the compiler is able to produce acceptable results in C or D today. shared_ptr will demonstrate what we already know is not acceptable, not whether the results of compiler support for RC optimisation is satisfactory. I believe your explanations, but that's not where I'm hung up. In most cases I can visualise, there is significant opportunity for the compiler to eliminate redundant work, and in the remaining cases, I can imagine numerous very simple approaches to remove the bumps from hot code without interfering very much at all. Andrei's detailed document from months ago demonstrating a good RC implementation was encouraging, although he somehow presented it as evidence against RC, which I never understood. It's all about the compilers ability to eliminate the redundant work, and it's possible that in some instances, that might result in slightly different usage or access patterns, which is a relevant part of the experiment. I don't see how I can do any meaningful experiment with shared_ptr, since the bumps will never go away no matter how they're arranged.
Jun 17 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/17/2014 4:36 AM, Manu via Digitalmars-d wrote:
 On 17 June 2014 18:18, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On 6/16/2014 10:02 PM, Manu via Digitalmars-d wrote:

 I can't imagine exceptions would appear in hot code very often/ever?
I've tried to explain this to you for months. You don't believe my explanations, we just go round in circles. I strongly suggest you write some code with shared_ptr<T> and try it out. Disassemble the result. Benchmark it. Use Microsoft C++, so I won't be sabotaging your results and it won't be because I write crappy compilers :-)
ARC is useless without compiler support.
It is not possible to understand the tradeoffs with ARC without understanding the cost of the DEC.
 If we can't experiment with
 the compiler's ability to eliminate redundant RC related work, then we
 aren't 'experimenting' with anything of interest.
That is assuming that a sufficiently smart compiler can eliminate all costs associated with ARC, so there is no need to understand those costs. This really is a faulty assumption. No compiler has achieved this, or come even close.
 I have no way of testing whether the compiler is able to produce
 acceptable results in C or D today. shared_ptr will demonstrate what
 we already know is not acceptable, not whether the results of compiler
 support for RC optimisation is satisfactory.
What shared_ptr will demonstrate to you is the cost of a dec, which you do not believe to be significant, and how that is affected by exception handling, which you stated that you do not understand. I don't think it is possible to make appropriate tradeoffs without understanding these costs, and when/why they are incurred. Nor does it make it possible to understand the tradeoffs in relation to the design decisions made by Rust/Swift. To advocate ARC for D means understanding this stuff. It'll only take a few minutes of your time.
 Andrei's detailed document from months ago demonstrating a good RC
 implementation was encouraging, although he somehow presented it as
 evidence against RC, which I never understood.
Please, take some time to try out RC and disassemble the code.
 It's all about the compilers ability to eliminate the redundant work,
 and it's possible that in some instances, that might result in
 slightly different usage or access patterns, which is a relevant part
 of the experiment. I don't see how I can do any meaningful experiment
 with shared_ptr, since the bumps will never go away no matter how
 they're arranged.
If compilers were smart enough to remove the ref counts, you'd be right. But they aren't - not even close. Hence there are big time penalties for those bumps, and to understand the tradeoffs it is necessary to understand the height of them.
Jun 17 2014
next sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Tuesday, 17 June 2014 at 18:15:24 UTC, Walter Bright wrote:
 It is not possible to understand the tradeoffs with ARC without 
 understanding the cost of the DEC.
One thing D has going for it compared to C++ for reference counting is shared vs. unshared types. At least ARC in D wouldn't have to default to performing synchronized reference counting like shared_ptr does in C++.
Jun 17 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/17/2014 11:20 AM, Sean Kelly wrote:
 One thing D has going for it compared to C++ for reference
 counting is shared vs. unshared types.  At least ARC in D
 wouldn't have to default to performing synchronized reference
 counting like shared_ptr does in C++.
Yup.
Jun 17 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 17, 2014 at 11:15:29AM -0700, Walter Bright via Digitalmars-d wrote:
 On 6/17/2014 4:36 AM, Manu via Digitalmars-d wrote:
[...]
If we can't experiment with the compiler's ability to eliminate
redundant RC related work, then we aren't 'experimenting' with
anything of interest.
That is assuming that a sufficiently smart compiler can eliminate all costs associated with ARC, so there is no need to understand those costs. This really is a faulty assumption. No compiler has achieved this, or come even close.
[...] I don't think he's claiming that the compiler can eliminate *all* costs associated with ARC, just that it can do enough to be reasonably performant. But as I said, until somebody actually implements such a thing in a (github fork of a) D compiler, we have no real evidence as to just how much the compiler can/cannot do. T -- I don't trust computers, I've spent too long programming to think that they can get anything right. -- James Miller
Jun 17 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/17/2014 11:31 AM, H. S. Teoh via Digitalmars-d wrote:
 I don't think he's claiming that the compiler can eliminate *all* costs
 associated with ARC, just that it can do enough to be reasonably
 performant.
Such a claim still cannot be made without understanding the costs incurred when it cannot be eliminated.
 But as I said, until somebody actually implements such a
 thing in a (github fork of a) D compiler, we have no real evidence as to
 just how much the compiler can/cannot do.
You can do data flow analysis in your head and mock up the results and test them without too much difficulty.
Jun 17 2014
prev sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Tuesday, 17 June 2014 at 18:15:24 UTC, Walter Bright wrote:
 On 6/17/2014 4:36 AM, Manu via Digitalmars-d wrote:
 On 17 June 2014 18:18, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On 6/16/2014 10:02 PM, Manu via Digitalmars-d wrote:

 I can't imagine exceptions would appear in hot code very 
 often/ever?
I've tried to explain this to you for months. You don't believe my explanations, we just go round in circles. I strongly suggest you write some code with shared_ptr<T> and try it out. Disassemble the result. Benchmark it. Use Microsoft C++, so I won't be sabotaging your results and it won't be because I write crappy compilers :-)
ARC is useless without compiler support.
It is not possible to understand the tradeoffs with ARC without understanding the cost of the DEC.
Is there a way to move the costs of exception handling to occur only if an exception is actually encountered? Perhaps something similar to the mark & sweep for a garbage collection that can update reference counts? The idea being that code that cares enough about lack of pauses is not generally going to be throwing exceptions in the first place (though may not necessarily be able to be nothrow due to rare circumstances). I'm guessing there's also no way to actually estimate what sort of performance hit ARC would bring? Even something like a 20% performance hit in functions that are not specifically optimized for it would be reasonable if it comes at the benefit of lack of pauses.
Jun 17 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/17/2014 2:51 PM, Kapps wrote:
 Is there a way to move the costs of exception handling to occur
 only if an exception is actually encountered?
That's already been done to a large extent. But you can see what's left for yourself - compile some shared_ptr<T> code with clang/g++/VC++ and take a look at the generated code.
 I'm guessing there's also no way to actually estimate what sort
 of performance hit ARC would bring?
Yes, there is. Write code that a hypothetical ARC would generate, and then test it.
Jun 17 2014
prev sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 17, 2014 at 09:36:09PM +1000, Manu via Digitalmars-d wrote:
 On 17 June 2014 18:18, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On 6/16/2014 10:02 PM, Manu via Digitalmars-d wrote:

 I can't imagine exceptions would appear in hot code very
 often/ever?
I've tried to explain this to you for months. You don't believe my explanations, we just go round in circles. I strongly suggest you write some code with shared_ptr<T> and try it out. Disassemble the result. Benchmark it. Use Microsoft C++, so I won't be sabotaging your results and it won't be because I write crappy compilers :-)
ARC is useless without compiler support. If we can't experiment with the compiler's ability to eliminate redundant RC related work, then we aren't 'experimenting' with anything of interest. We agree ARC isn't acceptable without compiler support. That's never been on debate. I have no way of testing whether the compiler is able to produce acceptable results in C or D today. shared_ptr will demonstrate what we already know is not acceptable, not whether the results of compiler support for RC optimisation is satisfactory. I believe your explanations, but that's not where I'm hung up. In most cases I can visualise, there is significant opportunity for the compiler to eliminate redundant work, and in the remaining cases, I can imagine numerous very simple approaches to remove the bumps from hot code without interfering very much at all.
[...] Perhaps the way to convince Walter, is to fork dmd on github, check it out, and implement ARC in your fork (to whatever extent is necessary for a first, possibly very crude, demonstration)? It doesn't have to work 100%, it doesn't even have to pass the test suite or compile the full D language, it just has to do enough to prove that the compiler is capable of automatically making performance-critical ARC optimizations on whatever benchmark you choose to use. This would add a lot of substance to all the hot air we've been pumping at each other every time a GC/ARC-related thread comes up. T -- If it's green, it's biology, If it stinks, it's chemistry, If it has numbers it's math, If it doesn't work, it's technology.
Jun 17 2014
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 17 Jun 2014 01:02:32 -0400, Manu via Digitalmars-d  
<digitalmars-d puremagic.com> wrote:

 On 17 June 2014 13:18, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On 6/16/2014 5:48 PM, Manu via Digitalmars-d wrote:
 Hmmm, I still don't buy it,
I know, but you also have not responded to my explanation of why. Such as the "dec" being required to be inside an expensive exception handler.
Granted. I don't really understand the situation well enough to comment with any authority. What are the conditions that create the requirement, or could relax it? The problem is if something throws, it need an implicit catch to release the ref right?
This is the issue, because the release can do a LOT of shit. It could release a whole tree of objects, it could start throwing its own exceptions. It's like doing a lot of stuff inside a signal handler. Possible, but very hairy. A possible solution might be to defer the releasing until the exception is caught, and have the catch statement call all the releases. Just speaking from ignorance, I don't know if this solves Walter's concern. The stack unwinding still would have to figure all this stuff out. But if we just add these calls to a release pool that is drained at the catch point, maybe it helps solve the problem. BTW, as a general response, I don't think swift is as proven yet as Objective C. As has been pointed out many times, one of the greatest (and arguably worst) parts of Objective C is that any C code is valid Objective C code. This means, you can instantly go into unsafe C mode if you need the performance. From what I can tell, swift does NOT allow that, there will need to be some sort of bridge there. I think it will make code that uses pure objective C calls and methods more pleasant to write (i.e. UI and framework code). I'm not sure how I feel about it yet, I have yet to use Swift. But I am hesitant to say that swift will be a step forward performance-wise. Apple claims it is, we shall see. -Steve
Jun 17 2014
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/16/2014 11:18 PM, Walter Bright wrote:
 On 6/16/2014 5:48 PM, Manu via Digitalmars-d wrote:
 Hmmm, I still don't buy it,
I know, but you also have not responded to my explanation of why. Such as the "dec" being required to be inside an expensive exception handler.
Pardon my ignorance here, but is this a cost that would *always* be paid, or *only* while an exception is being thrown and the callstack is being unwound? If it's only paid while an exception is thrown, then does it really matter? Exception throwing has never really come with any particular expectation of speed, being "exceptional" cases. Roughly how much of a slowdown are we talking here?
Jun 16 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2014 10:30 PM, Nick Sabalausky wrote:
 is this a cost that would *always* be paid,
Yes. I've probably written 30+ posts explaining this again and again. Nobody believes me. I beg you to write some code and disassemble it and see for yourself.
Jun 17 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/17/2014 4:23 AM, Walter Bright wrote:
 On 6/16/2014 10:30 PM, Nick Sabalausky wrote:
 is this a cost that would *always* be paid,
Yes. I've probably written 30+ posts explaining this again and again. Nobody believes me. I beg you to write some code and disassemble it and see for yourself.
It's not that I don't believe you, I guess I must have just missed a lot of those posts, or probably glanced through them too quickly. I'm more interested in this topic now than I was before, so I'm just trying to get up to speed (so to speak). I'll try to look up those posts again before I end up asking them to be repeated. Keep in mind, for people in certain areas, the allure of a memory management system with no/minimal collection pauses, minimized memory requirements and good behavior in low-memory conditions (even if it all comes with a non-trivial overall performance cost and a little bit of care here and there) can be VERY strong. So, FWIW, that's the perspective where all this is coming from.
Jun 17 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/17/2014 1:59 AM, Nick Sabalausky wrote:
 It's not that I don't believe you, I guess I must have just missed a lot of
 those posts, or probably glanced through them too quickly. I'm more interested
 in this topic now than I was before, so I'm just trying to get up to speed (so
 to speak). I'll try to look up those posts again before I end up asking them to
 be repeated.

 Keep in mind, for people in certain areas, the allure of a memory management
 system with no/minimal collection pauses, minimized memory requirements and
good
 behavior in low-memory conditions (even if it all comes with a non-trivial
 overall performance cost and a little bit of care here and there) can be VERY
 strong. So, FWIW, that's the perspective where all this is coming from.
Oh, I totally understand where it's coming from. I'm trying to point out that ARC is not a magic zero-cost system. Its costs are SUBSTANTIAL. But in order to understand those costs, it is necessary to understand how exception handling works.
Jun 17 2014
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/17/2014 5:10 AM, Walter Bright wrote:
 On 6/17/2014 1:59 AM, Nick Sabalausky wrote:
 Keep in mind, for people in certain areas, the allure of a memory
 management
 system with no/minimal collection pauses, minimized memory
 requirements and good
 behavior in low-memory conditions (even if it all comes with a
 non-trivial
 overall performance cost and a little bit of care here and there) can
 be VERY
 strong. So, FWIW, that's the perspective where all this is coming from.
Oh, I totally understand where it's coming from.
Fair enough.
 I'm trying to point out
 that ARC is not a magic zero-cost system. Its costs are SUBSTANTIAL. But
 in order to understand those costs, it is necessary to understand how
 exception handling works.
Oh right, I definitely don't mean to imply it's any sort of "no cost" deal. It's certainly all tradeoffs, of course. As you undoubtedly know, for some things, GC's costs can be high, too. But like I've said, I'm an ARC novice, so I'm just trying to gain an understanding of the extent of ARC's costs since it does, at the very least, have some intriguing properties.
Jun 17 2014
prev sibling parent reply "eles" <eles eles.com> writes:
On Tuesday, 17 June 2014 at 09:10:14 UTC, Walter Bright wrote:
 On 6/17/2014 1:59 AM, Nick Sabalausky wrote:

 Oh, I totally understand where it's coming from. I'm trying to 
 point out that ARC is not a magic zero-cost system. Its costs 
 are SUBSTANTIAL. But in order to understand those costs, it is 
 necessary to understand how exception handling works.
It is not (only) about cost, it is about determinism. Exceptions are on the error recovery path, so they are less important to be deterministic. What is really critical is not that the execution time of such or such function, but the moment when it is called. And on the normal execution path. This is what manual memory management (and, to a degree, ARC) and the GC fails to do: determinism of the calls on the normal execution path (and in the call of finalizers). Yes, both ARC and manual memory management may be non-deterministic, but not on the normal execution path and not with respect to the calls (a malloc is nedeterministic, but its call is; you could always statically allocate beforehand).
Jun 17 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/17/2014 2:31 AM, eles wrote:
 It is not (only) about cost, it is about determinism. Exceptions are on the
 error recovery path, so they are less important to be deterministic.
Yes, I do understand that. What I am trying to get across is that ARC can often consume MORE aggregate time than GC.
Jun 17 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/17/2014 2:00 PM, Walter Bright wrote:
 On 6/17/2014 2:31 AM, eles wrote:
 It is not (only) about cost, it is about determinism. Exceptions are
 on the
 error recovery path, so they are less important to be deterministic.
Yes, I do understand that. What I am trying to get across is that ARC can often consume MORE aggregate time than GC.
That isn't necessarily a deal-breaker for certain applications. For example, most games will happily accept a slightly reduced "typical" framerate to reduce dropped frames or other time spikes. Framerate spikes can be far more jarring and noticeable for the player than loosing a few fps. Of course, as usual, the acceptability of tradeoffs all depends on the actual numbers. Ex: An ARC that bloats overall execution time by 100x is certainly not worthwhile, but one that increases execution time by 0.1% can definitely be a fantastic tradeoff for soft-realtime and low-memory environments. Obviously those numbers are exaggerated examples, but just to illustrate the point. Again, nobody's saying "ARC is definitely better/worthwhile". It's just that, since we don't have numbers, we really can't say that ARC *isn't* worthwhile.
Jun 17 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/17/2014 11:38 AM, Nick Sabalausky wrote:
 That isn't necessarily a deal-breaker for certain applications.
I do know that.
 Again, nobody's saying "ARC is definitely better/worthwhile".
Yes, they are, and the problems/costs of ARC are dismissed as either insignificant or something that ordinary compiler technology can overcome. I can't even get anyone to examine what code is generated for a DEC. It's like arguing about the best route from Seattle to Denver while refusing to look at a map.
Jun 17 2014
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 17 Jun 2014 14:00:08 -0700
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 I can't even get anyone to examine what code is generated for a DEC.
 It's like arguing about the best route from Seattle to Denver while
 refusing to look at a map.
You probably explained it elsewhere and I just missed it, but what's a DEC? I'm not finding much useful when I search for it. - Jonathan M Davis
Jun 17 2014
parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Tuesday, 17 June 2014 at 23:45:20 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
 You probably explained it elsewhere and I just missed it, but 
 what's a DEC?
I think he is probably talking about decrementing the ref count.
Jun 17 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/17/2014 4:51 PM, Tofu Ninja wrote:
 On Tuesday, 17 June 2014 at 23:45:20 UTC, Jonathan M Davis via Digitalmars-d
wrote:
 You probably explained it elsewhere and I just missed it, but what's a DEC?
I think he is probably talking about decrementing the ref count.
Yes
Jun 17 2014
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 17 Jun 2014 18:35:37 -0700
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 6/17/2014 4:51 PM, Tofu Ninja wrote:
 On Tuesday, 17 June 2014 at 23:45:20 UTC, Jonathan M Davis via
 Digitalmars-d wrote:
 You probably explained it elsewhere and I just missed it, but
 what's a DEC?
I think he is probably talking about decrementing the ref count.
Yes
Okay, thanks. - Jonathan M Davis
Jun 17 2014
parent reply "whassup" <Whasss yahoo.com> writes:
  Doesn't Nimrod do deferred referencing counting(with backup 
cycle detection). Stack references don't need to DEC/INC. Do 
conservative stack scan during collection. Nimrod doesn't have 
D's GC issues, why not just do that?
Jun 18 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 18 June 2014 at 17:08:25 UTC, whassup wrote:
  Doesn't Nimrod do deferred referencing counting(with backup 
 cycle detection). Stack references don't need to DEC/INC. Do 
 conservative stack scan during collection. Nimrod doesn't have 
 D's GC issues, why not just do that?
Ho, that make me think, doing RC but not when unwinding exception and backing the whole thing with a GC would probably be an interesting solution.
Jun 18 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 17 Jun 2014 15:02:32 +1000
Manu via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 I can't imagine exceptions would appear in hot code very often/ever?
They could definitely appear in hot code if the exception is for a case that is very rare, but it's certainly true that if an exception is likely to be thrown frequently that that calls for rethinking that code so that exceptions aren't thrown so frequently (and that's that much more true if you're talking about hot code). - Jonathan M Davis
Jun 17 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 17/06/14 05:18, Walter Bright wrote:

 Note that Swift seems to not do exceptions (I may be wrong, again, I
 know little about Swift), which is one way to avoid that problem.
It does not support exceptions. -- /Jacob Carlborg
Jun 17 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/17/2014 5:21 AM, Jacob Carlborg wrote:
 On 17/06/14 05:18, Walter Bright wrote:

 Note that Swift seems to not do exceptions (I may be wrong, again, I
 know little about Swift), which is one way to avoid that problem.
It does not support exceptions.
I wouldn't be surprised if it doesn't in order to make ARC more palatable.
Jun 17 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 17 June 2014 at 18:17:21 UTC, Walter Bright wrote:
 I wouldn't be surprised if it doesn't in order to make ARC more 
 palatable.
I don't know, but on iOS you are supposed to save state to disk continuously so that the app can die silently and reboot to where you left off. And mobile apps are supposed to boot real fast since they are used on the move. So maybe they figured it was good enough to leave the try-catch complexity out…
Jun 17 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/17/2014 11:25 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Tuesday, 17 June 2014 at 18:17:21 UTC, Walter Bright wrote:
 I wouldn't be surprised if it doesn't in order to make ARC more palatable.
I don't know, but on iOS you are supposed to save state to disk continuously so that the app can die silently and reboot to where you left off. And mobile apps are supposed to boot real fast since they are used on the move. So maybe they figured it was good enough to leave the try-catch complexity out…
If an app can be cheaply restarted, an easy & fast way to do memory allocation is to use a "bump allocator" like dmd does, and then restart when it runs out of memory. I'm not joking, this can actually be very practical for certain kinds of programs.
Jun 17 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 17, 2014 at 11:39:50AM -0700, Walter Bright via Digitalmars-d wrote:
 On 6/17/2014 11:25 AM, "Ola Fosheim Grøstad"
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
On Tuesday, 17 June 2014 at 18:17:21 UTC, Walter Bright wrote:
I wouldn't be surprised if it doesn't in order to make ARC more
palatable.
I don't know, but on iOS you are supposed to save state to disk continuously so that the app can die silently and reboot to where you left off. And mobile apps are supposed to boot real fast since they are used on the move. So maybe they figured it was good enough to leave the try-catch complexity out…
If an app can be cheaply restarted, an easy & fast way to do memory allocation is to use a "bump allocator" like dmd does, and then restart when it runs out of memory.
I don't think the user would enjoy the app "randomly" shutting down and starting up again on him. :-) One idea that occurs to me, though, is to split the app into a frontend that does not allocate during runtime, and a backend, which may. Design it in such a way that the backend can freely restart anytime without adversely affecting the frontend; then you can maintain an apparance of continuous execution across backend restarts. If the restart time can be reduced to within a single animation frame, for example, one could actually write a game engine that never deallocates, it just restarts itself when it runs out of memory and the frontend maintains the façade of continuous execution. This will trump GC, ARC, malloc, indeed, any memory allocation scheme beyond bump-a-pointer. :-P T -- That's not a bug; that's a feature!
Jun 17 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/17/2014 3:04 PM, H. S. Teoh via Digitalmars-d wrote:
 I don't think the user would enjoy the app "randomly" shutting down and
 starting up again on him. :-)

 One idea that occurs to me, though, is to split the app into a frontend
 that does not allocate during runtime, and a backend, which may. Design
 it in such a way that the backend can freely restart anytime without
 adversely affecting the frontend; then you can maintain an apparance of
 continuous execution across backend restarts.

 If the restart time can be reduced to within a single animation frame,
 for example, one could actually write a game engine that never
 deallocates, it just restarts itself when it runs out of memory and the
 frontend maintains the façade of continuous execution. This will trump
 GC, ARC, malloc, indeed, any memory allocation scheme beyond
 bump-a-pointer. :-P
Sounds cool, but I would think in that case you may as well just stick with region allocators. Same effect with less overhead and more fine-tuning control. Or a global region allocator or something. Speaking of manual memory management, is it currently possible to manually allocate closures?
Jun 17 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/17/2014 1:36 PM, Nick Sabalausky wrote:
 Speaking of manual memory management, is it currently possible to manually
 allocate closures?
You can hijack the function that does it with your own, and do it how you like.
Jun 17 2014
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 17 June 2014 at 21:02:14 UTC, Walter Bright wrote:
 You can hijack the function that does it with your own, and do 
 it how you like.
Or do some kind of functor thingy and pass the closed over variables manually.
Jun 17 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 17 June 2014 at 20:36:58 UTC, Nick Sabalausky wrote:
 Speaking of manual memory management, is it currently possible 
 to manually allocate closures?
Yes and no. You can create a delegate manually by creating a struct with a method. You can also force allocation on the stack by using scope.
Jun 17 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 17, 2014 at 04:36:49PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
 On 6/17/2014 3:04 PM, H. S. Teoh via Digitalmars-d wrote:
I don't think the user would enjoy the app "randomly" shutting down
and starting up again on him. :-)

One idea that occurs to me, though, is to split the app into a
frontend that does not allocate during runtime, and a backend, which
may. Design it in such a way that the backend can freely restart
anytime without adversely affecting the frontend; then you can
maintain an apparance of continuous execution across backend
restarts.

If the restart time can be reduced to within a single animation
frame, for example, one could actually write a game engine that never
deallocates, it just restarts itself when it runs out of memory and
the frontend maintains the façade of continuous execution. This will
trump GC, ARC, malloc, indeed, any memory allocation scheme beyond
bump-a-pointer. :-P
Sounds cool, but I would think in that case you may as well just stick with region allocators. Same effect with less overhead and more fine-tuning control. Or a global region allocator or something.
[...] Hmm, that's an idea. Instead of having a region allocator bound to a particular function scope, have it at global level, and when it runs out of memory, it will invoke a delegate that deallocates it, create a new allocator, and reload all the objects back (presumably, the latest saved copy of the objects is good enough to continue running with). OTOH, thinking about this more carefully, it's no difference in essence from a compacting GC (bump the pointer until you run out of memory, then move all live objects to the bottom of the heap (i.e. restart the backend and reload all "live objects" back into memory) and start over), so this isn't exactly treading on new territory. T -- "I speak better English than this villain Bush" -- Mohammed Saeed al-Sahaf, Iraqi Minister of Information
Jun 17 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/17/2014 5:13 PM, H. S. Teoh via Digitalmars-d wrote:
 On Tue, Jun 17, 2014 at 04:36:49PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
 On 6/17/2014 3:04 PM, H. S. Teoh via Digitalmars-d wrote:
 I don't think the user would enjoy the app "randomly" shutting down
 and starting up again on him. :-)

 One idea that occurs to me, though, is to split the app into a
 frontend that does not allocate during runtime, and a backend, which
 may. Design it in such a way that the backend can freely restart
 anytime without adversely affecting the frontend; then you can
 maintain an apparance of continuous execution across backend
 restarts.

 If the restart time can be reduced to within a single animation
 frame, for example, one could actually write a game engine that never
 deallocates, it just restarts itself when it runs out of memory and
 the frontend maintains the façade of continuous execution. This will
 trump GC, ARC, malloc, indeed, any memory allocation scheme beyond
 bump-a-pointer. :-P
Sounds cool, but I would think in that case you may as well just stick with region allocators. Same effect with less overhead and more fine-tuning control. Or a global region allocator or something.
[...] Hmm, that's an idea. Instead of having a region allocator bound to a particular function scope, have it at global level, and when it runs out of memory, it will invoke a delegate that deallocates it, create a new allocator, and reload all the objects back (presumably, the latest saved copy of the objects is good enough to continue running with).
Actually, I was just referring to traditional usages of region allocators, but that's an idea too.
 OTOH, thinking about this more carefully, it's no difference in essence
 from a compacting GC (bump the pointer until you run out of memory, then
 move all live objects to the bottom of the heap (i.e. restart the
 backend and reload all "live objects" back into memory) and start over),
 so this isn't exactly treading on new territory.
I think there is a notable difference between this and compacting GC though. With this, you're trading off the inconvenience of paying careful attention to data persistence and fast reloading, for the benefit of eliminating the potentially-doubled memory requirements of a traditional compacting GC. It's an interesting thought. Especially since the persistence stuff has other benefits too, like improved fault tolerance (well, as long as the persisted data doesn't get corrupted).
Jun 17 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 17, 2014 at 05:30:46PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
 On 6/17/2014 5:13 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Jun 17, 2014 at 04:36:49PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
On 6/17/2014 3:04 PM, H. S. Teoh via Digitalmars-d wrote:
[...]
Hmm, that's an idea. Instead of having a region allocator bound to a
particular function scope, have it at global level, and when it runs
out of memory, it will invoke a delegate that deallocates it, create
a new allocator, and reload all the objects back (presumably, the
latest saved copy of the objects is good enough to continue running
with).
Actually, I was just referring to traditional usages of region allocators, but that's an idea too.
OTOH, thinking about this more carefully, it's no difference in
essence from a compacting GC (bump the pointer until you run out of
memory, then move all live objects to the bottom of the heap (i.e.
restart the backend and reload all "live objects" back into memory)
and start over), so this isn't exactly treading on new territory.
I think there is a notable difference between this and compacting GC though. With this, you're trading off the inconvenience of paying careful attention to data persistence and fast reloading, for the benefit of eliminating the potentially-doubled memory requirements of a traditional compacting GC.
But this may wind up being worse than a traditional compacting GC, because now you have to manually do essentially what the compacting GC does for you -- decide (on slow-access persistent storage, no less!) which objects are live and which are dead. So you end up reimplementing your own GC. And when memory runs out, you have to load things back from said slow-access storage, whereas a compacting GC would have the benefit of copying only within the relatively-faster RAM.
 It's an interesting thought. Especially since the persistence stuff
 has other benefits too, like improved fault tolerance (well, as long
 as the persisted data doesn't get corrupted).
I suppose if your program already has persistence built in, then you might as well take advantage of it by foregoing any kind of memory management and just restart when memory runs out. I'm not sure if it's actually any *better*, though. All of this rests on the assumption that it's possible to (re)load all your live objects from persistent storage within the space of a single animation frame, which may not even be possible to begin with! :-) T -- Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis
Jun 17 2014
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 17 June 2014 at 18:39:46 UTC, Walter Bright wrote:
 If an app can be cheaply restarted, an easy & fast way to do 
 memory allocation is to use a "bump allocator" like dmd does, 
 and then restart when it runs out of memory.

 I'm not joking, this can actually be very practical for certain 
 kinds of programs.
I think it was common to use a region allocator in ray tracing, per ray-path. Meaning you calculate the worst case memory consumption and malloc one big block (or put it in a segment in the exec), then just move a pointer ahead for allocations, and reset the pointer before you fire the next ray from the camera. iOS ARC do use Autorelease Pool Blocks which takes care of release() at the end of the event loop. That probably affects ARC implementation/code gen. It basically means that you don't release allocated memory except at the end of an iteration. That won't work very well in D though? https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmAutoreleasePools.html
Jun 17 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 17, 2014 at 07:19:54PM +0000, via Digitalmars-d wrote:
 On Tuesday, 17 June 2014 at 18:39:46 UTC, Walter Bright wrote:
If an app can be cheaply restarted, an easy & fast way to do memory
allocation is to use a "bump allocator" like dmd does, and then
restart when it runs out of memory.

I'm not joking, this can actually be very practical for certain kinds
of programs.
I think it was common to use a region allocator in ray tracing, per ray-path. Meaning you calculate the worst case memory consumption and malloc one big block (or put it in a segment in the exec), then just move a pointer ahead for allocations, and reset the pointer before you fire the next ray from the camera. iOS ARC do use Autorelease Pool Blocks which takes care of release() at the end of the event loop. That probably affects ARC implementation/code gen. It basically means that you don't release allocated memory except at the end of an iteration. That won't work very well in D though?
[...] Why wouldn't it? I thought that was the whole point of Andrei's work on std.allocator, specifically, a pool allocator. You allocate a pool at the beginning of an iteration, and it can be as simple as a bump-the-pointer allocator inside the pool, then at the end of the iteration you free the entire pool all at once. Presumably Andrei would come up with some way of making sure that built-in constructs like ~ would allocate from the pool instead of the GC heap, then you don't even need to restrict the code that runs inside each iteration. T -- Famous last words: I wonder what will happen if I do *this*...
Jun 17 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 17 June 2014 at 19:28:26 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 Why wouldn't it? I thought that was the whole point of Andrei's 
 work on
 std.allocator, specifically, a pool allocator. You allocate a 
 pool at
 the beginning of an iteration, and it can be as simple as a
 bump-the-pointer allocator inside the pool, then at the end of 
 the
 iteration you free the entire pool all at once.
One key difference is that iOS is a controlled framework and Apple ARC presumes that you only allocate a modest amount of ARC objects per event. So you have to take special care if you allocate lots of memory per event (create your own pools). AFAIK, Apple-style ARC is only safe to use if you don't treat it as an optional library solution. The AutoReleasePool does not free the entire pool, only the ones that have a retain-count of 1. The basic idea is that you don't have to match up the initial allocation-retain() with a release(). So I believe the codegen only have to do retain()/release() when an ARC object might escape the "event handler" call chain… Sure, you can do it for D, but you have to deal with additional issues (compared to GC).
Jun 17 2014
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 16 June 2014 at 15:16:44 UTC, Manu via Digitalmars-d 
wrote:
 What say you to that, Walter?

 Apple have committed to pervasive ARC, which you consistently 
 argue is
 not feasible...
 Have I missed something, or is this a demonstration that it is
 actually practical?
http://stackoverflow.com/questions/24101718/swift-performance-sorting-arrays Does it answer the question ?
Jun 16 2014
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 17 June 2014 10:08, deadalnix via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Monday, 16 June 2014 at 15:16:44 UTC, Manu via Digitalmars-d wrote:
 What say you to that, Walter?

 Apple have committed to pervasive ARC, which you consistently argue is
 not feasible...
 Have I missed something, or is this a demonstration that it is
 actually practical?
http://stackoverflow.com/questions/24101718/swift-performance-sorting-arrays Does it answer the question ?
-Ofast seems to perform the same as C++. -Ofast allegedly does basically what '-release -noboundscheck' does. You'd never try and benchmark D code without those flags.
Jun 16 2014
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 6/16/14, 9:22 PM, Manu via Digitalmars-d wrote:
 On 17 June 2014 10:08, deadalnix via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On Monday, 16 June 2014 at 15:16:44 UTC, Manu via Digitalmars-d wrote:
 What say you to that, Walter?

 Apple have committed to pervasive ARC, which you consistently argue is
 not feasible...
 Have I missed something, or is this a demonstration that it is
 actually practical?
http://stackoverflow.com/questions/24101718/swift-performance-sorting-arrays Does it answer the question ?
-Ofast seems to perform the same as C++. -Ofast allegedly does basically what '-release -noboundscheck' does. You'd never try and benchmark D code without those flags.
But other languages are very fast without loosing the bounds check... Other languages don't sacrifice safety and yet are very performant.
Jun 16 2014
next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 17 June 2014 10:57, Ary Borenszweig via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 6/16/14, 9:22 PM, Manu via Digitalmars-d wrote:
 On 17 June 2014 10:08, deadalnix via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On Monday, 16 June 2014 at 15:16:44 UTC, Manu via Digitalmars-d wrote:
 What say you to that, Walter?

 Apple have committed to pervasive ARC, which you consistently argue is
 not feasible...
 Have I missed something, or is this a demonstration that it is
 actually practical?
http://stackoverflow.com/questions/24101718/swift-performance-sorting-arrays Does it answer the question ?
-Ofast seems to perform the same as C++. -Ofast allegedly does basically what '-release -noboundscheck' does. You'd never try and benchmark D code without those flags.
But other languages are very fast without loosing the bounds check... Other languages don't sacrifice safety and yet are very performant.
The disassembly showed that without -Ofast, lots of redundant ref fiddling remained, and also many bounds checks. It might be something like rigid safe-ty without -Ofast.
Jun 16 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2014 5:57 PM, Ary Borenszweig wrote:
 On 6/16/14, 9:22 PM, Manu via Digitalmars-d wrote:
 On 17 June 2014 10:08, deadalnix via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On Monday, 16 June 2014 at 15:16:44 UTC, Manu via Digitalmars-d wrote:
 What say you to that, Walter?

 Apple have committed to pervasive ARC, which you consistently argue is
 not feasible...
 Have I missed something, or is this a demonstration that it is
 actually practical?
http://stackoverflow.com/questions/24101718/swift-performance-sorting-arrays Does it answer the question ?
-Ofast seems to perform the same as C++. -Ofast allegedly does basically what '-release -noboundscheck' does. You'd never try and benchmark D code without those flags.
But other languages are very fast without loosing the bounds check... Other languages don't sacrifice safety and yet are very performant.
It's also not a ref-counting benchmark. BTW, just pushed a new optimization to dmd's back end that dramatically reduces the number of bounds checks. But that won't help with ref-counting, either.
Jun 16 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/16/2014 8:57 PM, Ary Borenszweig wrote:
 On 6/16/14, 9:22 PM, Manu via Digitalmars-d wrote:
 On 17 June 2014 10:08, deadalnix via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On Monday, 16 June 2014 at 15:16:44 UTC, Manu via Digitalmars-d wrote:
 What say you to that, Walter?

 Apple have committed to pervasive ARC, which you consistently argue is
 not feasible...
 Have I missed something, or is this a demonstration that it is
 actually practical?
http://stackoverflow.com/questions/24101718/swift-performance-sorting-arrays Does it answer the question ?
-Ofast seems to perform the same as C++. -Ofast allegedly does basically what '-release -noboundscheck' does. You'd never try and benchmark D code without those flags.
But other languages are very fast without loosing the bounds check... Other languages don't sacrifice safety and yet are very performant.
Well, I think interesting part we're trying to look at here is the ARC's impact on speed. We already know bounds-/overflow-checks can slow things down, so I'm not sure the -O3 and -O0 timings are relevant to the analysis of ARC's impact. (If anything, I have a hunch they're more indicative of Swift's current immaturity.) But, the comments in that thread seem to suggest that -Ofast *keeps* the ARC. If that's so, then the -Ofast timings seem to suggest ARC might not necessarily be a performance killer. Although direct side-by-side comparison with a D equivalent (or an otherwise no-ARC version) would be more meaningful.
Jun 16 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky wrote:
 Well, I think interesting part we're trying to look at here is 
 the ARC's impact on speed.
ARC without deep whole program analysis is bound to be slow. It turns reads into writes. You even have to do writes to access read-only data-structures that will never be freed, due to separate compilation units. ARC with multi-threading (and without language level transactions) is even worse. If you restrict ARC to thread-only then you might as well try to implement thread-local GC too. Sure, with single thread restrictions, deep semantic analysis and heavy "templating" of functions you can get low overhead by inferring "borrowed pointer semantics" in the call tree, after taking ownership of an object, and let it propagate down the call chain. But to get there you also need to deal with aggregates and arrays, so you need to take "over-reaching" ownership (e.g. take ownership of the entire array, graph or large struct) to avoid ref-counting every single pointer in the array/aggregate.
 We already know bounds-/overflow-checks can slow things down, 
 so I'm not sure the -O3 and -O0 timings are relevant to the 
 analysis of ARC's impact. (If anything, I have a hunch they're 
 more indicative of Swift's current immaturity.)
I somehow suspect that Apple is content if they can bring Swift within 10-20% of Objective-C's performance, which isn't impressive to begin with. The goal is to get programmers more productive, having a REPL etc. Swift's main competitors are ECMAScript6, Dart, HTML5 and cross-platform mobile scripting frameworks. JITs are now at about 40-20% of raw C speed, with multiple JITs to get fast spin-up time, that's good enough for most apps and even most of the code in an average mobile game. When devs go that route, in order to cut costs, then iOS loose out on iOS-only apps. The surge in mobile CPU/GPU processing power makes that a real threat since a yesterdays C app that runs on a 2-4x faster CPU can be implemented in a scripting language with comparable performance. So Apple needs to cut dev costs for apps and Swift is a very attractive solution. Swift will probably never get the speed enhancements that involve challenging semantics due to the desire to keep the language simple (so businesses can hire cheaper programmers). That's the main motivation for having ARC everywhere IMO. With Swift Apple can provide better tooling, not C/C++ level performance.
Jun 16 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/17/2014 2:56 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky wrote:
 Well, I think interesting part we're trying to look at here is the
 ARC's impact on speed.
ARC without deep whole program analysis is bound to be slow.[...]
Right, but what I'm mainly curious about is "How much slower?" Depending how the numbers play out, then as Manu has mentioned, it could be that the relaxed memory requirements and amortized cost are enough to make it a good tradeoff for a lot of people (Like Manu, I have some interest in soft-realtime as well). But I'm new to ARC, never even used ObjC, so I don't really even have much frame of reference or ballpark ideas here. So that's why I'm interested in the whole "How much slower?" Your descriptions of the ins and outs of it, and Apple's motivations, are definitely interesting. But even if nothing else, Manu's certainly right about one thing: What we need is some hard empirical data.
Jun 17 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 17 June 2014 at 08:36:10 UTC, Nick Sabalausky wrote:
 But even if nothing else, Manu's certainly right about one 
 thing: What we need is some hard empirical data.
Sure. Empirical data is needed on many levels: 1. How fast can you get the GC if you exploit all possibilities for semantic annotations or even constrain existing semantics? 2. How fast can you get the GC if you segment the collection (by thread, type, clustering of objects etc) and how does that affect semantics? 3. How fast can you get the GC if you change memory layout etc in order to limit the amount of touched cache lines? 4. How fast can you make transaction-based multithreading when you have Haswell-style hardware support in the CPU cache? 5. How far can you get by using region based allocators inferred by semantic analysis? 6. Can you exploit bit patterns on 64-but architectures if you provide your own malloc? 7. How far can you get by having type-based pools? 8. Can you deal with multiple pointer types if everyting is templated and then reduced by "de-foresting" of the AST (like common sub-expression elimination)? I think D2 has too many competing features to experiment, so an experimental D-- implemented in D2 would be most interesting IMO. But it takes a group effort… :-/
Jun 17 2014
parent reply "Araq" <rumpf_a web.de> writes:
 I think D2 has too many competing features to experiment, so an 
 experimental D-- implemented in D2 would be most interesting 
 IMO. But it takes a group effort… :-/
What's the point? Nimrod already exists and answers most of your questions. If only you would know how to ask...
Jun 17 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 17 June 2014 at 09:24:32 UTC, Araq wrote:
 What's the point? Nimrod already exists and answers most of your
 questions. If only you would know how to ask...
If you know the answers then I am an eager listener. Go ahead! :-) But isn't Nimrod a source-2-source compiler/translator? In order to get efficient heap, GC, exception handling etc you need to go all the way down to exploiting the underlying hardware and memory layout on modern 64-bit architectures and leave some of the C-cruft behind. It basically requires runtime and backend-level changes. You can get there by experimenting with one feature at the time, but if you add all features at once you lock yourself into a corner, IMO. So having a minimal and clean C-ish base as a starting point would be valuable.
Jun 17 2014
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 17 June 2014 18:36, Nick Sabalausky via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 6/17/2014 2:56 AM, "Ola Fosheim Grøstad"
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky wrote:
 Well, I think interesting part we're trying to look at here is the
 ARC's impact on speed.
ARC without deep whole program analysis is bound to be slow.[...]
Right, but what I'm mainly curious about is "How much slower?" Depending how the numbers play out, then as Manu has mentioned, it could be that the relaxed memory requirements and amortized cost are enough to make it a good tradeoff for a lot of people (Like Manu, I have some interest in soft-realtime as well). But I'm new to ARC, never even used ObjC, so I don't really even have much frame of reference or ballpark ideas here. So that's why I'm interested in the whole "How much slower?" Your descriptions of the ins and outs of it, and Apple's motivations, are definitely interesting. But even if nothing else, Manu's certainly right about one thing: What we need is some hard empirical data.
Andrei posted a document some time back comparing an advanced RC implementation with "the best GC", and it performed remarkably well, within 10%! D does not have 'the best GC'. I doubt D's GC is within 10% of 'the best GC'. In addition, my colleagues have reported no significant pain working with ARC on iOS, whereas Android developers are always crying about the GC by contrast. I can visualise Walter's criticisms, but what I don't know is whether his criticisms are actually as costly as they may seem? I also haven't seen the compilers ability to eliminate or simplify that work, and the circumstances in which it fails. It's conceivable that simply rearranging an access pattern slightly may offer the compiler the structure it needs to properly eliminate the redundant work. The thing is, I don't know! I really don't know, and I don't know any practical way to experiment with this. D theoretically offers many opportunities for ARC optimisation that other languages don't via it's rich type system, so direct comparisons via O-C could probably be reasonably considered to be quite conservative. Here's what I do know though; nobody has offered conception of a GC that may be acceptable on a memory limited device, and it's also not very acceptable just by nature (destructors are completely broken; cost). As far as I know, there is NO OTHER CHOICE. Either somebody invents the fantasy GC, or we actually *experiment* with ARC... We know: GC is unacceptable, and nobody has any idea how to make one that is. We don't know: ARC is acceptable/unacceptable. Why. What other position can I take on this issue?
Jun 17 2014
next sibling parent "ed" <gmail gmail.com> writes:
On Tuesday, 17 June 2014 at 11:59:23 UTC, Manu via Digitalmars-d 
wrote:
 On 17 June 2014 18:36, Nick Sabalausky via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On 6/17/2014 2:56 AM, "Ola Fosheim Grøstad"
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky 
 wrote:
 Well, I think interesting part we're trying to look at here 
 is the
 ARC's impact on speed.
ARC without deep whole program analysis is bound to be slow.[...]
Right, but what I'm mainly curious about is "How much slower?" Depending how the numbers play out, then as Manu has mentioned, it could be that the relaxed memory requirements and amortized cost are enough to make it a good tradeoff for a lot of people (Like Manu, I have some interest in soft-realtime as well). But I'm new to ARC, never even used ObjC, so I don't really even have much frame of reference or ballpark ideas here. So that's why I'm interested in the whole "How much slower?" Your descriptions of the ins and outs of it, and Apple's motivations, are definitely interesting. But even if nothing else, Manu's certainly right about one thing: What we need is some hard empirical data.
Andrei posted a document some time back comparing an advanced RC implementation with "the best GC", and it performed remarkably well, within 10%! D does not have 'the best GC'. I doubt D's GC is within 10% of 'the best GC'. In addition, my colleagues have reported no significant pain working with ARC on iOS, whereas Android developers are always crying about the GC by contrast. I can visualise Walter's criticisms, but what I don't know is whether his criticisms are actually as costly as they may seem? I also haven't seen the compilers ability to eliminate or simplify that work, and the circumstances in which it fails. It's conceivable that simply rearranging an access pattern slightly may offer the compiler the structure it needs to properly eliminate the redundant work. The thing is, I don't know! I really don't know, and I don't know any practical way to experiment with this. D theoretically offers many opportunities for ARC optimisation that other languages don't via it's rich type system, so direct comparisons via O-C could probably be reasonably considered to be quite conservative. Here's what I do know though; nobody has offered conception of a GC that may be acceptable on a memory limited device, and it's also not very acceptable just by nature (destructors are completely broken; amortised cost). As far as I know, there is NO OTHER CHOICE. Either somebody invents the fantasy GC, or we actually *experiment* with ARC... We know: GC is unacceptable, and nobody has any idea how to make one that is. We don't know: ARC is acceptable/unacceptable. Why. What other position can I take on this issue?
Check out the compiler and start the experiment you keep talking about. Cheers, ed
Jun 17 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/17/2014 4:59 AM, Manu via Digitalmars-d wrote:
 What other position can I take on this issue?
Instead of taking positions, you can do some research. Understand how shared_ptr works and what it costs, for starters. Try out Rust/Swift, disassemble the code, and try to understand the tradeoffs those languages make.
Jun 17 2014
prev sibling parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 17/06/14 13:59, Manu via Digitalmars-d wrote:
 The thing is, I don't know! I really don't know, and I don't know any
 practical way to experiment with this. D theoretically offers many
 opportunities for ARC optimisation that other languages don't via it's
 rich type system, so direct comparisons via O-C could probably be
 reasonably considered to be quite conservative.

 Here's what I do know though; nobody has offered conception of a GC
 that may be acceptable on a memory limited device, and it's also not
 very acceptable just by nature (destructors are completely broken;

 cost).
 As far as I know, there is NO OTHER CHOICE.
 Either somebody invents the fantasy GC, or we actually *experiment* with ARC...

 We know: GC is unacceptable, and nobody has any idea how to make one that is.
 We don't know: ARC is acceptable/unacceptable. Why.

 What other position can I take on this issue?
I'm broadly sympathetic with your position here, but I think to be honest the only real answer is: the other position you can take is to grab the compiler sources and implement the support that you want to see. I understand if you're worried that it might be a big investment of time and effort with uncertain prospects of acceptance, but I'm sure that if you were able to demonstrate something working effectively, it would shift the terms of the debate dramatically.
Jun 17 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/17/2014 2:47 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
 but I think to be honest the
 only real answer is: the other position you can take is to grab the compiler
 sources and implement the support that you want to see.
There's another way. Simply write the code that a hypothetical ARC would generate, and then compile/test it.
Jun 17 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 17, 2014 at 06:56:11AM +0000, via Digitalmars-d wrote:
 On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky wrote:
Well, I think interesting part we're trying to look at here is the ARC's
impact on speed.
ARC without deep whole program analysis is bound to be slow.
[...] But isn't whole program analysis impractical with D's separate compilation model? T -- My program has no bugs! Only unintentional features...
Jun 17 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/17/2014 12:13 PM, H. S. Teoh via Digitalmars-d wrote:
 On Tue, Jun 17, 2014 at 06:56:11AM +0000, via Digitalmars-d wrote:
 On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky wrote:
 Well, I think interesting part we're trying to look at here is the ARC's
 impact on speed.
ARC without deep whole program analysis is bound to be slow.
[...] But isn't whole program analysis impractical with D's separate compilation model?
I think that's exactly the concern he's voicing. Limitations of the separate compilation model have come up before. For example, the inability to retrieve all the subclasses of a base class. Pretty sure there's been others, too. Since whole-program-at-once *is* a common way to use D, I've always felt that (issues of manpower aside, of course) whole-program-at-once users shouldn't necessarily be robbed of abilities just because *other* projects can't use them due to their own usage of separate-compilation. Sometimes things are mutually exclusive. Doesn't mean we can't let the user choose their tradeoffs for themselves. But that's kinda venturing off onto a tangent.
Jun 17 2014
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 17 Jun 2014 13:55:33 -0400, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:

 Limitations of the separate compilation model have come up before. For  
 example, the inability to retrieve all the subclasses of a base class.
This is not an issue that can be solved by removing separate compilation. Dynamically loading objects could easily add to or remove from this list at runtime. -Steve
Jun 17 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 17 June 2014 at 16:15:27 UTC, H. S. Teoh via
Digitalmars-d wrote:
 On Tue, Jun 17, 2014 at 06:56:11AM +0000, via Digitalmars-d 
 wrote:
 On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky 
 wrote:
Well, I think interesting part we're trying to look at here 
is the ARC's
impact on speed.
ARC without deep whole program analysis is bound to be slow.
[...] But isn't whole program analysis impractical with D's separate compilation model? T
It is certainly doable in release build, granted one have a powerful enough computer. Probably no realistic for fast, debug builds.
Jun 17 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 17, 2014 at 06:04:56PM +0000, deadalnix via Digitalmars-d wrote:
 On Tuesday, 17 June 2014 at 16:15:27 UTC, H. S. Teoh via
 Digitalmars-d wrote:
On Tue, Jun 17, 2014 at 06:56:11AM +0000, via Digitalmars-d wrote:
On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky wrote:
Well, I think interesting part we're trying to look at here is the
ARC's impact on speed.
ARC without deep whole program analysis is bound to be slow.
[...] But isn't whole program analysis impractical with D's separate compilation model? T
It is certainly doable in release build, granted one have a powerful enough computer. Probably no realistic for fast, debug builds.
Well, first we need an option to turn on the GC in dmd... ;-) Otherwise we'll run out of memory as soon as std.algorithm is involved. :-P Frankly, I think dmd should enable its GC when compiling for -release; it's the release build, you aren't expecting a fast code-compile-test cycle anymore, and you probably want maximum optimization, so why not take the time to conserve memory that can be used for other things, like whole-program optimization, or a longer but more powerful optimization pass? --T
Jun 17 2014
prev sibling parent reply "w0rp" <devw0rp gmail.com> writes:
On Tuesday, 17 June 2014 at 00:22:55 UTC, Manu via Digitalmars-d 
wrote:
 On 17 June 2014 10:08, deadalnix via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On Monday, 16 June 2014 at 15:16:44 UTC, Manu via 
 Digitalmars-d wrote:
 What say you to that, Walter?

 Apple have committed to pervasive ARC, which you consistently 
 argue is
 not feasible...
 Have I missed something, or is this a demonstration that it is
 actually practical?
http://stackoverflow.com/questions/24101718/swift-performance-sorting-arrays Does it answer the question ?
-Ofast seems to perform the same as C++. -Ofast allegedly does basically what '-release -noboundscheck' does. You'd never try and benchmark D code without those flags.
The thing which slowed his loop down was the compiler not removing the retain and release calls for ARC in that case. As he says.
 With -O3 I get something that was beyond my wildest 
 imagination. The inner loop spans 88 lines of assembly code. I 
 did not try to understand all of it, but the most suspicious 
 parts are 13 invocations of "callq _swift_retain" and another 
 13 invocations of "callq _swift_release". That is, 26 
 subroutine calls in the inner loop!
Obviously they can optimise these retain and release calls away. However, I don't believe it will work with the right optimisations in place for hot code. I think the only thing which can work reliably in hot code is memory you manage yourself. I don't think there's an automatic memory management scheme which will do all of the work for you in most situations without incurring some additional runtime cost.
Jun 17 2014
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 17 June 2014 22:26, w0rp via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Tuesday, 17 June 2014 at 00:22:55 UTC, Manu via Digitalmars-d wrote:
 -Ofast seems to perform the same as C++. -Ofast allegedly does
 basically what '-release -noboundscheck' does. You'd never try and
 benchmark D code without those flags.
The thing which slowed his loop down was the compiler not removing the retain and release calls for ARC in that case. As he says.
 With -O3 I get something that was beyond my wildest imagination. The inner
 loop spans 88 lines of assembly code. I did not try to understand all of it,
 but the most suspicious parts are 13 invocations of "callq _swift_retain"
 and another 13 invocations of "callq _swift_release". That is, 26 subroutine
 calls in the inner loop!
Obviously they can optimise these retain and release calls away. However, I don't believe it will work with the right optimisations in place for hot code.
Huh? I'm not sure what you mean? But yes, it appears that -Ofast enabled RC optimisations, which seems like an important optimisation for an ARC based language.
 I think the only thing which can work reliably in hot code is memory
 you manage yourself. I don't think there's an automatic memory management
 scheme which will do all of the work for you in most situations without
 incurring some additional runtime cost.
Maybe. But 'hot' code would never be crafted so carelessly. It's very easy to refactor reference capturing outside of loops. It would become second nature in no time if it was a requirement for good performance.
Jun 17 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 16/06/14 17:16, Manu via Digitalmars-d wrote:
 What say you to that, Walter?

 Apple have committed to pervasive ARC, which you consistently argue is
 not feasible...
 Have I missed something, or is this a demonstration that it is
 actually practical?
I think Swift is only intended for high level application development. It doesn't feel like a true systems or general purpose language. -- /Jacob Carlborg
Jun 17 2014
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 17 June 2014 at 12:10:13 UTC, Jacob Carlborg wrote:
 On 16/06/14 17:16, Manu via Digitalmars-d wrote:
 What say you to that, Walter?

 Apple have committed to pervasive ARC, which you consistently 
 argue is
 not feasible...
 Have I missed something, or is this a demonstration that it is
 actually practical?
I think Swift is only intended for high level application development. It doesn't feel like a true systems or general purpose language.
Why not? It enjoys feature parity with Objective-C and then some. You want to do typical unsafe C style coding when required to do so, it is possible: https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithCAPIs.html#//apple_ref/doc/uid/TP40014216-CH8-XID_13 -- Paulo
Jun 17 2014