Making Revolution faster using dimensioned arrays

[Alex Tweedly]

Dennis wrote:

> "These declared arrays would run 10 to 100 times  faster than the 
> type-less ones for the kind of operations that are  required by image 
> processing, AI, statistics, and many other  applications."
>
Jon wrote:

> Given the detailed work that Alex (?) did a week or two ago with my 
> algorithms, I am not at all sure that your optimism is warranted.  
> That said, I love the idea <grin>


I too love the idea. I think it would extend the scope of pure-Transcipt 
to cover a wide range of interesting problems. When it coalesces into a 
solid Bugzilla enhancement request, it will get quite a few of my votes.

But this on its own will not make pure-Transcript feasible for image 
processing tasks.

Imagine that the engine could be incredibly fast at accessing 
these"dimensioned arrays". We can easily benchmark to see how long it 
would take for various assumptions about how fast it *could* possibly be.

For a 6MP loop:
doing nothing take 430 ms
assigning to a scalar variable takes 1500 ms
accessing via an index (char i of var) takes 2500 ms
incrementing via an index (char i of var) takes 5200 ms
idealized version of histogram takes 10400 ms

So even if the optimization of "dimensioned arrays" achieves everything 
it can hope for, and can access those arrays through a single index 
look-up - it will still take 10 seconds to do a histogram for an image 
of the size produced by last year's consumer cameras.

It is still, IMO, a worthwhile addition to the language, and would allow 
us to do a lot of things that are beyond pure-Transcript today but are 
less demanding than image processing. In some future combination with a 
"compileIt" optimization (and perhaps some optimizing of "repeat with" 
loops) it might stretch to cover image processing.

But honestly, image processing is a specialized area, and I think it 
might well be better served by using a specialized (already written) 
package, such as ImageMagick, or PIL, or .... either through an 
external, a command-line or process call, or via RPC-like socket 
communication.

In fact, an RPC-like mechanism would also help with the ability to take 
full advantage of multi-core or multi-CPU systems. Since the near-term 
(5-10 year) growth in PC performance is likely to come from multiple 
processors rather than faster linear CPU cycle times, anyone doing image 
processing needs to be looking at using multiple threads or multiple 
processes to gain those benefits - and so an RPC-like mechanism has a 
lot going for it ...

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 01/07/2005