8 ms·
Why not have optimized versions that use native instructions when available, and then fall back to the portable version when they are not?
by jharger 7y ago
Why not have optimized versions that use native instructions when available, and then fall back to the portable version when they are not?
- messe 7y agoI'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.
- joshuamorton 7y agoMore specifically, cpython generally biases toward simpler implementations. I'd be surprised if there's any custom x86 assembly anywhere in cpython.
- DoctorOetker 7y agoI 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 https://people.cs.uchicago.edu/~teutsch/papers/truebit.pdf
- ChrisLomont 7y agoIt'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....
- slx26 7y agoI suspect different behaviors might be an issue in some tricky cases.