Stockfish 1.7 and benefit of hyperthreading?

[Aaron Becker]

Itanium made the mistake of depending too much on a good static schedule, which compilers aren't good enough to deliver in practice, and will never work well for backwards compatibility. But the worst thing about Itanium is that its failure has made all the big chip designers extremely conservative with their new designs. There has been some innovation in floating point accelerator architectures and many-core architectures, but nothing that seems like it will displace the current kings of the hill. Too bad; I'd really like to see someone manufacturing an EDGE chip, for example.

[Gian-Carlo Pascutto]

But the worst thing about Itanium is that its failure has made all the big chip designers extremely conservative with their new designs. There has been some innovation in floating point accelerator architectures and many-core architectures, but nothing that seems like it will displace the current kings of the hill.

What other techniques are there to improve single-thread performance that someone who wants to take a risk could use?

Too bad; I'd really like to see someone manufacturing an EDGE chip, for example.

What's that?

[Robert Flesher]

But the worst thing about Itanium is that its failure has made all the big chip designers extremely conservative with their new designs. There has been some innovation in floating point accelerator architectures and many-core architectures, but nothing that seems like it will displace the current kings of the hill.

What other techniques are there to improve single-thread performance that someone who wants to take a risk could use?

Too bad; I'd really like to see someone manufacturing an EDGE chip, for example.

What's that?

Good question! All I could find was this:
http://www.3gnewsroom.com/3g_news/feb_0 ... 6679.shtml


Unlikey what he meant, but, all I could find on the "EDGE" chipset, etc, etc.

[jwes]

Well, I don't know Itanium, so for all I know its design could be as crappy as x86. But doing things at run time a billion times what could have been done once at compile time once, still sounds like a bad idea.

It's not quite like that. With x86, the compiler orders instructions as best it can, and then the processor does more at run time.

[hgm]

True, but the need to do it at run time is much bigger because of the clumsy x86 architecure. There just aren't enough registers to schedule all loads long enough in advance to account for the latency of an L1 miss. So you become really dependent on register renaming to remove false dependences, (i.e. two instructions using the same register for independent date), which then makes reordering possible.

[Aaron Becker]

But the worst thing about Itanium is that its failure has made all the big chip designers extremely conservative with their new designs. There has been some innovation in floating point accelerator architectures and many-core architectures, but nothing that seems like it will displace the current kings of the hill.

What other techniques are there to improve single-thread performance that someone who wants to take a risk could use?

Too bad; I'd really like to see someone manufacturing an EDGE chip, for example.

What's that?

EDGE is a design that breaks the code down into independent data graphs, and encodes a lot of information about the program's dataflow graph explicitly in the ISA. It's sort of similar to VLIW architectures like Itanium in that it breaks the program into large execution blocks, but it doesn't require a static schedule within the blocks. There's a group at UT Austin that's working on an EDGE architecture called TRIPS. Here's a nice overview article: http://www.cs.utexas.edu/ftp/pub/dburge ... _trips.pdf

Generally I think that there are a lot of architectures that should be reconsidered now that the memory wall has become such a barrier to high performance code and clock scaling has fallen off. Stuff like dataflow architectures and Tera. Turnaround time and capital investment for new chip designs are still really high, though, and there's a strong bias towards the status quo in architecture for good reasons.

[jwes]

True, but the need to do it at run time is much bigger because of the clumsy x86 architecure. There just aren't enough registers to schedule all loads long enough in advance to account for the latency of an L1 miss. So you become really dependent on register renaming to remove false dependences, (i.e. two instructions using the same register for independent date), which then makes reordering possible.

I am not going to argue that there is much good about the x86 architecture, though register renaming and OoO execution masks many of its faults. In fact, I think that the biggest mistake AMD made in the x86-64 was making it almost binary compatible with x86 rather than assembly language compatible.

[Gian-Carlo Pascutto]

They had good reasons to do so: the x86 architecture has been proven to be scalable beyond its limitations.

For some of the supposedly better and elegant designs, that's still an open question.

Just see ARM->Thumb->Thumb2 evolution for example.