Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(4 edits) (+1)

Nice to see you're sticking with your project until the end, you really understand the importance of finishing something you started! Props to you!

I just noticed your attempt to benchmark QB64, and I couldn't hold myself from giving you my two cents on that matter as I worked on developing benchmarking applications for embedded devices for 4 years of my life.

Your loop only has a print command in it, which basically has the same implementation on almost every language, it's a OS interruption basically (interop), so you're not actually measuring the performance of your language but rather measuring the OS interop to print a value. The interop sometimes hold the application until it has completely executed your task, in this case printing a value, so that's why it takes minutes to finish your test.

The simplest but accurate language benchmark I can think of is maybe a MD5 solver for a very long string, or something similar, anything simpler will most likely diverge from the actual purpose of the benchmarking.


Now there's a good overall simple rule to know if a language is fast or slow: How is it converted into machine instructions?

The fastest languages out there are the LLVM compiled languages, like: C, C++, Fortran, Rust and Zig

The slowest are the interpreted languages, like: Ruby on Rails, Python and JavaScript

There are also some languages that are not exactly interpreted, but something like compiled to a intermediate stage just to be translated into machine code, they are like the "half way" between compiled and interpreted languages, like: C#, java and Lua. That's why, although very slow comparing with languages like C++ and Rust, they are still quite fast (mostly what slow them down is a system called garbage collection).

As for QB64(I never used it) but it seems like they can be either compiled (not LLVM though) or interpreted too, so yes it can be very fast, just one step behind languages C++, Rust and Zig.

Hi FearCode! I'm admittedly inexperienced when it comes to benchmarking programming languages so thanks for the insights! Not exactly sure how I would implement an MD5 solver, but I saw on YT that another benchmark method is to see how many "passes" a programming language can make in 5 seconds when solving for all prime numbers. 

According to its creator,  "The QB64 compiler converts BASIC code into C++ code, and then uses a third-party C++ compiler (GCC) to compile the C++ code into an executable file."

For now I'm pretty happy with QB64, mostly because it's what I'm familiar with and pretty easy to work with. But if I need something blazing fast I'll definitely be checking out those low-level languages. I've played around with C++ a little bit, but I'd have to really dedicate some time to get to a point where I can work with it.

(1 edit) (+1)

Interesting, didn't know the compiler converts to C++, yes, then if you just switch away from GCC (to clang or msvc) it may be as fast as C++ itself (depending on how good this converter is, ofc)

About the video from dave's garage, it's okay-ish, but not enough, I use this site as a good reference, they are old timers, and have a lot of benchmarks from mandelbrot to reverse complement. As you can see: C, C++ and Rust are the fastest on an average of all their cases (note that unfortunately they don't use a LLVM for C and C++ which could make them even faster).

For games I do recommend C++, it's not only blazing fast but also the best in terms of content and tools produced for game development, but to be honest you can make a very good and efficient game on any language.

Java. for instance, I have a history with it and oh boy it's a painfully annoying language, specially for game dev, but still it was minecraft's first development language, it all comes to how you make it, as long as you leave the heavy lifting to the GPU you can even make hardcore games in python (that may be too much lol, Lua maybe?) 

So yes, if you're comfortable with QB64, go ahead I and finish it up in there, I know it will be just fine