>> * It would expose potentially significant optimizations that can't be
>> made today by eliminating the attribute lookup and function call to
>> range, and thus getting rid of that little bit of dynamism nobody
>> ever uses anyway.
Tim> As I said last time this went around, I doubt the optimizations are
Tim> significant: loop overhead is generally at worst a
Tim> handful-of-percent thing in real programs, and the cost of one
Tim> global lookup+call per entire loop (not per loop *trip*) isn't even
Tim> measurable outside contrived examples.
I was thinking more along the lines of generating C or assembler on the
fly. Knowing a priori the types of the values emitted by
for i in [0, 1 .. 10]
are ints means that the code generator can mostly avoid dealing with "i" as
a Python int and instead use native ints. In
for i in range(11):
you'd have to examine the output of range() and for
for i in xrange(11):
it might be "too difficult" (whatever that means) to ascertain the types of
the elements.
...
Tim> (BTW, repeated addition is almost exactly the worst thing to do for
Tim> fp sequences; doing starting_value + iteration_ordinal * step_value
Tim> on each trip is usually much better behaved for floats.)
Yes, that's what I had in mind.
Skip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4