GCC and static analysis
Posted Apr 23, 2012 21:40 UTC (Mon) by khim
In reply to: GCC and static analysis
Parent article: GCC and static analysis
Check out Golang for an example of an imperative language built around message passing between lightweight threads. Such a language could easily scale to thousands of cores.
Golang still produces programs which connects sequential islands with pipes. To efficiently ulitize millions of cores you need to parallelize task as much as possible. Not sure about thousands: perhaps Go will scale to this level, perhaps not, time will tell.
It's possible to write anything in imperative languages (any functional language is translated to imperative ISA of target CPU, after all). But I'm not sure if such a feat is achievable by someone who can not program in functional languages - and if you need to employ such people anyway, then it makes to sense to strangle them with imperative programming.
Whether or not something can be parallelized is more related to the algorithm than the programming language you write it in.
Sure, but that's the problem: when you write programs of thousand of lines they you usually think that you are implementing one single algorithm. Which may be parallelziable or not. But in reality if implement hundreds of tiny subalgorithms there - and even if the "main" algorithm is not parallelizeable these subalgorithms may be parallelziable.
Think about map::insert example again. Suppose you have sequence of keys and you need to print for each key the line number. High-level algorithm employed by the imperative programmer and by functional programmer may be the same (insert all the elements in the map or, better yet, priority queue, pull them one after another), but imperative program (even written in Go) will, most likely, use just one core while functional program (given smart enough compiler) will meaningfully saddle dozen of core with meaningful work!
The problem we hit here is simple: contemporary CPUs are so much tuned for streamlined execution of imperative programs that they are useless for such organization of the work! Sure, you can meaningfully use dozen of cores for the aforementioned task… in your dreams. In real life all these countless buffers and caches start working against you and lose so much speed in communications between them that functional program may be even slower on dozen of cores then imperative one on a single core!
You need completely different organization of the hardware to effectively utilize this kind of parallelism! It's possible to create it, but then it'll be slow when you'll try to run the existing programs so who'll buy it? Thus I'm sure that till SMP paradigm will work we'll be stuck with the existing architecture and imperative languages.
to post comments)