Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Almost every cloud instance I can find only offers one CPU. Why is this only one CPU now, and should I expect this to increase in the future?

Does this design impact my code design so that I exclude technologies like Task Parallel Library?

This is on topic to Programmers.SE because it impacts the long-term scalability of muti-threaded code on cloud platforms.

share|improve this question
You usually have such limitations because of some sort of payment option. From what I know, Windows Azure for example has the option of creating a multi-core VM. It's not a general limitation of the cloud system. – Radu Murzea Jul 26 '12 at 20:37
Amazon EC2 offers up systems with multiple CPUs. – GlenH7 Jul 26 '12 at 22:52
I would go for a Grid like architecture then, with computing nodes serving in place of traditional threads. You just simply throw more machines at the problem as workload scales up. – Peter Smith Jul 26 '12 at 23:01

For sure, you should plan for the execution environment you are expecting to use.

The cloud platform I use lets me define VMs with multiple CPUs. If explicit parallelism is important to you, select a different vendor.

share|improve this answer

No, you actually should. I would even go as far as to say - everyone should.

Parallel programming is actually a huge problem for the whole industry, it's a topic universities, tutorials, project managers and architects usually shy away from. This is bad, very bad, and should be fixed ASAP.

Parallel programming is not actually that hard, but it needs a different mindset that most people are not comfortable with. Decent multi-threaded apps can be written with just knowing and abiding by the rule that all function calls should be reentrant and shared objects protected. This solves most of the problems.

But getting used to that is problematic. Documentation is not always threading aware, or does not explicitly talk about threads. Bread and butter safety nets like unit-tests fail miserably in parallel programming. Thread joining and abnormal termination/cancellation is a huge issue. And deadlocks are one scary thing as soon as people start getting overly creative.

This extra complexity is enough that most people just forget about extra threads, heck, even I used to, and even now I sometimes "forget" about threads. This is also a perfect way for cloud providers to forget about multi-cores, and run more VMs on the base hardware.

But this is wrong, computing power growth is in threads now, we as programmers have to get used to the new world, and we should try to use the threads whenever possible.

share|improve this answer

This certainly hampers concurrency prospects, but there are cases when a single-threaded program running on a single core could still benefit from multiple threads : every time the thread waits for something (e.g. blocking IO).

Let's say this program executes a set of similar tasks where each involves C compute time and W wait time, then to keep the single core fully utilized you need W/C threads.

Here's the general formula, given those definitions:

Ncpu = number of CPUs

Ucpu = target CPU utilization; 0 <= Ucpu <= 1

W/C = ratio of wait time to compute time

The optimal number of threads to keep CPUs at the dezired utilisation is :

Nthreads = Ncpu * Ucpu * (W/C)

This means that multiple threads do not improve performance (only) when there are more runnable threads than available CPUs.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.