<br><br><div class="gmail_quote">On Thu, Aug 6, 2009 at 4:36 PM, Sturla Molden <span dir="ltr">&lt;<a href="mailto:sturla@molden.no">sturla@molden.no</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Charles R Harris wrote:<br>
&gt; Whether the code that gets compiled is written using lazy evaluation<br>
&gt; (ala Sturla), or is expressed some other way seems like an independent<br>
&gt; issue. It sounds like one important thing would be having arrays that<br>
&gt; reside on the GPU.<br>
</div>Memory management is slow compared to computation. Operations like<br>
malloc, free and memcpy is not faster for VRAM than for RAM. There will<br>
be no benefit from the GPU if the bottleneck is memory. That is why we<br>
need to get rid of the creation of temporary arrays, hence lazy evaluation.<br>
<br>
Having arrays reside in VRAM would reduce the communication between RAM<br>
and VRAM, but the problem with temporary arrays is still there.<br>
</blockquote><div><br>I&#39;m not arguing with that, but I regard it as a separate problem. One could, after all, simply use an expression to GPU compiler to generate modules. The question is what simple additions we can make to numpy so that it acts as a convenient io channel. I mean, once the computations are moved elsewhere numpy is basically a convenient way to address memory.<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Also VRAM tends to be a limited resource.<br>
<font color="#888888"></font></blockquote><div><br>But getting less so. These days it comes in gigabytes and there is no reason why it shouldn&#39;t soon excede what many folks have for main memory.<br><br>Chuck <br></div>
<br></div>