integer vs long for boolean variables and performance in general?

[madscijr]

Is it preferable to use Integer or Long for boolean variables? And when would we want to use Integer instead of Long?

My understsnding is, since QB64 has no native Boolean tyoe, we use 0 for False and -1 for True, and we can use constants for readability:

Code: QB64: [Select]

1. Const FALSE = 0
2. Const TRUE = Not FALSE

So far I have declared my "boolean" variables as Integer:

Code: QB64: [Select]

1. Dim bFinished As Integer

However, I've seen it mentioned on here a few times that Long is "native" to QB64 "under the hood" and offers a slight performance benefit over Integer. If this is true, and assuming the extra memory needed for a Long instead of an Integer isn't an issue, do I want to declare my "boolean" variables as type Long rather than Integer?

And in general, other than saving memory, is there any reason you would want to use Integer instead of Long for numeric types where you just need to store values between -32,768 and 32,767 signed or 0-65,535 unsigned?

Much appreciated...


Update: I'd still like to know what people have to say, but it looks like Long does work for boolean, per this test program...

Code: QB64: [Select]

1. Const FALSE = 0
2. Const TRUE = Not FALSE
3.  
4. Dim sValue As String
5. Dim iValue As Long
6. Dim bValue As Long
7.  
8. Print "1. Does Val work with Long?"
9. sValue = "1256512"
10. Print "   sValue=" + Chr$(34) + sValue + Chr$(34)
11. iValue = Val(sValue)
12. Print "   iValue=" + cstrl$(iValue)
13. Print
14.  
15. Print "2. Does type Long work for boolean values?"
16.  
17. bValue = (10 > 5)
18. Print "   (10 > 5) evaluates to " + cstrl$(bValue)
19.  
20. bValue = (5 > 10)
21. Print "   (5 > 10) evaluates to " + cstrl$(bValue)
22.  
23. bValue = ((2 + 2) = 5)
24. Print "   ((2 + 2) = 5) evaluates to " + cstrl$(bValue)
25.  
26. bValue = ((2 + 2) = 4)
27. Print "   ((2 + 2) = 4) evaluates to " + cstrl$(bValue)
28.  
29. bValue = (5 > 3) Or (2 < 1)
30. Print "   (5 > 3) Or (2 < 1) evaluates to " + cstrl$(bValue)
31.  
32. bValue = (5 > 3) And (2 < 1)
33. Print "   (5 > 3) And (2 < 1) evaluates to " + cstrl$(bValue)
34.  
35. Print
36. Print "Finished."
37.  
38. ' /////////////////////////////////////////////////////////////////////////////
39.  
40. Function cstrl$ (myValue As Long)
41.     cstrl$ = _Trim$(Str$(myValue))
42. End Function ' cstrl$
43.  

Results:
1. Does Val work with Long?
   sValue="1256512"
   iValue=1256512
   
2. Does type Long work for boolean values?
   (10 > 5) evaluates to -1
   (5 > 10) evaluates to 0
   ((2 + 2) = 5) evaluates to 0
   ((2 + 2) = 4) evaluates to -1
   (5 > 3) Or (2 < 1) evaluates to -1
   (5 > 3) And (2 < 1) evaluates to 0

Finished.

[bplus]

It is rumored Longs are faster than Integers but of all the things to worry about this isn't one of them. :)

[Cobalt]

I'm with Bplus, not really something you need to be fretting over for speed issues.

Personally I use _BYTE for my TRUE\FALSE work. As I see no need to waste extra memory for them(regardless of the trivial-ness of memory consumption anymore).

On a memory note however, I did just run into an issue where one of my programs would have needed little more than ~48gigs of ram to load and run. And how many folk have that in their computer(I don't)? So memory limits can still come back to _byte you if your not careful.

[madscijr]

Thanks for clearing that up @bplus and @Cobalt. Makes my life a little easier not having to update 10,000 Integer variables to Long, LoL.

[SMcNeill]

Longs, generally are faster than integers, but not by an appreciable amount unless you're doing a lot of heavy math, inside a loop, with a large array of data...

For example, let's take a look at the following:

Code: QB64: [Select]

1. t# = Timer(0.01)
2.  
3. DefInt I-Z
4. For i = 1 To 10000
5.     For j = 1 To 10000
6.         For k = 1 To 10
7.             foo% = foo% + 1
8.         Next
9.     Next
10. Next
11.  
12. t2# = Timer(0.01)
13. Print t2# - t#
14.  
15. DefLng I-Z
16. For i = 1 To 10000
17.     For j = 1 To 10000
18.         For k = 1 To 10
19.             foo% = foo% + 1
20.         Next
21.     Next
22. Next
23.  
24. t3# = Timer(0.01)
25. Print t3# - t2#
26.  
27. _Define I-Z As _INTEGER64
28. For i = 1 To 10000
29.     For j = 1 To 10000
30.         For k = 1 To 10
31.             foo% = foo% + 1
32.         Next
33.     Next
34. Next
35.  
36. t4# = Timer(0.01)
37. Print t4# - t3#
38.  

Now, all things being equal, except for my variable types in those 3 loops, the speeds I get are about:

2.5 seconds.
2.4 seconds.
2.2 seconds.

On Win 11, 64-bit OS, compiling with the 64-bit version of QB64, integer64's are the fastest for me, while Longs are a fraction slower, and Integers are just a miniscule slower than that...

But, in the grand scheme of things, it's such a small change here, that it has to be compounded in multiple loops repeatedly before it adds up to anything noticeable.  To just compare True/False values, I really don't think it'd ever make much of a difference at all.

[jack]

sometimes you get unexpected results, a while ago I run a simple primes benchmark and I thought that long or integer would surely be faster than byte on a 64-bit machine but I was wrong, byte was significantly faster

[OldMoses]

I've used _BYTE a few times in boolean work, though I was generally unconcerned about speed. It just seems economical. I always assumed that any speed issues were due to a particular data type being "closer to the metal" by matching register sizes better. If that is the case, then _INTEGER64 should be pretty quick on modern systems, but it would seem to be a memory waste for a simple boolean. Not that that is a problem on modern systems either...

Any time I've had speed issues, I can't recall ever changing integer types that made any improvements.