Framework Group recent work report [sumtec]

Recent work includes:
1. Study the influence of delegate on performance;
2. Study object handling methods;
3. Think about object computing.

The descriptions are as follows:
I. Delegate problems.
This problem is caused by the fact that there are many areas of interaction in the game object, so it is worth exploring how to interact. First, there will always be passive calls to the game interaction object. For example, if the other party hits "you", then "you" must have the corresponding action performance. We can use the "event" method, "interface" method, or "direct call" method to solve the problem. I will not make a detailed report here. I will briefly explain the test results and the final conclusions. For a detailed report, I can refer to my other post, or this post has some subsequent ideas. To put it simply: 1. Delegate, interface, and directCall have a low performance difference when a single call is triggered. 2. In case of multiple triggers, the delegate and other methods have relatively high performance aberration, which is several times different. 3. Multiple triggers are performed when the trigger code contains a simple accumulate loop of one thousand times. The performance difference is not big, about 5%. The test results are not very favorable for delegate, but we finally have to use delegate (event) for the following considerations ):
1. In case 3, the performance difference is not very obvious. Here we perform 10 million subtasks, with a performance difference of about 0.5 s. However, this is just a test of this problem. If it is placed in the real product, there will be a lot of other operations, so the performance impact of this problem will be lower, basically, it should not be the bottleneck.
2. considering multiple triggers, No matter interface or directCall is used, it will cause a certain level of trouble for the design and development personnel. Even for the engine design, some additional code is required, and some things may be inconvenient. To implement multiple triggers, we may need to do a lot of extra work.
3. Considering situation 1, this situation (single-trigger) should be the majority of actual situations, so we may not be able to get the expected benefits from using interface/directCall. The expected performance improvement is obtained by testing multiple triggers.
4. Considering that it may be transplanted to whidbey in the future, this performance difference will not exist at all. (In this regard, it seems that some messages can imply that the performance problem of Delegate will be solved satisfactorily .)

Ii. Object Processing Method
This problem is actually about how to maintain a large number of objects. This problem is mentioned in many articles about designing games. Most of them suggest maintaining a large object pool to avoid the construction of a large number of objects. I also had a positive opinion on this statement at the beginning, but later I thought about it and found that this work was completed by GC in. net. (For example, the. NET object does not need to be parsed. For example, the. NET heap is maintained accordingly .) If we maintain another object pool by ourselves, there may be problems: 1. Can our object pool performance be compared with GC? What about correctness and security? 2. Will our object pool interfere with the normal operation of GC? For example, some objects are not stored in our own object pool. Because the existence of this object pool occupies a large amount of space, the efficiency of the objects that are no longer in the object pool may be very low. It is even possible that the object pool itself is too large, and there is an efficiency problem (GC cannot put a part of it in the faster gen0, instead, we had to put all the data in gen2, and so on ). 3. Design an object pool by yourself. Will the entire design be difficult? Will it cause the design trouble for the final game developers?

For this problem, I handed it over to mikespook for testing. My requirements for testing are as follows: First, use a large number of objects to occupy n of memory. This step simulates some objects that will not be released frequently as the basic memory pressure. Second, use a small object with the size of X and the number of Y to continuously generate and destroy in the memory at the frequency of H, and ensure that there are Z such objects in the memory at all times. In the simulation, n, x, y, H, and Z should be adjustable to simulate the results under different circumstances, let's take a look at the situations under which the GC is faster, and under which conditions the object pool is more reasonable, or under which circumstances there is actually no big difference.

