←back to thread

Nominal for Storing, Structural for Manipulating

(welltypedwitch.bearblog.dev)
42 points todsacerdoti | 4 comments | 20 Nov 24 02:50 UTC | HN request time: 0.832s | source
Show context
PaulHoule ◴[20 Nov 24 02:56 UTC] 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 ◴[20 Nov 24 08:22 UTC] 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 ◴[20 Nov 24 08:43 UTC] 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 #
1. thesz ◴[20 Nov 24 11:07 UTC] 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 #
2. PaulHoule ◴[20 Nov 24 13:13 UTC] No.42193650[source]▶
Python has a peephole optimizer: https://akaptur.com/blog/2014/08/02/the-cpython-peephole-opt...
replies(1): >>42194022 #
3. maccard ◴[20 Nov 24 14:05 UTC] 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 #
4. thesz ◴[20 Nov 24 23:29 UTC] No.42199243{3}[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.