Comparison QB64 compiled with gcc optimizations and without - Printable Version +- QB64 Phoenix Edition (https://qb64phoenix.com/forum) +-- Forum: Chatting and Socializing (https://qb64phoenix.com/forum/forumdisplay.php?fid=11) +--- Forum: General Discussion (https://qb64phoenix.com/forum/forumdisplay.php?fid=2) +--- Thread: Comparison QB64 compiled with gcc optimizations and without (/showthread.php?tid=366) |
RE: Comparison QB64 compiled with Ofast and without - Coolman - 08-15-2022 thank you for the additional information. what would be fun is to find a c c++ code to compare the processing speed with the code generated by qb64. when i got interested in qb64, i thought about using it to create command line programs under linux but i noticed a latency time when launching them and a processing speed much slower than freebasic. so i came back to freebasic but i continue to test qb64 and to follow this very interesting forum. RE: Comparison QB64 compiled with Ofast and without - mnrvovrfc - 08-15-2022 (05-07-2022, 09:07 AM)Coolman Wrote: :Instead of "_DELAY" statement you might want to put: DO: LOOP UNTIL _SCREENEXISTS RE: Comparison QB64 compiled with Ofast and without - madscijr - 08-15-2022 (08-15-2022, 04:22 PM)Pete Wrote: Nice! Thanks for speed testing. I hear you on the computer binary math errors, wouldn't it make sense to extend QB64 with native types that hold the bigger numbers and do the calculations without error, natively, at machine code speed? Or if we already have big enough types, to fix whatever under the hood causes these calculation errors? Because the string math is a good exercise, but it sounds like a band-aid for a bigger problem that needs to be fixed for real. Does that make sense? RE: Comparison QB64 compiled with Ofast and without - Pete - 08-15-2022 I did come across some C/C++ code, but those languages uses a math lib, so the code is not nearly as involved. I find it interesting in that QB64 is a c/C++ translator. To that end, if my assumption that the c/C++ languages have a built in math lib to call, why didn't the developers take advantage of it? As for FreeBASIC, I was there at its inception and everyone here knows I'm nott a fan, to put it mildly, but FB does have the advantage of compiling directly to binaries, where QB64 has to translate to c/c++ and then compile, so of course FB is going to be slower in that regard. My assumption is that once a "finished " project is in exe form, it becomes more a question of the most efficient way the routine was coded making it the fastest, no matter what language it is coded in. Pete RE: Comparison QB64 compiled with Ofast and without - madscijr - 08-15-2022 (08-15-2022, 05:08 PM)Pete Wrote: I did come across some C/C++ code, but those languages uses a math lib, so the code is not nearly as involved. I find it interesting in that QB64 is a c/C++ translator. To that end, if my assumption that the c/C++ languages have a built in math lib to call, why didn't the developers take advantage of it? If there are errors with binary math, we definitely should have that in the backlog of things to fix in QB64. Maybe changing to a different better C math library would be a good workable solution, that's something the developers would need to decide. I don't mind QB64 translating to C code which is then compiled to executable - as long as it works! I think this way of doing things probably makes it easier to port it to other operating systems (like Mac & Linux) since they all have C compilers. As long as it ends up as working native code, that's fine. It's great to be able to write one program that can be compiled to run natively on Windows, Mac and Linux. Anyway, we need to make sure any errors or issues get put on the QB64 "to do" list so they can eventually get fixed... RE: Comparison QB64 compiled with Ofast and without - Pete - 08-15-2022 Errors with binary math meaning errors occur when we use computer binary math to represent base 10 output. So it's not the language, it's the principle. For instance, try running the following... Code: (Select All) DIM j AS SINGLE You will see inaccuracies in both DIM models. So the computer counts in base 2, whatever the language. The only way around it is to make a math library for the language to access. Pete RE: Comparison QB64 compiled with Ofast and without - madscijr - 08-15-2022 (08-15-2022, 08:25 PM)Pete Wrote: Errors with binary math meaning errors occur when we use computer binary math to represent base 10 output. So it's not the language, it's the principle. For instance, try running the following... Sounds like a plan! (for someone with the time and interest! not me! lol) RE: Comparison QB64 compiled with Ofast and without - Coolman - 08-16-2022 (08-15-2022, 04:50 PM)mnrvovrfc Wrote:(05-07-2022, 09:07 AM)Coolman Wrote: :Instead of "_DELAY" statement you might want to put: It should be possible but if the window does not appear because of a bug, the program will be stuck in a perpetual loop. RE: Comparison QB64 compiled with Ofast and without - Coolman - 08-31-2022 i have redone the tests with qb64 3.0.0 to check that this version is stable and compatible with the old one. the result is globally positive. this version is faster during the compilations and the programs generated with O3 optimization are efficient. note that the binaries created by this version are always seen as shared libraries under linux with the dolphin file browser. i think it's a forgotten option in the command line of the compilation. i've looked at the modifications a bit. the work done is remarkable. simple code using pset 2.3x seconds : program compiled with qb64 v0.5.0 -O3 2.1x seconds : program compiled with qb64 v3.0.0 -O3 3.5x seconds : program compiled with qb64 v0.5.0 original Fractal Tree : I got this code from the site rosettacode. 2.9x seconds : program compiled with qb64 v0.5.0 -O3 3.0x seconds : program compiled with qb64 v3.0.0 -O3 6.1x seconds : program compiled with qb64 v0.5.0 original Bucketsort : I got this code from the site rosettacode. 1.1x seconds : program compiled with qb64 v0.5.0 -O3 1.0x seconds : program compiled with qb64 v3.0.0 -O3 3.4x seconds : program compiled with qb64 v0.5.0 original sorting algorithm QuickSort. 3.0x seconds : program compiled with qb64 v0.5.0 -O3 3.0x seconds : program compiled with qb64 v3.0.0 -O3 4.6x seconds : program compiled with qb64 v0.5.0 original Alien Trees Reflection - Plasma Mod. 5.3x seconds : program compiled with qb64 v0.5.0 -O3 5.4x seconds : program compiled with qb64 v3.0.0 -O3 9.2x seconds : program compiled with qb64 v0.5.0 original Nbody 16.9x seconds : program compiled with qb64 v0.5.0 -O3 16.5x seconds : program compiled with qb64 v3.0.0 -O3 68.0x seconds : program compiled with qb64 v0.5.0 original Picture unroller 1.3x seconds : program compiled with qb64 v0.5.0 -O3 1.1x seconds : program compiled with qb64 v3.0.0 -O3 2.5x seconds : program compiled with qb64 v0.5.0 original New screen - How ?. Found in the old forum. 1.4x seconds : program compiled with qb64 v0.5.0 -O3 1.1x seconds : program compiled with qb64 v3.0.0 -O3 2.3x seconds : program compiled with qb64 v0.5.0 original opens a text file of about 4 mo to read it line by line three times in a row with the use of Left$ InStr 6.5x seconds : program compiled with qb64 v0.5.0 -O3 6.3x seconds : program compiled with qb64 v3.0.0 -O3 7.2x seconds : program compiled with qb64 v0.5.0 original a very simple code that opens a text file of about 4 mo to read it line by line and copy it to a new file. 3.0x seconds : program compiled with qb64 v0.5.0 -O3 2.7x seconds : program compiled with qb64 v3.0.0 -O3 3.0x seconds : program compiled with qb64 v0.5.0 original here is another very simple code that copies a test file of about 4 mo to an array and copies the data randomly to another array. program compiled with qb64 v0.5.0 -O3 4.4x seconds : Read file and copy to table 7.1x seconds : Copy data randomly into another table. program compiled with qb64 v3.0.0 -O3 4.6x seconds : Read file and copy to table 8.3x seconds : Copy data randomly into another table. program compiled with qb64 v0.5.0 original 5.9x seconds : Read file and copy to table 27.4x seconds : Copy data randomly into another table. found a code in the old forum 13.2x seconds : program compiled with qb64 v0.5.0 -O3 10.88 seconds : program compiled with qb64 v3.0.0 -O3 26.2x seconds : program compiled with qb64 v0.5.0 original CRC-32 : I got this code from the site rosettacode. 6.7x seconds : program compiled with qb64 v0.5.0 -O3 6.9x seconds : program compiled with qb64 v3.0.0 -O3 17.6x seconds : program compiled with qb64 v0.5.0 original _Deflate (compression) and _Inflate (decompression) functions. program compiled with qb64 v0.5.0 -O3 : Function _Deflate : 10.1x seconds Function _Inflate : 1.2x seconds program compiled with qb64 v3.0.0 -O3 : Function _Deflate : 9.5x Function _Inflate : 1.2x program compiled with qb64 v0.5.0 original : Function _Deflate : 10.1x seconds Function _Inflate : 1.2x seconds RE: Comparison QB64 compiled with Ofast and without - Coolman - 09-02-2022 (08-31-2022, 09:30 PM)Coolman Wrote: note that the binaries created by this version are always seen as shared libraries under linux with the dolphin file browser. i think it's a forgotten option in the command line of the compilation. to solve the problem : Options / C++ Compiler Settings in the field C++ Compiler Flags I had the value -O3, I added -no-pie, which gives : -O3 -no-pie or only -no-pie if you don't want to use the O3 optimized compilation. |