PureBasic Forum

What about some examples of your (recursive) procedures which have to be tuned...


Something else I must have missed, each enhancement of the whole purebasic biotope is welcome (for everyone, I guess)...
...and there stil a lot of possibilities to improve this great product, seen in many feature requests being posted in this forum.

But before Fred's small team will be able to have done all bug fixes and enhancements, it may be useful to discuss, if there are any alternativ methods in coding or workarounds to get (slightly) improved results. So even some strange ideas may inspire someone to find an accepted solution...

The performance hit of such initializations is minimal, especially on modern processors. If speed is that critical you are probably better off doing the critical parts in asm directly. In the general case, it is simply not worth it.

The funny thing is that if you guys both read this whole thread, then you probably have already spent as much time on it as it would take to implement... I know it is capable, because you have the "bulk" zero implemented.

Even if it is possible, why would you want an option like that ?
Like already mentioned, for most procedures you won't notice the difference and for the special cases you can use static variables or use ASM.
Writing an ASM routine usually gives much more speed improvement compared to not initializing variables.
You are right however that Static is no option if you need recursion.

Protected vs Static difference

4 millionths of a second per variable initialization.

I'd say drop whatever you're doing and jump right on this one.

Guys sit here and discuss in great lengths how to squeeze one instruction out of an asm routine... and I'm just asking for one per variable on every single procedure. The amount of time to eliminate this code is moments...

If not SkipInizializeToZero
InitializeVarsToZero
Else
JustAllocateSpaceForVars
Endif

...and 4 millionths of a second is a LOT when you are calling it 250,000 times per second!!!!

...and here is just one more reason to apply even "small" improvements to PB optimization:
Here is a quote...

...from an old thread that was recently resurrected:
viewtopic.php?f=17&t=44141&start=30#p371904

If we take a laissez faire attitude towards simple optimizations, then clearly, people will continue to think PB is not good enough to make "critical" code. It is all hogwash! Afterall, it is not the "basic" part of PB that makes it less optimized than C (in 99% of code, anyway), it is the post-compile optimization that does it. Unfortunately, only C compiler authors take optimization seriously, so it is always thought of as superior.

I would have no problem with the option you are requesting but I don't share your opinion on your last post. Yes, it's very well possible a C compiler would outperform the PB compiler in speed tests. In real world examples however, the majority of the time a program is waiting for you instead of you waiting for the program.
And when speed is very important ASM usually beats C.

My main problem with your request, is that it seems a big problem to me if you would have the option turned on and forget somewhere to initialize a variable yourself. It would be a nightmare to find out where the problem is located.
For such an option, the ideal situation would be if the PB debugger would give a warning message if a variable is used that hasn't been initialized yet.

I would think it's better to clearly specify with a keyword which variable yo do not want, something like.

To have i defined but not initiated. To switch all on-/off in the preferences seems like playing Russian roulette with much of the code.
The other reasonable version would be to force the use to initiate any variable before first use, that may be a stable alternative if a global switch where to be used.

Still, calling a procedure 250k times a second? Gosub will likely save you much more then not initiate the variables, just by skipping all the overhead on procedures.

This feature is no different--nor any more (or less) likely to lead to errors--than using the DEFAULT setting of DisableExplicit. Anyone who argues this feature should not be implemented may as well also argue that DisableExplicit be removed with EnableExplicit be turned on by default. So your statement is only true with old code, and with coders using habits accepted in the industry as "bad programming practices". Most compilers will not guarantee a value; PB has a safe mode, which is nice for beginners. However, most programmers who are active on this board are not beginners, and therefore have the skills to benefit from this feature request.

If you still need some type of handholding for the newbies, then there could be THREE options:
1. All vars init to 0
2. No vars init ; Set in compiler options, or with EnableInitSkip--much like enableexplicit
3. Only skip marked vars

While I would certainly use the No Vars Init option, for option 3 it makes more sense (to me) to use a new keyword rather than an additional one:
ProtectedNC.i x,y,z ;Not Cleared

I agree about what you say regarding DisableExplicit and "bad programming practices", but this has been historically that way for PureBasic. EnableExplicit didnt even exist when i started with PureBasic. This "bad programming practice" behaviour by default, is just one of the 'historic' flaws of PB to me, that most programming languages have. Changing this default in a new version, would likely break backward compatibility to a lot programs.



Advanced programmers can already avoid this "limitation" in different ways. Argueing for this compiler change, seems a bit misguided to me tbh. because personally i would just write a function with the parameters you mentioned, in hand optimized assembler and link/include it into PureBasic software. Even if you can't write assembler code, you could rewrite your recursive solution and use GOTO/GOSUB to avoid the stack "humping" and variable initialisation of a recursive solution.

Excessive recursive solutions can be dangerous anyway, because the program/thread stack frame doesnt always dynamically grow. I just tried 250.000 recursive calls for a PB function with 2 parameters and a 32-bit executable still crashes with a stack overflow in Win7.

I almost laughed out loud at this!!! On my current project, it is currently at 7900 lines containing over 260 procedures, and a lot more than 1/3 of them are recursive... I guess you just have to avoid the recursive summation of numbers over 1,000,000. But if you code with care, there is no problem at all with using recursion.


The way I see it is the biggest difference between the "code safety" of "this feature request" vs. enableexplicit is that the latter is "unsafe" by default, and encourages bad habits, whereas I am asking for an option to make the new feature "unsafe" to encourage good habits. Oddly, PB has them exactly opposite of every "modern" programming language...except maybe some interpreted junk.

For windows you can also use the Visual Studio tool "editbin" with the option "/stack:size" to extend the default stacksize in executable files. The default limit was below 65000 recursive calls for my test with 2 parameters (16 bytes on the stack for each call, 1 MB default stacksize).

I will keep that in mind if I ever need more space. So far, I haven't even come close.

> Oddly, PB has them exactly opposite of every "modern" programming language...except maybe some interpreted junk.

You mean such junk as Java?


The zero initialization has been part of the language from the very beginning. And as we pointed out its costs are minimal. So it is not going to change.