Good, but cheap machine for Android Development

L.Jenkins

So my question this evening is, does anyone have any recommendations for a decent laptop for Android Development? My current laptop has an AMD A9 processor and 8 GB of ram, but it's no where near enough, as Android Studio seems to eat ram like Chrome on crack.

smacl

For anything desktop possibly better asked of the hardware oriented folks on the PC building forum. I got some great pointers on building my current dev rig which works like a charm. Laptop depends more on budget and what your looking for in terms of size / speed / weight. First thing I'd do is profile your current laptop under load to see where the bottlenecks actually (e.g. single threaded speed, multi-threaded speed, RAM being exhausted, disk access, network, etc...) and build or buy accordingly. For C++ on Visual Studio, thread count is most important to build time followed by disk. My own programs are also very heavily multi-threaded so went with 16C/32T and also a reasonable GPU as I'm starting to get into some compute shader programming and more general GPU stuff.

14ned

It's exactly the opposite of cheap so apologies for the off topic reply, however I recently splurged on a 16 core Threadripper with 128Gb of ECC RAM and a top-of-the-range Samsung 970 Pro NVMe SSD.

I can now recompile from scratch the Linux kernel in about a minute. I can recompile work's monolithic behemoth codebase within 20 minutes from scratch. For everybody else, it's a two hour plus effort. I can recompile all of Boost and its test suite within a few minutes. It's silly fast.

For Android development, I have no idea if this level of hardware would help you. I suspect most of your problems will be a poorly written IDE, and no matter what hardware you use, your experience will still suck. Still, if you have a spare two grand, I'd highly recommend Threadripper. The hardware is utterly rock solid (not a single blue screen yet!), performance is excellent, and the performance-to-cost ratio outstanding compared to alternatives.

And it's rather hard to run out of RAM when you have 128Gb of it! Even where I'm running AddressSanitiser on work's binaries where we suck down ~100Gb of RAM during the test run, so far I have not yet hit any memory limit. Touch wood.

Niall

L.Jenkins

Will have to fork out for something good so.

Anima

14ned wrote: »

It's exactly the opposite of cheap so apologies for the off topic reply, however I recently splurged on a 16 core Threadripper with 128Gb of ECC RAM

Curious as to why you went for ECC RAM? How does that help development?

smacl

L.Jenkins wrote: »

Will have to fork out for something good so.

Net necessarily. Some excellent deals on 1st gen Threadripper which would get you a really solid dev PC on a decent budget, e.g. 1920x 12 core, 24 thread at £193 ex VAT. No point throwing thousands of quid on a CPU, GPU or RAM that never actually get used. Threadripper is truly great for C++ dev and while there are CPU bargains, the motherboards are a bit more expensive. If you're not doing a massive amount of compiling or processor intensive stuff, the 3600 is a cracking 6C/12T CPU at just £145 ex VAT and AM4 motherboards are also inexpensive. Easy enough to build a really solid dev machine under a grand these days. The folks on the PC building forum are the ones to ask. Just give them a budget and tell them what you need.

14ned wrote: »

I can recompile all of Boost and its test suite within a few minutes. It's silly fast.

Is Boost not mostly a header only library with minimal build times? Totally with you on Threadripper for big open source C++ library builds, it really munches through stuff.

The_B_Man

8GB is probably the minimum. You'll get by with 8GB, an i7, and an SSD. Anything extra is a bonus.

14ned

Anima wrote: »

Curious as to why you went for ECC RAM? How does that help development?

So, yeah, that ...

Finding available for sale eight matched sticks of 16 Gb = 128Gb of RAM running at 2933 which is on the manufacturer's QVL list of verified memory is very hard. The cause is that they are unregistered DIMMs, and running eight of them in parallel at such a higher speed is not common. Here were my choices:

• HX430C15PB3K8/128 Kingston HyperX 128 GB (Kit 8 x 16 GB), 3000 MHz CL15 DIMM XMP, made from Hynix RAM chips. Best price I could find was €647 ex VAT.

Yep, that's one choice. And that's buying globally, from anywhere in the world. That memory came from a single supplier in the US.

An alternative choice was to fit memory not on the QVL list, but with ECC, and then I would be able to tell if it is stable or not with 8x sticks. I had to take a shot in the dark with that, so I chose the easily available Samsung server memory on the basis that the internet says that Threadripper loves Samsung RAM chips:

• M391A2K43BB1-CTD Samsung 16GB DDR4-2666 ECC UDIMM PC4-21300V-E CL19 Dual Rank. Best price I could find was €564 ex VAT.

Now you'll surely observe that 2666 CAS 19 RAM is oodles slower than 3000 CAS 15 RAM, in fact it's exactly 42.5% slower. But Samsung RAM is rumoured to be highly overclockable, so I took the risk.

Anyway I'm glad to report that the Samsung memory happily overclocks to 2933 at CAS 16. They'd likely go higher, but gen 2 Threadripper won't itself do better than 2933 with eight memory sticks, you need gen 3 to go higher. And ECC is working very well, both the motherboard and Windows detect ECC and log bitflips. And to date zero bit flips detected.

So tldr you don't need ECC for development, but it was a workaround for lack of availability of validated 128Gb. And it came out cheaper too. I'm happy with it.

Niall

14ned

smacl wrote: »

