14

I am trying to use Cython to code my project.

My plan is to write .dll in C++, and call them from Python via Cython. So I can have high computational performance of C++, while keeping the simplicity of development of Python.

As I go further, I am a bit confused. As I understand, Cython wraps python code into C. The performance is improved since C has better calculation performance. Am I correct at this?

If I am right above, then is it necessary to write .dll in C++ and call it from Python in order to improve the performance?

If I write python code and wrap it into C, then call it from Python, does it perform better than calling .dll that written in C++?

user3745189
  • 521
  • 1
  • 7
  • 17
ChangeMyName
  • 7,018
  • 14
  • 56
  • 93
  • Looks like you gonna have to check and see. Maybe publish the results somewhere – raam86 Oct 04 '13 at 13:24
  • 3
    Cython can be roughly 30x the speed of python in a specific setting, and is maybe half the speed of C https://notes-on-cython.readthedocs.io/en/latest/std_dev.html – Jonathan Aug 18 '18 at 07:57

1 Answers1

4

First of all, let me disband a few misconceptions that you seem to have.

  • Calling a library from another program will speed up your library.

No, no, no, no, no. This makes about as much sense as saying "driving a car at a set speed is slower than having a F1 racer drive a car at the same speed". It just makes no sense. When Python loads your library, it loads and processes it similar to how the kernel loads and processes it (in fact, the kernel does that in Python's case too). In fact, this "double loading" (which wasn't the original design for dynamic libraries) can slow down your library. I should emphasise that this is a tiny difference, and should not concern the ordinary programmer.

  • Cython "wraps" Python code into C

It doesn't. It compiles the python code into C, which is then compiled into a dynamic library for Python to load later. This may optimise your Python code somewhat, and give you the ability to interface with atomic C data types, with Python's magic sauce on top. While this is pretty cool, it doesn't give your code any "magical" abilities.

I would also like to add that some tests have proven that Java is (drum roll) actually faster than C, C++, Python and other languages because the JVM is very optimised. That doesn't mean you should use Java (because it has other problems), but it should give perspective.

cyphar
  • 2,840
  • 1
  • 15
  • 25
  • 2
    I want to clarify one of your points. The language you write your code in __can__ have a significant impact on performance. The difference between C, C++ and Fortran can be small, but the difference between C and Python can be quite large. For example, if we look at [Debian's shootout project](http://benchmarksgame.alioth.debian.org/u32/performance.php?test=nbody), the nbody algorithm can be done in 9 seconds in C, but it takes over 18 minutes in Python. – Bill Lynch Oct 04 '13 at 14:08
  • Sorry, my points are mostly about compiled languages. Interpreted languages are generally slower (especially with certain algorithms). – cyphar Oct 04 '13 at 14:18
  • 2
    Even looking only at compiled languages, the differences in performance can be significant. In the example @sharth linked, the best C program is over twice as fast as the best Fortran (in other cases, the opposite may be true). Other cases have greater differences. The language *does* have a significant impact. Specifically, the combination of language, algorithm, system architecture, and compiler optimizations *does* make a significant difference. – bogatron Oct 04 '13 at 14:45
  • 1
    @cyphar Thanks for yor answer. As far as I know, some of the banks are using the similar architecture. They write .dll in C++ or other high performance languages, and call them in Python. In this case, the financial analysts who may less experienced in programming can easily develop analytical programs. And this is where my idea from. – ChangeMyName Oct 04 '13 at 14:49
  • 1
    @bogatron it is important to understand that the algorithms, architecture and compiler make the _most_ significant difference. I never stated there wasn't a difference between languages, but it shouldn't be a major concern compared to the major concern of well-designed algorithms. – cyphar Oct 04 '13 at 14:51
  • 1
    @cyphar In my plan, I'm going to deal with large chunks of data and a lot of computaion within objects and across classes. So I'd like to use C++ since it supports multithreading while Python banned it with GIL. – ChangeMyName Oct 04 '13 at 14:54
  • @cyphar The first sentence of your concluding paragraph states "So, to conclude, **no** the language you write your library in does **not** generally have a significant impact on the speed of the library." – bogatron Oct 04 '13 at 14:58
  • @bogatron "... it does not _generally_". How would you like me to phrase it? – cyphar Oct 04 '13 at 15:01
  • 1
    You already clarified the confusion regarding cython generating (vice wrapping) C and that calling the library from another program won't speed the library. @NewLong appears to understand that C & C++ are faster than python. Making statements that a library's implementation language is generally not significant (as in your first and last paragraphs) is misleading at best and gets off topic. I recommend removing those statements from your otherwise informative answer. – bogatron Oct 04 '13 at 15:29
  • It's somewhat misleading to suggest that Java is faster than C or C++ because it has only proven to outperform C in specific scenarios against an unoptimized C binary. In the general case, a C/C++ binary compiled with optimization flags will consistently outperform Java by a considerable margin. – James M. Lay Oct 06 '20 at 03:53