Suggest enhancement for $CHECKING:OFF

[RhoSigma]

See this simple (useless) code:

Code: QB64: [Select]

1. $CHECKING:OFF
2.  
3. DIM myArray%(100)
4. myArray%(0) = 0
5. myArray%(100) = 100
6. myArray%(50) = (myArray%(100) - myArray%(0)) / 2
7. PRINT myArray%(0)
8. PRINT myArray%(50)
9. PRINT myArray%(100)
10. END
11.  

it translates into this C code (main.txt)

Code: C: [Select]

1. S_0:;
2.  
3. tmp_long=array_check(( 0 )-__ARRAY_INTEGER_MYARRAY[4],__ARRAY_INTEGER_MYARRAY[5]);
4. if (!new_error) ((int16*)(__ARRAY_INTEGER_MYARRAY[0]))[tmp_long]= 0 ;
5. tmp_long=array_check(( 100 )-__ARRAY_INTEGER_MYARRAY[4],__ARRAY_INTEGER_MYARRAY[5]);
6. if (!new_error) ((int16*)(__ARRAY_INTEGER_MYARRAY[0]))[tmp_long]= 100 ;
7. tmp_long=array_check(( 50 )-__ARRAY_INTEGER_MYARRAY[4],__ARRAY_INTEGER_MYARRAY[5]);
8. if (!new_error) ((int16*)(__ARRAY_INTEGER_MYARRAY[0]))[tmp_long]=qbr_float_to_long((((int16*)(__ARRAY_INTEGER_MYARRAY[0]))[array_check(( 100 )-__ARRAY_INTEGER_MYARRAY[4],__ARRAY_INTEGER_MYARRAY[5])]-((int16*)(__ARRAY_INTEGER_MYARRAY[0]))[array_check(( 0 )-__ARRAY_INTEGER_MYARRAY[4],__ARRAY_INTEGER_MYARRAY[5])])/ ((long double)( 2 )));
9. tqbs=qbs_new(0,0);
10. qbs_set(tqbs,qbs_add(qbs_str((int16)(((int16*)(__ARRAY_INTEGER_MYARRAY[0]))[array_check(( 0 )-__ARRAY_INTEGER_MYARRAY[4],__ARRAY_INTEGER_MYARRAY[5])])),qbs_new_txt(" ")));
11. if (new_error) goto skip1;
12. makefit(tqbs);
13. qbs_print(tqbs,0);
14. qbs_print(nothingstring,1);
15. skip1:
16. qbs_free(tqbs);
17. qbs_cleanup(qbs_tmp_base,0);
18. tqbs=qbs_new(0,0);
19. qbs_set(tqbs,qbs_add(qbs_str((int16)(((int16*)(__ARRAY_INTEGER_MYARRAY[0]))[array_check(( 50 )-__ARRAY_INTEGER_MYARRAY[4],__ARRAY_INTEGER_MYARRAY[5])])),qbs_new_txt(" ")));
20. if (new_error) goto skip2;
21. makefit(tqbs);
22. qbs_print(tqbs,0);
23. qbs_print(nothingstring,1);
24. skip2:
25. qbs_free(tqbs);
26. qbs_cleanup(qbs_tmp_base,0);
27. tqbs=qbs_new(0,0);
28. qbs_set(tqbs,qbs_add(qbs_str((int16)(((int16*)(__ARRAY_INTEGER_MYARRAY[0]))[array_check(( 100 )-__ARRAY_INTEGER_MYARRAY[4],__ARRAY_INTEGER_MYARRAY[5])])),qbs_new_txt(" ")));
29. if (new_error) goto skip3;
30. makefit(tqbs);
31. qbs_print(tqbs,0);
32. qbs_print(nothingstring,1);
33. skip3:
34. qbs_free(tqbs);
35. qbs_cleanup(qbs_tmp_base,0);
36. sub_end();
37. sub_end();
38. return;
39. }
40.  

Although $CHECKING:OFF is in place, there are still all that array_check() calls to verify the indicies are in range. There is usually one call per index per use of any array element, hence it even multiplies for multidimensional arrays.

I know it's a small function and it's also inlined, but nevertheless it's unnecessary overhead for "error free" code which has been checked prior putting it into $CHECKING:OFF mode.

So i'd like to suggest to waive to the array_check() calls whenever $CHECKING:OFF is in place.

