Wild Ideas

[piotr5]

except for the similarity to gpu, parallella is a completely new idea. well, actually a coprocessor isn't that new an idea at all, x86 platform had those since early days. but instead of taking advantage of the paralell processing power, more and more processing units were added and most of the time they are unoccupied. somehow I'm wondering why parallella believes this will be any different here. i.e. the straight-forward use is to let the cores calculate matrix stuff and such by a customized math-lib.

well, honestly this is all I can imagine to happen when restricted to high-level programming languages and 8kb big assembler-programs. however, this isn't all that's possible. an interesting idea would be to re-write the linux kernel such that the cores are used as little helpers emulating hardware or filled with actual mini-tasks to perform in background. this way however the programmers wont have much cores left for doing the actually interesting stuff. so this approach would require a good management software in the main cpu that can allow fine-tuning how much is in use by kernel-space and eventually freeing up everything if requested.

interesting approach would be to allow for in-kernel translation between machine-code for main processor and the parallella cores. if there is a thread small enough to fit into the 8kb, translate it and run it. all that could be done even at the level of libthread and ld.so and such. would require an new binary format for libs and executables though. but since we are talking of a completely new architecture here...

what the major parallell programming approaches are missing is to make use of predictable calculation-speed. one could minimize communication by forcing 2 cores to calculate the same thing simultaneously. sometimes a good prediction on what other cores are doing can allow the more idle cores to send some data over dma before it's being requested. data-transfer could be optimized by sending data over the edge, through the main processors, to where it belongs. (afterall the topology is shaped like a ball or doughnut.) i.e. on a 64-core architecture the upper left core can send a message to lower right core by messaging the main cpu which hands over the massage, hopefully in much less cycles than the 14 cycles it would otherwise need. also interesting is to optimize programs by aligning calculations to time-frames and making sure no other core will block the communication path there.

people keep complaining that 8kb is too little for a sensible program, but this is only true when you are using shared libs. when you statically link your program then you save on administrative code and only code that actually gets used will be included in this limited space. so, how about a dynamic linker doing the same kind of improvements at run-time?

those parallella cores are obviously a security-issue in a normal linux kernel if they can be accessed freely by the user. however, I can imagine this situation could be turned around if the cores would take over the work of hardware otherwise used for security improvement. starting with encrypted disks and monitoring network, right down to watching over the very code the main cores are executing and thereby effectively preventing those cores from messing with the parallella cores. additionally branch-prediction and various other complex duties of a processor could be emulated, increasing the speed as a by-product of the whole monitoring. also virtual machines could make the additional cores do the actual translation from machine-code to machine-code and thereby making parallella emulate any platform you want with several security addons. great platform to research and develop some computer-virus or its antidote.

there are many projects that give a meaning to idle cores, all it takes is to alter the code so it runs on parallella efficently. would also serve as a good testing-ground for various ide-improvements and such. I think those projects should be looked into too in the beginning. so whoever buys parallella will have at least one advantage: better success in those projects...


anybody has some other wild ideas that might not fit into the "what will you do" cathegory? at least my ideas are too much to handle for a single person, so any takers on maintaining some large projects in those directions?

[ed2k]

those are really inspirational ideas.

[theover]

So what are you: cynical, too dialectial to think straight all by yourself, too super expert to do some low level handywork?

