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 background processes and dumping background apps from memory in iOS, whereas the latter is more liberal with app management in Android (though Google is gradually moving toward the Apple way of doing things). The upshot is that an iPhone can feel super smooth and responsive with half the RAM of an Android device. RAM consumes power, so having less of it is another factor contributing to the iPhone’s efficiency lead."

This may be interpreted as follows: the iPhone uses native apps with reference counting whereas the Android uses a virtual machine with tracing garbage collection. 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. 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 follow a Moore trajectory, so at this point in history demand for battery lifetime is elastic.


Andrei

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 distinction between Apple and Google. The former is neurotic about killing background processes and dumping background apps from memory in iOS, whereas the latter is more liberal with app management in Android (though Google is gradually moving toward the Apple way of doing things). The upshot is that an iPhone can feel super smooth and responsive with half the RAM of an Android device. RAM consumes power, so having less of it is another factor contributing to the iPhone’s efficiency lead."
>
> This may be interpreted as follows: the iPhone uses native apps with reference counting whereas the Android uses a virtual machine with tracing garbage collection. 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. 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 follow a Moore trajectory, so at this point in history demand for battery lifetime is elastic.
>
>
> Andrei

I would interpret it quite differently to this.
On iOS applications that are not currently in the foreground or are a service get killed unconditionally.
On Android applications keep running even when they are no longer foreground but instead get 'paused'. Here is a handy little graph of the different events an Android app can be in[0]. Note the difference between onPause and onStop.

[0] https://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle

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.

> whereas the Android uses a virtual machine with tracing garbage collection.

Dalvik's GC is truly horrible and Java is addicted to memory allocations, which makes it worse. A match made in hell.

> It follows that the latter needs more memory for the same performance,
> and is more jerky in behavior than the former.

Putting a stop the world GC in a UI program is the worst idea ever. Doing this java is giving steroïd to the worse idea ever. I have no idea what Google was thnking here.

> Wondering to what extent this is true. 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 follow a Moore trajectory, so at this point in history demand for battery lifetime is elastic.
>

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 disaster for shared data.

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).

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 disaster for shared data.
>
> 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).

I quite agree with the hybrid approach.
My rule of thumb is if it is short lived its "managed" but if it can last a long time use the GC.

Ok so my managed memory concept auto deallocates as any ref counting solution should do. So for short lived memory, this is perfect since it isn't being moved around much and you can afford it.
But for long lived references such as a window you really want the default to be that you specifically tell it to deallocate at a set point in time you know it should.

For reference, SPEW's UI creation manager[0] and screenshot feature[1].

[0] https://github.com/Devisualization/spew/blob/master/src/base/cf/spew/instance.d#L72
[1]  https://github.com/Devisualization/spew/blob/master/src/base/cf/spew/ui/window/features/screenshot.d#L26

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 this point in history demand for battery lifetime is elastic.

Not Moore, but you never know what is around the bend:

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/

But yes, Moore's law is hitting fundamental limits and batteries will never match that growth curve, so efficiency will be at a premium in the coming years.

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 techs in very misleading ways. What you want is higher power density, and this is specifically the metric that hasn't been improving that much.

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 GC consumes twice the used memory. Also without card marking D GC scans entire heap every collection, which adds to energy consumption. I'm leaning towards arena allocator.

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 distinction between Apple and Google. The former is neurotic about killing background processes and dumping background apps from memory in iOS, whereas the latter is more liberal with app management in Android (though Google is gradually moving toward the Apple way of doing things). The upshot is that an iPhone can feel super smooth and responsive with half the RAM of an Android device. RAM consumes power, so having less of it is another factor contributing to the iPhone’s efficiency lead."
>
> This may be interpreted as follows: the iPhone uses native apps with reference counting whereas the Android uses a virtual machine with tracing garbage collection. 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. 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 follow a Moore trajectory, so at this point in history demand for battery lifetime is elastic.
>
>
> Andrei

Just some update on your information, the Android story is much more complicated than having  VM.

They had a VM up to version 5.0, afterwards Java bytecode (actually Dex) is compiled to native code at installation time, then there is just the language runtime, just like D.

Now with Android 7, due to the big compilation times, specially when large applications need to be updated, they have an hybrid design. An interpreter written in Assembly that makes use of a JIT for hot code, then the JIT makes use of PGO and when the device is plugged and charging, the hot code will be AOT compiled to native code and never JITed or interpreted again until a new update takes place.

Likewise the GC algorithm in Dalvik is pretty lame, even some J2ME JVMs do better than it.

However that was changed in ART, updated in Android 6.0 and changed again in Android 7.0.

So it is not easy just to say Android works like X, because X depends on the Android version and OEM build, as some of them do also change the AOSP runtime and compilers behaviors.

Also for additional comparison, the Windows Phone also has a mix of RC (WinRT now renamed as UWP) and GC (.NET Native / Chackra JavaScript VM), yet the devices perform much better than similar Android devices.

Also Microsoft does a full AOT build to native code on the WP Store, instead of using the consumer devices for AOT compilation like Google does.

So it is not that easy to generalize the OS behaviors like the article does.

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. less-eager not-currently-running process killing strategy.
D's GC lies in a different plane ...

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