D Programming Language

Why D?

Show off D

Semantics

Garbage Collection

Example code showing GCStats:

import std.stdio;

extern (C)
{
    void gc_stats(GCStats* stats) nothrow;
}

struct GCStats
{
    size_t poolsize;        // total size of pool
    size_t usedsize;        // bytes allocated
    size_t freeblocks;      // number of blocks marked FREE
    size_t freelistsize;    // total of memory on free lists
    size_t pageblocks;      // number of blocks marked PAGE
}

void main()
{
    GCStats stats;
    gc_stats(&stats);
    writeln(stats);
    auto p = new byte[200];
    gc_stats(&stats);
    writeln(stats);
    p = new byte[1000];
    gc_stats(&stats);
    writeln(stats);
    p = new byte[10000];
    gc_stats(&stats);
    writeln(stats);
}

To turn on garbage collection profiling

$ max_column_sum_by_key_v1 --DRT-gcopt=profile:1 ngrams.tsv 1 2
max_key: 2006 sum: 22569013
        Number of collections:  132
        Grand total GC time:  246 milliseconds
GC summary:   35 MB,  132 GC  246 ms

Summary of GC discussion

See June 2016 discussion on the Garbage collector

Memory allocations are /always/ expensive. Higher level languages like Java have the benefit of using pools and optimizing for this usage pattern, D does and will never have this. Keep in mind an allocation = usage of malloc + write to returned pointer. – rikki c.

The point is, D doesn’t have to have a GC. Not using it is way easier than in most other languages because all the tools to help you profile it and avoid it are provided by the compiler. Go without a good GC is a dead language. D without a good GC is just not as good as it could be. And btw we’re generally faster than Go ;-) The point is: while a better GC is a work in progress we’ll never have a GC that can fit all needs, but it’s not as critical as it is in Go or in C# because we provide other ways to manage memory when limitations arise. – cym13

“Has anyone thought about taking GC from .NET and reusing it in D?”

One significant point has been already mentioned: cost of write barriers. I’d like to mention another factor: .NET GC is a copying one, it moves data around. One good feature of current D is it never moves data, so you can very easily call C and C++ code and pass pointers to your buffers and stuff and C/C++ code just takes these pointers and works with them as usual. No pinning, no marshaling, zero overhead. If you take a moving GC like .NET’s, you immediately make all C/C++ interaction much harder, now you need to worry about pinning stuff or copying “managed” data to “unmanaged” memory and back. This is all costly both in terms of CPU cycles and of programmer cycles. You’ll need “FFI”, what most other GC-ed languages have to have, and D doesn’t. –thedeemon

Precise Garbage Collector

GSoC project

It is essentially in a similar state that it was when Rainer presented it at DConf2013. The version in the pull request is not different from the one Rainer presented at all. It’s actually the same one, just updated with what has been changed in druntime recently and my attempts at making the marking phase faster.

Meta programming3

Debugging

Building

Serialization

Concurrency

Range based programming

Profiling / performance

D run time

Testing

C/C++ binding

Lexing and parsing

Another option is to use a lexer/state machine generator. Ragel supports D and Rust (as of the not-quite-released v7) as target languages. HN

Memory safety

Documenting D code

Higher level programming

Resources

Introduction

Intermediary

Articles

Tutorials

Presentations

Editor

Blogs

Talks

Read code

Discussions

Contributing to D development

Software written in D

Developing and distributing D software

Misc

User experience

Libraries

For some reason, many D programmers have this “collection of D libraries”, which is interesting in the sense that more than one developer has found it just easy to write their own library to do X…

In addition to those of CWEB:

Inspired from CWEB:

Interop