On Thursday, 23 April 2015 at 12:37:12 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 23 April 2015 at 08:56:38 UTC, rumbu wrote:
>> I think because of the potential overflow in a * 3 (if we ignore the a < 5 condition). To optimize this, a compiler must figure out that there is no overflow for any a < 5.
>
> Yes, it is because of modular artithmetics which is a D design flaw. In C++ this only applies to unsigned integers, signed integers are monothonic in C++. I think Rust uses non-modular for both and Ada allows you to specify it.
>
> Compiled using ICC:
>
> int foo(int a)
> {
> 	if (a > 5)
> 		return (a * 3) / 3;
> 	else
> 		return 0;
> }
>
> yields:
>
>         xorl      %edx, %edx
>         cmpl      $5, %edi
>         cmovle    %edx, %edi
>         movl      %edi, %eax
>         ret
>
> ---------------------------------
>
> int foo(unsigned int a)
> {
> 	if (a > 5)
> 		return (a * 3) / 3;
> 	else
> 		return 0;
> }
>
> yields:
>
>         cmpl      $5, %edi
>         jbe       ..B1.3
>         movl      $-1431655765, %eax
>         lea       (%rdi,%rdi,2), %ecx
>         mull      %ecx
>         shrl      $1, %edx
>         movl      %edx, %eax
>         ret
> ..B1.3:
>         xorl      %eax, %eax
>         ret

Just to confirm this, all C compilers I tried were able to use the undefined behaviour of signed overflow to avoid the multiplication. D compilers of course do not do this, as signed overflow is defined.

Nonetheless, I maintain that the compiler should be able to propagate the value range of a and perform the optimisation regardless.

On 4/23/2015 1:33 AM, John Colvin wrote:
> Is there a good reason for this,

Modern compilers check for literally thousands of such patterns, and more are constantly added. There's an infinitely "long tail" of these patterns possible, and at some point, you have to ship the compiler.

The ones that get added are the ones that, unsurprisingly, are brought to the compiler writers' attention, usually via a benchmark example that they are losing :-)

On 4/23/2015 5:37 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> Yes, it is because of modular artithmetics which is a D design flaw.

Out of the innumerable posts you write, I can't recall one which didn't assert that whatever D does is wrong.

On 4/23/2015 3:23 AM, Andrea Fontana wrote:
> I was wondering if compilers can optimize this:
>
> uint foo3(uint a)
> {
>    return a*!(a/5);
> }
>
> That actually gives the same results.

A fun article about these sorts of things:

http://www.davespace.co.uk/blog/20150131-branchless-sequences.html

On Thu, 23 Apr 2015 19:05:06 -0700, Walter Bright wrote:

> On 4/23/2015 5:37 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> Yes, it is because of modular artithmetics which is a D design flaw.
> 
> Out of the innumerable posts you write, I can't recall one which didn't assert that whatever D does is wrong.

that's 'cause he don't talking about features done right. ;-)

On Thursday, 23 April 2015 at 10:23:57 UTC, Andrea Fontana wrote:
> On Thursday, 23 April 2015 at 10:08:24 UTC, John Colvin wrote:
>>> asm.dlang.org
>>
>> and d.godbolt.org
>>
>> This isn't a D-specific question though, so gcc.godbolt.org would allow you to test a wider range of backends.
>
> I was wondering if compilers can optimize this:
>
> uint foo3(uint a)
> {
>   return a*!(a/5);
> }
>
> That actually gives the same results.

That is cool ! However, careful, division can stall the pipeline.

On Friday, 24 April 2015 at 02:33:19 UTC, ketmar wrote:
> On Thu, 23 Apr 2015 19:05:06 -0700, Walter Bright wrote:
>
>> On 4/23/2015 5:37 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
>> <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>> Yes, it is because of modular artithmetics which is a D design flaw.
>> 
>> Out of the innumerable posts you write, I can't recall one which didn't
>> assert that whatever D does is wrong.
>
> that's 'cause he don't talking about features done right. ;-)

Oh, but I have!! I've pointed out that the vision for D1 was right, but D2 ruined it by adding cruft without fixing the flaws... ;-)

Walter got A LOT right in his original _vision_ as represented on his original website for D1:

- Taking current practice for C++ and building a better syntax for the most common patterns.

- Clearly stating that a programming language should encourage you to write code that is aesthetically pleasing on the screen and make that easy.

- Clearly stating that language semantics should be so simple that you didn't need a long specification for it.

- Clearly stating that performance was imperative as a goal for the language and that D would not aim to replace higher level languages like C#.

I can applaud to this, anyone who has exposed themselves to the annoyances of C++ can applaud to this! And D1 was a step in the right direction. A good start.

The vision was lost on the way to D2, and most unfortunately the market for programming languages is a Winner Takes It All market. D2 is only a marginal improvement on C++, and worse in some areas. That can't win.

