From 34f1910e24420966b798164b156ef2e88b92a80f Mon Sep 17 00:00:00 2001
From: "Name: ________________" <112137590+mlibre2@users.noreply.github.com>
Date: Wed, 27 Nov 2024 18:33:16 -0400
Subject: [PATCH] ..github.io/rehlds/ -> ..github.io/ReHLDS/

---
 ...performance-optimization-month:-results.md | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/The-performance-optimization-month:-results.md b/The-performance-optimization-month:-results.md
index e337d0b..be617ce 100644
--- a/The-performance-optimization-month:-results.md
+++ b/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 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://rehlds.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’:
 
-<img src="http://rehlds.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:
 
-<img src="http://rehlds.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.
 
@@ -49,7 +49,7 @@ Now let's go through configuration elements:
  - GameDLL's optimization is AngleQuaternion function rewritten using SSE instructions
 
 # 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://rehlds.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:
 <ol>
@@ -59,16 +59,16 @@ To visualize raw results we should do two things:
 
 And there is a chart with all results:
 
-<img src="http://rehlds.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:
 
-<img src="http://rehlds.github.io/rehlds/images/wiki_may2015/res_graph_i3-3110M.png"></img>
-<img src="http://rehlds.github.io/rehlds/images/wiki_may2015/res_graph_i7-920.png"></img>
-<img src="http://rehlds.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-3450.png"></img>
-<img src="http://rehlds.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-3770.png"></img>
+<img src="http://rehlds.github.io/ReHLDS/images/wiki_may2015/res_graph_i3-3110M.png"></img>
+<img src="http://rehlds.github.io/ReHLDS/images/wiki_may2015/res_graph_i7-920.png"></img>
+<img src="http://rehlds.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-3450.png"></img>
+<img src="http://rehlds.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-3770.png"></img>
 
 # 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.