in reply to parallel programming and MCE - hubris and the frame
However, to continue sharing my observations, there is one thing you overlook in the whole discussion. It's the problem of i/o to the disk or network when writing programs for parallel processing. I/O is very slow compared to how fast the cpu runs, and unless you are running an 8-core Xeon machine, with a T1 internet line, most of the cpu time in the program is wasted in waiting for the i/o to complete. That fact makes parallel processing a tricky proposition because you may waste more resources trying to fork and spawn threads than you gain in overall program efficiency. Newer software designs like node.js and Perl6 are designed to address this issue. The general solution is to run single threaded "event-loop" programs which handle the i/o with "promises" and callbacks. This is essentially how gui code, like Tk or Gtk+ runs. Node.js is just a single threaded event-loop program which listens on a socket .
There is a simple explanation of this at asynchronous Perl6 and the author of Perl6's MoarVM, has an easy to watch video on youtube -> Worthington on Parallel programs in Perl6
Of course, frameworks like MCE, parallel forks, and spawning worker threads are still very useful in certain circumstances, but in general, the software of the future will be event-loop based solutions.
Finally, most of us, have single core or a few core computers. On machines like these, parallel processing is usually just an exercise in coding, and dosn't really speed anything up.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: parallel programming and MCE - hubris and the frame
by 1nickt (Canon) on Apr 10, 2017 at 12:10 UTC | |
by zentara (Cardinal) on Apr 10, 2017 at 14:43 UTC |