PureBasic Forums - English

Faster programs, better optimized programs, and the possibility to port your programs easily to other platforms.

jacdelad wrote: Sat Jul 30, 2022 12:49 pm Faster programs, better optimized programs, and the possibility to port your programs easily to other platforms.

Sounds good, Thanks

chi wrote: Wed Jul 27, 2022 9:10 pm Anyway, would you be interested in such a 'ToolChainSwitcher'? Which compilers should be supported?

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.

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...

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...

Are the results in the zip?

skywalk wrote: Sun Jul 31, 2022 4:03 pm Are the results in the zip?

Spec.: Intel(R) Core(TM) i7-3930K CPU @ 3.80GHz
Cores: 6, Threads: 12, Memory: 16 GBytes
GPU: NVIDIA GeForce GTX 1060 6GB

What are the units of the results?
ms - milliseconds
fps - frames per second

If it's ms, why is opt slower?!

chi wrote: Sun Jul 31, 2022 10:57 am The problem with Zig is that it doesn't work on Windows 7 (and older) without a hack!

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:

Et cetera is my worst enemy

Is by any chance Et Cetera related to Peter Cetera?
I can fully understand, as I cannot listen to his music for a long time either...

skywalk wrote: Sun Jul 31, 2022 8:33 pm What are the units of the results?
ms - milliseconds
fps - frames per second

If it's ms, why is opt slower?!

The number of rendered screens in 10 seconds.... That's the way cologneskater did it with his/her original code and I was never bothered to change it. So technically you have to divide the numbers by 10.0 to get the fps

fsw wrote: Sun Jul 31, 2022 9:05 pm If Windows 7 is still your main operating system I can fully understand why you are reluctant to implement Zig as well.

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...

fsw wrote: Sun Jul 31, 2022 9:05 pm BTW: Your signature says:

Et cetera is my worst enemy

Is by any chance Et Cetera related to Peter Cetera?
I can fully understand, as I cannot listen to his music for a long time either...

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

So it appears gcc + opt is an excellent choice. Pity that 'volatile' is messing this up.

skywalk wrote: Mon Aug 01, 2022 3:32 am So it appears gcc + opt is an excellent choice.

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) :

skywalk wrote: Mon Aug 01, 2022 3:32 am Pity that 'volatile' is messing this up.

With and without volatile and Gcc -O2 (like every .exe)
Gcc with sinf() and without volatile: Gcc with Sin (double) and without volatile: With Sin (double) and with volatile:

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.

skywalk wrote: Mon Aug 01, 2022 3:32 am So it appears gcc + opt is an excellent choice. Pity that 'volatile' is messing this up.

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.