Thoughts on Multicore.

Intel recently announced a research multi-core chip with 40 cores on a die, taking about the same power as a small table lamp. It achieves a teraflop performance that would have required a hall sized supercomputer and a small power plant just a year or two ago. In other words, we are just a few year away from having todays supercomputers on the desktop.
Of course, Intel and AMD are already marketing dual and quad core chips. Multicore is clearly the way the computer world is evolving. This is certainly true in the server world, but it is bound to come to the desktop world at some point- if for nothing else, as a marketing one-upmanship.

Multicore makes sense on servers – using virtualization, one can run multiple back-end applications on the same box or blade with no loss of performance, which would have previously required multiple boxes or bladse, saving space and power – big issues in server farms. But the funny thing is, which many experts have pointed out, there are very few applications today that can actually benefit from multiple cores on a desktop.

Neither are they going to come out any time soon. Software programmers today simply do not have the tools or the training to write application that make effective use of multi-core. If you have done multi-threaded programming and spent days and nights struggling with strange bugs, you will recognize the problem. Mult-core should be significantly more difficult. Intel and AMD are currently trying to come out with a set of tools that will kick-start the adoption of multi-core by software developers.

However, my guess is that most of these tools will be crude hacks which will either attempt to recompile existing applications for multicore, by analyzing the code for possibilities of parallism, or provide slapdash extentions to C and C++ to write multicore code. The first approach is not likely to succeed – researchers have been struggling with that problem for years with limited success. So, most of us are going to end up having to learn how to use some crude extensions to C, C++ (or Java, C#....whatever), just the way we learnt threads.

What particularly irrititates me is the hegemony of C, C++, and its likely continuation into the future. Ever since these languages became popular, all successive languages have stayed within the same paradigm. The reason given each time is that as there are millions of developers familiar with these languages, and it will be easy for them to upgrade their skills.

Although I used to agree with this statement previously, and was relieved at how quickly I could move from one language to the other (C-C++-Java-C#-Ruby), nowadays it just irritates me. I feel that this paradigm is fundamentally limiting the imagination of developers, and forcing everyone to think in a particular way. After all, it is the expressiveness of the language which inspires the imagination. Lisp enthusiast would of course say that they have been saying this for years. But lisp is just another paradigm in its own way, with its own limitations.

I think we are at a historic point in software, where a fundamentally new way of looking at software may be possible. As multi core moves from 4, 10, 40 to 100, 1000, and beyond (million, billion?), which is very likely, it will require a radically new way of looking at computer architecture, and at software, to be truly useful. And it would require a new kind of language to express the new way of looking at things. Possibly, no language at all, as we understand it today.
I am not endowed with sufficient imagination to predict what it could look like…but I would just like to throw this idea, off the cuff: My guess is that it would end up looking more and more like the human brain. I don’t mean we are going the direction of neural-net software or its hardware equivalent we have today, which try to mimic the working of neurons on software or software-hardware. What I mean is that we will have intense meshes of intelligent nodes, where each node is not autonomous and does its own work, sharing data with nearby nodes when required (as meshes are designed today), but that the entire mesh works in unision…the knowledge and software is in the mesh, not in the nodes per-se.

I am just tossing this idea in air as something to think about...don't ask me the details. If I knew it, I would'nt be writing blogs about it, I would be building it myself.
© Poltu