Is there a performance difference between using bitmask values and sets?

For example:

Option #1:
=================================
const
  FLAG_A = 1;  // 1 shl 0
  FLAG_B = 2;  // 1 shl 1
  FLAG_C = 4;  // 1 shl 2
var
  Flags: Integer;

[..]

  Flags:= FLAG_A or FLAG_C;
  if FLAG_A and Flags  0 then ..  // check FLAG_A is set in flags variable

=================================

vs

Option #2:
=================================
type
  TFlag = (FLAG_A, FLAG_B, FLAG_C);
  TFlags = set of TFlag;
var
  Flags: TFlags;

[..]

  Flags:= [FLAG_A, FLAG_C];
  if FLAG_A in Flags then ..  // check FLAG_A is set in flags variable

=================================

While we are on the topic of Sets. What is the maximum number of values you may have in a set, and does it differ between 32-bit and 64-bit platforms?

Regards,
- Graeme -

Am 20.01.2016 19:26 schrieb "Graeme Geldenhuys" <

: Is there a performance difference between using bitmask values and sets?

For sets with <= 32 elements it should behave the same if I remember correctly (I don't know right now though whether it would be 64 elements on 64-bit platforms though). With more elements there will be a penalty as then helper routines are needed.
You cam check this by compiling with -al and comparing the assembler code. :)

While we are on the topic of Sets. What is the maximum number of values you may have in a set, and does it differ between 32-bit and 64-bit platforms?

The maximum is currently 256 and it's the same on both platforms.

Regards,
Sven

I think you can have even larger sets, but they are not supported by the RTTI functions and the FCL streaming system. Also, if you are using sets larger than 32 elements, the default value for {$packset} is not very optimal, as it will waste space for 256 elements, even if you need only
33. So, you're better off using something like {$packset 4}. The default setting is only kept for backward compatibility.

Nikolay

Nikolay Nikolov wrote on Thu, 21 Jan 2016:

No, sets with more than 256 elements are not supported by the compiler.

Jonas

Sven Barth wrote

The maximum is currently 256 and it's the same on both platforms.

That you for all the information. 256 is more than enough for what I need.

As for my other question, I'll compare the assembler code to see how each option performs.

Regards,
- Graeme -

My public PGP key: http://tinyurl.com/graeme-pgp

Sven Barth wrote

You cam check this by compiling with -al and comparing the assembler code.

It seems using Sets produce slightly smaller assembler code (2 instructions less) for the example code I posted. Attached is a comparison.

I guess the other benefit is that using Sets is more "pascal like" and probably easier for more developers to understand.

Regards,
- Graeme -

My public PGP key: http://tinyurl.com/graeme-pgp

Am 25.01.2016 12:36 schrieb "Graeme Geldenhuys" <

: On 2016-01-20 23:11, Sven Barth wrote: > You cam check this by compiling with -al and comparing the assembler

code.

It seems using Sets produce slightly smaller assembler code (2 instructions less) for the example code I posted. Attached is a

comparison.

I guess the other benefit is that using Sets is more "pascal like" and probably easier for more developers to understand.

In theory the compiler could optimize the non-set code... I don't know whether the compiler is currently indeed capable of doing so though. Did you test with different optimization settings?
Anyway I agree that sets are easier to read ;)

Regards
Sven

Sven Barth wrote

Did you test with different optimization settings?

No, I use -O- for the test. But I did think that optimization might make a difference, but didn't actually test it.

Anyway I agree that sets are easier to read ;)

Yup. I've decided to change my bitmask usage to sets instead - purely for ease of reading and understanding the code.

Regards,
- Graeme -

My public PGP key: http://tinyurl.com/graeme-pgp