Start a thread talking about future processors from amd and I will be happy to come in and flame ya . TROLL
Hard Ball
Senior member
- Jul 3, 2005
- 594
- 0
- 0
If you are taking this kind of article from the inquirer to be fact, than it is you who's the biggest troll around here. You have no evidence, yet you insist that the article is with full merits, and that the EE merom will have HT. Where in the world are you getting your "information" from??
I dont pay attention to the hype. itanic was suppose to take over the world and kill X86, Nehalem (netburst) was to hit 10.25 Ghz in 2005 and prescott was suppose to be the final nail in AMD's coffin after the poor showing of the 3200 AXP.
Itanic didnt take over the world. It didnt kill x86. Nehalem and the long terms of plans of netburst were dicthed. 10 Ghz or even 4Ghz was not seen in 2005. Prescott was delayed and became preshott and handed the performance crown over to AMD for being a backwards step interms of performance over northwood.
My point...Wait for the damn for thing.
Itanic didnt take over the world. It didnt kill x86. Nehalem and the long terms of plans of netburst were dicthed. 10 Ghz or even 4Ghz was not seen in 2005. Prescott was delayed and became preshott and handed the performance crown over to AMD for being a backwards step interms of performance over northwood.
My point...Wait for the damn for thing.
This is from the Anand article
Moving on to the final architecture, we come to IA-64/EPIC. While similar in some ways to VLIW (Very Long Instruction Word) architectures of the past, Intel worked to overcome some of the problems with VLIW (specifically the need to recompile code for every processor update) and called their new approach EPIC: "Explicitly Parallel Instruction Computer". In contrast to the P6, NetBurst, K7, and K8 architectures that can issue up to three instructions per cycle, the current Itanium 2 chips can issue eight instructions per clock. From a purely theoretical standpoint, the fastest Itanium 2 running at 1.6 GHz actually has more computational power than any other Intel chip. Throw in dual core designs with HyperThreading - HyperThreading that actually works much better than NetBurst HTT due to the wide design of EPIC - and each chip not only has the potential to issue eight instructions per clock, but it should actually come relatively close to that number. Another difference between Itanium and the other designs is that large amounts of cache are present in order to keep the pipelines fed with data. Current models ship with up to 9MB of L3 cache, while future parts like the Montecito will have 24MB of L3 cache (and a transistor count of 1.7 billion transistors - about eight times the transistor count of the Pentium D Smithfield core)!
Of course, with the wide issue rate of Itanium 2 (the original Itanium "only" had a 6-wide issue rate), you need a lot of execution units. NetBurst has 7 execution units in Prescott: two simple integer units (which can function as 4 integer units if you count the double pumped design), a complex integer unit, two FP/SIMD units, and dedicated memory load and store units. If you want to count the simple integer units as 2 each, you could make a stretch and say NetBurst has nine execution units. AMD's K7 and K8 both have nine execution units as well, only they go for a less customized approach and instead have three each of the integer, FP/SIMD, and memory units. Each of AMD's units is fully functional, unlike the "simple" and "complex" integer units in NetBurst. In contrast to these architectures, the current Itanium 2 chips have six ALUs (Arithmetic Logic Units), three BRUs (Branch Units), two FPUs, one SIMD, two load units, and two store units - call it 16 functional units if you prefer, though the specialization of some of them makes it slightly less than that. While Itanium 2 is very wide, the length of the pipeline is only 8 stages - less than any other modern x86 processor by a significant amount. That certainly plays a role in the reduced clock speeds, but like Athlon 64, lower clock speeds with a more efficient architecture can outperform long pipelines in many instances. In order to extract all of the potential performance from Itanium, however, a lot of work needs to be done during code compilation. This is the Achilles' heel of VLIW designs; Processor updates require the code to be recompiled. While EPIC doesn't require that you recompile the code, newer compiler optimizations can improve performance significantly.
This is a discussion about future processor development and what we get out of it . speculations is all we have . What part of that don't you understand.
Start a thread talking about future processors from amd and I will be happy to come in and flame ya . TROLL (this was meant for the meth, guy hard ball)
Hard Ball
Senior member
- Jul 3, 2005
- 594
- 0
- 0
So, you are saying that you don't have evidence, nor would you need to have evidence for any of this discussion. One of the classic signs that points to a TROLL is preponderance of speculations with no fact to back it up; and passing all of this to the forum as if it were fact.
That description would be best applied to you; Dude, or dudette.
I'd rather not have 'domination' Intel or otherwise thank you!
Hush now!
Noone, can say what the situation will be in 2007. Maybe I should have started a separate thread about speculating on the K10 design given that's what Conroe will be coming against, but alas it'll be too early and fruitless.
Either way Intel are at least looking to be coming out with a far better chip than Netburst and for that we can all be thankful - maybe it'll even give some fanboys something worth touting
IntelUser2000
Elite Member
- Oct 14, 2003
- 8,686
- 3,787
- 136
The performance rumor of Merom over Yonah is 30% PER CLOCK. Remember Conroe is a desktop variant of Merom. I hate to disappoint people, but it COULD be this way. Let's look at the rumored specs of Merom first before I explain my theory:
-65nm
-Arbitration logic(manages data between two cores)
-4MB shared L2 cache(meaning one core can use all the cache when the other core is off, or two cores can share)
-Four-wide implementation of the x86 architecture
-Similar pipeline stages to Pentium M, little possibility its greater
-Dual Core
-Hyperthreading or some sort of multi-threading on Extreme Editions??
-1066MHz bus
Let's look at Yonah
-65nm
-Arbitration logic
-2MB shared L2 cache, which has the ability to increase bandwidth when two cores access data, with better data prefetch
-667MHz bus
-More advanced thermal management
-Dual Core
-Three-wide implementation of the x86 architecture, which is what all P6 cores have
-Similar pipeline stages to Pentium M
Let me explain what "three-wide" and "four-wide" means. 3-wide means that it can have theoretical IPC of 3 and 4-wide means, you guessed it, IPC of 4. Now none of the CPUs ever manufactured gets close to the theoretical IPC numbers(In contrast, Pentium 4 can have maximum IPC of 2, or 2-wide due to limitations, and all Athlons have 3).
To get as close as possible to theoretical IPC:
-You must have programs that are optimized to be parallel as possible
-The CPU must have enough bandwidth
-The CPU must have enough resources, like registers(which x86 seriously lacks with 8 registers, and x86-64 only a bit better with 16)
-It should have massively Out of Order execution capability
"My theory:
This is where it may be disappointing for people who is expecting 30% performance increase per clock from Yonah. I believe the first person who heard the 4-wide rumor, thought since 4-wide is 33% greater than 3-wide(4/3=1.33), the performance increase must be 30%. Then everyone now says performance increase is 30% since IPC is 30% greater. That's not true because it gets harder to extract IPC as IPC theoretical increases. It may be in reality, 10%. Of course that may be the real performance increase. But remember how there was a rumor that Prescott would have been 40% faster PER CLOCK over Northwood??"
-65nm
-Arbitration logic(manages data between two cores)
-4MB shared L2 cache(meaning one core can use all the cache when the other core is off, or two cores can share)
-Four-wide implementation of the x86 architecture
-Similar pipeline stages to Pentium M, little possibility its greater
-Dual Core
-Hyperthreading or some sort of multi-threading on Extreme Editions??
-1066MHz bus
Let's look at Yonah
-65nm
-Arbitration logic
-2MB shared L2 cache, which has the ability to increase bandwidth when two cores access data, with better data prefetch
-667MHz bus
-More advanced thermal management
-Dual Core
-Three-wide implementation of the x86 architecture, which is what all P6 cores have
-Similar pipeline stages to Pentium M
Let me explain what "three-wide" and "four-wide" means. 3-wide means that it can have theoretical IPC of 3 and 4-wide means, you guessed it, IPC of 4. Now none of the CPUs ever manufactured gets close to the theoretical IPC numbers(In contrast, Pentium 4 can have maximum IPC of 2, or 2-wide due to limitations, and all Athlons have 3).
To get as close as possible to theoretical IPC:
-You must have programs that are optimized to be parallel as possible
-The CPU must have enough bandwidth
-The CPU must have enough resources, like registers(which x86 seriously lacks with 8 registers, and x86-64 only a bit better with 16)
-It should have massively Out of Order execution capability
"My theory:
This is where it may be disappointing for people who is expecting 30% performance increase per clock from Yonah. I believe the first person who heard the 4-wide rumor, thought since 4-wide is 33% greater than 3-wide(4/3=1.33), the performance increase must be 30%. Then everyone now says performance increase is 30% since IPC is 30% greater. That's not true because it gets harder to extract IPC as IPC theoretical increases. It may be in reality, 10%. Of course that may be the real performance increase. But remember how there was a rumor that Prescott would have been 40% faster PER CLOCK over Northwood??"
IntelUser2000
Elite Member
- Oct 14, 2003
- 8,686
- 3,787
- 136
Conroe/Merom is not based off P6 architecture due to the fact that it may be a 4-wide CPU.
It is nearly impossible or not feasible from either technical or marketing standpoint to have Conroe/Merom be based on EPIC. The IA-32EL(translates IA32 instructions to EPIC instructions) have a performance that's around 50% in Integer and 35% in Floating Point compared to native performance. In order to have a competitive CPU based on that architecture for 32-bit performance, the native 64-bit performance would have to be unimaginable from current point of view.
I think my theory above is right.
(Response to the Anandtech article:
First Itanium is 6-wide
Itanium 2 is 6-wide
Itanium 2 doesn't increase the issue rate, what Itanium 2 does is increase the possibility that IPC of 6 is possible by making better architecture.
Brief overview of Itanium architecture: The CPU processes the EPIC instructions by using two bundles of 3 instructions each. Each bundle can have a certain combination of different instructions.
Main execution units in Itanium consists of 4, that is Branch unit, Floating Point Unit, Memory Unit, Integer Unit. Memory and Integer unit can be considered in simple terms as ALU from what I understand.
In one bundle, you can have certain combinations of those execution units. Examples may be: MMI(memory, memory, integer), MII, MIF, BBB, and such. Remember that each bundle can have that combinations, and there is like 26 combinations or so. That means if the second bundle can't have that combinations due to the lack of execution units, 6-wide isn't possible.
Itanium had 2 M units, 2 I units, 2 FP units, 3 B units. So if the first bundle is MMI and the second bundle is MMI, it can't have 6-wide execution.
According to the article I read, first Itanium can have in theory of ~3.8 IPC due to lack of execution units, and Itanium 2 have theoretical IPC of 5.6-5.7 due to more execution units, specifically 4 M units rather than 2 as in Itanium.)
It is nearly impossible or not feasible from either technical or marketing standpoint to have Conroe/Merom be based on EPIC. The IA-32EL(translates IA32 instructions to EPIC instructions) have a performance that's around 50% in Integer and 35% in Floating Point compared to native performance. In order to have a competitive CPU based on that architecture for 32-bit performance, the native 64-bit performance would have to be unimaginable from current point of view.
I think my theory above is right.
(Response to the Anandtech article:
First Itanium is 6-wide
Itanium 2 is 6-wide
Itanium 2 doesn't increase the issue rate, what Itanium 2 does is increase the possibility that IPC of 6 is possible by making better architecture.
Brief overview of Itanium architecture: The CPU processes the EPIC instructions by using two bundles of 3 instructions each. Each bundle can have a certain combination of different instructions.
Main execution units in Itanium consists of 4, that is Branch unit, Floating Point Unit, Memory Unit, Integer Unit. Memory and Integer unit can be considered in simple terms as ALU from what I understand.
In one bundle, you can have certain combinations of those execution units. Examples may be: MMI(memory, memory, integer), MII, MIF, BBB, and such. Remember that each bundle can have that combinations, and there is like 26 combinations or so. That means if the second bundle can't have that combinations due to the lack of execution units, 6-wide isn't possible.
Itanium had 2 M units, 2 I units, 2 FP units, 3 B units. So if the first bundle is MMI and the second bundle is MMI, it can't have 6-wide execution.
According to the article I read, first Itanium can have in theory of ~3.8 IPC due to lack of execution units, and Itanium 2 have theoretical IPC of 5.6-5.7 due to more execution units, specifically 4 M units rather than 2 as in Itanium.)
Conroe/Merom will be a true next generation architecture, or maybe current generation architecture, considering Dothan was just a suped up P3.
BTW, isn't a shared L2 cache slower than one that isn't shared?
BTW, isn't a shared L2 cache slower than one that isn't shared?
it really is too bad that intel dropped P3 archetecture...
Netburst was a waste of time and money. I hope someone lost their job over that!
It is nice they are trying something new with the processors cuz amd is killing them in the gaming world right now!
Netburst was a waste of time and money. I hope someone lost their job over that!
It is nice they are trying something new with the processors cuz amd is killing them in the gaming world right now!
Markfw
Moderator Emeritus, Elite Member
- May 16, 2002
- 27,329
- 16,161
- 136
At the moment, what (other than dothan laptop) does Intel have that competes at all ? Dual-core ? I don't think so, server ? I don't think so., as you pointed out, single-core no way. And the Turion at least takes a stab at dothan. My son got a new laptop with it, and it was $400 cheaper than the least exspensive pentium M, and it is smokin fast.
Netburst enjoyed...something like 3-6 months on top before A64s came out, plus gave Intel a much needed boost in the server/workstation market that P3 never could have done performance wise, and really helped them in sales as people bought on the mhz, and allowed them to really cripple Celeron yet still get people to buy it.
And if Netburst hadn't run out of steam, it could possibly still be on top. 5ghz prescott versus ~3ghz athlon 64 would probably be a similar matchup to northwood versus athlon xp.
The idea that Hyperthreading only benefits processors with longer pipelines is usually perpetuated by those who also equate pipeline depth with IPC.
Pipeline depth has absolutely nothing to do with determining whether a given processor architecture is suitable for SMT.
Hyperthreading allows the P4's schedulers to pick from instructions from independent threads. If a thread has a very low amount of ILP (often caused by a high degree of data dependency) then it is going to be very difficult for the schedulers to find instructions that can be executed in parallel. Hyperthreading allows the schedulers to pick instructions from two independent threads, meaning that the schedulers should be able to find non-dependent instructions it can issue in parellel, since data dependencies do not exist across threads.
This is the whole point of SMT; to assist superscalar architectures to manage an IPC of > 1. Indeed, SMT would have been useless on pre-Pentium architectures, as superscalar execution didn't exist on the x86 platform previously.
There are two simple ways to increase the performance of an architecture:
1. An increase in frequency through an extended pipeline (accompanied with according improvements to the branch prediction mechanism to offset the negative impact on IPC).
2. An increase in theoretical IPC.
Of course, ideally we'd implement both methods, but since the high IPC method seems to have been given the spotlight of late, let's discuss this.
The maximum number of instructions a processor can execute per clock is determined by the number of execution units of each type. A thread comprised of integer code, for example, can only be executed by the integer units, and the maximum IPC attainable by the processor when executing this code will be determined by the number of these.
The average IPC however, is determined by the issue rate, the accuracy of the branch predictor (and the number of clock cycles wasted in flushing the pipeline), and the ability of the schedulers to find instructions to execute in parallel, which was discussed above.
The Athlon can sustain a very high issue rate, thanks to its three general purpose decoders, but if the schedulers can't find an equal number of intructions to execute in parallel per clock, then its decode ability is going to go to waste. One way to increase the Athlon's (admittedly already high) IPC would be to increase the instruction window and correspondingly the number of tracked instructions. This would make life easier for the schedulers but would greatly increase the power draw.
An alternative method would be to introduce an independent instruction stream, reducing the need for a larger instruction window.
The importance of finding instructions that can be executed in parallel increases with the number of execution units.
So, if Conroe is going to be a wide-issue design, it will need to either have a very large instruction window, or it will need Hyperthreading.
Considering the impact on power requirements of the former method, I would expect Intel to place more emphasis on the latter.
IntelUser2000
Elite Member
- Oct 14, 2003
- 8,686
- 3,787
- 136
Shared caches are better when you manage to implement it well. It seems that Yonah's caches are really good. One of the features of the shared cache that Intel calls called Bandwidth Adaptation Buffer, when two cores are accessing the cache, it doubles the bandwidth and implements prefetch algorithm when compared to single core accessing that same size cache.
- Exactly as expected.
...Which is good because it also means no surprises...
(why ain't there any smilies for 'unbearably smug' ? )
...Which is good because it also means no surprises...
(why ain't there any smilies for 'unbearably smug' ? )
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 23K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter