On Mon, 13 Jun 2005 09:22:55 +0200, Andreas Kostyrka <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
