<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 12.03.2015 um 13:48 schrieb Julian Taylor <<a href="mailto:jtaylor.debian@googlemail.com" class="">jtaylor.debian@googlemail.com</a>>:</div><br class="Apple-interchange-newline"><div class="">On 03/12/2015 10:15 AM, Gregor Thalhammer wrote:<br class=""><blockquote type="cite" class=""><br class="">Another note, numpy makes it easy to provide new ufuncs, see <br class=""><a href="http://docs.scipy.org/doc/numpy-dev/user/c-info.ufunc-tutorial.html" class="">http://docs.scipy.org/doc/numpy-dev/user/c-info.ufunc-tutorial.html</a><br class="">from a C function that operates on 1D arrays, but this function needs to<br class="">support arbitrary spacing (stride) between the items. Unfortunately, to<br class="">achieve good performance, vector math libraries often expect that the<br class="">items are laid out contiguously in memory. MKL/VML is a notable<br class="">exception. So for non contiguous in- or output arrays you might need to<br class="">copy the data to a buffer, which likely kills large amounts of the<br class="">performance gain.<br class=""></blockquote><br class="">The elementary functions are very slow even compared to memory access,<br class="">they take in the orders of hundreds to tens of thousand cycles to<br class="">complete (depending on range and required accuracy).<br class="">Even in the case of strided access that gives the hardware prefetchers<br class="">plenty of time to load the data before the previous computation is done.<br class=""><br class=""></div></blockquote><div><br class=""></div><div>That might apply to the mathematical functions from the standard libraries, but that is not true for the optimized libraries. Typical numbers are 4-10 CPU cycles per operation, see e.g. </div><div><a href="https://software.intel.com/sites/products/documentation/doclib/mkl_sa/112/vml/functions/_performanceall.html" class="">https://software.intel.com/sites/products/documentation/doclib/mkl_sa/112/vml/functions/_performanceall.html</a></div><div><br class=""></div><div>The benchmarks at <a href="https://github.com/geggo/uvml" class="">https://github.com/geggo/uvml</a> show that memory access to main memory limits the performance for the calculation of exp for large array sizes . This test was done quite some time ago, memory bandwidth now typically is higher, but also computational power.</div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class="">This also removes the requirement from the library to provide a strided<br class="">api, we can copy the strided data into a contiguous buffer and pass it<br class="">to the library without losing much performance. It may not be optimal<br class="">(e.g. a library can fine tune the prefetching better for the case where<br class="">the hardware is not ideal) but most likely sufficient.<br class=""></div></blockquote><div><br class=""></div><div>Copying the data to a small enough buffer so it fits into cache might add a few cycles, this already impacts performance significantly. Curious to see how much.</div><div><br class=""></div><div>Gregor</div><br class=""><blockquote type="cite" class=""><div class=""><br class="">Figuring out how to best do it to get the best performance and still<br class="">being flexible in what implementation is used is part of the challenge<br class="">the student will face for this project.<br class="">_______________________________________________<br class="">NumPy-Discussion mailing list<br class=""><a href="mailto:NumPy-Discussion@scipy.org" class="">NumPy-Discussion@scipy.org</a><br class="">http://mail.scipy.org/mailman/listinfo/numpy-discussion<br class=""></div></blockquote></div><br class=""></body></html>