David Kanter (dkanter@realworldtech.com) on 2/6/09 wrote:
---------------------------
>Linus Torvalds (torvalds@linux-foundation.org) on 2/5/09 wrote:
>---------------------------
>>David Kanter (dkanter@realworldtech.com) on 2/5/09 wrote:
>>>
>>>This article talks about the catalyst for the delays, which
>>>was primarily a change in the platform, and the history and
>>>decisions that ultimately lead to the delay.
>>
>>The much more interesting issue is if they fixed anything
>>else than the platform?
>>
>>You compare to (very optimistic) POWER6 platform numbers,
>>and try to make it out to be the achilles heel of Itanium,
>>but look at Spec numbers, and realize that the weakest
>>point of Itanium was never the platform - it's the core.
>>
>>SpecInt runs basically close-to-100% out of the cache, and
>>of all the architectures out there, Itanium is way way
>>behind the competition. Improving on the platform will do
>>absolutely nothing to that, since it isn't even
>>relevant.
>>
>>Look at the SpecInt2006 numbers:
>>- Core i7-965: 36
>>- p570 (4.7Ghz): 21.7
>>- Itanium (1.66GHz/18MB): 17.0
>>
>>Now, the Core i7 number is obviously much more recent than
>>the other two, but hey, that's what Tukwila will be facing.
>>(And quite frankly, you can find old Core 2 numbers that
>>are just under 30, so even if you want to go back to the
>>previous generation, you're really not changing the argument
>>at all).
>
>So, I'm curious, what recommendations would you make for improving the Itanium 2 core?
>
>the most obvious would be move to a single bundle core, perhaps add OOO. Or you
>could go niagara style to hide latency...
>
>David

a) just focus upon integers as the floating point battle has been lost already so bigtime that supporting floating point is already questionable

b) kick out SSE*, as other solutions will be way faster for vectorisation anyway. Don't compete with your other products i'd argue. This platform is supposed to run integer code faster than other platforms.

c) don't build SMT. Though it is good for testsets, forget now for once please, this just slows down speedup. Spec is calculating namely in a wrong manner. They don't count speedup, just scaling they measure. In the manner they count a big cluster always is faster.

d) make a design that clocks high, historically intel always sold well as they clocked higher, abandoning that with itanium was bad idea, except when condition E gets flfilled

e) put 128 cores on a chip. Just do the math of: "how can we have a multicore that executes the maximum amount of x86/x64 instructions for software that can get easily ported to multicores, without a single vector instruction. Doubling the number of cores is always better than 1% speed increase adding a lot of transistors to get higher IPC.

f) don't focus upon really huge L3 cachesize, just use the amount of L1/L2/L3 that is needed for getting the cores enough busy. Be sure to allow instructions to get from L2 to L1.

g) reduce bundles from being in total 6 instructions to 4

h) keep it inorder bundle processor, i was told that this needs less transistors than OoO, and i don't want to blow my odds for a 128 core chip this time

i) clock it as high as possible

j) most important: use the latest processtechnology to produce it. If x86 gets produced on 32nm, then this design also. If x86 gets produced at 10nm, then don't have the illusion that a $7500 chip produced at 32 nm can outperform a x86 chip produced at 10nm. A bunch of those 10nm cpu's then always will prove to be a cheaper solution and we'll go for that in that case.

k) have shared memory and possibility for at least 4 sockets at mainboard, as then i can have 512 cores.

Idea is 1 machine with a lot of shared memory and a huge number of cores.

All the military researchers and algorithmic investment financial dudes (same type of guys, both studied math especially), they want to run their sucking monte carlo software (game tree technical i can write down a simple proof that there exists better algorithms, but heh, i'm not getting paid by them to improve their model to something better).

You don't want to know how many cores they run. It's sick even how many. Power6 very popular there now.

Oh they CAN use shared memory, most slowly figure that out now, that this works better.

Think dead simple: IPC 1.0 effectively * 512 cores * 2Ghz = 1 trillion instructions a cycle.

That destroys any other hardware platform from Diep's viewpoint seen.

Make me a shared memory box that executes Diep real fast.

Don't have compromises like: "we want floating point". Forget vectors, forget floating point. Too complicated to write software for, too complicated to recompile software for. Other hardware platforms will win the gflops battle anyway.

If you can make this chip, also consider producing a second chip, doing exactly the same thing like this, just not integers, but double precision floating point only.

Nothing vectors of 2 doubles. That's making things too complicated.

"yes but at specfp program XYZ it speeds up bla bla"

Forget those discussions. Just make a chip that can execute me more instructions a cycle than anything else for software that doesn't profit from VECTORS.

For vectorisation we can buy a Tesla, or so i was told larrabee or whatever AMD shows up with, not to mention IBM.

Think simple. Compare how fast Beckton Xeon MP can be for my proggie.

4 sockets 8 cores we're talking.
First action i undertake in bios is turn off HT.
Away with logical cores. SMT makes sense in highend chippies like power6 from ibm or Alpha 21464. HT for my proggie in x64 is not so useful for speedup (scaling of course it is).

4 sockets * 8 cores * 3ghz * 2 ipc = 192 billion instructions a cycle from which i use in many cases just 8-32 bits. Actually 8-20 bits in most cases.

I compile in 32 bits of course with pgo. Faster than 64 bits (1.34% misses in L1i). Branches eat the biggest toll (12.2% at opteron, regrettably cachegrind doesn't have a model of how core2/nehalem is doing branch prediction).

So a quad socket platform capable of 1T instructions a cycle i would be happy with.

Most important condition: MULTICORE.

Vincent