Performance Comparison on Accessing Bitmap Pixels lazarus / 39-Graphics ---------------------------------------------------------------------- ADMGNS · 2020-05-08 23:19 hello, i,ve scratched a test app that query performance accessing bitmaps pixel.. here is: https://tinyurl.com/ycbyqkwq Q: i think, x64 compilers have some performance issues. how can we solve this problem ?? platform: win7, x64 thank you ---------------------------------------------------------------------- winni · 2020-05-09 00:10 Hi! There is nothing to solve. Look into the code of TBitmap - then you will understand. It must be compatible to all OS. I you want quicker bitmaps the have a look: https://wiki.freepascal.org/Fast_direct_pixel_access Winni ---------------------------------------------------------------------- circular · 2020-05-09 07:24 Interesting measures. It is very surprising indeed the difference with 64 bits. It is like 30 times slower. What exactly are you measuring? Can you post your project as well? ---------------------------------------------------------------------- Thaddy · 2020-05-09 09:55 What is the compiler version and what are the compiler settings? fpc 3.2.0 and trunk contain many Intel X64 optimizations. The compiler settings are also important, e.g. -CpCOREAVX2 and -CpCOREAVX2 can make a significat difference too. ---------------------------------------------------------------------- ADMGNS · 2020-05-09 11:08 Quote from: circular on May 09, 2020, 09:24:04 amInteresting measures. It is very surprising indeed the difference with 64 bits. It is like 30 times slower. What exactly are you measuring? Can you post your project as well? hello, project is there, pls check the link.. thank you ---------------------------------------------------------------------- ADMGNS · 2020-05-09 11:11 Quote from: Thaddy on May 09, 2020, 11:55:26 amWhat is the compiler version and what are the compiler settings? fpc 3.2.0 and trunk contain many Intel X64 optimizations. The compiler settings are also important, e.g. -CpCOREAVX2 and -CpCOREAVX2 can make a significat difference too. hello, i wil try.. but, all settings were the same while compiling/linking.. thank you ---------------------------------------------------------------------- ADMGNS · 2020-05-09 11:15 Quote from: winni on May 09, 2020, 02:10:52 amHi! There is nothing to solve. Look into the code of TBitmap - then you will understand. It must be compatible to all OS. I you want quicker bitmaps the have a look: https://wiki.freepascal.org/Fast_direct_pixel_access Winni hello, i,ve already checked that page. i know these methots, but,  i,ve tried other fast access methots as well.. problem is about x64 compiling and maybe compilers.. thank you ---------------------------------------------------------------------- marcov · 2020-05-09 11:53 Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  imgTest.Picture.Bitmap.BeginUpdate();     for k:=0 to Size-1 do    begin      if (bpp = 4) and (k mod bpp = 3) then continue; // alpha channel, don't touch      t := Byte(not p[k]);      if (k mod bpp = 1) then continue;  //BGRA   0:b, 1:g, 2:r, 3:alpha      p[k] := t;    end;     imgTest.Picture.Bitmap.EndUpdate(); Really weird code. Looks like you are testing mod and continue operators :-) If you are gunning for speed, simply split the loops on BPP. E.g. for bpp=4 Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i var p : pdword;  for i:=0 to (size div 4)-1 do    p^:=(p^ and $FF000000) or ((not p^) and $FFFFFF);[/code For odd bpp's you probably need to unroll the loops a few times. Of course, for real serious stuff, you need to implement the above in SSE2 for 4 pixels at a time, or 8 for the AVX2 case. ---------------------------------------------------------------------- Thaddy · 2020-05-09 12:02 Quote from: Thaddy on May 09, 2020, 11:55:26 amWhat is the compiler version and what are the compiler settings? fpc 3.2.0 and trunk contain many Intel X64 optimizations. The compiler settings are also important, e.g. -CpCOREAVX2 and -CpCOREAVX2 can make a significant difference too. Second one should read -OpCOREAVX2. Option -Sv may also benefit graphics processing. As does -CfAVX2 sometimes. ---------------------------------------------------------------------- ADMGNS · 2020-05-09 20:32 Quote from: marcov on May 09, 2020, 01:53:33 pmCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  imgTest.Picture.Bitmap.BeginUpdate();     for k:=0 to Size-1 do    begin      if (bpp = 4) and (k mod bpp = 3) then continue; // alpha channel, don't touch      t := Byte(not p[k]);      if (k mod bpp = 1) then continue;  //BGRA   0:b, 1:g, 2:r, 3:alpha      p[k] := t;    end;     imgTest.Picture.Bitmap.EndUpdate(); Really weird code. Looks like you are testing mod and continue operators :-) If you are gunning for speed, simply split the loops on BPP. E.g. for bpp=4 Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i var p : pdword;  for i:=0 to (size div 4)-1 do    p^:=(p^ and $FF000000) or ((not p^) and $FFFFFF);[/code For odd bpp's you probably need to unroll the loops a few times. Of course, for real serious stuff, you need to implement the above in SSE2 for 4 pixels at a time, or 8 for the AVX2 case. hello, here, the focused problem is not using mod or continue; but also the problem is, under same conditions, x64 compilers are dramatickly getting slow. right? thank you ---------------------------------------------------------------------- marcov · 2020-05-10 11:43 Quote from: ADMGNS on May 09, 2020, 10:32:28 pmhere, the focused problem is not using mod or continue; but also the problem is, under same conditions, x64 compilers are dramatickly getting slow. right? I see no reason for that to happen. So it might be something in the setup. (e.g. optimizations on on 32-bit but not on x64) It is not a general problem. ---------------------------------------------------------------------- jiaxing2 · 2020-05-10 12:53 About the slow compiler, I don't know if Free Pascal also patched itself to mitigate recent Intel vulnerabilities but GCC definitely does. It's slower to compile, produces slower to run and consumes more memory binary. The binary size also increased. GCC and Clang now include many sanitizers and mitigations for hardware vulnerabilities. ---------------------------------------------------------------------- ADMGNS · 2020-05-10 19:06 hello guys, many thanks for your all valuable replies. i will do same tests on linux. thank you