>>260
that it ended up being overall much much slower than running multiple commands on a fast architecture
Look at when those studies were published. Back then, they thought they could keep raising clock speeds indefinitely, and memory bandwidth was plentiful. The technology of the time was such that the disparity between CPU core speeds and memory speeds was much smaller. A lot has changed since then.
CISC->RISC subsystems on modern x86 processors
I already answered that in the first part of
>>258. I wouldn't call it "CISC->RISC" though, it's just a parallel microsequencer.
All these people brainwashed by "logic" and "mathematics" will never have your vision
The problem is the academics parroting information from out-of-date or flawed studies and failing to actually look at the reality and
think. We saw this from the discussion of register allocation earlier.
From the RISC wiki page:
"The goal was to make instructions so simple that they could easily be pipelined, in order to achieve a single clock throughput at high frequencies."
Anyone reading that should automatically think "what about the rest of the system? Can the memory keep up? Can the clock frequency be raised indefinitely?" The huge assumption they made there was that memory would always be fast enough --- and that assumption, while it may have been true in the 80s and early 90s, is not anymore. The laws of physics also weigh in on this, limiting clock frequencies. Someone who accepts that statement without questioning its assumptions is like one who believes in a religion; as that quote from one of your "idols" himself says, it's "unscientific and ultimately destructive".
When your opponent starts becoming half-unintelligible it's a good sign that he's unable to think anymore. P.S. calling someone a "retard" is far from "factual" :)
>>263
EVEN IF THE OTHER PROCESSOR CAN DO A HUNDRED INSTRUCTIONS IN THE SAME TIME
But it
can't, given the same memory bandwidth. That's the whole point. A simple calculation shows it even more clearly: Suppose you have 10GB/s of memory bandwidth. On a classic RISC with 4-byte instructions and 1 instruction per cycle (e.g. MIPS), that corresponds to 2.5GIPS. That is the
maximum speed you can execute instructions at, and would be equivalent to a clock speed of 2.5GHz. You
cannot raise the clock speed more without needing to insert wait states, even it the silicon allowed going up to 4GHz. 100 instructions is going to take 40ns, no matter what. Now consider a typical modern x86, up to 4 instructions per cycle, as low as 1 byte per instruction, and a clock speed of 2.5GHz. Assuming that 4 1-byte instructions can do as much work as the 100 RISC instructions, and runs in 100 clock cycles, they can be fetched in 0.4ns, leaving the memory bus idle for the remaining 39.6ns while the instructions execute in the core for 99 more clock cycles. Even ignoring the 4x superscalar speedup, here is where x86 has the advantage: the silicon can do more than 2.5GHz, so let's increase it to e.g. 4GHz. You can't do this for the RISC because the memory can't go any faster. The x86 is now fetching in 0.4ns and takes 24.75ns to execute, total of 25.15ns for the
four instructions of 100 clock cycles each, running in parallel. The core can be run at the highest frequency it can, not limited by how fast instructions can be fed into it. In practice, memory is a bit slower (10GB/s quoted above is a peak burst rate), so the difference is even bigger.
>>265
If by "killing" you mean repealing old misconceptions and beliefs and encouraging more critical thinking, I'm in complete agreement.
/prog/ isn't a church. Fuck this pseudo-religion.