https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/REDMINE1D-340 1D Redmine <p><em><font color="#505f79"> Created on 2023-10-19 14:15:44 by Didier Vibert. % Done: 100</font></em></p> <p>The wrapper (pyconv.h) was written to be able to bind std::vector to numpy arrays. This wrapper has a drawback since it returns a raw pointer to the std::vector data buffer without having the property of this vector. Thus it is not controlling the life-time of the buffer which may not survive the use of the returned pointer that seems to be directly bind by swig to the numpy array buffer.</p> <p>we can remove all these wrappers, since swig is able to bind a std::vector to a python list, and then we can convert the list to a numpy array in the python API code.</p> <p>we should also check if swig 4 is able to bind a std::vector to a numpy array without any wrapper... If I am correct I think it can !</p> <p>MR: <a href="https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/561" class="external-link" rel="nofollow">https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/561</a></p> REDMINE1D-340

[RM-8427] [swing bindings] remove the std::vector -> numpy array wrapper

Task Normal Done Done Redmine-Jira Migtation Redmine-Jira Migtation Thu, 19 Oct 2023 18:16:34 +0000 Mon, 13 Nov 2023 18:20:55 +0000 Mon, 13 Nov 2023 18:20:55 +0000 0 1 <p>Comment by Didier Vibert on 2023-10-20 09:12:02:</p> <h2><a name="laconversionsimpleimplique2copies"></a>la conversion simple implique 2 copies</h2> <p>en creusant un peu, la solution d'abandonner les wrapper et de passer par la simple conversion a l'inconvénient de génèrer 2 copies...</p> <p>&lt;pre&gt;<br/> std::vector -<del><span class="error">&#91;swig std_vector.i&#93;</span></del><del>&gt; python tuple --<span class="error">&#91;python api&#93;</span></del>-&gt; numpy array<br/> &lt;/pre&gt; </p> <h2><a name="l%27impl%C3%A9mentationactuelle%2Caucunecopie%2CMAIS..."></a>l'implémentation actuelle, aucune copie, MAIS...</h2> <p>&lt;pre&gt;<br/> std::vector -<del><span class="error">&#91;swig numpy.i (Argout View Arrays)&#93;</span></del>-&gt; numpy array (même buffer que celui du std::vector)<br/> &lt;/pre&gt;<br/> ne génère aucune copie si on passe l'adresse du buffer du std::vector mais pose alors le problème de durée de vie du buffer (cf "Argout View Arrays":<a href="https://numpy.org/doc/stable/reference/swig.interface-file.html#argout-view-arrays" class="external-link" rel="nofollow">https://numpy.org/doc/stable/reference/swig.interface-file.html#argout-view-arrays</a>) </p> <p>&gt; There is almost no way to guarantee that the internal data from the C code will remain in existence for the entire lifetime of the NumPy array that encapsulates it. If the user destroys the object that provides the view of the data before destroying the NumPy array, then using that array may result in bad memory references or segmentation faults. Nevertheless, there are situations, working with large data sets, where you simply have no other choice.</p> <p>Avec cette solution on peut à la place allouer dans le wrapper et copier le contenu, dans ce cas plus de risque de destruction intempestive du buffer, mais une fuite mémoire, car la desallocation du nouveau buffer ne sera jamais faite.</p> <h2><a name="Alternative%2Cavecunecopie"></a>Alternative, avec une copie</h2> <p>Il y a une autre possibilité, qui génère une seule copie au lieu de deux, en modifiant le wrapper actuel, toujours via numpy.i mais en utilisant cette fois des "Memory Managed Argout View Arrays":<a href="https://numpy.org/doc/stable/reference/swig.interface-file.html#memory-managed-argout-view-arrays" class="external-link" rel="nofollow">https://numpy.org/doc/stable/reference/swig.interface-file.html#memory-managed-argout-view-arrays</a> :<br/> &lt;pre&gt;<br/> std::vector -<del><span class="error">&#91;swig numpy.i (Memory Managed Argout View Arrays)&#93;</span></del>-&gt; numpy array (buffer alloué par le wrapper, désalloué par le code python à la disparition du numpy array)<br/> &lt;/pre&gt;</p> <p>(cf <a href="https://scipy-cookbook.readthedocs.io/items/SWIG_Memory_Deallocation.html" class="external-link" rel="nofollow">https://scipy-cookbook.readthedocs.io/items/SWIG_Memory_Deallocation.html</a>)</p> <p>L'utilisation des "Memory Managed Argout View Arrays" permet de transférer à python le contenu d'un std::vector dont on ne connait pas la taille à l'avance, et dont pyhon va manager la desallocation (il faut alors allouer et copier le contenu du std::vector dans le wrapper c++)</p> <p>Note: On peut aussi arriver au même résultat en utilisant des "Argout Arrays":<a href="https://numpy.org/doc/stable/reference/swig.interface-file.html#argout-arrays" class="external-link" rel="nofollow">https://numpy.org/doc/stable/reference/swig.interface-file.html#argout-arrays</a> mais dans ce cas, lors de l'appel python pour retourner le tableau, il faut passer en argument la taille du tableau retourné (pour que swig alloue un numpy array de la bonne taille avant):<br/> &lt;pre&gt;&lt;code class="python"&gt;<br/> myarray = PC.Get_Float64Array(binded_vector, known_size)<br/> &lt;/code&gt;&lt;/pre&gt;<br/> ce qui est moins "pythonic" mais faisable dans notre cas car nous voulons des getter sur des vecteurs déjà construits et dont on peut connaitre la taille en exportant une fonction qui la retourne.</p> <h2><a name="Alternativesanscopies"></a>Alternative sans copies</h2> <p>pas trouvé sans avoir de problèmes de memory management. </p> <p>Comment by Ali Allaoui on 2023-10-20 09:14:23:<br/> On ne fait pas ça un moment critique point de vue mémoire ou performance, donc de mon point de vue ce n'est pas grave de faire deux copies</p> <p>Comment by Didier Vibert on 2023-10-20 09:26:16:<br/> Ali Allaoui wrote in #note-2:<br/> &gt; On ne fait pas ça un moment critique point de vue mémoire ou performance, donc de mon point de vue ce n'est pas grave de faire deux copies</p> <p>c'est pas faux, aujourd'hui. </p> <p>De toute façon il faut modifier le code dans un sens ou dans l'autre, et ce n'est bien compliqué d'implémenter la version économe avec ce qu'on a déjà (pas de modif du code python, une allocation et copie à ajouter dans les fonctions de pyconv.h, et la déclaration modifiée pour passer des memory managed argout view arrays dans redshift.i)</p> <p>Comment by Didier Vibert on 2023-10-27 13:12:59:<br/> finalement j'ai implémenté la conversion vector -&gt; numpy<br/> qui gagne un peu en vitesse et en mémoire</p> <p>Comment by Pierre-yves Chabaud on 2023-11-10 15:17:23:<br/> Merged into @develop@ (@8e65b718@)</p> Development Rank 0|zzt01j: