I dont see anyone in this whole thread disputing if kentfield is true quadcore just the fact that it is not native quad core. it seems that you've now mixed up the argument of whats native quadcore with what is truly quadcore. Kentfield=True Quadcore non native quadcore. True Quadcore simply means four cores on one processor, while native quadcore is stricter and refers to four cores on one die.Donnie27 said:http://enthusiast.hardocp.com/article.html?art=MTIxMywxLCxoZW50aHVzaWFzdA==
Originally Posted by [H
] Understandably you will hear many critics complain about how this solution is not a "true" quad-core design, or they will sound off and bash it for not being as "elegant" as what the competition is bringing to market. And they may be right, but it hardly changes the facts. The fact of the matter is that it is truly a quad-core processor whether or not it is a quad-core die. The fact of the matter is that Intel's front side bus design might be a bit long in the tooth, but there is no doubt that we are seeing tremendous performance channeled through it. To me, at the end of the day, it is all about the application performance we can squeeze out of it and how hot it gets along the way. Yes, real performance per watt is our measure.
Nailed that one,
![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
-
Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.
Native Quad Core?
- Thread starter Donnie27
- Start date
(cf)Eclipse said:
Last time I checked, HTT and Crossbar is Internal Hardware as well. Each K8 Processor Core's L2 is connected to an Internal Crossbar
This then connects to an HTT or two in the case of the MP versions, yes, they're on die.You're entitled to your Opinion
Intel called Smith Field Dual Core but not native like Conroe. Just like with AMD, Intel laid the groundwork for Conroe to connect to other Conroes without modification. IMHO, that's native. So it still stands that AMD is merely talking $#it!Donnie27 said:
LOL... he's just got some weird jones for me. He'll get on a tangent and follow me from thread to thread telling everybody that because I have a job I can't be trusted, yada yada yada.
I think he feels that he is a crusader for the masses and that I hide the fact, sneaking around the boards shuffling misinformation around to help my cause... whatever that is. I think it's cute really... it's like my own little PR machine. Poncho said:
Yes, there are accepted Double standards that are alive and well here.
IMHO, there are a lot of AMD plants here who'll NOT ID themselves as such. I don't know why either since many posters here would be sucking up to them anyway LOL j/k. At least like you, I'd respect them more if they did at least work for AMD. You mean Duby229 and many others are is doing this out of some kind of misplaced love for AMD I've honestly seen you try to be fairer than many on the AMD side who claim to not be an employee or stand to gain anything from AMD (stockholder, advertising revenue and etc...). But hell, that's easy!
GreyMatterTripp
Weaksauce
- Joined
- Oct 2, 2006
- Messages
- 96
whats cute is I said nothing about AMD yet your still trying to pound them into the ground, showing your true objectives. Your a joke.
GreyMatterTripp
Weaksauce
- Joined
- Oct 2, 2006
- Messages
- 96
get a life outside of the confines of plastic and solder, it would help your social skills.
GreyMatterTripp
Weaksauce
- Joined
- Oct 2, 2006
- Messages
- 96
native means native....morons
Who cares... really? People so obsessed with the arbitrary labeling of "true," "native," "full," etc. on things lose sight of the big picture. What really matters is performance and people are trying to use arbitrary labels to measure performance of non-released products.
Exactly...
Take the multithread-thingie I've coded and posted here: http://www.hardforum.com/showthread.php?t=1047658
So far the best results I had reported is a gain of 47% from running the Multithread2 version.
Ironically enough that machine was a Pentium D 805.
Yes, the 'non-native' dualcore, which everyone was flaming for being a hackjob.
My personal experience is that both Pentium D and Athlon X2 perform quite badly on multithreading algos where parts of memory are updated on both cores.
I originally wrote my algo that way, because it ran fine on my Core2 duo, so I thought I could get away with it (I didn't expect a lot of updates between cores, and I didn't expect the shared cache to be as efficient as it apparently is).
While admittedly the Pentium D was affected the most, and performance actually dropped when running the multithreaded version, the point is rather moot, because the Athlon X2 didn't gain any performance either. So in both cases singlethreaded would be the better choice.
But after I had rewritten my algo to avoid writing to common memory as much as possible, the Pentium D got more gain than the X2.
Even the Core2 got a bit extra gain, which I didn't really expect, to be honest.
But I have to conclude that the Pentium D basically only has performance problems with multithreaded code when the code would not work properly on an Athlon X2 anyway.
Apparently the Athlon X2's cache synchronization is not that much more efficient, even though it doesn't use an FSB.
I also tested on a HyperThreading machine, and the first multithreading algo wasn't slower than the singlecore version there, so my theory is that both the P4 HT and the Core2 Duo are not adversely affected because both threads share the same L2-cache, which means that the synchronization is much more efficient than with isolated caches such as the Pentium D and Athlon X2.
I expect the quadcore world to be pretty much the same. I don't think the K8L will have good performance in this situation, because it doesn't have shared L2 cache either. They will add shared L3 to compensate, but I don't think it will win out against the Kentfield. Namely, the Kentsfield has shared L2 cache at least between the two pairs of cores. Only when more than two cores need their cache synchronized, you need the FSB... But since the Pentium D wasn't affected that much, and the Kentsfield has a faster FSB... I don't think it will be a big deal. If it happens at all, you may just have to reduce the number of threads anyway.
So I think the shared L2-cache is the ticket to efficient multithreading. It makes the CPU much more forgiving for threads that need to keep their caches synchronized, which opens up new ways to optimize algos for multicore. K8 cannot take advantage of that, and K8L will probably only take limited advantage, because L3 cache will be considerably slower than L2 cache. Combine that with the fact that the Kentsfield has faster cores and more cache per core, and I think Intel is going to win this round of the multicore wars.
As for Quadfather... I think that will be a joke, really. 4 cores that don't even have shared L3-cache... I think the multithreading capabilities will be severely limited.
Take the multithread-thingie I've coded and posted here: http://www.hardforum.com/showthread.php?t=1047658
So far the best results I had reported is a gain of 47% from running the Multithread2 version.
Ironically enough that machine was a Pentium D 805.
Yes, the 'non-native' dualcore, which everyone was flaming for being a hackjob.
My personal experience is that both Pentium D and Athlon X2 perform quite badly on multithreading algos where parts of memory are updated on both cores.
I originally wrote my algo that way, because it ran fine on my Core2 duo, so I thought I could get away with it (I didn't expect a lot of updates between cores, and I didn't expect the shared cache to be as efficient as it apparently is).
While admittedly the Pentium D was affected the most, and performance actually dropped when running the multithreaded version, the point is rather moot, because the Athlon X2 didn't gain any performance either. So in both cases singlethreaded would be the better choice.
But after I had rewritten my algo to avoid writing to common memory as much as possible, the Pentium D got more gain than the X2.
Even the Core2 got a bit extra gain, which I didn't really expect, to be honest.
But I have to conclude that the Pentium D basically only has performance problems with multithreaded code when the code would not work properly on an Athlon X2 anyway.
Apparently the Athlon X2's cache synchronization is not that much more efficient, even though it doesn't use an FSB.
I also tested on a HyperThreading machine, and the first multithreading algo wasn't slower than the singlecore version there, so my theory is that both the P4 HT and the Core2 Duo are not adversely affected because both threads share the same L2-cache, which means that the synchronization is much more efficient than with isolated caches such as the Pentium D and Athlon X2.
I expect the quadcore world to be pretty much the same. I don't think the K8L will have good performance in this situation, because it doesn't have shared L2 cache either. They will add shared L3 to compensate, but I don't think it will win out against the Kentfield. Namely, the Kentsfield has shared L2 cache at least between the two pairs of cores. Only when more than two cores need their cache synchronized, you need the FSB... But since the Pentium D wasn't affected that much, and the Kentsfield has a faster FSB... I don't think it will be a big deal. If it happens at all, you may just have to reduce the number of threads anyway.
So I think the shared L2-cache is the ticket to efficient multithreading. It makes the CPU much more forgiving for threads that need to keep their caches synchronized, which opens up new ways to optimize algos for multicore. K8 cannot take advantage of that, and K8L will probably only take limited advantage, because L3 cache will be considerably slower than L2 cache. Combine that with the fact that the Kentsfield has faster cores and more cache per core, and I think Intel is going to win this round of the multicore wars.
As for Quadfather... I think that will be a joke, really. 4 cores that don't even have shared L3-cache... I think the multithreading capabilities will be severely limited.
(cf)Eclipse said:last i checked, the htt is on the crossbar for external comunication, not internal
in my mind, smithfield is native dual core. two cpus on one die. it's a very clearcut definition, no reason to make things more difficult than it has to be.
And on another note!
http://www.bit-tech.net/news/2006/09/27/intel_ship_1m_quad_core_before_amd/
cuz then the next logical progression would be to octalcore cpus, and by that time, dual core cpu utilization will be much more prevalent for games and probably even some quad core utilization. imagine ten years from now games coming out with native octalcore support. the future holds good things.Donnie27 said:
i would be more inclined to say there there will be more then 8 core natively by then. Intel is going to ship native quad core next year and i would imagine if they follow the same pattern, release dual die 8 core processors a few months later and then native 8 core processors a year or so later. It's scary how fast this stuff is starting to movekhuyakuya said:
now only if AMD would follow suit itd be even more interesting. they need to hurry up and release the k8l SOON cuz im putting off on getting a new system til i can compare intels offering with amds when both have quad out or im very tempted to jump the gun and get a conroe.Duke3d87 said:
Donnie27 said:
Thanks, I would have expected more feedback though...
This basically shows that the Athlon X2 is only marginally better at synchronizing caches between cores than the Pentium D, even though the AMD-fans would always say that the FSB between the cores of the Pentium D would be a very weak point in this situations.
Granted, it is a weak point of the Pentium D, but as it turns out, it is also a weak point on the Athlon X2.
Only the shared L2-cache on the Core2 is actually a strong point in this situation.
I only came across this problem by accident, as I had originally written my code on a Core2 Duo... and was just curious how other CPUs would handle it. I rewrote it because I couldn't accept that other dualcores wouldn't get any gain. But I only expected the Pentium D to have trouble, not the Athlon X2.
Let's just say my trust in AMD has sunk to an all-time low now. I'm not buying their marketing-talk anymore either. I'll just test my code on it and see how much better their stuff is.
Native dualcore/quadcore... right. If it doesn't perform, I don't care.
Scali2 said:
Not buying BS marketing was the root point of the Whole Native BS to start with. I'm looking forward to AMD's core improvements and I have very little confidence in anything else they're BS-ing about.
Very interesting! Kind of like that thread awhile back about 64bit. Even though P4D was the slowest of the 3 (C2D, P4D and A64-FX) it showed the most improvement with WinXP-64. Sure the end result was that it was still slower at the end of the day. But the OP's view was that 64bit didn't work as efficiently on C2D as the others.
Yea, 64-bit is another nice myth, just like this multicore stuff.
Sure, in theory the Athlon may be better... but the difference is so marginal that you will not notice much of it in practice.
In practice the Core2 is the only one where you actually notice a substantial difference in the way multithreaded code performs. The others should basically be treated like a dual CPU system, where the cores are physically separated, because in effect they are.
As for Core2 not getting as much gain in 64-bit mode... part of that could be because the baseline performance in 32-bit is much higher. Which means you'll be limited more by other hardware, such as memory, harddisks, videocards etc.
I have yet to see a comparison of a Core2 and Athlon with virtually the same baseline 32-bit performance. That Core2 may scale better in 64-bit mode than a high-end Core2.
Obviously, the faster you go, the harder it is to improve, if the rest of the system isn't improving.
Even so, the gain an Athlon gets in 64-bit mode is quite irrelevant, because it isn't substantial enough to get anywhere near the performance levels of a Core2.
We have yet to see if AMD can create a processor that can reach the levels of Core2, and then we should see if it STILL scales as well in 64-bit mode.
I find it strange that so many people talk about this kind of nonsense, and so little people actually bother to investigate just how much the difference is.
And well, ironically I actually wrote the singlethreaded version on my Athlon XP 1800+, so if the core algorithm was favouring any architecture at all, it would probably be the Athlon, because that was my reference for testing my optimizations.
The multithreading didn't alter the core algo, it just split up some loops over multiple threads, and some variables had to be duplicated for each thread, but that's about it.
Sure, in theory the Athlon may be better... but the difference is so marginal that you will not notice much of it in practice.
In practice the Core2 is the only one where you actually notice a substantial difference in the way multithreaded code performs. The others should basically be treated like a dual CPU system, where the cores are physically separated, because in effect they are.
As for Core2 not getting as much gain in 64-bit mode... part of that could be because the baseline performance in 32-bit is much higher. Which means you'll be limited more by other hardware, such as memory, harddisks, videocards etc.
I have yet to see a comparison of a Core2 and Athlon with virtually the same baseline 32-bit performance. That Core2 may scale better in 64-bit mode than a high-end Core2.
Obviously, the faster you go, the harder it is to improve, if the rest of the system isn't improving.
Even so, the gain an Athlon gets in 64-bit mode is quite irrelevant, because it isn't substantial enough to get anywhere near the performance levels of a Core2.
We have yet to see if AMD can create a processor that can reach the levels of Core2, and then we should see if it STILL scales as well in 64-bit mode.
I find it strange that so many people talk about this kind of nonsense, and so little people actually bother to investigate just how much the difference is.
And well, ironically I actually wrote the singlethreaded version on my Athlon XP 1800+, so if the core algorithm was favouring any architecture at all, it would probably be the Athlon, because that was my reference for testing my optimizations.
The multithreading didn't alter the core algo, it just split up some loops over multiple threads, and some variables had to be duplicated for each thread, but that's about it.
brucedeluxe169
2[H]4U
- Joined
- Aug 24, 2004
- Messages
- 3,720
obvious f@nboyism
I'm not on the side of either manufacturer. I'm on the side of technology.
I just want my code to run as well as possible on any CPU.
Which requires that I know about the strengths and weaknesses of them all, in order to choose my optimization strategies.
Currently the Core2 seems to offer the most options in that respect, and also gives the best absolute performance.
Which is a luxury really, because I used to prefer the Intel for its raw SSE2-power, but the Athlon was more forgiving to code for.
In multicore the Athlon is not forgiving at all, it seems.
I just want my code to run as well as possible on any CPU.
Which requires that I know about the strengths and weaknesses of them all, in order to choose my optimization strategies.
Currently the Core2 seems to offer the most options in that respect, and also gives the best absolute performance.
Which is a luxury really, because I used to prefer the Intel for its raw SSE2-power, but the Athlon was more forgiving to code for.
In multicore the Athlon is not forgiving at all, it seems.
- Joined
- Dec 9, 2000
- Messages
- 16,282
I believe the better reason for native and not native discussions are due to the fact that non-native quad core cpus will be used the same way dual dual core cpus would, where as giving more latency to their communication between the 2 chips? where as a native quad core will be used a single cpu / 4 cores and faster communication between the cores .
i guess its like taking 2 4 cylinder motors and tryin to call them "V8" but in reality they would be an 8 Cyl or 2 x4cyl , where as a true V8 would be a v8 =p and an 8 cyl?
i guess its like taking 2 4 cylinder motors and tryin to call them "V8" but in reality they would be an 8 Cyl or 2 x4cyl , where as a true V8 would be a v8 =p and an 8 cyl?
Donnie27 said:No, not this time. I didn't say he said 4 X 4 was Native Quad Core, so you read more carefully next time. I said they're calling 4 X 4 "Quad Father". I didn't say they're calling 4 X 4 native Quad Core. Link to where I did? I said I didn't think K8L was any more "Native" Quad Core than Kentsfield is=P
Again, if Two Dual Cores ain't Native Quad Core, then Four Single Processors sure as hell ain't
I clearly said if AMD doesn't upgrade the core, and we both know they will, the native stuff is shown for the BS that it is. You can Natively connect the current K8 all you like and it still gets pimp slapped IMHO.
Then AMD is setting themselves up to Fail. If AMD squeezes out a 1 to 7% advantage over Intel or just matches them, it'll still seen as if they failed. Folks will say stuff like; "You say you have the real Native QC support, IMC, better Architecture and that's all you can do?".
Digital Viper-X- said:
This is exactly why I posted my findings earlier!
In *theory* a native dualcore quadcore can be better.
What my program demonstrates, however, is that in *practice* the Athlon X2 is barely more efficient than the Pentium D.
It's all about the implementation. Core2 Duo is a good native dualcore implementation, Athlon X2 isn't. It's basically the same as a Pentium D, except that they don't have an FSB, technically. They still communicate via an inefficient bus, the cores are physically separated otherwise.
K8L may be native, but it's still with physically separated cores, up to the L2-cache, like the K8. They patched L3-cache on, but so far the information indicates that it will be either 2 or 4 mb in size, which is way too small for 4 cores. A Core2 has 2 mb per core, not in total!
And that's L2-cache, which is faster than L3 cache by definition.
So I expect similar results as with the K8 and Pentium D.
In theory AMD has a better design, but in practice it may not perform better at all. Which makes the whole 'native' thing a hollow marketing term.
Native is only better if you have a proper implementation! AMD does not!
Digital Viper-X- said:
That's a very bad analogy. Why? The 8cyl engine was born from two 4 cyl. IMHO, native should mean each core can talk or communicate without a Crossbar or FSB. Another example, A Chevy/GM 305ci motor is nothing more than a 350ci with two of the Cylinders cut off.
The Core should have direct ties to the other 3 cores before each reaches L1 cache, that's Native IMHO. They would be 100% dynamic in that all 4 could work on one thread as one big processor or one each on a Quad thread, on-the-fly.
Intel's makes fewer steps than AMD's. Shared L2 and no L3 with two cores that feature 14 cycle latency makes that NATIVE talk seem stupid! Something else missed and not really talked about is Intel's Smart Cache access and Smart Memory Access That makes that old FSB and no MCM/ICM much less of an Issue. Plus, Intel seems to have that arbitration thing working nicely. If AMD's Direct Connect needs extra buffers and a L3, seems AMD doesn't
Again, AMD should be talking about making the same CORE Improvements to K8 as Intel did going from Pentium-M to Core. That, should be the real performance comeback for AMD to push, not some Cock-a-mammie Native crap-o-la. Make an AMD Native Quad Core (as they call it) with current K8's and watch it get spanked to hell and back.