Hacker News Reader

Comment by nayuki | Hacker News Reader

The title is bad; the article doesn't deliver on the promise of making Python programs "blazingly" fast.

The first example given (the exponential function) is basically the worst scenario, because it's a purely numerical computation expressed in pure Python code. Whereas Python's performance is okay-ish for I/O or calling C modules.

From doing Project Euler solutions, I have ample evidence that for pure numerics (e.g. int, float, array), Java is anywhere from 10× to 30× faster than pure Python code executed in CPython. https://www.nayuki.io/page/project-euler-solutions#benchmark...

I believe it is basically impossible for Python to win back all that performance loss without adopting radical and jarring features like static typing, machine-sized integers, and no more "every number is a full-fledged object".

View on HN

Lisp, Smalltalk, Dylan, JavaScript prove otherwise regarding performance of dynamic languages.

The problem is that projects like PyPy remain on the sidelines, instead of being fully embraced by the community.

That's because PyPy has poor support for C-API exentions, which is what all the performance-oriented python packages rely on.

Most people doing serious numeric work don't care about the speed of the Python interpreter because all the heavy lifting is done by optimized libraries like Numpy and TensorFlow.

Which will never change, because instead of improving Python, one writes C instead.

I could even use them from TCL if bothered to do so, thus Python's benefits as programming language are meaningless.

Tensorflow has multiple language support for example.

> Python's benefits as programming language are meaningless.

Being the most flexible and user-friendly interface to the most powerful libraries written in other languages isn't meaningless.

That isn't unique to Python.

Then maybe the statement should have been "I believe it is basically impossible for Python to win back all that performance loss without adopting radical and jarring features like dropping the legacy C interface to Python objects."

The fastest dynamic languages I see are those which have no C interface at all. How many of the performance optimizations in a modern JavaScript engine would be possible if it had to support accessing every property of every object as a C string at any point in a program? JS has exactly none of the features that comment claims would be necessary for performance.

> dropping the legacy C interface to Python objects.

This is nonsense. No language ever will have linear algebra or numeric implementations faster than Fortran/C implementations of BLAS, LAPACK etc. Not being able to make ffi calls makes python essentially unusable for most of its niche uses.

> JS has exactly none of the features that comment claims would be necessary for performance.

I don't see people doing ML, scientific computing etc in JS.

C++ is pretty close to it.

C++ compilers can and do (g++, clang++) use pretty much the same set of optimization techniques used by C compilers.

And even offer REPL and Jupiter notebooks, so..

You're confusing "no FFI whatsoever" with "a sane FFI". Python's legacy interface is insane--it exposes virtually all details of the CPython interpreter to C extensions such that any deviation from CPython's implementation is effectively a breaking change.

Because of the web, Google and other companies have poured tons of resources into improving the speed of JavaScript. I wonder where Python would be if the same level of resources had been devoted to it.

There was no Web for pouring resources into Lisp, Scheme, Smalltalk, or even Dylan considering its short life.

Python already has it, PyPy, but it tends to be ignored by many.

Interestingly you didn't mention Lua. The best Common Lisp, Smalltalk, and JS systems are always about a factor of 2 to 10 slower than C. This is not very good evidence for your assertion. (I suspect that's true of Dylan too, but haven't tried it.) By contrast, LuaJIT often beats GCC on performance. This is excellent evidence for your assertion.

My point was about being fast enough, faster than CPython currently is by a factor of hundreds, not about beating C with its UB optimization tricks.

LuaJIT is stuck on a 2017 release, and an old Lua version, is it ever going to be updated?

Typically I measure CPython at about 40× slower than C, and SBCL, V8, and the like at about 2–10× slower than C. What cases are you seeing where those runtimes are hundreds of times faster than CPython?

People don't normally update to new versions of Lua, because they're not backwards compatible; it's not like Python or JS. WoW is still using Lua 5.1, as is MediaWiki. It's unlikely that this will ever change.

Probably at some point someone will continue LuaJIT development. It seems as likely that they will diverge in a different direction as follow PUC.

When those CPython applications are actually pure Python, without any call to C helper libraries.

