64bit DMD on Windows

Jonathan M Davis newsgroup.d at jmdavisprog.com
Fri Jun 29 20:57:24 UTC 2018


On Friday, June 29, 2018 20:23:05 bauss via Digitalmars-d wrote:
> On Friday, 29 June 2018 at 16:11:56 UTC, Seb wrote:
> > I hope we manage to ship it with the official releases soon.
>
> I can't wait.
>
> Honestly, a compiler should never run out of memory and it's a
> major issue that DMD does it.
>
> Regardless of that it has fast compilation, it should never run
> out of memory.
>
> I assume it's something that will never be fixed in DMD however,
> because of its memory model.

It could be fixed, even if it's just adding a compiler switch to indicate
that you want it to use the GC to collect memory, because you're going to
run out of memory if you don't. As I understand it, the compiler already can
have that turned on internally. It's just that it hurt compilation times
enough to do so that it's been left off - which makes sense for many, many
cases, but is a definite problem when your project is large enough or doing
enough CTFE that compiling it causes it to run out of memory. What the best
way to handle ti is, I don't know, since we do want the compilation speed in
the typical case, but we also don't want to run out of memory. A compiler
switch would be an easy out but less than ideal.

Regardless of all of that, I expect that newCTFE will have a fairly large
impact on memory consumption once it's finally ready, because the current
CTFE is an absolute memory hog (e.g. as I understand it, it allocates a new
object every time a variable is mutated, so doing something like
incrementing an integer in a loop in CTFE means that the compiler is doing a
_lot_ of allocating). So, depending on why folks run out of memory when
compiling, newCTFE alone may fix the problem for most folks.

Still, we really should have the 64-bit compiler binary available on
Windows. For most developers, there's really no reason to use a 32-bit
binary, and if it solves the running out of memory problem (even if it's
only by being able to throw more memory at the compiler), then that will be
a big help even if it doesn't fix the underlying problem that the compiler
isn't versatile enough to be able to free memory when it needs to without
paying the full cost of memory management when it doesn't need to.

- Jonathan M Davis



More information about the Digitalmars-d mailing list