Concurrency is hard... well no kidding...

« previous entry | next entry »
Dec. 17th, 2007 | 01:11 pm

Article from Slashdot:
http://developers.slashdot.org/article.pl?sid=07/12/17/1635200&from=rss

The point is that to make use of multiple way systems, aka machines with a mix of processors and cores, you have to put more thought into your designs.

I've always thought that perl, PHP, and to some extent Java came about because developers could write code in weakly typed/garbage collected systems faster.
Sure, Java is not weakly typed, but the way I see developers program with it, you would not know the difference.

These languages gave us tools to develop against systems that had plenty of memory. Until the advent of 32bit systems, you really had to watch the amount of memory you were using.

Memory issues Today?

"Not so much".

Memory is plentiful, and with 64bit systems becoming common this more true then ever.

Multi-way machines are a catalyst for a new language. One which is concurrent by nature (which might just mean it is map/reduce in nature... which is one of the simplest way to make use of concurrency). Whatever language, or languages, that provide concurrency through the simplest design will when.

I have an Erlang book on my Amazon Wishlist if anyone wants me to give an opinion on it :)

I wonder where my book on Occam is?

If I was designing a language today? I would target 32 processors. It will be common soon enough, and that is enough processors where problems with concurrency can be explored. The argument of "just do two" is pretty lame (and I am hearing that over and over).

Other lame things I am hearing?

Forking? Get real.
Global locks? Yeah, that is going to scale.

Something will come about. Who knows, maybe someone in China has already written it, and I have not heard about it yet because I do not read Chinese.

Back to coding... on MySQL... which is concurrent... using C++... which is not all that friendly for this problem.

Link | Leave a comment | Add to Memories | Share

Comments {5}

Occam link breakage

from: yosnoop
date: Dec. 18th, 2007 02:57 am (UTC)
Link

Brian, always thanks for your great articles.
In this article Occam link lead me to 404.
I want to read that article, though.
If you fix it, I would appreciate that.

Reply | Thread

Brian "Krow" Aker

Re: Occam link breakage

from: krow
date: Dec. 18th, 2007 05:22 am (UTC)
Link

Thanks for commenting on the broken link, I have now updated it.

Reply | Parent | Thread

..

from: burtonator
date: Dec. 18th, 2007 11:41 pm (UTC)
Link

Ha. For a second I thought you meant 32bits and not 32 cores.

I think it's not exactly bright to focus on single cores.

My distributed computing fallacy is going to really start proving itself :)

Reply | Thread

Brian "Krow" Aker

Re: ..

from: krow
date: Dec. 19th, 2007 12:23 am (UTC)
Link

If you want 32bit, use last year's software :)

No database is really handling the distributed problem all that well, but then people are tied to architectures which require synchronous states.

Reply | Parent | Thread

regarding erlang

from: milosp
date: Jan. 1st, 2008 11:22 pm (UTC)
Link

I've read book, tried examples. Nice language, and it's very nice to practice programming from functional programming point of view. It's easy to read, but getting used on this functional way of thinking took me some time. It's nice to see distributed problems solved on one page code listing, written in essence, creating building blocks for next chapter problems. In this paradigm they say you don't worry how to communicate, addressing and so on. In this paradigm they say you just think what to do, not how to do. There is same communicating interface passing all parameters by value, on same or any node you have in cluster.

Reply | Thread