November 29, 2017
On Tuesday, November 28, 2017 18:18:20 Walter Bright via Digitalmars-d wrote:
> On 11/28/2017 9:27 AM, Jacob Carlborg wrote:
> > Why would druntime be a barrier for you for those projects?
>
> When the C version is 90K and the translated D version is 1200K, it is a barrier. It's a barrier for others, as well.
>
> Another barrier for me has turned out to be the way assert() works in D. It just is not lightweight, and it visibly slows down dmd to have assert's turned on internally. The amount of machinery involved with it in druntime is way overblown. Hence, asserts in dmd are turned off, and that wound up causing me a lot of problems recently. There are even initiatives to add writefln like formatting to asserts. With betterC, asserts became lightweight and simple again.

I wouldn't have expected assertions to cost much more than however much it costs to evaluate the expression being asserted unless the assertion fails. Now, even that can slow down a program a fair bit, depending on what's being asserted and how many assertions there are, but it's not something that I would have expected to vary particular between C and D. It doesn't surprise me that the generated code would be larger than you'd get for the same assertions in C because how assertions are handled when they fail is quite different, but I would expect the assertions themselves to cost about the same in terms of performance as long as they don't fail. What's going on that's making them so much worse?

- Jonathan M Davis

November 29, 2017
On 11/29/2017 6:54 PM, Steven Schveighoffer wrote:
> But even though it doesn't come with Windows, it can be installed once, and shared between all applications that use it.

That's the theory. Unfortunately, that relies on the library not changing. Microsoft changes it all the time, hence "dll hell".

> The issue with druntime isn't that it's not installed, it's the static linking.

If the user still has to download the dll, he hasn't gained anything by dynamic linking.

> A second problem is that due to the way D works most of the time (with templates just about everywhere), each new release is likely to be binary-incompatible. So you will essentially need many copies of druntime, probably one per release that was used to compile any D programs on your system.

At this point, relying on druntime not changing is just not realistic. libc is different, having been cast in stone for nearly 30 years now.


> But this is much less of an issue, especially if there are many programs that build using the same release.

It didn't work for Microsoft shipping a different, incompatible C runtime DLL with each compiler.
November 29, 2017
On 11/29/2017 7:15 PM, Jonathan M Davis wrote:
> I wouldn't have expected assertions to cost much more than however much it
> costs to evaluate the expression being asserted unless the assertion fails.
> Now, even that can slow down a program a fair bit, depending on what's being
> asserted and how many assertions there are, but it's not something that I
> would have expected to vary particular between C and D. It doesn't surprise
> me that the generated code would be larger than you'd get for the same
> assertions in C because how assertions are handled when they fail is quite
> different, but I would expect the assertions themselves to cost about the
> same in terms of performance as long as they don't fail. What's going on
> that's making them so much worse?

The code *size* causes problems because it pushes the executing code out of the cache. Another issue (I should check this again) was doing null checks on member function calls, which is not necessary since if they're null it'll seg fault.

November 29, 2017
On Wednesday, November 29, 2017 19:29:56 Walter Bright via Digitalmars-d wrote:
> On 11/29/2017 7:15 PM, Jonathan M Davis wrote:
> > I wouldn't have expected assertions to cost much more than however much it costs to evaluate the expression being asserted unless the assertion fails. Now, even that can slow down a program a fair bit, depending on what's being asserted and how many assertions there are, but it's not something that I would have expected to vary particular between C and D. It doesn't surprise me that the generated code would be larger than you'd get for the same assertions in C because how assertions are handled when they fail is quite different, but I would expect the assertions themselves to cost about the same in terms of performance as long as they don't fail. What's going on that's making them so much worse?
>
> The code *size* causes problems because it pushes the executing code out of the cache.

Well, given that assertions would normally be used in a debug build where you generally don't optimize, and the debug symbols are compiled in, I wouldn't think that that would matter much in most cases.

> Another issue (I should check this again) was doing null
> checks on member function calls, which is not necessary since if they're
> null it'll seg fault.

