First, where did you read the word "exclusively"? I cannot find it in anything that I wrote.
x86 is too complicated an arch to be emulated, so this would force an x86+ARM config, which defeats the purpose of going ARM in the first place (power).
Second, Windows also runs on ARM. Nvidia expects a RT+ARM future.
Windows RT, which has zero compatibility with legacy Windows apps. And those apps are the reason people use Windows.
Third, Windows is a minority OS and Microsoft has shown that no longer drives the PC market. AMD announced that abandon Windows exclusivity, and Intel has announced the same at IDC. I gave the link a pair of posts ago. Intel is joining with Google.
Windows drives the market though market share. Linux hovers around 2-3 percent, OSX at 10. It's the lead development platform for that reason.
That being said, Android and OSX [if unified with iOS, as far as running apps go] has a chance of taking significant share away from Windows. But not Linux.
The FX 4000 line will be discontinued, I can promise you that. It has no reason to exist. For like $10 more you can get 50% more cores. And it actually hurts AMD's plans for HSA adoption, as people who buy FX 4000 series are buying into a platform which doesn't support HSA as opposed to an APU that has HSA. FX 4000 series is directly competing with APUs while FX 4000 series harms AMD's HSA push.
Binning. That's why the 4xxx series exists. That being said, its stuck between APU's, i3's, and the 6xxx series, so AMD needs to do SOMETHING with it.
What the hell are you trying to say? Are you implying that there's also no difference between Intel Dual, Intel Quad and Intel Hex as an i3 is just fine in a single core game?
You do see gains going from i3 to an i5 at the same speed, so its clear that i3's, at current clocks, are very close to being overburdened. It's worth noting though: They remain faster on average then any FX chip under 4GHz.
http://translate.google.com/translate?act=url&depth=1&hl=en&ie=UTF8&prev=_t&rurl=translate.google.com&sl=auto&tl=en&u=http://pclab.pl/art50000-12.html
In games, on average, the i3 3245 @ 3.4GHz is 4% faster then the FX-8350 @ 4GHz. That's AMD's problem: For games, i5's do command a price premium, and cheaper i3's offer more performance in *most* titles at a cheaper price. I'd still be REALLY interested in a 4Ghz i3...
You remind me of the people I used to talk to before dual core CPUs existed. I said back then "it'd be so cool to have a dual CPU system" and they all laughed, going "nothing will use both CPUs it's a total waste and it always will be."
And I was here, calling those people out. Even then, games used two heavy threads: The main program thread and the primary render thread. So there was an obvious need for duo cores. Beyond that however, focusing on games, you simply do not get much better scaling, because you have multiple threads touching the same objects in memory. And if two threads touch the same object, they can not run at the same time. THAT'S your bottleneck, and who most games, while using 50+ threads, use all but 2-3 for VERY simple tasks.
Now, if you build a single core CPU system now, you're a joke. Coincidentally, at that very same time, Intel was talking about 10ghz Nehalem Pentium chips (the old Nehalem that got cancelled, not LGA1366) and there was a massive wall of FUD on the internet about how multiple cores was a complete waste and we'd have 10ghz Pentiums soon.
I'm going to say this again: If you could clock to infinite speeds, a fast single core will ALWAYS outperform a CPU with any number of cores at a slower speed. But when you have Duo's and Quad's running at the same speed, the Quad will always be at least as good as the duo. That does NOT imply you will see performance gains, however.
And if you remember correctly, AMD made multiple core CPUs back in the day, and now everyone has a CPU with more than one core. Christ, you have to dig pretty deep to buy a CELLULAR PHONE with a single core.
And DEC and dozens of other companies were making systems with multiple CPU's back in the late 60's. PS: They all abandoned those ideas or went bankrupt.
Seriously, do you think we haven't tried multiple CPU's before? We tried in the late 60's and early 80's. And every single time we ran into the same problem: To make the software multiple thread safe, you had to use so much synchronization that you lost almost all the performance gains of using multiple cores to begin with. Some tasks scaled well, and today, those tasks are computed (or co-computed) on the GPU.
The rule for threading is simple: If you have a block of code that touches the same object in memory, you do not thread. If not, then you do. And if you do a bunch of serial processing on a single object in memory, guess what? You can't thread, as it costs you performance to do so.
I've lived through this so many times already. "TWO CORES IS STUPID", "FOUR CORES IS STUPID", "8 CORES IS STUPID". How many times are we going to go through this before you realize that this is the only way to scale x86 CPUs now and that single thread performance gains are DEAD. You're basically advocating that the past is going to be different this time because of reasons that everyone else said in the past and were wrong about. And you're probably all frothing at this ready to go "BUT IM A GAME DEVELOPER!!!! ZOMG LOOK IM AN AUTHORITY ON THE SUBJECT!!!!"
Single core performance gains are alive an well; see an i3 @ 3.4 beating an 8350 @ 4.
Again:
YOU CAN NOT THREAD IF THE THREADS IN QUESTION TOUCH THE SAME OBJECT IN MEMORY. Synchronization kills performance gains, essentially forcing you back into serial processing. The stuff we can thread: Rendering, Physics, etc, we do, by offloading to a processor specially designed to handle those workloads.
Your fallacy is thinking only of the CPU. That hasn't been the case for 20 years. The GPU is where the bulk of the workload is being done, and where most of the workload is being handed off to. Stuff that threads well tends to thread VERY well, thus leading to more efficient processing on the GPU, not the CPU.
I mean really, you whine all day long about how it's IMPOSSIBLE for all this sharing of memory to happen, and look: http://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions
No it hasn't, you simply don't understand the downside to Transactional memory.
Transaction memory works on this premise: I'll do the processing, and if the memory contents I started with haven't been modified, then I know some other thread hasn't gone in and used that data, and thus it is safe to overwrite.
The downside, however, if the memory HAS been overwritten, is huge: You have to disregard the processing you just did, put a traditional locking mechanism in place, and do the processing
ALL OVER AGAIN. At minimum,
a 100% loss in performance for that code block, more if some other thread ends up getting locked out while you are re-doing a lot of your processing.
So here's my question: Would you go for this if you would constantly be jumping between 45 and 10 FPS in a game when this happens, or would you prefer the constant 35 FPS?
Transaction memory works well when the length of the period where the memory is normally locked is small. In that case, the times you have to re-do processing is insignificant to the gains you get by removing synchronization. In short: The 10% of times you need to re-do processing is less then the performance loss of ensuring you compute the output correctly the first time. Databases are a VERY good example of something which would benefit from Transactional memory. Games are not.
So how about actually understanding the subject matter before commenting on it?
Facebook
Twitter
Instagram