I don't care about task manager load graphics,
I have seen plenty of benchmarks and played plenty of Arma 2 to say, the game is mostly using 2 cores, and does not show clear performance improvements with more cores (more than 3), it shows with IPC, clock, cache... whatever.
Goal and Means
It is important not to lose the sights from the goal, which is the performance increase. All other things are secondary. One example of wrong metrics is a concurrency level. Concurrency level tells us how much are the additional cores used. This factor is very easy to measure (you can do it in default system task manager), and that is probably why many hard core end users and reviewers are interested about it. Often you can see phrases like "Game XXXX is using quad cores very well, because when you watch CPU usage in task manager, you see all cores are running 100 %". It is very easy to create a trivial program which will make "full use of all cores" - all you need to do it to spawn a few threads and make them spin in an infinite loop. Concurrency is not a goal, only a mean. It is required, but not sufficient. Real life scenarios are more intricated then idle loops, but the principle is the same: using CPU does not mean you get any benefit from using it. In many cases the overhead of going "threaded" is so high that even when two cores are running 100 %, the performance improvement is very small, say about 20 % from single core, and the difference between quad and dual is even smaller.
Conclusion
ArmA 2 gets following improvements from running on a dual/multi core:
- improved rendering performance
- smarter AI
- larger scenes possible (higher view distance, more objects in view, more AI units) with little performance drop, especially on multi core machines
I don't care what you think you have seen, when the devs are quite clear themselfes:
http://www.bistudio.com/english/company/developers-blog/91-real-virtuality-going-multicore
My bet is that a lot of people posting in this thread suffers from the Concurrency -syndrome...due to limited understanding of game engines.
again,
I care about actual real world performance not about task manager or a blog post.
here you can see the gain from the PII X3 at 2.8GHz to the PII X4 at 2.8GHz is small
http://www.pcgameshardware.com/aid,687620/ArmA-2-tested-Benchmarks-with-18-CPUs/Reviews/
the gain from 1 to 2 cores is huge.
as I said, the game is old, BI is small company with limited resources, they made this game when most of their user base had 2 cores available, and some had 4,
a newer benchmark,
http://i42.tinypic.com/vyxe0x.png
what can we see here? the game suffers a lot less from "less cores" than with lower per core performance,
there are games the scale way better with more than 3 cores.
so I don't really understand why you brought Arma 2 to this topic, this is relevant for Arma 2, which is a single game.
I was right...you suffer form the concurrency-syndrome.
But you benches do show I was right:
please explain, right about what? I was wrong about what?
the benchmarks show that the game doesn't benefit much from more than 3 cores.... which is what I said...
but that's Arma2, a single game.
Really...first you dismiss Taskmangers CPU load metrics..a.nd now you try and use it?
Make up your mind...can se use it or not?
And why do you keep on ignoring my link?
BI devs post > your post...sorry to say.
I'm sorry, but where am I trying to use "task manager CPU load metrics"?!
again, please explain, you are right about what exactly? and what is the relevance of arma 2 to this topic?
was Arma 2 developed for a fixed spec hardware with 6-8 x86 cores like future console games will? or for PCs with mostly 2 cores from 2009 by a small company with limited resources (compared to Epic, EA or something)?
this game is showing almost no gains with CPUs with more than 3 cores, but huge gains with more than 1 core... which is... irrelevant? because it's only a single game, and other games can show bigger gains.
I'm a developer. I've done multithreaded programming, yes there is performance overhead. In general it's hard to do right but if you do it right- using the right tools, you will not see a loss of performance, nor a ton of overhead. If done right (which isn't easy with today's tools, but they will improve) the performance gain will outweigh the overhead even today. That's why most enterprise game engines are multithreaded already to an extent.
The tooling is only going to get better as there's an increasing incentive for it to get better. As of the PS4/XB1, it's a major marketplace advantage to have the better multicore engine. So I wouldn't just off the past, the gap is only going to widen. Combine that with the engines being specifically tuned for AMD's arch and you have a real problem on your hands (if you don't like AMD that is..)
Post #226:What is concurrency syndrome?
It is important not to lose the sights from the goal, which is the performance increase. All other things are secondary. One example of wrong metrics is a concurrency level. Concurrency level tells us how much are the additional cores used. This factor is very easy to measure (you can do it in default system task manager), and that is probably why many hard core end users and reviewers are interested about it. Often you can see phrases like "Game XXXX is using quad cores very well, because when you watch CPU usage in task manager, you see all cores are running 100 %". It is very easy to create a trivial program which will make "full use of all cores" - all you need to do it to spawn a few threads and make them spin in an infinite loop. Concurrency is not a goal, only a mean. It is required, but not sufficient. Real life scenarios are more intricated then idle loops, but the principle is the same: using CPU does not mean you get any benefit from using it. In many cases the overhead of going "threaded" is so high that even when two cores are running 100 %, the performance improvement is very small, say about 20 % from single core, and the difference between quad and dual is even smaller.
Post #226:
Well written applications do not spin in a loop unless they need very short service times. I understand what that Arma 2 developer was saying, but it's a facetious example he has given.
Task manager doesn't say everything about what is going on. It's entirely possible to have a CPU running at 70% because the system is memory bandwidth limited, or waiting on IO to the GPU, etc.
That said, it's kind of silly to say that developers are not going to move towards multi-core in a big way. That is going to happen even without the consoles, simply because single core performance increases are becoming minuscule.
This has been a long time in coming but it seems that it is here now.
Dr Dobbs from 2004, a famous article titled "The Free Lunch is Over", which predicts the decline of single CPU performance increases and the importance of multithreaded / concurrent applications in the future :
"CPU performance growth as we have known it hit a wall two years ago. Most people have only recently started to notice."
"Starting today, the performance lunch isnt free any more. Sure, there will continue to be generally applicable performance gains that everyone can pick up, thanks mainly to cache size improvements. But if you want your application to benefit from the continued exponential throughput advances in new processors, it will need to be a well-written concurrent (usually multithreaded) application."
"Applications will increasingly need to be concurrent if they want to fully exploit continuing exponential CPU throughput gains
Efficiency and performance optimization will get more, not less, important"
http://www.gotw.ca/publications/concurrency-ddj.htm
Single core performance hit a wall 2 years before 2004? That would be 2002. Seems to be coming true now, but it was hardly true in 2002. That was even before the Core architecture.
source
Matt Higby, creative director of Planetside 2, tells us how game engine optimization on PlayStation 4 will ultimately benefit PC gamers using AMD processors:
"The big challenge with the PS4 is its AMD chip, and it really, heavily relies on multi-threading. We have the exact same kind of Achilles heel on the PC too. People who have AMD chips have a disadvantage, because a single core on an AMD chip doesn't really have as much horsepower and they really require you to kind of spread the load out across multiple cores to be able to take full advantage of the AMD processors."
"Our engine sucks at that right now. We are multi-threaded, but the primary gameplay thread is very expensive. The biggest piece of engineering work that they're doing right now, and it's an enormous effort, is to go back through the engine and re-optimise it to be really, truly multi-threaded and break the gameplay thread up. That's a very challenging thing to do because we're doing a lot of stuff - tracking all these different players, all of their movements, all the projectiles, all the physics they're doing."
"It's very challenging to split those really closely connected pieces of functionality across in multiple threads. So it's a big engineering task for them to do, but thankfully once they do it, AMD players who've been having sub-par performance on the PC will suddenly get a massive boost - just because of being able to take the engine and re-implement it as multi-threaded."
"I'm very excited about that because I have a lot of friends, lots of people who are more budget minded, going for AMD processors because nine times out of ten they give a lot of bang for the buck. Where it really breaks down is on games with one really big thread. Planetside's probably a prime example of that."
---
*Note: Both Playstation 4 and XBox One basically use the same AMD computing unit with some tweaks on each side. This means that all console ports enjoy the full benefits as mentioned in the article.
Good, this helps everyone, including Intel CPU users.
Single core performance hit a wall 2 years before 2004? That would be 2002. Seems to be coming true now, but it was hardly true in 2002. That was even before the Core architecture.
On the contrary, he nailed it before most people noticed it, which is why it is a well respected article. Advancements post P4 have been quite slow.
Before you laugh at a P4, keep in mind that was 12 years ago. In a previous age, we went from a 4Mhz 8088 to a 60Mhz Pentium in 12 years (1981-1993).
You could still run WinXP and do common tasks with a P4 today.
A 4Mhz 8088 was a doorstop in 1993, after the same 12 year period.
Look at the inflection point on these graphs :
http://preshing.com/wp-content/uploads/2012/02/float-point-perf.png[img][/QUOTE]
I don't know why it really matters, but the average increase for the second part of the graph is still 50% of the rate for the first part, which in my mind does not meet the definition of "hitting a wall". That would seem to me to be more like sb to haswell, with only a 10 to 15% increase over a 2+ year period. If you extended the graph to 2013, you would see almost a plateau for that period, which is what to me indicates "hitting a wall". In any case, it seems pointless to continue to argue about a 10 year article. I was just trying to point out that most people did not feel unhappy with the trend of CPU progress until after sandy bridge.