| |||||||||||||
World-writable memory on Samsung Android phonesWorld-writable memory on Samsung Android phonesPosted Dec 24, 2012 17:27 UTC (Mon) by paulj (subscriber, #341)In reply to: World-writable memory on Samsung Android phones by khim Parent article: World-writable memory on Samsung Android phones
Hmm, it seems to be nix who is stating the simple fact: JVM memory allocation is extremely hard to predict. At least for a programmer. Yes, you can make an analysis of what would be the required amount, but this is just a lower-bound. The JVM has, for good reason, an extra-ordinary level of freedom in what it does. It could vary from doing GCs frequently in order to be as conserving of memory as possible (at cost of performance), to very infrequently and using far far memory than what you anticipated (trading space to gain time/performance).
If I were given a question by an interviewer that led me then to explain these trade-offs in reply, and that interviewer then stamped "No Hire" because I had failed to accept "simple facts of life" simply because of that, then I think I'd be glad to have dodged a bullet...
(Log in to post comments)
World-writable memory on Samsung Android phones Posted Dec 24, 2012 19:49 UTC (Mon) by khim (subscriber, #9252) [Link] Hmm, it seems to be nix who is stating the simple fact: JVM memory allocation is extremely hard to predict. No. He uses said "simple fact" as an excuse to avoid discussions about real problem. Let me repeat once more: before you can deploy any program (including JVM-based) program you must know what resources said program will need. No excuses. Release managers will just refuse to accept your code if you can not answer this question. And JVM complexity is most certainly no excuse. Sure, it makes said task harder, but so what? It's still a strict requirement. If I were given a question by an interviewer that led me then to explain these trade-offs in reply, If you'll take a look on the initial question you'll see that it has nothing to do with all these complexities. Sure, question was not 100% correctly defined, sure it needed emends to be unambiguous—but ball was in Nix's court. Nix raised JVM-introduced problems with JIT, GC and other horrors. And instead of simple and sensible suggestion to ignore all these problems (good approximation for the first try) he raised them to central position of the task. Well, if you want to discuss these things (instead of limiting our exposure to them by using some rough estimates), then I'm ready to do that, too—but it still does not free your from the need to solve this task. And that interviewer then stamped "No Hire" because I had failed to accept "simple facts of life" simply because of that, then I think I'd be glad to have dodged a bullet... Good for you. Perhaps you'll find a place where people always enunciate all the tasks precisely and unambiguously. Perhaps such places do exist, but I've not seen them. In my experience the ability to refine requirements of the task is half of what I do when I write programs. Often the ability to write the code itself is less important compared to the ability to understand WTH we are trying to create in first place and what kinda trade-offs are there.
World-writable memory on Samsung Android phones Posted Dec 24, 2012 21:27 UTC (Mon) by paulj (subscriber, #341) [Link] Let me repeat once more: before you can deploy any program (including JVM-based) program you must know what resources said program will need. No excuses. Release managers will just refuse to accept your code if you can not answer this question. And you think stamping "No Hire" on the curricula vitae of interviewees who can discuss and show a good understanding of how Java code memory allocation maps to JVM/system level allocation will get you that? Really? :) Sure, question was not 100% correctly defined, sure it needed emends to be unambiguous - but ball was in Nix's court. … In my experience the ability to refine requirements of the task is half of what I do when I write programs. I agree 100% with the latter statement. Refining requirements is critical, it takes time and usually at least several communication roundtrips, if not many more, in working out all the hidden assumptions that each side has. I would be sceptical that you will get such people if you stamp "No Hire" on the CVs of people who start exploring technical issues that arise out of ambiguities in questions, and instead hire those who don't, be that out of ignorance or timidity. But hey, YMMV - whatever works for you. I'm sure at least some of your competitors will be glad to hire at least some of the "No Hires" who you find to be questioning ;).
World-writable memory on Samsung Android phones Posted Dec 26, 2012 17:54 UTC (Wed) by khim (subscriber, #9252) [Link] And you think stamping "No Hire" on the curricula vitae of interviewees who can discuss and show a good understanding of how Java code memory allocation maps to JVM/system level allocation will get you that? Knowledge of JVM/system level allocation are great, but these not a replacement for common sense. Joel said it better then me: Our goal is to hire people with aptitude, not a particular skill set. Any skill set that people can bring to the job will be technologically obsolete in a couple of years, anyway, so it's better to hire people that are going to be able to learn any new technology rather than people who happen to know SQL programming right this minute. Now, go back and think. Do all these discussions about JIT, system level allocations, etc look like something academic about a problem? Well, that's the problem right there. Now, I'm not saying that nix does not Get Things Done, more likely then not he just does not know how to adjust his knowledge to the situation of the interviewing process where interviewer have 45 minutes to say "Hire" or "No Hire", but well… it's his problem, not mine. I would be sceptical that you will get such people if you stamp "No Hire" on the CVs of people who start exploring technical issues that arise out of ambiguities in questions, and instead hire those who don't, be that out of ignorance or timidity. Well, that's why interviews must be conducted in person (even VC is not a good replacement although it can be used as “last resort” kinda thing). When someone tries to dig “too deep” (and discusses pieces which are not really all that relevant to the task on hand) or “too shallow” (and ignores most corner cases) you can quickly try to resolve the situation before it'll escalate. If someone raises JIT-related concerns then it's not plus or minus by itself! The next step is critical: if person says something like “well, usually these are not a problem on practice, let's forget about them for now” then it's big fat plus (interviewee knows about Leaky Abstractions problem but it knows when not to talk about them), but if person goes on to discuss all these minutiae details and abandons the initial task entirely… it's not a good thing to say the least. It's much harder to do discuss these things on forums like LWN: no visual contact and no 45 minutes restriction.
World-writable memory on Samsung Android phones Posted Dec 24, 2012 22:03 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
> Let me repeat once more: before you can deploy any program (including JVM-based) program you must know what resources said program will need. No excuses. Release managers will just refuse to accept your code if you can not answer this question.
you can repeat it all you want, but in the real world things are not always this rigid or predictable and you are wrong to state it as an absolute. I'd say that most release managers won't even ask you about resources, let alone refuse to accept something without the requirements tightly specified.
A huge number of companies don't measure this sort of thing ahead of time, they throw it up and buy more hardware as needed, only addressing the efficiency (and resource consumption) when the cost of providing enough hardware becomes a problem.
This smacks strongly of premature optimization.
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.
World-writable memory on Samsung Android phones Posted Dec 26, 2012 18:20 UTC (Wed) by khim (subscriber, #9252) [Link] 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).
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.)
|
|||||||||||||