On Monday, 8 April 2019 at 13:34:04 UTC, jmh530 wrote:
> I'm in for an extra $100 at least for #2, could be persuaded on the others.

Haha, it is exciting that the community cares about those things a lot.
I think they need a separate thread, in which anyone is welcome to propose
how one could go about solving them (a thing I'm trying to figure out too).

On Monday, 8 April 2019 at 15:58:10 UTC, Stefanos Baziotis wrote:
> On Monday, 8 April 2019 at 13:34:04 UTC, jmh530 wrote:
>> I'm in for an extra $100 at least for #2, could be persuaded on the others.
>
> Haha, it is exciting that the community cares about those things a lot.
> I think they need a separate thread, in which anyone is welcome to propose
> how one could go about solving them (a thing I'm trying to figure out too).

You could start here:
https://forum.dlang.org/post/jyzgzxqgaggltgifwnxx@forum.dlang.org

On Monday, 8 April 2019 at 16:20:39 UTC, jmh530 wrote:
> You could start here:
> https://forum.dlang.org/post/jyzgzxqgaggltgifwnxx@forum.dlang.org

Thanks, I'm discussing with Ilya about something related to the DataFrame project
(specifically, the points that he wrote in the previous post). DataFrame project
is rough.. I will certainly sum up our discussion in a separate thread so
that anyone can see and add.

On Monday, 8 April 2019 at 10:47:17 UTC, Mike Franklin wrote:

> It's actually quite alarming how many calls there are to memcpy for such small amounts of data.
>
> Phobos:
>   count fn     size_in_bytes
>   48420 memcpy 8
>   26298 memcpy 2
>   26298 memcpy 1

I actually neglected to consider something here.  I think the compiler actually recognizes calls to memcpy and replaces them so it may not actually be making function calls for each of these.  Nevertheless, if this were implemented as a template in the runtime, there would be no need any compiler magic, which would make the compiler just that much simpler to implement and maintain.

Mike

On Tuesday, 9 April 2019 at 00:14:09 UTC, Mike Franklin wrote:
> I actually neglected to consider something here.  I think the compiler actually recognizes calls to memcpy and replaces them so it may not actually be making function calls for each of these.  Nevertheless, if this were implemented as a template in the runtime, there would be no need any compiler magic, which would make the compiler just that much simpler to implement and maintain.
>
> Mike

How do we know that? I guess yes the compiler could have done that but
don't we need a look in asm?

I get the general point though, good call.

- Stefanos

On Tuesday, 9 April 2019 at 14:52:52 UTC, Stefanos Baziotis wrote:

> How do we know that? I guess yes the compiler could have done that but
> don't we need a look in asm?

Yes, looking at the asm would be a good way to confirm it.  I haven't done that, and I'm mostly relying on rumor, but here's some evidence:  https://github.com/dlang/dmd/blob/e3cb9363bff55170624667fb819289aceccdc90d/src/dmd/backend/cod2.d#L3395-L3399

Mike

On Wednesday, 10 April 2019 at 00:05:16 UTC, Mike Franklin wrote:
> Yes, looking at the asm would be a good way to confirm it.  I haven't done that, and I'm mostly relying on rumor, but here's some evidence:  https://github.com/dlang/dmd/blob/e3cb9363bff55170624667fb819289aceccdc90d/src/dmd/backend/cod2.d#L3395-L3399

Yes, it's interesting. Well, unfortunately it needs a lot of time to understand
the backend enough to track whether it actually replaces it.

However, I made a simple test case:

import core.stdc.string;
extern(C) void main() {
	int a = 5;
	int b = 5;
	memcmp(&a, &b, int.sizeof);
}

which is a test case that should definitely be inlined.

Compiled with -betterC -g -O -release -inline, there is an actual call:
lea    rsi,[rbp-0x4]
lea    rdi,[rbp-0x8]
call   0x400640 <memcmp@plt>

and the code inside the call is what I would expect for a full memcmp.

I used -betterC because it makes smaller executables and makes it easy to
inspect on GDB. Maybe without it, dmd inlines it in some way although I doubt it.
Also, maybe LDC and GDC do something clever, but I don't have available right now either
of them.

On Wednesday, 10 April 2019 at 12:25:55 UTC, Stefanos Baziotis wrote:
> On Wednesday, 10 April 2019 at 00:05:16 UTC, Mike Franklin wrote:
>> [...]
>
> Yes, it's interesting. Well, unfortunately it needs a lot of time to understand
> the backend enough to track whether it actually replaces it.
>
> [...]

LDC does this
https://godbolt.org/z/y0WiI9

On Wednesday, 10 April 2019 at 12:40:47 UTC, Radu wrote:
> On Wednesday, 10 April 2019 at 12:25:55 UTC, Stefanos Baziotis wrote:
>> On Wednesday, 10 April 2019 at 00:05:16 UTC, Mike Franklin wrote:
>>> [...]
>>
>> Yes, it's interesting. Well, unfortunately it needs a lot of time to understand
>> the backend enough to track whether it actually replaces it.
>>
>> [...]
>
> LDC does this
> https://godbolt.org/z/y0WiI9

Actually, this is what you might look for:

https://godbolt.org/z/Zvyc3G

Notice that at -O the memcmp is inlined.

On Wednesday, 10 April 2019 at 12:56:39 UTC, Radu wrote:
> Actually, this is what you might look for:
>
> https://godbolt.org/z/Zvyc3G
>
> Notice that at -O the memcmp is inlined.

Yes, thanks Radu, as I said in the previous post, I don't have LDC on my machine
right now to test but I also didn't know that godbolt supports D. That's good.
GDC interestingly does not inline it.