Re: iPhone vs Android

On Wed, 14 Sep 2016 13:37:03 +, Laeeth Isharc wrote: > On Wednesday, 14 September 2016 at 13:28:45 UTC, finalpatch wrote: >> On Tuesday, 13 September 2016 at 18:24:26 UTC, deadalnix wrote: >>> No you don't, as how often the GC kicks in depend of the rate at which >>> you produce garbage,

Re: iPhone vs Android

On Monday, 12 September 2016 at 22:57:23 UTC, Andrei Alexandrescu wrote: [snip] If it is, that provides more impetus for reference counting for D by the following logic: (a) it is likely that in the future more code will run on portable, battery-powered systems; (b) battery power does not

Re: iPhone vs Android

On Tuesday, 13 September 2016 at 17:59:52 UTC, Andrei Alexandrescu wrote: So do you agree you were wrong in positing 2x as the rule of thumb? I didn't look into how he connects perceived application performance with collection frequency.

Re: iPhone vs Android

On Wednesday, 14 September 2016 at 14:43:29 UTC, H. S. Teoh wrote: Honestly, I've never actually run across a real-life case where chained exceptions matter. Most of the code (that I work with, anyway) involve simply throwing an exception when some problem occurs, and the catch block simply

Re: iPhone vs Android

On 14/09/16 16:49, Laeeth Isharc wrote: In D code that I have read where people use RC types they have different names making it quite clear - eg RCString.but I find the suggestion that the compiler make code generation decisions based on type names not one I would gladly see happen. If

Re: iPhone vs Android

On Wednesday, 14 September 2016 at 13:28:45 UTC, finalpatch wrote: On Tuesday, 13 September 2016 at 18:24:26 UTC, deadalnix wrote: No you don't, as how often the GC kicks in depend of the rate at which you produce garbage, which is going to be very low with an hybrid approach. This is simply

Re: iPhone vs Android

On Wednesday, 14 September 2016 at 07:55:24 UTC, John Colvin wrote: On Tuesday, 13 September 2016 at 22:28:09 UTC, deadalnix wrote: On Tuesday, 13 September 2016 at 22:19:54 UTC, Jonathan M Davis wrote: The big problem with exceptions being allocated by the GC isn't really the GC but @nogc.

Re: iPhone vs Android

On Wednesday, September 14, 2016 07:43:29 H. S. Teoh via Digitalmars-d wrote: > > But the fact that the workarounds either require that you don't have > > unique, independent exceptions or that you know that you need to > > manually free the exception after catching it is a serious problem. > >

Re: iPhone vs Android

On Wed, Sep 14, 2016 at 05:19:45AM -0700, Jonathan M Davis via Digitalmars-d wrote: > On Tuesday, September 13, 2016 16:13:05 H. S. Teoh via Digitalmars-d wrote: > > On Tue, Sep 13, 2016 at 03:19:54PM -0700, Jonathan M Davis via Digitalmars-d > > wrote: [...] > > > > > But none of the code that's

Re: iPhone vs Android

On Wednesday, 14 September 2016 at 06:33:59 UTC, Shachar Shemesh wrote: On 14/09/16 09:05, Walter Bright wrote: On 9/13/2016 10:38 PM, Shachar Shemesh wrote: But if you do want to allow it, then my original problem comes back. You have to scan the malloced memory because you are not sure

Re: iPhone vs Android

On Wednesday, 14 September 2016 at 13:28:45 UTC, finalpatch wrote: On Tuesday, 13 September 2016 at 18:24:26 UTC, deadalnix wrote: No you don't, as how often the GC kicks in depend of the rate at which you produce garbage, which is going to be very low with an hybrid approach. This is simply

Re: iPhone vs Android

On Tuesday, 13 September 2016 at 18:24:26 UTC, deadalnix wrote: No you don't, as how often the GC kicks in depend of the rate at which you produce garbage, which is going to be very low with an hybrid approach. This is simply not true. Assume in a pure GC program the GC heap can grow up to X

Re: iPhone vs Android

On Tuesday, September 13, 2016 16:13:05 H. S. Teoh via Digitalmars-d wrote: > On Tue, Sep 13, 2016 at 03:19:54PM -0700, Jonathan M Davis via Digitalmars-d > wrote: [...] > > > But none of the code that's marked @nogc can throw an exception unless > > you're either dealing with pre-allocated

Re: iPhone vs Android

On 2016-09-13 20:40, Steven Schveighoffer wrote: Swift doesn't support exceptions AFAIK. It supports weird error handling that looks similar to exceptions, but is really just a standard return. i.e. this: do { try someFunctionThatErrors(arg) } catch(Exception ex) { // handle ex }

