Nehalem

Page 3 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

dmens

Platinum Member
Mar 18, 2005
2,275
965
136
Dothan has fewer pipeline stages than c2d yet c2ds has better IPC.

Amd has fewer pipeline stages than c2D yet C2D has better IPC.

Please Explain why what your saying isn't proving to be true in the real world.

dont forget that ipc is an entirely useless metric without achievable frequency.

as for nehalem pipestages, im pretty sure that is confidential at this point in time.
 

CTho9305

Elite Member
Jul 26, 2000
9,214
1
81
Originally posted by: Nemesis 1
Thank for your speedy respose. You said it pretty dam good. So if intel makes improvements on Nehalem in the areas you pointed over Nehalem . In theory Intel could lengthen the stages to achieve higher freq. and still have = Ipc to penrtn at the same clock speed is this correct?

Sort of. It becomes pretty hard to maintain IPC as you lengthen the pipeline beyond a certain point, though.

For one thing, you throw away more work with each mispredicted branch instruction.

At reasonable pipeline lengths, you can always figure out which instructions are ready to issue on a certain cycle. After a certain point (assuming you're increasing the pipeline length by making each stage shorter, rather than doing more total work somehow), however, you run into a problem: you won't know for sure whether certain operations will have completed by cycle n early enough reliably to schedule instructions that depend on it (probably cycle n-1 or n-2) (the common example would be a memory access: it takes some time before you know whether you hit in the L1 cache or not. If the access hits, a dependent instruction can be issued, say, 3 cycles later. If you miss, you can't issue the dependent instruction until you get data back at some point in the future). You get into a situation like P4, where you have to speculatively issue the dependent instructions, and then replay them if you guessed wrong. If replaying happens a lot, you waste a lot of power and lose a lot of performance.

There are also circuit/electrical disadvantages to short stages like P4 (especially insane implementations like the cancelled Tejas). You're most likely going to have to increase the number of flip-flops on the chip, which increases load on the clock, which increases power (it's sort of a double-whammy: power goes up because you're increasing frequency, and power goes up because you're increasing capacitance). You also waste more time on synchronization overhead... that's probably too complicated to explain in this thread though.

So, I won't say it's impossible to maintain/improve IPC while significantly lengthening the pipeline, but it would take some good innovation.

This paper by two Intel architects argued for really deep pipelines (many short stages), but I doubt anyone takes it seriously.
 

Nemesis 1

Lifer
Dec 30, 2006
11,366
2
0
Ya thats been on my mind a bit. I am fairly certain by the time the Israel plant starts puting out Nehalems that Intel will have improved the new process even further.

So is what I was hoping for and I don't beieve this is a stretch. Nehelem top end qcore processor comes out @ 4ghz. Looking @ Penryn it looks like intel can pull it off.

That would be a good performance increase. in IpC +freq. = 40-50% performance increase
 

Nemesis 1

Lifer
Dec 30, 2006
11,366
2
0
Demens I understand you can't talk about the stages. Than could you explain to me what intel means when they say this about Nehalem .

Multi- leveled shared cache. I understand that the server part will have24MB L3 shared cache . But what about the other nehalems? Do they also have multi-leveled shared cache even if they don't have L3 cache.

If they do . Does that mean intel has found away to use L1 shared cache?
 

dmens

Platinum Member
Mar 18, 2005
2,275
965
136
Originally posted by: CTho9305
Sort of. It becomes pretty hard to maintain IPC as you lengthen the pipeline beyond a certain point, though.

For one thing, you throw away more work with each mispredicted branch instruction.

At reasonable pipeline lengths, you can always figure out which instructions are ready to issue on a certain cycle. After a certain point (assuming you're increasing the pipeline length by making each stage shorter, rather than doing more total work somehow), however, you run into a problem: you won't know for sure whether certain operations will have completed by cycle n early enough reliably to schedule instructions that depend on it (probably cycle n-1 or n-2) (the common example would be a memory access: it takes some time before you know whether you hit in the L1 cache or not. If the access hits, a dependent instruction can be issued, say, 3 cycles later. If you miss, you can't issue the dependent instruction until you get data back at some point in the future). You get into a situation like P4, where you have to speculatively issue the dependent instructions, and then replay them if you guessed wrong. If replaying happens a lot, you waste a lot of power and lose a lot of performance.

it seems like you are referring to bottlenecks. yes highly aggressive pipelining takes a bigger hit on IPC due to bottlenecks. and in general it is true that increasingly aggressive pipelines will aggravate the apparent latency of bottleneck resolution. that is where two tweaks come into play, buffer depth and high ROI speculation. buffer depth alleviate bottlenecks at the cost of power and potential cost of frequency, and speculation is to reduce the average latency. P4 replay is a good example of arbitrary speculation. there are innumerable examples of high ROI speculation, such as branch prediction and L1 go-ahead.

imho the real headache of maintaining width while pipelining is dividing up the work into chunks that can be pipelined. if that is not possible, then width is sacrificed. increasing processing width has a brutal effect on logic length.

There are also circuit/electrical disadvantages to short stages like P4 (especially insane implementations like the cancelled Tejas). You're most likely going to have to increase the number of flip-flops on the chip, which increases load on the clock, which increases power (it's sort of a double-whammy: power goes up because you're increasing frequency, and power goes up because you're increasing capacitance). You also waste more time on synchronization overhead... that's probably too complicated to explain in this thread though.

all true. another issue with more aggressive pipelining is complication of protocols and validation effort, i think what you mean by synchronization is part of that.

but consider the fact that if (big if) an aggressive pipeline is achieved resulting in a high throughput machine, one can always downclock and downvolt to reach the desired thermal envelope. i guess my opinion is that aggressive pipelining opens up options and broadens a design's performance range.
 

dmens

Platinum Member
Mar 18, 2005
2,275
965
136
Originally posted by: Nemesis 1
Demens I understand you can't talk about the stages. Than could you explain to me what intel means when they say this about Nehalem .

Multi- leveled shared cache. I understand that the server part will have24MB L3 shared cache . But what about the other nehalems? Do they also have multi-leveled shared cache even if they don't have L3 cache.

If they do . Does that mean intel has found away to use L1 shared cache?

plz don't ask what you know is confidential.
 

BrownTown

Diamond Member
Dec 1, 2005
5,314
1
0
Originally posted by: Nemesis 1
Why is this confidentcal? I got the multi-shared cache thin from IDF papers

All you need is in the HKEPC article, just look at the slides and most all of your questions will be answered (just not the pipeline depth one).

As for this whole discussion:

Originally posted by: dmens
more pipeline stages makes a CPU have a LOWER IPC

not at all, the two metrics are not related.

the number of stages in the pipeline is a trade off between clockspeed (high number of pipeline stages) and lower power, and high IPC (less pipeline stages)

not really since again highly pipelined designs does not equate to lower processing width. that is highly dependent on the design.

Sure it is *possible* to make a CPU with higher IPC, clockspeed and everything else, but in the real world not so much. As we are all aware when you go to design a chip there is a limited transistor budget which must be accommodated, over time this budget has risen considerably, so yeah the Core2 can have a longer pipeline and better IPC than the P3, but in terms of going out and designing a new chip on a preset transistor budget it is silly to imply that IPC and the number of pipeline stages are unrelated because the ARE very much related. The same is true for the width of the processor, in real life the comparison isn't going to be between a deeply pipelined CPU with 10 execution units verse a moderately pipelined CPU with 5 execution units, that decision is a no brainier, but the one CPU would need WAY more transistors and likely wouldn't fit into your transistor budget. The reason why the Core2 can destroy the P3 is that is has a deeper pipeline, more execution units, more control logic (branch prediction, macro/micro ops fusion and a dozen other things), more cache etc.. Of course it also has 10 times as many transistors, so really there is no fair comparison.
 

Nemesis 1

Lifer
Dec 30, 2006
11,366
2
0
Nehalem details spill through the Tubes
Author: Richard Swinburne
Published: 3rd December 2007

Unconfirmed Nehalem die image, courtesy of PC Watch Impress, Japan.
More Nehalem news has made its way onto the net recently, via Japanese site PC Watch Impress (translator required). Even if you can't read the Kanji, there are lots of pictures in the link above, which I highly recommend nosing over, showing how things are likely to work inside Nehalem.

The general jist of things is as follows:
Nehalem-EX, codenamed Beckton, will have eight cores but supports 16 threads because HyperThreading makes a return. Each pair of cores will have an amount of shared cache between them, then there will be a mahoosive 24MB of shared cache between them all - basically a Stoakley platform on single chip.

The EX is designed for a multi-processor environment so this has QPI, or Quick Path Interconnect--Intel's alternative to HyperTransport--with four links at 4.8 or 6.4Gbps and an FB-DIMM2 quad-channel memory controller. All this is under the envelope of varying TDPs of 90W, 105W and 130W and the chips use a new LGA socket with 1567 pins, Socket-LS.


Quad-core, dual-socket (DP) Nehalem-EP, codenamed Gainestown will also have HyperThreading and 8MB of cache, triple channel DDR3 and two QPI links bundled in either 60, 80 or 130W TDP. It'll also have a new LGA socket, but this time with 1366 pins.


The quad-core, "extreme" performance CPU codenamed Bloomfield, will be identical to the DP parts above, but will be single socket only and have a single QPI link. This will also be on socket LGA1366. It is suggested to have a 270mm² die size, about the same as current Kentsfield?s 65nm 286mm² die, but it?ll have nearly 150m more transistors at 731m.


Quad-core, performance mainstream CPUs codenamed Lynnfield and Clarkfield, will have a lower clock and lower TDPs of 90W for desktop and 45/55W for mobile. A more normal dual-channel DDR3 is included here with the integrated memory controller, but instead of a QPI link it will include a PCI-Express 2.0 x16 slot and DMI link to a southbridge instead. It'll have a different socket, again - this time it's called LGA1160.


Dual-core chips will still be around next year, with new cores codenamed Havendale and Auburndale - these have HyperThreading, come with 4MB of shared cache and in addition to the integrated memory controller they have a graphics core that's talked to via an internal QPI. The memory controller is dual-channel DDR3, with a TDP of 35-45W for mobile and under 95W for desktop. Additionally, it will have a PCI-Express 2.0 x16 graphics lane included. Like above, it features an LGA1160 socket.

Remember, all this is stemming from the single CPU socket! AMD processors have had an integrated memory controller since the Athlon 64 launched, but not until Fusion arrives in 2009 now that we'll see a similar CPU from the green team.

These CPUs will be predominantly mobile or mainstream parts that require integrated graphics and not as much processing power.
Obviously integrating a single PCI-Express x16 lane into the north bridge limits the multi-GPU usage, but it also makes the interface with graphics card, CPU and memory a lot faster being on all one package. In comparison, the more enthusiast-orientated parts will have a separate chipset that handles all the PCI-Express stuff and will require a graphics card to negotiate an extra stop before getting main memory access - a criticism of AMD's current CPUs.

Unfortunately the CPU sockets have been split in two between more mainstream and enthusiast parts - my guess will be that Intel is creating a very niche segment with very few, but expensive CPUs in it. As Intel's flagship product, these parts will require you to buy three DDR3 DIMMs for tri-channel memory, and while we'd assume this to normally be just a bit of a marketing gimmick - remember that SLI or CrossFire will likely only be available on these CPUs as Bloomfield has a QPI to a separate north bridge, unless someone hacks multi-GPU into a "south bridge/MCP" to work with Lynnfield/Clarksfield, but then you're limiting traffic to the bandwidth of the DMI.

The CPU-GPU Havendale and Auburndale processors should feature in many notebooks and your low profile inexpensive PCs. Having a motherboard only need a simple south bridge with everything else on CPU should make things cheaper, but might also have a more restricted upgrade path. In addition, even though Intel has stated it is committed to making integrated graphics far better than it has been, because of the limitation in space and heat output from a single space, that might cause a significant restriction on what it can achieve.

We expect some serious performance out of these CPUs given the current climate, although we are slightly sceptical about the increase in pipeline length Nehalem will have, even if it is just in the low twenties. There's nothing to say that in just a year we'll suddenly all require a whole load more multi-threading capabilities either.

The Japanese website suggests that Bloomfield will be the first Nehalem available in Q4 2008, with the rest possibly arriving in 2009.

Personally, after writing this I'm actually quite concerned about Intel's positioning - I'm worried that now Intel is the current preferred product over AMD, it'll use this leverage to try and suck out as much cash from enthusiasts as possible, and not have them overclock lower parts, like the E6300, Q6600 etc, to perform like £700 CPUs. At the same time, it's also potentially limiting the availability of multi-GPU by its competitors by forcing the separate north bridge, which offers better performance, to potentially only be available onto Bloomfield CPUs. It seems all the cards are in Intel's hands to deal precisely how it wishes.
 

dmens

Platinum Member
Mar 18, 2005
2,275
965
136
Originally posted by: BrownTown
Sure it is *possible* to make a CPU with higher IPC, clockspeed and everything else, but in the real world not so much. As we are all aware when you go to design a chip there is a limited transistor budget which must be accommodated, over time this budget has risen considerably, so yeah the Core2 can have a longer pipeline and better IPC than the P3, but in terms of going out and designing a new chip on a preset transistor budget it is silly to imply that IPC and the number of pipeline stages are unrelated because the ARE very much related. The same is true for the width of the processor, in real life the comparison isn't going to be between a deeply pipelined CPU with 10 execution units verse a moderately pipelined CPU with 5 execution units, that decision is a no brainier, but the one CPU would need WAY more transistors and likely wouldn't fit into your transistor budget. The reason why the Core2 can destroy the P3 is that is has a deeper pipeline, more execution units, more control logic (branch prediction, macro/micro ops fusion and a dozen other things), more cache etc.. Of course it also has 10 times as many transistors, so really there is no fair comparison.

the real silliness to use a "preset transistor budget" to make an argument on design complexity, especially when that number is a resulting artifact of actual limitations as opposed to being a limitation in itself.
 

BrownTown

Diamond Member
Dec 1, 2005
5,314
1
0
Originally posted by: dmens
Originally posted by: BrownTown
Sure it is *possible* to make a CPU with higher IPC, clockspeed and everything else, but in the real world not so much. As we are all aware when you go to design a chip there is a limited transistor budget which must be accommodated, over time this budget has risen considerably, so yeah the Core2 can have a longer pipeline and better IPC than the P3, but in terms of going out and designing a new chip on a preset transistor budget it is silly to imply that IPC and the number of pipeline stages are unrelated because the ARE very much related. The same is true for the width of the processor, in real life the comparison isn't going to be between a deeply pipelined CPU with 10 execution units verse a moderately pipelined CPU with 5 execution units, that decision is a no brainier, but the one CPU would need WAY more transistors and likely wouldn't fit into your transistor budget. The reason why the Core2 can destroy the P3 is that is has a deeper pipeline, more execution units, more control logic (branch prediction, macro/micro ops fusion and a dozen other things), more cache etc.. Of course it also has 10 times as many transistors, so really there is no fair comparison.

the real silliness to use a "preset transistor budget" to make an argument on design complexity, especially when that number is a resulting artifact of actual limitations as opposed to being a limitation in itself.

Well see now your just arguing semantics here, so yeah the *real* limiting factor might be unit costs, but the cost to produce each chip is based on the the process being used which will set some sort of area budget, and the amount of area which you use for your chip will determine in large part the number of transistors there are. The fact of the matter is that there is a very limited set of rules in terms which determine how complex of a chip you can make, you can blame then on whoever or whatever you want but it is very much true that the complexity of your design is a limited factor and acting like it is somehow possible to have your cake and eat it too in this case is simply false, when designing a chip you have to make these sort of tradeoffs and implying that you can have it all in one chip is not accurate. You could add ore execution units and make a deeper pipeline, but then you would have to reduce the size of the cache, you could have a deeper pipeline and extra control logic for it, but then you would have to reduce some other part of the chip etc..

Now yeah I know you work for Intel and I am a college senior who has taken only a few classes in VLSI design, the most complicated thing I have ever layed out and had fabricated was a 4-bit berger check ALU with 4000 transistors where you may have worked on designs with hundreds of millions of transistors, but all the classes and professors and reading of VLSI developments on the internet would indicate what I say to be true. Hell, even my own work was limited in this very way, the design was for 1.5mm^2 on a 500nm technology so we were very much constrained in terms of transistor budget, now sure with some better routing of metal line or more efficient placement we could have put in more transistors, but the point is this is a very serious constraint which must be considered in your desing. In our case it meant not being able to include a multiplier unit (IE: less complex and powerful design due entirely to transistor budget). Now I am 100% NOT trying to imply I know more about this subject than you because I certainly do not. I believe the difference of opinions here is simply one of misinterpreting what is being said. All I am trying to imply is that the designers of Nehalem (and any other chip) were constrained in terms of die size and therefore transistor number, power envelop e and other factors. And that due to this constraint tradeoffs have to be made in terms of pipeline depth, execution units, cache sizes and every other thing. In light of these constraints I believe it is accurate to imply that a much longer pipeline would result in a lower IPC because lengthening the pipeline and keeping everything else the same WILL do this, sure they could compensate by adding more control logic or more cache, or more execution units, but all these things mean more transistors and more die area and in a real design you have to weigh one against the other not simply add them all (unless you intend to double the price).
 

Nemesis 1

Lifer
Dec 30, 2006
11,366
2
0
I love what Swinburn wrote here.

Personally, after writing this I'm actually quite concerned about Intel's positioning - I'm worried that now Intel is the current preferred product over AMD, it'll use this leverage to try and suck out as much cash from enthusiasts as possible, and not have them overclock lower parts, like the E6300, Q6600 etc, to perform like £700 CPUs. At the same time, it's also potentially limiting the availability of multi-GPU by its competitors by forcing the separate north bridge, which offers better performance, to potentially only be available onto Bloomfield CPUs. It seems all the cards are in Intel's hands to deal precisely how it wishes.

I don't understand this kind of thinking. It looks to me like Intel is adderessing every segment in a way that will be cost effective for all sectors top middle and bottom . Effectively locking AMD and NV out of the intels lowend parts. So intel is making syre this is an intel chipset only . I love it. In the mid range only 1 16x pci-e or 2 8x pci-e slots.

This is good for midrange. Any see a problem here I sure don't.

Than the highend . I can't wait. I hope Larrabe works like I am hoping in so far as scaling . No way do I exspect Larrabbe to out perform Nv or ATI topend cards. But I am hoping that you can install 4 cards and get better scaling than either sli or XF.

It is really going to be nice knowing if you put out the $$$$ for the Highend desktop parts. The cheaper mid and lower end parts won't be able to = the performance. It about time.

Really whats it matter . As long as intels lowend stumps on AMDs topend its all good.
 

dmens

Platinum Member
Mar 18, 2005
2,275
965
136
Originally posted by: BrownTown
All I am trying to imply is that the designers of Nehalem (and any other chip) were constrained in terms of die size and therefore transistor number, power envelop e and other factors. And that due to this constraint tradeoffs have to be made in terms of pipeline depth, execution units, cache sizes and every other thing. In light of these constraints I believe it is accurate to imply that a much longer pipeline would result in a lower IPC because lengthening the pipeline and keeping everything else the same WILL do this, sure they could compensate by adding more control logic or more cache, or more execution units, but all these things mean more transistors and more die area and in a real design you have to weigh one against the other not simply add them all (unless you intend to double the price).

ok let's focus on transistor budget. given that a machine is floorplan limited, what would be the best way to maximize performance.

you say that a narrower machine can compensate for lower "IPC" using more cache, or more execution units. i believe it is the opposite, such a machine would be less bottlenecked by those items than a wider machine. a low width machine needs more operations in flight. the logic growth would be in buffer space, and some control logic. whereas in a high width, lower clock machine needs enough resources at each stage to accommodate all operations.

i think it is definitely incorrect to make the assumption that a design with more aggressive pipelining is a larger design, or even higher power, when compared with an equal performing machine with less pipelining, no matter the circumstances.
 

Nemesis 1

Lifer
Dec 30, 2006
11,366
2
0
Ok demens this cann't be confidentical . Could you tell me please. What did intel do with the Elbrus design team . What project are they working on . please say nehalem . I understand that they worked with VLIW (epic). So Itanic be my best guess but I am hoping they worked with nehalems compilers'
 

Nemesis 1

Lifer
Dec 30, 2006
11,366
2
0
Demens Brown Town has some strong points here.

Originally posted by: BrownTown
All I am trying to imply is that the designers of Nehalem (and any other chip) were constrained in terms of die size and therefore transistor number, power envelop e and other factors. And that due to this constraint tradeoffs have to be made in terms of pipeline depth, execution units, cache sizes and every other thing. In light of these constraints I believe it is accurate to imply that a much longer pipeline would result in a lower IPC because lengthening the pipeline and keeping everything else the same WILL do this, sure they could compensate by adding more control logic or more cache, or more execution units, but all these things mean more transistors and more die area and in a real design you have to weigh one against the other not simply add them all (unless you intend to double the price).


So I guess a few questions are inorder here.

On the nehalem top end desktop . The transitor count is a little less than that of Penryn.

Penryn has 12 mb of shared cache 12x 56= 672 million cache transitors.

Nehalem has 8mb shared cache 8x56= 448 million cache transitors

So penryn has 224 million more L2 cache transitors than Nehalem

If L1 cache transitor count stays the same.

We need to no how many transitors are in the Quick path and memory controller on die.
budget.

Than we can come close to the nuber of new logic transitors.

With Penryn having 224 more transitors in cache . It looks to me as if Intel increased logic transitor budget considerably. Because there is noway memory controller and quick path used any were near 200 million transitors. About 100 million for memory controller and quick path I havent a clue.
 

BrownTown

Diamond Member
Dec 1, 2005
5,314
1
0
You can look at the die and see the relative sizes of the different parts to some extent. Also it should be noted that transistors sizes also have a big play when you start talking about adding memory controllers and stuff, the big amplifiers and ESD diodes for all those extra pads are take alot more area than the number of transistors might suggest.

Here is one persons take on the layout which may or may not be correct.

Based on the information in these other places though it seems to be incorrect, what it labels as the shared L3 would seem to be the shared L2 and what it has as the L2 would appear to simply be the tags for each cache block, but then again none of other really knows so its all speculation.
 

dmens

Platinum Member
Mar 18, 2005
2,275
965
136
Originally posted by: BrownTown
You can look at the die and see the relative sizes of the different parts to some extent. Also it should be noted that transistors sizes also have a big play when you start talking about adding memory controllers and stuff, the big amplifiers and ESD diodes for all those extra pads are take alot more area than the number of transistors might suggest.

on the whole scale of things, those items are insignificant.

Here is one persons take on the layout which may or may not be correct.

Based on the information in these other places though it seems to be incorrect, what it labels as the shared L3 would seem to be the shared L2 and what it has as the L2 would appear to simply be the tags for each cache block, but then again none of other really knows so its all speculation.

well he got the cache sizes right but not the right location. anyways, nemesis should recalculate with the correct cache sizes
 

BrownTown

Diamond Member
Dec 1, 2005
5,314
1
0
Just BTW that same site has some other pretty sweet diagrams for those interested

Maybe Nemesis 1 should check out his favourite sexy P4C
 

Munky

Diamond Member
Feb 5, 2005
9,372
0
76
I open this thread thinking I'd read something informative, and instead I just see more Intel propaganda, and anti-AMD FUD. :thumbsdown:
 

Nemesis 1

Lifer
Dec 30, 2006
11,366
2
0
Originally posted by: dmens
Originally posted by: BrownTown
You can look at the die and see the relative sizes of the different parts to some extent. Also it should be noted that transistors sizes also have a big play when you start talking about adding memory controllers and stuff, the big amplifiers and ESD diodes for all those extra pads are take alot more area than the number of transistors might suggest.

on the whole scale of things, those items are insignificant.

Here is one persons take on the layout which may or may not be correct.

Based on the information in these other places though it seems to be incorrect, what it labels as the shared L3 would seem to be the shared L2 and what it has as the L2 would appear to simply be the tags for each cache block, but then again none of other really knows so its all speculation.

well he got the cache sizes right but not the right location. anyways, nemesis should recalculate with the correct cache sizes

Ya know. I normally spot the easy stuff right off. But I never paid attention to L1 cache size. Ya thats a sizable increase. That transitor budget is slipping away . But still 2 million logic transitors are a lot.

 

Nemesis 1

Lifer
Dec 30, 2006
11,366
2
0
Well Munky your sorta right. I will stay off amd . But your wrong about the nehalem subject matter.

We have guys here that work in the industry. I don't . All I can do is read to gather info.

So when new arch. appears. I want all info I can get. Sure some is bad info .

But this isn't Nehalem propaganda. Its a discussion on what nehalem appears to be.

Now if you want to discuss propaganda we could start a thread on it .

But I don't think that would be a good thing with all the propaganda(lies) put out buy AMD in the last 11/2 years. All one has to do is go back and pull up those threads.

Everyone thought that talking about K10 for a year and half. Was Ok . Would it be OK if we try in discuss Nehalem for 9 months before it arrives. Some stuff will be spot on . Some won't thats how it works .

Its not as if the Intel fan base is going to just make stuff up. As it is intel leading in performance . with C2D / Penryn and Nehalem on release.

Now if intel was behind would that change. Well we have recent history to look at .

Before C2D was demoed. . I really only seen a couple of Intel fanbois hyping Merom . Funny thing is they under hyped it.

So if you look at all the evidence. It has been the AMD guys that have been going the propaganda root and not the Intel guys.

One simply has to pull up old forum threads to find the facts.
 

Nemesis 1

Lifer
Dec 30, 2006
11,366
2
0
Idontcare man that was on called for . These are Hardware furum section is processors.

For you to try and say that Jag87 or myself was the grandfather type here was off the wall .
I love my children and grandchild. No talk like that would ever occur in my home with children present. I can go off on adults but Kids have a special spot in my heart. Their our hope for a better future. If one exist.

 

Idontcare

Elite Member
Oct 10, 1999
21,110
64
91
Originally posted by: Nemesis 1
Idontcare man that was on called for . These are Hardware furum section is processors.

For you to try and say that Jag87 or myself was the grandfather type here was off the wall .
I love my children and grandchild. No talk like that would ever occur in my home with children present. I can go off on adults but Kids have a special spot in my heart. Their our hope for a better future. If one exist.

Nowhere in my post did I say you (or Jag) are depicted as the angry grandfather on break.com...

But thanks for letting us all know that when you watch it that you internalize it and relate the most to that particular crazy guy in the video. (there are lots of people there...why fixated on him?)

And for the record my post wasn't to you, it was clearly to Munky (i.e. that is why I quoted him and not you...:roll:).

Now if you and Jag weren't the schoolchildren locked in a forever forum battle then I could buy into your pious claims of what you view this forum to be all about.

But your record stands in this thread already... as , so try throwing rocks at your own glass house "Mr. Holier than Thou".

Edit: But you are right that my post was uncalled for...I do feel bad for that...and I apologize to both you and Jag for airing my perceptions of your behaviours in this CPU forum thread instead of in PM. Peace be with you both.
 

JAG87

Diamond Member
Jan 3, 2006
3,921
3
76
Originally posted by: Idontcare
Originally posted by: Nemesis 1
Idontcare man that was on called for . These are Hardware furum section is processors.

For you to try and say that Jag87 or myself was the grandfather type here was off the wall .
I love my children and grandchild. No talk like that would ever occur in my home with children present. I can go off on adults but Kids have a special spot in my heart. Their our hope for a better future. If one exist.

Nowhere in my post did I say you (or Jag) are depicted as the angry grandfather on break.com...

But thanks for letting us all know that when you watch it that you internalize it and relate the most to that particular crazy guy in the video. (there are lots of people there...why fixated on him?)

And for the record my post wasn't to you, it was clearly to Munky (i.e. that is why I quoted him and not you...:roll:).

Now if you and Jag weren't the schoolchildren locked in a forever forum battle then I could buy into your pious claims of what you view this forum to be all about.

But your record stands in this thread already... as , so try throwing rocks at your own glass house "Mr. Holier than Thou".

Edit: But you are right that my post was uncalled for...I do feel bad for that...and I apologize to both you and Jag for airing my perceptions of your behaviours in this CPU forum thread instead of in PM. Peace be with you both.


Im not locked... cant you see my number of replies is clearly less than his number of retarded posts?

I have stopped caring for his threads a while ago, I only reply to illuminate readers that they are not reading information from an impartial source.