[Tutor] who makes FOR loop quicker

[Alan Gauld]

On 06/08/15 14:28, John Doe wrote:
> Well, I think, both of us understands that any reference isn't about any
> sort of a language. It's about REGISTER = [ALU, FPU, ...]
>

No thats about the implementation.
The language and implemewntation are completely separate.
There can be many different implementations of a single
language and they all have to follow the semantics defined
by the language but are free to build those semantics
any way they like. (And indeed the different versions
of Python do just that!)

> While You're talking about Python - You're talking ONLY about
> interpreter for a BYTEcode
> Alas, CPU don't speak BYTEcode but BITcode.

Some do. Some speak higher level things. For example
some CPUs speak Forth. And still others don't use binary
at all but use tri-state values. There werte even some
in the early days that used 4-state values. But these
are all implementation details that the programmer
doesn't need to care about.

> So, Python can't allocate memory for CPU only for interpreter, which
> will ask allocation through underlying-C-language.

Not necessarily. The interpreter could get C to allocate
a huge pool of memory at startup and then use that for
its own allocation/deallocation purposes.

> CPU have compiler for Python?

Not yet but it is theoretically possible.
And python would not change if someone built one.

> As well as multithreading, for instance, in Python goes to a single
> interpreter, but in C - to multiple cores of CPU.

That depends on the implementation. I have a C compiler
that does not do multi-core/thread working. It's an
implementation detail and the C language does not
specify that it must. It all depends on the code that
the compiler generates.

>  So Python doesn't have
> REAL multithreading, but C - does.

Python does. But not all of its implementations do.
The emulate it instead.  But so far as the programmer is
concerned his code is using threading/concurrency.
He may need to be aware that the implementation is not
honoring his request fully but that doesn't change his
code.

> And in my case by means of C-rules Python allocates FOR-loop's list as a
> reference.

No, the C implementation might do that. Python as a language
does not. High level languages exist to stop us thinking about
the low level details. The implementation may change, that's not our 
problem. Python specifies how the Python execution model works
not how the CPU or the assembler, or the compiler or the
implementer interprets that.

Even C has many different implementations. Some are more efficient
than others. Should we be worrying about which C compiler was used
to build our interpreter? Should we care about whether the CPU 
implements multiplication in hardware or in microcode? Or whether it 
caches local variables on on-chip cache or uses main memory?

And what about the I/O routines. Do we need to worry about
whether our chosen C compiler is using it's own I/O library,
or calling the BIOS directly?  or using the OS system calls?
These are all implementation details that regular
programmers can, and should, ignore.

> And that mistake wastes each iteration of FOR-loop in
> unnecessary RE-evaluation of initial-list IN LOGIC STATEMENT, which must
> be created only once. Any INITIATIONS make once. 'Cause it sucks
> CPU-memory-allocation-cycle.

In the modern world of fast CPUs and memory and where the vast majority 
of applications run in virtual machines(JVM, .Net) and the vast majority 
of servers run inside virtualized environments (VMWare etc)
none of that is of the slightest concern to me.

If I was writing code for an embedded system it might be more worrisome, 
but then I'd probably not be using Python for that.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos