Is The Game Coded For Multiple Cores?
rmbrown09
Join Date: 2012-10-17 Member: 162592Members
Join Date: 2012-10-17 Member: 162592Members
The answer here is yes, but I am wondering how many cores is the game coded to take advantage of? Many of us are rocking hyperthreaded i7's that run a total of 8 logical cores. A potential improvement in performance could be had chugging all that Lua by using every single core. Some people are probably even using 2011 series 6 core, 12 hyperthreaded CPU's. Haswell is around the corner and we will only see the core count go up.
Just want to make sure that at minimum this game is taking advantage of all 4 cores, hopefully 8 if they are available. I don't know if the answer is something that can be derived from the game code or if someone from UWE will respond. Thanks either way.
Just want to make sure that at minimum this game is taking advantage of all 4 cores, hopefully 8 if they are available. I don't know if the answer is something that can be derived from the game code or if someone from UWE will respond. Thanks either way.
Comments
That said most games these days only provide a fps boost within the margin of error when going from 2 to 4 cores, so I think it's kinda harsh to expect a indie dev team to overcome this challenge.
Games are in a select few cases, like perhaps AI and physics, but other than that it is all very sequential, and very interdependant, which means you can't get respectable speed-ups from multiple cores.
No games use 8 cores. If it was that easy, games would be running exclusively on GPUs.
Almost certain that (at the moment) NS2 is using one core for the vast majority of work (the primary processing thread), and offloading what it can to a secondary. Which isn't much. Task scheduling takes an immense amount of work, testing, and planning to get right.
Saying 'use multiple cores to improve performance' is about as helpful as saying 'press the jump button!' when watching someone play a video game. They know. It's just not that simple.
What you're describing is more akin to doing a brutality in MK3.
Take all the slow Lua code, and compile it to something faster like C. There are Lua to C converters as far as I can tell all over. I understood one major reason they use Lua is because it is more easily moddable. But you could construct or implement a Lua to C converter in the game so that you can edit in Lua and then it is transformed to C with the converter when you're done.
Something like this, just build it into the game: http://lua-users.org/lists/lua-l/2008-08/msg00004.html
My flame shield is ready I stand not afraid.
Does that say 25-75% performance of LUA?
Yep. This would just make performance worse.
The engine is already coded as a native compiled binary, and is essentially (sort of) a realtime version of the software rmbrown09 had linked, but with better performance.
It also doesn't address the multicore question which was the original intent of this thread, and would not farm it out to multiple cores.
I was just linking the first one I found to show the potential for the idea. I feel like if UWE or someone made a converter that would take Lua code and allow it to perform at C speeds things would run much better seeing as how the game logic is the biggest burden.
Multithreading is awful. It's akin to programming with Zerg swarm logic.
Here's a simple example:
Master: "Go! Bring me three apples!"
Threads: "Does he have less than three apples?"
Master: "Yea"
(All available threads go get apples at the same time and dump them back on Master's lap)
Master: "I have 5 apples. What the hell, guys?"
Threads: "Well there are 5 of us and you had less than 3 apples when we started. We don't care or know what the other guys are doing!"
Master: "God dammit, now I have to micromanage you morons. Only go get apples one at a time for now on!"
Threads: "But then how can we be fast like threads are supposed to do??!"
For the most part, none of the whips need to know anything about the others, so their checks can be done in parallel. Is this the way the game logic currently works? From a quick google, it does seem LUA supports some form of rudimentary threading.
The NS2 server runs on about 1.05 cores, while the client runs the logic in one thread and the renderer in another; if you get bad fps, its usually the logic thread that slows things down.
I genuinely want to know what is the difference and (or dis) advantages between codes like C, lua, and other computer languages?
Luckily Hugh wrote an article a long time ago for the rest of us plebs who do not understand jack about coding
http://www.ns2hd.com/2012/04/performance-where-is-it-now-and-where.html
The parts that answer your question:
"Lua is 'high level' programming language. Imagine a spectrum. On one end of the spectrum is ones and zeros, or 'Binary' code. This is the language that your PC speaks. Every calculation it makes is done in Binary. At the other end of the scale is the English/French/German/other spoken language. This is what you use to communicate with other humans, and can most readily understand. Programming languages act as intermediaries between Binary and our spoken human languages, so that we can tell computers what we want them to do.
A 'high level' programming language sits further towards the English/French/German end of the spectrum, while a 'low level' programming language sits further towards the Binary end of the spectrum.
Lua sits very far towards the spoken language end of the spectrum. It is very easy to understand, and that is why I was so easily able to create my little spectator mode mod. Natural Selection 2 is entirely written in Lua, so that people can modify it very, very easily. It can be modified with a simple text editor such as Notepad, and does not need to be 'compiled' before it can be executed.(roughly, to compile a program means to prepare it to run, and takes time).
In fact, it is perfectly accurate to call Natural Selection 2 a mod of the Spark engine. Spark is the in-house engine developed as the brain-child of Max 'm4x0r' McGuire. Spark is written in C++, a fast low level language. NS2 sits on top of Spark, written entirely in easily accessible Lua. It is possible to mess with the game without ever having to deal with the C++ engine.
So far, this sounds really cool. Why don't all games run in languages like Lua, on top of low level language engines? Let's go back to the spectrum. The further a language is towards the Binary end, the faster it runs on your computer. The further it is towards the spoken language end, the slower it runs on your computer. This is not to say that Lua is absolutely slow, only that it is relatively slow compared to a low level language such as C++. It is relatively slow because it takes more effort to move all the way from the spoken language end of the spectrum to the Binary end of the spectrum, where the computer can understand and execute the game code.
In summary, Lua trades some execution speed for ease of access, and therefore ease of modding. Not just ease of modding, but ease of writing.
Right now, Lua takes up around 50% of the CPU cycles that NS2 goes through to produce ever frame. This is, on its own, almost entirely responsible for the limited framerates that people experience when playing in the NS2 Beta. Rendering in Spark is actually very fast. This is why turning down graphics options, or playing on a more powerful GPU, yields negligible performance benefits."
Of course it's not in beta anymore so things have improved since then.
Trading programmer time for CPU time and memory usage.
A lower level language like C can but won't necessarily run more efficiently, but is slower and may be more cumbersome at all times but runtime. A higher level language like Lua is slower at runtime and may use more memory but is faster to write, maintain, debug, tweak, test and doesn't need be compiled.
Trying to "convert" code using automated tools is likely useless. I have not even bothered to check, but there's no way the Lua VM and libs aren't already written in C or maybe C++, so why some converter to the very same language it already runs under, that hasn't received as much testing or programmer time would do better I don't know. The code you'd end up with would also be a unreadable mess and using a debugger would be hell.
Rephrase: C runs better but much harder to work with, while lua slower but more user-friendly. This is why 7 dudes in Australia can churn out builds as fast as some big name companies.
I'm currently a computer science major (junior) so I have experience using a decent amount of languages on the scale so far.
But basically the farther from 1's and 0's you get the slower it goes. Actually had a 3 hour lab yesterday writing a program in assembly. (the lowest level language that literally translates what you write into machine code)
Jesus that language is awful. Makes you really appreciate things in Python like: x = "hi"
Learning to program in assembly actually has been the most helpful though in understanding how a computer really truly works at the basic level. For example:
in normal programming languages you can do something like
x = 5
y = 10
z = x+y
So that z ends up being 15 without ever actually explicitly saying yo z, you're 15.
But even simple things in assembly like multiplying by 8 are stupidly hard. At least with what we've learned.
You take the number, and shift its binary value in the register.
In binary numbers are 0 and 1.
0001 is the number 1
0101 is the number 5
0010 is the number 2
In assembly you store the value in something called an accumulator and then perform operations. So to like do the operation 2*8
you would take the binary value of 2, 0010 and shift the most significant bit over left twice to 8: 1000
In assembly the command is LSRA.
So you do that twice and then restore the value in A
looks like:
LSRA
LSRA
STAA
Anyways the whole point here is that low level languages can be freaking hard to do anything in, but are much more efficient if you know what you're doing.
Lua is really far away from binary shifting in the CPU register to do simple steps, but as a result is slower as it needs to get translated to assembly language and then machine code before it is run.
/rant
ret
Yes. Possibly the most important point though is that C code is a whole lot harder and more time consuming to write than Lua.
Ay, I phrased that wrong, I meant as in modifying or changing the code, not a game mod #-o
(I assume) Something like LUA would have no concept of memory management. Its interpreter would simply allocate space when an object came into existence, and deallocate it once that object fell out of scope, or was no longer usable. The process of monitoring when and how to do this, while incredibly useful, isn't free, and doesn't do it in an optimal fashion.
C++ also allows direct access to memory addresses, while essentially all languages of a higher level only expose abstracted references.
Because interpreters and compilers can't handle ambiguity, the way higher level languages handle things like this, while usually adequate, is not optimal.
To get you some examples of HOW powerful Assembler (=most low level programming language) can be: There are festivals where some really talented programmers make Demos (=real time rendered video with nice graphics and sound). http://en.wikipedia.org/wiki/Demoscene
Now, the most astounding thing isn't how nice looking the things are, that they can develop. But that there are categories for down to 1Kbyte. We are talking here about videos with music that are much much smaller than a MP3! This is some real algorithmic magic!
If you want to see for yourself: This is the 3rd place of the Assembly 2010 in the category 64Kbyte
http://www.scene.org/file.php?file=/demos/groups/acceptcorp/ars_nova.zip&fileinfo
(You need DirectX installed. It will render it live on your PC.)
Warning: Some Virus-Scanners have problems with exe-files that use direct memory access in assembler. Some may even delete the files instantly when unpacking.
If you don't want or can't try out the real files, here is a youtube video of this thing: http://archive.assembly.org/2010/64k-intro/ars-nova-by-phantom-lord-accept-corp
But you won't really get the magic when you are not rendering it on your own pc. Seeing this tiny 64kbyte file and what it brings on your screen is really astounding.
Also, this is the 2008 winner at the BreakPoint in the free category (I love that song):
And here is the archive (also with youtube videos) if you are now interested: http://archive.assembly.org/2010/64k-intro
Is there a spark mod which just serves as a tech demo where you can see how much FPS are possible on your system with minimal game logic?
Yes, its called the ready room.
Most game logic and movement code isn't calculated while you are in it. Thats why you get higher fps before you join a team.