Channel 9 Forums - Coffeehouse - Parallellized Functional Programming & Multiple control flow paths of a binary`s execution

Coffeehouse - Parallellized Functional Programming & Multiple control flow paths of a binary`s execution

Eric Aguiar — Sun, 28 Feb 2010 12:42:46 GMT

1) I'd like to state exactly WHY functional programming is far easier parallelized, it's not because of immutability per-se, immutability help in a way, but the reason is something slightly more subtle. C++ and other compilable languages get assembled into assembly instructions, that linear form is actually the problem. The instructions depend on instructions above other than the branch/jumps to find the final momentary code execution path. Functional languages on the other hand use LAMBDAS, which are self-contained packages of instructions which are independent of other lambdas. The ability for one lambda/anonymous function to not rely on the others in the program other than possible data dependency's, is why you can run a lambda function independent of the predecessor instructions or processor. Thus a lambda function's instructions are at a coarse enough grain that they aren't tied together by a built-in per-CPU hardware program counter like the imperative way of both a program`s structure and logic.

2) The other thing I've not been able to understand is WHY today we are limited to a single main function!!! To me, if code entry execution point and exit points could be referenced or indexed like a function table at the beginning of the file, after the magic number and before the header meta-data, then the binary could/should be able to run different functions on different processing cores at the same time using hardware supported memory spaces per execution path for sharing memory. Instead of the one large traditional main function which must start at one point in the code/binary and end at specified exit/exception points.

This is an alternate way in my head I've been wondering as a different approach to the "thread" way of software engineering.

Coffeehouse - Parallellized Functional Programming & Multiple control flow paths of a binary`s execution

Joshua Ross — Sun, 28 Feb 2010 16:19:47 GMT

I cannot think of any benefits to having multiple mains. It's not like a lot of work is done in it. It's there mostly for execution control flow purposes. The only place that I have seen something like multiple mains is in a computer virus. The basic idea behind those is to spawn another main(ok so, it's a proc, whatever) when something kills or suspends the other.

Since net4 arrived in my dev-workflow, I have stopped using threads anyways. The Task Parallel Library works much better, by being more difficult to screw-up and more performant.

Coffeehouse - Parallellized Functional Programming & Multiple control flow paths of a binary`s execution

Eric Aguiar — Sun, 28 Feb 2010 22:17:49 GMT

JoshRoss said:

I cannot think of any benefits to having multiple mains. It's not like a lot of work is done in it. It's there mostly for execution control flow purposes. The only place that I have seen something like multiple mains is in a computer virus. The basic idea behind those is to spawn another main(ok so, it's a proc, whatever) when something kills or suspends the other.

Since net4 arrived in my dev-workflow, I have stopped using threads anyways. The Task Parallel Library works much better, by being more difficult to screw-up and more performant.

I'm sorry if it seemed like I specifically desired multiple "main()" functions, I was referring to what main actually does, as an execution entry point for the whole program to follow in its steed.

I want a way for one core to start one part of a program whilst another core can execute a different path, working towards a common goal using the memory address the OS gives the program.

lol and yes, the TPL would indeed be a much more sane way to go for the runtime to manage your thread pool's usage, I for one have only explored the PPL for usage of C++0x features & Lambda's along with interfacing with Intel's TBB for cross platform STL style code.

Rick Molloy is THE MAN along with Erik, they're both really inspiring.