Interview by Quin and Enne

Hi Fred, and happy holidays !

Nsstudios (Enne) and me have compiled this list of questions for you about Pure/SpiderBasic, and Fantaisie software in general. I hope they’re all okay to ask !

Part 1: Private Life

Quin: It’s been quite some time since the last interview with you. What does your personal situation look like now? Do you have any kids, where are you living, etc?

    Hi Quin and Enne, thanks for coming up with this interview ! On a personal standpoint, my life greatly changed since the last interview which was almost ten years ago. I’m married since 10 years, got 2 boys which are now 8 and 5 so they are old enough to get back some free time the evening/night 😄. We live in the Paris suburb, and I have a daily work in a big french bank named SG.

    Quin: How do you feel about where PureBasic/SpiderBasic currently stand? You just did the major SB 3.00 release and the first beta of PB 6.20 dropped just a few days ago. How do you feel about the direction of Fantaisie Software’s products in recent months/years?

      I’m pretty proud of where we actually stand, with two robust products which found their audience. Please bear in mind that while I’m the main guy working on these products, I get help from many other people to improve the final products (to translate the docs, to do some IDE enhancement, to help with the 3D engine, even writing new libraries). For PureBasic, which is the more complex of the both due to the native machine code nature of the compiler, I feel like it’s now a mature product which covers a lot of area and allow to write very fast native looking cross platform programs and games. The time spent these last years to fix many remaining issues pays off and the new bugs reports are less frequent that it once was. About SpiderBasic, it’s a bit different as it’s still a kind of new product for me, even if it has like 10 years now ! It takes more time to get things rights but the latest 3.00 version is very big step forward with an integrated web view, debug output in the IDE and a new mobile UI. More people are actually building apps with it, so it’s a good sign for the future.

      Quin: How much time do you tend to spend on SpiderBasic vs. PureBasic? In general, does one take priority over the other?

        I try to not to, but PureBasic was getting more attention lately due to some important changes (new CRT, old timers bug fixes, new C back-end, OGRE3D update). I expect this to change starting from this year to have more evenly spread time across these two.

        Quin: How do you decide what exactly to work on? Is it whatever seems most manageable, or something that presently interests you?

          Lately it was more doing the essential stuffs on PureBasic to keep it up-to-date and working on new OS. There were not that much new features in the last few years and I hope it will change as I indeed prefer to write some new code which enhance the compiler/command-set than fixing things which used to work in the past.

          Enne: How did you come up with the idea to make PureBasic? What would you do differently if you were to make PB today? Do you have any regrets?

            PureBasic finds its root in the (old) Amiga days and is a spiritual successor of BlitzBasic. At that time, there was accelerators cards which were released on Amiga using PowerPC chips (the Amiga used 680×0 chips) and BlitzBasic wasn’t supporting these. So I wrote a kind of fork from scratch to support PowerPC. It started like that, and then when the Amiga finally died, I moved on PC and ported PureBasic for x86. If I were to start PureBasic nowadays, it would be a different product because I have a lot more experience now. But I got this experience while building PB, so you it’s hard to have any regrets. I think the only regrets I have is to have spend so much time on now dead ASM back-end/API (PowerPC for macOS, x86 for macOS, Carbon for macOS). I should have switch to a C back-end much sooner.

            Enne: Do you use PureBasic or SpiderBasic for your projects outside of PB/SB development? Can you tell us what you use them for if so?

              I use PB to build tools for managing PB and SB build process. Except from that I don’t use them anymore for other projects. I would like to find the time to use SB to build a good kid game for Android/iOS but right now it’s out of reach.

              Enne: What do you find most rewarding about maintaining PureBasic and SpiderBasic?

                The most rewarding thing is to see this heathly community around these products, with good help results. I like to follow the projects done with these products as well.

                Quin: How do you balance your personal life with maintaining and developing PB and SB?

                  I keep some time for the family on the week-end and during the vacation, it’s not difficult. The evenings are for development though (and I can be up late) !

                  Quin: While SB certainly isn’t a dead product, it’s been observed that its forums are nowhere near as active or lively as the PB forums, despite its age. Is this something you see ever possibly changing? I for one love SB, I think it just hasn’t had its moment in the sun.

                    It’s hard to get a spot in the mobile app development as there is so many tools which are free and got the momentum. But I still think it’s getting better and if SB works as it should (which is not always the case TBH) it should find its audience. It’s a good all-in-one package which can deliver complex mobile apps in a BASIC way, with no additional setup to do. Time will tell !

                    Part 2: Computer Programming / Business in General / PB Team-Work

                    Quin: Is there any kind of approval process for pending changes (e.g., if you make a change, does it have to get approved by anyone else on the team)?

                      No, I approve my own work 😄. And if someone else contribute for internal libraries (for example Timo (Fr34k) for the internal libraries or Pf Shadoko for the OGRE 3D engine) he can push directly and I will change the things later if needed.

                      Enne: How profitable is PureBasic, considering its single payment model? What are your thoughts on switching PB to a different payment model?

                        It’s profitable because the cost of shipping a software is low, but it doesn’t bring a lot of money, that’s why I get a daily job. In France new taxes are coming for small businesses this year so I’m planning to switch to same payment model than SpiderBasic soon (1 year free update included, then if you need the most recent version you have to subscribe for another year at a discounted price).

                        Enne: I recently saw that DLL hijacking protection was sponsored by a forum member. Is sponsoring features something anyone can do? How does someone go about it, and what are the requirements? Would you accept syntax additions through sponsorship?

                          Yes, everyone can contact me trough PM on the forum or email to discuss about sponsored features. I don’t accept everything, it needs to be something useful for the whole community. Once we agree on a price, I give a reasonable time-frame for the implementation and it will make it way for the next major release. Prices are usually low for specific development, between 100 and 500 €.

                          Quin: There are some things (like faster strings) that would be amazing to have implemented but aren’t super fun to work on. At what point do you buckle down and decide to do something even if it’s not enjoyable to code?

                            I do major overhaul only if really necessary. Faster strings could be cool (mostly with cached length) but for speed critical apps, you can work with string builders or directly with pointers. Actually, a string rework seems very cool to work on, but it’s too time consuming right now.

                            Enne: How manageable would you say the compiler source code is, given how long PureBasic has existed?

                              I would say it’s barely manageable and very messy. The whole project is a pain to work but I guess it’s not that unusual for a project which has grown over 30 years. I won’t do the Netscape mistake (a must read BTW) to ditch all this working code to restart from scratch and hope for the best.

                              Enne: What are the biggest challenges of working on PureBasic and SpiderBasic as a small team?

                                The biggest challenges are to keep up with the ever coming changes in the IT world. Nothing is definitive you always have to keep up the pace. For example, Windows is now on ARM64 with Copilot+ PC and we needed to support it quickly. Also finding the time to deliver the products with new features on regular basis is not an easy task.

                                Part 3: PureBasic / SpiderBasic History and Review

                                Enne: If I understand correctly, you have expressed explicit dislike of adding OOP to PB, yet the IDE itself features simulated OOP through virtual tables. Why are you against adding OOP support to the language?

                                  OOP is an advanced programming concept which is not inline with BASIC and the PureBasic target which is to allow people with few programming knowledge to learn and create something. Small OOP programs are OK to me, but my experience is it quickly become hard to maintain and to understand, and side effects can very quickly become a nightmare.

                                  Quin: Following up on the OOP question, is something like allowing us to declare procedures on structures ever going to be a possibility, thus eliminating the need for a virtual table and datasection, just having the compiler do it for you, including management of the *This pointer?

                                    This is not real OOP and it could be something doable. Inheritance, overriding, polymorphism, scopes won’t be available so it would greatly reduce the possible side-effects.

                                    Enne: PB updates often include tooling and library improvements, but the syntax seems stagnant. Why is that? Are there specific reasons why syntax additions or updates are rare?

                                      Yes, because it takes a lot of time as you need to change the code emitting backends (x86, x64, C). If one day only the C backend is remaining, I guess the syntax additions would be easier to do.

                                      Quin: Is there any chance of SpiderBasic/PureBasic ever compiling to WebAssembly?

                                        No, I don’t think so.

                                        Enne: What would you suggest to someone interested in making their own compiler, but who finds the task daunting?

                                          Just start and don’t look ahead. PB hasn’t been done in one day, it’s years of building blocks. You can also start by reading books about how doing your own compiler, as there is a lot of frameworks available to ease this task. PB is a full custom compiler which has some advantages (fast) but also some drawbacks (single pass).

                                          Quin: What are the most significant milestones in the development of PureBasic and SpiderBasic that you’re particularly proud of?

                                            For PB:

                                            • First released version on Amiga 680×0
                                            • First true multi-platform release (Windows and Linux)
                                            • True multi-platform IDE (Win32, GTK, Cocoa, QT)

                                            For SB:

                                            • First Android and iOS app creation
                                            • Integrated Web View and debugger
                                            • Mobile UI

                                            Part 4: Questions About the Future of PureBasic / SpiderBasic

                                            Enne: What are your thoughts on the future of PureBasic and its sustainability? In which direction would you like it to go? Are there any plans or things you’re currently working on that you can share with us?

                                              As I don’t rely on PureBasic incomes I can say it will continue for years and years. I actually don’t have any plan to stop, as PureBasic has never been in any better shape than now and I can steadily improve it, step by step. I also like very much working on it and it’s definitely a big part of my life and my identity. The current plans are to finally review all the IDE bugs from the English forum and start to fix them. I also want to review the remaining bugs in the Windows sub-forums to see what can be done. About the new features, I would like to add an HID/USB lib to PB.

                                              Enne: How do you envision the long-term evolution of SpiderBasic? Are there specific features or goals you hope to achieve?

                                                The next steps is to allow Android app creation on Linux/macOS and then add more commands to create a native-looking app with all the standard feature you can expect.

                                                Quin: What do you think is the biggest challenge in keeping PureBasic and SpiderBasic relevant for future developers?

                                                  You need to follow the trends, and keep giving something powerful and easy enough to use so it worths the invested money. For example, it would be great to have better result for PureBasic code generation from the IA bots, as it will quickly become a must have for all the languages. Those which won’t be good in IA will probably be deprecated fast.

                                                  Enne: How do you plan to handle maintaining PureBasic and SpiderBasic over the next decade? Are there any thoughts on succession or expanding the team?

                                                    I guess, unless the sales starts to rocket, nothing will really change on this side, as I can’t afford to pay anyone else. One way to expand the team would be to switch fully to Opensource but then it will be hard to monetize the projects and while it’s not enough for a full salary, it still helps !

                                                    Thank you both and see you !

                                                    End of PureBasic LTS version

                                                    Twelve years ago, we introduced a new way of delivering PureBasic by implementing an LTS (Long-Term Support) version, which received bug fixes for two years (see this blog post for more details). At that time, the release process was relatively simple:

                                                    • 2 Linux packages
                                                    • 2 Windows packages
                                                    • 2 macOS packages

                                                    Additionally, major releases that introduced breaking changes were more frequent.

                                                    Fast forward to today, managing PureBasic across platforms has become significantly more complex:

                                                    • 4 Linux packages (each with both ASM and C backends)
                                                    • 2 Raspberry Pi packages
                                                    • 2 macOS packages (one with ASM and C backend)
                                                    • 3 Windows packages (each with both ASM and C backends)

                                                    This increase in complexity has made the build process far more time-consuming. As a small team, maintaining both the LTS and regular versions—while ensuring bug fixes are properly merged and retested across branches—has become unsustainable.

                                                    Meanwhile, the PureBasic API has matured, resulting in fewer breaking changes with each major version. As a result, the need for an LTS version has diminished.

                                                    Going forward, our plan is to follow each major release with one or more minor updates to fix any new bugs. This approach should provide a stable production environment while ensuring smooth, hassle-free migration from one major version to the next.

                                                    Keep It Fresh

                                                    A software needs to evolve and keep up with trends, especially when that software, like PureBasic, is intended to create other software. Over the past few years, we’ve dedicated a lot of time to fixing many old bugs and updating most of the third-party libraries to their latest versions (Scintilla, libcurl, libjpg, libpng, PCRE, etc.).

                                                    When we started working on PureBasic almost 30 years ago, there was no easy way to build these third-party libraries across all operating systems supported by PureBasic. As a result, we decided to write specific makefiles for each library. The problem with custom makefiles is that they can’t automatically track new or removed files, new compiler definitions, and other small specifics, which made updating C libraries difficult. This became a recurring issue for all libraries, and fortunately, CMake was created to solve that. It began to gain real traction around 2010, and nowadays, almost all C libraries have CMake build support, which has greatly simplified keeping third-party libraries up to date, as much of the work is done automatically across all operating systems. You usually only need to run two commands, and the library is built using the native OS compilers (Visual Studio on Windows, Xcode on macOS, and GCC on Linux). We started migrating to CMake a few years ago, which wasn’t exactly an easy task, as the regular makefiles were deeply integrated into the build pipeline, but now it works. For example, LibreSSL is fully built using CMake on all operating systems.

                                                    A major component of PureBasic is the 3D Engine, which relies on OGRE. We haven’t updated the engine in 10 years due to the massive scale of OGRE, which has many dependencies, all of which needed to be updated simultaneously (each dependency also had its own custom makefiles). It could take months of work just to get everything up to date across all operating systems, so we decided to postpone this as much as possible. However, with the new experience we gained from CMake, it was time to switch from custom makefiles to native CMake files. After just one week of work, we had a beta version working across all operating systems! The good news is that the update should be virtually seamless, as the dependencies will now be updated automatically. A lot of time was spent updating the PureBasic OGRE wrapper, as many changes occurred over the past 10 years, which wouldn’t have been necessary had the updates been applied regularly.

                                                    The next step is to convert all remaining custom makefiles to CMake to ensure that we can keep all libraries fully updated with every new PureBasic release. This will be a significant improvement in terms of security and performance for all applications created with PureBasic !

                                                    Upgrading the Windows build chain

                                                    Since the very first Windows version of PureBasic (23 years ago), we decided to stick with the built-in MSVCRT.dll to avoid to ship others DLLs along the created PureBasic executables. It allowed to have very small executables (as small as 10 KB) without any dependencies (PureBasic programs never had to enjoy the famous DLL hell which plagued many other programming language at time). Unfortunately, overtime the MSVCRT.dll was becoming older and older because it wasn’t updated by Microsoft which was pushing for using specific DLL from VisualStudio. The side effect of sticking to the old MSVCRT.dll is the added complexity to integrate new third party libraries (like libcurl, sqlite, scintilla and so on) into PureBasic because we can’t access new C functions, or new C++ features. So we had to patch the libs to have them linking properly, was very time consuming to try to emulate new functions with a mix of old functions. We still did this (painful) extra work while we were supporting Windows XP but it’s now going to an end with the PureBasic 6.10 version.

                                                    Once XP support was dropped, we could use Visual C++ 2022 (which doesn’t support XP anymore) and started to update the whole build chain. It took a lot of time to update the libraries and to be able to link the MS runtime statically, but it’s finally working ! The good news is we can now use an up-to-date C++ compiler which make our work much more easier and faster (the first new library we are integrating for 6.10 is the WebView one, which requires C++17). The drawback to link statically the MSVC runtime is bigger executables, so smaller one starts in the 150 KB range (still very small anyway by nowadays standards). But there is no DLL dependency, and we could even reduce one DLL dependency by statically linking Scintilla (which wasn’t possible with the old MSVCRT.dll).

                                                    So far, so good, we’re all set for the future on Windows and you should enjoy soon faster PureBasic executables (the whole command-set is now recompiled with a better C compiler) and more modern commands, like WebView, coming up faster !

                                                    PureBasic Non-Regression Suite

                                                    When writing massive software like PureBasic, you need to have automated tests to validate it and ensures there is no regression when publishing a new version. We will try to explain how we achieve this for PureBasic and why it is essential for the product robustness.

                                                    First, let’s recap the main PureBasic components and their size:

                                                    • The compiler, which is about 250k lines of C, generating x86 asm, x64 asm and C
                                                    • The IDE, written in PureBasic which is about 130k lines of code
                                                    • The libraries, written for 3 platforms (Linux, Windows, OS X) in ASM, C, C++ or Objective C which are about 1.200k lines of code

                                                    Each time a compiler bug is squashed, we add a new test in the test suite to ensures it won’t happen again. For now, there is more than 2500 unit tests covering all public features of the PureBasic language, validating the syntax and ensuring the results are corrects. Theses tests are run in different context (Threaded mode ON/OFF, debugger ON/OFF, Optimizer ON/OFF) and if one of these tests fail, the build script is aborted. These tests are just written in standard PureBasic files, compiled into a single executable and run all at once. Each platform runs these tests. Here is a small example of how it looks from the AritmeticFloat.pb file:

                                                    ; Float promotion
