> >>>>> "Richard" == Richard B Johnson <root@chaos.analogic.com> writes:
> > machine-code on a fast machine. However, with the advent on the 400+
> > MHz processors, where everything is now I/O bound with main memory,
> > it seems to become less important to minimize instructions. The way
>
> 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.
On the contrary.
>
> > 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.
Currently SOS (silicon on saphire) runs up to 30 GHz. With current-seeking
logic, where voltages are not changing, therefore capacity is not
a controlling factor in establishing speed, prototype CPU cells are
already being tested.
Given that typical application software requires multiple CPU operations
for every RAM access, a balance will occur when the CPU operations
just fit between the RAM access.
> > 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.
This is double-speak. CPUs execute instructions sequentially, which they
presently get from RAM. Logic requires that this instruction sequence
is not necessarily sequential in RAM (hense caching).
Data are not necessarily accessed sequentially. Long buffers are not the
most common RAM access. The most common access are register-size variables
scattered all over the place. It is harder to keep this in a cache.
Therefore RAM access-time is the domanent pole in the transfer-function
unless you are running tinny spinning-loop benchmarks which mean nothing.
> 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.
>
You may disagree. However, from what I've seen in the Labs, there is
a concerted effort to re-balance CPU vs RAM speeds. One of our divisions
is Sky Computer, makes array-processors with "Sky High" performance.
These are mostly sold to the Armed Services, however since the technology
now exists to make real fast stuff, and the yields are getting good, it
will not be long before you get at least the RAM you need.
> > 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.
If you get RAM that runs at twice cache-speed you won't need a cache
(there will probably always be an instruction cache so branch prediction
works).
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.1.131 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
Wisdom : It's not a Y2K problem. It's a Y2Day problem.
-
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/