Right! When your hot code is in C you get a performance mix. Still, only about 3% of your logic has to be in interpreted Python for it to dominate your runtime.

Chez scheme is just as dynamic as python and is about as fast as C# running on mono IIRC. My scheme was probably worse than my C# was when I did project Euler though.

Chez does unboxed integer arithmetic (but not floats) and does not have to do any OO-like dispatch, and is also probably one of the best language implementations there are.

A nice show of Chez Scheme speed is Idris 2. Edwin is very impressed with the performance; it is very fast. And imho it is a lovely language with, as you rightfully say, one of the best implementations out there. Extremely portable (cpu/OS). And quite readable too.

C# running on mono is in my experience 10 times slower than equivalent C++ even for simple things like adding numbers in an array.

That story of mine is old, but I have some newer anecdata: porting all my old project Euler solutions to SBCL and getting help by some better lispers than me to optimize it made SBCL come out close, but almost universally slower than Chez if someone really wants I can see if I find the code on any of my external HDDs.

A number quoted is that SBCL preforms roughly on par with, but slightly slower than, java. For what it is worth, the computer benchmarks game confirms that: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

That was with optimize level 3, which burns on (car 1), and then you might as well use C, but the language at least allows for those speeds.

Ooh! I don't think I've ever seen someone claim Chez Scheme produced faster code than SBCL before. That's interesting.

It is hard to claim, because there are hardly any benchmarks. I just had the opportunity to move between the implementations and found chez to be faster for the kind of things I was doing, which was numerical stuff and loops.

SBCL is also an amazing project, and lately the GC story has gotten better IIRC.

So will Racket become super super fast ?

"… Racket CS available, a beta version of the Racket on Chez Scheme implementation."

https://download.racket-lang.org/v7.4.html

Probably not, but the code is a hell of a lot cleaner! I looked through it and thought that even I could work on it. The new macro expander is even possible to follow :)

It’s hard to find a Scheme implementaron that isn’t significantly faster than Python... all while being at least as dynamic and more expressive.

I think a lot of CS students had their brains melted by tough classes where Scheme was the vehicle. Thus, you have a population of users that either are anti-evangelists because they have PTSD, or you have evangelists who exist on a plane above the lumpenproletariat like me, which can contribute to the false notion that Scheme is intrinsically esoteric.

I never got a formal CS education, so I don’t have PTSD from Scheme. Also, I am not a super brain, so I guess I haven’t felt compelled to become expert at the hard concepts that Scheme enables.

People fixate on the S-expression syntax (“all those parentheses!”; counter argument “way fewer commas!”). But I think the real issue for Scheme is the lack of libraries that do hard things for “normals” like me.

If I’m strictly honest, I’m more productive in Python than Scheme. This is not because Python is easier. It’s because the Python community has attracted the CS grads who grokked enough of the hard stuff to make libraries that abstract away stuff.

There’s no reason people can’t write Scheme like they write Python. That is, people don’t need to do all the possible stuff in Scheme all the time. Truthfully, Scheme is at least as easy as Python.

Scheme just needs more smart normals writing libraries for mediocre normals like me for Scheme to become popular. Maybe take a domain approach. I feel like adapting R’s tidyverse to Chez is an easy target. Scheme could be the data scientist’s goto. Maybe show people how easy it is to build self-contained serverless apps in the cloud.

If there were a Scheme community that earnestly tackled any domain with the idea of making it accessible to practitioners within the domain, I think it could get real traction.

And it would be fast. Much faster than Python.

"Chez scheme is just as dynamic as python"

Is it? Python is really, really dynamic, which contributes to its slowness. You can directly change an instance's __class__ attribute. You can add properties to classes dynamically, changing how fundamentals of how attributes get looked up at run time. You can write a new class, using a new metaclass, and then set an existing instance to the new class.

A great deal of why Python is so slow is that it is really too dynamic. A language doesn't really want to be "as dynamic as Python".

Nothing that Common Lisp or Smalltalk aren't capable of doing as well, and they have quite capable JITs.

As an example, Smalltalk becomes: message completely replaces one object representation by another one.

Chez lacks a built in OOP system, but there is nothing prohibiting you from adding something like CLOS which does all python does and more (much faster than python).

