Blog post !

Developed or developing a new product in PureBasic? Tell the world about it.
Yann64
User
User
Posts: 24
Joined: Wed Nov 10, 2004 1:06 pm
Contact:

Re: Blog post !

Post by Yann64 »

Mijikai wrote:I dont see how dropping the soap and then asking for another one is helping PBs development.
Both GCC or Clang get ported reasonably quickly to new archs and new OSes (clearly fasm does not help on that point). Most of the libs for non-gui stuff will be easy to port.
Also, it will open the door to cross compiling, and easier porting of PB to less common platforms, at least for the non GUI part (thinking of BDSs which are fairly close to Linux/unix, or even Haiku).

You are clearly not picking the same category of soap...
Last edited by Yann64 on Sun Mar 14, 2021 10:41 pm, edited 1 time in total.
User_Russian
Addict
Addict
Posts: 1443
Joined: Wed Nov 12, 2008 5:01 pm
Location: Russia

Re: Blog post !

Post by User_Russian »

I assume Inline C will be available?
Then it's better to use C++. It is C compatible, but much more powerful and flexible.
cas
Enthusiast
Enthusiast
Posts: 597
Joined: Mon Nov 03, 2008 9:56 pm

Re: Blog post !

Post by cas »

STARGÅTE wrote:I have a lot of include and modules in which I use inline ASM code for speed optimization.
Can I still use them for x86 and x86-64 processor architecture or do they become invalid in future PB versions?
You will remove ASM code and replace it with regular PB code and C compiler will do speed optimizations for you. Final binary will be as fast or most probably even faster (in many cases) than your custom ASM code. And your PB source code will be more readable. Win-win.
User avatar
STARGÅTE
Addict
Addict
Posts: 2067
Joined: Thu Jan 10, 2008 1:30 pm
Location: Germany, Glienicke
Contact:

Re: Blog post !

Post by STARGÅTE »

cas wrote:
STARGÅTE wrote:I have a lot of include and modules in which I use inline ASM code for speed optimization.
Can I still use them for x86 and x86-64 processor architecture or do they become invalid in future PB versions?
You will remove ASM code and replace it with regular PB code and C compiler will do speed optimizations for you. Final binary will be as fast or most probably even faster (in many cases) than your custom ASM code. And your PB source code will be more readable. Win-win.
I am not convinced of that. In some cases there is no equivalent regular PB code for the ASM code (for example the SSE instructions) in other cases I'm not sure that the C compiler is better in optimizing than myself. Even in GMP documentation they wrote: "The speed of GMP is achieved [...] by including carefully optimized assembly code for the most common inner loops for many different CPUs, and by a general emphasis on speed (as opposed to simplicity or elegance).".
With directly written ASM I can write machine code directly optimized for my/a CPU, depending on the latency and reciprocal throughput for each instruction. It would be sad if PB lost this feature.
But of course, reaching other platforms would be useful for some PB users and I still have the option using the LTS version :lol:
Keya wrote:yes, C supports inline asm. and yes, you'd still be able to compile object files and libraries in asm and include them in PB, just as you already can (C already has this capability)
Good to hear.
PB 6.01 ― Win 10, 21H2 ― Ryzen 9 3900X, 32 GB ― NVIDIA GeForce RTX 3080 ― Vivaldi 6.0 ― www.unionbytes.de
Lizard - Script language for symbolic calculations and moreTypeface - Sprite-based font include/module
BarryG
Addict
Addict
Posts: 3292
Joined: Thu Apr 18, 2019 8:17 am

Re: Blog post !

Post by BarryG »

STARGÅTE wrote:I still have the option using the LTS version
I bet there's going to be a lot of speed tests happening in future.
User avatar
Tenaja
Addict
Addict
Posts: 1948
Joined: Tue Nov 09, 2010 10:15 pm

Re: Blog post !

Post by Tenaja »

BarryG wrote:
STARGÅTE wrote:I still have the option using the LTS version
I bet there's going to be a lot of speed tests happening in future.
I'll bet you are right!

I will also be surprised if ASM is removed altogether. Sure, it will not work for all targets, but Fred tries not to break code and lose features.
cas
Enthusiast
Enthusiast
Posts: 597
Joined: Mon Nov 03, 2008 9:56 pm

Re: Blog post !

Post by cas »

STARGÅTE wrote:...
SSE instructions do not need to be explicitly called. You just tell to your compiler what is your desired CPU architecture for compiled binary and it will produce best code for that architecture based on available instructions of that architecture. Custom extremely optimized handwritten ASM code can be faster (like in the example of GMP) but it is hard to write and understand. Not very practical. In most cases, it is better to sacrifice small performance uplift (that is probably only noticeable in benchmarks) for better code readability and portability.
When this new PB version will be released, we will benchmark our current ASM implementations vs native PB implementations of our algorithms and every time when we will see very little or no performance increase (that will be the case most of the time), we will replace that ASM code parts with native PB code to make it architecture independent and more readable.
User avatar
Tenaja
Addict
Addict
Posts: 1948
Joined: Tue Nov 09, 2010 10:15 pm

Re: Blog post !

Post by Tenaja »

