Ask HN: Is C/C++ really faster than Python?

See "The Computer Language Benchmarks Game" at http://benchmarksgame.alioth.debian.org/ for a head-to-head comparison of various small programs as measured across a wide number of language implementations. Do be careful that a "language" has no performance, only implementations of the language. For example, different implementations of Python may differ by an order of magnitude on a given task, as might different C compilers. Java and Javascript used to be considered slow languages, but the effective billions of dollars of R&D improved the implementations.

The overall solution space is complex. For example, development time on Python is about 1/2 that of C++ (the classic paper is http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprt_computer... - is there something more recent?). Since algorithms can trump raw performance, it may be that in 8 hours its possible to develop a more sophisticated implementation in Python which outperforms the naive implementation in C++.

In the late 1990s, when people started using Python for traditional supercomputing problems, the phrase was to use Python to "steer" the low-level code written in a faster language. For example, NumPy is a Python API which uses C/ Fortran/ assembly code at lower levels for doing array calculations. Thus, only some people need to be skilled in both levels, while most can focus on writing Python code. The actual code has parts written in multiple languages, and not "only C/C++".

The "Python is the language, not the implementation" answer has already been given by @dalke, so I'll answer whether cPython, the implementation of Python that Python developers commonly use, is slower than C/C++:

cPython is necessarily slower and uses more memory than C for most tasks, and that's because cPython is implemented in C. You couldn't expect a new programming language that was implemented in Python to be faster than Python, either.

This is less of a concern for scientists and others with very tough performance requirements than it otherwise would be, in part, because cPython code can delegate C and C++ code[0]. This means portions of your program that need to be highly optimized can be implemented in C or C++, while the rest of your program can continue to be written in Python.

[0] https://docs.python.org/3/extending/extending.html

If you consider the raw languages, C/C++ is indeed faster. But unfortunately it's not that easy.

It's easier and faster to write a program in python that in C++. So given limited programmer time, it might be possible to write a faster solution in python than in C/C++ because you have more time to optimize your algorithm instead of fighting with the compiler. If you have a big project, you can spend the extra programmer time you gain by using python by moving crucial code from python to C. The crucial code can be found by using a profiler. (Saw an article about this some time ago, but don't remember which company actually did this)

Finally, python has a lot of math libraries that offer good speed for computation intensive operations, see http://www.scipy.org/.

So yes, it's not that easy. I would suggest use Python because it programs easier/faster, and if you really run into a wall, you can always port parts to C.

Programming languages aren't slower or faster. The implementations of them are.

Provided no FFI or extensions written in other languages, non-I/O bound interpreted CPython is 50-100x slower than C/C++. JIT compiled (PyPy, etc.) Python might be in 2-10x slower bracket.

If extensions written in C/C++ are used, then you might be effectively comparing those extensions against another C/C++ implementation.

So if your code is going to be I/O bound and/or can effectively offload all computation in modules written in C/C++ (like NumPy), then Python might be practically as fast as C/C++.

If you use pure interpreted Python and implement compute limited algorithm in it, your code is going to be 50-100x slower than C/C++.

Real life scenarios are probably somewhere in between those two extreme cases.

It's basically 100% true. Any program written in python can be translated to an equivalently functioning C++ program which requires fewer expensive operations to run.

The Python VM is doing a fair bit more work per instruction it executes; for example, incrementing an int isn't going to be a simple register add, it's going to involve a pointer dereference, some comparisons and branches, execution of several C functions, and overhead for interpreting the VM bytecode.

That said, if you understand what Python is doing under the hood you can greatly speed up your programs and approach C++ performance in some areas.

That said, I strongly recommend all performance-sensitive code is written in C++ with wrappers to drive it from Python.

It is generally true. For the same algorithm, C++ can be hundereds of times faster, but sometimes you can push computations down to the C code in which the most popular Python implementation is written.

A very general approach to optimizing Python code is to look at all your loops and ask yourself which ones you can replace with library calls.

https://wiki.python.org/moin/PythonSpeed/PerformanceTips

Yes , and there is no point to ask questions like is X scripting is faster then c++ . each software that is running by software will be slower then native code .

I find Python's speed is highly uneven and dependent on what you are doing with it.

Are you doing something that has some kind of underlying C implementation (file I/O usually)? Then it should be pretty quick.

Are you doing something that is all handled by the Python interpreter? Expect it to be slower than you'd like. e.g. for loops in Python are usually slower than list comprehensions.

It can be kind of frustration to write a bunch of code that runs lightning quick and then suddenly see your runtimes explode when you add a few more fairly trivial lines to complete off some code. I'd almost rather Python had a more consistent performance profile even if it was a bit slower on average than fastest possible, because it would make it easier to reason about the performance of your code.

