←back to thread

47 points todsacerdoti | 2 comments | | HN request time: 0.417s | source
Show context
PaulHoule ◴[] No.42190446[source]
I think is forgotten here that one of the benefits of nominal typing is that the compiler can know that data layout at run time so performance benefits.

There has been so much ink spilled on the question of what kind of type systems help programmers be productive but there is not such controversy on the performance side.

replies(3): >>42190752 #>>42191794 #>>42199051 #
lmm ◴[] No.42191794[source]
Premature optimisation is the root of all evil. If you get the semantics right then good performance will generally follow, if you make the wrong thing then it doesn't matter how fast it is.
replies(4): >>42191922 #>>42192250 #>>42192332 #>>42194078 #
taeric ◴[] No.42191922[source]
Performant code in the wild largely disagrees? This is the difference between a numpy array versus a regular python list. It is stark.

You are correct that you can often engineer the performance later. But layout concerns and nominal types for performance are fairly non controversial.

replies(1): >>42192750 #
thesz ◴[] No.42192750[source]
Python does not do optimizations at all.

In contrast, you can find Fortran compilers that can substitute your inefficient implementation of some numerical algorithm with different much more performant one.

replies(1): >>42193650 #
PaulHoule ◴[] No.42193650[source]
Python has a peephole optimizer: https://akaptur.com/blog/2014/08/02/the-cpython-peephole-opt...
replies(1): >>42194022 #
1. maccard ◴[] No.42194022[source]
I think what OP meant was "Python's optimisations are not very fast", which (IMO) is a fair statement. Python is many, many things, but it's best case scenarios (without rewriting in C, at which point you're writing C not python) are slower than the naive implementations in many other languages.
replies(1): >>42199243 #
2. thesz ◴[] No.42199243[source]
Python optimizations are not deep and/or broad. I did not mean "very fast" as in "compilation speed."

Python does not attempt to apply anything more complex than that peephole optimizer, whatever that means.

Judging from my experience with Python, that peephole optimizer cannot lift operations on "dictionary with default value" to a regular dictionary operations using conditionals. I had to manually rewrite my program to use conditionals to recover it's speed.