On 2018-01-26 08:18 PM, Chris Barker wrote:
If there are robust and simple optimizations that can be added to
CPython, great, but:
This mail is the consequence of a true story, a story where CPython
got defeated by Javascript, Java, C# and Go.
at least those last three are statically compiled languages -- they
are going to be faster than Python for this sort of thing --
particularly for code written in a non-pythonic style...
Java and C#? Statically compiled? Haha.
No.
Java has a bytecode. While yes, Java doesn't need to compile your code
before running it, the compilation time in CPython is usually minimal,
unless you're using eval. You can precompile your python into bytecode
but it's usually not worth it. Java can also load bytecode at runtime
and do bytecode manipulation stuff.
The only "real" benefit of Java is that object layout is pretty much
static. (This can be simulated with __slots__ I think? idk.) See also,
for example:
http://luajit.org/ext_ffi.html#cdata
(The same goes for C#. Idk about Go.)
(Ofc, their JITs do also help. But even with the JIT off, it's still
pretty good.)
def filter(rule, whatever):
if rule.x in whatever.x:
return True
rules = get_rules()
whatevers = get_whatevers()
for rule in rules:
for whatever in whatevers:
if filter(rule, whatever):
cnt = cnt + 1
return cnt
It's true that they didn't optimize the code, but
they did not for any language having for all of them the same cost in
terms of iterations.
sure, but I would argue that you do need to write code in a clean
style appropriate for the language at hand.
For instance, the above creates a function that is a simple one-liner
-- there is no reason to do that, and the fact that function calls to
have significant overhead in Python is going to bite you.
for rule in rules:
x = rule.x
for whatever in whatevers:
if x in whatever.x:
cnt += 1
The performance of the CPython boosted x3/x4 just doing these
"silly" things.
"inlining" the filter call is making the code more pythonic and
readable -- a no brainer. I wouldn't call that a optimization.
making rule.x local is an optimization -- that is, the only reason
you'd do it to to make the code go faster. how much difference did
that really make?
I also don't know what type your "whatevers" are, but "x in something"
can be order (n) if they re sequences, and using a dict or set would
be a much better performance.
and perhaps collections.Counter would help here, too.
In short, it is a non-goal to get python to run as fast as static
langues for simple nested loop code like this :-)
The case of the rule cache IMHO is very striking, we have plenty
examples in many repositories where the caching of none local
variables is a widely used pattern, why hasn't been considered a way
to do it implicitly and by default?
you can bet it's been considered -- the Python core devs are a pretty
smart bunch :-)
The fundamental reason is that rule.x could change inside that loop --
so you can't cache it unless you know for sure it won't. -- Again,
dynamic language.
The case of the slowness to call functions in CPython is quite
recurrent and looks like its an unsolved problem at all.
dynamic language again ...
If the default code that you
can write in a language is by default slow and exists an alternative
to make it faster, this language is doing something wrong.
yes, that's true -- but your example shouldn't be the default code you
write in Python.
BTW: pypy looks like is immunized [1]
[1]
https://gist.github.com/pfreixes/d60d00761093c3bdaf29da025a004582
<https://gist.github.com/pfreixes/d60d00761093c3bdaf29da025a004582>
PyPy uses a JIT -- which is the way to make a dynamic language run
faster -- That's kind of why it exists....
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov <mailto:chris.bar...@noaa.gov>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
