From reactos@einsurance.de Thu Mar 24 03:35:47 2005 From: Ash To: ros-dev@reactos.org Subject: [ros-dev] Speed Tests (was: ping Alex regarding log2() for scheduler) Date: Thu, 24 Mar 2005 03:35:41 +0100 Message-ID: <002501c5301a$2c282ac0$3814a8c0@PR0N> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3282313932245980443==" --===============3282313932245980443== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, I'd like to provide a small VS.NET project file with 5 different tests. - 46ffffe9 tells everything is alright with the function calculation - times are measured with QueryPerformanceCounter - loop run cnt: 0x2ffffff result orig function 46ffffe9 it took 1491052 result orig function inlined 46ffffe9 it took 1035547 result second proposal inlined 46ffffe9 it took 1244434 result optimized asm 46ffffe9 it took 1338367 result debug asm 46ffffe9 it took 8774815 The second proposal is the original proposal but more shifts - still slower=20 tho. Interesting is the inlined version generated by MSVC, shaving off almost 1/3 = of the overall time. Also stared as "optimized asm" - no gurantee on register safety tho ;) For portability and performance sake it should be considered to create a=20 compiler macro. This function is terribly small, any optimisations inside are outweighted by = the calling overhead in this case. The most impressive one is the original function inlined, althought the ASM=20 would only work on x86. Please do not think about using 64k tables, thats what, 1/2 of a Sempron L2=20 cache? It would really really trash performance. Available at: Kernel Test http://wohngebaeudeve= rsicherung.einsurance.de=20 --===============3282313932245980443==--