On 12/7/13 8:23 AM, Maxim Fomin wrote:
> On Saturday, 7 December 2013 at 15:42:54 UTC, Andrei Alexandrescu wrote:
>> 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.

I agree it's unusual.

> 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).

What links did I post on reddit that would be inappropriate for the charter of that site?

> When speaking about D
> newsgroups in general, I found myself pretty neutral.

I'd find that difficult to argue. Consider:

http://forum.dlang.org/thread/l37h5s$2gd8$1@digitalmars.com?page=3#post-wllaccthfrnvquuhsbsr:40forum.dlang.org

It was a factual, undeniable piece of good news: some nontrivial D code was starting daily use at Facebook. There was no sensationalizing to complain about. Yet there had to be one smartaleck comment, and guess who it came from. Just browse through your own posting history. Making one's name a great predictor (NLP machine learning algos for sentiment analysis would love it) for snarky comments, facts be damned, is hardly being 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?

I appreciate your very strong contributions to the bug reports and associated discussions. It seems you are worried we're too busy keeping in denial about our shortcomings and feel the urge to keep us grounded every so often. Worry not. There is time to focus, and there is time to chillax.

>> 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.
>
> 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.

I agree we should fix problems that prevent maximum performance from being achieved simply and easily.


Andrei

07-Dec-2013 13:32, Johannes Pfau пишет:
> Am Sat, 07 Dec 2013 03:12:02 +0400
> schrieb Dmitry Olshansky <dmitry.olsh@gmail.com>:
>
>> 07-Dec-2013 02:20, Walter Bright пишет:
>>>
>>> "there is no way proper C code can be slower than those languages."
>>
>>> 3. Function inlining has generally been shown to be of tremendous
>>> value in optimization. D has access to all the source code in the
>>> program, or at least as much as you're willing to show it, and can
>>> inline across modules.
>>
>> Uh-oh. I'd avoid advertising this particular point until after a
>> critical bug is fixed:
>> https://d.puremagic.com/issues/show_bug.cgi?id=10985
>> Applies to all 3 compilers.
>>
>> Otherwise - it's spot on. D has many ways to be typically "faster
>> then Cee" ;)
>>
>
> But cross-module inlining can't be done if you have shared libraries
> cause you can not know if the other module is in a shared library right?
>

I've no idea how would compiler do inlining of a shared library internals. I believe it can inline everything in the same library that is not exported, right? (Is that your point (1) ?)

> If you inlined such code it wouldn't get updated if the shared library
> was updated and you'd have two versions of the code around...

Then some critical stuff simply must not be called via shared library and better be translated to ... 0-argument templates.

Use cases: std.ascii and not only that. Checking ASCII isAlpha as a _function call_ is madness.

>
> I see only 2 solution to avoid this:
>
> (1) If the source files are compiled at once it's safe to assume they
>      must be part of the same library and inlining is safe

> (2) The linker of course knows how objects fit together, so LTO.
>


-- 
Dmitry Olshansky

On 07/12/13 20:00, H. S. Teoh wrote:
> 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.

When I was writing a lot of C code, I used that approach a great deal -- I learned it from the internals of the GNU Scientific Library and found it very productive and useful for a lot of what I was working on.  Ironically, when I later came into touch with C++'s generics I found them very strange and found it difficult to see the sense in them, because I was so used to having and making use of _runtime_ polymorphism in C.

Am Sat, 07 Dec 2013 23:37:08 +0400
schrieb Dmitry Olshansky <dmitry.olsh@gmail.com>:

> > But cross-module inlining can't be done if you have shared libraries cause you can not know if the other module is in a shared library right?
> >
> 
> I've no idea how would compiler do inlining of a shared library
> internals. I believe it can inline everything in the same library
> that is not exported, right? (Is that your point (1) ?)

I think it can also inline stuff in the same library even if it's exported. But say for example libfoo is using libphobos and functions of libphobos are inlined into libfoo. Now there's a bugfix in libphobos but libfoo doesn't see it, as the function was inlined. You'd have to recompile libfoo as well.

