dmd -run speed trends (page 4)

December 19

Re: dmd -run speed trends

Posted by Siarhei Siamashka
in reply to Witold Baryluk

Permalink

Siarhei Siamashka

Posted in reply to Witold Baryluk

Permalink

On Sunday, 17 December 2023 at 17:34:01 UTC, Witold Baryluk wrote:

On Sunday, 17 December 2023 at 08:17:18 UTC, Siarhei Siamashka wrote:

Running touch was not enough to prevent Nim from reusing the cached version. Appending a single space character to the source code on each test iteration resolved this problem.

This is not how I run my tests of Nim. I cleaned all Nim cache instead.

And what have you achieved by clearing Nim's cache? Nim still spends a bit of time to check whether the cached binary exists. And then spends a bit of time to save the newly created binary in its cache for future use. That's an extra overhead and the comparison against dmd -run won't be fair no matter what you do. But the functionality of nim r and go run can be directly compared to rdmd and dub, because all of them implement various forms of caching.

> >

Creating binaries that depend on the shared Phobos library isn't a reasonable default configuration. However it seems to be perfectly fine if used specifically for the "-run" option. Would adding an extra section in the dmd.conf file for the "-run" configuration be justified?

What?! I always (for a decade) tough that dmd by default links dynamically phobos. I think it should definitively link dynamically by default. Just like gcc, gdc, ldc, clang are doing things. Compiling phobos statically by default does not really solve versioning fully anyway, as one still have dependencies on glibc, and such.

Dynamic linking with glibc isn't too bad. Old programs still keep working fine after upgrading glibc to newer versions. The same can't be said about phobos.

But I'm talking about dmd -run. The compiled binary is discarded after use. So there are no downsides of using dynamic linking in this scenario. We can get a nice compilation speed improvement for free. The use of static linking just makes dmd -run slower and this is a waste.

Thank you! But I'm a little confused. I'm not sure if the times posted are runtime or compile time. I'm interested in the runtime difference between writefln() and printf(). This is because with the next version of Phobos, I'd like performance issues of writefln() addressed.

On Tuesday, 19 December 2023 at 02:11:24 UTC, Walter Bright wrote:

Thank you! But I'm a little confused. I'm not sure if the times posted are runtime or compile time.

It's compile time + runtime + cache management overhead. Runtime is essentially zero and can be ignored here (see the source code of the program in the starter post of this thread).

Different caching strategies of the compiled binaries cause performance differences betwen dmd -run, rdmd and dub. The dmd -run case is a nearly pure compilation time with no cache management overhead. While rdmd and dub are somewhat slower.

I'm interested in the runtime difference between writefln() and printf().

The runtime differences between writefln() and printf() are neither tested nor discussed in this thread. People complain about the compilation time of writefln() and about the compilation time increase caused by importing various Phobos modules.

I myself don't mind moderately slower compilation time if it's a fair price for coding convenience. But I don't like when the compilation slowdown is caused by entirely stupid reasons. Such as static vs. dynamic linking of Phobos, missing PGO or a bad design of rdmd.

This is because with the next version of Phobos, I'd like performance issues of writefln() addressed.

Next Phobos version 2.107.0? Or a new Phobos design for D3?

BTW, I have https://github.com/competitive-dlang/speedy-stdio library, which runs circles around Phobos at runtime for the types of formatted output that it supports (and this special-cased fast-path code compiles as @nogc). But the library is slow to compile because of CTFE.

On Tuesday, 19 December 2023 at 02:11:24 UTC, Walter Bright wrote: > Thank you! But I'm a little confused. I'm not sure if the times posted are runtime or compile time. I'm interested in the runtime difference between writefln() and printf(). > > This is because with the next version of Phobos, I'd like performance issues of writefln() addressed. As Siarhei Siamashka mentioned, this post and thread are about compile time. I think post I care zero about runtime performance. The whole test program finishes in few milliseconds. Compared to 100-1000ms of compilation time. If IO performance is critical, I use my custom IO library, which bypasses phobos and libc completely (talking directly to kernel), has custom formatting, type conversions, optimized buffering methods, zero copy interfaces, and no GC. But obviously it would be nice to improve Phobos itself, as it is a decent match for generic applications.

Forums