What is different with Python ?

[Andrea Griffini]

On Mon, 13 Jun 2005 09:22:55 +0200, Andreas Kostyrka
<andreas at kostyrka.org> wrote:

>Yep. Probably. Without a basic understanding of hardware design, one cannot
>many of todays artifacts: Like longer pipelines and what does this
>mean to the relative performance of different solutions.

I think that pipeline stalls, CPU/FPU parallel computations
and cache access optimization is the lowest level I ever
had to swim in (it was when I was working in the videogame
industry, on software 3D rendering with early pentiums).
Something simpler but somewhat similar was writing on
floppy disks on the Apple ][ where there was no timer
at all in the computer excluding the CPU clock and the
code for writing was required to output a new nibble for
the writing latch exactly every 40 CPU cycles (on the
Apple ][ the CPU was doing everything, including
controlling the stepper motor for disk seek).

However I do not think that going this low (that's is still
IMO just a bit below assembler and still quite higher than
HW design) is very common for programmers.

>Or how does one explain that a "stupid and slow" algorithm can be in
>effect faster than a "clever and fast" algorithm, without explaining
>how a cache works. And what kinds of caches there are. (I've seen
>documented cases where a stupid search was faster because all hot data
>fit into the L1 cache of the CPU, while more clever algorithms where
>slower).

Caching is indeed very important, and sometimes the difference
is huge. I think anyway that it's probably something confined
in a few cases (processing big quantity of data with simple
algorithms, e.g. pixel processing).
It's also a field where if you care about the details the
specific architecture plays an important role, and anything
you learned about say the Pentium III could be completely
pointless on the Pentium 4.

Except by general locality rules I would say that everything
else should be checked only if necessary and on a case-by-case
approach. I'm way a too timid investor to throw in neurons
on such a volatile knowledge.

>Or you get perfect abstract designs, that are horrible when
>implemented.

Current trend is that you don't even need to do a
clear design. Just draw some bubbles and arrows on
a white board with a marker, throw in some buzzword
and presto! you basically completed the new killing app.
Real design and implementation are minutiae for bozos.

Even the mighty python is incredibly less productive
than powerpoint ;-)

>Yes. But for example to understand the memory behaviour of Python
>understanding C + malloc + OS APIs involved is helpful.

This is a key issue. If you've the basis firmly placed
most of what follows will be obvious. If someone tells
you that inserting an element at the beginning of an array
is O(n) in the number of elements then you think "uh... ok,
sounds reasonable", if they say that it's amortized O(1)
instead then you say "wow..." and after some thinking
"ok, i think i understand how it could be done" and in
both cases you'll remember it. It's a clear *concrete* fact
that I think just cannot be forgot.

If O(1) and O(n) and how dynamic arrays could be possibly
be implemented is just black magic and a few words in a
text for you then IMO you'll never be able to remember
what that implies, and you'll do soon or late something
really really stupid about it in your programs.

Andrea