On Mon, 9 Nov 2015 12:04 pm, Ben Finney wrote: > There isn't a way for the compiler to *know*, in all cases, whether > module attributes will be updated during the lifetime of the program > (short of, as pointed out elsewhere, running the entire program under > all possible conditions). > > So the optimisation can't be applied by the compiler without risking > breaking perfectly valid code.
It's not 1980 any more, compiler technology has come a long way since the Dragon Book. In the words of Steve Yegge, describing the attitudes of C++ developers who insist that no other language (and especially dynamic languages) can be sufficiently fast: "And so, you know, their whole argument is based on these fallacious, you know, sort of almost pseudo-religious... and often it's the case that they're actually based on things that used to be true, but they're not really true anymore" http://steve-yegge.blogspot.com.au/2008/05/dynamic-languages-strike-back.html The compiler doesn't need to decide in advance whether or not the module attributes have been changed. It can decide that at runtime, just before actually looking up the attribute. In pseudo-code: if attribute might have changed: use the slow path just like today else: use the optimized fast path The PyPy FAQs suggest that PyPy is capable of fast, optimized attribute access in this fashion, using a guard to ensure the fast path is taken only when “this class attribute was not modified”. I'm not a compiler expert, but I would expect that this sort of technology could be adapted to do the same for module attributes. http://doc.pypy.org/en/latest/faq.html Such optimizations don't come for free: PyPy has taken a lot of development effort, and some funding from the EU. And PyPy is more memory-hungry than CPython. But that's just the same old trade-off that programmers have been doing since time immemorial: you can save time, or you can save space, but you can rarely save both together. Other dynamic languages also have proven fast implementations: for decades, Lisp (dynamic) and Fortran (static) were the two fastest languages around. If Lisp has fallen behind, it is not because it is dynamic, but because nobody is working on optimizing it. What was optimal in 1975 may not be optimal on today's hardware. Javascript and PHP also have extremely fast versions. Javascript's V8 compiler is actually two compilers in one, and it automatically swaps over to the optimizing compiler when it is appropriate: http://jayconrod.com/posts/54/a-tour-of-v8-crankshaft-the-optimizing-compiler When Crankshaft's assumptions are violated, the compiler automatically swaps back to running the unoptimized code. Facebook took a different approach with HipHop, using a JIT language translator that takes PHP and outputs compiled C++ code: https://www.facebook.com/notes/facebook-engineering/hiphop-for-php-move-fast/280583813919 HipHop is perhaps not the best example, as it does give up some of the most dynamic features of PHP, such as eval. The post above isn't clear whether using such features is prohibited, or merely falls back on the slow, regular PHP interpreter when you use them. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
