Slashdot Mirror
Android ICS Will Require 16GB RAM To Compile
ozmanjusri writes "New smartphones may be lightweight, compact objects, but their OSs are anything but. Ice Cream Sandwich will need workstations with no less than 16 GB RAM to build the source code, twice the amount Gingerbread needed. It will take 5 hours to compile on a dual quad-core 2+GHz workstation, and need 80GB disk space for all AOSP configs. Android developers are also being warned to be cautious of undocumented APIs: 'In almost every case, there's only one reason for leaving APIs undocumented: We're not sure that what we have now is the best solution, and we think we might have to improve it, and we're not prepared to make those commitments to testing and preservation. We're not claiming that they're "Private" or "Secret" — How could they be, when anyone in the world can discover them? We're also not claiming they're forbidden: If you use them, your code will compile and probably run.'"
Nobody will ever need more than 16GB...
If you want news from today, you have to come back tomorrow.
16GB recommended, or else you'll be waiting quite awhile. But, you could build the thing in less RAM than that, right?
This is a guess as to the reason.
One of the better ways to optimize C++ code for building with GCC is to put all of the source code into one big code file. Or you can build it as a few independent modules, but the code is still quite large. Then you build it with the O3 flags. In GCC, the amount of RAM and CPU used in an O3 compile goes up by quite a lot as the code size in a single module increases. I am not sure what the exact equation is but I think it's an exponential function.
This would easily explain the RAM and CPU usage.
I mean, you can spend $100 and buy a 16-inch horse cock dildo, but that doesn't mean you can shove the whole thing up your ass.
While Android will remain open-source, eventually it will require so much RAM/processing power/etc. to compile that only Google will have the computational resources available to compile it.
Clever!
Quick question for those with giant codebases such as this. How the heck do you test, and debug the software with those kind of lag times? Do you split everything up into smaller pieces or something? If so, then surely there are cases where you need to test something that requires EVERYTHING to be compiled. I can imagine such shot in the dark scenarios to be the stuff of pure nightmares.
Why OpalCalc is the best Windows calc
16GB RAM recommended, more preferred, anything less will measurably benefit from using an SSD.
Emphasis mine. Still pretty beast, though.
I mean, you can spend $100 and buy a 16-inch horse cock dildo
I'll leave that to you. Interesting that you knew the price off the top of your head, though.
Unless the build system is screwed up, recompiling after a change should be relatively fast. Usually source code is stored as lots of smaller files, and each file is compiled separately to produce a separate object file (e.g., .o). Then next time a rebuild is requested, the system should notice what changed, and only rebuild the needed parts. Some parts take the same time each time (e.g., a final link), but it shouldn't take anywhere near the same amount of time.
There are lots of build tools, including make, cmake, and so on. If you use the venerable "make" tool, you might want to read Miller's "Recursive Make Considered Harmful":
http://aegis.sourceforge.net/auug97.pdf
Cue the lovers and haters of "make", here :-).
- David A. Wheeler (see my Secure Programming HOWTO)
TFA: "5+ hours of CPU time for a single build, 25+ minutes of wall time, as measured on a workstation (dual-E5620 i.e. 2x quad-core 2.4GHz HT, with 24GB of RAM, no SSD)."
/. Summary: "It will take 5 hours to compile on a dual quad-core 2+GHz workstation"
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
While it is a lot of RAM compared to what many system have, it really isn't a big deal these days. 4GB DDR3 sticks are $25 or less each, and that is for high quality RAM. Regular, consumer grade, LGA1155 boards support 4 of them. So for $100 you can have 16GB on a normal desktop system. My home system I type this on has 16GB for that reason. It was so cheap I decided "Why not?"
They actually can support more, with 8GB chips you can have 32GB on a standard desktop, but those are still expensive.
The enthusiast X79 LGA2011 boards coming out will have 8 sockets and thus handle 64GB. Of course beyond that there's workstation which cost a lot more, but not as much as you might first think.
At any rate, 16GB is now a "regular desktop" amount of RAM. Standard boards the likes of which you get in cheap ($1000 or less) towers support that much, and it only costs $100 to get. It is quite a realistic thing to require, for something high end.
I was looking for something else to do on my old 16-cpu Itanium cluster with 64gbs of shared ram. I think I just found it...
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
16 GB is far more than any desktop user should need, and most laptops simply cannot hold that much, so it's creating a sharp demarcation between user and developer. This is bad. You want your advance users to naturally transition into becoming developers, and making your codebase inaccessible for them prevents that.
IOW, most people have suggestions for improvement for any tool they use. Ideally, it would be trivial for someone to download the source, modify it, recompile, test, and submit improvements. People start with simple things (e.g. misspelled words) and move to more advanced tasks as they gain familiarity. By requiring several hundred dollars of hardware and massive time investments, you are ensuring that users never become developers, just needy consumers whining about feature requests.
Unless the build system is screwed up, recompiling after a change should be relatively fast. Usually source code is stored as lots of smaller files [...] Then next time a rebuild is requested, the system should notice what changed, and only rebuild the needed parts.
I feel your pain brother.
Human nature -- If you document it, people will expect it to be stable (no matter what you may say to the contrary). Undocumented API's have a built-in "we told you so" flavour to them.
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
I wonder how long a full compile of that takes...
Unless the entire program is in 1 gigantic 8 billion billion billion line file why would it need that many resources or even be able to use 16 GB of RAM?
Assuming it is like a normal program would it not just be a large collection of relatively small files that are compiled one after the other (theoretically number of CPUs + 1 threads running at a time with that many files being compiled concurrently being the optimal solution)?
And I just do not see how you could ever use up 16 GB at any one time.
Troll is not a replacement for I disagree.
This article would be shocking, but considering that 16 GB of memory -- especially the dual-channel DDR3 used for the i5 and consumer i7's -- is so cheap, less than $100, this article doesn't have any shock value. It's just informative. It's letting us know the 'recommended' memory and giving more nerds an excuse to add more RAM. That is the NERDS that don't already have 24 gigs for their virtual machines. :P
The D programming language compiles much faster than C++. It was designed to be easier to lex & parse
So how much of the compile time for C/C++ code is spent processing the characters in the source code and how much is spent processing the intermediate representation and turning it into machine code? If the answer is "most of the time is spent doing the latter", then "designed to be easier to lex and parse" doesn't help much.
(And how much of Android is C/C++ and how much of it is in their Java dialect? How much of that time is spent translating C/C++ to machine code and how much of it is spent translating Java to Dalvik bytecode?)
Hyperthreading! With 8 physical cores, the OS sees 16 logical cores. 16 threads can be running at once. Though technically only 8 are running because there aren't extra copies of the adders, multipliers, etc, whenever one is waiting on memory, or stalled because a branch miss-prediction emptied the pipeline, etc. then the other thread can run instantly. Normally it's stupid to context switch due to a branch error or cache miss, since probably that will be resolved before you can finish the very expensive context switch operation. Having two sets of registers and such allows for instant switching between which of the two logical cores is being handled by the physical core, so any time either thread is waiting on memory, the other thread can get some work done. And whenever it's stalled on something that actually would require a context switch normally, it can be handed off to the other one while that switch is occurring. It's not nearly as good as having 16 physical cores, but usually you get about 30% more CPU time squeezed in be doing this. 4 hours * 1.30 = 5.2 hours. Seems consistent to me.
ASCII stupid question, get a stupid ANSI