3

Based on questions like this What makes C faster than Python? I've learned that dynamic/static typing isn't the main reason that C is faster than Python. It appears to be largely because python programs are interpreted, and c programs are compiled.

I'm wondering if strict typing would close the gap in performance for interpreted vs compiled programs enough that strict typing would be a viable strategy for improving interpreted Python program performance post facto?

If the answer is yes, is this done in pro-dev contexts?

Mustafa
  • 45
  • 6
  • No; everything is still dynamically typed at run-time. The static type hints are only used to verify *correctness* of the source code itself. – chepner Nov 20 '22 at 18:12
  • So then would static typing have the opposite effect and get in the way Python doing its thing? – Mustafa Nov 20 '22 at 18:16
  • @Mustafa, run-time type checking adds work to what Python already has to do. I wouldn't describe that as "get[ting] in the way", but I would expect any measurable impact on performance to be negative. – John Bollinger Nov 20 '22 at 18:18
  • 2
    Type hints are *ignored* at run-time, aside from them being preserved in `__annotation__` attributes on `function` and `class` objects. If the one-time cost of creating those attributes on startup negatively impacts your performance, you probably shouldn't be using Python in the first place. – chepner Nov 20 '22 at 18:22
  • Thanks @chepner - https://docs.python.org/3/library/typing.html looks like I could've found out that hints were ignored here and saved a thread. Appreciate the help! – Mustafa Nov 20 '22 at 20:39

1 Answers1

2

With current versions of Python, type annotations are mostly hints for the programmer and possibly some validation tools but are ignored by the compiler and not used at runtime by the byte-code interpreter, which is similar to the behavior of Typescript.

It might be possible to change the semantics of Python to take advantage of static typing in some circumstances to generate more efficient byte-code and possibly perform just in time executable code generation (JIT). Advanced Javascript engines use complex heuristics to achieve this without type annotations. Both approaches could help make Python programs much faster and in some cases perform better than equivalent C code.

Note also that many advanced Python packages use native code, written in C and other languages, taking advantage of optimizing compilers, SIMD instructions and even multi-threading... The Python code in programs using these libraries is not where the time is spent and the performance is comparable to that of compiled languages, while giving the programmer a simpler language to express their problems.

chqrlie
  • 131,814
  • 10
  • 121
  • 189
  • Interestingly in C a standard way to get "performance" is also to use libraries of preoptimised routines. That's what Intel's MKL/IPL is all about, and other examples such as FFTW, Mercury's SAL, VSIPL, etc. All the C ends up doing is marshalling calls in/out of such libraries. It's also why messing around with core affinity buys so little especially when the range of CPUs on which a binary might have to run can vary so much in built-in opcode set and core count. Us die-hard embedded high performance types have been using libraries and trusting OS schedulers to get it right for decades now :-) – bazza Nov 20 '22 at 21:07
  • In my field there is now a serious question as to whether or not to ditch C. So many scientific routines now are produced for Python; there's not necessarily a C version of such a library, even if the Python package had been written in C in the first place. Sure, calling in/out of packages from Python adds overhead, but not too much, and it's probably always more expedient (especially for a developer) to suffer that overhead and throw one more CPU core at the problem to compensate, if needs be. And TBH, modern CPUs are so fast that people are running out of problems that can tax them! – bazza Nov 20 '22 at 21:16