Hacker News Reader

Comment by desertrider12 | Hacker News Reader

C++ is only "fast" because people who care about performance use it and a lot of people who are good at compilers work on gcc/intel/llvm. If the LLVM team decided to spend 5 years making python "fast", I bet they could make it benchmark just as well as C++.

View on HN

No, It’s not possible to optimise Python like c++ because of the characteristics of the language. Plenty of very good people are working on Python optimisation and it’s still painfully slow and will always be.

Perhaps you should consider this a different way.

Consider the end to end performance of a system - from inputs in (say, timesheets and HR data) to outputs out (bank payment APIs called, emails sent).

Would you bet the end to end performance of a system built by mediocre C++ programmers would be better than that of a system built by mediocre Python programmers?

I certainly wouldn't.

To elaborate a bit: what I mean is, it is easier to build an acceptably performant system in Python than in C++.

Yes, an arbitrary algorithm will probably perform significantly faster in C++.

But that probably won't matter in a real-world system built from multiple integrated components, when the performance is more likely to be determined by the abstractions chosen and the system architecture in use. And IMO Python and its surrounding ecosystem makes it easier to make good choices in those areas.

> Plenty of very good people are working on Python optimisation and it’s still painfully slow and will always be.

Pypy etc never had the resources to build a truly amazing Python implementation. With Oracle throwing their weight behind Graal there's now ZipPy: http://thezhangwei.com/documents/oopsla113-zhang.pdf

Backwards compatibility with native extensions is the single biggest problem preventing optimising both Python and Ruby. If we could completely throw out C API compatibility like LuaJIT did, then we could make huge improvements to Python and Ruby performance and memory usage.

I have been using Python for a while now, and its rarely that the language is too slow (I have encountered it on one problem). A lot of Python is for web programming where you optimize the database and set up caching to improve performance. If you want to do some heavy number crunching Numpy is apparently not far of C in terms of performance.

Obviously its a case of the correct tool for the job and depends heavily on the type of software you are writing, but in most cases its a different type of optimization that is needed for Python code.

> …too slow…

No language implementation is "too slow" if performance doesn't matter.

> … Numpy is apparently not far of C in terms of performance

As-fast-as C when it is C (or Fortran or assembler…) :-)

Numpy is a Python library, not a C library. By your reasoning Python is C.

> If the LLVM team decided to spend 5 years making python "fast", I bet they could make it benchmark just as well as C++.

Better, perhaps, if John Walker's experiences with Javascript are anything to go by:

https://www.fourmilab.ch/fbench/fbench.html

John Walker has a program called fbench which is a floating-point benchmark built around raytracing. He's implemented it many times, in many languages, throughout the decades, beginning with implementations for the original IBM PC.

Anyway, the results are posted on the site, in terms of multiples of the speed of the C implementation, which is defined to be 1.0. The Python implementation is 2.633 (PyPy 2.2.1 (Python 2.7.3), Linux), and the Javascript implementation is 0.372 (Mozilla Firefox 55.0.2, Linux). Yes, it completes in approximately a third the speed of a C implementation compiled on full optimization (-O3) by GCC 3.2.3.

(The C++ implementation is at 0.939, GCC 5.4.0 -O3.)

Anyway, Javascript has been the target of a lot of people for a fairly long time, and, despite the fact it's a very dynamic (hard-to-optimize) language... well, the numbers speak for themselves. I have no doubt Python could be improved to a similar degree.

Downloads: https://www.fourmilab.ch/fbench/

The weblog post where he analyzes the modern Javascript numbers a bit: https://www.fourmilab.ch/fourmilog/archives/2017-10/001715.h...

That is only a very specific benchmark and as that post said the result is so strange probably because of the changes in the C trigonometric functions lib that slowed down a lot to increase precision.

The point, however, is that if the difference is down to library code, the language itself isn't imposing a penalty. That is what is counter-intuitive here.

What's "counter-intuitive" about that?

As-fast-as C when it is C (or Fortran or assembler…)

Well the link you posted is not very useful - Javascript is faster on a trigonometry benchmark and the author admits it's probably because GCC's trigonometry functions are probably slow and not optimized. If you switch them out to use better functions or use a different compiler, I imagine the time would go down.

This is probably a better comparison: https://benchmarksgame-team.pages.debian.net/benchmarksgame/

Altough it seems to only have been run on node.js for Javascript.

There's more to it than that. C++ is designed for implementations to produce fast code. "Leave no room between C++ and Assembly" has been a guiding principle of C++. This is not true of Python, and thus the engineering effort required for an implementation to reach the same level of performance is huge, if at all possible.

I view C and C++ as "portable assembly language".

(I happily and productively used C++ for many years; there's no hatred in the above sentiment.)

LuaJIT can do it and ZipPy + Graal + JVM should be able to get close enough to make a massive difference to Python performance in the near future.

Reply on news.ycombinator.com