Anyhow, there are a few things not too wild about this project IMHO: there is the power matter (very important in DSP, too, and not a strong point of the Intel mains stream or the graphics card parallel processors), there is the matter of the relatively fine grained connections with relatively high speed (your CPU talking to you GPU or other co-processor will probably not make it in the microsecond range, and over a Gigabyte/Sec isn't that bad compared to the 4GB/S or maybe some more in practice on the main intel CPU based boards), there is the matter of price (hard to beat), general useability (Open Source, nice FPGA user pins, precomiled and usable Linux and parallel chip access functionality), and the design is something new: an FPGA with embedded processor usable for serious general purpose work, well connected with partially (and even safely) reprogrammable FPGA cells, with fast connection to mildy fine grained parallel processing chip, and all Open Source is, sorry to say, new.

Theo V.

[piotr5]

didn't mean this project would be a wild idea, my ideas are. what I said is unlikely to get much support from the developers since it means back to the drawing-board and deep assembler-hacking, instead of the cozy wide pre-prepared field of various programming languages. now we have decades of software-development in the past to make use of, but for the parallella project it all is somewhat useless. gentoo users expect a fast computer to compile their programs quickly, but how can you force gcc to make use of parallell processors without a major rewrite? just running make on each of those processors wont help much anyway, even if it were possible. gamers expect a fast computer to give them high frame-rate and high details, even if parallella could emulate a gamer's favourite graphics card, the game still would only make use of the 2 main cores if the game-engine doesn't get a heavy rewrite. so the major applications of this system are only video- and sound-processing? are you sure linux/posix is the right os for that?

I'm not being cynical just realistic. what this project needs is to get some wild ideas implemented, and I'm not talking of my own ideas here. when I said this project is nothing new I were not offending the hardware-developers, it was meant as a critique to what I read in this other thread here! price and power-consumption are indeed low. so low that less than 64 cores wouldn't make much sense -- 4 times the core-count at 2 times the consumption? however, they are not really a big leap forward: same power as raspberry pi (maybe one third of intel-stuff) and price is half of what you pay for gaming-console. the competition doesn't sleep! so in whole, it's like the developers of this piece of hardware said, to become a financial success we need good projects based on it! fact is this forum has many subsections for language-bindings, but only 3 projects?

oh well, back on topic: what about an implementation of L4 microkernel? anyone experience with that? any possibility to implement that on those additional cores? any ideas what one could make of that, beyond signal-processing?

[sent]

You go way to quick into detail and practices. You partly lost me... but to recap: I understand. You also want native use of the parallel processing power of the parallela. AND you want every (future) user use them as much as possible.

This can be done on several levels: 1) the kernel as-is, 2) the gcc compiler, 3) libraries and 4) in code (written by you). For now, the support for 16+2/64+2 cores appears (to me) to be manual; so implement it yourself.
EDIT: Do you propose it to happen on level '0': the soft side of hardware, assembler and such...?
If/When we rewrite the kernel, we can have threading support on every level, but we have to maintain (as a small group, now, of parallela users) a custom kernel... and distribution. We could execute tasks as threads, where ever it can be used. The only integrity question needed: can each OS-task be trusted and understood to operate as specified, as good as procedural? This trust will arise when the mainstream will start to understand parallel execution.
We could also base our system on ARM (because we have two of those cores), re-use every package distributed. This leaves the developer the option of compiler and libraries. Then, you can provide native-parallela threading to every running (recompiled) program. So: you optimally use every core and turn it truly into a 12Ghz or 45Ghz computer on 5V.

It ain't a wild idea, at all!

[piotr5]

once upon a time most programs were written in assembler for 2 reasons:

1) limited space and speed ressources were more optimally used there
2) compilers didn't exist yet or the compilers that exist only worsened 1)

with parallella we have a similar situation now. there are at least 16 cores with similar capabilities as the 2 main processors, but they are using a different machine-code. should we compile the programs for the machine-code those 2 processors use or the machine-code the 16 cores use? obviously linux needs certain hardware-features to ensure security and maintainability: some sort of memory-protection (those 16 cores have that to some extent) and memory-paging (might be a problem) and the possibility to distinguish between in-kernel code and userspace (haven't found that in the docs). therefore we are forced to use the 2 well-established processors and their machine-code. but it would be nicer if the compiled program could somehow also run on those 16 cores in a distributed fashion. let's face the truth, for that a lot of work must be done, with pure assembler-programming!just think back, why didn't linux kernel support 186 processors, or at least 286? I think we must do all the things you mentioned: gcc support for parts of kernel-sources to be re-used, parts of kernel would need to be written in assembler and someone would need to maintain that, and of course the math-libs too need access to the 16+2 cores, as does the programmer. problem with linux is it treats all cores as equal, while parallella has a certain structure, with communication between cores taking up time depending on what cores those are and depending on the activity of other cores. therefore I suggested additional meta-info about libs and programs: threads that must communicate must be located close to eachother...

[fmotta]

One of the many things I was considering was to see if this subsystem can be low-cost enough then it might be great for slicing 3D for CNC (3D printing) without the use of a PC for the work. Allowing for a "print-n-go" 3D printer.

Decomp of a 3D graphics is very basic. So, the partitioned work might be paralleled well.

[sent]

piotr5: True, we have to do all of the above. One of the problems we are facing: most of us don't understand the architecture of parallela, yet. While most (like me) are just beginning to study parallel programming and are most of the parallela-specs unknown (to me). This will dramatically change when we receive our boards and start playing, developing, testing. --I want mine, now!! -- And then it will take time! A lot of time! Our best hopes are with Adapteva: they know their product. Hopefully it has matured enough, already. Mature for us to build upon, without the need to "re-discover the wheel" and build these many layers of parallel-threading support our parallela needs to operate 'out-of-the-box' as a 16+2 core computer.
For our education: Adapteva should start giving lectures/vlogs explaining how it all works. For example compare their platform against GPU-strategies like CUDA/Nvidia. And a update (announcing this) on Kickstarter would be very nice.

fmotta: I'm (going to) using a RaspberryPi for those tasks.. but 3D-printing just takes time; be patient. Well, we could go and rewrite the slicers-calculation to operate in parallel. Good idea!