Most modern lisp compilers do a lot of different things to make CLOS fast, though, prefilling caches and all that for you. Not only that, you can connect to a running program and redefine it while it is running.

"Chez lacks a built in OOP system,"

In that case, the answer is actually no to my question. Yes, of course you could program in that level of dynamicness, because you could in any language, but it will then slow you down. No sensible CLOS would be as dynamic as Python.

Like I said, in a lot of ways, you don't want to be as dynamic as Python, and I advise against language advocates seeing the phrase "Python is more dynamic than your language" as a cue to jump up and start insisting that they are just as dynamic as Python. Even in hindsight, I'd say the level of dynamicness in Python was a mistake. You don't need it to have a nice, usable, dynamic language, but it has been a ball & chain around its legs in terms of performance for decades.

To be clear, this isn't a criticism of dynamic languages as a concept. I have criticisms, but these aren't it. This is a criticism of Python specifically. A dynamic language can be pretty nice with, let's say, two or three layers of dynamicness, but Python has four or five. If you follow the full process that Python has to go through to resolve "x.y", including all possible points where you might have done something to affect the result, it's crazy overkill. In Guido's defense, when he was writing it way back when, that wasn't clear. There wasn't a lot of highly-relevant prior art to look at for that style language.

CLOS is just as dynamic as Python _and_ fast, at least in SBCL and LispWorks. CLOS is probably the most expressive object system you can find, and if you wanted it fast you would restrict it somewhat to allow for at least some of the dispatch to happen at compile time :)

Scheme is relentlessly monomorphic, and most implementations don't provide much reflection, preferring compile-time macros. (I don't know what Chez’s reflection facilities are like; can you do the equivalent of def __getitem__ or x.__setattr__ = y?) These attributes make Scheme much easier than Python to implement efficiently.

My experience is that simple programs usually take about twice as much code in Scheme. This is related to the polymorphism thing, but also I think Python supports imperative programming better. Python is built around autogrowing hash tables (“dicts”) and autogrowing arrays (“lists”); standard Scheme provides neither, preferring alists and cons lists.

In guile I would do

   (define-method (get (lst <list>) (n <integer>)) 
     (list-ref lst n))

in chez I would probably use chez soop, which is hideously underdocumented and probably bitrotten by now, or any of the other object systems available.

It would of course slow things down since I doubt chez optimizes that so you get runtime dispatch. SBCL however has an amazing object systems that does all of python's Oop with pretty good speed.

You are right that python is better at imperative programming, but that is also very much a matter fo taste. I always get a sour feeling in my mouth when using python because it is almost exclusively about mutability.

(hashtables are a part of r6rs, btw. Not very pleasant to use since: (hashtable-ref h key default-value))

You could just use Julia which basically gives you a Python like language but with C like performance. Julia will kick Java to the curb on numerics because it was actually built with that in mind.

And you get all of this WITHOUT static typing and yes in Julia everything is still a full-fledged object. There is no difference between numbers and other objects in Julia. But numerics is still fast.

I tried really hard to like Julia and just couldn't get behind it. We used it for a research paper in the area of optimization and by the end of the project I really regretted it. Performance and built in numerics libraries were great, but I feel the language ergonomics are pretty bad. I hate Python just as much as the next developer, but I do find it much easier to use than Julia for research type work.

My biggest qualm with Julia (and maybe this speaks to my inexperience with the language) is that it isn't always obvious when Julia is going to make a copy. We spent about an hour working through some code that was very slow (props to Julia's profiling tools) but couldn't figure out _why_ it was slow. It turned out that despite our best efforts, Julia was still copying a vector despite us using pre-allocated scratch space for the work.

From my point of view, if I am comparing algorithms then Python's performance doesn't really matter and it's ergonomics win. If performance matters I'd just use C++ or Rust.

> My biggest qualm with Julia (and maybe this speaks to my inexperience with the language) is that it isn't always obvious when Julia is going to make a copy.

If you're talking about slices of an array, those always create a copy unless created with the @views macro (or the equivalent function call).

Interesting how we can have such vastly different experiences.

