On Sunday, 30 December 2018 at 13:59:57 UTC, Petar Kirov [ZombineDev] wrote:
> On the other hand, hopefully soon we'll have the option to turn on the GC for the frontend. See: https://github.com/ldc-developers/ldc/pull/2916

GC might not be needed here. Compiler compiles your program in steps and memory that were used in previous step could be deallocated later in one place. We could just use a couple different allocators for different parts of compiler and call free on them when we are sure that nothing will need that data anymore. For example we can deallocate file buffers after we parsed those files. A person more familiar with compiler could find more cases where this kind of strategy is applicable.

On Sunday, 30 December 2018 at 16:51:07 UTC, Jacob Carlborg wrote:
> On 2018-12-30 15:46, Andrei Alexandrescu wrote:
>> On 12/29/18 9:03 PM, Timon Gehr wrote:
>>> alias then(alias a)=(r)=>map!a(r).joiner;
>> The "then" abstraction is pretty awesome. Thanks!
>
> Isn't that usually called "flatMap"?

Yeah, in Haskell monad terminology, "then" means >>, but flatMap is >>= ("bind").  So flatMap is a less confusing name for some people.

On Sunday, 30 December 2018 at 15:10:17 UTC, Guillaume Piolat wrote:
> On Sunday, 30 December 2018 at 13:46:46 UTC, H. S. Teoh wrote:
>>
>> There's also dmd's ridiculous memory usage policy, which is supposed to help compile times when you have ridiculous amounts of free RAM, but which causes anything from swap thrashing slowdowns to outright unusability on medium- to low-memory systems.
>>
>
> Don't get me started :)
> My VPS host has 512 mb RAM, and it's stressful when a D compiler can't build a few files. Upping this memory limit costs significantly more money.

i was shocked when i encountered the exact same thing on an ec2 micro instance. it was a bit upsetting and disappointing.

On 12/30/2018 5:18 AM, Atila Neves wrote:
> On Saturday, 29 December 2018 at 09:29:30 UTC, Walter Bright wrote:
>> http://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/
>>
>> Time to show off your leet D skilz and see how good we can do it in D!
> 
> I'm on it. As I write, I'm timing (compile and run time) several C++, D, and Rust implementations and writing a blog post. I'm only on the 2nd implementation but D is winning... :)
> 
> I'm going to shamelessly steal Timon's range code in this thread and the generator one posted on reddit.

Wow! I'm looking forward to it.

On 12/29/2018 6:03 PM, Timon Gehr wrote:
> Current D:
> ---
> import std.range, std.algorithm, std.typecons;
> import std.bigint, std.stdio;
> alias then(alias a)=(r)=>map!a(r).joiner;
> void main(){
>      auto triples=recurrence!"a[n-1]+1"(1.BigInt)
>          .then!(z=>iota(1,z+1).then!(x=>iota(x,z+1).map!(y=>tuple(x,y,z))))
>          .filter!((t)=>t[0]^^2+t[1]^^2==t[2]^^2);
>      triples.each!((x,y,z){ writeln(x," ",y," ",z); });
> }
> ---

I never would have thought of that. Thank you!

On 12/30/2018 6:27 AM, H. S. Teoh wrote:
> Recently I noticed that LDC now compiles every function into their own
> section

DMD has always done that.

> and runs LTO, including GC of unreferenced sections, by default.

I've tried using the GC feature of ld, but it would produce executables that crashed.

But that was years ago, perhaps ld has improved. If someone would like to turn that on with dmd, it would be a worthwhile experiment.

On 12/30/2018 5:46 AM, H. S. Teoh wrote:
> There's also dmd's ridiculous memory usage policy,
Now that D is written in D, one can compile it with:

    -profile=gc

and see where the memory usage is coming from.

On Sunday, 30 December 2018 at 14:27:56 UTC, H. S. Teoh wrote:
> Recently I noticed that LDC now compiles every function into their own section and runs LTO, including GC of unreferenced sections, by default. As a result, executable sizes are back down to where equivalent C/C++ code would be, as opposed to being a MB or so larger when compiled with DMD. It more-or-less nullifies most of the ill-effects of template bloat.

At DConf I showed executable size reductions on my apps resulting from applying LDC's LTO. They are on slide 14 here: https://github.com/eBay/tsv-utils/blob/master/docs/dconf2018.pdf. I didn't have a basis for comparison to equivalent C/C++ though.

--Jon

On 2018-12-30 23:37, Walter Bright wrote:

> I've tried using the GC feature of ld, but it would produce executables that crashed.

I think there might be some sections (perhaps the module info and similar) that need to be tagged (somehow) otherwise they will be removed.

-- 
/Jacob Carlborg

On Sunday, 30 December 2018 at 22:31:27 UTC, Walter Bright wrote:
> On 12/30/2018 5:18 AM, Atila Neves wrote:
>> On Saturday, 29 December 2018 at 09:29:30 UTC, Walter Bright wrote:
>>> http://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/
>>>
>>> Time to show off your leet D skilz and see how good we can do it in D!
>> 
>> I'm on it. As I write, I'm timing (compile and run time) several C++, D, and Rust implementations and writing a blog post. I'm only on the 2nd implementation but D is winning... :)
>> 
>> I'm going to shamelessly steal Timon's range code in this thread and the generator one posted on reddit.
>
> Wow! I'm looking forward to it.

Blog:

https://atilanevesoncode.wordpress.com/2018/12/31/comparing-pythagorean-triples-in-c-d-and-rust/

Reddit:

https://www.reddit.com/r/programming/comments/ab71ag/comparing_pythagorean_triples_in_c_d_and_rust/


Hacker news something something dark side.