Nehalem-EP......BLOOMFIELD

[Hornet331]

im still waiting for benches from a not beta platform.

[JCornell]

im still waiting for benches from a not beta platform.

Almost become Alpha platform
Nehalem chips already released ES Rev. C0 & C1

[OBR]

Yeah, my CPU has retail revision ... and mobo is last Rev. before Retail ... my platform become almost Retail ...

[Linchpin]

Yeah, my CPU has retail revision ... and mobo is last Rev. before Retail ... my platform become almost Retail ...

Well that took away a fair bit of my enthusiasm for Nehalem, thanks for the info

[Drwho?]

I don't think Nehalem will be another Prescott. But it seems strange to have crippled the L2 by such a large amount. L3 shared on all 4 cores is good, but certainly the value the L2 was playing was known. It's going to certainly be interesting to see where the i7 does well and where it does not before pushing the "buy" button...

Here is an interresting topic ...

Ronak and I argued for 4 years on this topics, we did extensive study on this, Ronak architect team vs the Performance team. I was very afraid that it will cause too much latency increase. After 2 years of arguying, I was forced to admit that I was wrong, and Ronak was right. The increase of latency in smaller than anything you can measure on real application. The multi-layer prefetcher does its job, as it did on Core 2 via the FSB.

The explanation is so simple that it is scary ... The memory prefetcher from L2 to L3 is working almost 100% because the pattern from L2 to L3 is filtered by the L2, I mean, the L2 remove most of the unpredictable pattern.

Ronak was and is right, the L2 cache of Nehalem does not cause any issue.

I actually like when the architects are right, and I am wrong, it mean that we will have a kick a// product.
And remember Andy's moto: "Only paranoid survive", it is my job to apply this to Intel's product

[informal]

Here is an interresting topic ...

Ronak and I argued for 4 years on this topics, we did extensive study on this, Ronak architect team vs the Performance team. I was very afraid that it will cause too much latency increase. After 2 years of arguying, I was forced to admit that I was wrong, and Ronak was right. The increase of latency in smaller than anything you can measure on real application. The multi-layer prefetcher does its job, as it did on Core 2 via the FSB.

The explanation is so simple that it is scary ... The memory prefetcher from L2 to L3 is working almost 100% because the pattern from L2 to L3 is filtered by the L2, I mean, the L2 remove most of the unpredictable pattern.

Ronak was and is right, the L2 cache of Nehalem does not cause any issue.

I actually like when the architects are right, and I am wrong, it mean that we will have a kick a// product.
And remember Andy's moto: "Only paranoid survive", it is my job to apply this to Intel's product

Interesting post ,thanks.

Do you have any comments on OBR's post here,especially on power consumption in full load(supposedly a lot higher than on 45nm C2Q):

My first impressions with own Nehalem ...

1. BIOSes and whole platform is still very immature ...
2. Only little raised reference clock causes massive unstability ...
3. Ocing of locked-multi Nehalems will be a problem ... Reference clock of Bus is not like a FSB - my max stable clock is 140MHz from 133MHz
4. If you want great clocking, you need a Extreme chip with unlocked multi
5. With these early BIOSes is Memory performance poor (or Everest dont know how to measure it?)
6. Power consuption is in idle with all power savings great, but in fully load is far away from 45nm Quads ...
7. Max stable ocing was on my chip about 3500MHz ...
8. Performance is various, read my previous posts in this thread ...
9. We have two months to launch, and i believe Intel will do many improvements to that date. Will see next month, with new BIOSes and maybe different mobo ...

[bowman]

Here is an interresting topic ...

Ronak and I argued for 4 years on this topics, we did extensive study on this, Ronak architect team vs the Performance team. I was very afraid that it will cause too much latency increase. After 2 years of arguying, I was forced to admit that I was wrong, and Ronak was right. The increase of latency in smaller than anything you can measure on real application. The multi-layer prefetcher does its job, as it did on Core 2 via the FSB.

The explanation is so simple that it is scary ... The memory prefetcher from L2 to L3 is working almost 100% because the pattern from L2 to L3 is filtered by the L2, I mean, the L2 remove most of the unpredictable pattern.

Ronak was and is right, the L2 cache of Nehalem does not cause any issue.

I actually like when the architects are right, and I am wrong, it mean that we will have a kick a// product.
And remember Andy's moto: "Only paranoid survive", it is my job to apply this to Intel's product

Now that is interesting. I wonder what you said about static CMOS..

[Drwho?]

Interesting post ,thanks.

Do you have any comments on OBR's post here,especially on power consumption in full load(supposedly a lot higher than on 45nm C2Q):

I will let the journalists make the demos at launch time ...
I believe OBR has a very early sample.

[npk]

I will let the journalists make the demos at launch time ...
I believe OBR has a very early sample.

and that would be.....?

[Anemone]

I'm not saying the L3 central isn't worthwhile and certainly to have a central pool and still have the individual cores fed properly you had to replicate to the L2. But seems to me there is no room left in the L2 to conduct a single core's chores (to keep the example simplified). You could have doubled or quadrupled the L2 with not a large hit on cost or really complexity since you've already designed the basic working format. Even then you'd still have room leftover in the L3 pool and each core would work faster, utilizing L2, and still have an excess of L3 to tap for the next tasks to assign to a core.

How I would have envisioned the layout:
1mb L2/Core
8mb of L3 shared

