Sign in with
Sign up | Sign in
Your question

TheInq talks about Nehalem's performance

Last response: in CPUs
Share
October 16, 2007 5:58:42 PM

http://www.theinquirer.net/gb/inquirer/news/2007/10/16/idf-taipei-nehalem-real-big

Now, since TheInq is known for their news inaccuracy, so take this news with grains of salt.

Quote:

...If we compare the initial top Core 2 launch part, the 2.93GHz Conroe, vs 3.73GHz Presler, the last Netburst part in the same process, we're talking a speed increase between 30 per cent. And over 80 per cent right there and then, depending on what you run - I'm not counting some of those rare benchmarks where the difference was more than double....

...Just think the Harpertown benchmarks scaled to 3.6GHz, then multiplied by 1.3 to 1.8 depending on the case.


Nehalem, anyone? ;) 
October 16, 2007 7:14:44 PM

thanks mate for that. but yeah rite lol i hope thay are that gd :D 
October 16, 2007 7:37:35 PM

Wow, way to state the obvious inquirer.
A 5 year old could have made that guess, who knows one of the editors kids probably did. I wish people would quit reading rumour sites, then we could watch them die and never hear of them again.
James
Related resources
October 16, 2007 8:44:34 PM

...still waiting for constructive response... :??: 
October 16, 2007 9:31:23 PM

The reason its so fast is that the Nehalem architecture finally gets an integrated memory controller and does away completely with FSB. They're moving to a similar idea to AMD's hypertransport with a (much) higher-bandwidth bus called Intel QuickPath Interconnect.
The FSB has been a massive bottleneck for years, good riddance.
October 16, 2007 9:36:03 PM

It will be interesting to see what the desktop variants will do as I believe those will be initially released w/o an IMC and a "bottlenecked" FSB....
October 16, 2007 9:47:54 PM

boduke said:
It will be interesting to see what the desktop variants will do as I believe those will be initially released w/o an IMC and a "bottlenecked" FSB....


Very true. The desktop variants will not have an IMC, but still rely on FSB. Only the server and maybe high end enthusiast systems will be IMC.

Anyway, how many FSB bottlenecks have been seen recently with Core 2 Duo systems? I haven't had a problem with the FSB bottlenecking anything I have ran lately.
October 16, 2007 10:17:38 PM

Thus my use of " " around bottlenecked.... ;-)

I would venture a guess at saying that eventually the IMC will go across the line but probably not until late 2009, my one prediction for this particular processor line - and that will depend on how AMD can compete....
October 16, 2007 10:22:49 PM

boduke said:
Thus my use of " " around bottlenecked.... ;-)

I would venture a guess at saying that eventually the IMC will go across the line but probably not until late 2009, my one prediction for this particular processor line - and that will depend on how AMD can compete....


Sorry boduke, my FSB question was actually to niz, who brought up the old adage of FSB limited stuff.
October 16, 2007 10:25:56 PM

Yah, s'what I figured but wanted to point that out to others who might think I was agreeing with that line of thought....
October 16, 2007 10:26:12 PM

if that is true then goddamn!!!
October 16, 2007 10:35:24 PM

If the initial desktop part is released without an IMC is it possible the a Nehalem could drop into current mainboards? with some kind of BIOS update maybe?, obviously no idea on FSB's on these or memory support either.
If they cannot drop in, then Intel is adding another layer to the already complex mainboard/chipset compatibility. One for Desktop part (excluding highend), highend desktop and server. Then we will still have the older tech around too desktop and server (conroe and penryn). Making this very confusing for the average joe.
October 16, 2007 10:53:26 PM

chookman said:
If the initial desktop part is released without an IMC is it possible the a Nehalem could drop into current mainboards? with some kind of BIOS update maybe?, obviously no idea on FSB's on these or memory support either.
If they cannot drop in, then Intel is adding another layer to the already complex mainboard/chipset compatibility. One for Desktop part (excluding highend), highend desktop and server. Then we will still have the older tech around too desktop and server (conroe and penryn). Making this very confusing for the average joe.


I see your point with motherboard and CPU compatibility, but the average Joe won't care, since s/he will most likely buy a pre-built system, and not piece part a computer. But I read somewhere that there will be a socket change for Nehalem in mid-late 2008.
Quote:
Intel processors from the Nehalem generation that are scheduled to appear in H2 2008 will exist in two modifications: Socket H (LGA 715) and Socket B (LGA 1336). This difference in the number of pins is determined by Intel’s decision to offer two CPU modifications: with the integrated three-channel memory controller and without it.
X-bit Labs
I still take it with a grain of salt, since H2'08 is quite a bit away.

