Thread overview
quick question, probably of little importance...
Apr 26, 2023
WhatMeWorry
Apr 26, 2023
WhatMeWorry
Apr 26, 2023
H. S. Teoh
May 01, 2023
Cecil Ward
May 01, 2023
Cecil Ward
April 26, 2023

I just need an even/odd functionality. Don't think D has a built-in operator.

// Found this C code online.

int isEven(int num)
{
    return !(num & 1);
}

// found this in std.functional.unaryFun

alias isEven = unaryFun!("(a & 1) == 0");
assert(isEven(2) && !isEven(1));

If interested just in speed, is either one faster?

April 27, 2023
Don't forget ``num % 2 == 0``.

None should matter, pretty much all production compilers within the last 30 years should recognize all forms of this and do the right thing.
April 26, 2023
On Wednesday, 26 April 2023 at 23:02:07 UTC, Richard (Rikki) Andrew Cattermole wrote:
> Don't forget ``num % 2 == 0``.
>
> None should matter, pretty much all production compilers within the last 30 years should recognize all forms of this and do the right thing.

Thanks. Fastest reply ever! And I believe across the world?   I suppose my examples required overhead of a function call. So maybe num % 2 == 0 is fastest?
April 26, 2023
On Wed, Apr 26, 2023 at 11:07:39PM +0000, WhatMeWorry via Digitalmars-d-learn wrote:
> On Wednesday, 26 April 2023 at 23:02:07 UTC, Richard (Rikki) Andrew
> Cattermole wrote:
> > Don't forget ``num % 2 == 0``.
> > 
> > None should matter, pretty much all production compilers within the last 30 years should recognize all forms of this and do the right thing.
> 
> Thanks. Fastest reply ever! And I believe across the world?   I suppose my examples required overhead of a function call. So maybe num % 2 == 0 is fastest?

If performance matters, you'd be using an optimizing compiler. And unless you're hiding your function implementation behind a .di, almost all optimizing compilers would inline it, so you shouldn't even be able to tell the difference.


T

-- 
Without outlines, life would be pointless.
April 27, 2023
On 27/04/2023 11:07 AM, WhatMeWorry wrote:
> On Wednesday, 26 April 2023 at 23:02:07 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> Don't forget ``num % 2 == 0``.
>>
>> None should matter, pretty much all production compilers within the last 30 years should recognize all forms of this and do the right thing.
> 
> Thanks. Fastest reply ever! And I believe across the world?   I suppose my examples required overhead of a function call. So maybe num % 2 == 0 is fastest?

Indeed, all the way from New Zealand.

I wouldn't bother timing this. A compiler will rewrite it and emit whatever instructions it thinks is best for a given cpu target that you select. This is one of those things that was solved 30 years ago :)
May 01, 2023
On Wednesday, 26 April 2023 at 23:07:39 UTC, WhatMeWorry wrote:
> On Wednesday, 26 April 2023 at 23:02:07 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> Don't forget ``num % 2 == 0``.
>>
>> None should matter, pretty much all production compilers within the last 30 years should recognize all forms of this and do the right thing.
>
> Thanks. Fastest reply ever! And I believe across the world?   I suppose my examples required overhead of a function call. So maybe num % 2 == 0 is fastest?

I made a small change, making the retval a bool rather than an int. I got slightly better code generation with the int, as it seems that some of the compilers have not yet got all the good tricks they should be using when manipulating bool-typed expressions and also it can be one extra instruction converting values to bool strictly zero or one, not zero or any non-zero value. Here’s the D, enlarged a little so that we can see your routine in action, inlined. Your isEven boils down to two instructions with a seriously optimising compiler. I’ve included the x86-64 machine code generated by the GDC and LDC compilers so you can see how fast it is. GDC made a bit of a dog’s breakfast of my longer routine whereas LDC performed superbly. GDC generated twice as much code, but its excellent instruction scheduler and what looks like an awareness of ILP mean that the two streams of instructions will be carried out in parallel  so the two streams will only take three instruction times - ie whatever the total time is for those three instruction in the one stream - not six.

bool isEven( int num )
	{
	return ! ( num & 1 );
	}

bool AreBothEven( int a, int b )  // returns true if both arguments are even
	{
	return isEven( a )  &&  isEven( b );
	}

===
Compiler output:: GDC:: x86-64: -O3 -mcpu=native -frelease

bool isEven( int ):
	mov 	eax, edi
	not		eax
	and	        eax, 1
	ret

bool AreBothEven( int, int ):
	mov 	eax, edi
	not		esi
	not 	        eax
	and	        esi, 1
	and	        eax, 1
	cmovne  eax, esi
	ret

===
Compiler LDC: x86-64: -O3 -mcpu=native -release

bool isEven( int ):
	test	        dil, 1
	sete	al
	ret

bool AreBothEven( int, int ):
	or		edi, esi
	test	        dil, 1
	sete 	al
	ret
May 01, 2023
On Monday, 1 May 2023 at 03:53:24 UTC, Cecil Ward wrote:
> On Wednesday, 26 April 2023 at 23:07:39 UTC, WhatMeWorry wrote:
>> [...]
>

Correction: I can’t count. There are only two instructions in parallel with another pair running alongside, not three. The first reg, reg move counts as zero cycles, so the total time is just the sum of the following three instructions’ times, ignoring the other parallel stream.