5 ms·

Why 1GB RAM in iOS Gives at Par Performance with 3GB Android Phone?

14 points by sourcex 12y ago

dozzie 12y ago
Simple: because of Java.
- informatimago 12y ago
  You could (try to) write coarser grained classes in Java too (granted, with static typing, it may be harder to do).
- CmonDev 12y ago
  Java or Dalvik?
paines 12y ago
BSD-ish vs Linux Kernel ?
ParvusPonte 12y ago
Better memory usage due to the (BSD-like) kernel, vs Linux could be one of the factors. "My server earlier used to consume over 1 GB of memory for running PHP, MySQL and Nginx. Now, it doesn’t even touch 500 MB! It’s always less than 500 MB. Everything is just same, configuration, etc. Only OS changed." http://nileshgr.com/2013/06/07/the-move-from-linux-to-freebsd http://nileshgr.com/2013/06/07/the-move-from-linux-to-freebs... Slightly off topic but I really wish mainstream VPS providers start adopting FreeBSD, perhaps http://labs.online.net/ http://labs.online.net/ can spark that change, I'd move from Digital Ocean in a heart beat!
- informatimago 12y ago
  Well, MacOSX and iOS don't have a BSD kernel (or even a BSD-like kernel) at all. They have a Mach kernel. They have howewver, a BSD-like userland and kernel personality. But I guess we can assume that the Mach kernel is also more frugal than Linux. In any case, AFAICS, Apple takes some care about this, because of the performance and user experience consequences.
barrystaes 12y ago
There is only 1GB of ram in iPads? This explains why the browser keeps crashing when i keep 20 tabs open.. jeez!
vlad 12y ago
Besides reasons mentioned in this topic, Apple's desktop and mobile operating systems feature memory compression and other algorithms to save memory and battery life for the last year, since Mavericks and iOS 7. http://www.umass.edu/newsoffice/article/key-features-apple%E2%80%99s-new-operating-system http://www.umass.edu/newsoffice/article/key-features-apple%E...
vardump 12y ago
I think Java's issue is not really due to garbage collection directly, but overuse of references (pointers) leading to very complicated object graphs. This in turn leads to a lot of pointer chasing, cache thrashing and typically significantly higher memory requirements. It's sad how bad reputation this has "earned" for garbage collection in general. Even with just a few CPU cores, if you tried to emulate a similar number of object pointers by using reference counting instead of garbage collection, I believe it'd be at least by an order of magnitude slower than modern GC algorithms. With tens of CPU cores, reference counting would get almost no actual work done. Garbage collection would outperform it by a very large margin. Manual memory management wouldn't fare much better, because memory allocation is glacial: "malloc" (and often also "free") are very slow. Allocators need to traverse a complicated data structure to find a suitable free memory block and to mark it used. Fortunately memory allocation algorithms can at least scale with number of CPU cores. Reference counting is problematic with more than one CPU core. If multiple cores can access the same reference counted object, naive reference counting very quickly saturates CPU core interconnect with cache coherence traffic. Every time a reference count is increased (retained/reserved/locked) or decreased (released), an atomic operation is required, all cores must have same value in their local caches. The reference count changes need to be communicated to all other CPU cores [1]. This performance penalty can be partially worked around by minimizing number of reference count alterations and by using hacks on top of the simple case, but at cost of complexity and reduction of safety. In Java, you can't have an array of Objects, for non-elementary types you get an array of references (pointers) instead, where each array element carries overhead of java.lang.Object. The number of pointers is gigantic in pretty much any JVM heap. This is very bad especially for small objects, which unfortunately tend to dominate nearly any heap. You can of course get around this by "rotating" arrays of Objects. No array of Objects, but Object of arrays. Each semantic Object field becomes an elementary type array in a holder Object. This fixes performance and memory consumption at cost of flexibility, code size and readability. Garbage collection extends the object lifetimes and scales linearly with number of CPU cores, but needs [periodic] housekeeping. Reference counting keeps object lifetimes short, but is unsafe with multiple CPU cores or needs slow atomic operations that result expensive inter-core cache coherence traffic, making it ultimately scale badly. There's no silver bullet. [1]: Real cache coherence protocols are quite a bit more complicated than that, see http://en.wikipedia.org/wiki/Cache_coherence http://en.wikipedia.org/wiki/Cache_coherence

