Yury Selivanov added the comment: > People should stop getting hung up about benchmarks numbers and instead > should first think about what they are trying to *achieve*. FP performance in > pure Python does not seem like an important goal in itself.
I'm not sure how to respond to that. Every performance aspect *is* important. numpy isn't shipped with CPython, not everyone uses it. In one of my programs I used colorsys extensively -- did I need to rewrite it using numpy? Probably I could, but that was a simple shell script without any dependencies. It also harms Python 3 adoption a little bit, since many benchmarks are still slower. Some of them are FP related. In any case, I think that if we can optimize something - we should. > Also, some benchmarks may show variations which are randomly correlated with > a patch (e.g. before of different code placement by the compiler interfering > with instruction cache wayness). 30-50% speed improvement is not a variation. It's just that a lot less code gets executed if we inline some operations. > It is important not to block a patch because some random benchmark on some > random machine shows an unexpected slowdown. Nothing is blocked atm, we're just discussing various approaches. > That said, both of Serhiy's patches are probably ok IMO. Current Serhiy's patches are incomplete. In any case, I've been doing some research and will post another message shortly. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21955> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
