3 ms·
You are assuming that Python code executes the same way that a C code does. There is a whole lot more going on in a Python execution, so intuition drawn from C
by srean 12y ago
You are assuming that Python code executes the same way that a C code does. There is a whole lot more going on in a Python execution, so intuition drawn from C does not apply line by line to Python code. You have to think in terms of Python bytecode and think about how that byte code is interpreted by CPython. You have to think about the fact that Python is dynamic so for every value it also has to look up the type. But then I would not have known all this when I was 17, not even the C execution model, so keep hacking.
In fact I redid my tests and reduce is actually consistently faster than the for loop. Not by much but always faster (by that I mean the minimum of 10 runs of reduce is faster than the minimum of 10 runs of for loop. My box was fairly loaded during these tests https://news.ycombinator.com/item?id=7961091 https://news.ycombinator.com/item?id=7961091 , the numbers halved when I tried again, but their relative ranking remains the same.
- thegeomaster 12y agoThat is a fair point. Perhaps I got too carried away by analyzing the raw performance that I forgot what kinds of things need to happen behind the scenes. However, I imagine that the type checking has to be done by reduce as well as within a loop. Reduce is probably faster because the underlying native C function can iterate over a vector faster than the bytecode-compiled for loop, and since you're passing a builtin to it, it doesn't ever need to leave the native realm until it returns from reduce. If the for loop wasn't JIT'ed, I'd understand why this is slower. What about PyPy? How about trying the code on that? Maybe it will be smart enough to compile the for loop into native code that is equivalent to the reduce builtin. I'm really curious about what happens under the hood here...