Aceshardware

Hi, Eric

".....vs. 1.0X if we had double pumped......"

I read "double pumped" here as "using two cycles per 256 bit operation" at the same
frequency which would indeed give you a maximum speed up of 1.0X compared to the
current architecture, as he says.

Using two cycles at double the frequency should give a maximum speed up of 2.0X
compared to the current architecture. (limited to 1.42X due to the L1 cache write
ports with 48 bytes per cycle, in the case if that's the bottleneck)

I would expect a >20% increase in core-size with all 256bit units which simply isn't there.
There should also be this 1500+ entry trace cache increasing the core transistor count...

Regards Hans
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~ http://www.chip-architect.com ~~~ http://www.physics-quest.org ~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Nehalem core:

well maybe, there is some clues (in the same thread at the AVX forum) in favor of your hypothesis :
- the "wrong chart" with AVX HIGH and AVX LOW labels
- Intel's Shih Kuo remark : "It seems point 1) may have assumed it requires monolithic 256-bit hardware to achieve 1 cycle throughput for 256-bit AVX instructions. That's not true."


I never heard of it for Sandy Bridge, where did you get the info ? a patent ?

Oh no... Hans repeats that crap again and again... Although, given the long history of incorrect predictions about the the Intel's architectures, it should not greatly surprise.

come on stupid, don't you see it's a lot of fun to try to predict these things?, even if proved partially wrong sometimes

For a fact that this picture is a year before the launch (November 17, 2008). It is rather close. It's not perfect, but also not bad.

J

The image is called "Nehalem_at_1st_glance" and is based on the
very first raw Nehalem die picture which:

1) Totally conceals the L2 caches under the wiring.
2) Has half of the memory interface cut off !!

I had to paste another copy of the raw die's memory interface on top
of the annotated die to make the size fit with that from later photo's..
The only info from intel was the transistor count.

Regards, Hans

> I had to paste another copy of the raw die's memory interface on top
> of the annotated die to make the size fit with that from later photo's..

Liar. Here is what came out straight of Intel's presentations back then.

Wasn't it confirmed many times that making predictions on the microarchitecture, based on low-quality, low-resolution photos is a bad idea?
But even worse idea, it is to protect his unfulfilled predictions, inventing more incredible predictions. Although, I do not think that double pumped fpu is a bad idea, but even in so "speed demon" architecture as Netburst, Intel was able to implement only double pumped simple integer ALU (ADD/SUB). Now, if Intel is able to implement double pumped FPU and double pumped sheduler in SB, I see no reason why not to implement double pumped integer part as well. This thing only would give something like 50% bust overall on integer code. But this is too good to be true.

With so many double pumping why not just double the frequency? :)

What's so hard to believe about doubled FP resources on Sandy Bridge? According to PCWatch, the core size has indeed become slightly larger on Sandy Bridge compared to Westmere(unlike your analyzations).

I don't know what it is. Anti-Intel or Pro-AMD or a bit of both? Far as I remember you didn't have such bias mere few years ago.

please ignore

I don't see why it's worse than basing them on nothing at all


I'll be interested to learn from the EE of the board with recent experience (if any) if it's indeed possible (i.e. to have the FPU at roughly 8 GHz on 32 nm) My understanding is that it's self contained in a small area so it's far easier to have it at twice the core clock than wider structures with more wiring delay


It's another subject entirely, isn't it ?


since each regular ALU has already 1 clock throughput for common operations and since the L1D cache, decoder and scheduler (for ex.) are the limiting factors, I don't see how do you find this 50% speedup ? => please provide more details

Hey mr. as...., that was not the first picture out on the web.

If you look at the annotated picture then you see the copy and paste I had to do.
The memory interface contains two identical parts. It has been there all the time,
copied many times over on the internet as a lasting proof.

This is a fully automated process. The functional logic doesn't need to be faster.
Point is that there are no data-dependencies between halfstages. It's just inserting
flip-flops at the right locations where the signal propagation is at half the cycle time.

I discussed this data dependency issue Agner who looked at AVX in great detail.
He concluded that all instructions which would give data-dependencies were omitted.


Regards, Hans

Intel would simply be way smarter to do it in the fashion I described:

1) Using less die area.
2) Using less static energy (leakage)

At least I would try to do it this way.

I don't get why people get angry and outraged. I remember a similar outrage
because my simple annotated Nehalem picture had an L3 cache in it instead
of a common L2 cache shared by all eight threads.

One or two were extremely insulting towards me. The only thing that you can
do is to ignore those people and avoid getting angry as well and hitting back.
The'll turn in stalkers that follow you all over the internet in order to insult
and harass you anonymously wherever and whenever they can.


Regards, Hans