Also, since Nehalem based products won't be available until H2 '08, early '09, so by then, the Conroes might be replaced by Penryn, and then Nehalem will start to trickle in.
October 16, 2007 11:09:14 PM

Ok everyone here must be asleep as no one said anything about the AMD blunder.

Quote:
On a lighter note, a rumour circulated here that AMD mistakenly delivered 500 of its new CPU parts to one customer but forgot the charge. Intel wags promptly suggested it was the largest AMD delivery they heard of this year to date.


Thats about a 100,000~500,000$ screw up depending on which of their new CPU they forgot to charge.
October 16, 2007 11:26:18 PM

Quote:
So Intel finally figured out a integrated memory controller.....hmmm...


???

And...what is your point? IMC or FSB, both are nowhere near saturated, so what's the big deal about IMC for desktop? You get a better memory benchmark score? Yay?!? Exactly what desktop program/application will get a huge boost using an IMC over FSB? Please, tell us. Sure, it will help with server apps, but who cares about it for desktops? I can run multiple applications without any problems on my lowly FSB based motherboard system.

So, that means I can say "AMD finally figured out how to make a quad core on one package....hmmm..."
October 17, 2007 12:30:04 AM

Quote:
So Intel finally figured out a integrated memory controller.....hmmm...


Go research the 386/486 architecture and ask that question again...
October 17, 2007 12:33:35 AM

Quote:
So Intel finally figured out a integrated memory controller.....hmmm...


and AMD still hasn't figure out how to execute...
a c 447 à CPUs
October 17, 2007 2:34:52 AM

Well, I just hope Intel will release some preliminary benchmarks in Q1 2008. Then I'll decide to either upgrade to Penryn or wait for Nehalem.

Waiting for Nehalem will mean the Athlon XP-M 2600+ in my HTPC will be serving me for 5 years. It can still do it's job, but I would like to use it for more than just recording video and playing back both video and music files. DivX 6 encoding is painfully slow.
October 17, 2007 3:38:54 AM

@jaguarskx
What about the system in your sig? which might i add is comparable to mine...

@boduke
HEHE quick come back there Intel just like changing it up a bit hehe

@NMDante
Thanks for the info dude, i see what you mean about the pre-builds. But leaves us poor upgraders with bad options. New CPU means new Mobo in most cases (by what info we are given about them currently).

I still believe the only thing pushing the CPU/GPU market in desktop is the games that people are releasing. I cant see anyone needing that type of RAW power in CPU for anything but latest release games, and even then you GPU has to be top notch to force the CPU to potential.
a c 447 à CPUs
October 17, 2007 3:58:21 AM

chookman said:
@jaguarskx
What about the system in your sig? which might i add is comparable to mine...



That's my primary rig. I literally want to take all the innards and place them in a new HTPC case (got one already picked out), then buy a new mobo and either the Penryn or Nehalem.

That way I can offload some encoding from my primary rig to the HTPC which is connected to the TV.
October 17, 2007 5:30:36 AM

Quote:
X-bit Labs
I still take it with a grain of salt, since H2'08 is quite a bit away.


Without divulging specific information about Nehalem and possibly getting into trouble at work, I will say you should take the Xbit article with a huge chunk of rock salt. As they got their own info from the Inquirer, this is not shocking.


October 17, 2007 11:17:28 AM

Re that Inquirer article... what was the author smoking?
October 17, 2007 11:54:22 AM

*Yawn*

Intel still can't pass on architectural advances to its consumers. Instead they flood the market with radically reworked Pentium-M core CPUs with archaic front side bus technology. Intel has the capacity and yields - sure, but not the drive to deliver innovation when needed.


October 17, 2007 1:51:10 PM

bitrate said:
*Yawn*

Intel still can't pass on architectural advances to its consumers. Instead they flood the market with radically reworked Pentium-M core CPUs with archaic front side bus technology. Intel has the capacity and yields - sure, but not the drive to deliver innovation when needed.


From what I know, Intel passed down a lot of technology to the consumers. This is why we go out and buy their products, and they use our money to develop new technology.

