5 ms·

The point of the OP was "patterns for fast python", i.e performance. It's absurd to claim that you "advocate abstractions over performance" in the context of ac

by jmilloy 14y ago

The point of the OP was "patterns for fast python", i.e performance. It's absurd to claim that you "advocate abstractions over performance" in the context of achieving performance, so your comparison doesn't make sense to me. Just because you don't advocate performance doesn't mean that these aren't the ways to achieve performance. In addition, it sounds you mostly agree with regard to rewriting in C... use it as a last resort. It sounds to me like you are just trying to disagree.

JulianWasTaken 14y ago
I don't see where in fijal's comment you got the impression that he doesn't advocate performance. I very much would hope (and believe) otherwise, that he cares very much about it. It also does not seem that he agrees at all with regard to writing in C, since his "last resort" sounds much more last than yours (again, a thing I'd expect from him ;). His point sounds like it is "if you care about performance, these are not really ways to get it, because they sacrifice more important things". If your issue with that is "yeah but I still want performance" I would bet that fijal would point you to PyPy :).
- jmilloy 14y ago
  >you should not sacrifice your abstractions in favor of performance I only point out that a list of optimization techniques that advocates nothing will be different than a list of optimization techniques that advocates certain abstractions at the expense of performance. And there's nothing sad about that.
  - JulianWasTaken 14y ago
    I repeat, I see nothing there that says "don't optimize for performance". It says "if you want performance don't do X because X is not a reasonable sacrifice". Then he linked to some better ones. If you watch the linked talk, "write simple code when given the choice between simple and complex code" seems like fijal's main suggestion (and in my limited experience with PyPy has worked for me). The other main suggestion that I assume is underlying is "if you want performance try PyPy". Neither of those require sacrificing abstraction. Some of Guido's suggestions do.
dmorgan 14y ago
>The point of the OP was "patterns for fast python", i.e performance. It's absurd to claim that you "advocate abstractions over performance" in the context of achieving performance, so your comparison doesn't make sense to me. Just because you don't advocate performance doesn't mean that these aren't the ways to achieve performance. He never said he doesn't advocate performance. He said performance should not be achieved by sacrificing abstractions. >In addition, it sounds you mostly agree with regard to rewriting in C... use it as a last resort. In CPython, not necessarily in Guido's advice, it's one of the first and most common things you hear about performance. "Just write parts of it in C". If that was the advice of the early JVM guys ("just write parts of it in JNI"), we would never have gotten a fast JVM.
- jmilloy 14y ago
  >He never said he doesn't advocate performance. Agreed. But Guido didn't advocate performance, or anything, so fijal is trying to disagree with him about a topic he didn't state an opinion on. There's no need to make up a disagreement. Imagine if fijal instead said: "This is a fine list of techniques if you are willing to sacrifice your abstractions. At PyPy, we're not willing to do that, and we still achieve sufficiently high performance by..."

by jmilloy 14y ago

JulianWasTaken 14y ago

I don't see where in fijal's comment you got the impression that he doesn't advocate performance. I very much would hope (and believe) otherwise, that he cares very much about it. It also does not seem that he agrees at all with regard to writing in C, since his "last resort" sounds much more last than yours (again, a thing I'd expect from him ;). His point sounds like it is "if you care about performance, these are not really ways to get it, because they sacrifice more important things". If your issue with that is "yeah but I still want performance" I would bet that fijal would point you to PyPy :).

jmilloy 14y ago
>you should not sacrifice your abstractions in favor of performance I only point out that a list of optimization techniques that advocates nothing will be different than a list of optimization techniques that advocates certain abstractions at the expense of performance. And there's nothing sad about that.
- JulianWasTaken 14y ago
  I repeat, I see nothing there that says "don't optimize for performance". It says "if you want performance don't do X because X is not a reasonable sacrifice". Then he linked to some better ones. If you watch the linked talk, "write simple code when given the choice between simple and complex code" seems like fijal's main suggestion (and in my limited experience with PyPy has worked for me). The other main suggestion that I assume is underlying is "if you want performance try PyPy". Neither of those require sacrificing abstraction. Some of Guido's suggestions do.

dmorgan 14y ago

>The point of the OP was "patterns for fast python", i.e performance. It's absurd to claim that you "advocate abstractions over performance" in the context of achieving performance, so your comparison doesn't make sense to me. Just because you don't advocate performance doesn't mean that these aren't the ways to achieve performance. He never said he doesn't advocate performance. He said performance should not be achieved by sacrificing abstractions. >In addition, it sounds you mostly agree with regard to rewriting in C... use it as a last resort. In CPython, not necessarily in Guido's advice, it's one of the first and most common things you hear about performance. "Just write parts of it in C". If that was the advice of the early JVM guys ("just write parts of it in JNI"), we would never have gotten a fast JVM.

jmilloy 14y ago
>He never said he doesn't advocate performance. Agreed. But Guido didn't advocate performance, or anything, so fijal is trying to disagree with him about a topic he didn't state an opinion on. There's no need to make up a disagreement. Imagine if fijal instead said: "This is a fine list of techniques if you are willing to sacrifice your abstractions. At PyPy, we're not willing to do that, and we still achieve sufficiently high performance by..."