The difficult part is, how do you know if two source files end up in the same library? Say you compile foo.d which depends on foo2.d and std/algorithm.d and you have the full source code for all three. Now how do you know that you shouldn't inline from algorithm.d but you can inline from foo2.d?

You can only be sure if foo.d and foo2.d are compiled at once. Or with LTO.

> 
> > If you inlined such code it wouldn't get updated if the shared library was updated and you'd have two versions of the code around...
> 
> Then some critical stuff simply must not be called via shared library and better be translated to ... 0-argument templates.
> 
> Use cases: std.ascii and not only that. Checking ASCII isAlpha as a _function call_ is madness.

That solution is also often used in C: Use macros for small functions that always need to be inlined. It's not exactly pretty but I don't know a better solution.

On Saturday, 7 December 2013 at 16:23:17 UTC, Maxim Fomin wrote:
> 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.
>

Sorry you aren't. Your argument do make a lot of sense. D do not devirtualize ? Can you explain me how C does ? You are actually mentioning drawback that C have too, the only difference between C and D on these is that C do not have the advantages.

> 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.

Tango.xml is another example. When it come to text processing, D is a no match to C.

On 8 December 2013 03:33, Walter Bright <newshound2@digitalmars.com> 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.
>

True as compared to C, but I wouldn't say this is true in general.
C# and Java make it easy to refactor code rapidly. D doesn't have any such
tools yet.
It's my #1 wishlist item for VisualD and Mono-D, and I await such tooling
with great anticipation.
Maybe when the D front-end is a library, and tooling has such powerful (and
reliable) semantic analysis as the compiler does it may be possible?

On 8 December 2013 03:29, Walter Bright <newshound2@digitalmars.com> wrote:

> 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++).
>

But, that's irrelevant, because if they did forget 'final' as suggested, then everything is virtual, so your point has no foundation.

There is overwhelming (almost total) evidence that people barely use final,
either due to inexperience/ignorance, indifference, or forgetfulness. I
suspect those criteria probably cover close to 100% of the workforce.
It can't be the default state, there are no syntactic safeguards. You've
agreed on that in the past. Have you doubled back, or do you still agree?

People who make the sort of _conscious choice_ for their OOP library that it should be the sort of java-like library where everything is overridable, can easily type 'virtual:' at the top, and make their intent explicit. There's no such simplicity with final, because unlike the 'everything is virtual' case, where 'virtual:' is easily applicable and the compiler _will produce an error message_ if they forget, there is no such useful concept 'everything is final', only 'most things are final', which means final must always be micromanaged; 'final:' can't easily be used like 'virtual:' can. And regardless, it remains prone to the risks in my second paragraph.

On 12/7/2013 4:46 PM, Manu wrote:
> True as compared to C, but I wouldn't say this is true in general.
> C# and Java make it easy to refactor code rapidly. D doesn't have any such tools
> yet.
> It's my #1 wishlist item for VisualD and Mono-D, and I await such tooling with
> great anticipation.
> Maybe when the D front-end is a library, and tooling has such powerful (and
> reliable) semantic analysis as the compiler does it may be possible?

Needing a tool to refactor code is a bit of a mystery to me. I've never used one, and never felt that not having one inhibited me from refactoring.

On Sunday, 8 December 2013 at 01:34:34 UTC, Walter Bright wrote:
> Needing a tool to refactor code is a bit of a mystery to me. I've never used one, and never felt that not having one inhibited me from refactoring.

Do you include renaming a variable as refactoring? I'm sure you can appreciate that having a tool automate that process reduces errors, and is faster (a generic text replace function is dangerous).

On 12/7/2013 5:49 PM, "Luís Marques" <luis@luismarques.eu>" wrote:
> Do you include renaming a variable as refactoring? I'm sure you can appreciate
> that having a tool automate that process reduces errors, and is faster (a
> generic text replace function is dangerous).

I've done global renaming, and it just hasn't been much of an issue. I suppose if I did it a lot a tool would help, but I don't do it often enough to matter.

I also usually run grep first to make sure I don't bork things up completely :-)

But when I talk about refactoring, I mean things like changing data structures and algorithms. Renaming things is pretty far over on the trivial end, and isn't going to help your program run any faster.