I was just reading about ARM's latest announcement for their new A9 processor core. I'm a bit of a fan of ARM and not just because they have a committer on the CDT :). They have a very interesting strategy when it comes to their market and rely fairly heavily on open source tools to enable software developers to use their small low power cores.
What struck me about the A9 core is that it comes with built-in support for multi-core configurations of up to four cores on a single System-on-Chip (SOC). One of the concerns I have heard of ARM in the past is the performance of their cores, particularly their earlier versions. Going multi-core makes a lot of sense to help alleviate that without too much of a power overhead. And it opens up a new class of software application that can take advantage of it.
But once again, the spectre of doing multi-threaded development is starting to take hold in another sector of the industry. Are embedded tools ready to handle this? Even more important, are embedded developers ready to handle it. This is a recurring theme in my blogs and I still haven't found the answer.
My gut tells me the best way for programmers to deal with the complexity of multi-threaded development is to introduce a new programming paradigm that simplifies the thought process and puts doing multiple things at the same time as a first class citizen. This is what we did when programs became gigantic and the old functional approach didn't scale. Objects were our saviour.
The era of multi-core brings new challenges and I wonder out loud, is there a better paradigm to help us deal take advantage of all power it brings while allowing C and C++ developers to leverage their skills at embedded development? Is OpenMP the answer? Or does it go far enough as a new paradigm? Something to look into.
I guess most of embedded developers are happy with programming in C, given its predictability.
ReplyDeleteIf we pushed the use of multicores towards the operating systems than a developer could write separate programs with a low degree of interaction and still take advantage from the architecture. The hard bit would be partitioning the application(as this article from embedded.com states).
But even with OO and UML skills I find it to be a challenge to represent multi threads on the same piece of paper. One could use use numbers to mark different thread operations on a sequence diagram but it soon becomes quite messy.
The best aid remains debugging multithread programs with Eclipse, it has made our life much easier - what would it be like not having a jtag key...
Plenty of discussion on multicores on embedded.com
Be careful of the way you use the word functional. I think what you really mean there is procedural. Functional programming is something entirely different. Lisp is functional, C is not.
ReplyDeleteI lurk in a few forums that focus on programming languages. A lot of people there seem to think that objects aren't the solution, they are actually the problem. An object represents state, and synchronizing the sharing of state between threads is error prone. Languages like Haskell (a real functional language) reject the concept of state. Haskell programs can then be trivially run in parallel. Now, Haskell has its own set of problems so I don't think its going to take over any time soon. However some of the ideas from that language may find their way into more mainstream languages in the future. (Simon Peyton Jones, the main Haskell guy, works for Microsoft research.)
If you are really interested into that space, you should listen to the lecture of the ACM Turing Award given by Allen Frances in 2006. She talks about various directions though not in details.
ReplyDelete