cas wrote:
STARGÅTE wrote:...
SSE instructions do not need to be explicitly called. You just tell to your compiler what is your desired CPU architecture for compiled binary and it will produce best code for that architecture based on available instructions of that architecture. Custom extremely optimized handwritten ASM code can be faster (like in the example of GMP) but it is hard to write and understand. Not very practical. In most cases, it is better to sacrifice small performance uplift (that is probably only noticeable in benchmarks) for better code readability and portability.
When this new PB version will be released, we will benchmark our current ASM implementations vs native PB implementations of our algorithms and every time when we will see very little or no performance increase (that will be the case most of the time), we will replace that ASM code parts with native PB code to make it architecture independent and more readable.
Cas, when did you join the dev team?
User avatar
Danilo
Addict
Addict
Posts: 3037
Joined: Sat Apr 26, 2003 8:26 am
Location: Planet Earth

Re: Blog post !

Post by Danilo »

User_Russian wrote:Then it's better to use C++. It is C compatible, but much more powerful and flexible.
Beside BCX there is also Wonkey (github.com/wonkey-coders/wonkey) which translates to C++ and can import C and C++ libraries.
cas
Enthusiast
Enthusiast
Posts: 597
Joined: Mon Nov 03, 2008 9:56 pm

Re: Blog post !

Post by cas »

Tenaja wrote:Cas, when did you join the dev team?
I do not need to join the dev team to know that c compilers that are being developed for the last 20-30+ years by thousands of experts and are constantly being improved by open source community will produce better binaries than what we currently have with PB. Everyone in our PB community will profit from this switch to c backend.
I currently use msvc with /O2 and /arch:SSE2 for max compatibility with older CPUs to compile translated PB -> C code and it is faster than native PB binaries. And gcc is apparantely producing even faster binaries but unfortunately i did not manage to make it work with PB. PB compiler crashes (specifically polink.exe) when i import static lib compiled with anything higher than -O0 and -mach=core2 and that is just not comparable to msvc with /O2.
User avatar
the.weavster
Addict
Addict
Posts: 1537
Joined: Thu Jul 03, 2003 6:53 pm
Location: England

Re: Blog post !

Post by the.weavster »

Danilo wrote:Beside BCX there is also Wonkey (github.com/wonkey-coders/wonkey) which translates to C++ and can import C and C++ libraries.
Looks cool but I couldn't find a Get Started tutorial 8)
And an example of importing C (preferably webview) would be very interesting :D
Fred
Administrator
Administrator
Posts: 16619
Joined: Fri May 17, 2002 4:39 pm
Location: France
Contact:

Re: Blog post !

Post by Fred »

That's a lot of comments about the new back-end :) ! Let's clarify some points:

- The x86-x64 asm compilers will still be supported, we don't have a plan to drop them at this point
- The C backend will take time to mature, but will be available for all platform to make it better. It will be based on gcc, and shipped in the PB installer for Windows (nothing to install, plug and play). You could choose your compiler like you do when installing several version of PB)
- Inline C will be supported
- Inline ASM won't be supported directly at start. We plan to add naked ProcedureASM : EndProdecure which will create an assembly file, use fasm and link it to the final exe without needed to do anything
- Compilation in dev mode should be fast as we disable all optimisation in the C compiler and we don't have any include file (flat .c file)
- Compilation in release mode will be much longer, but will produce much faster code especially on processing code (heavy memory data manipulation). If you don't have a lot of processing in your app, and using mostly PB commands, it shouldn't have a big difference.
- From an user point of view, you shouldn't notice anything unless you deal with inline ASM
- It could be some limitation in the C back-end (we have trouble to implement GOSUB properly for example), but it should be very specific and not core functions.

I will do a series of post on the blog regarding the progress and going deeper about this choice, with PRO and CONS about this.

Also don't get too excited, it's not ready for release, even alpha. For example the debugger is not supported yet :)
User avatar
Danilo
Addict
Addict
Posts: 3037
Joined: Sat Apr 26, 2003 8:26 am
Location: Planet Earth

Re: Blog post !

Post by Danilo »

the.weavster wrote:
Danilo wrote:Beside BCX there is also Wonkey (github.com/wonkey-coders/wonkey) which translates to C++ and can import C and C++ libraries.
Looks cool but I couldn't find a Get Started tutorial 8)
You may want to join the Discord Chat to ask questions.
the.weavster wrote:And an example of importing C (preferably webview) would be very interesting :D
You need to write a module like the included modules (SDL2, GLFW, Sokol, pigpio, etc.)

Examples:
- /modules/raspberry/pigpio/pigpio.wx
- /modules/stb-image/stb-image.wx
- /modules/sqlite/sqlite_extern.wx

You basically just import .h/.hpp/.c/.m/.mm/.cpp/.a/.o/.lib/.framework/.dylib files and write struct/function declarations.
Last edited by Danilo on Mon Mar 15, 2021 10:51 am, edited 1 time in total.
User avatar
jacdelad
Addict
Addict
Posts: 1432
Joined: Wed Feb 03, 2021 12:46 pm
Location: Planet Riesa
Contact:

Re: Blog post !

Post by jacdelad »

Regarding that we can choose which compiler to use: Does this mean the compiler we use at the moment will still be in development?

Also, and please remember I'm still new to PureBasic, I never used gosub and from what I heard about other languages it's obsolete (e.g. XProfan dropped a while ago). Is this really needed in the future?
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
User_Russian
Addict
Addict
Posts: 1443
Joined: Wed Nov 12, 2008 5:01 pm
Location: Russia

Re: Blog post !

Post by User_Russian »

Fred wrote:we have trouble to implement GOSUB properly for example
I think that gosub can be abandoned.
Fred wrote:don't have any include file (flat .c file)
C supports separate compilation (each c file is compiled separately). This allows you to run how many instances of the compiler, how many cores there are in the processor. This will speed up compilation.
Post Reply