It helps having a language which supports concurrent programming. You get this for free if operations are pointwise or vector arithmetic on long vectors - but this is the case only for some applications.
You get this for free where the structure of the algorithm allows concurrency if you write in functional languages (does not matter much whether lazy or strict).
But whatever you do multi-thread concurrency does not solve every problem. Superscalar (single-thread) concurrency can speed up most code a small but useful factor (say 2-10X). multi-thread concurrency can provide arbitrary speedup, if you have the processors available, but is very restricted by algorithm.
programmers find it hard enough writing correct programs, let alone correct programs that expose all possible parallelism.
Best wishes, tom
A Polywell recession
Lots of algorithms are inherently parallel.
Like this emulation of a simple bandpass filter:
http://www.intellasys.net/templates/tri ... amProg.pdf
Like this emulation of a simple bandpass filter:
http://www.intellasys.net/templates/tri ... amProg.pdf
Engineering is the art of making what you want from what you can get at a profit.
I was under the impression that cost of distribution (incl. maintenance) was significant regardless of how the power is generated. A large part of the plant cost is in the turbines, etc, assuming they'll still be used with a Polywell.power production is coming at 1/10th of current prices
Now, what's this about 1/10th?
That only works if it is a pB11 plant which eliminates turbines.JohnP wrote:I was under the impression that cost of distribution (incl. maintenance) was significant regardless of how the power is generated. A large part of the plant cost is in the turbines, etc, assuming they'll still be used with a Polywell.power production is coming at 1/10th of current prices
Now, what's this about 1/10th?
Distribution typically runs about 1/2 of electrical costs.
Engineering is the art of making what you want from what you can get at a profit.
DSP is easy parallelism. On the other end of the complexity scale, try FEA with an ad-hoc mesh and collision detection. Updating an octree search grid in parallel is an standing invitation for trouble if you don't do the mutex work right.MSimon wrote:Lots of algorithms are inherently parallel.
Like this emulation of a simple bandpass filter:
http://www.intellasys.net/templates/tri ... amProg.pdf
As for natural parallelism in a functional language, that calls for efficient launching of micro-threads, something leading hardware is very poor at. But if a thread could be launched as efficiently as a forth function call, that would be very sweet.
Message passing between processors is useful. Shared memory is far more flexible, but more difficult to engineer for large scales.
I like the idea of massive numbers of fairly simple processors. But they're not easy to use well.
If they are small they are cheap. And if you don't use them they only cost 7 uW of power. And 7 mW at full bore (700 to 900 MHz).I like the idea of massive numbers of fairly simple processors. But they're not easy to use well.
I'm told that the main cost of one of these jobs is the package. Figure about 1 cent a pin. That is 88 cents for the package. The silicon comes in at probably 10 or 20 cents. In high volumes they sell them at $2 to $3 a chip.
Suppose you only use 20 cores of a 40 core chip. 20 * 700 = 14,000 MIPS for $3 delivered. Now compare that to Intel. Or the Analog Devices Shark DSP.
If they can get these out into the market in volume it will collapse the whole uP industry. BMW is looking in to them. All it will take is a few high volume apps that get recognition and it is off to the races. And Moore will have the last laugh on all those uP industry suckers.
Engineering is the art of making what you want from what you can get at a profit.