Re: iPhone vs Android

On Wednesday, 14 September 2016 at 07:16:04 UTC, deadalnix wrote: On Wednesday, 14 September 2016 at 05:38:38 UTC, Shachar Shemesh wrote: On 14/09/16 02:59, Walter Bright wrote: [...] But if you do want to allow it, then my original problem comes back. You have to scan the malloced memory

Re: iPhone vs Android

On Tuesday, 13 September 2016 at 22:28:09 UTC, deadalnix wrote: On Tuesday, 13 September 2016 at 22:19:54 UTC, Jonathan M Davis wrote: The big problem with exceptions being allocated by the GC isn't really the GC but @nogc. No the problem IS @nogc . Allocating with the GC is absolutely not a

Re: iPhone vs Android

On Wednesday, 14 September 2016 at 05:38:38 UTC, Shachar Shemesh wrote: On 14/09/16 02:59, Walter Bright wrote: Memory allocated with malloc() is unknown to the GC. This works fine unless a reference to the GC memory is inserted into malloc'd data, which is why there's an API to the GC to

Re: iPhone vs Android

On 9/13/2016 10:38 PM, Shachar Shemesh wrote: But if you do want to allow it, then my original problem comes back. You have to scan the malloced memory because you are not sure where that memory might contain pointers to GC managed memory. If mallocing for types that are statically known at

Re: iPhone vs Android

On 14/09/16 02:59, Walter Bright wrote: Memory allocated with malloc() is unknown to the GC. This works fine unless a reference to the GC memory is inserted into malloc'd data, which is why there's an API to the GC to let it know about such things. But if you do want to allow it, then my

Re: iPhone vs Android

On 9/13/2016 6:09 PM, Andrei Alexandrescu wrote: On 09/13/2016 05:43 PM, Walter Bright wrote: There's currently nothing that would prevent any handler code from saving a reference to the thrown exception. Statically allocating them would break that. Didn't we reach the agreement to closely

Re: iPhone vs Android

On 09/13/2016 05:43 PM, Walter Bright wrote: The all-or-nothing approach to using the GC is as wrong as any programming methodology is. That's a bit much. There's currently nothing that would prevent any handler code from saving a reference to the thrown exception. Statically allocating them

Re: iPhone vs Android

On 9/13/2016 11:24 AM, deadalnix wrote: No you don't, as how often the GC kicks in depend of the rate at which you produce garbage, which is going to be very low with an hybrid approach. Also, if you only use GC for exceptions, there isn't going to be much memory it needs to scan.

Re: iPhone vs Android

On 9/13/2016 4:59 AM, Shachar Shemesh wrote: Here's my worries about the hybrid approach. The GC run time is proportional not to the amount of memory you manage with the GC, but to the amount of memory that might hold a pointer to a GC managed memory. In other words, if most of my memory is RC

Re: iPhone vs Android

On 9/13/2016 4:13 PM, H. S. Teoh via Digitalmars-d wrote: There's nothing about the 'throw' keyword that requires GC allocation. It's just that `throw new Exception(...)` has become a standard incantation. The exception object itself can, for example, be emplaced onto a static buffer as I

Re: iPhone vs Android

On Tuesday, 13 September 2016 at 19:30:16 UTC, Marco Leise wrote: Am Tue, 13 Sep 2016 18:16:27 + schrieb Laeeth Isharc : Thanks you for the clear explanation. So if you don't have GC allocations within RC structures and pick one or the other, then the

Re: iPhone vs Android

On Tuesday, 13 September 2016 at 22:19:54 UTC, Jonathan M Davis wrote: So, I really think that we need to find a way to make it so that exceptions aren't GC allocated normally anymore - or at least have a way to reasonably and easily not be GC allocated - but the problem is @nogc, not the

Re: iPhone vs Android