I find it worrying that the evangelical D users are perceiving D as a compiled scripting language and claim it is similar to Python... D semantics are not at all like Python. That can't win.

I find it worrying that the people who say they want to use D as a system programming language are into games, yet the projected vision for the D leadership now is to make it a web programming language that should ship with vibe.d. That can't win.

I find it worrying that so many people attracted to D system level programming are into games, yet game development needs are ignored. That can't win.

D is lucky that Rust is annoying, Go is marginal, and Nim is unknown, so people are stuck with ugly look C++ code.

There is a need to move towards something beautiful, and that's not in Andrei's vision, but in the original D1 vision + the improvements proposed by Bearophile, Timon Gehr and others. Or swing 100% to Andrei's direction and improve significantly on meta programming by adding pattern matching and partial evaluation, so that you have something significantly better than C++.

…but move...

Remember: It's a winner takes it all game.

On Friday, 24 April 2015 at 07:04:10 UTC, Ola Fosheim Grøstad wrote:
> I find it worrying that so many people attracted to D system level programming are into games, yet game development needs are ignored. That can't win.
>
> D is lucky that Rust is annoying, Go is marginal, and Nim is unknown, so people are stuck with ugly look C++ code.
>

+1 to all of this, D needs better ownership semantics to be useful for game development.
Many of the recent improvement requests have felt like ugly hacks at best(ref return is useless for classes, not sure if that was intended.)

I'm biased because I do essentially zero webdev though, so when I see a lot of changes for std.json or text processing, I don't get too excited. D has a lot of sugar but missing many essential things you'd expect if you want to compete with C++.

for example, typecons.unique has been in an unusable state for... ever? It's just another one of those things in D that feels like it will never be finished. It's hard to attract people to a language then tell them they need to fix the standard library if they want to use it. I'm aware that work is being done on master, but it's just one example(and there's tons of blockers...)

> There is a need to move towards something beautiful, and that's not in Andrei's vision, but in the original D1 vision + the improvements proposed by Bearophile, Timon Gehr and others. Or swing 100% to Andrei's direction and improve significantly on meta programming by adding pattern matching and partial evaluation, so that you have something significantly better than C++.

I think pattern matching and better meta programming in general would make the language better either way.

C++ has mach7 for pattern matching, all done in metaprogramming AFAIK. I doubt anything like that could be done in D without being far uglier.

On Friday, 24 April 2015 at 06:29:55 UTC, deadalnix wrote:
> On Thursday, 23 April 2015 at 10:23:57 UTC, Andrea Fontana wrote:
>> On Thursday, 23 April 2015 at 10:08:24 UTC, John Colvin wrote:
>>>> asm.dlang.org
>>>
>>> and d.godbolt.org
>>>
>>> This isn't a D-specific question though, so gcc.godbolt.org would allow you to test a wider range of backends.
>>
>> I was wondering if compilers can optimize this:
>>
>> uint foo3(uint a)
>> {
>>  return a*!(a/5);
>> }
>>
>> That actually gives the same results.
>
> That is cool ! However, careful, division can stall the pipeline.

I'm not an assembly expert but it seems that some compilers (using godbolt, asm.dlang.org) optimize it as:

return a*(a<=4)

gcc:

foo3(unsigned int):
	xor	eax, eax
	cmp	edi, 4
	setbe	al
	imul	eax, edi
	ret


gdc:

uint foo2(uint a)
{
  return a*(a<5);
}

uint foo3(uint a)
{
  return a*!(a/5);
}

uint example.foo2(uint):
	xorl	%eax, %eax
	cmpl	$4, %edi
	setbe	%al
	imull	%edi, %eax
	ret
uint example.foo3(uint):
	movl	%edi, %eax
	movl	$-858993459, %edx
	mull	%edx
	xorl	%eax, %eax
	shrl	$2, %edx
	testl	%edx, %edx
	sete	%al
	imull	%edi, %eax
	ret

On Friday, 24 April 2015 at 06:29:55 UTC, deadalnix wrote:
> On Thursday, 23 April 2015 at 10:23:57 UTC, Andrea Fontana wrote:
>> On Thursday, 23 April 2015 at 10:08:24 UTC, John Colvin wrote:
>>>> asm.dlang.org
>>>
>>> and d.godbolt.org
>>>
>>> This isn't a D-specific question though, so gcc.godbolt.org would allow you to test a wider range of backends.
>>
>> I was wondering if compilers can optimize this:
>>
>> uint foo3(uint a)
>> {
>>  return a*!(a/5);
>> }
>>
>> That actually gives the same results.
>
> That is cool ! However, careful, division can stall the pipeline.

No optimiser worth it's salt is going to emit a idiv instruction there.