Unvanquished Is Rewriting, Modernizing The Quake 3 Engine

[ciplogic]

IIRC, const and restrict usage don't overlap. One is about the variable (either pointer or not), and the other is about the data pointed by the pointer, i.e., if you declare const, you say you will not change the const value, but for a const pointer the data can be modified by other pointers pointing to the same direction. restrict says there is only one pointer to the data, and that's the one declared as restrict. If that's true, the compiler can avoid checking for dirtiness, if I understand it correctly, thus working directly on the cached data.(...)

You're right about the correction.

What I wanted to mean, in a wrong wording, is that people that try to write a fast enough code and look for what language offers for performance, they will put "restrict" everywhere in C, and "const" everywhere in C++.

As restrict is more or less a compiler optimizer hint, about the semantic of pointers that you say you will not break the pointer data by accessing and modifying through other pointer, will reduce (sometimes by a lot) the "load/store" memory accesses.

In comparison the const keyword, if used extensively it doesn't give only a compiler hint for optimizer (which it does), but it also offers code guarantees that no weird stuff happen with your array or whatever you send it by reference (like const reference). This is very useful for common subexpression elimination part, for example in the code:

auto x = data->getX();
x = x+2;
x = data->getX();

If your method is const, the data->getX() result can be hoisted (saved in a temporary variable). This hoisting is even more important if this assignment is in a loop, and the compiler can "proove" that data is not changed throughout the loop body, so it can hoist some of the accesses out of the loop.

In a way is like for simple operations are macros in C vs templates in C++, first is "unchecked" and you do manually write the expansion, the templates are ugly maybe to work with (up-to-the point you get them working) but they are compiler checked.

Being said that, I agree that I wwas not clear about the difference of const and restrict.

[mrugiero]

We're talking about games where code modules can be streamed down from any random server you connect to and run. It basically does the same thing a web browser does in that regard. Any networked game like this without sandboxing (or using a purely interpreted language like most do) should be avoided.

The WTF here is not that they are wanting sandboxed VM, the WTF part is where they think they need anything even remotely close to the PNaCl level of performance. Very large AAA games ship using stock Lua on old consoles with extremely limited resources. I'm all for "make it faster," but only where it doesn't sacrifice some other goals. Using LuaJIt, V8, Mono, Pypy, etc. all provide a much nicer sandboxed modding environment with quite "good enough" performance characteristics. PNaCl is both harder to integrate (meaning the team is wasting more time on irrelevant tech and less time making a better game) and requires a much steeper learning curve to use (reducing the amount of little tweaks and mods that will be available). If actual money were on the line, it would be pure folly.

All of the alternatives you proposed mean rewriting the scripts to another language, which they stated they want to avoid. The "scripts" are actually C/C++ files built on the run, which Quake 3 worked with. That's why PNaCl is the easiest way to keep their sandboxed VM while delegating maintenance of the framework used to run it and avoiding a total rewrite of the game scripts.

[elanthis]

Oh yeah I get that. What I didn't get is why not target the full LLVM. PNaCl seems to use a very specific subset of LLVM; trading off performance for sandboxing.

We're talking about games where code modules can be streamed down from any random server you connect to and run. It basically does the same thing a web browser does in that regard. Any networked game like this without sandboxing (or using a purely interpreted language like most do) should be avoided.

The WTF here is not that they are wanting sandboxed VM, the WTF part is where they think they need anything even remotely close to the PNaCl level of performance. Very large AAA games ship using stock Lua on old consoles with extremely limited resources. I'm all for "make it faster," but only where it doesn't sacrifice some other goals. Using LuaJIt, V8, Mono, Pypy, etc. all provide a much nicer sandboxed modding environment with quite "good enough" performance characteristics. PNaCl is both harder to integrate (meaning the team is wasting more time on irrelevant tech and less time making a better game) and requires a much steeper learning curve to use (reducing the amount of little tweaks and mods that will be available). If actual money were on the line, it would be pure folly.

[mrugiero]

So, let's clarify, C++ will give to you basically the same performance as C with a similar coding style. There is the concept of "zero-cost abstractions" of C++, that if you avoid the word "virtual", you will likely get for the same coding the same performance (this with or without LTO). There are tricks in C (like restrict keyword, which some C devels are using it, but too few C++ that do use it), and there is const in C++. Anyway, the const is a bit more powerful than restrict, in my view, as it give more code guarantees and give more chances for the compiler to optimize.

IIRC, const and restrict usage don't overlap. One is about the variable (either pointer or not), and the other is about the data pointed by the pointer, i.e., if you declare const, you say you will not change the const value, but for a const pointer the data can be modified by other pointers pointing to the same direction. restrict says there is only one pointer to the data, and that's the one declared as restrict. If that's true, the compiler can avoid checking for dirtiness, if I understand it correctly, thus working directly on the cached data.

C++ has the power of optimizations because it allows more places to tune for performance and do it without a heavy burden over all codebase. Like you can override new operator.

Even though I'm aware C++ can be used to achieve better performance, this comment doesn't imply it. The fact it allows more places to tune for performance, if it were poor enough would not mean it gets better than other language.