On Tue, Sep 13, 2016 at 03:19:54PM -0700, Jonathan M Davis via Digitalmars-d wrote: [...] > But none of the code that's marked @nogc can throw an exception unless > you're either dealing with pre-allocated exceptions (in which case, > they're less informative), I don't see why pre-allocated

Re: iPhone vs Android

On Tuesday, 13 September 2016 at 22:19:54 UTC, Jonathan M Davis wrote: The big problem with exceptions being allocated by the GC isn't really the GC but @nogc. No the problem IS @nogc . Allocating with the GC is absolutely not a problem is you deallocate properly. What is a problem is when

Re: iPhone vs Android

On Tuesday, September 13, 2016 14:43:09 Walter Bright via Digitalmars-d wrote: > Case in point, exceptions. Currently exceptions are fairly wedded to being > GC allocated. Some people have opined that this is a major problem, and it > is if the app is throwing a lot of exceptions. But exceptions

Re: iPhone vs Android

On Tuesday, 13 September 2016 at 20:19:40 UTC, Jonathan M Davis wrote: LOL. It's on my unfinished projects list, so I intend to complete it at some point, but unfortunately, it's been on the backburner for a while. Still, it's funny that you say that considering how many typos were in that

Re: iPhone vs Android

On 9/13/2016 10:44 AM, Jonathan M Davis via Digitalmars-d wrote: Folks have posted here before about taking that approach with games and the like that they've written. In a number cases, simply being careful about specific pieces of code and avoiding the GC in those cases was enough to get the

Re: iPhone vs Android

On Tuesday, September 13, 2016 18:50:20 jmh530 via Digitalmars-d wrote: > On Tuesday, 13 September 2016 at 18:04:19 UTC, Jonathan M Davis > > wrote: > > As I understand it, [snnip] > > If you ever write a book, I would pre-order it. LOL. It's on my unfinished projects list, so I intend to

Re: iPhone vs Android

Am Tue, 13 Sep 2016 18:16:27 + schrieb Laeeth Isharc : > Thanks you for the clear explanation. So if you don't have GC > allocations within RC structures and pick one or the other, then > the concern does not apply? That's right. Often such structures

Re: iPhone vs Android

On Tuesday, 13 September 2016 at 18:04:19 UTC, Jonathan M Davis wrote: As I understand it, [snnip] If you ever write a book, I would pre-order it.

Re: iPhone vs Android

On 9/13/16 2:24 PM, deadalnix wrote: This is why ObjC exeption handling and ARC never worked well together. This is why C++ exception are dog slow and this is why Swift is nothrow by default. Swift doesn't support exceptions AFAIK. It supports weird error handling that looks similar to

Re: iPhone vs Android

On Tuesday, 13 September 2016 at 11:59:46 UTC, Shachar Shemesh wrote: On 13/09/16 02:21, deadalnix wrote: RC itself is not panacea, it doesn't work well with exceptions, generate a huge amount of code bloat, I will need explanation to those two. Assuming we have RAII, why doesn't RC work

Re: iPhone vs Android

On Tuesday, 13 September 2016 at 18:04:19 UTC, Jonathan M Davis wrote: On Tuesday, September 13, 2016 17:48:38 Laeeth Isharc via Digitalmars-d wrote: On Tuesday, 13 September 2016 at 11:59:46 UTC, Shachar Shemesh wrote: > On 13/09/16 02:21, deadalnix wrote: >> I stay convinced that an hybrid

Re: iPhone vs Android

On 9/13/16 1:51 PM, deadalnix wrote: On Tuesday, 13 September 2016 at 10:04:43 UTC, Andrei Alexandrescu wrote: On 9/13/16 3:53 AM, Kagamin wrote: The rule of thumb is that for efficient operation an advanced GC consumes twice the used memory. Do you have a citation? The number I know is 3x

Re: iPhone vs Android

On Tuesday, September 13, 2016 17:48:38 Laeeth Isharc via Digitalmars-d wrote: > On Tuesday, 13 September 2016 at 11:59:46 UTC, Shachar Shemesh > > wrote: > > On 13/09/16 02:21, deadalnix wrote: > >> I stay convinced that an hybrid approach is inevitable and am > >> surprised > >> why few are

Re: iPhone vs Android

On 9/13/16 11:58 AM, Kagamin wrote: On Tuesday, 13 September 2016 at 10:04:43 UTC, Andrei Alexandrescu wrote: Do you have a citation? The number I know is 3x from Emery Berger's (old) work. -- Andrei http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ This suggests the ratio is 4x

Re: iPhone vs Android

On Tuesday, 13 September 2016 at 10:04:43 UTC, Andrei Alexandrescu wrote: On 9/13/16 3:53 AM, Kagamin wrote: The rule of thumb is that for efficient operation an advanced GC consumes twice the used memory. Do you have a citation? The number I know is 3x from Emery Berger's (old) work. --

Re: iPhone vs Android

On Tuesday, 13 September 2016 at 11:59:46 UTC, Shachar Shemesh wrote: On 13/09/16 02:21, deadalnix wrote: I stay convinced that an hybrid approach is inevitable and am surprised why few are going there (hello PHP, here right). Here's my worries about the hybrid approach. The GC run time

Re: iPhone vs Android

On Tuesday, September 13, 2016 03:58:50 Walter Bright via Digitalmars-d wrote: > On 9/12/2016 4:21 PM, deadalnix wrote: > > I stay convinced that an hybrid approach is inevitable and am surprised > > why few are going there (hello PHP, here is a thing you get right). > > Interestingly, Warp (the C

Re: iPhone vs Android

On Tuesday, 13 September 2016 at 10:04:43 UTC, Andrei Alexandrescu wrote: Do you have a citation? The number I know is 3x from Emery Berger's (old) work. -- Andrei http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ http://www-cs.canisius.edu/~hertzm/gcmalloc-oopsla-2005.pdf Probably

Re: iPhone vs Android

On Tuesday, 13 September 2016 at 10:04:43 UTC, Andrei Alexandrescu wrote: Do you have a citation? The number I know is 3x from Emery Berger's (old) work. -- Andrei IIRC there was a thread about GC here where somebody posted a bunch of links to resources and benchmarks.

Re: iPhone vs Android

On 13/09/16 02:21, deadalnix wrote: RC itself is not panacea, it doesn't work well with exceptions, generate a huge amount of code bloat, I will need explanation to those two. Assuming we have RAII, why doesn't RC work well with exceptions? Also, please note that explicit memory management

Re: iPhone vs Android

On Tuesday, 13 September 2016 at 10:58:50 UTC, Walter Bright wrote: Interestingly, Warp (the C preprocessor I developed in D) used a hybrid approach. The performance critical code was all hand-managed, while the rest was GC'd. Manual Memory management is key for performance oriented code.

Re: iPhone vs Android

On 9/12/2016 4:21 PM, deadalnix wrote: I stay convinced that an hybrid approach is inevitable and am surprised why few are going there (hello PHP, here is a thing you get right). Interestingly, Warp (the C preprocessor I developed in D) used a hybrid approach. The performance critical code

Re: iPhone vs Android

On 9/13/16 3:53 AM, Kagamin wrote: The rule of thumb is that for efficient operation an advanced GC consumes twice the used memory. Do you have a citation? The number I know is 3x from Emery Berger's (old) work. -- Andrei

Re: iPhone vs Android

I think the conclusions about iOS vs. Android OS-level memory collection are not applicable to D GC discussion. An OS collects all the memory pages allocated for a process upon exit - no heap scan, no RC. It more resembles a one huge free() call. The discussion is mainly about eager vs.

Re: iPhone vs Android

On Monday, 12 September 2016 at 22:57:23 UTC, Andrei Alexandrescu wrote: An interesting article written for laypeople: http://www.theverge.com/2016/9/12/12886058/iphone-7-specs-competition One quote that may be of relevance to us: "As to the iPhone’s memory, this is more of a philosophical

Re: iPhone vs Android

On Monday, 12 September 2016 at 22:57:23 UTC, Andrei Alexandrescu wrote: It follows that the latter needs more memory for the same performance, and is more jerky in behavior than the former. Wondering to what extent this is true. The rule of thumb is that for efficient operation an advanced

Re: iPhone vs Android

On Tuesday, 13 September 2016 at 01:04:06 UTC, Joakim wrote: https://www.engadget.com/2016/08/19/smartphone-batteries-with-twice-the-life-may-arrive-in-2017/ https://www.engadget.com/2016/04/22/accidental-discovery-batteries-last-years-longer/ The battery industry is king to drum up various

Re: iPhone vs Android

On Monday, 12 September 2016 at 22:57:23 UTC, Andrei Alexandrescu wrote: (a) it is likely that in the future more code will run on portable, battery-powered systems; Completely agree, it's why I've been working on the Android port. (b) battery power does not follow a Moore trajectory, so at

Re: iPhone vs Android

On Monday, 12 September 2016 at 23:21:12 UTC, deadalnix wrote: RC itself is not panacea, it doesn't work well with exceptions, generate a huge amount of code bloat, hurt throughput, which you don't care in UI thread, but do care in the backend, and so on. But first and foremost, it is a

Re: iPhone vs Android

On Monday, 12 September 2016 at 22:57:23 UTC, Andrei Alexandrescu wrote: This may be interpreted as follows: the iPhone uses native apps with reference counting I think the native part is fair, but the RC part maybe not. I know first hand that they have a fair amount of problem on the side.

Re: iPhone vs Android

On Monday, 12 September 2016 at 22:57:23 UTC, Andrei Alexandrescu wrote: An interesting article written for laypeople: http://www.theverge.com/2016/9/12/12886058/iphone-7-specs-competition One quote that may be of relevance to us: "As to the iPhone’s memory, this is more of a philosophical

iPhone vs Android

An interesting article written for laypeople: http://www.theverge.com/2016/9/12/12886058/iphone-7-specs-competition One quote that may be of relevance to us: "As to the iPhone’s memory, this is more of a philosophical distinction between Apple and Google. The former is neurotic about killing