Skip to main content.

Monday, June 28, 2010

I've been so busy that I didn't even had the time to put down this notes recently.

Long story short:

Parallel programming is writing programs where one or more parts are designed to potentially or actually run at the same time on different computational nodes (processors, computers, co-processors).

Multithreading programming (or simply threading) consists in using a set of tools to control physical computational parallel resources, together with their physical synchronization and sharing devices. Some multithreading structures abstract the final physical layer, but MT never gives completely off the ability to control the minute instruction flow on every processor you have at your disposal. Mutexes and MT-wise semaphores (i.e. MS-Windows events or POSIX condition variables) may be implemented differently on different processor architectures, but their point is granting that the underlying processors and/or the operating system tightly bound to it will do a set of operation granting some specific behavior of the hardware.

So, is MT parallel programming? -- No, but you can DO parallel programming with MT tools/programs/libraries. When using MT, either you want to control the underlying hardware parallel abilities for other reasons (and you don't want to mess with the raw ASM needed to do that), or you're writing your own parallel programming environment, for how simple it is, to make your program to do tasks in parallel.

After some years in the field and in the field of programming languages, I finally came to the conclusion that high level languages, and especially scripting languages, doesn't need MT. Worse, exposing MT-level operations and concepts to high level scripts (threads, mutexes, and so on) can harm more than help.

What you want when using a low level language is to be low level as low as you can, but not lower. In C and C++, you want threads, CPU affinity masks, mutexes, condition variables. What you want when you use an high level language is to be high level as much as you can, but not more. Like, doing all the messy stuff of a whole C program in a couple of well-designed instructions or commands. You want to tell the system the LOGIC of your THOUGHTS, and then you want the system to do the stuff for you.

In short, the next Falcon version will have threads and parallel structures removed, and will embed threading in the language itself, not differently from Erlang or Ocalm. Coroutining may be reviewed as well, and be considered a special case of threading. The idea is to be able to define parallel code, and find the compiler (for what can be told at compile time) and the VM (for the runtime conditions) to run it "as parallel as possible". A VM may be assigned the limit of 0 thread, thus making all the parallel code to run as coroutines.

More on the upcoming idea in the next post.


No comments yet

Add Comment

This item is closed, it's not possible to add new comments to it or to vote on it