What is dcache?

It's a patch for dmd that enables a *persistent* shared-memory hash-map, protected by a spin-lock from races. Dmd processes with -cache flag would detect the following pattern:

enum/static variable = func(args..);

And if mangle of func indicates it is from std.* we use a cache to store D source code form of a result of function call (a literal) produced by CTFE.

In action:

https://github.com/dlang/dmd/pull/7239

(Watch as 2.8s - 4.4s to compile various ctRegex programs becomes constant ~1.0s.)

Caching is done per expression so it stays active even after you change various parts of your files.

Broadening the scope to 3rd party libraries is planned but cache invalidation is going to be tricky. Likewise there is a trove of things aside from CTFE that can be easily cached and shared across both parallel and sequental compiler invocations.


Why caching compiler?

It became apparent that CTFE computations could be quite time-consuming and memory intensive. The fact that each CTFE invocation depends on a set of constant arguments, makes it a perfect candidate for caching.

Motivating example is ctRegex, patterns are hardly ever change and std.library changes only on compiler upgrade,  yet each change to a file causes complete re-evaluation of all patterns in a module.

With presistent per-expression cache we can precompile all of CTFE evluations for regexes, so we get to use ctRegex and maintain sane compile-times.

----

How to use

Pass new option to dmd:

-cache=mmap

This enables persistent cache using memory-mapped file.
Future backends would take the form of e.g.:

-cache=memcache:memcached.my.network:11211

----

Implementation

Caveats emptor: this is alpha version, use at your own risk!

https://github.com/DmitryOlshansky/dmd/tree/dcache

Keeping things simple - it's a patch of around 200 SLOCs.
I envision it becoming a hundred lines more if we get to do things cleanly.

Instead of going with strangely popular idea of compilation servers I opted for simple distributed cache, as it doesn't require changing any of the build systems.

Shared memory mapping split in 3 sections: Metadata (spinlock) + ToC (hash-table index) + Data (chunks)

For now it's an immutable cache w/o eviction.

A ToC entry is as follows:

hash(64-bit), data index, data size, last_recent_use

Indexes point to Data section of memory map.

Data itself is a linked list of blocks, where a header contains:

(isFree, next, 0-terminated key, padding to 16 bytes)

last_recent_use is a ts of the start of the respective compilation.  last_recent < now - 24h is considered unutilized and may be reused.

In theory we can cache result of any compilation step with a proper key and invalidation strategy.

1. Lexing - key is compiler-version + abs path + timestamp, store as is. Lexing from cache is simply taking slices of memory.

2. Parsing to Ast - key is compiler-version + abs path + timestamp + version/debug flags

3. CTFE invocations - key is tricky, for now only enabled for std.* as follows:

enum/static varname = func(args...);

Use compiler-version + compiler-flags + mangleof + stringof args.

On Tuesday, 24 October 2017 at 13:19:15 UTC, Dmitry Olshansky wrote:
> What is dcache?
>
> It's a patch for dmd that enables a *persistent* shared-memory hash-map, protected by a spin-lock from races. Dmd processes with -cache flag would detect the following pattern:

Blog post or it didn't happen!

On Tuesday, 24 October 2017 at 13:19:15 UTC, Dmitry Olshansky wrote:
> What is dcache?
>
> It's a patch for dmd that enables a *persistent* shared-memory hash-map, protected by a spin-lock from races. Dmd processes with -cache flag would detect the following pattern:
>

Ooooh, very nice! Looking forward to non-std lib usage.

On Tuesday, 24 October 2017 at 13:29:12 UTC, Mike Parker wrote:
> On Tuesday, 24 October 2017 at 13:19:15 UTC, Dmitry Olshansky wrote:
>> What is dcache?
>>
>> It's a patch for dmd that enables a *persistent* shared-memory hash-map, protected by a spin-lock from races. Dmd processes with -cache flag would detect the following pattern:
>
> Blog post or it didn't happen!

Let us at least try it outside of toy examples.

If anybody has std.regex.ctRegex usage I'd be curious to see:

1. Build time w/o -cache=mmap
2. First build time w -cache=mmap
3. Subsequent build times w -cache=mmap

P.S. It's a crude PoC. I think we can do better.

---
Dmitry Olshansky

