On Thursday, June 06, 2013 20:01:09 Andrei Alexandrescu wrote:
> On 6/6/13 6:12 PM, Jonathan M Davis wrote:
> > On Thursday, June 06, 2013 14:57:00 Walter Bright wrote:
> >> On 6/6/2013 2:23 PM, Andrei Alexandrescu wrote:
> >>> (The tool I'm envisioning
> >>> would add final annotations or prompt the user to add them.)
> >> 
> >> Sorry, that's never going to fly.
> > 
> > It could tell the programmer which functions it _thinks_ don't need to be virtual, but it can't be 100% correct.
> 
> It would be 100% correct if given the entire application. You may want to take a look at the CHA paper.

It may be (I'd have to look at the paper), but it's my understanding that dynamically loading libraries while the program would kill that when those libraries can change. You could have functions which are not currently overridden but which a later version of a plugin could override without needing the program to be recompiled. The tool would mark such functions as final, making it so that the plugin couldn't add such an override later without requiring the main program to be rebuilt.

- Jonathan M Davis

On Friday, 7 June 2013 at 00:04:18 UTC, Andrei Alexandrescu wrote:
> On 6/6/13 8:01 PM, Andrej Mitrovic wrote:
>> On 6/6/13, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
>>> In my heart of hearts I somehow hope this will blow over and we'll get
>>> to some actually interesting stuff...
>>
>> Which stuff? :)
>
> E.g. finalizing shared and threading.

+1.

By the way, was that a deliberate pun? If so, I bow to the master. ;)

David

On 6/7/13, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> E.g. finalizing shared and threading.

Complex stuff.. But as far as I know people tend to avoid using shared (what does it to, except not work with Phobos most of the time?). And since we're moving into a direction of thread isolation, it seems to me like shared is something that should be removed from the language and replaced with a library type.

Couldn't it be replaced with a library type? Disabling ++/-- is easy, we can write an opAssign, we could make opDispatch automatically return a Shared!(member), etc. I don't see why something that's both unsafe (sharing data) and slow should ever be directly supported by the language.

On Thursday, 6 June 2013 at 18:27:10 UTC, Walter Bright wrote:
> On 6/6/2013 11:11 AM, deadalnix wrote:
>> It is also possible to automatically generate code like :
>> if (virtualMethod == givenMethod) {
>>     givenMethod();
>> } else {
>>     virtualMethod();
>> }
>>
>> It sound like it is completely stupid, but in fact, as the compiler know the
>> call you'll do, it can run optimizations.
>
> You're right, that is a valid optimization for virtual methods. But, it is not as good as final, because the call to virtualMethod() negatively affects the code generation even if it is never called.
>
> (This is because of things like function calls destroy the scratch registers, meaning that variables can't easily be enregistered into them.)

Yes, which happen anyway for shared objects !

On Friday, 7 June 2013 at 00:34:45 UTC, deadalnix wrote:
> Yes, which happen anyway for shared objects !

This.

We can do whole-program-optimization to finalize
non-shared-library functions - and for shared-library functions
it doesn't make sense to finalize for performance - you're
trading one kind of indirection function call for another.

Can we all please address or recognize this?

On Thursday, 6 June 2013 at 23:54:49 UTC, Manu wrote:
>> The trouble, as has been pointed out before, is shared libraries.
>>
>
> And the existence of 'sufficiently smart linker', and the fact that the
> platforms that suffer from this stuff way harder than x86 almost always
> have less mature compilers/optimisers/linkers.
> I just wouldn't ever place my faith in the future arrival of some
> sufficiently-smart-[tool]. You couldn't make a business investment on that
> illusive possibility.

GCC and LLVM have what it take to implement this kind of stuff
and can do codegen for a large variety of plateforms. I think
it's never gonna work with dmd, and I think this is why Walter
and yourself are pushing that hard to break everybody's code.

On 7 June 2013 10:04, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>wrote:

> On 6/6/13 8:01 PM, Andrej Mitrovic wrote:
>
>> On 6/6/13, Andrei Alexandrescu<SeeWebsiteForEmai**l@erdani.org<SeeWebsiteForEmail@erdani.org>>
>>  wrote:
>>
>>> On 6/6/13 2:31 PM, Walter Bright wrote:
>>>
>>>  Ok, Manu, you win, I'm pretty much convinced.
>>>>
>>>
>>> In my heart of hearts I somehow hope this will blow over and we'll get to some actually interesting stuff...
>>>
>>
>> Which stuff? :)
>>
>
> E.g. finalizing shared and threading.


Looking forward to it! :)

On 6/6/2013 4:56 PM, Flamaros wrote:
> I think it depend of his simplicity and integration in the common D process
> development. Maybe because D build fast we can add some extra steps during build
> of the release?
> And developers of companies that develop the biggest application will be aware
> of this tool and certainly have script or advanced tools to build their software
> release, adding a line during the building process seems acceptable.

Consider a trivial and effective DMD tool for debugging and improving efficiency:

   -cov

and I'm the only one I know of that uses it.

Usage really doesn't get any simpler than that, but it fails because it requires the user to look at the feedback and then go edit his source code. Bzzzt!

What does work is:

    -O

and voila! Program runs faster! When we're talking about payoff for D users, bang for the buck, whatever, improving -O is where it's at, and making the semantics of D amenable to automated optimization is a big win.

On 6/6/2013 5:00 PM, Andrei Alexandrescu wrote:
> On 6/6/13 5:57 PM, Walter Bright wrote:
>> On 6/6/2013 2:23 PM, Andrei Alexandrescu wrote:
>>> (The tool I'm envisioning
>>> would add final annotations or prompt the user to add them.)
>>
>> Sorry, that's never going to fly.
>
> Like a dove.

Few companies care about performance like Facebook does. What performance analysis tools does FB use routinely and pervasively?

In my experience with major software companies, using anything other than -O is quite rare. Use of a profiler? nevah hoppin. Yes, a maverick here and there will use them, but use is not pervasive and routine.

Will our canonical D newbie coming from C++ or Java use such a tool? Nope. They'll run the compiler, if we're lucky they'll throw -O -release -inline -noboundscheck, then they'll give the thumbs up or down on performance. This thread is a classic example.

On 6/6/2013 4:54 PM, Manu wrote:
> And the existence of 'sufficiently smart linker', and the fact that the
> platforms that suffer from this stuff way harder than x86 almost always have
> less mature compilers/optimisers/linkers.
> I just wouldn't ever place my faith in the future arrival of some
> sufficiently-smart-[tool]. You couldn't make a business investment on that
> illusive possibility.

Linkers can't know what a plugin shared library is going to do.