For server Focus on Linux?

this
which links to this

seems to give hints which system to use for servers and performance.

The software for the server will work across all platforms, that's how you play an offline Skirmish after all.

Mike

Right. But if linux can get better performance out of the game, maybe its worth it to focus a bit on it. Because at the end of the day if you want to create as much or as many games with a given hardware every percent efficiency counts.

So, you're saying that a certain users of the software should arbitrarily have a better version of said software?

Mike

No, thats not what he said.
The software is the same, but you actually get an measurable speedup by using the POSIX API on Linux instead of the Win API. So it can make sense to keep the code paths shorter for POSIX systems to make better use of the lower latencies and to make a cut on optimizations for Windows as it won't make much of a difference anyway, at least not reliable across current Windows versions.

If a coder knows what they're doing, a good 90% of the optimized code will work just fine across Windows/Mac/Linux platforms, with very little change needed to compile on each. For the remaining 10%, it's usually best practice to wrap the code with worker functions and use the appropriate code depending on the target system. This way a generic function call would wrap the appropriate system calls that are the most appropriate for the system.

So I don't think there's anything to worry about, as Uber seems to know one or two things about how to code properly.

@knight:
And if there are hardware or software possibility s to speed up thinks f.i. fma3/4 vtx to speed up things I wsnt them used, if the outcome of the engine is the same.

Codewise it could be a difference in performance and precision if you write a*(b+c) or a*b+a*c or (b+c)*a.

The way you write certain things (like calculations) is usually optimum across all systems, not specific to Windows or Linux. The minor details about it are best left alone, and written using the most readable method, as the compiler does a better job of optimizing at the low level than the programmer can.

The only real area of concern nowadays is with regards to the graphical implementation, and that doesn't matter for the server implementation.

Neut wrote the following;

"It can't be C++ because it compiles to binary and we are cross platform. I thought about embedding LLVM but the sandboxing support just isn't there."

We can infer from this that they are using an interpreted language. Thus the interpreter will be handling direct interaction with the OS. Thus no optimization.

Ripping quotes out of context is fun, isn't it?

He said that while talking about the MODDING SYSTEM. Thats right, mods can't be written in C++ or any other high level language because they need to be distributable across multiple platforms and you can't just have a full compiler as dependency.

Thats not true when talking about the core however. That thing is distributed as binary ONLY, prebuild for various platforms and can be written in any high level language with direct access to the corresponding OS API without a detour over the various layers of abstraction any scripting language, respective the interpreter, would provide/enforce.

My bad your right about the modsystem.

My concern is that what you are asking for is the beginning of spaghetti code. The high level program should not be taking shortcuts to bypass the designed structure and abstraction layers that are designed to interface with the OS. This can lead to additional complexity when debugging, or attempting to troubleshoot problems with the game.

This is actually fairly standard practice, as it's often desirable to use specific system calls for the desired environment to achieve the best performance.

Take the network code, for example. To write efficient network code, you need to use the low-level system APIs specific to the environment you're on. Those system calls are very different for Windows and for Linux. So you create a generic wrapper object for the netcode, with general function calls. (ie connect(), sendPacket(), etc) You then implement several different versions of the code, using the environment-specific system calls for Linux, Windows, Mac, iOS, whatever. Set your compiler flags to choose the appropriate one, and you're set. The resulting network interface is identical across all platforms, but the implementation of that interface differs per platform. (There are other ways to do this, but this one is simple enough to understand.)

Of course, more often than not, developers will be using an API like SDL, which actually does this work for you behind the scenes. In this case, your interface is written out for you, and so for all intents and purposes, your code will be identical across platforms. (Although, this depends on the implementation the developer has in mind. In many cases, they may choose to roll their own version to accommodate specific requirements they have.)

http://stackoverflow.com/questions/...pow-to-square-or-just-multiply-it-with-itself

See, this is EXACTLY the problem I have with programmers overthinking the optimization issue.

Firstly, those types of tests are never accurate for the real world. In this case, I would expect that a major source of the performance loss is due to the function call (especially since the person who wrote the program ensured that the compiler wouldn't optimize subsequent calls out), and function calls add overhead when not optimized. If you're writing your code in such a way that this matters, then it's time to think of another way to write it. But even so, consider how you're going to be using this section of code. Is x always raised to the power of 3? If so, then perhaps doing the multiplication method is best. Otherwise, use the very efficient, very readable function call provided for you. (Which, by the way, has error checking and is written to take advantage of compiler optimization.)

In any case, don't forget the original point of this debate. Whichever implementation of exponentiation is the more efficient one for your purposes, it will be the most efficient on Windows, Linux, and Mac, more often than not. And if it isn't the most efficient implementation on one specific, then it's likely a compiler issue, which is not worth the trouble of working around. (If the issue is fixed in the future, your hand-optimized code is not so optimized anymore.) In fact, this is often why using a function call like pow is desirable. If you update your compiler, standard libraries like math.h will be updated as well, ensuring that they take full advantage of compiler optimizations, without the need for you to rewrite your code.

I read both articles in full. I fail to see any relevant metrics or benchmarks that justify his conclusion. This is little more than conjecture. I would like to see some real benchmarks that can support your claim.

I hope your running Gentoo, otherwise the above post might seem a bit silly

Linux gets more performance in certain areas because it just does some things better. Network stack perf is an example of this.

So how we do we handle platform specific code? Let's use sockets as an example. In this case each platform exposes one of these:
class SocketFactory
{
public:
virtual ~SocketFactory() { }
virtual uint32_t getLocalAddress() = 0;
virtual zu::Ref<Socket> create(Protocol protocol) = 0;

virtual bool resolveIPAddr(std::string const & name, uint32_t & ipaddr_out) = 0;
virtual bool resolveName(uint32_t ipaddr, std::string & name_out) = 0;
};

So on linux/mac we then have a function that looks like:
SocketFactory * createPosixSocketFactory();

Which then returns a socketfactory that creates posix sockets. The socket itself is another pure virtual interface that then implements sockets for that platform. We then can pass these virtual socket to all code that requires sockets.

So on windows you would use:
SocketFactory * createWinSockSocketFactory();

All of the code in the game then writes to our socket.
--

I just searched and there isn't a single place in the code that uses pow() that is performance sensitive other than inside shader code. As far as optimizing math functions goes you really have to look at a lot of stuff. Data movement is really the thing that is the most important when looking at performance. It doesn't matter if pow takes 1 cycle or 100 cycles if you are waiting around for 500 cycles to get the data. So organizing your data to get processed in streaming/cached batches is a fairly important design consideration otherwise you will likely be memory bandwidth limited anyway.

Above all design systems to be fast and worry about cycle level optimization only in the most extreme cases. Typically getting your data laid out correctly is the real work.

Uhm, what about IPv6?...
Several providers started shipping IPv6 addresses and decided to enforce provider grade NAT for IPv4 at the same time. 32bit surely isn't enough to handle IPv6 addresses.
I would even consider to handle IPv4 only as mapped into IPv6 so you can handle inhomogeneous networks with less effort. Not sure how Windows behaves, but with Linux and OSX it is actually the default behavior to handle also IPv4 when bound to IPv6 unless IPV6_V6ONLY was set.

Only Windows XP might require some special care, but I don't see why you shouldn't use IPv6 internally anyway, even when in pure IPv4 networks.

pow() was just one example to show that there are different performances of different functions/operators doing the same thing.

We haven't implemented IPv6 yet. It's on our radar but we simply haven't gotten to it.

And I used it as an example of a pointless optimization that wouldn't make a difference except in very unusual circumstances.