In other words, UC Berkeley has made no progress at all in coming up with a solution to the parallel programming crisis. They are no closer now than they were when they first began more than a year ago. All those millions invested by Intel and Microsoft have simply been wasted. Bravo, Berkeley. Failure must be the name of game in this business.
What's amazing about all this is that there is somebody at Berkeley who could have made a real difference in this research. His name is Edward Lee, the man who showed the world that multithreading is evil. What's even more frustrating is that the folks at Berkeley research have visited my site many times and have read my ideas on the crisis. Not once did any of them contact me to discuss these ideas. Well, neither will I contact them when my time in the limelight comes. Sooner or later, they'll come around. And they won't be able to say that nobody told them because I know they all read Rick Merritt's articles and the responses. Keep it up, Rick. You've been covering this crisis from the beginning and it will not go away anytime soon.
How to Solve the Parallel Programming Crisis:
UC Berkeleyâ??s Edward Lee: A Breath of Fresh Air:
Although it is no use to be so frustrated as Mapou is, he is essentially right. I have witnessed this for at least 20 years, the best they can come up with is a crude form of reverse engineering and a ad-hoc API while trying to get the parallelism out of a program that destroyed all parallel information from the original problem domain by using a sequential programming language. I call this the von Neuman syndrome.
Nevertheless, clean parallel programming paradigms have been been developed since the 70's. I refer here to Hoare's CSP process algebra. Languages and processors have been build that use it as a basis (transputer, occam, ...). We took another approach by embedded the programming model in the services of a distributed RTOS (Virtuoso). One customer's system had even 12000 processors (heterogeneous and using less the 1 Mbytes/node).
Recently we went further and redeveloped a new one from scratch but using formal modeling. The code size is now around 5 to 10 KBytes. And yes we have no thread model but a clean task model. It works completely transparent across any type of processors and any type of interconnect technology. The formal modeling made all the difference.
Hoare's CSP is not the answer either, otherwise we would not be here discussing the crisis. Hoare, like most academics, is addicted to complexity. Occam is way too abstract and too complicated to be the solution the industry is looking for.
The big surprise in all this is that the solution to the crisis is not rocket science. It is a simple parallelizing concept that has been in use for decades. We already use it to simulate parallelism in video games, simulations and cellular automata. We just need to take the concept down to the instruction level within the processor itself and adopt a synchronous reactive software model.
Folks, the days of Turing, Babbage and Lady Ada are coming to a quick end. It's time to wake up and abandon the flawed ideas of the baby-boomer generation and forge a new future. The boomers were wildly successful but this is a new age, the age of massive parallelism. The boomers need to retire and pass the baton to a new generation of computists.
Download the E-Book if you're interested:
Wow. You're absolutely right. We are in the mess that we are in because of academia. They invented it all. All the bright engineers and PhD research managers at Microsoft, Intel and elsewhere came from academia. It's painful to see the computer industry throwing money at the very people who gave us this mess in the first place and whose livelihood depends on the mess being with us forever. UC Berkeley, UIUC, Stanford and the others have a vested interest in seeing that this crisis lasts for as long as possible. Why? Because no crisis = no money. I'm sure this is not going to win me a lot of friends out there but I don't care. It's the truth, godd*mmit.
How will the new programming platform (by Berkeley) be comparable with already existed multicore programming tools such as Wind River Systems or QNX?
Especially by using these tools, you can literally visualize all of the cores on your board and you just program each core separately using the integrated RTOS semaphores for multi-tasking.
A Book For All Reasons Bernard Cole3 comments Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...