As for Penium M reworked CPU, Core 2 is indeed based on Pentium M. Its like saying Barcelona is a radically reworked K8 core (and less radical than Pentium M => Core 2). We haven't saturated the Front Side Bus at all, so using a faster interconnect doesn't help.

Intel actually delivers a lot of innovation in the past 2 years (Core uarch), and will continue to do so in the future (HK/MG, Nehalem)

October 17, 2007 2:31:31 PM

Quote:
So Intel finally figured out a integrated memory controller.....hmmm...

Intel did over a decade ago, but AMD has not :hello: 
October 18, 2007 1:48:59 AM

Mugz said:
Re that Inquirer article... what was the author smoking?



What the..... :pt1cable:  :ouch: 
BACK DOWN IN THE OTHER.......... :non: 

The inmates arent alowed outside of the asylum :pfff: 


;) 
a b à CPUs
October 18, 2007 2:04:48 PM

Intels superior rework on the Pentium M through to today with the Conroe etc. That's a massive oversimplification ... lol ... but reasonable.

Luckily they got those Israelli engineers in ... bless em ... to bury that netburst POS (and move forward!!

I still have a P3 933 server here handling the front end ... ol reliable.

I do hope their IMC project bears fruit.

I also hope AMD survive ... to keep them on their toes.

Remember this old article ... it really shocked many when it came out.

http://www.tomshardware.com/2005/05/25/dothan_over_netb...

October 18, 2007 4:26:25 PM

Reynod said:

I also hope AMD survive ... to keep them on their toes.


Personally I don't care about AMD surviving to keep them on their toes, any more than I do Intel surviving to keep AMD on their toes. I do care about healthy competition - if AMD would happen to go under (doubtful considering even under Chapter 11 they'd still continue to function) we'd be back to the day's of paying $400 for a midrange proc. No thanks.

The inverse is also true, because if anyone thinks that AMD wouldn't jack up prices if Intel bit it (even more doubtful) they're even more naive than Sharikook.
October 19, 2007 4:33:35 PM

To all those that doubt FSB is a bottleneck...
Try individually overclocking and behncmarking various parts of your system and you'll find that raising the FSB clock rate alone will give you the best performance gain.
If the FSB wasn't a bottleneck that wouldn't be the case.
October 19, 2007 4:50:42 PM

niz said:
To all those that doubt FSB is a bottleneck...
Try individually overclocking and behncmarking various parts of your system and you'll find that raising the FSB clock rate alone will give you the best performance gain.
If the FSB wasn't a bottleneck that wouldn't be the case.

Sure

From Anandtech:
http://anandtech.com/cpuchipsets/showdoc.aspx?i=3012&p=...


Oops... guess the difference is not that great huh...


Again, the difference is minimal


0.15 secs faster.. wow that's a big improvement


I'm definitely, positively sure that FSB is a bottleneck

Let's try some games, shall we?


Oblivion is probably the only game that show moderate improvement by going from 1066Mhz to 1333Mhz. Since AMD also shines in this test, I assume this game is RAM intensive.


Again, 1FPS improvement.


I guess graph speaks louder than words




Conclusion:
The FSB is not bottlenecked, in almost all cases. Unless of course, you're talking about multiple socket servers, then yes, FSB is bottlenecked, and this is why AMD has always been the leader in that arena.
a c 96 à CPUs
October 20, 2007 2:54:51 AM

yomamafor1 said:
http://www.theinquirer.net/gb/inquirer/news/2007/10/16/idf-taipei-nehalem-real-big

Now, since TheInq is known for their news inaccuracy, so take this news with grains of salt.

Quote:

...If we compare the initial top Core 2 launch part, the 2.93GHz Conroe, vs 3.73GHz Presler, the last Netburst part in the same process, we're talking a speed increase between 30 per cent. And over 80 per cent right there and then, depending on what you run - I'm not counting some of those rare benchmarks where the difference was more than double....

...Just think the Harpertown benchmarks scaled to 3.6GHz, then multiplied by 1.3 to 1.8 depending on the case.


Nehalem, anyone? ;) 


I don't doubt their claims that Nehalem might be as fast compared to Core as Core was to NetBurst...if they're talking about 4S-8S units. The chipset/shared FSB arrangement is the Achilles heel in such systems, so the same K8 core that is significantly slower than a Core clock-for-clock in a 1S configuration turns the tables and then some when comparing 4S and 8S units. That is why the Xeon MP (4S, 8S, even more with IBM chipsets) were still using NetBurst over a year after mobile and desktop CPUs switched over to the Core CPUs- they would underperform AMD's offerings by a large amount no matter what they had sitting in the sockets.

