Hi Eliot,

Eliot Miranda wrote:
> Hi Juan,
>
> On Wed, Dec 17, 2008 at 5:31 AM, Juan Vuletich <juan at jvuletich.org 
> <mailto:juan at jvuletich.org>> wrote:
>
>     Hi Andreas, Eliot,
>
>     Thank you very much for this effort, for funding it, and for
>     making it available to the community!
>
>         ... it is possible (albeit unlikely at this point) that the
>         focus might shift towards FFI speed or float inlining....
>
>
>     Can you tell a bit more about "float inlining"? I guess you're
>     talking about immediate (unboxed) floats, right? That could mean
>     no longer need to do plugins for numerical stuff. I would love to
>     have that!
>
>
>  I tried to post a reply yesterday but hit the 100k limit and the list 
> moderator refused to let my reply in anyway. 

If you Eliot have a limit to what you can say in this list, someone is 
really wrong!
>
> There are two things here.  Yes, one is doing immediate floats in a 
> 64-bit VM, which can produce floating-point that runs at half 
> SmallInteger speed, perhaps three times faster than boxed floats.

Yes! That would already be great.
>
> But much more interesting is an adaptive optimization/speculative 
> inlining scheme which aims to map floating-point operations down to 
> the processor's floating-point registers.  ere;s an abstract from my 
> AOStA design sketch (that I tried to post yesterday but was bounced) 
> that describes how this might be done.  The basic idea for an adaptive 
> optimizer is to use two levels, one bytecode to bytecode and another 
> bytecode to machine code.  The bytecode to bytecode level is written 
> in Smalltalk and is clever (does type analisys, inlining, etc).  The 
> bytecode to machine code level is not clever, but is processor-specific.
> ... big snip...

Thanks for all the detail.

> If this can work then yes, plugins could become a thing of the past. 
>  However, I doubt very much that Qwaq will fund me to do this.  Right 
> now with a Squeak VM that is 10 to 20 times slower than VisualWorks' 
> VM Qwaq Forums spends roughly 2/3rds of its time executing Smalltalk. 
>  The bulk of the rest of the time is in OpenGL.  The Cog JIT I'm 
> working on now should be able to reach ViaualWorks VM speeds and hence 
> the 66.6% should become no more than, say, 6% of entire execution 
> time, with say 90% of the time in OpenGL.
>
> A second stage JIT doing adaptive optimization/speculative inlining 
> could probably improve performance by another factor of three.  But 
> that would produce only a 4% improvement in Qwaq Forums performance. 
>  Yes, it might allow Qwaq to rewrite all their C plugin code in 
> Smalltalk and get the same performance from the Smalltalk code that 
> would then be easier to maintain and enhance etc.  But where is the 
> return on investment (ROI)?
>
> The system would not be measurably faster for Qwaq Forums.  The 
> maintainability/extensibility benefits are intangible and hard to sell 
> to investors.  Hence I don't see Qwaq funding this, and it it was my 
> call and my money I'd probably make the same decision.  However, we 
> haven't even begun to discuss this inside Qwaq so you never know.
>
> best
> Eliot

I see.

I can see a great use for such technology in Morphic 3. This is my 
project for redesigning Morphic. It makes heavy use of floating point 
for all the rendering. It currently uses a plugin, but that makes it 
harder to extend and enhance it. May be some day it could become a 
reason to actually do what you describe, and a means to get funding for it.

Thanks for your detailed answer.

Cheers,
Juan Vuletich