• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

What will come of this "Core war" HEDT processor manufacturers are in?

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.
Agreed. Ryzen is more than good enough to give a fight, so there will be a shift. The only question is how much. Even at my basic level of economic understanding, it may be worth Intel not chasing to maintain market share as it will be less loss for them in short or medium term. I can imagine small or gradual changes, but I don't expect sudden or large shifts any time soon. We're probably looking at generational timescales for things to happen. The only risk for Intel is that Ryzen could gain sufficient momentum quickly to become significant volume wise, then they might have to get more aggressive in response. I don't think we'll see that potential until R3, APUs and mobile arrive.

I agree. An awful lot would have to change quickly (including buying habits) for any kind of major shift in the near term. But AMD seems to be positioning themselves nicely for the future if they can keep the momentum going.
 
Hardware isn't the performance bottleneck it was at one time, but if people aren't buying lots of 8/10/12 core chips, then we won't get a lot of software development to take advantage of the extra horsepower.

The funny thing is that if more people had chips that with more cores,then more software would be written to use them. As it is, software designers are limited by the lowest common core count in order to get the biggest market share. They can't write software for 6-core machines when most folks are on 4 core.

Maybe I just restated what was already said... :)
 
I can see Intel being ballsy enough to throw away market share because they don't think AMD will ever fully catch up to them. They'll give up that market share, keep their prices the same save for maybe $20, and that'll be that until AMD drops their next gen.

 
The funny thing is that if more people had chips that with more cores,then more software would be written to use them. As it is, software designers are limited by the lowest common core count in order to get the biggest market share. They can't write software for 6-core machines when most folks are on 4 core. Im seriously, how hard do you think/is it really to have software be core count aware??

Maybe I just restated what was already said... :)
Why not... it would just use less cores. Seriously...how hard is it to code a piece of software to be core aware???
 
Why not... it would just use less cores. Seriously...how hard is it to code a piece of software to be core aware???
The issue is, the program trying to push a workload for a six core CPU to a quad core. I imagine that we'll eventually get to where certain workloads can only be done on a more than quad core CPU. And if software developers code for those multi core CPUs, I think that time will be sooner rather than later.

 
I know what the issue is... and what you said isnt it. Your replies seem to say you believe (all) software has hardcoded the amount of cores, which is patently false... so i ask again...

WHY CANT MORE SOFTWARE BE CORE AWARE???? Use what's available... simple.
 
So what happens when the workload takes hours on a quad core because it has to be spoonfed the instructions bit by bit, whereas a hex or octa core CPU could do it in significantly less time? It's an impractical bottleneck, and one that very few people will want to deal with.

 
So what happens when the workload takes hours on a quad core because it has to be spoonfed the instructions bit by bit, whereas a hex or octa core CPU could do it in significantly less time? It's an impractical bottleneck, and one that very few people will want to deal with.
Simply put, it is what it is... you have a quad and use a program that can use more cores, it takes more time than if you had a hex+. Buy a damn hex if it takes too long...novel idea, ehh? :)

In other words, its the same as it is now, nothing changes.
 
Why not... it would just use less cores. Seriously...how hard is it to code a piece of software to be core aware???
I dont know, but HWMonitor cant /couldn't code for the temp offset on Ryzen chips so I assume that core awareness difficult to implement? One developer couldn't code one offset for one family of chips, so I see no reason to even hope for core awareness across many games or softwares.

In my opinion the extra cores are most likely going to be put into backgrounding power user tasks for the average guy. Basically a system that maintains itself better and automatically. Average users will be in heaven.
 
Programmers are lazy/don't care ?
bingo... its not that it cant be done or is difficult...

I dont know, but HWMonitor cant /couldn't code for the temp offset on Ryzen chips so I assume that core awareness difficult to implement? One developer couldn't code one offset for one family of chips, so I see no reason to even hope for core awareness across many games or softwares.

In my opinion the extra cores are most likely going to be put into backgrounding power user tasks for the average guy. Basically a system that maintains itself better and automatically. Average users will be in heaven.
not sure what temp offset has to do with being core aware...

There is software out there already which scales to the number of cores available automatically.... how about any stress test where you dont manually input core #? Think about it.......(and look at kenrou's statememt again). P95... IBT...OCCT...Linx...Linpack...AIDA64... outsode of a64 and ibt, these arent multimillion dollar companies pumping millions into dev and they did it.....

:)
 
Last edited:
I didn't say it was hard or impractical, I just said software has historically been late to the 8+ core desktop party. I can't code so I have no idea why that is, but it is.
 
My comment about the offset was just to illustrate how things that seem simple or reasonable will be ignored or not implemented by developers. And I think core awareness might be viewed in the same light by other development teams.
 
My comment about the offset was just to illustrate how things that seem simple or reasonable will be ignored or not implemented by developers. And I think core awareness might be viewed in the same light by other development teams.

Proper multi threaded programming is definitely a bit more difficult than single thread stuff, but by no means is it terribly difficult. Being core aware in terms of looking at a machines avaible threads is simple as polling the system for the info, and then auto configuring to utilize X treads. Now not all workloads can be multithreaded, but alot can, and you can certainly spin other sets of work out of the main thread to ensure it doesn't waste time.
 
The funny thing is that if more people had chips that with more cores,then more software would be written to use them. As it is, software designers are limited by the lowest common core count in order to get the biggest market share. They can't write software for 6-core machines when most folks are on 4 core.

Maybe I just restated what was already said... :)

My comment about the offset was just to illustrate how things that seem simple or reasonable will be ignored or not implemented by developers. And I think core awareness might be viewed in the same light by other development teams.
Fair enough... also a fair bit different than the original statement. :)
 
Proper multi threaded programming is definitely a bit more difficult than single thread stuff, but by no means is it terribly difficult. Being core aware in terms of looking at a machines avaible threads is simple as polling the system for the info, and then auto configuring to utilize X treads. Now not all workloads can be multithreaded, but alot can, and you can certainly spin other sets of work out of the main thread to ensure it doesn't waste time.
I mean, games that automatically set their own recommended settings are doing this in a way anyways. But I don't think developers would care about it enough to take it any further than that.

 
There is software out there already which scales to the number of cores available automatically.... how about any stress test where you dont manually input core #? Think about it.......(and look at kenrou's statememt again). P95... IBT...OCCT...Linx...Linpack...AIDA64... outsode of a64 and ibt, these arent multimillion dollar companies pumping millions into dev and they did it.....

We have to be a little careful here. It is different running one single task on multiple cores, as opposed to separate tasks one on each core. One task on multiple cores is more difficult than multiple separate instances. P95 can do both, but in stress test I think it picks separate tasks per core. Linpack is used to rate supercomputers so if anything it going to scale, it will be that.

Even the P95 implementation of running multiple cores isn't perfect. I think I saw it described by its writer as splitting things up into blocks, firing them out and waiting for them to come back. There is a degree of work that can be split so that it isn't then dependant on something another core is working on. In my testing it scales well for "bigger" work, but for "smaller" work, it still provides less than ideal speedup, so you can go faster at the cost of lower throughput than compared to running multiple single threads. It doesn't seem great at high thread counts either. I see loading drop below 100% once cores go above around 8 or so. This leads to a weird situation where it is known that HT provides no benefit for this type of work, but in this case it can help mask the inefficiency of high thread count scaling.
 
Back