<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 02.01.2018 15:22, Jerome Kieffer
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20180102212201.69978472@mac13.esrf.fr">
<pre wrap="">On Tue, 02 Jan 2018 15:37:16 +0000
Yasunori Endo <a class="moz-txt-link-rfc2396E" href="mailto:jo7ueb@gmail.com"><jo7ueb@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">If the reason is just about human resources,
I'd like to try implementing GPU support on my NumPy fork.
My goal is to create standard NumPy interface which supports
both CUDA and OpenCL, and more devices if available.
</pre>
</blockquote>
<pre wrap="">
I think this initiative already exists ... something which merges the
approach of cuda and opencl but I have no idea on the momentum behind
it.
</pre>
<blockquote type="cite">
<pre wrap="">Are there other reason not to support GPU on NumPy?
</pre>
</blockquote>
<pre wrap="">
yes. Matlab has such support and the performances gain are in the order
of 2x vs 10x when addressing the GPU directly. All the time is spent in
sending data back & forth. Numba is indeed a good candidate bu limited
to the PTX assembly (i.e. cuda, hence nvidia hardware) </pre>
</blockquote>
<br>
This suggests a new, higher-level data model which supports
replicating data into different memory spaces (e.g. host and GPU).
Then users (or some higher layer in the software stack) can dispatch
operations to suitable implementations to minimize data movement.<br>
<br>
Given NumPy's current raw-pointer C API this seems difficult to
implement, though, as it is very hard to track memory aliases.<br>
<br>
Regards,<br>
<div class="moz-signature"><br>
<div class="moz-signature"><img moz-do-not-send="false"
src="cid:part1.B2727AA2.89A243BB@seefeld.name" alt="Stefan"
width="73" height="45"><br>
<pre>--
...ich hab' noch einen Koffer in Berlin...
</pre>
</div>
</div>
</body>
</html>