When Julia makes a copy is pretty straightforward and natural IMHO. I would have been curious to see an example of the code you used where a copy was made without you knowing.

I started with Python, but I find Julia better is almost every single way I can think of. Like even if Julia was slower than Python I would have picked it because I find it so much nicer to use.

I wrote an article here about some of the observations I had about using Python after coming back to it from Julia:

https://medium.com/@Jernfrost/python-vs-julia-observations-e...

There are some exchanges further down. Would have been interesting to hear your feedback on some of those things.

Julia is dead, but few realize it.

It's not as nice as Python, nor as fast as C++. And much less supported (tools/libraries/...) than both.

So it sits in this awkward middle between Python and C++, basically sucking at both and excelling at none.

I wouldn't claim that it's dead - it just fails to deliver on its main promise and the developer experience is still quite poor.

In which way does it 'fail to deliver on its main promise' and how is the developer experience 'quite poor'?

Does Julia have the number of libraries that Python does?

It's somewhat the other direction. In the area that I work, scientific machine learning and differential equation modeling, Python does not really have a well-developed ecosystem while Julia has all of the tools. High performance methods with stiffness handling, automatic detection of Jacobian sparsity form a Julia program, methods for stochastic/delay/differential-algebraic equations, and the ability to embed neural networks into arbitrary differential equations and train them in a scientific context. Python is very far behind even MATLAB or Mathematica in this domain.

That's interesting. How do you think R fares in this respect?

(The problem that I'm having with Julia isn't the math/computational aspect, it's Julia's use as a more general purpose programming language in additional to math.)

That wasn't its main promise and that doesn't much affect the developer experience if the existing libraries are of high quality.