Recently, mikespook has been busy, and may not have time to carefully prepare the report, or even give it out. He found Dudu last night and briefly explained the result. He probably did a simple test and the result showed that at least GC is better than we thought. (I guess this is already quite a conservative saying. I didn't talk to Mike directly, but I don't know the specific situation. The reason why I guess so is in the following sentence .) Mike may think this is caused by poor Object pool design. He looked for some information and tried to try another experiment. However, there is no time in the near future, and it may take some time for the result to come. As a matter of fact, I have expected better GC performance than we did, but I don't know and don't worry about it. Now I think I can say this: if we are in. under the. NET architecture, I was surprised to write an object pool structure that is more effective than GC management, and Microsoft was surprised. The reason is this: Ms considers GC very carefully and is more exaggerated than Java. First, GC is divided into three generations (Java is two generations). The size of gen0 is consistent with the LV1 cache of the CPU, gen1 is consistent with lv2, and gen2 is "infinite, the consistency here is at least an order of magnitude above. Why? Because a study shows that the older the object is, the less likely it will be to be released, and the lower the Access frequency. In other words, the newly generated objects are basically accessed in a short period of time, and are usually frequently accessed. If the objects with High Access frequency are always stored in the same memory, the possibility of hit by the CPU buffer is higher! Because the CPU is always trying to buffer a continuous, frequently accessed memory block. If we write the Object Buffer Pool on our own, it is difficult to consider it so carefully and clearly. At the same time, GC may be affected, because an object exists for a long time (the root cause of the existence of the Object pool is to make full use of an object that has been constructed to make it exist for a long time ), GC is bound to assume that it is an object with low access frequency, and is likely to be transferred to gen1 or gen2, which may reduce the efficiency (frequent cache hits, read from memory ). In addition, some gen0 space may be occupied, so that some objects not processed in the buffer pool are forced to be transferred to gen1 or gen2, and the efficiency has to be reduced. The buffer pool also occupies a large amount of heap space, making it difficult to allocate GC memory. If you have read some information about. net, you should have read the following suggestions for developing efficient programs: 1. Try to use the object structure that occupies a large amount of space as little as possible; 2. Associate as few objects as possible (that is, I reference you, you reference Him, He references ...... Such a long string); 3 ,......

Of course, if Mike's new test shows that the buffer pool is more efficient than GC, I still have to proceed with careful and careful consideration. But for now, I am planning to discard the "Object Buffer Pool" idea and prepare for the next step of design and other tests.

Iii. Thinking about object computing.
This problem is logically simple, but it is not easy to understand. Suppose you want to "attack" A building when controlling tank. The attack result is calculated based on your tank's attack power and my building's defensive power, to correct the hpvalue of my building. Well, the question is coming soon: Where is the tank object under your control? Where is my building? How to calculate the destroyed action-how to obtain data from both parties? Where is computing performed? How to fix it?
For details, you need to think about how to write such code. First of all, as long as it is an online game, whether you are in the C/S mode or distributed mode, whether it is a small-scale game such as C & C or a large-scale game such as legend, it will exist. For example, I assume the C/S mode, and assume that you are using server computing and then hand over the results to the client. How can this computing result be reflected on the client? Is it "HP:-12" or "tank. ID = 123; Action = Fire" transmitted to me (the building Controller) on the network "? In the previous method, how do you implement a framework? You cannot let the final game design such a game object:
Class metaltank
{
Void onreceivedmessage (string MSG)
{
If (MSG...) // parse the msg
}
}
No one will like this. If you say it is placed in the engine, you must use reflection, because the engine does not know what objects and attributes you have. In this case, the performance is not good, and the appearance is even more of a problem. Of course, such a design will certainly be able to run, but it should not be our goal.
Well, if it is the later method, how can I obtain the tank. ID = 123 attack power? Well, is there a tank. ID = 123 object on my machine? If so, regardless of how the tank. ID = 123 object is obtained, I have to raise the following questions:
1. What attributes do you need to know about this tank. ID = 123 object? All? Or part? How can we keep the data synchronized with the other host? If you have all the data, does it mean that the objects on your machine are the same as those on the other side? Are both sides doing the same computing? How can distributed computing be achieved? (Every client needs to know all the information and calculate all the things)
2. If we should not know everything, but just know that there is such an object and some basic information, does it mean that the tank class requires two versions? (In fact, this problem also exists in the mode where the previous server compute only sends the result to the client. The server is a complete version, and the client is a simple version .) Will such a design be complicated? Will it add a lot of work for game designers? What information needs to be known? Which do not need to know? In case of design mistakes, some things that need to be known are not required to be known, but some things that do not need to be known become known, and the bug needs to be changed, will it cause structural changes to the entire game?

When I wrote this post, I thought I had taken this issue into consideration. Later I thought about it and found that I did not think it over carefully. I will report it again when I think it over. However, I still insist on placing the computation in the action class, but it is very likely that this class will be modified to split the action steps into multiple parts, you may even add some auxiliary classes. In addition, I want all objects to exist in each client, but not all of them are computed. (But in this case, there are some other problems: We often trigger some engine updates during computing, such as some changes in the GUI, such as the location and HP bar, however, if some objects only accept results and some objects are computed, how can we trigger the definition in a unified manner ?)

There are many things to think about!