Macro PowerOfTwo( _num_ )
	!MOV     Eax, [v_#_num_]
	!SUB     Eax, 1
	!PowerOfTwo_Loop_#_num_:
	!MOV     Ecx, Eax
	!ADD     Eax, 1
	!AND     Ecx, Eax
	!JNZ     PowerOfTwo_Loop_#_num_ 
	!MOV [v_#_num_], Eax
EndMacro

Truth be told I was looking for some old libraries I wrote a while back and I stumbled upon that code. It made me chuckle so of course I had to share it. The reason I laughed was because, well… Who would really need to optimize such a routine?; in those days I was suffering from a severe case of premature-optimizationitis.

However, compared to the normal method which follows:

Procedure.i NearestPow2( Value.i )
	ProcedureReturn Pow( 2, Int((Log( Value ) / Log(2)) + 0.5) )
EndProcedure

The ASM routine is about 25 times faster (I benchmarked the code itself without the procedure to be fair, otherwise it would’ve been 55 times faster!)

So, while unnecessary it still proves a point — You can always optimize your code for speed. However, the cost is clear… readability!

I guess it’s worth stating the obvious in this case: Always benchmark your code and find a balance when it comes to optimization, only optimize your bottlenecks. Don’t waste time in small details unless the reward is worth the time.

Cheers!

PS: Since the PB pre-processor is case sensitive (who would’ve known!) Remember that you must pass the macro the same label your variable has, also because we define a label this means we can only call the routine in one place for one particular variable. That however was not an issue with my code, so it never bothered me.

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!

So I had to code my own, as always. When no proper framework is given, you have to either depend on others to implement it or just do it yourself, since the former requires time and patience… I always choose the latter

Heres a standards compliant routine to URL-Encode URIs in PureBasic:

The url_encode() code can be found at > here <

It complies with the RFC 3986 (the current standard) and it’s the fastest method available for the language. In my last benchmarks it proved to be 0.20 times faster than the fastest known/shared url-encode routine for this language (however, that one wasn’t compliant at all!). It’s also 2.50 times faster than the average suggested “solutions” for URL-Encoding in this language.

Notice the character ‘%’ being checked in one of the case statements, this is simply to prevent duplicate percent-encodings on already encoded URIs. Speed wise, you could still further optimize this routine here and there, but I personally think it’s not worth the hassle (readability is still important).

The reason I always optimize my routines once I’m done developing them is simply due to the fact that every little uop you save (or should I say ‘shave’?) counts, whether it’s a trivial operation or not, it doesn’t matter! – that’s simply a clue: It’ll give you a reference on how many time you should spend optimizing the routine. Yet in the case of a trivial operation, it doesn’t mean you should leave it “as is”. Again, just because you’ll call the routine once or twice during runtime doesn’t mean you can’t improve it!.

Thus if you can up-scale your code, then do it. Not only you’ll gain execution speed, but also knowledge; that’s a precious thing to earn.

My first entry is the FindChar() routine. Unlike the official FindString(), this one only searches for a single character. In situations where you’ll be dealing with single character string searches rather than multi-character, this routine will give you up to 2x speed increase in both Ascii and Unicode modes. Worst case scenario, you’ll get equal results speed-wise.

The FindChar() code can be found at > here <

Due to the fact that Unicode characters are 2bytes long, we must use SizeOf() to perform certain displacement operations. However, this implies the use of at least one division for our final result, this will slow things down in the long-run. So, instead, we hack ourselves into a nastier method and we thank the FPU for it (granted, multiply by 0.5, since we know the character size is constant at 2) As nasty as it is, this allows us to outperform the official routine by almost 2x, still in Unicode.

There are certain things to take care of before doing anything with my routines, and this includes making sure we pass a valid string pointer, while ensuring we never pass negative displacement values and that we don’t attempt to displace over the limits of the string. Any self-respectable coder will do this before calling any routine, though. If you want an extra push of speed, get rid of the main IF statement in the routine.

The ideal solution for this language would be to trash the actual string library and replace it with a proper one, but I fear this is a task for the author, not us. I also fear, we won’t be seeing this any time soon. So we might as well keep on sharing our solutions and “hope” the author reads a few books on proper software development, and that he understands them.

For those of you using Unicode, please beware that this routine has not been extensively tested on a production level. Even though it behaves equally to FindString(), I recommend you to perform at least a few tests before plugging this routine right into your main-code. It’s worth noting though, most of my string routines work on 0-based displacements but output equally to the official PB ones.

One of this days I’ll probably end up ranting quite badly on the fact that this sort of languages lack standad support for some really important routines… On the bright side, they provide quick means of prototyping small pieces of code before getting into production with your main language. Even so, theres no escape on the fact that the author lacks the real-world development experience to provide better solutions for his own product.

That’s it for now, I’ll be sharing more as I find time to post in here. Most of the rutines are being used on my in-house XML parser, just so you know. All benchmarks were done on multiple processors and results were averaged on a set of 20 tries per test.

Cheers.