3 ms·
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 researc
by 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 agoThe 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 agoIt'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.