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

http://www.quora.com/How-come-the-iPhones-1-GB-RAM-is-touted-to-be-able-to-compete-with-more-than-2-GB-RAM-of-Android-phones/answers/7061202?share=1

by sourcex • 12 years ago

14 12 12 years ago

quora.com

dozzie• 12 years ago

Simple: because of Java.

informatimago3• 12 years ago

You could (try to) write coarser grained classes in Java too (granted, with static typing, it may be harder to do).

CmonDev• 12 years ago

Java or Dalvik?

paines• 12 years ago

BSD-ish vs Linux Kernel ?

ParvusPonte• 12 years 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-freebs...

Slightly off topic but I really wish mainstream VPS providers start adopting FreeBSD, perhaps http://labs.online.net/ can spark that change, I'd move from Digital Ocean in a heart beat!

informatimago3• 12 years 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• 12 years ago

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

vlad• 12 years 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%E...

vardump• 12 years 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

geon• 12 years ago

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.

Isn't that true in Objective C as well, though? Or does NSObject have much less overhead?

informatimago3• 12 years ago

Indeed. The difference may be that classes in the iOS frameworks are general more coarse grained than classes in the Android frameworks.

When you only need one class to do something in iOS (and MacOSX), you might need ten classes in Android (and other Java frameworks).

For example, compare the number of classes to parse xml on iOS (one class: NSXMLParser), vs. the number of packages and classes to parse xml on Android: (javax.xml.datatype.DatatypeConstants, javax.xml.datatype.DatatypeConstants.Field, javax.xml.datatype.DatatypeFactory, javax.xml.datatype.Duration, javax.xml.datatype.XMLGregorianCalendar, javax.xml.namespace.NamespaceContext, javax.xml.parsers.DocumentBuilder, javax.xml.parsers.DocumentFactory, javax.xml.parsers.SAXParser, javax.xml.parsers.SAXParserFactory, javax.xml.parsers.ParserConfigurationException, javax.xml.parsers.FactoryConfigurationError, (I'll skip all the javax.xml.transform packages and classes, since assumedly they wouldn't be used to read xml), javax.xml.validation.Schema, javax.xml.validation.SchemaFactory, javax.xml.validation.SchemaFactoryLoader, javax.xml.validation.TypeInfoProvider, javax.xml.validation.Validator, javax.xml.validation.ValidatorHandler, javax.xml.xpath.XPath, javax.xml.xpath.XPathExpression, javax.xml.xpath.XPathFunction, javax.xml.xpath.XPathFunctionResolver, javax.xml.xpath.XPathVariableResolver, javax.xml.xpath.XPathConstants, javax.xml.xpath.XPathFactory, javax.xml.xpath.XPathException, javax.xml.xpath.XPathExpressionException, javax.xml.xpath.XPathFactoryConfigurationException, javax.xml.xpath.XPathFunctionException, amongst a lot of other classes).

frozenport• 12 years ago

Indeed, I recall benchmarking and being shocked how the same program ran slower and use 30% more RAM in 64 bit vs 32 bit mode.

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

Related Stories