www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Caching D compiler - preview version

reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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.
Oct 24 2017
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
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!
Oct 24 2017
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Oct 24 2017
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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.
Oct 24 2017
parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
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?
Oct 28 2017
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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.
Oct 29 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Nov 01 2017
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Wednesday, 1 November 2017 at 19:33:15 UTC, Walter Bright 
wrote:

 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.


https://issues.dlang.org/show_bug.cgi?id=17964
Nov 03 2017
prev sibling next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Oct 24 2017
prev sibling next sibling parent Joakim <dlang joakim.fea.st> writes:
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."
Oct 29 2017
prev sibling parent Martin Tschierschke <mt smartdolphin.de> writes:
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.
Nov 01 2017