Templates are powerful for performance (at least when we talk code without LTO) as the templates have to be parts of headers, so all compilers do have access both to type specialization (like using sort function) and to all code to make assumptions. STL (at least with unchecked iterators) have good performance algorithms which are a bit out of reach of the typical programmer: I talk here for example that the default std::map implementation is based on red-black trees which are balanced binary trees. Yes, you can write it in C, but is not made in a transparent way for users.

Another thing you omitted about it, is that it's also more space friendly than including C code in headers, since, except if you BOTH declared it as static (that's probably needed to avoid linker errors anyway) and the compiler removes unused code, C functions will get compiled into the modules including them, while templates are build on demand (i.e., you include the template, but only the used specializations get compiled).

At last, C++ is harder to successfully write a compiler, but most compilers target the same intermediate reprezentation as their C counterpart (like LLVM, GCC's GIMPLE, or whatever way they are abstarcting the code does), so I see no reason that a C++ code would perform (if you switch the extension from C to C++ or vice-versa) worst or better.

I see one: you need to transform it to the IR. This is harder as the language gets more complex, and at the very least this means a longer compile time. Anyway, this difference was negligible in 2006 (in the article I told about, I promise I'll look for it tomorrow), so right now it should be the same or maybe a bit better for C++ (since I believe it received the most efforts since then). Also, C++11 introduced several features aiming to better performance and to ease the work for the compiler.

Even I prefer Generic collections (from BCL/.Net world), std::vector gives basically the same performance of iterating with an indexer as a C array goes (again with unchecked iterators) and many STL algorithms are better than average programmer would write.

I don't think what the average programmer would write is that relevant, since there are libraries for C that someone caring about such things as performance could use, which probably have good algorithms. I wouldn't judge a language based on how crappy (and NIH-ish) some programmers could be. Of course, it's nice to have the templates to avoid looking for a good library for fairly common things.

A great C++ talk about using some tricks (there is one very close to C world, and one where std::move semantic is flawed in today's compiler implementations), and one of them is using templates to optimize bit operations:

http://channel9.msdn.com/Events/GoingNative/2013/Writing-Quick-Code-in-Cpp-Quickly

(sorry that is a MS site channel, but the talk is about GCC/Facebook/C++/templates)

Thanks, I'll look into it.

[n3wu53r]

More opportunities to optimize?! I'm at a loss for words... Just, speechless...



Oh God. This is just...



Why didn't you say you use Mono and C# voluntarily?! Here I was thinking this is some novel form of epic trolling. Or, at least, simply a severe case of miscommunication. Now I feel so silly trying so hard...

Here, this expresses everything you need to know about me while detailing my future commitment to this discussion:

#include <u.h>
#include <libc.h>

void 
main()
{
	print("\n");
	exits(0);
}

Did you seriously just use void main()........

[ciplogic]

You can do just the same with C, it will just not be as clean as with C++, and you'll need to declare them static, also.
Also, the most used compilers can use LTO, so there's no point to do that thing, performance wise (there are valid reasons to use templates that have nothing to do with performance). Also, optimizing with C++ is said to be harder because of its increased complexity. I don't remember where I read it, so I'd take it with a grain of salt.

On the C versus C++ performance, I have an article where it is shown C++ performing better than C for the same algorithm, but I need to look it up.

So, let's clarify, C++ will give to you basically the same performance as C with a similar coding style. There is the concept of "zero-cost abstractions" of C++, that if you avoid the word "virtual", you will likely get for the same coding the same performance (this with or without LTO). There are tricks in C (like restrict keyword, which some C devels are using it, but too few C++ that do use it), and there is const in C++. Anyway, the const is a bit more powerful than restrict, in my view, as it give more code guarantees and give more chances for the compiler to optimize.

C++ has the power of optimizations because it allows more places to tune for performance and do it without a heavy burden over all codebase. Like you can override new operator.

Templates are powerful for performance (at least when we talk code without LTO) as the templates have to be parts of headers, so all compilers do have access both to type specialization (like using sort function) and to all code to make assumptions. STL (at least with unchecked iterators) have good performance algorithms which are a bit out of reach of the typical programmer: I talk here for example that the default std::map implementation is based on red-black trees which are balanced binary trees. Yes, you can write it in C, but is not made in a transparent way for users.

At last, C++ is harder to successfully write a compiler, but most compilers target the same intermediate reprezentation as their C counterpart (like LLVM, GCC's GIMPLE, or whatever way they are abstarcting the code does), so I see no reason that a C++ code would perform (if you switch the extension from C to C++ or vice-versa) worst or better.

Even I prefer Generic collections (from BCL/.Net world), std::vector gives basically the same performance of iterating with an indexer as a C array goes (again with unchecked iterators) and many STL algorithms are better than average programmer would write. C by default doesn't offer this, and here is also an area where I think that the performance disparity goes. Similarly std::string (or std::wstring) are really fast(er) equivalents of the C world. As many programs go, this is all is needed to make things run.

As for C world, I love Vala and other platforms which are using C for code generator (I mean about a lot of functional languages like Caml, Clojure), as C is a really close-to-metal stuff, and the guarantee that it doesn't throw exceptions, and if you don't use exceptions (C++ has std::nothrow so you can give the same code guarantee, if you want to help compilers analysis).

A great C++ talk about using some tricks (there is one very close to C world, and one where std::move semantic is flawed in today's compiler implementations), and one of them is using templates to optimize bit operations:

http://channel9.msdn.com/Events/GoingNative/2013/Writing-Quick-Code-in-Cpp-Quickly

(sorry that is a MS site channel, but the talk is about GCC/Facebook/C++/templates)

[mrugiero]

Yes, you seem to have a very short attention span, and you find puzzling words at random.

Yes, most C/C++ compilers, excluding the case you're using LTO (Link time optimizations) are not able to do many optimizations accross object files, so as in C++ you can write real implementation in headers, this implementation can be inlined by the compiler.

You can do just the same with C, it will just not be as clean as with C++, and you'll need to declare them static, also.
Also, the most used compilers can use LTO, so there's no point to do that thing, performance wise (there are valid reasons to use templates that have nothing to do with performance). Also, optimizing with C++ is said to be harder because of its increased complexity. I don't remember where I read it, so I'd take it with a grain of salt.

On the C versus C++ performance, I have an article where it is shown C++ performing better than C for the same algorithm, but I need to look it up.

[JS987]

Performance (as in FPS) per-se doesn't mean necessarily it is less efficient, for example Crysis 2, a game I love, has low FPS for most machines (including mine), but it is because it adds many layers of physics and effects. On a similar note, Unvanquished has more scripts to run (necause it has RTS elements), so this may be the cause.

It seems developers of Crysis 2 were bribed by some manufacturer of graphics card to use pointless effects and force people to buy high end graphics card as that game wasn't able to run at 90 fps with lowest details and average discrete graphics card at time of release (Geforce GTX 550 Ti only 47 fps).

[ciplogic]

Does Unvanquished have much more detailed graphics than Xonotic Ultra?
Xonotic engine seems to be far more efficient than Unvanquished one.

Unvanquished - 33 fps
Xonotic Ultra - 76 fps

http://www.phoronix.com/scan.php?page=article&item=intel_iris_galago&num=4

http://www.phoronix.com/scan.php?pag...s_galago&num=5

Please read what the article said also:

Sadly with Unvanquished there's still incorrect OpenGL rendering when using the GL3 renderer on the Intel Mesa driver

It may be simply a bug, or an edge case. For now particular reason, I see this screenshot from internet which shows Unvanquished played at 81 FPS (look on top-right screen):

http://media.moddb.com/images/articles/1/110/109126/auto/z2KQch.jpg

Optimization takes time, and another generation game (this is not to say that game is Xonotic) can run faster just because it does less.

Performance (as in FPS) per-se doesn't mean necessarily it is less efficient, for example Crysis 2, a game I love, has low FPS for most machines (including mine), but it is because it adds many layers of physics and effects. On a similar note, Unvanquished has more scripts to run (necause it has RTS elements), so this may be the cause.

[ciplogic]

More opportunities to optimize?! I'm at a loss for words... Just, speechless...

Yes, you seem to have a very short attention span, and you find puzzling words at random.

Yes, most C/C++ compilers, excluding the case you're using LTO (Link time optimizations) are not able to do many optimizations accross object files, so as in C++ you can write real implementation in headers, this implementation can be inlined by the compiler. If you will read more than tabloid blogs that people justify why they created their new language as a proof of dicharging an "old" one like C++, maybe you can look at this talk. This combines more details about VM, sandbox, "performance window", and luckily, it has a simple language. This is not a C++ optimizer talk.

You still failed to show your source of your assertion that C is faster (or equal) in all cases than C++ which is your initial claim

Oh God. This is just...

... idiot, from your side as you throw words just to make sure that your beloved C is the single language it stands. You still did not address the idea that are real games using JS as their scripting engine (like 0AD), but you have simply said that is the worst scripting language.

Why didn't you say you use Mono and C# voluntarily?! Here I was thinking this is some novel form of epic trolling. Or, at least, simply a severe case of miscommunication. Now I feel so silly trying so hard...

This is the biggest difference between me and you: you are the "community" which produces nothing, and criticize developers because they don't align their code into the world of programming that was like 25 years ago: "write everything in C, a bit of assembly".

I use C# and Mono to make a virtual machine (to not say too much about my project already), what you seem to not see, that excluding some puzzling words like C# (read first line), you miss the part that the correction was a mistake in what you're saying: "JVM cannot implement LLVM because is a stack machine", isn't it so? Also you missed the part when you were educated that Mono includes some limited sandboxing, like it doesn't implement CAS. May you give your source where LLVM does sanboxing?

I feel fine for "smileys" written in C, even more when people live with their "ignorance is bliss" lifestyle.

I really appreciate that Unvanquished pick to write it into C++, and this is not because it will lose or win performance, but because at least they will be away of people like you. Also picking PNaCl seems a great design choice, I really hope they will succeed to finish it doing.