Hi Loup
Actually, your last guess was how we thought most of the optimizations would be
done (as separate code "guarded" by the meanings). For example, one idea was
that Cairo could be the optimizations of the "graphics meanings code" we would
come up with. But Dan Amelang did such a great job at the meanings that they
ran fast enough tempt us to use them directly (rather than on a supercomputer,
etc.). In practice, the optimizations we did do are done in the translation
chain and in the run-time, and Cairo never entered the picture.
However, this is a great area for developing more technique for how "math" can
be made practical -- because the model is so "pretty" and "compact" -- and
there is much more that could be done here.
Why can't a Nile backend for the GPU board be written? Did I miss something?
Cheers,
Alan
>________________________________
> From: Loup Vaillant <[email protected]>
>To: [email protected]
>Sent: Wednesday, February 8, 2012 1:29 AM
>Subject: Re: [fonc] Raspberry Pi
>
>Jecel Assumpcao Jr. wrote:
>> Alan Kay wrote:
>>> We have done very little of this so far, and very few optimizations. We can
>>> give
>>> live dynamic demos in part because Dan Amelang's Nile graphics system turned
>>> out to be more efficient than we thought with very few optimizations.
>>
>> Here is were the binary blob thing in the Raspberry Pi would be a
>> problem. A Nile backend for the board's GPU can't be written, and the
>> CPU can't compare to the PCs you use in your demos.
>
>Maybe as a temporary workaround, it would possible to use OpenGL (or
>OpenCL, if available) as the back-end? It would require loading a
>whole Linux kernel, but maybe this could work? </wild_speculation>
>
>
>>> I think it could be an valuable project for interested parties to see about
>>> how to
>>> organize the separate "optimization spaces" that use the meanings as
>>> references.
>>
>> I didn't get the part about "meanings as references".
>
>I understood that "meanings" meant "the concise version of Frank". The
>"optimization space" would then be a set of correctness-preserving
>compilers passes or interpreters. (I believe Frank already features
>some of that.)
>
>Or, re-written versions that are somehow guaranteed to behave the same
>as the concise version they derive from, only faster. But I'm not sure
>that's the spirit.
>
>Loup.
>_______________________________________________
>fonc mailing list
>[email protected]
>http://vpri.org/mailman/listinfo/fonc
>
>
>
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