Also, I'm betting that there will be a "best-case scenario" type of test run. You can prove the 45 nm Core 2s are twice as fast clock-for-clock as the 65 nm ones if you run SSE4 benchmarks (as was done in some of the initial Wolfdale/Yorkfield demos.) 30% is a lot of gain at once and 80% is pretty much unreal, unless you went from a clock-speed-at-all-costs arch like NetBurst to something that's much, much higher in IPC. I'm taking this story with a really big pile of sodium chloride...
a b à CPUs
October 20, 2007 3:45:20 AM

The inquirer talks alot, but never says anything.
a b à CPUs
October 20, 2007 11:42:22 AM

The FSB for Intel isn't an issue at present because of the vastly superior prefetching and overall cache speed and size.

Only in tasks where the cache is exceeded and the cpu needs to regularly access main memory is this a cause for consideration / penalty.

So your benchies above where FSB is increased (while keeping the same overall frequency) doesn't show much improvement because the tasks running aren't thrashing the cache.

I'd like a bit of clarification from someone who knows a lot more about this please?

I could be wrong ... if so please lead me back on the path.

October 22, 2007 4:28:40 PM

yomamafor1:
You aren't proving anything.
Your benchmarks are comparing different processors at different CPU core clocks. Thats unrelated to the FSB which is clocked independently of the core (it is usually obtained by dividing the core clock, but the divider itself can and usually does have different values between different cpus so the fsb clock works out right regardless of the CPU clock).

October 22, 2007 4:50:37 PM

niz said:
yomamafor1:
You aren't proving anything.
Your benchmarks are comparing different processors at different CPU core clocks. Thats unrelated to the FSB which is clocked independently of the core (it is usually obtained by dividing the core clock, but the divider itself can and usually does have different values between different cpus so the fsb clock works out right regardless of the CPU clock).


...different processor at different CPU core clocks?

Actually, FSB IS clock dependently to the core. You obtain FSB number by multiply CPU core clock by 4x. And no, the divider does not have different value between different CPUs. For example, the earlier Core 2 Duo have FSB of 1066Mhz, where the newer one has 1333Mhz. I've just shown that the increase in performance is minimal.
October 22, 2007 5:38:29 PM

>> You obtain FSB number by multiply CPU core clock by 4x.

Wrong. the FSB is usually divided by 9, 10 or 11 from the CPU clock.
The X4 thing you're talking about is because the FSB is quad-pumped, i.e. transfers occur on both the leading and trailing edge of a clock edge. Thats why you multiply by 4.


>> And no, the divider does not have different value between different CPUs.

Wrong again. how do you think a 2.13, 2.4, 2.66 and a 2.93 Ghz CPU can all provide a 1066 fsb?

No,
October 22, 2007 5:47:11 PM

yom,

I don't think dual core is the issue, but I don't doubt a lower FSB on the quads would bottleneck the system.

As far as this article.... um.... it didn't really say anything. I am not calling you guys fanboys but if this was an AMD article I think you guys might have reacted a little bit differently. Just a thought.
October 22, 2007 7:47:00 PM

niz said:
>> You obtain FSB number by multiply CPU core clock by 4x.

Wrong. the FSB is usually divided by 9, 10 or 11 from the CPU clock.
The X4 thing you're talking about is because the FSB is quad-pumped, i.e. transfers occur on both the leading and trailing edge of a clock edge. Thats why you multiply by 4.]

No. You're confused core clock with FSB. Core clock is not CPU clock. It is the base frequency a processor communicate with other components on the motherboard. Go download CPU-Z, and see what it says. Go to your own BIOS section, and see what it says.

Core clock x 4 = FSB.
Core clock x multiplier = CPU clock.


>> And no, the divider does not have different value between different CPUs.

Wrong again. how do you think a 2.13, 2.4, 2.66 and a 2.93 Ghz CPU can all provide a 1066 fsb?

No, said:

>> And no, the divider does not have different value between different CPUs.

Wrong again. how do you think a 2.13, 2.4, 2.66 and a 2.93 Ghz CPU can all provide a 1066 fsb?

No,

With all due respect, I heavily suspect that... you have no idea what you're talking about.

