XPost: alt.comp.lang.borland-delphi, alt.winsock.programming   
   From: BloodyShame@hotmail.com   
      
   Hello,   
      
   I just came across this old newsgroup posting of mine comparing results.   
      
   I noticed how the custom lock methods didn't use inlining (thus causing lots   
   of call overhead). I don't know why I didn't use inline back then... I   
   deciced to repeat the test but this time with inlining.   
      
   When the custom lock methods are inlined the results are pretty spectacular:   
      
   Nice/even spreading between producer/consumer too... (though for engine vs   
   gui more producer would be nice but ok ;))   
      
   program started   
   Locked Producer Runs  : 845302   
   Locked Consumer Runs  : 845495   
   Locked Total Runs : 1690797   
   Critical Producer Runs: 586261   
   Critical Consumer Runs: 178042   
   Critical Total Runs : 764303   
   Producer Performance Improvement:        44.185   
   Consumer Performance Improvement:       374.885   
   Total    Performance Improvement:       121.221   
   press enter to repeat test   
      
   Locked Producer Runs  : 844744   
   Locked Consumer Runs  : 846213   
   Locked Total Runs : 1690957   
   Critical Producer Runs: 593467   
   Critical Consumer Runs: 170566   
   Critical Total Runs : 764033   
   Producer Performance Improvement:        42.341   
   Consumer Performance Improvement:       396.121   
   Total    Performance Improvement:       121.320   
   press enter to repeat test   
      
   Locked Producer Runs  : 844970   
   Locked Consumer Runs  : 846120   
   Locked Total Runs : 1691090   
   Critical Producer Runs: 607831   
   Critical Consumer Runs: 163188   
   Critical Total Runs : 771019   
   Producer Performance Improvement:        39.014   
   Consumer Performance Improvement:       418.494   
   Total    Performance Improvement:       119.332   
   press enter to repeat test   
      
   "Skybuck Flying"  wrote in message news:...   
   > Ok,   
   >   
   > I decided to give it one last try, because all your research must have   
   > been good for something ?   
   >   
   > So I decided to extend the example with more intensive calculations.   
   >   
   > Instead of just a few counters, ten thousand counters are   
   > incremented/decremented/copied in the continous-lock-free algorithm as   
   > well as in the blocking-lock algorithm.   
   >   
   > $ifdefs have been used to easily switch between "Custom TryLock/TryUnlock"   
   > and "Critical Section TryEnter/Leave".   
   >   
   > This time the benchmarking shows between a 100% and 200% performance   
   > improvement for the continous-lock-free algorithm which is quite amazing   
   > since there is some heavy copieing going on... but it's still faster ?!   
   >   
   > Also again this test debunks your theory that "CAS" would be faster than   
   > Window's Critical Section implementation.   
   >   
   > The Window's Critical Section TryEnter implementation performs better for   
   > the "Data Producer" and that's what it's ultimately about.. more   
   > performance for a "data producer" ;)   
   >   
   > Well you can take a look at the results yourself because I copy/pasted   
   > them into the comments.   
   >   
   > The test was run at full cpu speed. (X2 3800+, For full specs google   
   > Skybuck's Dream PC for 2006), range/overflow checking off,   
   > debugging on (probably doesn't have much influence.)   
   >   
   > So my conclusions for now:   
   >   
   > 1. Stick with Window's/Delphi's Critical Sections.   
   >   
   > 2. Maybe use a continues-locking-free algorithm as demonstrated in the   
   > example below.   
   >   
   > If UDP Speed Test 2 would benefit from such an algorithm remains to be   
   > seen, since it doesn't do that much heavy cpu calculations or memory   
   > copies... so I am still skeptical if it would benefit at all, also I   
   > wonder if the gui results updating would start to some "stutters/misses of   
   > updates".   
   >   
   > // *** Begin of Code ***   
   >   
   > program Project1;   
   >   
   > {$APPTYPE CONSOLE}   
   >   
   > {   
   >   
   > Test Lock Free Idea's   
   >   
   > Version 0.01 created on 19 september 2007 by Skybuck Flying   
   >   
   > Investigate idea to write non locking or lock free code   
   >   
   > Idea is to copy data, modify one copy, while the others remain stable.   
   >   
   > The stable copies are used by those that needed synchronized data.   
   >   
   > This simple benchmark compares my own Locking/Unlocking Techniques against   
   > CriticalSections.   
   >   
   > I am not yet sure if the locking/unlocking techniques work perfeclty.   
   >   
   > So far I can see one problem: Delphi strings which are copy-on-write which   
   > might give problems for   
   > locking/unlocking code/data copies.   
   >   
   > This is where critical section might be safer.   
   >   
   > Benchmark conclusion:   
   >   
   > More or less inconclusive, code performs more or less the same, the   
   > critical sections probably slightly   
   > faster because of less code overhead.   
   >   
   > Maybe if the data producer did more complex calculations it might become   
   > an interesting technique.   
   >   
   > However one thing can clearly be seen if the comments are uncommented.   
   >   
   > The locking/unlocking mechanism is of less quality because the try lock   
   > might fail and then nothing   
   > will be updated to the screen !   
   >   
   > }   
   >   
   > {   
   >   
   > Version 0.02 created on 19 september 2007 by Skybuck Flying   
   >   
   > Apperently Delphi 2007 has a new member for TCriticalSection which is not   
   > that well documented...   
   >   
   > It's probably actually the same as "my" TryLock method lol   
   >   
   > To prove this the code will be replaced with that method to see if it   
   > works the same :)   
   >   
   > Yup it works.   
   >   
   > }   
   >   
   > {   
   >   
   > Version 0.03 created on 22 september 2007 by Skybuck Flying   
   >   
   > There was a bug in the previous version, no var parameter used to clear   
   > the data structures, it didn't matter though Delphi initialized the run   
   > variables to zero anyway ;)   
   >   
   > For this updated test it does matter since the test is re-run three times.   
   >   
   > I decided to give this one last test.   
   >   
   > This time I use some more counters like ten thousand to simulate more   
   > intensive computations.   
   >   
   > (I tried to use one million at first but that gave a stack overflow which   
   > is kinda weird)   
   >   
   > Run counts producer runs   
   > Run2 counts consumer runs.   
   >   
   > The total number of runs is now calculated as producer runs + consumer   
   > runs.   
   >   
   > Before it was only producer runs.   
   >   
   > This might have caused some skewed results ? or maybe only the producer   
   > matters.   
   >   
   > Whatever the case may be, the results are now significantly different.   
   >   
   > The continues-lock-free based code is much faster than the blocking-locked   
   > code.   
   >   
   > However the critical section method outperforms the locks methods which   
   > debunks the theory   
   > that cas would be faster than a critical section.   
   >   
   > At least for this test.   
   >   
   > CustomLock results:   
   >   
   > program started   
   > Locked Producer Runs  : 647086   
   > Locked Consumer Runs  : 815195   
   > Locked Total Runs : 1462281   
   > Critical Producer Runs: 251621   
   > Critical Consumer Runs: 409901   
   > Critical Total Runs : 661522   
   > Producer Performance Improvement:       157.167   
   > Consumer Performance Improvement:        98.876   
   > Total    Performance Improvement:       121.048   
   > press enter to repeat test   
   >   
   > Locked Producer Runs  : 634840   
   > Locked Consumer Runs  : 832632   
   > Locked Total Runs : 1467472   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)