Re: Array fill performance differences between for, foreach, slice

2020-04-08 Thread data pulverizer via Digitalmars-d-learn
In all honesty till now I haven't really thought deeply about memory allocation, I just assumed that malloc, free, and so on where low level operating system functions and that was that. I've heard people in the D community talk about garbage collection, and memory allocation but I didn't

Re: Array fill performance differences between for, foreach, slice

2020-04-01 Thread Steven Schveighoffer via Digitalmars-d-learn
On 4/1/20 11:23 AM, data pulverizer wrote: Thanks for all the suggestions made so far. I am still interested in looking at the implementation details of the slice assign `arr[] = x` which I can't seem to find. Before I made my initial post, I tried doing a `memcpy` and `memmove` under a `for`

Re: Array fill performance differences between for, foreach, slice

2020-04-01 Thread data pulverizer via Digitalmars-d-learn
Thanks for all the suggestions made so far. I am still interested in looking at the implementation details of the slice assign `arr[] = x` which I can't seem to find. Before I made my initial post, I tried doing a `memcpy` and `memmove` under a `for` loop but it did not change the performance

Re: Array fill performance differences between for, foreach, slice

2020-04-01 Thread Adam D. Ruppe via Digitalmars-d-learn
On Wednesday, 1 April 2020 at 15:04:44 UTC, Jesse Phillips wrote: It is nice that bounds checks remain in place when using release and the code is @safe. Yeah, it used to be even worse than it is now, but it is still a terrible switch that should NEVER be used. There are always better ways

Re: Array fill performance differences between for, foreach, slice

2020-04-01 Thread Jesse Phillips via Digitalmars-d-learn
On Wednesday, 1 April 2020 at 12:22:48 UTC, Adam D. Ruppe wrote: On Wednesday, 1 April 2020 at 06:48:09 UTC, Jacob Carlborg wrote: You have not enabled optimizations. You should compile with `-O -release -inline` to enable all optimizations. -release should *never* be used. You're trading

Re: Array fill performance differences between for, foreach, slice

2020-04-01 Thread lithium iodate via Digitalmars-d-learn
On Wednesday, 1 April 2020 at 06:48:09 UTC, Jacob Carlborg wrote: I you care about performance you should really compile using LDC (with `-O5 -release -flto=full -defaultlib=phobos2-ldc-lto,druntime-ldc-lto`), which usually produces much better code: Slice: Mean time(usecs): 50.58, Standard

Re: Array fill performance differences between for, foreach, slice

2020-04-01 Thread Adam D. Ruppe via Digitalmars-d-learn
On Wednesday, 1 April 2020 at 06:48:09 UTC, Jacob Carlborg wrote: You have not enabled optimizations. You should compile with `-O -release -inline` to enable all optimizations. -release should *never* be used. You're trading memory safety and security holes for a few microseconds of execution

Re: Array fill performance differences between for, foreach, slice

2020-04-01 Thread Jacob Carlborg via Digitalmars-d-learn
On 2020-03-31 23:30, data pulverizer wrote: $ dmd fill.d && ./fill You have not enabled optimizations. You should compile with `-O -release -inline` to enable all optimizations. Without optimizations I get numbers like these: Slice: Mean time(usecs): 92.91, Standard Deviation: 49.8002

Re: Array fill performance differences between for, foreach, slice

2020-03-31 Thread Steven Schveighoffer via Digitalmars-d-learn
On 3/31/20 5:30 PM, data pulverizer wrote: I've observed large differences in timing performance while filling arrays using different methods (for vs foreach vs arr[] = x) and don't know why. I've looked at array.d

Array fill performance differences between for, foreach, slice

2020-03-31 Thread data pulverizer via Digitalmars-d-learn
I've observed large differences in timing performance while filling arrays using different methods (for vs foreach vs arr[] = x) and don't know why. I've looked at array.d (https://github.com/dlang/dmd/blob/9792735c82ac997d11d7fe6c3d6c604389b3f5bd/src/dmd/root/array.d) but I'm still none the