Anyone who's OC'ed multi core chips knows that one core will be the weak link. Technically, the other cores might have higher OC potential, if it wasn't for their twin brother holding them back.
What AMD is doing is giving us a way around that by letting us OC to the highest level on each core. So say, one core might max out at 3.4Ghz, and the other 3.3Ghz. You'll get the benefit of 100Mhz that you wouldn't normally get on a chip that had only one multiplier for all 4 cores.
Question is, what anomaly's might appear when you do asynchronous over clocking? The result might be performance that seems uneven, like an egg rolling end over end. Or the result might be that the faster core will end up waiting on the slower core, so your effective speed will still be only as good as the slowest core, unless you manually set affinity. No one will know until this ends up in the hands of John Q Public.
Last edited by Rock&Roll; 11-18-2007 at 07:35 AM.
Correcto. But what I'm talking about is in heavy multithreaded application which uses all the cores possible. The workload would be distributed to all the cores evenly, and if one of the cores is slower, it'll take longer to finish executing the instruction. Having this one instruction a bit slower may not seem like a big deal at first, but if the other instructions in the core are dependent on each other to finish a certain clock cycle, this could become problematic. My best guess of how AMD got around this was probably the shared L3 cache and using it as storage for all 4 instructions. Then fetching the finished executed result from there. The other solution is likely to be stalling for the slower core, which would reduce the purpose of indepedent core overclocking. Fixing this solution by far is not an easy task.
Last edited by Start; 11-18-2007 at 07:40 AM.
Anyone else noticed that there will probably be an extreme edition of this soon? He uses multi 14 so his one at least has to be unlocked
of course you can.
remember the TSC problem with dualcore cpus?
one core would skip every second clock and throttle since its barely being used, as a result the TSC would run out of sny and the games stuttered or crashed. once there were patches that synced the TSCs games and apps worked fine even if core2 is idel enough to trigger the clock skipping.
and in case you didnt know this on intel quads this is possible as well, you can clock 2 of the 4 cores at a different clockspeed by changing the multi, and no, games and apps dont crash or produce errors. :P
do you honestly think amd goes all the length to design a cpu where every core can be clocked independantly when doing so actually makes most apps crash and not work properly? :P
There is a difference with a hardware TSC bug and being able to dynamicly load cores after performance. There simply aint no such thing.
The affected issue you talk about got nothing to do with throttling. But how the software counter ran and was affected.
Also I bet you that the 2 speed core issue that was with early beta BIOSes didnt get tested much back then. But even then, you still cant make windows automaticly use those faster cores in multithreaded applications. it would still end up with the rollercoaster model.
But again, I didnt say every game and app would crash did I? We talk about the possible speed benefit of it and what could go wrong. Aka some certain apps that still use software TSC.
There is a reason why OEMs ship servers with disabled CnQ and Speedstep too you know.
Crunching for Comrades and the Common good of the People.
Not necessarily, take Cinebench for instance. It will continue on with it's rendering of an image even if one core has slowed down rendering part of the scene. You can clearly see this in the Cinebench benchmark. Any good multithreading program should be able to do this. Of course, it's easier said then done.![]()
Yeah, but that is with all the cores running the same speed. We haven't really seen any results from different clock frequency. Anytime you throw multiple clock frequency, things start to get more complicated. I'm sure AMD engineers aren't that stupid not to address this issue. We'll see in a couple of days whether or not this will be an issue. Until then, just speculation.
The day of truth for Phenom is tomorrow. Watch for leaks late tonight!
"To exist in this vast universe for a speck of time is the great gift of life. Our tiny sliver of time is our gift of life. It is our only life. The universe will go on, indifferent to our brief existence, but while we are here we touch not just part of that vastness, but also the lives around us. Life is the gift each of us has been given. Each life is our own and no one else's. It is precious beyond all counting. It is the greatest value we have. Cherish it for what it truly is."
Bookmarks