On Saturday, 7 December 2013 at 00:40:52 UTC, Manu wrote:

>
> Assuming a comparison to C++, you know perfectly well that D has a severe
> disadvantage. Unless people micro-manage final (I've never seen anyone do
> this to date),

I do. Whether a function should be virtual is a design decision that needs to be made form the outset. Having all class functions freely overridable is not a good idea.

> then classes will have significantly inferior performance to
> C++.
> C++ coders don't write virtual on everything. Especially not trivial
> accessors which must be inlined.

07-Dec-2013 12:07, qznc пишет:
> On Saturday, 7 December 2013 at 00:26:34 UTC, H. S. Teoh wrote:
>> On Sat, Dec 07, 2013 at 01:09:00AM +0100, John Colvin wrote:
>
> What is the actual problem? Compile times? Binary size? Surely not
> performance or efficency.

Binary size and compile times. Since the end result doesn't penalize end-user in any other way it's a win across the board.

And you can always import whole packages.

> I remember someone from the Go team (maybe Pike), that they have
> deliberate code duplication in the standard library to decouple it. I
> did not understand the reasoning there, too.

That is just one way to it. Most of the time "the right thing" is to factor things into smaller reusable parts. Unlike Go we have ways to write very flexible code once and have it run at top speed in all cases.

-- 
Dmitry Olshansky

On 12/6/13 11:34 PM, Maxim Fomin wrote:
> On Friday, 6 December 2013 at 23:19:22 UTC, Walter Bright wrote:
>> Dmitry's regex also showed huge gains over C regex implementations.
>
> This C code is easy to fix.

That's not quite so. The second best after ctRegex is the Javascript V8 engine, which does the same thing - JITs the regex. This is not an easy fix for a traditional engine written in C.

Andrei

On 12/6/13 11:34 PM, Maxim Fomin wrote:
> And again, notice that you are speaking about 'hypothetical advantages'
> (language advantages) which implies two things:
> 1) current efficiency is worse when comparing with some benchmark
> 2) despite many years of development, community failed to realize these
> advantages.
>
> This makes me think that probably there is another reason of why code is
> less efficient, for example fundamental characteristics of the language
> make him hard to be quick. This is not bad per se, but saying that
> language code can be faster than C, taking into account some many
> problems with D, looks like advertisement, rather then technical
> comparison.

That is not advertisement, and your tenor is dissonant in this forum. This community, as pretty much any other languages', is looking for strategic advantages compared to other languages, and how to exploit them. It is perfectly natural to look for places where D semantics may lead to better code and exploit those at their best.

D code is easy to make fast. This has been shown numerous times in various contexts. There are also convenience features that are not aimed at performance, bugs, and insufficiencies. Enumerating them in an attempt to argue that D code is not or cannot be faster than C is missing the point.


Andrei

On 12/7/13 12:41 AM, Walter Bright wrote:
> But in D, using a best-of-breed
> implementation of quicksort is easy as pie

ahem :o)


Andrei

On Saturday, 7 December 2013 at 15:42:54 UTC, Andrei Alexandrescu wrote:
> On 12/6/13 11:34 PM, Maxim Fomin wrote:
>> And again, notice that you are speaking about 'hypothetical advantages'
>> (language advantages) which implies two things:
>> 1) current efficiency is worse when comparing with some benchmark
>> 2) despite many years of development, community failed to realize these
>> advantages.
>>
>> This makes me think that probably there is another reason of why code is
>> less efficient, for example fundamental characteristics of the language
>> make him hard to be quick. This is not bad per se, but saying that
>> language code can be faster than C, taking into account some many
>> problems with D, looks like advertisement, rather then technical
>> comparison.
>
> That is not advertisement, and your tenor is dissonant in this forum.

This is not the first time you are commenting my 'tenor' which is an unusual thing. Of course, it is dissosant in this 'forum', if you mean by forum constant advertisement which does not express full information about the subject (like reddit link bombing). When speaking about D newsgroups in general, I found myself pretty neutral.

