CPU workarounds?
IronHorse
Developer, QA Manager, Technical Support & contributor Join Date: 2010-05-08 Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
Hey, first off: GREAT job, guys! been playing a lot lately and its tons of fun, the patches have made giant strides in all areas, thank you for delivering.
just a quick, possibly silly question:
anyone find a decent method to increase the CPU utilization? I've been testing around with some things and have noticed a CPU bottleneck occurring with my i7 920 OC @ 3.2ghz.
I know its been said before that there still needs to be some optimization but i was wondering if anyone found any temporary workarounds for increasing the usage of multiple cores? setting priority/affinity doesn't seem to make any difference, neither does windowed mode etc. anyone found anything that helps?
just a quick, possibly silly question:
anyone find a decent method to increase the CPU utilization? I've been testing around with some things and have noticed a CPU bottleneck occurring with my i7 920 OC @ 3.2ghz.
I know its been said before that there still needs to be some optimization but i was wondering if anyone found any temporary workarounds for increasing the usage of multiple cores? setting priority/affinity doesn't seem to make any difference, neither does windowed mode etc. anyone found anything that helps?
Comments
[edit]
Heh and of course this post was useless :D
Max is a<!--sizeo:1--><span style="font-size:8pt;line-height:100%"><!--/sizeo--> very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very ver<!--sizec--></span><!--/sizec-->y busy man these days, so poking him might not have the desired effect :P
yea, hmm.. alright well i'll just be patient then. :)
They should sign up for one of those reality TV shows and max should morph into "max headroom" and twitch and stutter allot.
I have seen this come up may times i from what i understand it the multi-core processes where only so the server would run on a different core than the game but i could be wrong.
You need to have a fast single core (I'm not saying a single-core processor) to run NS2 quickly.
You need to have a fast single core (I'm not saying a single-core processor) to run NS2 quickly.<!--QuoteEnd--></div><!--QuoteEEnd-->
which... really sounds counter intuitive if this was in fact their finalized goal in this area? i should hope not with multiple cores being the standard for today's gaming. a lot of unused resources right there.
I'm sure they're well aware of this though and have plans. just curious for any tweaking in this area. but i suppose its all code.
Essentially all games are multithreaded; this was true even when 99% of home users only had single core processors. Optimizing a game to take advantage of multiple cores is a very different proposition than just spinning off networking and a few other things into their own threads.
<!--quoteo(post=1817328:date=Dec 19 2010, 03:58 PM:name=Jiriki)--><div class='quotetop'>QUOTE (Jiriki @ Dec 19 2010, 03:58 PM) <a href="index.php?act=findpost&pid=1817328"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Even if all your cores are running the same thread, they cannot execute code simultaenously but in serial.<!--QuoteEnd--></div><!--QuoteEEnd-->
Well yeah; splitting a serial task across multiple threads won't help, which is exactly why its hard to make good use of many cores. Often you would have to redesign an algorithm to be more ammenable to parallelization.
Note that you'd have to do some serious profiling of NS2 to find where the bottlenecks are, and they are often not where you think. Paralellism is not necessarily the best or easiest way to increase performance.
Well yeah; splitting a serial task across multiple threads won't help, which is exactly why its hard to make good use of many cores. Often you would have to redesign an algorithm to be more ammenable to parallelization.
Note that you'd have to do some serious profiling of NS2 to find where the bottlenecks are, and they are often not where you think. Paralellism is not necessarily the best or easiest way to increase performance.<!--QuoteEnd--></div><!--QuoteEEnd-->
It's the only way. :P After you're done with optimizing serial code (UWE has lot to do here) the only thing you can do is to parallelize it. It's not the parallelism/concurrency that's hard it's getting rid of assumptions from serial version.
Only things that Source 2009 runs properly in parallel are particles and queueing draw calls. That alone gives huge boost so UWE might want to do that. Well at least if/when LuaJIT has locks/threads and all these synchronization/sharing utilities.
Only things that Source 2009 runs properly in parallel are particles and queueing draw calls. That alone gives huge boost so UWE might want to do that. Well at least if/when LuaJIT has locks/threads and all these synchronization/sharing utilities.<!--QuoteEnd--></div><!--QuoteEEnd-->
id like to see interaction of physics more offloaded to the GPU or another CPU core.. not ragdolls, but whatever causes slow downs when theres more than one person in a well developed base..
Not necessarily, no.
<!--quoteo(post=1817583:date=Dec 20 2010, 02:53 PM:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant @ Dec 20 2010, 02:53 PM) <a href="index.php?act=findpost&pid=1817583"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->:P After you're done with optimizing serial code (UWE has lot to do here) the only thing you can do is to parallelize it. It's not the parallelism/concurrency that's hard it's getting rid of assumptions from serial version.<!--QuoteEnd--></div><!--QuoteEEnd-->
If it's not well-profiled and optimized yet it's possibly a lot easier to make big performance gains by just finding where the hotspots are and optimizing that code rather trying to adapt the algorithm and reimplementing the hotspots with multithreading.
By the time you reach satisfactory performance you may not have needed to exploit much parallelism to get there.