Default (structuredmayhem@hotmail.com) on 2/6/09 wrote:
---------------------------
>Since your post was long, I'll try to keep my response simple.
>
>128 cores with small caches one a chip is a pipe-dream. Yes, the logical core
>of the Itanium is small, but it's not that small.
>
>Take for example, Madison, the first "real" Itanium worth talking about, because
>it had a respectable amount of cache to keep the processor fed.

That is another pipedream from most HPC guys, the huge L3 caches.

From all the different software i know that runs at itaniums, ranging from CFD's, to prime number crunching, to financial data, a 1MB L3 cache is doing just as well as a bigger L3 cache.

A bigger L3 cache for itanium only did do really well at specint/specfp. Other than these 2 testsuites a real giant L3 cache is not much of a help for all real world applications i know.

I see many different types of applications and none of them has a need for a tad larger L3. That really speeds up under 0.1% for them.

At specfp/specint it's maybe factor 2 or so for a 1MB L3 versus 16MB L3?

For my own proggie Diep, if you google a bit you already can find objective measured results. Johan de Gelas measured a 512KB L2 was not slower than a 2048KB L2.

On the other hand, increasing L1 size from 64KB to 128KB
has a very healthy impact at my software. Again not all softwares around me.

>At 374mm^2 on a
>0.13 micron process, it's a big one, and at best, you'll fit two of these boys on
>a 90nm process (Montecito), four on a 65nm process (Tukwila), and eight on a 45nm
>process, and sixteen on a 32nm process.

How about improving the core and getting rid of that much L3 cache?

>Even if you nix some more cache, the best you can get is around 16/32 cores using
>your cutting-edge 45nm/32nm processes (this is ignoring the overhead of cache coherency
>support, which gets more complex as you add more cores).

In contradiction to some regular posters here, i have faith in engineers to find clever ways to solve problems. I'm really disappointed in most commissions in that sense. They are so paranoia and trusting so little people, they usually only go for 'proven technology'. No one can outclever a commission huh?

So 64 core multicore should be no problem i read from your estimate in 32 nm. That's great.

>In addition, cutting the
>cache has a LARGE detrimental effect on performance with EPIC, because the processor
>takes every branch until the test is evaluated (see my post above). You're just
>not going to get 128 cores on a chip with EPIC.

Question is: does EPIC need MORE or LESS transistors to get to the same IPC like out of order?

>As for getting rid of vectors...vectorization is a necessity today! Vectorization
>cuts-down on the instruction decode overhead of having individual instructions,
>placing the burden on software. Sure, it sucks for many tasks, but the reality
>is that the costs of adding it are less than the costs of adding another ALU/FPU
>and another dispatch pipe to keep it fed.

Well how about a chip design where you DEMAND that the same software code and program executes at n cores. So it is a multicore that reads instructions from the same instruction cache and you have garantuee that for all the n cores it is the same program executing (kind of similar to how the operating systems do it). However each core is a multicore and can be at a different spot in executing the code.

Vectorisation is evil as it requires you must make new software and that eats a lot of time which not many are going to do. Only for tiny programs you can get away usually. For experimental codes like game tree search it is very difficult to make a quick test that also vectorizes.

Most algorithms is easy to experiment with at a multicore level and near to impossible at vector level. Practical no one is doing experiments at a vector level in game tree search, yet there is millions of people involved all together there.

>And I wouldn't decrease the number of instructions in a bundle - the number of
>instructions within a bundle defines the upper-bound of IPC for Itanium. Changing
>this would also mean you'd need a new set of optimizing compilers.

Well this is a valid point, but my question would be how many of those 2 bundles of 3 can be at latest intel design integer instructions?

In that madison only 2 out of 6 could be integers. So it is executing code at a maximum efficiency of 33%. Or did i calculate that wrong? (maybe a bit better considering cache fetches, am not knowledgeable there)

So in that case from the core 66% is total wasted already if not more as it doesn't deal with integers?

Thanks,
Vincent