Thoughts on the impact of multi-core development on Online Game Design

As early as a few years ago, Herb
The article "free lunch is over and software is always moving closer to concurrency" published by Sutter has aroused a great reaction in the industry, and dual-core has become popular now, in September, it should be a year of domestic popularization of 4 cores.
Erlang is also becoming increasingly popular with the development of multi-core programming technologies. There are also a lot of online debates about whether common programmers need to master multi-core programming technologies, whether they are correct or not, at least multi-core related technologies
Attention of developers.

I developed a game server. The server configuration of the company's old games is generally a dual-Xeon CPU with hyper-threading, and a logic of four CPUs (not to mention the performance improvement of hyper-threading ), it should have been a multi-thread design for game servers, but I know that most of the game server logic in China is single-threaded, that is, there is a saying that the so-called main thread exists, A single thread is designed based on
The following factors (listed as 3000 gamers online at the same time ):
1: about 20-30% of the CPU is occupied by network I/O, and the network layer is easily implemented using multiple threads.
2: The architecture can be used to strip data access, Io, and other components that are easily implemented using multiple threads. The remaining CPU-intensive operations are called the main thread.
3: multi-threaded design leads to longer development cycles, more complex design, and lower maintainability.
3: the most critical point is the complexity and number of bugs caused by multithreading. Frequent downtime and rollback are intolerable for any game.
4: Let's take a look at the performance loss caused by the previous single-threaded dual-CPU server (the performance caused by hyper-threading is extremely limited and will not be discussed for the moment, the network I/O part can be composed of two
The CPU is evenly shared, and the cost of some locks and cache synchronization and other software (such as monitoring and statistics) are put aside, resulting in a performance loss of about 30%-40%, loss between performance and stability and development cycle
Weigh, of course, choose a single-threaded design.

Now let's take a look at how to consider performance if a new project is started. First, let's make two assumptions: 1: the project cycle is 2 years, that is, 2 years after the game beta test, or large-scale internal testing. 2: 2 years later, mainstream server configurations
16-core, 8-core low-end configuration. If the single-threaded server is still designed and computed with a 16-core CPU, the loss of performance will reach at least 800%. At this time, someone may say that I put all servers
Put it on a machine, and even the database, so that you can make full use of all CPU resources. Yes, I admit that this basically makes full use of CPU resources, but this is not the core content of the game.
Currently, only 3000 players and 10000 servers that activate the NPC are supported. Hardware is developing, and players' experience needs are also evolving. Just as the network bandwidth has increased by 100 times, we still
However, it is unacceptable to only view intermittent videos. Having said so much, I just came to the conclusion that the development of multi-core must be paid attention to in game development.
So how can we use multi-core resources? I have summarized the following methods:
1: multi-process design, which is the path of cloud wind
2: Challenges logical complexity, well-designed thread models and data structures
3: Use intel OpenMP, TBB, and other technologies

The following is my personal opinion on the above designs:

The multi-process design conforms to the Unix philosophy and kiss. The difficulty lies in process management, communication, and coordination. The advantage is ease of maintenance, debugging, and clear structure. The disadvantage is that process management is troublesome and there is some efficiency loss.
The most important thing is that the multi-process design may still fail to improve the efficiency of the multi-core CPU. According to the 80-20 rule, 80% of the CPU may be consumed within 20% of the process, if
Module division processes. Even if a well-designed data pipeline is used, parallel computing is required in 20% of processes.

In 2nd, the practice is too risky. It requires years of game design experience and good and powerful design capabilities.

The practice in 3rd is a compromise, and the code of the 80% CPU usage is analyzed and parallelized. Of course it is easier to say than to do it. This method still requires a good data structure design. For example, to search for 1000 monsters at the same time, this read-only operation is easy to parallelize without locking.

In combination with the above designs, I think the most appropriate practice is to adopt coarse-grained processes. It is a relatively good design to combine TBB and other databases to perform parallel operations within CPU-intensive processes.

The writing is messy, and in some cases it is not rigorous. The above ideas only provide a way of thinking and are not yet used in practice :)

PS: TBB has a pipeline framework, which provides a pipeline mechanism conveniently within the process.