compileIt for revolution?

[Dennis Brown]

Dan,

I also would like to speed up array processing.  It kills me that my  
friend won't move from VB to Rev because when I write the same array  
processing problem that he uses, VB runs 10+ times faster than Rev.   
I also have had to jump through hoops trying to figure out ways to  
make my array processing go faster --it usually requires taking a  
simple script and making it 5 times as complicated as the way you  
would do it in VB or RB or any other ordinary language.  It is not  
just for the type of math problems that I am dealing with.  As visual  
effects become more important, being able to quickly process numeric  
arrays like a pixel image array becomes important.

However, I don't think compiling scripts is the answer.  I love  
having the interpreted environment for interactive debug and  
experimentation.  The UI is where all the code and debugging time is  
spent.  I don't want to trade that in for anything.  Rev is all about  
UI, but weak on array speed.   The language as it is defined would  
hardly be faster as a compiled version because of the type-less and  
stringy nature of the variables.  Compiled languages get their  
effeciency by the programmer telling them up front the data type and  
therefore the correspondence to specific machine code operators.   
There is no guessing or mixing of types.  The processing of numeric  
(or fixed length strings) hardly needs any checks at runtime.

What I advocate is a cross platform runtime package that is a pure  
fixed type, fixed operator, math orientated array language.  It can  
be PCode or threaded with very low overhead.  Languages with no UI  
considerations are very easy to create and code for a machine code  
programmer. I would like to see the basic operators and control  
structures to work on regular arrays of n dimensions.  I am not  
actually referring to "array" operators, just the ability to apply  
ordinary operators to one addressable array element at a time with  
efficient looping structures.  That should result in an order of  
magnitude increase in speed for the stuff that bogs Rev down, and  
open up Rev as a universal development tool.

The key is to have an efficient and elegant way for Rev to interface  
with such a package.   It needs to be able to pass the "program code"  
and pass array elements, rows, columns, and whole arrays to the  
coprocessor (really it just needs to be able to pass pointers to the  
array memory blocks).

As long as Rev has this Achilles heel, it will preclude it's use as a  
"real" programming language in the minds of many.

I did make a BZ enhancement request, but I think it could benefit  
from a discussion on this list.

Dennis


On Jun 22, 2005, at 1:27 AM, Dan Shafer wrote:

> Xavier....
>
> I guess we'll just have to agree to disagree about this.
>
> How in the world would you expect a compiled script or handler --  
> if such a thing were possible -- to then be smoothly integrated  
> into a stand-alone app?
>
> We needed CompileIt! in HyperCard *far* less for performance than  
> for code protection and the ability to deliver stuff that didn't  
> require the player to be around. Neither of those is an issue today  
> in Revolution.
>
> As for performance, tuning for such situations has produced  
> staggering results. I was blown away in Monterey last weekend to  
> watch a dynamically populated menu that was pulling its contents  
> from 100 text files appear in under a second. I've never heard much  
> here in the way of complaints about slow programs written in Rev.
>
> Dan
>
> On Jun 21, 2005, at 9:31 PM, MisterX wrote:
>
>
>> Dan,
>>
>> Creating apps with rev has NOTHING to do with compileIt.
>>
>> I really would like to speed up some scripts to manipulate
>> arrays (where rev has some serious limitations) and the best
>> possible way to do that would be to have something like
>> CompileIt.
>>