reHLDS/rehlds
2
0
Fork 0
mirror of https://github.com/rehlds/rehlds.git synced 2025-04-24 07:13:38 +03:00
Code Issues Projects Releases Wiki Activity

fixed old dreamstalker url (the new address of the images was not indicated... dreamstalker.github.io -> rehlds.github.io)

Name: ________________ 2024-10-30 10:12:44 -04:00
parent d5b46a2e3a
commit 7369f681e6
1 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
The-performance-optimization-month:-results.md

@ -3,15 +3,15 @@ May 2015 was the performance optimization month for ReHLDS project: hundreds pro
# ReHLDS demo recorder/player # ReHLDS demo recorder/player
ReHLDS demo recorder & player are parts of ReHLDS test suite which, in a nutshell, is the ‘black box’ testing appliance. To understand how it works we should treat ReHLDS as the black box which consumes data from external services, does some processing and sends data back. Services are well-known APIs: Win32 API, standard C library, Steam API. ReHLDS demo recorder & player are parts of ReHLDS test suite which, in a nutshell, is the ‘black box’ testing appliance. To understand how it works we should treat ReHLDS as the black box which consumes data from external services, does some processing and sends data back. Services are well-known APIs: Win32 API, standard C library, Steam API.
<img src="http://dreamstalker.github.io/rehlds/images/wiki_may2015/demo_rp_1.png" width="500"></img> <img src="http://rehlds.github.io/rehlds/images/wiki_may2015/demo_rp_1.png" width="500"></img>
Before we can do a ‘black box’ testing we should intercept the data flow between ReHLDS and external services and write it to some file which is called ‘ReHLDS test demo’: Before we can do a ‘black box’ testing we should intercept the data flow between ReHLDS and external services and write it to some file which is called ‘ReHLDS test demo’:
<img src="http://dreamstalker.github.io/rehlds/images/wiki_may2015/demo_rp_2.png" width="650"></img> <img src="http://rehlds.github.io/rehlds/images/wiki_may2015/demo_rp_2.png" width="650"></img>
Now we can run ReHLDS in test mode and feed data from file we recorded on previous step. We should also make sure that ReHLDS produces the same output as it produced by (Re)HLDS during test demo recording: Now we can run ReHLDS in test mode and feed data from file we recorded on previous step. We should also make sure that ReHLDS produces the same output as it produced by (Re)HLDS during test demo recording:
<img src="http://dreamstalker.github.io/rehlds/images/wiki_may2015/demo_rp_3.png" width="650"></img> <img src="http://rehlds.github.io/rehlds/images/wiki_may2015/demo_rp_3.png" width="650"></img>
In that way we can replay recorded scenario as many times as we need. We may also make some modifications to code and ensure that it still produces the same output as original(unmodified) version – this is how existing integration tests work. Another cool fact about this test suite is that we don’t depend on external things like OS timers and network anymore: when ReHLDS calls recvfrom() in test mode, interceptor just reads next recorded packet from the file; when ReHLDS calls Sleep(), nothing actually happens (interceptor just ensures that Sleep is the next function that was called by original app). This means that ReHLDS always consumes 100% of one CPU core in ‘test demo play’ mode, which, in turn, makes it suitable for benchmarking. In that way we can replay recorded scenario as many times as we need. We may also make some modifications to code and ensure that it still produces the same output as original(unmodified) version – this is how existing integration tests work. Another cool fact about this test suite is that we don’t depend on external things like OS timers and network anymore: when ReHLDS calls recvfrom() in test mode, interceptor just reads next recorded packet from the file; when ReHLDS calls Sleep(), nothing actually happens (interceptor just ensures that Sleep is the next function that was called by original app). This means that ReHLDS always consumes 100% of one CPU core in ‘test demo play’ mode, which, in turn, makes it suitable for benchmarking.
@ -49,7 +49,7 @@ Now let's go through configuration elements:
- GameDLL's optimization is AngleQuaternion function rewritten using SSE instructions - GameDLL's optimization is AngleQuaternion function rewritten using SSE instructions
# Benchmark results # Benchmark results
Demos in each configuration were played 3 times, average duration was used as a result. 6 different systems were used to run benchmark. Raw result are available <a href="http://dreamstalker.github.io/rehlds/images/wiki_may2015/benchmark_results_raw.csv">here</a>. Demos in each configuration were played 3 times, average duration was used as a result. 6 different systems were used to run benchmark. Raw result are available <a href="http://rehlds.github.io/rehlds/images/wiki_may2015/benchmark_results_raw.csv">here</a>.
To visualize raw results we should do two things: To visualize raw results we should do two things:
<ol> <ol>
@ -59,16 +59,16 @@ To visualize raw results we should do two things:
And there is a chart with all results: And there is a chart with all results:
<img src="http://dreamstalker.github.io/rehlds/images/wiki_may2015/res_graph_all.png" width="612"></img> <img src="http://rehlds.github.io/rehlds/images/wiki_may2015/res_graph_all.png" width="612"></img>
Charts for each CPU: Charts for each CPU:
<img src="http://dreamstalker.github.io/rehlds/images/wiki_may2015/res_graph_i3-3110M.png"></img> <img src="http://rehlds.github.io/rehlds/images/wiki_may2015/res_graph_i3-3110M.png"></img>
<img src="http://dreamstalker.github.io/rehlds/images/wiki_may2015/res_graph_i7-920.png"></img> <img src="http://rehlds.github.io/rehlds/images/wiki_may2015/res_graph_i7-920.png"></img>
<img src="http://dreamstalker.github.io/rehlds/images/wiki_may2015/res_graph_i5-2400.png"></img> <img src="http://rehlds.github.io/rehlds/images/wiki_may2015/res_graph_i5-2400.png"></img>
<img src="http://dreamstalker.github.io/rehlds/images/wiki_may2015/res_graph_i5-3450.png"></img> <img src="http://rehlds.github.io/rehlds/images/wiki_may2015/res_graph_i5-3450.png"></img>
<img src="http://dreamstalker.github.io/rehlds/images/wiki_may2015/res_graph_i7-4710MQ.png"></img> <img src="http://rehlds.github.io/rehlds/images/wiki_may2015/res_graph_i7-4710MQ.png"></img>
<img src="http://dreamstalker.github.io/rehlds/images/wiki_may2015/res_graph_i7-3770.png"></img> <img src="http://rehlds.github.io/rehlds/images/wiki_may2015/res_graph_i7-3770.png"></img>
# Analysis # Analysis
It is clearly seen that fully optimized ReHLDS (E:Opt, G:Opt M:Opt) configuration is much faster (2.5 to 3 times) than stock configuration on all CPUs. It is clearly seen that fully optimized ReHLDS (E:Opt, G:Opt M:Opt) configuration is much faster (2.5 to 3 times) than stock configuration on all CPUs.