The cost reduction of the smaller L2 than in prior series would have covered the addition of the L3 and probably a mem controller of significant capability in the bargain.

Now I say this and I have to believe you gave this a shot. I honestly think you didn't draw up the current ratios without experimenting. So yes I'll wait for the tests, but it "feels" to me like Intel took the L2 down more for cost to benefit ratio than anything purely performance oriented. Meaning there was an advantage to the additional L2 (as surely there would be) but it was judged that the additional benefit didn't warrant the cost involved. I'm not baiting you to argue this, just explaing a "feeling" on this topic and any commentary you may feel is worthy is fine or none is fine too.

Given where the 9770 landed in cost, perhaps bringing things under control wasn't all bad. And perhaps what was sacrificed won't be all that noticeable. So I'll wait and see. But I do feel "some" additional L2 would have yielded a slightly better chip.

[Movieman]

Dr.Who?:
What would be your guess as to the difference in performance of a 8 core Harpertown machine at 3200 and a 8 core gainstown at 3200 doing work that can take advantage of the HP in the new Nehalem based systems?
I'm talking about Distributed Computing work as we do for WCG where each core is assigned a work unit.
That's really what this comes down to me, how much more work can be done in the same timeframe..
Thank you.

[Ace-a-Rue]

You could have doubled or quadrupled the L2 with not a large hit on cost or really complexity since you've already designed the basic working format.

i DOUBT that because the transistor count on the die would probably quadruple just on doubling the size of L2.

[Drwho?]

i DOUBT that because the transistor count on the die would probably quadruple just on doubling the size of L2.

you will see very little gain from increasing the size of the L2, its very short latency is a plus that you do not want lose.

[Drwho?]

Dr.Who?:
What would be your guess as to the difference in performance of a 8 core Harpertown machine at 3200 and a 8 core gainstown at 3200 doing work that can take advantage of the HP in the new Nehalem based systems?
I'm talking about Distributed Computing work as we do for WCG where each core is assigned a work unit.
That's really what this comes down to me, how much more work can be done in the same timeframe..
Thank you.

hehehe, I just can't answer this, I hope you understand ...

[Movieman]

hehehe, I just can't answer this, I hope you understand ...

That's honest and yes, I do understand..
My guess is a 30% increase based on what I've seen and thats enough to push me to do one and if they will do 4000 like these Harpertowns then they will be winners.
My other concern is heat.
As to whether with the onchip IMC they will produce a higher heat dump than the harpertowns.
Currently I am able to run a pair of harpertowns at 100% load at 3758 on air at 47C in a 72F room..
Can you comment on the heat factor or is that still under NDA also?
Thank you..



Looks around, sees Dr.Who? is gone......
Damn, ran the poor guy right off the forum again!

[qurious63ss]

[QUOTE=OBR;3264423]Yeah, my CPU has retail revision ... and mobo is last Rev. before Retail ... my platform become almost Retail ...[/QUOT

You might have an earlier rev. The process (45nm HK) has already matured on penryn and now is ready for nehalem (BTW that is the beauty of tic toc). The chip that you have may still have some bugs in the arch design level for power mgmt that still hadn't been worked out yet. As long as the problem exist in the design level and not the process level then a single stepping can fix the issue.

BTW, I can tell you that it's fixed, but I can't provide sources.

[OBR]

[QUOTE=qurious63ss;3266266]

Yeah, my CPU has retail revision ... and mobo is last Rev. before Retail ... my platform become almost Retail ...[/QUOT

You might have an earlier rev. The process (45nm HK) has already matured on penryn and now is ready for nehalem (BTW that is the beauty of tic toc). The chip that you have may still have some bugs in the arch design level for power mgmt that still hadn't been worked out yet. As long as the problem exist in the design level and not the process level then a single stepping can fix the issue.

BTW, I can tell you that it's fixed, but I can't provide sources.

yes it is possible, that was my EARLY suggestions of Nehalem ... we have to wait for retail mobos and CPU and will see ...

[Donnie27]

[QUOTE=OBR;3266453]

yes it is possible, that was my EARLY suggestions of Nehalem ... we have to wait for retail mobos and CPU and will see ...

Sure but you know some folks will jump on that and go negative for the sake of FUD to boost the other company's outlook. Kind of lame that they think this works.

[Mk]

guys are we even gonna see Core i7 in September?

[Donnie27]

guys are we even gonna see Core i7 in September?

Should see an announcement and maybe NDA's are lifted.

[GoldenTiger]

So what's the latest on when we can buy Core i7 CPU's (say the $300ish model)? I've been looking around but most of the news I'm finding is older. Is it possible we'd see it in Oct/Nov. for purchase?

[@@@@]

so if ES Rev. is already at C0 & C1

what would be the revision of the retail products?

[bowman]

So what's the latest on when we can buy Core i7 CPU's (say the $300ish model)? I've been looking around but most of the news I'm finding is older. Is it possible we'd see it in Oct/Nov. for purchase?

I wouldn't expect anything earlier than November at this point.

[Anemone]

you will see very little gain from increasing the size of the L2, its very short latency is a plus that you do not want lose.

Fair enough - and I'm sure an honest answer. You've said several times in several ways that much of any slowness of comparing Yorktown to Nehalem and finding Nehalem slower is more due to early silicon/boards vs L2 issues. So I'll take that at face value.

Painful to realize that we've still got a couple more months till this chip is out But that is the zen of XS I think

[Sumanji]

More benchies here