One of the key factors for them is that “their compiler makes small exes”… They never, ever, mention speed.

Some time ago I did a bunch of benchmarks, in a time where it was uncertain for me which language should I stick to (We all asked this question at least once) and I found some shocking results, but not surprisingly. You see, developing an efficient compiler is not an easy task. However, when someone talks their butt off a certain subject, be sure that they are hiding something else.

The benchmark ran a few simple, trivial tests such as single and multi-dimensional array access as well as a factorial test. All of which were linear. The languages I chose were C++, BlitzMax and PureBasic.

Results were loud and clear, PB was the slowest of all three tested languages with no exceptions.

For the linear array access, C++ did 700ms whereas BMX (BlitzMax) did 650ms, Sadly PB did 2160ms.

Similar pattern emerged in the multi-dimensional array test with C++ performing a whopping 1250ms against BMX’s 1750ms, again PB did a lousy job with 4330ms, ouch.

As for the factorial test: C++ 578ms, BMX 590ms, PB 1578ms.

Now, this are averaged results (out of 10 runs each). The versions used of each compiler were the latest, stable releases. And I just finished running the tests again, yielding the results I just showed you (which didn’t differ much from my old findings anyway).

For C++ I used the GCC frontend, I also compiled with the default switches. Reason being, I wanted to be “fair” with the other languages that don’t seem to provide any compiler switches at all regarding true code optimization. It’s also good to know that both PB and BMX use similar backends for assembly and BMX itself uses GCC for it’s C++ integration.

It is clear that PB’s compiler does a lousy job, period. Whenever you’re working on an application in the real world, a few extra KBs don’t matter as long as your program runs FAST. Obviously a more extense set of tests should be created to really call it final, but I don’t have high hopes for PB since it’s not a worldclass compiler, it can’t compete with C++, period.

“Programmers are the only men who boast how small theirs is.” – Wil Baden

Well Mr. Baden, I don’t. OK, Sometimes…

For those afraid of C++, did you ever try it or were you too scared of the syntax and decided it was too much for you?, do yourself a favor and look again, this time do make an effort and I promise you’ll soon get an epiphany the size of an elephant. If not, at least go for C#, Java, or Python! – Boy there are good choices out there.

You can find the benchmarks along with their source in here.

(notice this is quite an old piece of code, specially for the cpp tests; there are certain headers included that shouldn’t even be there in the first place. you could also get a smaller exe by avoiding iostream alltogether, ha)

That’s all I wanted to say, I’m really tired of how idiotic they can get with their product. It’s not like they’re offering something that doesn’t exist, they don’t even have a RAD or even the standard libraries and most importantly size doesn’t matter if you can’t perform at all… Oh well, I better wrap it up for now.

Cheers.

</rant></hate><love>

The reason for this library is quite simple, and so is the library itself. you can either include it or install the resource file and start using it right away. After taking a quick look at the source, you’ll soon familiarize with it’s naming convention; there is no need to write any documentation for this type of code, since it’s basic vector math. However a test source is included for your delight.

You can find the source in here: http://gushh.net/dev/?file=pb/vec3_macro.pbi
And some ugly test code in here: http://gushh.net/dev/?file=pb/vec3_macro_test.pb

Or, you can get “the whole package” from here: http://gushh.net/dls/vec3_macro.zip

Using this library is as easy as…

Define.VEC3 a, b, c
VEC3_SET( a, 0.1, 0.2, 0.3 )
VEC3_SET( b, 0.4, 0.5, 0.6 )
VEC3_ADD( a, b, c )
VEC3_DEBUG3( a, b, c ) ; display the vectors in the debug console.

I mention “so-called fast” because it’s relatively fast, however not as fast as a pure sse2+ implementation would be – although we remain “as fast as we can” without breaking code readability and maintainability at all. This is also 100% cross-platform and as fast as it gets with the current compiler. “Macrofobics” could disagree but it’s their loss.

Some might argue that using a “fast sqrt” would be a good thing, but I disagree. You don’t really need this at all now a days. Also, any implementation of the fast sqrt in PB would not benefit from much speed increase at all, if any you’ll ruin code readability over a little bit of speed while giving away precision and portability.

That said, feel free to modify as you see fit – But please share your findings with the community.

If there is a need for a VEC2 lib, I’ll gladly release it. Remember, you don’t need a point library / class at all, a vector library can indeed be used for points and it is recommended; cuts unecesarry redundant code and makes your life easier. Perhaps a purist OOP coder would disagree, but I don’t care.

Have fun with vectors!