Am 05.11.2021 um 02:06 schrieb Manfred:
> On 11/4/2021 8:29 PM, Bonita Montero wrote:
>> Am 04.11.2021 um 19:28 schrieb Manfred:
>>> On 11/4/2021 6:13 PM, Bonita Montero wrote:
>>>> Am 04.11.2021 um 17:58 schrieb Bonita Montero:
>>>>> You're right, but this works:
>>>>>
>>>>> bool test256( char *p, bool set )
>>>>> {
>>>>>      uint64_t *p64 = (uint64_t *)p;
>>>>>      return !(p64[0] + set) & !(p64[1] + set) & !(p64[2] + set) &
>>>>> !(p64[3] + set);
>>>>> }
>>>>
>>>> This is the assembly-variant (MSVC):
>>>>
>>>> PUBLIC ?test256@@YA_NPEBD_N@Z
>>>>
>>>> _TEXT SEGMENT
>>>> ?test256@@YA_NPEBD_N@Z PROC
>>>>      movzx    rdx, dl
>>>>      mov      r8, [rcx]
>>>>      add      r8, rdx
>>>>      setz     al
>>>>      mov      r8, [rcx + 8]
>>>>      add      r8, rdx
>>>>      setz     ah
>>>>      and      al, ah
>>>>      mov      r8, [rcx + 16]
>>>>      add      r8, rdx
>>>>      setz     ah
>>>>      and      al, ah
>>>>      mov      r8, [rcx + 24]
>>>>      add      r8, rdx
>>>>      setz     ah
>>>>      and      al, ah
>>>>      ret
>>>> ?test256@@YA_NPEBD_N@Z ENDP
>>>> _TEXT ENDS
>>>> END
>>>>
>>>> rcx is p, dl is set, r8 is volatile.
>>>
>>> This may leave ah nonzero on ret
>>
>> A bool-return is a single byte returned in al.
>>
>>
>
> But the assembler doesn't know that

The code returns the correct value in al where it is
expected by the caller.

