[Tutor] who makes FOR loop quicker

[John Doe]

Thank You, Alan.

This is THE FIRST time, when I've got a pleasure from the opponent.
You're maintain status of a thinking human and, as a humble DAOist, I 
always say THANK YOU, when I talk to such a Man.
'Cause wisdom bring us the beauty.

So, what else I can add.
Just a little bit.

It would be great to work with You.
You know, life is so shot..
And any talks don't make it better, alas.

Just we can do.



Alan Gauld 於 08/06/2015 09:54 PM 寫道:
> 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 searate.
> 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.
>