;
Check(Round(Val("2") * 1.2, #PB_Round_Nearest) = 2)

Integer.i = Round(Val("3") * 1.2, #PB_Round_Nearest)
Check(Integer = 4)

Integer = 1
Integer = Integer + Round(Val("2") * 1.5, #PB_Round_Nearest)
Check(Integer = 4)

Integer = 1
Integer = Integer - Round(Val("2") * 1.5, #PB_Round_Nearest)
Check(Integer = -2)

Integer = 2
Integer = Integer * Round(Val("2") * 1.5, #PB_Round_Nearest)
Check(Integer = 6)

Integer = 9
Integer = Integer / Round(Val("2") * 1.5, #PB_Round_Nearest)
Check(Integer = 3)

; Constant rounding
;
Integer.i = 0.6 * 2 ; rounded to 1
Check(Integer = 1)

Integer = 0.9 * 2 ; rounded to 2
Check(Integer = 2)

Integer = 0.6 ; rounded to 1
Check(Integer * 2 = 2)

                                                    When we work on the libraries, it’s a bit different, as we use the PureUnit tool (which can be found freely in the SDK) which is similar to NUnit or JUnit if you know those tools. It is very good at writing single commands tests, and provide a solid way to run the tests randomly, in different modes (Threaded, with different Subsystems, etc.). When a bug is fixed in a library we add a test when it’s possible (testing UI, Sprites, 3D engine is complicated as you can’t really check the graphical output). The Syntax is very easy to use as you can see from this example taken from the String library unit test file:

                                                    ProcedureUnit InsertStringTest()
  Hello$ = "Hello"
  World$ = "World"
  AssertString(InsertString("Hello !", World$, 7), "Hello World!")
  AssertString(InsertString("Hello !", World$, 8), "Hello !World")
  AssertString(InsertString("Hello !", World$, 1), "WorldHello !")
  AssertString(InsertString("Hello !", World$, -1), "WorldHello !") ; Test with out of bounds value
  AssertString(InsertString(Null$, Null$, 1), "") ; Null values should be accepted as well
  AssertString(InsertString("", "Hello", 1), "Hello") ; Inserting empty string shouldn't touch the string
  AssertString(InsertString(Null$, "Hello", 1), "Hello") ; Inserting null string shouldn't touch the string
  
  AssertString(InsertString(Hello$+Hello$, World$+World$, 6), "HelloWorldWorldHello") ; Test with internal buffer use
EndProcedureUnit


ProcedureUnit LeftTest()
  Test$ = "Test"
  AssertString(Left(Test$, 1)      , "T")
  AssertString(Left(Test$, 0)     , "")
  AssertString(Left(Test$, -1)     , "")
  AssertString(Left(Test$, 10)     , "Test")
  AssertString(Left(Test$, 3)      , "Tes")
  AssertString(Left(Test$, 4)      , "Test")
  AssertString(Left(Null$, 0)      , "")
  Result$ = Left(Test$, 1)
EndProcedureUnit


ProcedureUnit LenTest()
  Test$ = "Test"
  Assert(Len(Test$) = 4)
  Assert(Len(Null$) = 0)
EndProcedureUnit

                                                    The test procedure are declared with ProcedureUnit and EndProcedureUnit, there is some Assert commands available to control the checks. You can declare some common setup or clear procedure to run before and after each test with ProcedureUnitBefore and ProcedureUnitAfter. There is much more, feel free to check the PureUnit documentation to get the most of it. I strongly recommand to give it a try if you need to write some unit tests for your own PureBasic application.

                                                    The next tests we have are ‘linker’ tests. We put all commands of a single library in a file, and compile it to ensures it links properly. Then we put all the commands of PureBasic in a single file and we link it as well.

                                                    Then we test if all the examples found the in PureBasic/Examples directory compiles properly with the new PureBasic version.

                                                    Once all these tests are run and successful, the final package can created and published.

                                                    Linux and PureBasic

                                                    Since 20 years, PureBasic runs natively on Linux, using seamlessly specific libraries like GTK, QT, SDL and more. However, as PureBasic is a closed source software, we can only ship a binary package and it can be sometimes difficult to find the right distro to run your PureBasic programs. Every distro can have slightly different binary versions of GTK, QT, libc, zlib etc. and it could prevent PureBasic binaries to run at all.

                                                    Up to know, the Linux build servers were upgraded in somewhat chaotic manner, without real rules. For example, the current Linux build servers are running on Ubuntu 17.10 for both x64 and x86 because it was the last Ubuntu version handling x86. The problem is Ubuntu 17.10 was basically only supported for 6 months and then was in support mode for a few more months. Executable created on it are no more compatible with Ubuntu 20.04 or some other recent distros.

                                                    To address this, we decided to change way we will support Linux distros. Starting with PureBasic 6.00, we using the following scheme:

                                                    – PureBasic for Linux x64 will be available on the 2 last Ubuntu LTS versions (at the time of writing, it means Ubuntu 18.04 LTS and Ubuntu 20.04 LTS)
                                                    – PureBasic for Linux x86 will be available on the latest Debian (at the time of writing, Debian 10). As it is a lot of work, we only support one Debian at once because x86 is loosing traction on Linux distro side (for example, Ubuntu x86 is no more).

                                                    What does it means for you, PureBasic programmer ? It should be be easier to choose your dev environment (basically stick to Ubuntu LTS and upgrade it when a new version is released) and the produced executable should run on a wide range of Linux distros (you can even choose to build 2 versions, one on 18.04 LTS, and one on 20.04 LTS if you want to support even more Linux distros).

                                                    These 3 new build servers are already up and running, we hope it will solve some of the issues related to the Linux version of PureBasic !

                                                    PureBasic on Apple M1 processors

                                                    Last week, I bought a new Mac Mini to be able to port PureBasic on the new Apple M1 chip. First boot looks very familiar, you can’t really tell there is a new processor here. A quick look at the Task Monitor and we can see all the programs running on an ‘Apple’ CPU. Great. All seems smooth so far, a very quiet computer in a small form factor.

                                                    After a few minutes toying with the prefs to plugin my PC keyboard and Monitor on a KVM switch, I was ready to start to dev, and downloaded XCode. It was the longest installation I never experienced, at a point I though the Mini was broken. It tooks over 4 (four !) hours to install (after downloading). Seems to be known issue if I believe all the posts found on Reddit. Needed to install homebrew for subversion (I know, I know) and I finally started hacking the compiler.

                                                    This promised to be exciting, as the C toolchain isn’t based on gcc but on clang/LLVM. I expected some adjustements to do here and here, but there were actually zero. Everything compiled out of the box and the first running executable was created after half day. Two more days and the whole compiler test suits was working which was amazing ! There is indeed some more work to do to build the full package, as some libraries needs to be tuned (missing headers due to new Cocoa SDK mainly), build scripts adjusted and so on, but it does looks very bright.

                                                    This will be the first version of PureBasic shipped without an assembly back-end. It does feel a bit weird for me, but I know it will do the job just fine to build your cool apps on new Macs !

                                                    Sneak peak into new CPU support for C back-end

                                                    I just finished the x86 (32-bit) support for the C Back-end on Windows and it barely took a week to do. Most of the time was spent on upgrading the build chain (linker, windows static libs, packaging the 32-bit version of gcc etc.), it was very very fast. Next step is to work on a ‘real’ new architecture, probably ARM M1 for OS X, looks interesting !

                                                    The IDE is finally working with the C back-end !

                                                    This is the milestone we waited to validate the C back-end. It tooks quite a lot of iteration with the alpha testers (and thanks to all of you all btw) to iron major issues, but here we are: the IDE is mostly working when compiled with the C back-end. This is a big deal: the IDE is a very large software of about 130 000 lines of PureBasic code and using a lot of different features of the language. So what’s the functional changes ? Well, nothing. And that’s on purpose. The plan is to be able to switch seemlessly from ASM to C back-end and be able to compile the IDE on new platform, like Raspberry or OS X M1.

                                                    The only noticeable change is the compilation time, which jumps from 5 secs on the ASM back-end to a whooping 24 secs on the C back-end (based on GCC) with the debugger on and optimisation disabled. Keep in mind I got a very old CPU (Core i7 860 from 2009) and as discussed previously, just swapping the C compiler could lead to dramatic improvements.

                                                    All in all, it’s very good news, and we are looking forward to fix the last remaining showstoppers and creating a beta version for all the OS, including may be some new like Raspberry !

                                                    Quick look to PureBasic C back-end performance

                                                    PureBasic is currently using raw assembly code generation, which means the code is translated line by line to its corresponding assembly counterpart. This way to generate code has pros and cons: it’s easy to do but we loose the code context, so doing advanced optimizations (like variables to registers, loop unrolling, function inlining, code vectorization, variable removing etc.) are off the table. The only optimization PureBasic can perform is once the full assembly code is generated: a pass to detect patterns which can be optimized and replaced by more efficient one. For example:

                                                              MOV ebx,dword [v_Gadget_ImagePool]
          INC ebx
          MOV dword [v_Gadget_ImagePool],ebx

                                                    is transformed to:

                                                              INC    dword [v_Gadget_ImagePool]

                                                    PureBasic x86 can detect 16 different patterns and optimize them. It’s not much, but it still improves the final code quality. This kind of optimization is called peephole optimizer. It works on final code generation and can’t do much regarding high level optimization. The good point is the speed of it, the additional pass barely add any time to the compilation time. So you may ask why PureBasic can’t generated more complex optimizations ? Well, because we just don’t have the time (and let be honest, the skills) to do it our-self. It takes a lot of efforts which requires large programmer teams and academic researches.

                                                    Entering the C language, the world most used low-level language and probably the one which best optimizing compilers. PureBasic is now able to leverage the power of its optimizations, so let’s take a real world look at it. We are using the 3D example ‘MeshManualParametrics’ found in the PureBasic package. This is a mix of 3D rendering (through OGRE) and 3D calculations done in PureBasic. Here are the results:

                                                    PureBasic x64 – assembly back-end : 192 FPS

                                                    PureBasic x64 – C Back-end with optimizer enabled (-02) : 298 FPS

                                                    That’s basically a 50% increase in frame-rate just by switching the compiler. It’s really a lot. Another interesting point is the speed of the executable of C back-end without optimization (-O0) was 192 FPS as well, like PureBasic assembly back-end. Not that bad for small team compiler !