Am 04.11.2021 um 18:28 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 04.11.2021 um 18:13 schrieb Ben Bacarisse:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>
>>>> You're right, but this works:
>>>>
>>>> bool test256( char *p, bool set )
>>>> {
>>>> uint64_t *p64 = (uint64_t *)p;
>>>
>>> This is undefined id p is not properly aligned for uint64_t.
>>
>> Doesn't matter on x86-computers, they're even optimized in a way that
>> unaligned accesses that don't cross page-bounaries have no performance
>> -penalty.
>>
>
> It is, of course, possible to implement the entire test256
> function with three instructions on x86. Exercise left
> to the student, but hint: AVX.

IF testing for ones or zeroes is variable the code is not
three instructions:

bool test256Avx( char *p, bool set )
{ __m256i xor_ = _mm256_xor_si256( *(__m256i *)p, _mm256_set1_epi8(
-(char)set ) );
return _mm256_testz_si256( xor_, xor_ );
}

.... which results in the following code ...

negl %esi
vmovd %esi, %xmm0
vpbroadcastb %xmm0, %ymm0
vpxor (%rdi), %ymm0, %ymm0
vptest %ymm0, %ymm0
sete %al
vzeroupper
ret

Am 05.11.2021 um 11:56 schrieb Bonita Montero:
> Am 04.11.2021 um 18:28 schrieb Scott Lurndal:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Am 04.11.2021 um 18:13 schrieb Ben Bacarisse:
>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>
>>>>> You're right, but this works:
>>>>>
>>>>> bool test256( char *p, bool set )
>>>>> {
>>>>>     uint64_t *p64 = (uint64_t *)p;
>>>>
>>>> This is undefined id p is not properly aligned for uint64_t.
>>>
>>> Doesn't matter on x86-computers, they're even optimized in a way that
>>> unaligned accesses that don't cross page-bounaries have no performance
>>> -penalty.
>>>
>>
>> It is, of course, possible to implement the entire test256
>> function with three instructions on x86.   Exercise left
>> to the student, but hint: AVX.
>
> IF testing for ones or zeroes is variable the code is not
> three instructions:
>
> bool test256Avx( char *p, bool set )
> {
>     __m256i xor_ = _mm256_xor_si256( *(__m256i *)p, _mm256_set1_epi8(
> -(char)set ) );
>     return _mm256_testz_si256( xor_, xor_ );
> }
>
> ... which results in the following code ...
>
>     negl    %esi
>     vmovd    %esi, %xmm0
>     vpbroadcastb    %xmm0, %ymm0
>     vpxor    (%rdi), %ymm0, %ymm0
>     vptest    %ymm0, %ymm0
>     sete    %al
>     vzeroupper
>     ret

The above code results from the expansion of _mm256_set1_epi8
through gcc. MSVC is not that clever so that you would need to
encode the instructions manually through individual intrinsics.

bool test256Avx( char *p, bool set )
{ __m256i xor_ = _mm256_xor_si256( *(__m256i *)p, _mm256_broadcastb_epi8(
_mm_cvtsi32_si128( -(char)set ) ) );
return _mm256_testz_si256( xor_, xor_ );
}

On my Linux-computer (Ryzen 7 1800X) this AVX-code is
30,5% slower than the 64 bit non-AVX integer-code !

Am 05.11.2021 um 18:20 schrieb Bonita Montero:
> Am 05.11.2021 um 11:56 schrieb Bonita Montero:
>> Am 04.11.2021 um 18:28 schrieb Scott Lurndal:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>> Am 04.11.2021 um 18:13 schrieb Ben Bacarisse:
>>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>>
>>>>>> You're right, but this works:
>>>>>>
>>>>>> bool test256( char *p, bool set )
>>>>>> {
>>>>>>     uint64_t *p64 = (uint64_t *)p;
>>>>>
>>>>> This is undefined id p is not properly aligned for uint64_t.
>>>>
>>>> Doesn't matter on x86-computers, they're even optimized in a way that
>>>> unaligned accesses that don't cross page-bounaries have no performance
>>>> -penalty.
>>>>
>>>
>>> It is, of course, possible to implement the entire test256
>>> function with three instructions on x86.   Exercise left
>>> to the student, but hint: AVX.
>>
>> IF testing for ones or zeroes is variable the code is not
>> three instructions:
>>
>> bool test256Avx( char *p, bool set )
>> {
>>      __m256i xor_ = _mm256_xor_si256( *(__m256i *)p, _mm256_set1_epi8(
>> -(char)set ) );
>>      return _mm256_testz_si256( xor_, xor_ );
>> }
>>
>> ... which results in the following code ...
>>
>>      negl    %esi
>>      vmovd    %esi, %xmm0
>>      vpbroadcastb    %xmm0, %ymm0
>>      vpxor    (%rdi), %ymm0, %ymm0
>>      vptest    %ymm0, %ymm0
>>      sete    %al
>>      vzeroupper
>>      ret
>
> The above code results from the expansion of _mm256_set1_epi8
> through gcc. MSVC is not that clever so that you would need to
> encode the instructions manually through individual intrinsics.
>
> bool test256Avx( char *p, bool set )
> {
>     __m256i xor_ = _mm256_xor_si256( *(__m256i *)p,
> _mm256_broadcastb_epi8( _mm_cvtsi32_si128( -(char)set ) ) );
>     return _mm256_testz_si256( xor_, xor_ );
> }
>
> On my Linux-computer (Ryzen 7 1800X) this AVX-code is
> 30,5% slower than the 64 bit non-AVX integer-code !

These are the timings:

std: 1.44802ns
asm: 1.84683ns
avx: 2.66244ns

std is my C++-function &-ing four bools which are p[n] + set.
asm is the straightforward asm-variant of that.
avx is the above avx-code.
So my straight idea written in C++ is the fastest.
I used __attribute((noinline) / __declspec(noinline) and disabled
whole program optimization to prevent the compiler from optimizing
away my code.

Groovy hepcat Ben Bacarisse was jivin' in comp.lang.c on Wed, 3 Nov 2021
10:50 pm. It's a cool scene! Dig it.

> Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> writes:
>
>> Groovy hepcat Stefan Ram was jivin' in comp.lang.c on Fri, 29 Oct
>> 2021 12:19 pm. It's a cool scene! Dig it.
>>
>>> skybuck2000 <skybuck2000@hotmail.com> writes:
>>>>The code needs to check if all bits are empty or if all bits
>>>>are full. So basically all clear or all set.
>>>
>>> I'd set up two constant arrays, kinda like
>>>
>>> uint32_t const f = 0xffffffff;
>>> uint32_t const a0[ 8 ]={ 0, 0, 0, 0, 0, 0, 0, 0, };
>>> uint32_t const a1[ 8 ]={ f, f, f, f, f, f, f, f, };
>>>
>>> , and then use memcmp with those arrays:
>>>
>>> if( !memcmp( ( void * )&x, ( void * )&a0, sizeof( x )))
>>> puts( "x is all zero" );
>>>
>>> . And only do more work /if/ I then learned that
>>> this was too slow.
>>
>> Here's a more flexible (but untested) way:
>>
>> #define ALL_CLEAR 1
>> #define ALL_SET 2
>>
>> unsigned all_bits_clear_or_set(unsigned char *data, size_t n)
>> {
>> unsigned clrset = 3;
>> size_t i;
>>
>> for(i = 0; i < n; i++)
>> {
>> if((unsigned char)~0U == data[i])
>> {
>> clrset ^= ALL_SET;
>> break;
>> }
>> }
>
> Logically, this is a while loop. I see of a lot of for loops being
> used
> this way. Is there an active anti-while campaign I've missed?

I don't know why you say that. It contains initialisation, condition
and update clauses - a for loop I'd say.
But if you want to use a while instead, and put in separate init and
update statements, you're perfectly free to do so.

>> for(i = 0; i < n; i++)
>> {
>> if(0 == data[i])
>> {
>> clrset ^= ALL_CLEAR;
>> break;
>> }
>> }
>
> Ditto.
>
> size_t i = 0;
> while (i < n && data[1] != 0) i++;
> clrset ^= (i < n ? ALL_CLEAR : 0);
>
>> return clrset;
>> }
>
> But this does not solve the problem. The OP wanted a test for all
> bits in all bytes, not all bits in at least one byte.

Perhaps you missed the intended logic (which, I admit, I
could've/should've commented better... or at all) that the returned
variable, clrset, is initialised to 3 (ALL_CLEAR | ALL_SET, which I now
wish I had used in the first place, for clarity) to assume that all
bits are set and all bits are clear. (Yeah, I know they can't be both;
but it's just a starting point.) The algorithm then checks the array
twice, once looking for bytes that are not all bits clear (and stopping
at the first instance, since that's all that's required to determine
that the array is not all clear), and once looking for bytes that are
not all bits set (again stopping at the first instance), and updating
clrset accordingly. By the end, clrset will contain either the value 0
indicating that the array is neither all bits clear nor all bits set, 1
(ALL_CLEAR) indicating that the array has all bits clear, or 2
(ALL_SET) indicating that the array has all bits set.
But, of course, as I said, it's untested, so I might have muffed it.

--

----- Dig the NEW and IMPROVED news sig!! -----

-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!

Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> writes:

> Groovy hepcat Ben Bacarisse was jivin' in comp.lang.c on Wed, 3 Nov 2021
> 10:50 pm. It's a cool scene! Dig it.
>
>> Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> writes:
>>
>>> Groovy hepcat Stefan Ram was jivin' in comp.lang.c on Fri, 29 Oct
>>> 2021 12:19 pm. It's a cool scene! Dig it.
>>>
>>>> skybuck2000 <skybuck2000@hotmail.com> writes:
>>>>>The code needs to check if all bits are empty or if all bits
>>>>>are full. So basically all clear or all set.
>>>>
>>>> I'd set up two constant arrays, kinda like
>>>>
>>>> uint32_t const f = 0xffffffff;
>>>> uint32_t const a0[ 8 ]={ 0, 0, 0, 0, 0, 0, 0, 0, };
>>>> uint32_t const a1[ 8 ]={ f, f, f, f, f, f, f, f, };
>>>>
>>>> , and then use memcmp with those arrays:
>>>>
>>>> if( !memcmp( ( void * )&x, ( void * )&a0, sizeof( x )))
>>>> puts( "x is all zero" );
>>>>
>>>> . And only do more work /if/ I then learned that
>>>> this was too slow.
>>>
>>> Here's a more flexible (but untested) way:
>>>
>>> #define ALL_CLEAR 1
>>> #define ALL_SET 2
>>>
>>> unsigned all_bits_clear_or_set(unsigned char *data, size_t n)
>>> {
>>> unsigned clrset = 3;
>>> size_t i;
>>>
>>> for(i = 0; i < n; i++)
>>> {
>>> if((unsigned char)~0U == data[i])
>>> {
>>> clrset ^= ALL_SET;
>>> break;
>>> }
>>> }
>>
>> Logically, this is a while loop. I see of a lot of for loops being
>> used
>> this way. Is there an active anti-while campaign I've missed?
>
> I don't know why you say that. It contains initialisation, condition
> and update clauses - a for loop I'd say.
> But if you want to use a while instead, and put in separate init and
> update statements, you're perfectly free to do so.

It's the break that makes me think that. I think it's more natural to
have the condition up front. I was taught to think about pre- and
post-conditions.

>> But this does not solve the problem. The OP wanted a test for all
>> bits in all bytes, not all bits in at least one byte.
>
> Perhaps you missed the intended logic (which, I admit, I
> could've/should've commented better... or at all) that the returned
> variable, clrset, is initialised to 3 (ALL_CLEAR | ALL_SET, which I now
> wish I had used in the first place, for clarity) to assume that all
> bits are set and all bits are clear. (Yeah, I know they can't be both;
> but it's just a starting point.) The algorithm then checks the array
> twice, once looking for bytes that are not all bits clear (and stopping
> at the first instance, since that's all that's required to determine
> that the array is not all clear), and once looking for bytes that are
> not all bits set (again stopping at the first instance),

The code does not do that. It scans for bytes that are all set and
stops at the first, flipping (so un-setting) the ALL_SET bit. I think
you have the two conditions flipped.

As it happens, I find the code re-written using two while loops much
easier to verify in my head, but that's because I've got into the habit
of inverting the test of a loop and checking that is makes sense just
after the loop.

Here is what you wrote, written as while loops, with the conditions that
must apply after the loop and in the following test as comments:

i = 0;
while (i < n && (unsigned char)~0U != data[i]) i++;
// i >= n or data[i] == -1
if (i < n)
// data[i] == -1
clrset ^= ALL_SET;

i = 0;
while (i < n && 0 != data[i]) i++;
// i >= n or data[i] == 0
if (i < n)
// data[i] == 0
clrset ^= ALL_CLEAR;

I don't think you would have got the test the wrong way round if you'd
written it this way. Here it is with the tests the right way round:

i = 0;
while (i < n && (unsigned char)~0U == data[i]) i++;
// i >= n or data[i] != -1
if (i < n)
// data[i] != -1
clrset ^= ALL_SET;

i = 0;
while (i < n && 0 == data[i]) i++;
// i >= n or data[i] != 0
if (i < n)
// data[i] != 0
clrset ^= ALL_CLEAR;

I think this is as obviously right and the previous code is obviously
wrong.

I do this automatically in my head (if the conditions are not too
complex) with every loop, so I notice, and worry, when I see a for loop
with a break in it because I know I've going to have to work harder to
check the code.

--
Ben.

Am 03.11.2021 um 12:50 schrieb Ben Bacarisse:
> Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> writes:
>
>> Groovy hepcat Stefan Ram was jivin' in comp.lang.c on Fri, 29 Oct 2021
>> 12:19 pm. It's a cool scene! Dig it.
>>
>>> skybuck2000 <skybuck2000@hotmail.com> writes:
>>>> The code needs to check if all bits are empty or if all bits
>>>> are full. So basically all clear or all set.
>>>
>>> I'd set up two constant arrays, kinda like
>>>
>>> uint32_t const f = 0xffffffff;
>>> uint32_t const a0[ 8 ]={ 0, 0, 0, 0, 0, 0, 0, 0, };
>>> uint32_t const a1[ 8 ]={ f, f, f, f, f, f, f, f, };
>>>
>>> , and then use memcmp with those arrays:
>>>
>>> if( !memcmp( ( void * )&x, ( void * )&a0, sizeof( x )))
>>> puts( "x is all zero" );
>>>
>>> . And only do more work /if/ I then learned that
>>> this was too slow.
>>
>> Here's a more flexible (but untested) way:
>>
>> #define ALL_CLEAR 1
>> #define ALL_SET 2
>>
>> unsigned all_bits_clear_or_set(unsigned char *data, size_t n)
>> {
>> unsigned clrset = 3;
>> size_t i;
>>
>> for(i = 0; i < n; i++)
>> {
>> if((unsigned char)~0U == data[i])
>> {
>> clrset ^= ALL_SET;
>> break;
>> }
>> }
>
> Logically, this is a while loop. I see of a lot of for loops being used
> this way. Is there an active anti-while campaign I've missed?
>
>> for(i = 0; i < n; i++)
>> {
>> if(0 == data[i])
>> {
>> clrset ^= ALL_CLEAR;
>> break;
>> }
>> }
>
> Ditto.
>
> size_t i = 0;
> while (i < n && data[1] != 0) i++;
> clrset ^= (i < n ? ALL_CLEAR : 0);
>

N000b !

>> return clrset;
>> }
>
> But this does not solve the problem. The OP wanted a test for all bits
> in all bytes, not all bits in at least one byte.
>

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> writes:

>> Perhaps you missed the intended logic (which, I admit, I
>> could've/should've commented better... or at all) that the returned
>> variable, clrset, is initialised to 3 (ALL_CLEAR | ALL_SET, which I
>> now wish I had used in the first place, for clarity) to assume that
>> all bits are set and all bits are clear. (Yeah, I know they can't
>> be both; but it's just a starting point.) The algorithm then
>> checks the array twice, once looking for bytes that are not all
>> bits clear (and stopping at the first instance, since that's all
>> that's required to determine that the array is not all clear), and
>> once looking for bytes that are not all bits set (again stopping at
>> the first instance),
>
> The code does not do that. It scans for bytes that are all set
> and stops at the first, flipping (so un-setting) the ALL_SET bit.
> I think you have the two conditions flipped.

I believe the original code is right except there are two ==
operators that should be != operators.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> writes:
>
>>> Perhaps you missed the intended logic (which, I admit, I
>>> could've/should've commented better... or at all) that the returned
>>> variable, clrset, is initialised to 3 (ALL_CLEAR | ALL_SET, which I
>>> now wish I had used in the first place, for clarity) to assume that
>>> all bits are set and all bits are clear. (Yeah, I know they can't
>>> be both; but it's just a starting point.) The algorithm then
>>> checks the array twice, once looking for bytes that are not all
>>> bits clear (and stopping at the first instance, since that's all
>>> that's required to determine that the array is not all clear), and
>>> once looking for bytes that are not all bits set (again stopping at
>>> the first instance),
>>
>> The code does not do that. It scans for bytes that are all set
>> and stops at the first, flipping (so un-setting) the ALL_SET bit.
>> I think you have the two conditions flipped.
>
> I believe the original code is right except there are two ==
> operators that should be != operators.

Yes (see my own follow up). In fact I took the operators to be correct
but the initialisation of clrset to be wrong, so I thought the OP was
aiming for a different function.

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> i = 0;
> while (i < n && (unsigned char)~0U == data[i]) i++;
> // i >= n or data[i] != -1
> if (i < n)
> // data[i] != -1
> clrset ^= ALL_SET;
>
> i = 0;
> while (i < n && 0 == data[i]) i++;
> // i >= n or data[i] != 0
> if (i < n)
> // data[i] != 0
> clrset ^= ALL_CLEAR;

For fun:

size_t i = -1, clear = 1, set = 1;
unsigned char ones = -1;
while( clear | set && ++i < n ){
clear &= data[i] == 0, set &= data[i] == ones;
}
return set<<1 | clear;

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> i = 0;
>> while (i < n && (unsigned char)~0U == data[i]) i++;
>> // i >= n or data[i] != -1
>> if (i < n)
>> // data[i] != -1
>> clrset ^= ALL_SET;
>>
>> i = 0;
>> while (i < n && 0 == data[i]) i++;
>> // i >= n or data[i] != 0
>> if (i < n)
>> // data[i] != 0
>> clrset ^= ALL_CLEAR;

For the record, not what I would write! I was explaining a point about
loops.

> For fun:
>
> size_t i = -1, clear = 1, set = 1;
> unsigned char ones = -1;
> while( clear | set && ++i < n ){
> clear &= data[i] == 0, set &= data[i] == ones;
> }
> return set<<1 | clear;
>

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> i = 0;
>>> while (i < n && (unsigned char)~0U == data[i]) i++;
>>> // i >= n or data[i] != -1
>>> if (i < n)
>>> // data[i] != -1
>>> clrset ^= ALL_SET;
>>>
>>> i = 0;
>>> while (i < n && 0 == data[i]) i++;
>>> // i >= n or data[i] != 0
>>> if (i < n)
>>> // data[i] != 0
>>> clrset ^= ALL_CLEAR;
>
> For the record, not what I would write! [...]

I never assumed otherwise. I was just having fun
with the code.

Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Sun, 7 Nov 2021
09:04 am. It's a cool scene! Dig it.

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> writes:
>
>>> Perhaps you missed the intended logic (which, I admit, I
>>> could've/should've commented better... or at all) that the returned
>>> variable, clrset, is initialised to 3 (ALL_CLEAR | ALL_SET, which I
>>> now wish I had used in the first place, for clarity) to assume that
>>> all bits are set and all bits are clear. (Yeah, I know they can't
>>> be both; but it's just a starting point.) The algorithm then
>>> checks the array twice, once looking for bytes that are not all
>>> bits clear (and stopping at the first instance, since that's all
>>> that's required to determine that the array is not all clear), and
>>> once looking for bytes that are not all bits set (again stopping at
>>> the first instance),
>>
>> The code does not do that. It scans for bytes that are all set
>> and stops at the first, flipping (so un-setting) the ALL_SET bit.
>> I think you have the two conditions flipped.
>
> I believe the original code is right except there are two ==
> operators that should be != operators.

Ah! (Slaps forehead.) Yes. Well spotted! :)

--

----- Dig the NEW and IMPROVED news sig!! -----

-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!

Conceptually this is very smart to invert the logic !

Your idea (Peter 'Shaggy' Haywood) has given me a new idea for the code:

Instead of wasting cpu cycles/times checking everything instead only check what is needed to come to a certain "inverted conclusions".

It is indeed not necessary to check all bits to see if they are all clear, if one of them is not clear then obviously the data is not empty, and the function can exit earlier.

It is indeed not necessary to check all bits to see if they are all set, if one of them is not set then obviously the data is not full, and the function can exit earlier.

HAHA ! Pretty smart and brilliant ! ;) =D

Or is it ? hmmmm

Maybe not.... it depends...

Let's analyze code below:

{$ifdef WIN32}
function TData.IsEmpty : boolean;
type
TUInt32Array = packed array[0..7] of longword;
var
vResult : longword;
begin
result := False;

vResult :=
TUInt32Array(mData)[0] or
TUInt32Array(mData)[1] or
TUInt32Array(mData)[2] or
TUInt32Array(mData)[3] or
TUInt32Array(mData)[4] or
TUInt32Array(mData)[5] or
TUInt32Array(mData)[6] or
TUInt32Array(mData)[7];

if vResult = 0 then
begin
result := True;
end;
end;
{$endif}

Theoretically it needs to pull in 8x 32 bit integers, this could strain the memory bus somewhat, slow down the cpu, while it's waiting for data.... and it may pollute the l1 data cache unnecessarily.

On the other hand it does only one branch comparison.

Now the alternative would be to do 8 branch comparisons. Perhaps there is a golden ground in the middle, maybe only do 2 or 4 comparisons that is a possibility as well.

So different combinations could be tried to see which one performs best.

Here is where a little bit of artificial intelligence could be handy.

The application could measure all versions during active/real world usage with statisticall data tracking... for the first few minutes or so...

Then once another variations and statistics collected it can switch to non-statistical methods and pick the one which it believes is the fastest.

Anyway let's create a worst case counter example and analyze that, untested code:

To cool thing is this also gets rid of the extra variable.

function TData.IsEmpty : boolean;
type
TUInt32Array = packed array[0..7] of longword;
begin
result := False;

// if not empty then exit.
if TUInt32Array(mData)[0]) <> 0 then exit;
if TUInt32Array(mData)[1]) <> 0 then exit;
if TUInt32Array(mData)[2]) <> 0 then exit;
if TUInt32Array(mData)[3]) <> 0 then exit;
if TUInt32Array(mData)[4]) <> 0 then exit;
if TUInt32Array(mData)[5]) <> 0 then exit;
if TUInt32Array(mData)[6]) <> 0 then exit;
if TUInt32Array(mData)[7]) <> 0 then exit;

result := True; // if execution reaches here then return true.
end;
{$endif}

Pretty cool,

These are still 8 data accesses, no or instructions, 8 comparisons, possibly 8 jumps

On average this will probably run at 4,4,4

It will take up some more branch predicators, less data cache

Hard to say which one will run faster ;) for now my bet would be on the first one, because or instructions are 1 cycle and produces can be 15 or something.

However data access can be in the range of 400 nanoseconds, maybe 400 cycles, that could severely impact performance.

And this this newer version might run faster, depends on how could the L1 data cache lining is, if it's good maybe 10 cycles per data access... for a average total of 40.

Hmmm... I may have to benchmark this sometime ! ;)

And the isFull version:

// untested code

{$ifdef WIN32}
function TData.IsFull : boolean;
type
TUInt32Array = packed array[0..7] of longword;
begin
result := False;

// if not full exit
if TUInt32Array(mData)[0] <> $FFFFFFFF then exit;
if TUInt32Array(mData)[1] <> $FFFFFFFF then exit;
if TUInt32Array(mData)[2] <> $FFFFFFFF then exit;
if TUInt32Array(mData)[3] <> $FFFFFFFF then exit;
if TUInt32Array(mData)[4] <> $FFFFFFFF then exit;
if TUInt32Array(mData)[5] <> $FFFFFFFF then exit;
if TUInt32Array(mData)[6] <> $FFFFFFFF then exit;
if TUInt32Array(mData)[7] <> $FFFFFFFF then exit;

result := True;
end;
{$endif}

Ok interesting,

Now we truely have something to benchmark ! ;) =D

I am kinda busy so this will have to wait time a further time, but other people are welcome to benchmark this themselfes ! ;) :)

Bye for now,
And thanks for the feedback and ideas !
Skybuck Flying ! =D