More than 10 years ago I participated in the development of an University IT system (the front- and backend to maintain grades and that sort of stuff). The system was based on a DB/2 backend (a very nice database system) with the business code stored on a Prolog interpreter (Prolog interpreter which was in-house developed) and the web backend being a Java servlet engine (the old JServ, the thingy pre-Tomcat from Apache). Prolog is famed to be slow, and Java (at that point in time) was very slow. Surprise, surprise… the bottleneck was on the DB/2 server. Eventually, as the system grow (and the database hardware was beefed up) the bottleneck come forward to the business and web tiers, but the problem was sorted by just adding more machines: The contention was on a bunch of parallel independent process, they could be run on separate machines.
The example above illustrates why the concurrency problem posed by multiple core CPUs and GPUs, might not be that much important:
- Many problems are not CPU bound anyway, and even if they are, the bottleneck might be elsewhere. Another example: I am the proud owner of 3 cheap, slow laptops (one being a netbook). For my use case I really don’t need faster applications, I wonder how many users really need more than they already have?
- Even if more CPU/GPU power is needed, a loosely coupled model (without much interprocess communication and contention issues) might be enough. This is typically the case of many web apps, which can scale by just adding more computers which run independent processes.
Concurrency, even with modern abstractions, is hard. It should be avoided if possible and it can be avoided in many applications. If it cannot be avoided, maybe a loosely coupled model is enough… Guido van Rossum has a nice take on this issue.
This is important as concurrency is being touted as an important criteria to evaluate languages. Modern functional languages (think Scala and Clojure) are being touted as a better option precisely because they are better to do concurrency (both because of functional – “no changing state” – programming and the availability of libraries implementing nice concurrency paradigms like actors).
When addressing this importance of this issue, I would propose, that people would ask themselves this: “Am I developing computationally intensive software?” and “If I am developing computationally intensive software, can I live with loosely coupled models of computation, preferably processes with no shared memory?”
This is not to say that there are not some cases where tightly coupled computing is a good idea. It is just that, this complex solution might be an overkill for many problems.
I would just like to add that I am not defending my cause, in fact it is quite the opposite. There is actually some content produced here, in the past, on how to tackle concurrent programming:
- LOSITAN – A multicore-aware Jython-based (Python for the JVM) Web Start application to do selection detection.
- An introductory tutorial on concurrent computing targeting computational biologists – Part 1, 2 and 3
Tom says:
I don’t see any examples of overhyping concurrency and multicores for specific applications. If you look at most examples given by these areas, they demonstrate their strengths – multicore, concurrency, works for problems that can be sped up using them.
Why NOT have it? If it’s a nice benefit on occasion, why not? Divvy out your problems between ones that can be attacked in a massively parallel way, those that can use GPU, those that just need brute CPU strength, and deal with them accordingly.
It sounds like extrapolation from one data point to say “i don’t need it, so why does everyone else?” which is the basic vibe from point 1. Why would you need a fast laptop? You don’t seem to. But many people want one. Wouldn’t you want an Ion, or Ion 2 in your netbook? Or maybe an SSD would speed it up?
There’s a fundamental difference between individual user’s needs, and their desires, their wants. The majority of netbook users would i’d argue want a faster netbook. They’re sucky slow. Concurrency might be in parts hard, but sometimes it’s pretty easy, and getting easier.
Concurrency, having the CPU GPU memory HD, SSD firepower is relevant when the problem can be tackled this way. And when it is, it’s hugely important, as the gains are manyfold. It’s not the general be all and end all, but if a user could have a more powerful computer, wouldn’t they take it? has there really been many cases of “excessive” or too much computational power?
Would many people go back to single core? Or integrated over discrete graphics power? The need/desire of a user for more computational power isn’t a fixed value, and i’d imagine it’s going up , with day to day variations, all the time.
November 22, 2009, 17:48