> This community, as pretty much any other languages', is looking for strategic advantages compared to other languages, and how to exploit them. It is perfectly natural to look for places where D semantics may lead to better code and exploit those at their best.

I am happy with looking at strategic advantages, but strategic advantages are not excuse for current disadvantages. Perhaps some major bugs should be fixed before promoting the language?

> D code is easy to make fast. This has been shown numerous times in various contexts. There are also convenience features that are not aimed at performance, bugs, and insufficiencies. Enumerating them in an attempt to argue that D code is not or cannot be faster than C is missing the point.
>
>
> Andrei

I remember regex implementation as example of superior performance. I don't remember any other libraries, projects (perhaps vide.d in some activities). Meanwhile, many people regular complain on some problems. I do remember only one thread (it was started by Jonathan) which was devoted to single purpose of describing how D language is usefull and good to solve problems.

On 12/7/2013 1:52 AM, Joseph Rushton Wakeling wrote:
> On 07/12/13 02:10, Walter Bright wrote:
>> I know well that people used to C++ will likely do this. However, one can get in
>> the habit of by default adding "final:" as the first line in a class definition,
>> and then the compiler will tell you which ones need to be made virtual.
>
> The disadvantage of this approach is that, if one forgets to add that "final",
> it doesn't just produce a performance hit -- it means that it may be impossible
> to correct without breaking downstream code, because users may have overridden
> class methods that weren't meant to be virtual.

D doesn't allow overriding non-virtual functions (unlike C++).

On 12/7/2013 1:45 AM, Joseph Rushton Wakeling wrote:
> TL;DR the point is that writing in D gave me the opportunity to spend mental and
> programming time exploring these different choices and focusing on algorithms
> and data structures, rather than all the effort and extra LOC required to get a
> _particular_ idea running in C.  That's where the real edge arises.

I've noticed this too, but I've found it hard to explain to C programmers.

To say it a different way, D makes it easy to refactor code to rapidly try out different algorithms. In C, one tends to stick with the original design because it is so much harder to refactor.

On 07/12/13 18:29, Walter Bright wrote:
> D doesn't allow overriding non-virtual functions (unlike C++).

I'm speaking of the case where what you mean to write is,

    final class Foo
    {
        /* ... lots of methods which are all final, because
         * the class as a whole is final
         */
    }

but what you actually write is,

    class Foo    // Whoops!  Forgot the final
    {
        /* ... lots of methods which, because of the missing
         * "final", are instead virtual and can be overridden
         */
    }

In this case you can't fix the original error -- by adding "final" before the class declaration -- without risking breaking downstream code, because someone may have created a subclass of Foo that overrides one or more of its methods.

On Sat, Dec 07, 2013 at 09:33:53AM -0800, Walter Bright wrote:
> On 12/7/2013 1:45 AM, Joseph Rushton Wakeling wrote:
> >TL;DR the point is that writing in D gave me the opportunity to spend mental and programming time exploring these different choices and focusing on algorithms and data structures, rather than all the effort and extra LOC required to get a _particular_ idea running in C.  That's where the real edge arises.
> 
> I've noticed this too, but I've found it hard to explain to C programmers.
> 
> To say it a different way, D makes it easy to refactor code to rapidly try out different algorithms. In C, one tends to stick with the original design because it is so much harder to refactor.

D's metaprogramming capabilities and compile-time introspection help this a lot. Even little things like @property (in spite of the problems associated with its current implementation) go a long way in allowing two divergent implementations to share the same API, so that it's much easier to replace one implementation with another -- with no runtime cost.

In C, once you've committed to a particular implementation, you can't easily change it without rewriting large chunks of code. While it *is* possible to do this to some extent using void* and function ptrs and so on, that would introduce runtime overhead, whereas in D, it's only a compile-time difference. To avoid runtime overhead you'd have to make heavy use of macros, which quickly becomes a maintenance nightmare.


T

-- 
Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.