On Saturday, June 16, 2018 18:45:53 wjoe via Digitalmars-d-learn wrote: > What you said earlier: > > On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis wrote: > > [...] > > > > 2. If the compiler knows that a function can't throw an > > Exception, then it doesn't have to insert any of the Exception > > handling mechanism stuff [...] So, the fact that a function is > > nothrow gives you a performance benefit, [...] > > > > - Jonathan M Davis > > made me believe that performance is one of the major reasons to > use it. No? > > From the betterC page https://dlang.org/spec/betterc.html section > 40.2: > --- > Not Available > > D features not available with BetterC: > > Garbage Collection > TypeInfo and ModuleInfo > Classes > Built-in threading (e.g. core.thread) > Dynamic arrays (though slices of static arrays work) and > associative arrays > Exceptions > switch with strings > final switch > synchronized and core.sync > Static module constructors or destructors > Struct destructors > unittest (testing can be done without the -betterC flag) > --- > Apart from a few convenience features lost this list reads like a > shopping list for performance gain over full fledged D, in the > spirit of nothrow omitting exception handling mechanism, to me. > You gain from no garbage collection overhead, no vtable overhead, > no RTTI overhead, no exception overhead, etc, etc, ... > > Back in the late 90ies I used to write the lion's share of code > in Pascal and implement mission critical algorithms in asm. > Worked back then why wouldn't it work today, except that I > wouldn't use asm anymore but something like C or betterC. > > Thus, people who need this kind of performance boost can benefit > 2 fold from using betterC. > 1. They get to keep most of D's awesomeness, including compile > time features, scope statements, RAII, lack of a pre processor, > memory safety protections and complete meta programming, are just > _some_ of the highlights. And on the other hand > 2. they gain by getting rid of a lot the 'performance hogs' like > GC, exceptions and more, right? > And, with no exceptions altogether they do not need to worry > about it at all. > > I'm sold!
The _entire_ point of betterC is to be able to call D code from C code without having to deal with druntime (you can call D code from C code even without betterC, but then you have to worry about initializing and shutting down druntime). Basically every feature that you can't use in betterC is considered a loss, and efforts are being made to make more of them work. There's always going to be a limit to that, and some D features just plain require druntime (just like some of C++'s features require a runtime), but it was never the point of betterC to strip out a bunch of D features. That's just the natural consequence of the goal of being callable from C code without needing to worry about druntime. All of those features that betterC can't use can be avoided in normal D code if you don't want them for whatever reason. nothrow is actually one of the few cases where you have to explicitly do something in order to avoid that list of features that you have there. In the other cases, you just don't use the feature, and the only cost you're paying is the startup and shutdown time for druntime and the few resources that it uses. So, while you might choose to use betterC over concerns about the performance of D features that betterC doesn't allow, that was never the point of betterC. - Jonathan M Davis
