<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hybrid Programming on Boyang Yue</title><link>http://blog.boyangyue.com/tags/hybrid-programming/</link><description>Recent content in Hybrid Programming on Boyang Yue</description><generator>Hugo</generator><language>en-us</language><copyright>A Good Year Ahead</copyright><lastBuildDate>Fri, 08 Oct 2021 14:00:00 +0800</lastBuildDate><atom:link href="http://blog.boyangyue.com/tags/hybrid-programming/index.xml" rel="self" type="application/rss+xml"/><item><title>When the Python Interpreter Is the Bottleneck</title><link>http://blog.boyangyue.com/2021/10/when-the-python-interpreter-is-the-bottleneck/</link><pubDate>Fri, 08 Oct 2021 14:00:00 +0800</pubDate><guid>http://blog.boyangyue.com/2021/10/when-the-python-interpreter-is-the-bottleneck/</guid><description>&lt;p&gt;Consider the logistic map, a one-line recurrence, iterated 10 million times. The computation does no I/O and spends almost all its time executing a handful of floating-point operations in a Python loop. Rewriting that loop in C++ can produce a large speedup. Most Python performance problems are not this clean.&lt;/p&gt;
&lt;p&gt;Performance-sensitive Python already delegates much of its work to compiled code. NumPy, image codecs, and compression libraries do not execute their inner loops as Python bytecode. Interpreter overhead matters when the hot computation remains in Python and no existing library can absorb it. In that case, &lt;a href="https://github.com/tbenthompson/cppimport" target="_blank" rel="nofollow noopener noreferrer"&gt;cppimport&lt;/a&gt; can compile a small C++ extension as part of the import process. First, though, the profiler has to show that the loop is the problem.&lt;/p&gt;</description></item></channel></rss>