The future of concurrent programming

[freeagle]

Henrik wrote:
> Todays rant on Slashdot is about parallel programming and why the support for multiple cores in programs is only rarely seen. There are a lot of different opinions on why we haven’t seen a veritable rush to adopt parallelized programming strategies, some which include:
> 
> * Multiple cores haven't been available/affordable all that long, programmers just need some time to catch up.
> * Parallel programming is hard to do (as we lack the proper programming tools for it). We need new concepts, new tools, or simply a new generation of programming languages created to handle parallelization from start.
> * Parallel programming is hard to do (as we tend to think in straight lines, lacking the proper cognitive faculties to parallelize problem solving). We must accept that this is an inherently difficult thing for us, and that there never will be an easy solution.
> * We have both the programming tools needed and the cognitive capacity to deal with them, only the stupidity of the current crop of programmers or their inability to adapt stand in the way. Wait a generation and the situation will have sorted itself out.
> 
> I know concurrent programming has been a frequent topic in the D community forums, so I would be interested to hear the community’s opinions on this. What will the future of parallel programming look like? 
> Are new concepts and tools that support parallel programming needed, or just a new way of thinking? Will the “old school” programming languages fade away, as some seem to suggest, to be replaced by HOFL:s (Highly Optimized Functional Languages)? Where will/should D be in all this? Is it a doomed language if it does incorporate an efficient way of dealing with this (natively)?
> 
> 
> Link to TFA: http://developers.slashdot.org/developers/07/05/29/0058246.shtml
> 
> 
> /// Henrik
> 

I think the languages are enough for concurrent programming. I'm planing 
to work on a project that will use concurrency from the ground up ( it 
will be a multimedia library ). I'm also interested in game/graphics 
development. I've read a few articles that talk about using multiple 
threads and multi-core CPUs in such environments. The ideas published 
were based on current generation of programming languages. They provide 
methods/approaches of coding a multi-threaded game engine with 
performance rising nearly linearly with additional CPU cores. So I think 
the problem with MT applications is that people has not yet adapted to 
thinking in parallel. They don't divide the problem correctly into parts 
that can be executed concurrently. Therefor they use a lot of locking 
mechanisms, which lead into other, and harder to solve, problems, like 
deadlocks. What may be lacking are not features in current programming 
languages, but maybe tools that would help with designing such applications.

freeagle