I didn't think that we _ever_ checked for null on accessing members (though as I understand it, we actually do need to if the type is large enough that segfaults don't actually happen when dereferencing null - at least, we need to check for null in those cases in @safe code, or the code isn't really @safe).

- Jonathan M Davis

November 29, 2017
On 11/29/2017 8:02 PM, Jonathan M Davis wrote:
> Well, given that assertions would normally be used in a debug build where
> you generally don't optimize, and the debug symbols are compiled in, I
> wouldn't think that that would matter much in most cases.

I want them in the release build, which means they should be at minimal cost.
November 29, 2017
On 11/29/17 10:23 PM, Walter Bright wrote:
> On 11/29/2017 6:54 PM, Steven Schveighoffer wrote:
>> But even though it doesn't come with Windows, it can be installed once, and shared between all applications that use it.
> 
> That's the theory. Unfortunately, that relies on the library not changing. Microsoft changes it all the time, hence "dll hell".

My understanding is that if you use the Microsoft supplied MSI package as a dependency, there is only one installation of the libraries necessary. Granted, the last time I built MSI packages was about 10 years ago...

But I don't remember having issues with DLL hell with that, even across compiler releases.

Yes, they changed the library on some revisions, but your MSVCRT dll would also be installed in the right places (and the right version loaded at runtime).

But we don't have to look at Microsoft as the gurus of library deployment, there are many good solutions already out there for other OSes.

> 
>> A second problem is that due to the way D works most of the time (with templates just about everywhere), each new release is likely to be binary-incompatible. So you will essentially need many copies of druntime, probably one per release that was used to compile any D programs on your system.
> 
> At this point, relying on druntime not changing is just not realistic. libc is different, having been cast in stone for nearly 30 years now.

Baby steps, let's deploy it as a shared object first :) Until we do that, there is no point to worry about binary compatibility.

-Steve
November 29, 2017
On 11/29/17 10:29 PM, Walter Bright wrote:
> Another issue (I should check this again) was doing null checks on member function calls, which is not necessary since if they're null it'll seg fault.

Just happened last release.

https://dlang.org/changelog/2.077.0.html#removePreludeAssert

-Steve

November 29, 2017
On Wednesday, November 29, 2017 20:08:53 Walter Bright via Digitalmars-d wrote:
> On 11/29/2017 8:02 PM, Jonathan M Davis wrote:
> > Well, given that assertions would normally be used in a debug build
> > where
> > you generally don't optimize, and the debug symbols are compiled in, I
> > wouldn't think that that would matter much in most cases.
>
> I want them in the release build, which means they should be at minimal cost.

Well, we could always have an alternate implementation of assertions for release builds that acted closer to C's assert. We already transform assert(0) into something else with -release. In general, for debugging, I'd much prefer to have D's assert as it is now, but I don't see any reason why we couldn't do something differently with a flag like -release but which specifically made assertions more primitive and lightweight for a release build rather than removing them for those folks that want to leave assertions enabled in a release build. Personally, I wouldn't want to enable assertions in the release build of most stuff, but some folks definitely have expressed the sentiment that they don't like the -release flag being named what it is, because they don't think that assertions should be disabled for release builds.

- Jonathan M Davis

November 30, 2017
On Thursday, 30 November 2017 at 04:21:20 UTC, Steven Schveighoffer wrote:
> On 11/29/17 10:29 PM, Walter Bright wrote:
>> Another issue (I should check this again) was doing null checks on member function calls, which is not necessary since if they're null it'll seg fault.
>
> Just happened last release.
>
> https://dlang.org/changelog/2.077.0.html#removePreludeAssert
>
> -Steve

That was specifically for constructors and destructors (i.e. (cast(Foo)null).__ctor() was the only way to trigger that assert) not member functions (of classes), which I believe is still part of the compiler.
November 29, 2017
On 11/29/2017 8:49 PM, Jonathan M Davis wrote:
> Well, we could always have an alternate implementation of assertions for
> release builds that acted closer to C's assert.

My plan for release builds is to have an option to make them just execute a HALT instruction. Short, sweet, un-ignorable and too the point!