Question on future performance
AlphaWolf
Join Date: 2003-01-11 Member: 12175Members
Join Date: 2003-01-11 Member: 12175Members
I'm noticing that for both dedicated servers and pure clients, the game uses at most two cores, maxing out one and making little use of the other. Does UWE plan on changing this? That is, utilization of more cores (all of my systems have four) or at least better distribution of work to the second core?
Comments
Which is pathetic. This isn't 1989.
Gives me hope my old single core 3.6gigahertz CPU might be worth reviving after all
Hi AlphaWolf;
i have two core 3.0 processor and game before the patch all detail is full i taking 77-80 fps and after the last patch i taking 91-95 fps with same graphic setup...
this last patch is the bestest perfect performance patch i guess. developers fixing the ns2's performance problem.
really perfect performance patch.
ty to developer/s...
An ideal lua-based system wouldn't put any of the core programming in Lua...it would just try to give it the parts that might change often, while the heavy load is handled by the other cores and the engine itself. I don't know how effective this engine is at that sort of thing...
Well I'm not *that* concerned about the client (mine runs at a higher FPS than I even need) but I was looking at setting up a server, and it looks like even high end server hardware will struggle to keep a decent tick rate for high pop.
I've got a xeon 3470 3.0ghz server (not cheap) on my hands, and from what I'm able to determine (based on reports from others) it isn't ideal for anything more than 12 players. Unless the reports are wrong? They are over a few months old (pre-release.)
I think they could win much performance in profiling the code in late game and translate the functions that create the most load into the c++ part of the engine.
It can be annoying, but I have faith in those who made their own engine for a game.
They could use Haskell for easy parallelization, it can be interleaved with C code.
<a href="http://an.davidsirritation.com/NS2.png" target="_blank">NS2 on several cores</a>
*Edit: I realize I'm not showing up to core 7 but that's because it won't fit on the screen
<a href="http://puu.sh/1HfWt" target="_blank">http://puu.sh/1HfWt</a>
You can expand the frames using the "views" dropdown. Here is the second screen on my monitor with my i7 3770k running at 4.2ghz, getting about 80 average ingame in a 18p server.
There's no way to parallelize game computations. A render thread and a logic thread, that's what you're seeing and what you'll see in 99% of games.
I've got a xeon 3470 3.0ghz server (not cheap) on my hands, and from what I'm able to determine (based on reports from others) it isn't ideal for anything more than 12 players. Unless the reports are wrong? They are over a few months old (pre-release.)<!--QuoteEnd--></div><!--QuoteEEnd-->
The thing is that during beta as mentioned by Davil, the good servers are still the ones that are running on a single thread (multiple servers that way ;), on overclocked i5's and i7's Sandy or Ivy bridge, running at 4.2+Ghz. Those servers can easily handle 18 players at a constant 30 ticks. I've not played much on 20-24 player servers, not because of performance, but because of balance (maps too small, teams not scaling and such). SO I don't know for sure if this uber rigs can run at least at 28+ticks at a constant rate.
You simply need that amount of Ghz to get a server running smoothy, anything below that magic 4.2Ghz mark is asking to be run at only 12 players afaik...
I've got a xeon 3470 3.0ghz server (not cheap) on my hands, and from what I'm able to determine (based on reports from others) it isn't ideal for anything more than 12 players. Unless the reports are wrong? They are over a few months old (pre-release.)<!--QuoteEnd--></div><!--QuoteEEnd-->
The thing is that during beta as mentioned by Davil, the good servers are still the ones that are running on a single thread (multiple servers that way ;), on overclocked i5's and i7's Sandy or Ivy bridge, running at 4.2+Ghz. Those servers can easily handle 18 players at a constant 30 ticks. I've not played much on 20-24 player servers, not because of performance, but because of balance (maps too small, teams not scaling and such). SO I don't know for sure if this uber rigs can run at least at 28+ticks at a constant rate.
You simply need that amount of Ghz to get a server running smoothy, anything below that magic 4.2Ghz mark is asking to be run at only 12 players afaik...
There's no way to parallelize game computations. A render thread and a logic thread, that's what you're seeing and what you'll see in 99% of games.<!--QuoteEnd--></div><!--QuoteEEnd-->
Not true, it depends on the game. Very very very very very few are actually optimized for it though. The only actual example I can think of is Flight Simulator X and Witcher2 that will use all 4. Most other games end up using 2 or 3, BF3 uses 2, Skyrim 2, Bulletstorm 3, Crysis 2 uses 3 on high settings. So no not true at all.
Well Bioshock, which is a bit older uses a lot of multithreading according to their lead programmer:
- simulation update (1 thread)
- UI update (1 thread)
- rendering (1 thread)
- physics (3 threads on Xenon, 1 or more on PC)
- audio state update (1 thread)
- audio processing (1 thread)
- texture streaming (1 thread)
- file streaming (1 thread)
Also, the operating system has a lot of influence on how threads get divided onto each available cpu core. Windows XP for example had quite a lot of problems with more than 2 CPU cores.
Multithreading a game still is a pain, as there are so many systems that depend on each other and some even will fail or cause big stalls when they do not get their result in time or before another process wants to run that depends on the one waiting.
- simulation update (1 thread)
- UI update (1 thread)
- rendering (1 thread)
- physics (3 threads on Xenon, 1 or more on PC)
- audio state update (1 thread)
- audio processing (1 thread)
- texture streaming (1 thread)
- file streaming (1 thread)
Also, the operating system has a lot of influence on how threads get divided onto each available cpu core. Windows XP for example had quite a lot of problems with more than 2 CPU cores.
Multithreading a game still is a pain, as there are so many systems that depend on each other and some even will fail or cause big stalls when they do not get their result in time or before another process wants to run that depends on the one waiting.<!--QuoteEnd--></div><!--QuoteEEnd-->
There's a big difference between cores and threads. A thread is run on a core, more or less a core is like the factory and the thread is like the conveyor in/out of the factory. If you have a ton of conveyors but now much production nothing will come out, similarly if you have tons of production but no throughput the factory(core) is waiting to send things out.
1) You can split up <b>different, independent tasks</b> into different threads; you'll have networking in one thread, sound processing in another, particle simulations in another etc. This will not give a big speed up and it doesn't scale to more cores because most of the heavy tasks have to occur in a specific order.
2) You can "pipeline" dependent tasks and run them at the same time. E.g. You are rendering the current frame, calculating the physics for the next frame and doing the game logic for next next frame. This promises big speed ups, but it introduces horrible input latency and responsiveness issues and it doesn't scale to dozens of cores.
3) You can parallelize the individual tasks. E.g. a hydra is dependent on the player positions having been updated(unless you cheat and use last frame's) but it is not dependent on other hydras; you can sort objects into a couple of buckets within which gamelogic for objects is independent and can be run in parallel. This often doesn't work because there is a overhead associated with splitting up a task across many threads, if the task is too small it's not worth it.
#3 is still the most promising because there are two important changes happening, games are becomming more complex(=more stuff that can run in parallel) and context switching overhead keeps getting smaller with each new generation of CPU. This is most common way games on the PS3 use the cell processor, even if it is a pain in the ass for programmers(it's even worse, SPEs are in-order, deeply pipelined and balanced towards SIMD).
It's usually the other way around, at least when it comes to super computers and very consciously so.
Amhdahl's law gives you the expected speed up when some fraction of the time is spent in code that is sequential and not easily parallelized. Battling Amhdahl's law is hard.
Gustafsson's law in effect tells you that you can always make a problem easily paralellizable by adding more stuff that is easily parallelizable, so that the sequential fraction becomes smaller. You're making the problem much bigger, but you'll use your extra computing power efficiently. This is much easier; first you figure out what can easily be done in parallel, then you figure out how to cram more of that into your games in a way that is interesting to the player; you don't achieve a speed up in the frames per second sense, but you can churn through more work per frame, which hopefully provides some value to the player.
i have two core 3.0 processor and game before the patch all detail is full i taking 77-80 fps and after the last patch i taking 91-95 fps with same graphic setup...
this last patch is the bestest perfect performance patch i guess. developers fixing the ns2's performance problem.
really perfect performance patch.
ty to developer/s...<!--QuoteEnd--></div><!--QuoteEEnd-->
which graka, which resolution, what ingame graphic settings?
wanted it to be a PM, sry forum :/
That's what I meant with 99%. Logic + render + AI (if applicable) is the standard setup.