«

On Fri, 3 Sep 2010 21:17:44 +0100, "BartC" <> declaimed
the following in gmane.comp.python.general:


> I'm not sure the Python developers were interested in getting fast loops.
>
> For-loops which iterate between two numbers are amongst the easiest things
> to make fast in a language. Yet originally you had to use:
>
> for i in range(N):
>
> which (if I understood correctly) actually created a list of N objects,
> populated it with the values 0, 1, 2...N-1 (presumably using a more sensible
> loop), then iterated between the values of the list!
>

In those languages in which a for loop cycles over a range of
integral values (or even floating point values) one often ends up with
code that then performs subscripting to access the real goal of the
loop...

The Python for loop is innately focused on giving one an object from
some iterable (list, tuple, dictionary, user-defined...) with which one
can directly process... Compare {pseudo-code}:

for item in world_objects:
item.update(simulation_time)

to

for i in range(len(world_objects)):
world_objects[i].update(simulation_time)

Those languages that have optimized numeric-only (integer-only in
some cases) for loops do not support the clean interface of the first
sample and force all access to look like the latter.

--
Wulfraed Dennis Lee Bieber AF6VN
HTTP://wlfraed.home.netcom.com/

On Fri, 03 Sep 2010 21:17:44 +0100, BartC wrote:


> I'm not sure the Python developers were interested in getting fast
> loops.
>
> For-loops which iterate between two numbers are amongst the easiest
> things to make fast in a language. Yet originally you had to use:
>
> for i in range(N):

I don't have any versions of Python prior to version 1.5, but as far back
as that there was always a choice between creating a list with range()
and a lazy iterator with xrange().

> which (if I understood correctly) actually created a list of N objects,
> populated it with the values 0, 1, 2...N-1 (presumably using a more
> sensible loop), then iterated between the values of the list!

By "more sensible", do you mean "in C code"? If so, then you are correct.


> So Python had the distinction of being one of the slowest languages in
> which to do nothing (ie. running an empty loop).

Nonsense.


[steve@sylar ~]$ time python test.py

real 0m3.441s
user 0m2.969s
sys 0m0.024s
[steve@sylar ~]$ time perl test.pl

real 0m3.490s
user 0m2.722s
sys 0m0.011s
[steve@sylar ~]$ time ruby test.rb

real 0m11.875s
user 0m6.740s
sys 0m3.995s


The difference between an empty loop in Python and Perl is insignificant,
and much faster than Ruby (at least the specific version of Ruby
installed on my machine, 1.8.6).

And if you want to see the code I ran:


[steve@sylar ~]$ cat test.*
# perl
for ($i = 0; $i < 10_000_000; ++$i) {
1;
}
# python
for i in xrange(10000000):
1
# ruby
for i in 0...10000000
1
end


Just for comparisons' sake:

[steve@sylar ~]$ gpc empty_test.p
[steve@sylar ~]$ time ./a.out

real 0m0.106s
user 0m0.070s
sys 0m0.004s
[steve@sylar ~]$ cat empty_test.p
program main(input, output);
var
i: integer;
begin
for i := 0 to 10000000 do
begin
end;
end.


Of course, a real optimizing compiler would realise that the Pascal code
did nothing at all, and compile it all away to an empty a.out file...



--
Steven

Steven D'Aprano, 05.09.2010 17:00:
> Of course, a real optimizing compiler would realise that the Pascal code
> did nothing at all, and compile it all away to an empty a.out file...

Which is just one of the reasons why this kind if "benchmark" provides no
insight into anything that should have an impact on a programmer's daily job.

Stefan