2009.11.28 - "the free lunch is over"

yesterday i've just back from Intel's tools workshop that took place in Poznań, Poland. Among many things, tools and concepts presented during 4-days-logs event we came across interesting article by Herb Sutter: the free lunch is over. since many years it was a main goal to provide working software, that did not have to be really fast and work optimal, since according to Moore's law computers in few-months time frame will be fast enough to handle it in a proper speed. oh - wait! there is a trick! Moore's law says only about transistors count, which until early 2000's was nearly 1:1 applicable to home PCs' speed. this was the “free lunch” – your application were running faster and faster over a time, without any extra effort from your side, as a developer.

these days are over for now and it appears that it will stay that way for some time. we've came across 2-3GHz CPUs about 6 years ago and GHzs on shops' shelves didn't changed much since. computer run faster though, so what have hanged? 3 main things change now, and it appears that it will continue that way in predictable future:

1. architecture upgrades (new algorithms, new, specialized instructions' sets, etc…)
2. cache sizes (i.e. faster handling of bigger programs and data)
3. cores' count – and mostly this, in fact

what does it mean for developers and software architects? no more free lunches! if your application has to be fast and/or scalable it has to use what CPUs offer, which will be multicore architecture. this means extra effort to prepare and test the program. “ok then - i'll make my application 2/3/4 threaded”. nope - this will not do the trick as well. it will, if properly designed and implemented, bring reasonable speedup of course, but assigning pre-defined number of threads to do the work simply won't scale for future CPUs. during the workshop we were told what are the main Intel's plans for speedup in recent years – mainly core's count. we already have 2-cores laptops and 4-cores workstations as a standard for some time. 8-cores? no problem! on the beginning of 2009 AMD has presented 24-core server system. does your recent code scale to this CPU count?

the truth is we don't have nice, parallel language, that count hide complexity of concurrent programming from developers. C++ doesn't have threads in specification at all, as for now, thought there are some interesting solutions that help going multithread easily, for example: OpenMP or Intel's Threading Building Blocks. there are languages like Ada that has build-in concurrency, though it is explicit anyway. new Google's Go language has a build-in concurrency, that appears to be easy to use, but it still does not look like revolutionary.

as for now, when doing production code for large systems we're bounded to more classic approach with explicit parallelism.