compileIt for revolution?

[MisterX]

then maybe the key is to have better array handlers like filter does for
lines for example...

is that what you mean?

Note that creating an external is just a function call in any script so the
script impact is minimal - actually, it does make scritps simpler...

And to rebute another of Dan's points whence we HyperCarders used externals
to hide code, this can still apply to rev! You can keep an easy GUI that
modifiable by the user but keep the real code away.

Here's one idea to give Dan an idea of the speed difference: Sorry for the
vetusty of the story:

I wrote a codec in HyperTalk that took 24 hours processing in HC on a
Powerbook 140.

Sorry, i wont test it today in rev and what it did is also irrelevant - too
involved.

Rewritten in C (6 months time longuer than HCs' script), the code took 16
ticks on the same powerbook. 

2 years ago i tried translating some Neural network C code. Same problem: 5
hours to run the runRev example as optimized as i could. In C it would take
a big 2 seconds!

The whole compileIT is not required but an internal module to create
ultra-fast native code would be great. Now that would be a programmer's tool
worth any eye candy in RunRev.

Dan, at work, i hardly ever treat lists that have less than 3X20X2000
objects imbricated in them. I need to run results on those a lot. Believe me
that those 15 seconds required sometimes can even be stressing sometimes
(usually friday late afternoons ;)

cheers
Xavier 

> -----Original Message-----
> From: use-revolution-bounces at lists.runrev.com 
> [mailto:use-revolution-bounces at lists.runrev.com] On Behalf Of 
> Dennis Brown
> Sent: Wednesday, June 22, 2005 15:40
> To: How to use Revolution
> Subject: Re: compileIt for revolution?
> 
> 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.
> >>
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage 
> your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>