for performance, what's the best variable type to use for boolean _TRUE & _FALSE ?

[madscijr]

(If it differs by OS or 64 vs 32-bit, I'm in 64-bit Windows 10/11.)

Since QB64PE doesn't have a dedicated boolean type and _TRUE/_FALSE are numbers -1 & 0, I usually just dim those variables as integer. 

However, I seem to recall someone saying, back in the days of QB64 2.0, that Long was the numeric type most "native" to QB64 under the hood, but I could be hallucinating that memory. 

Or what about _BYTE ? I would think _BYTE would be the logical choice. But I also recall reading that on a 64-bit CPU, the data type requiring the least wrangling under the hood is INTEGER64 - which would be an egregious waste of space for a boolean (unless one INTEGER64 could be repurposed somehow to store 64 booleans?)

Thoughts?

[NakedApe]

I asked this very question last year...

https://qb64phoenix.com/forum/showthread...our+friend

See Post #12 here and the whole thread ain't bad.

[madscijr]

Thanks - so reading over that, it sounds like _BYTE would be the most efficient type for performance and space, where _BIT would require unpacking under the hood. Do I have that right?

[ahenry3068]

Thanks - so reading over that, it sounds like _BYTE would be the most efficient type for performance and space, where _BIT would require unpacking under the hood. Do I have that right?

     I doubt _byte is the most performant.     Everything I know about computer architecture tells me on a 64 bit system that _INTEGER64 will be the fastest.    
On a 32 bit system it would be LONG ...     _byte is the best for memory usage.   

    That said,   I doubt there's any performance hit you would notice using any Integer Type or even Single or Double.   We are talking about stuff that's a rounding error on almost all modern systems.      Myself.   I tend to use INTEGER for my personal Boolean type.   This is mostly because I write code for a couple of different Flavors of BASIC and this seems a good common denominator for me !

Also if you do want to use an _INTEGER64 for the possible speed benefit. I wouldn't worry about the 8 bytes of memory. Like I said. That's a rounding error !

[bplus]

When I was young and full of piss and vinegar I would turn my questions into little experiments just like what a mad scientist junior might do.

Then I would find what works best for me!

Getting other people's opinion of performance is just that, opinion. From experiment you would know for yourself whats best.

[bplus]

Oh I do have an opinion on this issue BTW. 

Unless you are doing very serious number crunching don't worry about Type for True False, Integer would do fine and in fact the less mixed types you use the faster the math might be. eg, NOT using UDT's is definitely faster.

[ahenry3068]

About packing bit's into an INT64. 

Code: (Select All)

Function SETBIT64 (INPUTVAR As _Integer64, BIT_TO_SET As _Unsigned Integer)

    Dim MASK As _Integer64

    If BIT_TO_SET > 63 Or BIT_TO_SET < 0 Then

        Print

        Print " CANT SET OUT OF RANGE BIT: "; BIT_TO_SET

        Print

        End

    End If

    MASK = &B0000000000000000000000000000000000000000000000000000000000000001

    MASK = _ShL(MASK, BIT_TO_SET)

    INPUTVAR = INPUTVAR Or MASK

    SETBIT64 = INPUTVAR

End Function



Function UNSETBIT64 (INPUTVAR As _Integer64, BIT_TO_UNSET As _Unsigned Integer)

    Dim MASK As _Integer64

    If BIT_TO_UNSET > 63 Or BIT_TO_UNSET < 0 Then

        Print

        Print " CANT UNSET OUT OF RANGE BIT: "; BIT_TO_SET

        Print

        End

    End If

    MASK = &B0000000000000000000000000000000000000000000000000000000000000001

    MASK = _ShL(MASK, BIT_TO_UNSET)

    MASK = Not MASK

    INPUTVAR = INPUTVAR AND MASK

    UNSETBIT64 = INPUTVAR

End Function





Function TESTBIT64 (INPUTVAR As _Integer64, BIT_TO_TEST As _Unsigned Integer)

    Dim MASK As _Integer64

    If BIT_TO_TEST > 63 Or BIT_TO_TEST < 0 Then

        Print

        Print " CANT TEST OUT OF RANGE BIT: "; BIT_TO_TEST

        Print

        End

    End If

    MASK = &B0000000000000000000000000000000000000000000000000000000000000001

    MASK = _ShL(MASK, BIT_TO_TEST)

    If (INPUTVAR And MASK) = MASK Then

        TESTBIT64 = _TRUE

    Else

        TESTBIT64 = _FALSE

    End If

End Function

[SMcNeill]

When I was young and full of piss and vinegar I would turn my questions into little experiments just like what a mad scientist junior might do.

Then I would find what works best for me!

Getting other people's opinion of performance is just that, opinion. From experiment you would know for yourself whats best.

We did various tests on this type thing not very long ago.  You can ask @TempodiBasic if he's still got them and where he might've shared them online for everyone.

Honestly, the speed difference in integer types is rather minimal between the _BYTE, INTEGER, LONG, and _INTEGER64.  We're talking like 0.00001 seconds when doing millions of compares and calculations.

The difference in _FLOATS isn't all that astoundingly different either, between the SINGLE, DOUBLE, FLOAT types.

There *is* a difference between INTEGER and _FLOAT speeds, but that's heavily influenced by system and CPU/FPU and whatnot, so in that type case, you'd have to micro-optimize per machine/system/whatnot.  The difference isn't such that I'd really worry over it.

The thing with most modern systems is the *size* of the processing units in them.  If your CPU has 32-bit registers, then when it does an X + Y calculation, it's going to move 32-bits into register A, 32-bits into register B, then add and send result to register C.   Doesn't really matter if it sends a _BYTE, an INTEGER, or a LONG down the pathways to those registers, they're all more-or-less traveling the same highway and going the same speed and performance isn't going to be much different.

Speed wise, with most modern systems, I'd suggest deciding whether you need integer-type values or floating-point-type values.   Do you have decimals or not?  <-- There's your main consideration.

Beyond that, _BYTE, INTEGER, LONG, _INTEGER64 really makes little difference.   Same with SINGLE, DOUBLE, _FLOAT.  Performance is usually the same.

Ignore _BIT.  It's a performance hit that you don't need.  Just use _BYTE instead.

For most modern systems, variable types don't really hold much bite anymore.  You used to really care about if you were using 10kb arrays or 40kb arrays of memory.  Now, you can write a program and think, "Well, this array can either be 1mb in size, or 8mb in size... and I only have 128GB or ram....  Wooooo!!!!  I better worry my ass off and optimize and say those few mb!"

For Booleans, just use _TRUE and _FALSE.   Why even bother with _BITs and _BYTES anyway. 

[SMcNeill]

I asked this very question last year...

https://qb64phoenix.com/forum/showthread...our+friend

See Post #12 here and the whole thread ain't bad.

Note that our unclothed monkey buddy has pulled a nice April Fool's joke on everyone with his link!

Code: (Select All)

https://qb64phoenix.com/forum/showthread.php?tid=2393&page=2&highlight=bytes+are+your+friend

That's his link.  If you click it, it takes you to the topic which then has some nice and weird squares chopped out of the post that had at least one person on the Discord wondering if something was broke with the wiki/forum.

NOPE!!

That's just some naked primate monkeying around!  "highlight=bytes+are+your+friend"  <-- see the last part of that link?  Look closely at the words that are being blocked all bright yellow/white/your system color is.  It's an intentional part of that link.

Most likely where @NakedApe did a search to find the topic at hand, and copied the page he was directed to without cleaning up the link, but that's what's causing it.  It's not a glitch.  Your PC is not blowing up.  The forums aren't bugged and dying.  It's not a formatting/wiki problem.

It's working exactly as intended -- even if that's not how everyone *assumed* it was intended to work. 

[NakedApe]

"Unclothed monkey buddy," LOL!  Well who knew I had to clean up a link based on a search term. Man, there's all kindza ways to mess up around here.   Duly noted...