编译之前使用Python代码进行原型制作 [英] Prototyping with Python code before compiling

问题描述

一段时间以来，我一直在考虑编写峰拟合库。我对Python相当了解，并计划从Python开始实现所有功能，但我设想最终可能必须重新以编译语言实现一些核心例程。

I have been mulling over writing a peak-fitting library for a while. I know Python fairly well and plan on implementing everything in Python to begin with but envisage that I may have to re-implement some core routines in a compiled language eventually.

IIRC，Python的其中之一最初的职责是作为一种原型语言，但是Python在允许将函数，函子，对象传递给函数和方法方面相当宽松，而我怀疑C或Fortran并非如此。

IIRC, one of Python's original remits was as a prototyping language, however Python is pretty liberal in allowing functions, functors, objects to be passed to functions and methods, whereas I suspect the same is not true of say C or Fortran.

我对设计将要与编译语言接口的函数/类有什么了解？这些潜在问题中有多少是由cTypes，bgen， SWIG ， Boost.Python ， Cython 或 Python SIP ？

What should I know about designing functions/classes which I envisage will have to interface into the compiled language? And how much of these potential problems are dealt with by libraries such as cTypes, bgen, SWIG, Boost.Python, Cython or Python SIP?

对于这个特殊的用例（拟合库），我想允许用户将数学函数（Guassian，Lorentzian等）定义为Python函数，然后可以由编译后的代码拟合库传递解释。传递和返回数组也是必不可少的。

For this particular use case (a fitting library), I imagine allowing users to define mathematical functions (Guassian, Lorentzian etc.) as Python functions which can then to be passed an interpreted by the compiled code fitting library. Passing and returning arrays is also essential.

推荐答案

最后一个问题，我确实可以对:)给出值答案。

Finally a question that I can really put a value answer to :).

我研究了f2py，boost.python，swig，cython和pyrex作为我的工作（光学测量技术的博士学位）。我广泛使用swig，一些使用boost.python，很多使用pyrex和cython。我还使用了ctypes。这是我的细分：

I have investigated f2py, boost.python, swig, cython and pyrex for my work (PhD in optical measurement techniques). I used swig extensively, boost.python some and pyrex and cython a lot. I also used ctypes. This is my breakdown:

免责声明：这是我的个人经历。我没有参与任何这些项目。

Disclaimer: This is my personal experience. I am not involved with any of these projects.

痛饮：
在c ++中不能很好地发挥作用。它应该，但是链接步骤中的名称修改问题使我在linux& Mac OSX。如果您具有C代码并希望将其连接到python，则这是一个很好的解决方案。我根据自己的需要包装了GTS，并且基本上需要编写一个可以连接到的C共享库。我不推荐它。

swig: does not play well with c++. It should, but name mangling problems in the linking step was a major headache for me on linux & Mac OS X. If you have C code and want it interfaced to python, it is a good solution. I wrapped the GTS for my needs and needed to write basically a C shared library which I could connect to. I would not recommend it.

Ctypes：
我使用ctypes编写了一个libdc1394（IEEE相机库）包装器，非常有经验的经验。您可以在 https://launchpad.net/pydc1394 上找到该代码。将标头转换为python代码需要做很多工作，但是随后一切都可以可靠地工作。如果要连接外部库，这是一个好方法。 Ctypes也位于python的stdlib中，因此每个人都可以立即使用您的代码。这也是快速处理python中新库的好方法。我可以推荐它连接到外部库。

Ctypes: I wrote a libdc1394 (IEEE Camera library) wrapper using ctypes and it was a very straigtforward experience. You can find the code on https://launchpad.net/pydc1394. It is a lot of work to convert headers to python code, but then everything works reliably. This is a good way if you want to interface an external library. Ctypes is also in the stdlib of python, so everyone can use your code right away. This is also a good way to play around with a new lib in python quickly. I can recommend it to interface to external libs.

Boost.Python ：非常有趣。如果您已经拥有要在python中使用的自己的C ++代码，请执行此操作。通过这种方式将c ++类结构转换为python类结构非常容易。如果您有在python中需要的c ++代码，我建议您这样做。

Boost.Python: Very enjoyable. If you already have C++ code of your own that you want to use in python, go for this. It is very easy to translate c++ class structures into python class structures this way. I recommend it if you have c++ code that you need in python.

派热克斯/赛昂：使用赛昂，而不是派热克斯。期。 Cython更先进，使用更有趣。如今，我使用cython来做所有的事情，就像我过去使用SWIG或Ctypes一样。如果您的python代码运行得太慢，这也是最好的方法。这个过程绝对是太棒了：您将python模块转换为cython模块，进行构建，并像python一样进行性能分析和优化（无需更改工具）。然后，您可以应用与Python代码混合的尽可能多（或少）C代码。这比用C重写应用程序的整个部分要快得多。您只需要重写内部循环。

Pyrex/Cython: Use Cython, not Pyrex. Period. Cython is more advanced and more enjoyable to use. Nowadays, I do everything with cython that i used to do with SWIG or Ctypes. It is also the best way if you have python code that runs too slow. The process is absolutely fantastic: you convert your python modules into cython modules, build them and keep profiling and optimizing like it still was python (no change of tools needed). You can then apply as much (or as little) C code mixed with your python code. This is by far faster then having to rewrite whole parts of your application in C; you only rewrite the inner loop.

定时：ctypes的调用开销最高（〜700ns），其次是boost.python（322ns），然后是swig（290ns） ）。 Cython的通话开销最低（124ns），而花时间的最佳反馈（cProfile支持！）。这些数字从我的盒子中调用了一个琐碎的函数，该函数从交互式外壳返回一个整数；因此，模块导入开销不会计时，仅函数调用开销会计时。因此，通过概要分析和使用cython来快速获取python代码是最简单，最有效的方法。

Timings: ctypes has the highest call overhead (~700ns), followed by boost.python (322ns), then directly by swig (290ns). Cython has the lowest call overhead (124ns) and the best feedback where it spends time on (cProfile support!). The numbers are from my box calling a trivial function that returns an integer from an interactive shell; module import overhead is therefore not timed, only function call overhead is. It is therefore easiest and most productive to get python code fast by profiling and using cython.

摘要：对于您的问题，请使用Cython;） 。我希望这个摘要对某些人有用。我会很乐意回答任何剩余的问题。

Summary: For your problem, use Cython ;). I hope this rundown will be useful for some people. I'll gladly answer any remaining question.

编辑：我忘了提：出于数字目的（即与NumPy的连接）使用Cython；他们对此有支持（因为他们基本上为此目的开发了cython）。因此，这应该是您决定的另一个+1。

Edit: I forget to mention: for numerical purposes (that is, connection to NumPy) use Cython; they have support for it (because they basically develop cython for this purpose). So this should be another +1 for your decision.

这篇关于编译之前使用Python代码进行原型制作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！