Benefit from concurrent programming (-languages)? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

lately i'm trying to dive into the开发者_如何学JAVA world of concurrent programming. at the beginning i thought the only reason of multicore processors is an improved performance of the programs. but now i'm not so sure anymore...

considering the fact that writing multithreading programs in most languages is diffucult, many tend to recommend exspecially designed languages like Erlang or Clojure as the language of choice for concurrent computing. Sure, Erlang makes it a lot easier to write concurrent programs, but is it worth it?

i've look up some of the Erlang programs on shootout (yeah i know that microbenchmark doesnt say much...) and was surprised that many of the single-core C programs even outperform quad-core Erlang programs.

so my questions is, what are the advantages of languages like Erlang, Clojure etc? why should i use a language, which makes it easy to write multicore program, when single-core programs in C/Java are even faster?

(i forgot to mention, these questions are only related to multicore machines, distributed computing is something different, and i can see Erlangs advantages here)

---

As most good answers start, it depends on what you are trying to do, and in this case it depends on what you are trying to do it on (hardware).

Currently, there are some nice machines available with 32+ cpus on them. To utilize all these cpus requires either:

1. You write a multi-threaded program in the language of your choice
2. You write one single-threaded program and run lots of instances of it which all communicate in some way (to partition the workload) to solve your problem.

Often 1 is a lot easier to do than 2.

If you look at the "future of hardware" it appears that there is a trend towards more cpus rather than faster ones. So say, ParaCCC (imaginary language) is 10x slower than C, but you have a machine with 512 cpus on it that ParaCCC (for our problem) can utilize. In theory the ParaCCC program will run 51x faster than the C program. Without a rewrite. Plus C is typically not know for its time-to-market, where-as this is another boast of these new languages.

Also, you are probably not considering that most programs that do any amount of I/O end up multi-threaded anyway, since you tend to use different threads for I/O than processing, and you don't want a single slow client slowing you down (obviously C can do this but the threaded model commonly looks a lot nicer).

Regarding Erlang, I asked a related question here: How many CPUs are needed before Erlang is faster than single-threaded Java the answers of which have a lot more details and arguments along these lines...

---

Clojure is a good choice precisely for this tradeoff. It doesn't impose as many constraints on you as in erlang, in fact you can always re-write sections that need more performance in a mutable imperative style (still in clojure, though uglier) if you like and gain the speed of java. However, the correctness and concurrency guarantees give you a faster time to market than C and java for any sufficiently complex problem, and we all know that developer time is worth more than the cost of hardware.

The idea behind clojure is the constructs (immutability, transactions) enable you to reason about concurrency more easily.