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.
