a reader (a@b.c) on 7/22/10 wrote:
---------------------------
>anon (anon@anon.com) on 7/22/10 wrote:
>---------------------------
>>Linus Torvalds (torvalds@linux-foundation.org) on 7/21/10 wrote:
>>---------------------------
>>>a reader (a@b.c) on 7/21/10 wrote:
>>>>
>>>>odd things with store buffer replay? like what?
>>>>
>>>>are you sure it's not just L1D too small?
>>>
>
>>>I think there were a few other cases of nasty replays too,
>>>and they really end up depending very subtly about just
>>>which cycle the different micro-ops got scheduled in. When
>>>code works well, the P4 runs like a greased bat out of
>>>hell, and then some very non-obvious things can make the
>>>almost identical code take replay traps all the time and
>>>just come to a crawling halt.
>>
>>What made the P4 run so fast? Was it the high clock and ALU frequency?
>>
>>I wonder if we'll see a return of the trace cache to improve the apparent efficiency
>>and/or wideness of the x86 fetch and decoder? Preferably with the normal L1I still
>>intact. I guess the loop detector is basically that, and probably will expand to handle more cases.
>>
>
>p4 was designed for good micro-benchmark performance.
>gHz matter there.
>
>why do you want trace cache back? it worked in some
>academic cases. but it was probably a mistake to use
>it in production design.
>
>it's not easy to pin point why p4 perform so badly on real code.

In general the design sucked ass.

You want to do a shift-right instruction?

Boom 7 cycles penalty.

You wanted a CMOV type instruction (how ELSE to replace a branch?)?

Boom also BIG penalty.

All sorts of worst cases.

Just give me a chip with 512 pentium3's at 1Ghz at a cheap price.

Nearly no communication between the cores at all, or nearly not at all. No synchronisation between caches. Just embarrassingly parallel chip. *nearly* embarrassingly parallel.

Each P3 just its own memory space. Then i can run 128 tasks embarrassingly parallel.

Instead we got a P4 chip, wasting transistors.

High clocked, sure. And according to the announcement of intel at the time by 2010 we would see a 10Ghz P4.

Well so far history.

Let's bury it all :)

core2 is a winner design. Kicks butt.

All i want is a core2 chip with a multiplication unit for integers that can issue a multiplication every cycle, right now throughput cost is 3.75 cycles per multiplication.

64 x 64 unsigned int == 128 bits unsigned int split over 2 registers.

Alternative a SIMD instruction doing exactly this at a throughput of 1 a cycle.

AMD is kicking AMD silly here. Even oldie cpu's. The same thing at AMD has a cost of 2.25 cycles.

(source : Torbjorn Granlund, known to some from the GMP math library)

So this problem of intel that some instructions simply are real slow is not new and not old, it's of all times.

The chip has been optimized too much to testsuites if i may say so.

Regrettably GMP is not in specint...

>but Linus' explanation about the replays seems to be
>quite on the mark. it's possible that intel added some
>early rule-of-thumb checks on the replay path, which
>gave too many false positives, that would lead to excessive
>and unpredictable replays, hence the bad performance.