This is Core 2 Duo's lineup, from E6320 to X6800.
E6320 = 266 x 7 = 1.83Ghz
E6420 = 266 x 8 = 2.13Ghz
E6600 = 266 x 9 = 2.4Ghz
E6700 = 266 x 10 = 2.66Ghz
X6800 = 266 x 11 = 2.93Ghz.

Now, the newer Core 2 Duo features FSB 1333Mhz, so you divide 1333 with 4, and obtain 333 core clock.

Therefore:

E6550 = 333 x 7 = 2.33Ghz
E6750 = 333 x 8 = 2.66Ghz
E6850 = 333 x 9 = 3.0Ghz

The CPU core clock does not change, but the multiplier changes.
October 22, 2007 7:55:52 PM

weskurtz81 said:
yom,

I don't think dual core is the issue, but I don't doubt a lower FSB on the quads would bottleneck the system.

As far as this article.... um.... it didn't really say anything. I am not calling you guys fanboys but if this was an AMD article I think you guys might have reacted a little bit differently. Just a thought.


The core count does not directly contribute to FSB bottleneck, but it does have an effect on it. Programs on the other hand, contributes the most to the FSB bottleneck. If programs need to access the RAM frequently, FSB will likely to become a bottleneck, as it is only uni-directional. As a result, AMD co-developed HyperTransport to alleviate this problem by increasing the bandwidth. Even with massive cache, Core 2 usually have a difficult time keeping up with K8 in scientific programs (they frequently access the RAM).

On the other hand, on desktop, the FSB does not appear to be saturated at all. The desktop programs are usually smaller than server programs, and they do not access RAM that frequently. Hence I posted the article from Anandtech, showing that for desktop application, FSB not only is not saturated, it is sufficient for the users.
a c 96 à CPUs
October 23, 2007 2:30:59 AM

yomamafor1 said:
If programs need to access the RAM frequently, FSB will likely to become a bottleneck, as it is only uni-directional. As a result, AMD co-developed HyperTransport to alleviate this problem by increasing the bandwidth. Even with massive cache, Core 2 usually have a difficult time keeping up with K8 in scientific programs (they frequently access the RAM).


That is certainly true on servers, but not on desktops. The HT link on a single-socket desktop system is between the CPU and the southbridge as the DMI link is between the NB and SB on an Intel system. The RAM on a K8 desktop system is wired directly to the socket and HT has nothing to do with it.

The reason that the Core 2 has trouble keeping up with the K8s in some scientific programs are that some scientific programs use x87 FP instructions heavily. AMD's K7 and K8 architectures have three fully-pipelined FPUs while the Core 2 has two fully-pipelined and one basic FPU. But if you get a scientific program that uses SSE2, then the Core 2s pull way ahead. It's not memory, it's all about what kinds of instructions the chips are the strongest in. The C2Ds are strong in integer and SSE, the K8s are strong in non-SSE FPU.

Quote:
On the other hand, on desktop, the FSB does not appear to be saturated at all. The desktop programs are usually smaller than server programs, and they do not access RAM that frequently. Hence I posted the article from Anandtech, showing that for desktop application, FSB not only is not saturated, it is sufficient for the users.


You have part of it. The Intel desktop (and notebook) chips' FSBs aren't saturated in just about any case. You could make a case for the Core 2 Quads showing a little bit of FSB congestion in specFP_rate, but that's a benchmark and not a real user program. The real reason the FSB is a big issue in servers is that programs are largely multithreaded and there are multiple sockets and the FSB has to do more than just carry data from memory as it has to carry die-to-die snoops and cache data transfers. The FSB setup seems to be able to handle two dies relatively well, as evidenced by the scaling of the Core 2 Duo -> Core 2 Quad and a single Xeon 5100 -> dual Xeon 5100s. The NB and FSBs start to take a real beating when there are two quads (four dies) to keep straight. The Opterons scale much better with their individual RAM banks and IMCs as well as fast HT links for socket-socket memory transfer.
October 23, 2007 3:45:46 AM

Good game this weekend. I am glad you guys beat Tech.
October 29, 2007 4:45:25 PM

yomamafor1 said:
No. You're confused core clock with FSB. Core clock is not CPU clock. It is the base frequency a processor communicate with other components on the motherboard. Go download CPU-Z, and see what it says. Go to your own BIOS section, and see what it says.

Core clock x 4 = FSB.
Core clock x multiplier = CPU clock.


With all due respect, I heavily suspect that... you have no idea what you're talking about.