So far I mainly just use the default Python implementation, but if you're really struggling with it, it's probably worth it to look into using one of the JIT or JVM implementations for more consistent speed profiles.

BTW, there's also all sorts of weird performance tweaks in the community...mostly of the form of syntax A vs. syntax B, and I've found that surprisingly few of them are "real" or offer more than trivial speedups.

In other cases, in other languages, you know what you need to do to speed things up, but Python either doesn't offer that mechanism in the language or buries it under somewhere else (try finding out how to preallocate lots of entries in a dictionary instead of incrementally growing it, it exists, but it's almost impossible to find using search words like "preallocate")

If we load entire data into memory the difference is negligible.

What about PyPy? It generates native (JIT) code and run as fast as C.

The same code is faster (and easier) to write, correctly, in Python than in either C or C++. (this depends a little on what you're writing, but not much: C/C++ make you specify much more about your code than python does.)

The same code, however, will run faster on C/C++. This is because python is doing some of the work for you, and you did that work upfront when writing the C/C++.

If you are doing something which involves a lot of computation, which all fits in RAM (using numpy in python will make that a fairer test between the two choices), then C/C++ will be faster.

Remember that a good pattern is to write your high-level logic in Python, and write a python implementation of your app, and then profile it to work out the slow parts of the code and speed them up using Cython[1], which will allow you to convert python-like code to efficient C (you can also straight up borrow C/C++ implementations from other people, too). This pattern is designed to balance minimising both programmer-time (since you will only have to code the important bits in C) and run time (since the performance-critical bits can be optimised.)

[1] http://cython.org/

(for pedants: I am referring to the CPython implementation, which is the only one which supports C/C++ extensions.)

Yes. It's much faster. The reason C++ is fast is because you have explicit control over allocations and it compiles to native code (among other reasons). There are also a lot of subtle things that you can control in C++ that you can't in python, like memory layout. Memory layout is extremely important for CPU cache, and CPU cache is extremely important for performance. (Reading data from RAM is generally orders of a magnitude slower than reading from an L1 or L2 cache. For some reason this never gets mentioned in university CS courses, but there are a lot of data structures that are "theoretically" fast for certain things but in practice very unfriendly to hardware. For instance, linked lists. Sure insert/delete is O(1), but since linked lists are quite possibly the least cache friendly data structures in existence, you're better off with a vector/array even if you're inserting all the time. I'm not just making this up, you can read talks by people like Bjarne Stroustroup on this topic)

As to whether it matters for the algorithm, it depends on the algorithm. It's almost always going to be much faster in C, but, how fast do you really need it to be? Python is very good at saving programmer time, so if performance is not particularly important, I just wouldn't worry about it.

  struct City {
    char *name;
    int   popstrat[5];
    float bounds[2];
  };

  typedef struct
  {
      char* name;
      int   age;
  } prsnT1;
  prsnT1* peopleAOS = calloc(100, sizeof(*peopleAOS));

  typedef struct
  {
      char** name;
      int*   age;
  } prsnT2;
  prsnT2* peopleSOA = malloc(sizeof(*peopleSOA));
  peopleSOA->name   = calloc(100, sizeof(*peopleSOA->name));
  peopleSOA->age    = calloc(100, sizeof(*peopleSOA->age));

I wish people would stop saying "C/C++" , these are 2 different languages.

Python* itself is written in C, not in Python. Which should give you clues to mediate and find your own answers.

*: Python, the canonical implementation.

CPython is built more naively for lots of operations. A global lookup is a dictionary lookup. Getting a symbol out of an object is a dictionary lookup. An object creation is always an allocation; variables don't go on the stack. Everything is reference counted. The old 'range' builtin would create an actual list of that length in memory, rather than just keep track of the start and end points like a C-style for loop.

Other implementations could theoretically do better. PyPy can detect after a while that a variable can safely be declared on the stack, and so it will start to do that. If the object type is known, then a field lookup becomes just adding an offset to the pointer. It can even use different implementations for the same Python-visible classes (to store a range result in constant space, but still appear to be the full list, or use a different type of dictionary for objects and {}, or other things like that).

I implemented an algorithm in Python and C++. Heavily IO bound task, read a float, multiply it with a factor, save to another file. Input file was several Gigabytes. I didn't do any optimization and I'm a C++ noob. Python was 30 times slower.

What would be a good book to start to learn high performance C++ code?

Yes. Does it matter? It depends.

If you're writing a game in python, you're going to have a bad time. Yes, I know CCP does it, but from what I've heard their engine is C++, and even then it's been a long, uphill battle. You're just going to have a very hard time meeting soft-realtime performance constraints (e.g. 30ms or 15ms frames) if very much of your code is in python.

If you're doing a programming challenge, you'll probably be fine? I've never done a programming challenge, but my assumption is that getting a result is the goal, and the performance of the code that gets it isn't that big of a deal, so long as it runs in a reasonable amount of time.

Really, the point is that you aren't going to see algorithmic-level speed differences between C/C++ and python most of the time. There are cases where this is untrue (e.g. where the algorithm relies on low level memory control), but it's true enough. You'll see a constant factor speedup, ranging somewhere between small and massive. I've heard 100x is typical for code that runs mostly in python and isn't just calling out to C, C++, or Fortran.

That said, the 100x number could be way off. For compute intensive tasks, if you're using numpy, you'll see a much smaller speedup. If you're not using numpy, but are great at writing multicore and simd code, you could see a 100(num_vector_lanes)(num_cores), so on a recent quad-core intel chip, you might be able to get a 10084 = 3200x speedup. This would take a long time to write, only applies to problems that are both compute-bound and easily parallelizable, and could be overly optimistic, but you get the idea (I don't know where the 100x number comes from, and how well the C++ programs it was compared with were written -- if it's from Alioth, last I checked they tended to leave a lot of perf on the table, but are not too bad).

Also, cache friendliness can make a massive difference. I've seen 10x speedups in C++ programs by utilizing the cache better, and I've heard of people getting even more significant speedups. Python's implementation is extremely cache unfriendly, but writing cache friendly C++ programs is non-obvious to a lot of programmers (or they don't consider it, or something), so you might loose out here. Along these lines, if your memory allocation patterns in C++ are naive, your code won't perform very well, and a lot of C++ programmers fall victim to this.

So who knows. If you're great at C/C++, know your architecture, are excellent at parallization and SIMD, and have the right problem, the difference could be massive. Barring that, I'd guess you'd get something like a 10x-50x speed up for average code, which is a lot, but maybe not that significant

Sort of rambled there, hope that made sense.

P.S. A lot of this is only true for CPython. I hear PyPy is faster (still no simd, multicore, or memory allocation or layout control though, so I suspect you can still beat it a lot of the time).

My perspective having developed with Python for over 20 years now: it depends on the nature and context of the problem being solved.

In my experience, you usually need a CPU intensive problem for the implementation language to be a speed concern. Many practical everyday problems solved with Python (outside of contests and specialized fields) tend to be I/O bound.

Secondly, even when you do have a CPU bound problem, many Python modules you might use to solve it are wrappers for C/C++ implementations.

As a result, I've come to think of Python as a control and integration language and less as a platform for base algorithm implementation.

Viewed that way, I've found Python to be unbeatable for speed of implementation and long-term maintainability (two of my top metrics for valuing code).

It's generally difficult to say one language is faster than another, but there are some significant differences between the languages and implementations of Python and C/C++ that have very real performance implications.

Python is a dynamically typed language. This means that the language will handle conversions between types depending on the context. For example, one context can yield a 64 bit integer, another a arbitrary precision integer, another a string. Keeping track of when to use one versus another, and converting between costs performance. The different data representations for each type have different performance implications as well. For example, a 64 bit integer can fit into a register, and it's generally only one cycle to perform any math on it. Arbitrary precision requires math and carry be performed for every digit in the value. With C++, types are explicit, which means there is only one type for a value, and the representation is generally the most efficient (eg 64 bit integer).

Python is also generally interpreted. This means that code can't be directly executed on the CPU. An intermediate layer, called the interpreter takes an intermediate representation of the Python code, and translates it into instructions that run on the CPU. This happens at runtime, which adds overhead for each intermediate instruction. The more instructions you need to do something, the more overhead you have. C/C++ is compiled directly into code that executes on the CPU which is typically faster. This also allows for higher levels of optimization in code, since there's an understanding of what a piece of C/C++ code will look like when it executes on the CPU. The compiler can also optimize the code further, since it knows the code (generally) won't change. It's also a lot easier to use native features of the CPU like stack allocation, which is drastically faster than heap allocation.

One of the other differences is that Python tends to provide higher levels of abstraction than C/C++ code. So, doing something like a set intersection using x.intersection(y) may not necessarily be the fastest way. Python may do a hashed compare, but sorting and using memcmp may be faster. It's a lot more code to write though. This is generally the tradeoff for Python vs. C/C++ (natively compiled code) in general.

If you're concerned with performance, but you like programming in Python, you may want to check out Haskell. It's provides a lot of the same higher level abstractions Python provides, but the language is strongly typed and it can be compiled to native code. A simple example... http://uxcn.blogspot.com/2011/11/algorithm-complexity.html.