4 ms·

> If it's easier for you to write better algorithms in Python than in C++, than your code will probably be faster while written in Python. Because better algori

> If it's easier for you to write better algorithms in Python than in C++, than your code will probably be faster while written in Python. Because better algorithms will easily get you further than 10x in terms of performance. In practice I have not often seen this pan out - if you've got the most common case of a GUI app with tons of callbacks which update your UI in real-time, there isn't one algorithm to optimize anywhere, but instead you die a death of a thousand cuts because each callback will be marginally slower than what it would have been in C++. Also, it's much easier to control allocations & system calls in C++ (or other native languages for what it's worth) than in Python - and in my experience preventing those is an even better pathway to getting frames rendered in less than 5 milliseconds (which is what you want to do if you have any respect for your 144hz-screen users)

nostrademons 7y ago
I've rarely found that GUI code is ever the bottleneck. Usually it's only a problem for mousemove handlers and code that runs directly in the event loop. Most GUI apps don't even have those, unless you're writing a game. The big problem with Python GUIs is usually that the GUI framework is often written in Python. (Or it's that things like network & parsing code gets written in Python.) The framework does a lot more heavy lifting than the app does - in particular, it's responsible for converting the system events into clicks, drag&drops, submissions, etc. for the app, and for rendering components into bitmaps. If the framework is written in C++ and just exposes a Python API, there's no problem. That's how wxPython and PyQT do it.
okaleniuk 7y ago
Well, yes. GUI usually don't require much algorithmic work so there's just not much space to loose performance because of bad algorithms. But I've seen researchers been vastly prolific in Python. They make segmentation or registration algorithms that beet the market, and then they call us (C++ engineers) to make them "fast". Usually we do, since we're trained for that. But it's never orders of magnitude. It's like 2-3 times faster. And there were even cases where the C++ code appeared slower in the end. Well, we use slightly different math core than the numpy does and sometimes they're doing worse.
- TeMPOraL 7y ago
  The cases you're describing sound like cases where Python is cheating. The thing that allows Python to even be considered useful for any kind of heavier computing is that a lot of standard/popular libraries are FFI wrappers to C code. It's an excellent deal for scientific computing, where your logic is trivial and almost all work is done in C. But it's not so rosy for user-facing applications, where it's the logic that dominates.
  - deleted 7y ago
    [deleted]
  - dodobirdlord 7y ago
    > Python is cheating Weird to call it cheating when Python's strong intertop with C is a specific design goal of the language.
    - TeMPOraL 7y ago
      It's tongue-in-cheek. And also a little bit of jealousy; I wish Common Lisp felt a little less fragile around binding generation and package distribution - then I could have a high-level language that's almost as fast as C (when using SBCL implementation), that could still interface with even faster C code.

nostrademons 7y ago

I've rarely found that GUI code is ever the bottleneck. Usually it's only a problem for mousemove handlers and code that runs directly in the event loop. Most GUI apps don't even have those, unless you're writing a game. The big problem with Python GUIs is usually that the GUI framework is often written in Python. (Or it's that things like network & parsing code gets written in Python.) The framework does a lot more heavy lifting than the app does - in particular, it's responsible for converting the system events into clicks, drag&drops, submissions, etc. for the app, and for rendering components into bitmaps. If the framework is written in C++ and just exposes a Python API, there's no problem. That's how wxPython and PyQT do it.

okaleniuk 7y ago

Well, yes. GUI usually don't require much algorithmic work so there's just not much space to loose performance because of bad algorithms. But I've seen researchers been vastly prolific in Python. They make segmentation or registration algorithms that beet the market, and then they call us (C++ engineers) to make them "fast". Usually we do, since we're trained for that. But it's never orders of magnitude. It's like 2-3 times faster. And there were even cases where the C++ code appeared slower in the end. Well, we use slightly different math core than the numpy does and sometimes they're doing worse.

TeMPOraL 7y ago
The cases you're describing sound like cases where Python is cheating. The thing that allows Python to even be considered useful for any kind of heavier computing is that a lot of standard/popular libraries are FFI wrappers to C code. It's an excellent deal for scientific computing, where your logic is trivial and almost all work is done in C. But it's not so rosy for user-facing applications, where it's the logic that dominates.
- deleted 7y ago
  [deleted]
- dodobirdlord 7y ago
  > Python is cheating Weird to call it cheating when Python's strong intertop with C is a specific design goal of the language.
  - TeMPOraL 7y ago
    It's tongue-in-cheek. And also a little bit of jealousy; I wish Common Lisp felt a little less fragile around binding generation and package distribution - then I could have a high-level language that's almost as fast as C (when using SBCL implementation), that could still interface with even faster C code.