Aceshardware

>> Liar. Here is what came out straight of Intel's presentations back then.[/quote]
>
> Hey mr. as...., that was not the first picture out on the web.

Liar.

Attached are the three pictures which Intel showed at the Fall 2007 IDF
in Paul Otellini's and Stephen Smith's presentations (on September 18).

Each of them showed the full memory controller -- no copy and paste
needed. (Check the yellow area just above that 2nd core from the left.)

> If you look at the annotated picture then you see the copy and paste I had to do.

Your copy and paste is obvious, yes.

Why you failed to start from Intel's original pictures, I do not know.

> 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.

As has been (is) Paul Otellini's original picture, which shows the whole
controller:

http://images.google.com/images?q=intel ... ehalem+die

gives me for example:

http://www.dvhardware.net/article21936.html
http://blogs.zdnet.com/Ou/?p=758
http://www.behardware.com/articles/687- ... 7-idf.html

I'll happily mail you the IDF presentations, which predate your rev 4 of

http://chip-architect.com/news/Nehalem_ ... lance_.jpg

by a month.

It isn't worse (not that it's better also) but any way it's just about the quality of recent predictions from Hans.


Hmm... I always thought that FPU is a most critical thing from the performance point of view which is actually holds back frequency increase. The only possibility for FPU troughput increasing is adding additional pipeline stages (which is alone not a simple task for mul/div algorithms) and as a result - increasing mul/div instruction latency. This can greatly affect "regular" FPU/SSE2 code. Also I heard that some stages already doublepumped in Intel's implementation of radix-16.


Why? Wasn't AMD/Intel choose to double uops to implement SSE2 on 64-bit FPUs. Also, if you already have doublepumped FPU, why not to use it for "regular" x87/SSEx by doubling throughput?


There are many SSEx instructions without data dependency which theirs 256 bit implementation was omitted to. This may point that the "second" 128-bit fpu is a bit simplier then the "first" one. Probably omitting data-dependency instriction means that the inter-fpu communications is a bit costly

I remember an Intel ISSCC presentation (2003) with a 5 GHz FMA FPU @ 90 nm, I have no more the PDF with the advance program though, now I can imagine such a design can run at 8 GHz @ 32 nm, the number of pipeline stages is also quite less critcial if it runs at twice the speed of the core clock
NB: I just found this link : http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1234322


the ones with only an AVX 128 variant are the packed integers instructions, not the packed SP/DP fp instructions



yes just a small bit since only the packed ints are missing

Instead of coward anonymous insults now, two years after, you could
have asked me about this when I posted the first revision of this here:


http://aceshardware.freeforums.org/nehalem-at-idf-t141.html

It was the only high res image I had available (which was from before IDF).
Instead you posted a rather denigrating remark about how silly I was to
presume an L3 cache on Nehalem.....



I think I nevertheless responded polite. I don't see anything in my reaction
which explains your aggression.......

Regards, Hans

What "predictions" did cause your outrage? Was it that I insulted you in some way,
or did you simply dislike what I said?