14 points by sourcex 12y ago

dozzie 12y ago

Simple: because of Java.

informatimago 12y ago
You could (try to) write coarser grained classes in Java too (granted, with static typing, it may be harder to do).
CmonDev 12y ago
Java or Dalvik?

paines 12y ago

BSD-ish vs Linux Kernel ?

ParvusPonte 12y ago

Better memory usage due to the (BSD-like) kernel, vs Linux could be one of the factors. "My server earlier used to consume over 1 GB of memory for running PHP, MySQL and Nginx. Now, it doesn’t even touch 500 MB! It’s always less than 500 MB. Everything is just same, configuration, etc. Only OS changed." http://nileshgr.com/2013/06/07/the-move-from-linux-to-freebsd http://nileshgr.com/2013/06/07/the-move-from-linux-to-freebs... Slightly off topic but I really wish mainstream VPS providers start adopting FreeBSD, perhaps http://labs.online.net/ http://labs.online.net/ can spark that change, I'd move from Digital Ocean in a heart beat!

informatimago 12y ago
Well, MacOSX and iOS don't have a BSD kernel (or even a BSD-like kernel) at all. They have a Mach kernel. They have howewver, a BSD-like userland and kernel personality. But I guess we can assume that the Mach kernel is also more frugal than Linux. In any case, AFAICS, Apple takes some care about this, because of the performance and user experience consequences.

barrystaes 12y ago

There is only 1GB of ram in iPads? This explains why the browser keeps crashing when i keep 20 tabs open.. jeez!

vlad 12y ago

Besides reasons mentioned in this topic, Apple's desktop and mobile operating systems feature memory compression and other algorithms to save memory and battery life for the last year, since Mavericks and iOS 7. http://www.umass.edu/newsoffice/article/key-features-apple%E2%80%99s-new-operating-system http://www.umass.edu/newsoffice/article/key-features-apple%E...

vardump 12y ago

I think Java's issue is not really due to garbage collection directly, but overuse of references (pointers) leading to very complicated object graphs. This in turn leads to a lot of pointer chasing, cache thrashing and typically significantly higher memory requirements. It's sad how bad reputation this has "earned" for garbage collection in general. Even with just a few CPU cores, if you tried to emulate a similar number of object pointers by using reference counting instead of garbage collection, I believe it'd be at least by an order of magnitude slower than modern GC algorithms. With tens of CPU cores, reference counting would get almost no actual work done. Garbage collection would outperform it by a very large margin. Manual memory management wouldn't fare much better, because memory allocation is glacial: "malloc" (and often also "free") are very slow. Allocators need to traverse a complicated data structure to find a suitable free memory block and to mark it used. Fortunately memory allocation algorithms can at least scale with number of CPU cores. Reference counting is problematic with more than one CPU core. If multiple cores can access the same reference counted object, naive reference counting very quickly saturates CPU core interconnect with cache coherence traffic. Every time a reference count is increased (retained/reserved/locked) or decreased (released), an atomic operation is required, all cores must have same value in their local caches. The reference count changes need to be communicated to all other CPU cores [1]. This performance penalty can be partially worked around by minimizing number of reference count alterations and by using hacks on top of the simple case, but at cost of complexity and reduction of safety. In Java, you can't have an array of Objects, for non-elementary types you get an array of references (pointers) instead, where each array element carries overhead of java.lang.Object. The number of pointers is gigantic in pretty much any JVM heap. This is very bad especially for small objects, which unfortunately tend to dominate nearly any heap. You can of course get around this by "rotating" arrays of Objects. No array of Objects, but Object of arrays. Each semantic Object field becomes an elementary type array in a holder Object. This fixes performance and memory consumption at cost of flexibility, code size and readability. Garbage collection extends the object lifetimes and scales linearly with number of CPU cores, but needs [periodic] housekeeping. Reference counting keeps object lifetimes short, but is unsafe with multiple CPU cores or needs slow atomic operations that result expensive inter-core cache coherence traffic, making it ultimately scale badly. There's no silver bullet. [1]: Real cache coherence protocols are quite a bit more complicated than that, see http://en.wikipedia.org/wiki/Cache_coherence http://en.wikipedia.org/wiki/Cache_coherence