So, in clear, it's not a good idea to use `goto' for performance reasons.
It's still useful of course when it makes the code clearer.
> memory access is done becomes a controlling factor now (read/write
> whole aligned longwords when you only want to access a byte). This
> RISC-ness will go away when we get main memory that can keep up with
> the CPU clocks.
This has nothing to do with RISC (or CISC for that matter).
Furthermore, there is currently no indication that the speed difference between
memory and CPU will go away any time soon.
> It won't be too long now. The 100MHz memory will be running at 330MHz
> in a year or two. Unfortunately it's another motherboard change. So,
Changing the SDRAM interface (I assume that's what you're refering to here)
from 100MHz to 330MHz will not change the latency but only the bandwidth.
Furthermore, during this year or two processors will also increase their own
speed. In the end that means that memory bandwidth barely keeps up with CPU
requirements while latency keeps getting higher and higher (counted in number
of instructions (i.e. CPU-Mhz * IPC)).
In practice this translate into an even bigger difference in access time
between "same cache line" and "next cache line". So what you're (rightfully)
complaining about will not disappear.
> the fact that good code may not run any faster than bad code presently,
> should not be an end unto itself. In a few years, the good code
> will outperform the bad code again.
But "good code" will only apply to "cache conscious code" as opposed "reduced
instruction count" code.
Stefan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/