Hacker News new | ask | show | jobs
by jharger 2485 days ago
Why not have optimized versions that use native instructions when available, and then fall back to the portable version when they are not?
2 comments

I'm unsure as to why they don't do that, I suspect it's because nobody using Python has found floating-point rounding to be a bottleneck yet.
I have encountered situations where irregular rounding became solvable but annoyingly problematic to detect / calculate, in the LANL Earthquake dataset on Kaggle, it had a column with samples and a column with (incorrectly incrementing) sample times that were rounded. In order to create a corrected column, I noticed quite a lot of irregularities in the python rounding (or the underlying mechanism)

I also consider simultaneously deterministic, fast, portable rounding or binary formats to be important for decentralized delegation of computation, say a TrueBit style platform:

https://people.cs.uchicago.edu/~teutsch/papers/truebit.pdf

It's because Python is slow everywhere, so it's hard to find bottlenecks like this. This method is easily 100x slower than need be. If everything else were well written, this would stand out. Since lots of Python is written like this, none stand out.

Death by 1000 papercuts....

More specifically, cpython generally biases toward simpler implementations. I'd be surprised if there's any custom x86 assembly anywhere in cpython.
I suspect different behaviors might be an issue in some tricky cases.