[RhoSigma]

Hm, two weeks and nothing? - Yes, No, Maybe?

[Petr]

Hi. Do you suggest this as an adjustment you would like to make? How big is the speed difference? It's worth it?

[RhoSigma]

Another quick test program:

Code: QB64: [Select]

1. $CHECKING:OFF
2.  
3. REDIM a%(500, 500, 500) '125 mil. elements
4.  
5. st# = TIMER(0.001)
6. FOR x% = 0 TO 500
7.     FOR y% = 0 TO 500
8.         FOR z% = 0 TO 500
9.             a%(x%, y%, z%) = 0
10.         NEXT z%
11.     NEXT y%
12. NEXT x%
13. en# = TIMER(0.001)
14.  
15. PRINT en# - st#
16. END
17.  

on my system Win7 SP1 Intel i5-2430M @ 2.4GHz it takes between 4.0 and 4.1 seconds with the current dev build from Apr,28th, funny to mention here, the old SDL version 0.954 made it just 3.25 seconds, wow what's wrong with GL?

Now changing the essential line (81) in internal\temp\main.txt from

Code: C: [Select]

1. tmp_long=array_check((*__INTEGER_X)-__ARRAY_INTEGER_A[12],__ARRAY_INTEGER_A[13])+array_check((*__INTEGER_Y)-__ARRAY_INTEGER_A[8],__ARRAY_INTEGER_A[9])*__ARRAY_INTEGER_A[10]+array_check((*__INTEGER_Z)-__ARRAY_INTEGER_A[4],__ARRAY_INTEGER_A[5])*__ARRAY_INTEGER_A[6];
2.  

into

Code: C: [Select]

1. tmp_long=(*__INTEGER_X)+(*__INTEGER_Y)*__ARRAY_INTEGER_A[10]+(*__INTEGER_Z)*__ARRAY_INTEGER_A[6];
2.  

removing the 3 array_check() calls (one for each!!! dimension).

Then recompile the program using recompile_win.bat in the internal\temp folder and after that running the compiled EXE again. And see, it only takes ca. 2.8 seconds now, so yes its worth to consider this enhancement in a future version.

Will i do it? - NO, i only make this suggestion. I'm far less familiar with QB64's internals than our main developers and don't have the time currently to get into it.

[Pete]

Hm, two weeks and nothing? - Yes, No, Maybe?

My guess is we (meaning Fell) just reached a stable build with V1.3, which runs very smoothly with few, if any actual bugs, reported. So maybe now it's time for a breather? I'm sure improvements will always be welcomed, but I think Steve is still fairly new to C++  and has a lot on his plate, Bill mostly helped with the website, I suspect, and has been away, lately, Luke has never been around as much as you would think a coding developer would be, and has been AOL a lot more lately (yes, I meant AWOL, but being on AOL is so much worse...) and Fell, I bet, did a lot of the website update along with most of the v1.3 improvements. Instead of a well deserved ticker-tape parade for V1.3, I think we saw the typical response in programming projects, which is: "Well that's nice but what's up next? Well, it REALLY is nice and I sure, in time, there will be a what's next. Hell, maybe I just Murphy'ed law this into an update before any more responses are added to this thread, but if not, I'm sure in some time more tweaks will be added. Fell and company appreciate us as users finding ways to improve QB64 as much as we appreciate them as developers continuing on with this project. I also realize you are only asking for a yes, no, maybe, and not demanding an implementation, which is why I think I may be right about a need for a breather, or possibly your post just hasn't been read by a developer and discussed in chat, so no developer has responded.

I would just like to add my personal thanks to you for the neat projects and discussions you have posted in this forum. I'm not into C++ but you evidently are and maybe you have enough experience and time to consider also contributing as a developer? I mean you were totally on the wrong side of the argument about _INSTRREV, but yo were on Fell's side, so having that, and some other things in common, might make your addition to the "team" work out. I just wonder if the lone gun Karma of QB64 can ever truly be breached.

Pete

[RhoSigma]

Hi Pete,
I totally agree with your words about v1.3, and the respective overhaul of the website. And for sure, everybody deserved a breather. I'm certainly not going to push anybody to do any more changes RIGHT NOW! :)

All i was wondering, that my post did trigger absolute NO reaction, which is unusual for this forum, especially if it's about enhancements, bugfixes or new commands (_INSTRREV ;-)). And for sure there were already many discussions about speed tweaks.

