Different compilers
Re: Different compilers
Faster programs, better optimized programs, and the possibility to port your programs easily to other platforms.
PureBasic 6.04/XProfan X4a/Embarcadero RAD Studio 11/Perl 5.2/Python 3.10
Windows 11/Ryzen 5800X/32GB RAM/Radeon 7770 OC/3TB SSD/11TB HDD
Synology DS1821+/36GB RAM/130TB
Synology DS920+/20GB RAM/54TB
Synology DS916+ii/8GB RAM/12TB
Windows 11/Ryzen 5800X/32GB RAM/Radeon 7770 OC/3TB SSD/11TB HDD
Synology DS1821+/36GB RAM/130TB
Synology DS920+/20GB RAM/54TB
Synology DS916+ii/8GB RAM/12TB
Re: Different compilers
Sounds good, Thanks
Spec: Linux Mint 20.3 Cinnamon, i7-3770K, 16GB RAM, RTX 2070 Super
Re: Different compilers
What about Zig?
The Zig compiler has a C compiler built-in.
Also, Zig doesn't need make, cmake or something else, as the build file is written in Zig.
I am to provide the public with beneficial shocks.
Alfred Hitshock
Re: Different compilers
The problem with Zig is that it doesn't work on Windows 7 (and older) without a hack!
I posted the hack on reddit, but that was for zig-windows-x86_64-0.10.0-dev.1606, where all you had to do was to replace GetSystemTimePreciseAsFileTime (kernel32.dll) with GetSystemTimeAsFileTime inside Zig.exe and you also had to patch every executable you created. I did a test with a simple "hello world" and was able to compile and run it on Win7, Vista, Xp and Win2000, but I never tried a larger project. Maybe there are more problems?!
However, with zig-windows-x86_64-0.10.0-dev.3385 the hack doesn't work anymore because there is also a problem with RtlWaitOnAddress (ntdll.dll) which is not so easy to solve. Maybe I should contact Andrew Kelley (Zig creator) and ask if there are any plans to port Zig to older Windows versions...
I posted the hack on reddit, but that was for zig-windows-x86_64-0.10.0-dev.1606, where all you had to do was to replace GetSystemTimePreciseAsFileTime (kernel32.dll) with GetSystemTimeAsFileTime inside Zig.exe and you also had to patch every executable you created. I did a test with a simple "hello world" and was able to compile and run it on Win7, Vista, Xp and Win2000, but I never tried a larger project. Maybe there are more problems?!
However, with zig-windows-x86_64-0.10.0-dev.3385 the hack doesn't work anymore because there is also a problem with RtlWaitOnAddress (ntdll.dll) which is not so easy to solve. Maybe I should contact Andrew Kelley (Zig creator) and ask if there are any plans to port Zig to older Windows versions...
Et cetera is my worst enemy
Re: Different compilers
If somebody is interested, I've uploaded a small benchmark. The original code (plasma) is from cologneskater and Realizimo from the forum, but I also made some changes. In the zip file are .pb, .c and .exe files, each compiled with _imp or _imp_opt with the C backend (x64). _imp means that sinf() was imported from msvcrt.lib, since Sin() is imported as DOUBLE with PB6, but as FLOAT it is ~twice as fast. For _imp_opt, the .c code was manually optimized afterwards. I've tested Asm, Gcc, Clang, MSVC and Zig.
bm3.zip
If there is any AV screaming, it's probably a false positive. I'm not gonna force you to run the .exe in any case...
bm3.zip
If there is any AV screaming, it's probably a false positive. I'm not gonna force you to run the .exe in any case...
Et cetera is my worst enemy
Re: Different compilers
Are the results in the zip?
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Re: Different compilers
Code: Select all
143 - bm3_asm_imp.exe
173 - bm3_clang_imp.exe
215 - bm3_clang_imp_opt.exe
180 - bm3_gcc_imp.exe
279 - bm3_gcc_imp_opt.exe
282 - bm3_msvc_imp_opt.exe
170 - bm3_zig_imp.exe
219 - bm3_zig_imp_opt.exe
Spec.: Intel(R) Core(TM) i7-3930K CPU @ 3.80GHz
Cores: 6, Threads: 12, Memory: 16 GBytes
GPU: NVIDIA GeForce GTX 1060 6GB
Et cetera is my worst enemy
Re: Different compilers
What are the units of the results?
ms - milliseconds
fps - frames per second
If it's ms, why is opt slower?!
ms - milliseconds
fps - frames per second
If it's ms, why is opt slower?!
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Re: Different compilers
If Windows 7 is still your main operating system I can fully understand why you are reluctant to implement Zig as well.
BTW: Your signature says:
Is by any chance Et Cetera related to Peter Cetera?Et cetera is my worst enemy
I can fully understand, as I cannot listen to his music for a long time either...
I am to provide the public with beneficial shocks.
Alfred Hitshock
Re: Different compilers
Code: Select all
time = ElapsedMilliseconds() + 10000
Repeat
WindowEvent()
Paint()
counter + 1
Until ElapsedMilliseconds() > time
Windows 7 is not really the problem here, since it worked with Zig_dev10_1606 (see zip). But I was not able to compile the exe with "zig cc ..." in one run. I had to use "zig build-obj ..." to generate the PureBasic.obj and use PB's default toolchain (Pelles C porc.exe and polink.exe) to link the .libs to the .exe. Similar to PB's way of using FAsm/Gcc + porc + polink. Zig is using LLVM's Clang (clang.exe + llvm-rc.exe + lld-link.exe) with GNU/Gcc archives (.a [static library] + .so [shared object]), that are more or less Unix/Linux based (but usable on Windows with mingw64), and not with Windows' libs (.lib), which is Microsoft's native way (.lib + .dll). Purebasic on Windows is using .libs and .dlls ever since, that's why Fred is using the rest of Pelles C tool chain for creating resources (.rc), linking static/dynamic libraries (.lib) or creating import libraries (also .lib). I managed to get Zig's one shot approach (zig cc ...) down to a few errors (duplicate exports or missing export symbols), but was not able to completely solve the problem. There are many sites/forums on the internet complaining about similar experiences.
TL;DR: So Zig just uses Clang, maybe somewhat modified, but still. It' s nice to be able to convert .c code to Zig code though (zig translate-c ...) if you want to do programming with Zig...
Lol no, it's a reference to my early childhood watching Yul Brynner's "The king and I", where he continuously said "et cetera, et cetera, et cetera" and later, in my teenage years, listening to grunge and alternative metal having a flashback with Faith No More's "Absolute Zero", where the phrase is coming from
Et cetera is my worst enemy
Re: Different compilers
So it appears gcc + opt is an excellent choice. Pity that 'volatile' is messing this up.
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Re: Different compilers
In case of the Plasma demo, yes! Gcc and MSVC is a good choice. MSVC wins with 3 frames more and a lesser executable size (better linking).
Here is a comparison between Graphics API's...
Gcc with sinf(), without volatile + manual opt (bm3_imp_opt.c) :
Code: Select all
279 - DirectX9 - bm3_gcc_imp_opt.exe
280 - DirectX11 - bm3_gcc_imp_opt.exe
239 - OpenGL - bm3_gcc_imp_opt.exe
With and without volatile and Gcc -O2 (like every .exe)
Gcc with sinf() and without volatile:
Code: Select all
200 - DirectX9 - bm3_gcc_imp_novol.exe
200 - DirectX11 - bm3_gcc_imp_novol.exe
178 - OpenGL - bm3_gcc_imp_novol.exe
Code: Select all
176 - DirectX9 - bm3_gcc_def_novol.exe
176 - DirectX11 - bm3_gcc_def_novol.exe
158 - OpenGL - bm3_gcc_def_novol.exe
Code: Select all
159 - DirectX9 - bm3_gcc_def.exe
154 - DirectX11 - bm3_gcc_def.exe
144 - OpenGL - bm3_gcc_def.exe
Although Clang seems to be slow with PB's 2D/3D applications, everything not related to 2D/3D feels a bit faster and snappier than with Gcc (and it is). So in that respect, Clang is more neck-to-neck with MSVC (which always comes out on top in everything). It's a trade-off.
Et cetera is my worst enemy
Re: Different compilers
The one problem with it that it compiles much slower than PB ASM compiler, especially if turned on optimizations on a large code.
I don't know if there any threading options in GCC and does PB uses them, but surely slower.
"W̷i̷s̷h̷i̷n̷g o̷n a s̷t̷a̷r"