7 ms·

There's also the argument that at a certain scale the time of a developer is simply more expensive than time on a server. If I write something in C++ that does

• eska 4y ago
  If Python was merely twice as slow then I could agree with you.
  • bombolo 4y ago
    Not all code needs to process terabytes of data. I have code running that reads ~20 bytes, checks the internal status on an hashmap and flips a bit. Would it be faster in C? Of course. Would it have taken me much longer to write to achieve absolutely no benefit? Yes.
• dagw 4y ago
  Realistically something that takes 1 second in C++ will take 10 seconds (if you write efficient python and lean heavily on fast libraries) to 10 minutes in python. But the rest of your point stands
  • joenot443 4y ago
    Damn! Is the rule of thumb really a 10x performance hit between Python/C++? I don’t doubt you’re correct, I’m just thinking of all the unnecessary cycles I put my poor CPU through.
    • benji-york 4y ago
      As a long-time Python lover, yes that's a decent rule of thumb.
    • vgatherps 4y ago
      Outside cases where Python is used as a thin wrapper around some C library (simple networking code, numpy, etc) 10x is frankly quite conservative. Depending on the problem space and how aggressively you optimize, it's easily multiple orders of magnitude.
      • DiogenesKynikos 4y ago
        Those cases are about 95% of scientific programming. This is the first line in most scientific code: import numpy
      • intelVISA 4y ago
        FFI into lean C isn't some perf panacea either, beyond the overhead you're also depriving yourself of interprocedural optimization and other Good Things from the native space.
    • sva_ 4y ago
      It really depends on what you're doing, but I don't think it is generally accurate. What slows Python down is generally the "everything is an object" attitude of the interpreter. I.e. you call a function, the interpreter has to first create an object of the thing you're calling. In C++, due to zero-cost abstractions, this usually just boils down to a CALL instruction preceded by a bunch of PUSH instructions in assembly, based on the number of parameters (and call convention). This is of course a lot faster than running through the abstractions of creating some Python object.
      • kaba0 4y ago
        > What slows Python down is generally the "everything is an object" attitude of the interpreter Nah, it’s the interpreter itself. Due to it not having JIT compilation there is a very high ceiling it can not even in theory surpass (as opposed to things like pypy, or graal python).
  • bombolo 4y ago
    If the 1 second is spent waiting for IO, it will take 1 second in whatever language. But yes python is slow. However I've seen good python code be faster than bad C code.
    • roflyear 4y ago
      Well, to be fair the "good python code" is probably just executing something written in c lol. But lots of python is backed up by stuff written in c.
      • bombolo 4y ago
        Not necessarily. Just using a better optimized sort or hash algorithm can make a big difference. I was talking specifically of pure python code (except the python's standard library itself, where it really is unavoidable).
    • kaba0 4y ago
      Of course algorithmic complexity will trump anything else at big enough n values.
  • Gasp0de 4y ago
    And how much code is generally written that actually is compute heavy? All the code I've ever written in my job is putting and retrieving data in databases and doing some basic calculations or decisions based on it.
    • Yoric 4y ago
      That is absolutely true. But sometimes, you do end up writing that compute heavy piece of code. At that stage, you have to learn how to write your own native library :) Speaking of which, I've written some Python modules in Rust using PyO3, its' a very agreeable experience.
    • jimbokun 4y ago
      Rule of thumb: Code is "compute heavy" (could equally be memory heavy or IOPs heavy) if it's deployed into many servers or "the cloud" and many instances of it are running serving a lot of requests to a lot of users. Then the finance people start to notice how much you are paying for those servers and suddenly serving the same number of users with less hardware becomes very significant for the company's bottom line. The other big one is reducing notable latency for users of your software.
  • roflyear 4y ago
    Not for everything. There are plenty of Python operations that are not 10x slower than c.
    • dagw 4y ago
      That is true, but there are relatively few real world applications that consist of only those operations. In the example I mentioned below, there where actually some parts of my python rewrite that ended up faster than the original C++ code, but once everything was strung together into a complete application those parts where swamped by the slow parts.
      • ghostwriter 4y ago
        Most of the time these are arithmetic tight loops that require optimisations, and it's easy to extract those into separate compiled cython modules without losing overal cohesion within the same Python ecosystem.
  • giantrobot 4y ago
    I spend most of my time waiting on IO, something like C++ isn't going to improve my performance much. If C++ takes 1ms to transform data and my Python code takes 10ms, it's not much of a win for me when I'm waiting 100ms for IO. With Python I can write and test on a Mac or Windows and easily deploy on Linux. I can iterate quickly and if I really need "performance" I can throw bigger or more VPSes at the problem with little extra cognitive load. I do not have anywhere near the same flexibility and low cognitive load with C++. The better performance is nice but for almost everything I do day to day completely unnecessary and not worth the effort. My case isn't all cases, C++ (or whatever compiled language you pick) will be a win for some people but not for me.
• mharig 4y ago
  Speeding up the time critical parts with Cython or Numba or ... is rather easy.