However, this was just a suggestion about something to think about, if it finally makes it into the next dev built or in stable version 1.4 or never at all....

[Pete]

I actually read this, realized it didn't need a reply, got a kick out of the _INSTRREV comment, and clicked off... Then I realized, wait a minute, this is playing right into the Karma of "no response," so screw that, came back, and posted this.

Thanks for reading my reply!

Pete

[Petr]

Thank you RhoSigma.
Yes, the difference is big. Maybe when using MEM, wouldn't he be so big? The question is, what will be turned off when you edit it. Whether critical errors are still being checked or not. I can't see the QB64 code in C ++ much - my knowledge in C++ are very limited. Probably it would mean going through all the procedures in QB64 .... i think, no one will want to go through it.

[SMcNeill]

Thank you RhoSigma.
Yes, the difference is big. Maybe when using MEM, wouldn't he be so big? The question is, what will be turned off when you edit it. Whether critical errors are still being checked or not. I can't see the QB64 code in C ++ much - my knowledge in C++ are very limited. Probably it would mean going through all the procedures in QB64 .... i think, no one will want to go through it.

A lot of the checking done in QB64 is for user interruptions, such as if they hit CTRL-C or CTRL-Break while the program is running.  If my memory is correct, that’s mainly what all those if (!new_error) statements do.

The changes for this would all be in QB64.bas, and would require simply scrolling down to find the segment dealing with arrays, and then adding an exception to stop the printing of the error checking, if $CHECKING:OFF.  (I’m thinking you’d want to look for the PRINT #12 statements, if I haven’t got the number for “main.txt” confused with another.)

[RhoSigma]

@Petr
What is turned off?

array_check() will simply check, if your given index is within the lower/upper bound range of the given array, hence it's responsible for the "subscript out of range" runtime error, if the index is too small/big.

As arrays are straight forward memory areas, the worst thing which may happen is a crash due to a segmentation fault, if your given index is out of range and this is not checked. But this makes no difference to the _MEM commands, which would have the same problem when $CHECKING is switched off. So you have to make sure your code is error free first, and this is explicitly mentioned at the $CHECKING wiki page:

Warning: Turning OFF error checking could create a General Protection Fault (or segfault). Use only with 100% stable sections of code.

And that's all what i suggest. I don't want to remove the array_check() function at all, but only if i'm sure everything is error free and then put it into a $CHECKING:OFF section to gain maximum possible speed.

Probably i also should explain here why i make this suggestion.

Working on my GuiTools project, there is that one function called RemapImageFS&(), which is responsible to Floyd-Steinberg remap every image on the fly as it is used in the GUI. This function was already pretty well optimized for speed, but i ever felt it could be better, if not all these array_check() calls would lurking around there even with $CHECKING:OFF.

So i put hand on this function again, replacing all usual array stuff with _MEM operations, hence building my own array functionality using _MEM stuff, and so got a nice speedup, reducing worst case processing time per image pixel from 2.5 micro seconds to 1.95 micro seconds, and best case time from 620 nano seconds per pixel to 130 nano seconds per pixel.

If you now say ok, the speedup is simply the effect of using _MEM instead of arrays, NO, cause what the _MEM operation does in $CHECKING:OFF mode is almost exactly what my edited C++ line from the post above does, a direct memory access to a precalculated memory address.

[Petr]

Yes, you're right, RhoSigma. I read badly. I would also welcome this.

[Pete]

Actually, when I consider how many at this forum have English as a second language, I'm pretty impressed we can make any progress at all. Thank God we don't have to communicate in Assembly. That language is a bitch.

Pete

[RhoSigma]

Thanks Steve for pointing into the right direction, actually it's no direct PRINT, but the line is concatenated in a string and printed when completed. Only two lines of code in QB64.bas. To be sure i'll run a fulltext search for "array_check" on the entire qb64 folder. Well, seems to be easier and less time consuming than i though to make this adjustment.

@Petr
correcting my statement from above, Yes, i'll do it and push to the repo after some testing :)

[RhoSigma]

Changes done, pushed into the repo, pull request issued, the rest is on our main developers to merge the changes.

[Raven_Singularity]

I support this change.  Great to see you were able to patch the change in so easily, and I hope it's accepted/used by the developers.  Cheers.