World-writable memory on Samsung Android phones [LWN.net]

World-writable memory on Samsung Android phones

Posted Dec 26, 2012 18:20 UTC (Wed) by khim (subscriber, #9252)
In reply to: World-writable memory on Samsung Android phones by dlang
Parent article: World-writable memory on Samsung Android phones

I'd say that most release managers won't even ask you about resources,

Well, I guess we are living in totally different worlds. In my company "resources requirement" is one of the most important items in the release process.

let alone refuse to accept something without the requirements tightly specified.

Who said anything about "tightly specified"? It depends on what we are releasing. If it's some addon to the 100'000 servers cluster which produces better statistic then estimate “will need no more then one additional server of regular capacity” may be perfectly good estimate but if it's something like “will need additional 3% of RAM” then it may be a big deal (3% of RAM will mean 3'000 new servers and these are expensive enough to warrant further look).

In the end it's all about the money: if money lost (or “found” if we are measuring sales) are below certain threshold then, of course, resource consumption becomes a moot point, but when we are talking about services which have hundred millions of users then this threshold can be surprisingly low.

Yes, there are times when the resource utilization really matters, but much of the time it doesn't matter that much, and other pressures (like time to market) matter much more.

My experience is direct opposite. Yes, sometimes you only need rough estimate and don't care about 2x difference in memory or speed but you always care about 1000x difference. And O(N²) instead of O(N) can produce 1000x difference pretty easily (while JIT-introduced memory consumption rarely produce more then 2x difference… latency is much bigger problem when JITs and GCs are involved).

(Log in to post comments)

World-writable memory on Samsung Android phones

Posted Dec 26, 2012 18:58 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]

> And O(N²) instead of O(N) can produce 1000x difference pretty easily (while JIT-introduced memory consumption rarely produce more then 2x difference… latency is much bigger problem when JITs and GCs are involved).

I see a lot of stuff deployed without any consideration of these criteria.

> 3% of RAM will mean 3'000 new servers and these are expensive enough to warrant further look

This is what I was saying about not bothering about it until the cost becomes significant to care.

I've seen senior management say explicitly that they want to optimize for programming time over system resource usage, because they perceived hardware as 'cheap' compared to programming manpower, as the company grew, management started to care more about system resources

> Well, I guess we are living in totally different worlds. In my company "resources requirement" is one of the most important items in the release process.

don't make the assumption that every place (or even every large company) is like yours.

In an ideal world, these things would be considered, but in the real world it's frequently put out there on the basis that "it worked with a single user hitting it on the development machine" and only after mistakes take down production "too many times", does there start to be attention to resource usage.

World-writable memory on Samsung Android phones

Posted Dec 27, 2012 20:50 UTC (Thu) by khim (subscriber, #9252) [Link]

I see a lot of stuff deployed without any consideration of these criteria.

Sure, if it's some kind of in-house program where N will not ever be more then, e.g. 1000, then it may work. If you are lucky. If we are talking about commercial software… it just does not fly. I've seen a lot of stuff deployed in such a fashion, but it all tanks when users really come. You may be “first to market” but if your stuff stops working after 10'000th user (or after 100'000th user) then you are usually eaten alive by someone else who was second (or sometimes even third). Your only hope at this point is to sell this mess to someone with deep enough pockets and hope that redesign will survive. It rarely does.

I've seen senior management say explicitly that they want to optimize for programming time over system resource usage, because they perceived hardware as 'cheap' compared to programming manpower, as the company grew, management started to care more about system resources.

Well, that's why I'm talking about back-of-the envelope calculations. Quite often you only need to know resource usage very roughly. But it's one thing to estimate them imprecisely and explicitly refuse to spend time for too much fine-tuning and it's totally different thing to ignore resource requirements completely and not to even know if you need 10 times more servers with 10 times bigger userbase or 100 times more servers.

I think the only programs where you can explicitly refuse to think about rough estimates are some parts of games: there are a lot of not-all-that-time-critical stuff where you can use Lua or Python and N does not grow so your requirements don't grow either. And gamedev is not something we are doing here.

don't make the assumption that every place (or even every large company) is like yours.

I'm not doing that! Not even close! I know there are a lot of companies and a lot of so-called “software engineers” who don't care about this stuff. That's their choice. We just don't want to see these aliens from parallel universe landing in our world, that's all. Take a look on the title of this article—it explains what goes on pretty succinctly (why would you are about time to reference memory if you don't know roughly how many times you'll need to do that in your program?).

It does not mean that people are obsessed with all these numbers and complexities all the time—of course not. Often you just note something like “Ok, this is O(N) so will probably not be a bottleneck” or “fine, it's O(N³) memory, but we don't expect to ever see N > 10 thus it's Ok” in your head and happily go on with the implementation. Sometimes you need to actually stop and think if you want to fight for the smaller memory consumption or latency. But you usually do that at the design phase when changes are cheap and simple not when everything is deployed and the only way to fix something is try to add bazillion caches (and even they often don't help).

World-writable memory on Samsung Android phones

Posted Jan 4, 2013 22:32 UTC (Fri) by nix (subscriber, #2304) [Link]

Sure, if it's some kind of in-house program where N will not ever be more then, e.g. 1000, then it may work. If you are lucky. If we are talking about commercial software… it just does not fly. I've seen a lot of stuff deployed in such a fashion, but it all tanks when users really come.

Sorry, that's rubbish. It may be true for mass-scale web software with millions of simultaneous users, but most software is not like that! I've written software in which I chose to use really crappy sorts in slow interpreted languages because I knew perfectly well that N for this application could never be above 16 without other invariants being invalidated that would necessitate rewriting the entire application. And this was for a major international bank throwing who knows how many billions of dollars a day around. I think that could be considered 'commercial software' (even if said bank *did* then proceed to shag itself and the economy of a major first-world nation, it was no fault of this software: that division was making money hand over fist and the software worked fine).

(Of course, I had to pay attention to time and space complexity at times, and I frequently lamented the way my co-workers could not be bothered to do so. But that doesn't mean that you can always look at the complexity of an algorithm and conclude that you know something about the resource requirements of the system on which it sits, particularly if there are complex layers like modern server-class JVMs in the way. Note that particularly for time complexity all software has such layers in the way, because of the storage hierarchy; context switching and multicore architectures just make it worse, and virtual memory can make reasoning about space complexity into a rat's nest at times too. That's not to say you can't reason about it, but you certainly can't assume that an apaprent efficiency or inefficiency at one level translates into the same all the way up the stack.)