No. But the quality of the libraries is often much higher, and can do things that are impossible in Python and in most other languages (owing to the high degree of Julia's polymorphism and homoiconicity).

I don't think it's dead. You are right on the other points. I think that Julia could have its day, it's having a lot of trouble getting traction. I mean I remember 20 years ago being laughed at for using Python for a web app, but now look at python.

This is serious nonsense! Julia is way nicer than Python. If Python was faster than Julia, I would still have picked Julia, unless I really needed the performance.

With Julia I get first class meta programming. I get awesome multiple dispatch. I get environments and package system really well integrated. I get awesome integration with the shell. Better module system. More natural syntax for arrays. Much better system for closures. Better named functions.

REPL programming in Julia is just light years ahead of anything in Python. The OOP design of Python really kills the REPL experience.

Unless you are a very skilled C++ programmer, Julia is going to outperform you as the program gets larger. C++ programmers are going to get themselves tangled up when trying to run multi-threaded code, running on multiple machines on GPUs and specialized hardware. Julia does this effortlessly.

C++ cannot do JIT, hence as soon as you deal with complicated machine learning algorithms with custom kernels, C++ is going to tie itself into a knot.

Why do you think large Astronomy projects like Celeste and the next major climate models are built in Julia and not C++? Because developers realized that when you need to run massive calculations on super computers on hundreds of thousands of cores, C++ is going to get in the way.

As for libraries and tools. All the Python tools I have tried to match my Julia tools have just sucked. Julia tools often excel over much older Python tools.

Library development moves much faster on Julia than Python. It is not hamstrung by relying on complicated C++ code based. Also Julia libraries integrate very well, while Python libraries are often their own deserted island. That means a few Julia libraries can do what must be accomplished with dozens of Python libraries.

I think for pure numerics using numpy basically recovers all performance loss. It's when you get tricky control-flow that you run into real trouble.

Typically straightforward Numpy gets me from 40× slower than straightforward C to 5× slower. Tricky Numpy (output arguments, conversions to lower precision, weird SciPy functions) gets me another factor of 2. C SIMD (intrinsics or GCC’s portable vector types) gets me a factor of 4 faster than straightforward C. Presumably CUDA would buy me another factor of 100 but I haven't tried it and I haven't tried Numba either.

You're probably expecting a bit much from CUDA. If you have heavily optimized CPU code running on a high-core count Xeon, it's probably more like 2-3x. The reason why CUDA is so popular is because it makes that comparatively easy to achieve. Optimizing x86 to the last 10% is a dark art only very few programmers are capable of, while writing decent GPU code is IMO an order of magnitude easier, i.e. just a craft.

Main difference being: High memory bandwidth vs. heavy usage of cache, unified programming model for vectorization and multicore parallelism

Thanks! But what if I don't have any kind of Xeon, but do have an NVIDIA card?

You don’t need any kind of Xeon - most of recent i5/i7/i9 cores have AVX and even AVX2 support.

without lots of CPU cores and with a high-end NVIDIA card your speedup expectations just can become a bit higher. Typically 100x when comparing GPU-friendly algos to unoptimized (but native) CPU code or 10x when comparing it to decently optimized code running on slower CPUs.

Generally I think a performance/cost comparison is more useful: Take the price of the GPU and compare it to something with equivalent cost in CPU+RAM.

Btw GPU has its own cache and all problems related to it. You still have to watch what/how you do things on GPU to be cache friendly

Yes, but it's much less emphasized on GPU I think. If you have a data parallel algorithm, as long as you design the array ordering to allow coalesced access, the memory architecture will usually already allow better performance than what you can hope to get from CPU even with heavily cache optimized code that's basically unmaintainable (as it will likely perform much differently on the next architecture).

> Typically straightforward Numpy gets me from 40x slower than straightforward C to 5x slower.

I find this hard to believe. What kind of numerical work are you doing? Even something as simple as matrix-matrix multiplication should be hard to beat with C, unless your C code is using a cache efficient algorithm.

Branch heavy code, for example trading order book updating.

People always say "use numpy", but that is only possible if your algorithm can be described in terms of vectorized operations. For many kinds of processing, the only alternative is C/C++ (through Cython)

That was my hunch.

> People always say "use numpy", but that is only possible if your algorithm can be described in terms of vectorized operations. For many kinds of processing, the only alternative is C/C++ (through Cython

Agreed

> (through Cython)

My personal experience is that you can actually get another factor of 2 or 3 speed-up by ditching Cython and using actual C instead (I think it's because optimizers have a hard time cleaning up the C that Cython produces), even if you've turned off thing's like bounds checking.

I meant "through Cython" as in "passing through Cython", ie, Cython is just a thin wrapper layer over the real C/C++ code.

I think using numpy is always good first step after just trying to improve the algorithm. Numpy will be less effort than going to cython. After that cython is a good next step. I seriously don't know any situation where I would do the kind of micro-optimizations mentioned in the article.

> I find this hard to believe

I guess you haven't tried it, then. But your lack of knowledge is not a reasonable justification for attacking my integrity.

> Even something as simple as matrix-matrix multiplication

That's the best case for Numpy, not the worst. SGEMM is indeed just as fast when invoked from Numpy as when invoked from C, at least for large matrices.

Using GPUs involves significant tradeoffs that go way beyond writing SIMD code. (mostly batching and off device transfers)

CPU SIMD code can be trivially mixed with non SIMD code but mixing GPU and CPU code may negate the benefits.

Indeed, numpy is awesome. I used to do my computational experimenting (some of them including neural networks) the plain way (using classic data structures, the languages' built-in arithmetic operators and functional facilities) in many different languages. Once I've tried Python with numpy my mind was blown, it's so much faster than anything. Now I feel like I enjoyed writing functional code more but given the performance difference I can hardly imagine coming back. So the very reason I use Python is performance.

> I believe it is basically impossible for Python to win back all that performance loss without adopting radical and jarring features like static typing, machine-sized integers, and no more "every number is a full-fledged object".

Pypy is often quite a bit faster than CPython for real-world programs so clearly some improvement is possible.

It is a shame that Python became so popular. There are a number of choices that are just as “easy” (or better) and an order of magnitude more efficient.

Two options you can try guiding a budding python user to are Nim and F#

Both rather dead because you get to chase Microsoft, and even Mono cannot achieve that.

Short: they're not portable beyond Windows.

Nim is not related to Microsoft at all, and runs anywhere GCC can run.

F# runs on Windows/Linux/Mac standard since .NET Core, and Mono runs it anywhere, Nintendo Switch, IOS, Android, playstation.

? Ubuntu

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Reply on news.ycombinator.com