On Tuesday, 24 October 2017 at 14:17:32 UTC, Dmitry Olshansky wrote:
> On Tuesday, 24 October 2017 at 13:29:12 UTC, Mike Parker wrote:
>> On Tuesday, 24 October 2017 at 13:19:15 UTC, Dmitry Olshansky wrote:
>>> What is dcache?
>>>
>>> It's a patch for dmd that enables a *persistent* shared-memory hash-map, protected by a spin-lock from races. Dmd processes with -cache flag would detect the following pattern:
>>
>> Blog post or it didn't happen!
>
> Let us at least try it outside of toy examples.
>
> If anybody has std.regex.ctRegex usage I'd be curious to see:
>
> 1. Build time w/o -cache=mmap
> 2. First build time w -cache=mmap
> 3. Subsequent build times w -cache=mmap
>
> P.S. It's a crude PoC. I think we can do better.

Another caveat: Posix-only for now.

Did a few cleanups and widened the scope a bit.

So here is what happens in my benchmark for std.regex.

-O -inline -release:
88s --> 80s,  memory use ~700Mb -> ~400Mb

-release:
19s -> 12.8s

Experimental std.regex.v2 is sadly broken by a recent change to array ops.
It would be very interesting to check as it eats up to 17Gb of RAM.

On 10/24/2017 05:02 PM, Dmitry Olshansky wrote:
> Experimental std.regex.v2 is sadly broken by a recent change to array ops. It would be very interesting to check as it eats up to 17Gb of RAM.

What got broken there?

On Tuesday, 24 October 2017 at 13:19:15 UTC, Dmitry Olshansky wrote:
> What is dcache?
>
> It's a patch for dmd that enables a *persistent* shared-memory hash-map, protected by a spin-lock from races. Dmd processes with -cache flag would detect the following pattern:
>
> [...]

Posted to reddit and HN by someone:

https://www.reddit.com/r/programming/comments/79bphm/caching_d_compiler_preview_version/
https://hn.algolia.com/?query=caching%20d%20compiler

Just laughed out loud at this HN comment comparing D to C++:

"ranges, native strings, an insanely straight-forward and powerful template engine, compile-time evaluation, native contract programming and unit testing, modules (read: what's a header guard?), make C++ feel like clanging rocks together to make fire compared to D."

On Saturday, 28 October 2017 at 23:18:05 UTC, Martin Nowak wrote:
> On 10/24/2017 05:02 PM, Dmitry Olshansky wrote:
>> Experimental std.regex.v2 is sadly broken by a recent change to array ops. It would be very interesting to check as it eats up to 17Gb of RAM.
>
> What got broken there?

New array ops implemented as __simd, I think it needs a __ctfe branch.

On Tuesday, 24 October 2017 at 13:19:15 UTC, Dmitry Olshansky wrote:
> What is dcache?
>
> It's a patch for dmd that enables a *persistent* shared-memory hash-map, protected by a spin-lock from races. Dmd processes with -cache flag would detect the following pattern:
>
> enum/static variable = func(args..);
>

Just want to give you the short feedback, that I think a caching mechanism sounds very good.

When developing for / with vibe.d the problem (is/was) that the Diet-templates where always recompiled, Sönke took my idea to save the result of the evaluation at startup.

So that at the second time not the .dt template is parsed and mixed in but a .d file.

(See: Experimental HTML template caching at https://github.com/rejectedsoftware/diet-ng/)
But they still get compiled every time.

Until now I did not found the time to test your compiler, but I think by the right way of caching it should be possible to speed up the edit-compile-cycle significantly.

So that using D and not an interpreted language (like Ruby/PHP) becomes more attractive even for small web projects.

Regards mt.

On 10/29/2017 9:25 AM, Dmitry Olshansky wrote:
> On Saturday, 28 October 2017 at 23:18:05 UTC, Martin Nowak wrote:
>> On 10/24/2017 05:02 PM, Dmitry Olshansky wrote:
>>> Experimental std.regex.v2 is sadly broken by a recent change to array ops. It would be very interesting to check as it eats up to 17Gb of RAM.
>>
>> What got broken there?
> 
> New array ops implemented as __simd, I think it needs a __ctfe branch.


Please post a bugzilla issue for it.