Wait, why developers?

[SkeeterSkeeter]

I am just a little confused.

So with a normal PC, say I went and bought all the parts. MOBO, CPU, GPU, PSU, HDD, CD/DVD, and OS. Say I bought all of this put it together and now I have what the average person would call a desktop PC.

Say I purchase the parallella. I know it ships with Ubuntu for the OS and has the other components on-board. And now I have a parallella.


So all of this coding and developer talk I am hearing.
This is because if I want a program from my normal PC to run on the P||A then I need to re-write it correct? I must rewrite it to take advantage of the new processing cores that are available?

As it is, a program might be written for an 8 core computer. Say it runs some ACPI modules that control CPU usage, well if in these modules I have an array of CPU objects maxed at 8 then I will never ever hit/see/use/address the other 60+ cores on the P||A right?

So any software written now that can run on a PC, lets say firefox, can run on a P||A right? (of course, it ships with Ubuntu). But this firefox should be re-written to make use of the other cores right?



If all this is really the case above; the developer talk is for people to write programs that actually can utilize the cores. Then is it conceivable to write a program that acts as a buffer between programs and the P||A, such that a program written for N cores can be mapped to a M core machine, to be run efficiently?

(If this makes no sense let me know)....

[9600]

[SkeeterSkeeter]

Ok. So on the Parallella there are two regular CPU's that can run normally threaded software.
But you will never touch the other cores unless you write something yourself then? Or get what others have written?


So as it is, there is no logical way to look at a program written for 4 cores and expand it to run on 64?
Or
There is no way to look at a sequential list of operations and make it more viable on the Parallella?


I feel like sequential program would suffer being ran on the parallella;
Take for instance this pseudo code:
fetch a to R2
fetch b to R3
add R2 to R3 hold in R4
write R4 to c

Would it not be faster to do these operations inside a single processor? Otherwise we have to hit the inner-core router(eMesh?) to try and read/write a, b, or c from the other cores?



Is there a form that code must make for it to be useful to run on the parallella versus a single core?

[ysapir]

The code example you give is probably a bad example for parallelization indeed. In order to be effective, the gain from concurrent task execution must be higher than the impact of inter-core communications. Thus, you'd want to split your calculation to mostly independent units that work on self contained packs of data. After performing some calculation on the pack of data, it can be moved to an adjacent core for further processing.

Like running a multithreaded program (say, 8 threads) on a processor with small number of cores (say, 2 cores). The overhead on task switching per core can be higher than the gain you get from 2x parallel execution of the threads.

So, generally speaking, not all algorithms are suitable for parallelization, and balancing the computational load vs the data movement load is a part of your system (or software) engineering.

Regarding porting software for the Epiphany, it most likely requires re-writing and modifying at least some part of an existing program, and again, not all application programs are suitable for porting. Remember that in the Parallella computers, the Epiphany is considered as an accelerator, rather than the application processor. Just like a traditional program will not run on a GPU out of the box, so will it not run on the Epiphany (* maybe with the exception of a purposely written OpenCL program).

[piotr5]

to summarize, I would say there are 2 problems with re-using old software:
1)nowadays there exists practically no software that could be run on a processor that has only 32k of memory
2)the allegedly multithreaded software is actually only making use of 2 processors, one for gui and input and another for doing actual work. they are made multithreaded because without that users would experience that input isn't immediately displayed.

both problems are possible to solve: 1) is merely causing a big slowdown and it seems OS4E is aimed at handling that on a hardware-level. 2) will require a change in software-design from programmer-controlled threading to compiler-controlled. i.e. the compiler must analyze which parts of the program depend on eachother and do the rest in parallell. the point is that this is something only the compiler knows, a binary doesn't have this info so readily available for whatever automatic "buffer" to spread out the program onto more cores. in truth it doesn't make a difference though, a binary built for arm or whatever cpu wont run on epiphany anyway, it's a different architecture alltogether. somehow you must recompile it anyway. therefore the actual development needed for parallella is in the area of writing new compilers and scipt-interpreters and such. firefox doesn't need to be rewritten, its java-implementation might need a little optimization though. wherever some kind of hardware-acceleration exists, with parallella, as with every new platform, the highly optimized stuff must be rewritten from scratch in order to be also highly optimized for the new platform too...

[theover]

On Unix (Linux nowadays) you can run processes on many cores easily, and there are a lot of scientific and multimedia programs making use of multiple cores and threads, whereas on many PCs often programs make use of the "cache" of the I or other processor, which is some megabytes in size. 16 x 32kB is half a megabyte, isn't it ?

[piotr5]

I'm not so convinced *n[iu]x has become ready for parallell processing yet. multithreading is a good solution for the problem of workload blocking the gui. but if I have the sourcecode for a game or ocr or whatever time-critical application, posix simply does not have anything to offer that would make paralellization any simpler. all you can do is rewrite from scratch with paralellization in mind. I have here a processor with 4 cores, and according to the indicator most of the time only one of them is being in use, even when some complicated java-scripts are blocking firefox. so I ask you: if my linux is so "multicore", why can't the otherwise multithreaded firefox make use of multiple processors for one java script? even without parallella, developers are urgently needed in the area of multi-processor programming...

[tnt]

because javascript is designed to be single threaded. IIRC the language assumes that it will only run 1 thing at once and so the programmer doesn't have to think about concurrency or things like that.

[piotr5]

[jeinstei]

I'm going to have to say that this is not a pure software problem; it takes time for data to travel! Offloading to multiple cores means needing communication to and from the cores, and all the communication needs to be able to trigger events somewhere in the system. Lets take an example:

You'r running some code that is supposed to do different math operations on different operators. You can push each math operation to a separate core (as they don't affect each other), but to do that you're going to need to:

1) Parse the application and recognize that parallelization is possible (overhead)
2) Send the data to EACH other core (overhead, especially considering that the Epiphany uses a serial protocol for communication)
3) Complete the operations on each core
4) Receive notice that each core has finished it's operation (overhead)
5) Get the results of each operation and pull it back into the application for further use (overhead)

In the Parallela, this is occurring with a dual-core ARM pushing data into an FPGA pushing data into the Epiphany. It's not so easy.

Dynamic multi-core optimization such as that on modern machines requires A) programs that can handle having multiple threads and B) some sort of supervisory unit that can manage all the data in and out of the system. To keep the speed up, this would probably need to be done in hardware (Zynq FPGA fabric, anyone?).

Anyway. It's a fascinating project and I can't wait to play around with the co-processor.