Threadripper is truly great for C++ dev and while there are CPU bargains, the motherboards are a bit more expensive. If you're not doing a massive amount of compiling or processor intensive stuff, the 3600 is a cracking 6C/12T CPU at just £145 ex VAT and AM4 motherboards are also inexpensive.

I'm very with you on that AMD 3600 CPU.

However the list should be aware that Threadripper as a HEDT platform has twice the memory bandwidth of consumer hardware. This is why the motherboards are more expensive, keeping the timings for four sticks of RAM rather than two sticks in sync costs money.

The advantage of HEDT is that they're really the server platform, so they get far more hardware testing and validation than consumer platforms. I'll swear to you right now that not a single blue screen has occurred yet with this Threadripper platform. It's amazingly stable. You'll also get quickly used to all that extra memory bandwidth, using a high end consumer PC feels weirdly laggy in comparison.

smacl wrote: »

Is Boost not mostly a header only library with minimal build times? Totally with you on Threadripper for big open source C++ library builds, it really munches through stuff.

Boost is indeed mostly header only. Therefore every compiland must compile most of Boost repeatedly. The test suite is really mean to the library, and thus to the compiler. Seven minutes to compile a single file with optimisation would not be uncommon, and there are many, many tests to compile.

I'm actually right now writing a high performance RESTful API server in C++ using Restinio. It's header only, and all the libraries it uses are header only, so compile times rapidly become painful. Performance is very good however, and this specific problem I'm solving requires very high performance. The JSON library I'm using does do any dynamic memory allocation whatsoever, you have the NIC DMA the JSON request into a ludicrously large buffer, the JSON library converts the input into an AST in-place, we execute the query, and write the results by directly appending strings into another ludicrously large buffer to avoid any memory allocations. That then get DMAed back out to the client.

C++ sucked for years at web stuff, but it's become not awful recently, and if you need to answer 99.9% of queries within 10 microseconds, the alternatives are not a long list. Our clients are on a bespoke fabric bypassing the kernel network stack, yet still want JSON. Sigh.

Niall

smacl

14ned wrote: »

I'll swear to you right now that not a single blue screen has occurred yet with this Threadripper platform. It's amazingly stable. You'll also get quickly used to all that extra memory bandwidth, using a high end consumer PC feels weirdly laggy in comparison.

Very much the same experience, though only 64GB RAM and RAM rated for 3000 so no overclocking needed. The 64GB mounts as every second slot, so also easier cooled, which is just as well I'm regularly running 32 threads for extended periods. I use additional PCs for stuff like automated testing, profiling and building, which for me are a very cost effective way of remaining maximally productive without clogging up my main dev PC. This is where the lower cost kit really pays for itself.

Boost is indeed mostly header only. Therefore every compiland must compile most of Boost repeatedly. The test suite is really mean to the library, and thus to the compiler. Seven minutes to compile a single file with optimisation would not be uncommon, and there are many, many tests to compile.

I'm actually right now writing a high performance RESTful API server in C++ using Restinio. It's header only, and all the libraries it uses are header only, so compile times rapidly become painful. Performance is very good however, and this specific problem I'm solving requires very high performance. The JSON library I'm using does do any dynamic memory allocation whatsoever, you have the NIC DMA the JSON request into a ludicrously large buffer, the JSON library converts the input into an AST in-place, we execute the query, and write the results by directly appending strings into another ludicrously large buffer to avoid any memory allocations. That then get DMAed back out to the client.

C++ sucked for years at web stuff, but it's become not awful recently, and if you need to answer 99.9% of queries within 10 microseconds, the alternatives are not a long list. Our clients are on a bespoke fabric bypassing the kernel network stack, yet still want JSON. Sigh.

Niall

Fair enough, I include Boost as it is needed for some other 3rd party libs but don't use it much myself. Enjoying your commentary on newer features of C++ such as co-routines, should really take some time out to swot this up, though my head is already a bit wrecked getting up to speed with compute shaders. Was really peeved that AMP died off so soon, do you reckon the C++ standards will implement heterogeneous computing anytime soon? Waded through OpenCL after AMP but driver support is patchy and don't really want CUDA as it is nVidia specific. Currently delivering on Windows so using HLSL but it is another compromise in terms of portability.

Sephiroth_dude

My machine struggled with android studio so I had to uninstall it and I have 8 gigs of ram,the virtual phone would take ages to load or might not load at all as well as it taking AS ages to startup, was thinking of reinstalling it.

jester77

The_B_Man wrote: »

8GB is probably the minimum. You'll get by with 8GB, an i7, and an SSD. Anything extra is a bonus.

For android? 8GB will be painful especially if you also have an emulator running. 16GB minimum is what you would need to comfortably code and build.

Buford T Justice

jester77 wrote: »

For android? 8GB will be painful especially if you also have an emulator running. 16GB minimum is what you would need to comfortably code and build.

SSD makes a massive difference.

The_B_Man

I don't use the emulator because its a disaster, even with HAXM on Intel chips.
Hook up your phone via USB and then you'll have a much better time.
Without a physical device, yes you'll need more RAM. Or a 3rd party emulator, preferably.

L.Jenkins

The_B_Man wrote: »

I don't use the emulator because its a disaster, even with HAXM on Intel chips.
Hook up your phone via USB and then you'll have a much better time.
Without a physical device, yes you'll need more RAM. Or a 3rd party emulator, preferably.

Never thought of doing that. On saying that, I'm actually looking for an excuse to get a better spec Laptop or PC.