8 Feb 2012 16:23
Re: Raspberry Pi
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 <l <at> loup-vaillant.fr>
To: fonc-uVco7kAcSAQ@public.gmane.org
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
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc
<div><div> <div><span>Hi Loup</span></div> <div> <br><span></span> </div> <div><span>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.<br></span></div> <div><br></div> <div>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.</div> <div><br></div> <div>Why can't a Nile backend for the GPU board be written? Did I miss something?</div> <div><br></div> <div>Cheers,</div> <div><br></div> <div>Alan<br> </div> <div><br></div> <div> <br><blockquote> <div> <div> <div dir="ltr"> <span>From:</span> Loup Vaillant <l <at> loup-vaillant.fr><br><span>To:</span> fonc@... <br><span>Sent:</span> Wednesday, February 8, 2012 1:29 AM<br><span>Subject:</span> Re: [fonc] Raspberry Pi<br> </div> <br> Jecel Assumpcao Jr. wrote:<br>> Alan Kay wrote:<br>>> We have done very little of this so far, and very few optimizations. We can give<br>>> live dynamic demos in part because Dan Amelang's Nile graphics system turned<br>>> out to be more efficient than we thought with very few optimizations.<br>><br>> Here is were the binary blob thing in the Raspberry Pi would be a<br>> problem. A Nile backend for the board's GPU can't be written, and the<br>> CPU can't compare to the PCs you use in your demos.<br><br>Maybe as a temporary workaround, it would possible to use OpenGL (or<br>OpenCL, if available) as the back-end? It would require loading a<br>whole Linux kernel, but maybe this could work? </wild_speculation><br><br><br>>> I think it could be an valuable project for interested parties to see about how to<br>>> organize the separate "optimization spaces" that use the meanings as references.<br>><br>> I didn't get the part about "meanings as references".<br><br>I understood that "meanings" meant "the concise version of Frank". The<br>"optimization space" would then be a set of correctness-preserving<br>compilers passes or interpreters. (I believe Frank already features<br>some of that.)<br><br>Or, re-written versions that are somehow guaranteed to behave the same<br>as the concise version they derive from, only faster. But I'm not sure<br>that's the spirit.<br><br>Loup.<br>_______________________________________________<br>fonc mailing list<br><a ymailto="mailto:fonc@..." href="mailto:fonc@...">fonc@...</a><br>http://vpri.org/mailman/listinfo/fonc<br><br><br> </div> </div> </blockquote> </div> </div></div>
RSS Feed