This is Core 2 Duo's lineup, from E6320 to X6800.
E6320 = 266 x 7 = 1.83Ghz
E6420 = 266 x 8 = 2.13Ghz
E6600 = 266 x 9 = 2.4Ghz
E6700 = 266 x 10 = 2.66Ghz
X6800 = 266 x 11 = 2.93Ghz.

Now, the newer Core 2 Duo features FSB 1333Mhz, so you divide 1333 with 4, and obtain 333 core clock.

Therefore:

E6550 = 333 x 7 = 2.33Ghz
E6750 = 333 x 8 = 2.66Ghz
E6850 = 333 x 9 = 3.0Ghz

The CPU core clock does not change, but the multiplier changes.


Actually, With all due respect, I heavily suspect that... you are actually the one who has no idea what you're talking about.

So I say the multiplier is different for different CPU's, you say I'm wrong, then list them all with different multipliers. Thats funny.

Also, you're wrong about the definition of Core clock and FSB clock. The Core clock IS the CPU clock. Its the FSB clock (not the core clock) that is used to determine the speed the CPU talks to other components, such as memory.

See... FSB stands for Front Side BUS. A bus is a shared interface that devices talk with each other over. CPU's have things called cores. Its even clear just from the names which clock determines what.



October 29, 2007 5:45:34 PM

niz said:
Actually, With all due respect, I heavily suspect that... you are actually the one who has no idea what you're talking about.

So I say the multiplier is different for different CPU's, you say I'm wrong, then list them all with different multipliers. Thats funny.

Also, you're wrong about the definition of Core clock and FSB clock. The Core clock IS the CPU clock. Its the FSB clock (not the core clock) that is used to determine the speed the CPU talks to other components, such as memory.

See... FSB stands for Front Side BUS. A bus is a shared interface that devices talk with each other over. CPU's have things called cores. Its even clear just from the names which clock determines what.


I stand corrected on the terminologies, thanks for the correction.

In regards to your multiplier statement, I think you're a little confused.
Quote:
Wrong again. how do you think a 2.13, 2.4, 2.66 and a 2.93 Ghz CPU can all provide a 1066 fsb?


They all provide FSB 1066 because they all have the same bus speed, 266Mhz. Then 2.13, 2.4, 2.66 are obtained by the multipliers.
October 31, 2007 3:42:02 AM

Quote:

You have part of it. The Intel desktop (and notebook) chips' FSBs aren't saturated in just about any case. You could make a case for the Core 2 Quads showing a little bit of FSB congestion in specFP_rate, but that's a benchmark and not a real user program.


Actually, it might be much more than expected performance gain by moving to integrated memory controller. The thing that faster FSB brings is more memory bandwidth, but doesn't do too much in terms of memory latency. This is how AthlonXP wasn't too bottlenecked by memory bandwidth but gained 20% performance by going to integrated memory controller alone.

Integrated memory controller on a Core 2 based CPU may not gain much as AthlonXP because it also has very good latency, but we still can't say the gain will be nil, because IMC will bring substantial memory latency reduction. You can see that the 20% advantage of IMC on Athlon64 was against AthlonXP using the best chipset, the Nforce 2. And AMD back when they made chipsets weren't known for high performing chipsets. For Nehalem, this is Intel integrating their own memory controller on the CPU.

Looking here:
http://www.anandtech.com/showdoc.aspx?i=1884&p=10

AthlonXP: 144.22
Athlon64: 61.54(2.35x)

Pentium 4 3.2C: 72.48(70.86 from this link: http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx...)
Core 2 Duo: 36.75
Nehalem: 14.5??
Who can really say that Intel won't be able to bring 2.35x latency reduction over the already impressive latency on the Core 2 Duo??

A pure 10-15% gain over Core 2 by using IMC is possible imo. That won't be the only thing Nehalem will bring though. Along with the IMC, SMT, they'll also up the performance of the FP/SSE units and possibly also have a core modification. Core 2 brought 30% over Dothan. Nehalem might be able to bring 30% over Conroe.

For servers IMC and Quickpath brings even more advantage. Now Intel will be able to have fast communication between multiple CPUs and it'll have memory controller for each CPU.
April 5, 2008 6:46:55 PM

i have a question, if Nehalem has no FSB how do you overclock it?
April 5, 2008 9:11:53 PM

Quote:
i have a question, if Nehalem has no FSB how do you overclock it?


