Hacker News Reader

Comment by dahfizz | Hacker News Reader

Is python in the fast path? Why not rewrite in a performant language for a XXX% speedup?

In this case I believe python is faster by a few months.

Jokes aside this is pytorch so this is compiled to C++ or cuda, the problem likely comes from the different functions that are called for += vs +

The += operator is almost certainly calling some method on sends out the real work to some tuned hardware-specific framework written in a fast language.

Not exactly: most of these frameworks essentially JIT compile the entire operation graph so that it can be executed, and the Python code only touches the data at the endpoints of the full computation. I don't know why the JIT compiler doesn't optimize a = b + a to a += b, but I guess they assumed that the JIT-ed code path would only be used once, so the compiler has to be fast.

So python is marshalling data to and from an ffi in the fast path? That sounds even worse

I'm not sure this is the conventional use of the phrase "fast path."

But anyway, the idea is usually that the Python code calls out to the framework with operations that are in some way "large," and so the overhead is not so significant.

Python probably doesn't have to do any marshaling, hypothetically the framework could just return an object that represents a pointer. Then the python code sends that pointer to another framework method.

I think you mean critical path (which is ironically usually the slowest path). A fast path is usually a hardcoded shortcut you can take for select cases.

Reply on news.ycombinator.com