On Dec 1, 2004, at 1:22 PM, Joshua Scholar wrote:

> Well, I'm used to a sort of programming where the speed of loops is
> paramount.  In DSP programming, sound and graphics processing, an extra
> instruction or two in a loop can mean a massive speed difference to a
> program.

When you are talking this type of stuff, then really you are talking  
about doing a plugin.
A few years back I and others looked  at Altivec stuff for Squeak. What  
I found was that well we
do have a set of primtives to do vector math already. If the data is in  
Arrays we can make the
prim call and say add two vectors together. The problem was that adding  
a million elements takes
just a few milliseconds, but the overhead to setup the prim call and  
get at the data  took many ms.
So changing the cost from 2 milliseconds to less than 1 millisecond  
didn't make any difference to
the bottom line since it took 10 ms to get us to where we could do the  
math.

>
> Ok, maybe Smalltalk isn't so fast at number crunching anyway, but  
> still the
> speed of simple loops can make a massive difference in my experience.
> Whenever you have a lot of data to loop over and simple processing to  
> do on
> that data, the speed of the loop itself is very important.
>
> I was thinking about iteration and closures the other day.  Smalltalk  
> blocks
> are becoming the equivalent of lambdas, but in Scheme, the block  
> inside of a
> loop does not have to be a lambda, and can use the outer environment I
> think...  So when we slow our loops down in order to create a new
> environment for each iteration, we're doing something that Scheme and  
> Lisp
> didn't I think.  I'll have to write some Scheme programs to be sure.
>
> Anyway there may be some optimization for iteration there, once we've  
> gone
> to block closures.  Perhaps a block environment can have a flag that
> mentions whether it has ever become visible, and the loop code will  
> create
> new environment only if the old one was visible.

Well the question really is do we have fully closed, partial closed or  
full context blocks
where accessing information outside the block is expensive, and or as  
you notice sending
an "value:" is expensive. VW for example can make fully closed blocks  
and drag temps making them local into it, versus
having to refer to them outside the current context.

>
> On a similar note to the original topic (loops that crunch), one of my  
> long
> term goals is to learn Squeak well enough to implement a sublanguge or  
> tools
> that makes Squeak a suitable environment for Sound processing / DSP
> development.  I want to compile to Slang - though there may be some  
> problem
> with garbage collecting and calls out of Slang code into byte  
> interpreted
> code... Is it possible to unlink/relink Slang generated C code at run  
> time?
> In other words can I make Slang compilation transparent?  Basically I  
> want
> some tools to convert a more abstract language into Slang and to hide  
> all of
> that plug-in linking stuff.

Technically you could make a shell call to compile SLANG generated  
code, unload an existing primitive and reload the primitive.
There is VM support for doing the unload/load part, but I'm not sure if  
it really works correctly? Somehow the fun of creating a bad
chunk of slang code that you compile and attemp to run(crash) as you  
are fiddle with your development environment might be interesting.
Don't forget it's easy to corrupt Oops memory...  Still tho if you are  
assembling components to produce a plugin call, that could be quite  
safe & feasible.

>
> Joshua Scholar
>
>
>
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===