The same way you overclock an AMD processor.
April 5, 2008 9:55:48 PM

MU_Engineer said:
But if you get a scientific program that uses SSE2, then the Core 2s pull way ahead.


If your statement is correct... then why does Intel feel the need to disable CPU SSE optimizations for anything that is not "Genuine Intel" even if the chip in question can handle the optimizations?

In other words Intel's compiler does this:

(Query the CPU)
"Can you handle SSE2?"
"Are your genuine Intel?"

If both answers are YES then Optimizations are turned on.

If either answer is "NO" then optimization are disabled. Even if the chip can correctly run the SSE2 optimizations.


See more at: http://aceshardware.freeforums.org/cpuid-family-bits-added-because-of-flaw-in-intel-compiler-t428.html

OR

http://www.swallowtail.org/naughty-intel.html

Apparently if you disable the "Are you Genuine Intel" query then programs will run faster on AMD processors.

It seems nobody is debating whether or not this happening. They debate whether it is ethical or not. By that I mean that we can all accept that a company will (should) optimize specifically for their product's unique abilities and strengths. However in this case Intel is not doing that; they are purposefully giving the competition a handicap.

So then I have to ask: Are they doing this because if they don't then their product won't be able to compete?

But whether or not it is "ethical" or "acceptable" is moot... the question remains: Is your statement always correct or is it only correct if the benchmark was compiled using Intel's optimizing compiler.
April 5, 2008 9:57:35 PM

chookman said:

I still believe the only thing pushing the CPU/GPU market in desktop is the games that people are releasing. I cant see anyone needing that type of RAW power in CPU for anything but latest release games, and even then you GPU has to be top notch to force the CPU to potential.



I would have to disagree with that My machine is fast... hanvit played a game in years...
there is a lot more to desktop PC's then gaming...
I imagine that there are more desktop PC's in offices then there are in peoples homes.. (I may loose)
April 5, 2008 10:04:42 PM

yomamafor1 said:
Sure

From Anandtech:
http://anandtech.com/cpuchipsets/showdoc.aspx?i=3012&p=...

http://images.anandtech.com/graphs/intel%20core%202%20duo%20e6750_062507120647/14895.png
Oops... guess the difference is not that great huh...

http://images.anandtech.com/graphs/intel%20core%202%20duo%20e6750_062507120647/14900.png
Again, the difference is minimal

http://images.anandtech.com/graphs/intel%20core%202%20duo%20e6750_062507120647/14901.png
0.15 secs faster.. wow that's a big improvement

http://images.anandtech.com/graphs/intel%20core%202%20duo%20e6750_062507120647/14902.png
I'm definitely, positively sure that FSB is a bottleneck

Let's try some games, shall we?

http://images.anandtech.com/graphs/intel%20core%202%20duo%20e6750_062507120647/14913.png
Oblivion is probably the only game that show moderate improvement by going from 1066Mhz to 1333Mhz. Since AMD also shines in this test, I assume this game is RAM intensive.

http://images.anandtech.com/graphs/intel%20core%202%20duo%20e6750_062507120647/14916.png
Again, 1FPS improvement.

http://images.anandtech.com/graphs/intel%20core%202%20duo%20e6750_062507120647/14918.png
I guess graph speaks louder than words

http://images.anandtech.com/graphs/intel%20core%202%20duo%20e6750_062507120647/14919.png


Conclusion:
The FSB is not bottlenecked, in almost all cases. Unless of course, you're talking about multiple socket servers, then yes, FSB is bottlenecked, and this is why AMD has always been the leader in that arena.


Before you go rubbing it in a little bit more, consider that a bottleneck might show up regarding quad core cpus. Find a similar set of charts using say a q6600 versus the qx6700, with the former oc'd to the same clock speed as the later, then if your right again, hell, your truly right.
April 5, 2008 10:21:20 PM

spoonboy said:
Before you go rubbing it in a little bit more, consider that a bottleneck might show up regarding quad core cpus. Find a similar set of charts using say a q6600 versus the qx6700, with the former oc'd to the same clock speed as the later, then if your right again, hell, your truly right.



Better yet...
just take a single Q6600 and run it stock 2.4 ghz 9x266
then compare it to 2.4Ghz 8x300
then compare it to 2.4Ghz 7x343
then compare it to 2.4Ghz 6x400.

and the only thing changing is the FSB. your other graphs were comparing different CPU's, Apples to Oranges.
any other comparison would be useless.
!