November 29, 2009
Walter Bright, el 28 de noviembre a las 13:31 me escribiste:
> retard wrote:
> >Is this again one of those features that is supposed to hide the fact that dmd & optlink toolchain sucks? At least gcc can optimize the calls in most cases where the operator is defined to be virtual, but is used in non-polymorphic manner.
> 
> The gnu linker (ld) does not do any optimizations of virtual call => direct call. Optlink has nothing to do with it.

The *new* GNU Linker (gold) does (with plug-ins, both GCC and LLVM
provides plug-ins for gold to do LTO).

See:
http://gcc.gnu.org/wiki/LinkTimeOptimization
http://llvm.org/docs/GoldPlugin.html

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Se va a licitar un sistema de vuelos espaciales mendiante el cual, desde una
plataforma que quizás se instale en la provincia de Córdoba. Esas naves
espaciales va a salir de la atmósfera, va a remontar la estratósfera y desde
ahí elegir el lugar donde quieran ir de tal forma que en una hora y media
podamos desde Argentina estar en Japón, en Corea o en cualquier parte.
	-- Carlos Saúl Menem (sic)
December 01, 2009
On Fri, 27 Nov 2009 18:32:21 -0500, Walter Bright <newshound1@digitalmars.com> wrote:

> Making them not virtual would also make them not overridable, they'd all be implicitly final.
>
> Is there any compelling use case for virtual operator overloads? Keep in mind that any non-virtual function can still be a wrapper for another virtual method, so it is still possible (with a bit of extra work) for a class to have virtual operator overloads. It just wouldn't be the default.

I use virtual operator overloads in dcollections.  Such as opCat and opAppend.

collection1 ~= collection2; // 2 different collection types, using interfaces instead of templates to avoid code bloat.

Also, opApply should be by default virtual, since it's not a true operator.
December 01, 2009
Steven Schveighoffer wrote:
> On Fri, 27 Nov 2009 18:32:21 -0500, Walter Bright <newshound1@digitalmars.com> wrote:
> 
>> Making them not virtual would also make them not overridable, they'd all be implicitly final.
>>
>> Is there any compelling use case for virtual operator overloads? Keep in mind that any non-virtual function can still be a wrapper for another virtual method, so it is still possible (with a bit of extra work) for a class to have virtual operator overloads. It just wouldn't be the default.
> 
> I use virtual operator overloads in dcollections.  Such as opCat and opAppend.
> 
> collection1 ~= collection2; // 2 different collection types, using interfaces instead of templates to avoid code bloat.
> 
> Also, opApply should be by default virtual, since it's not a true operator.

Would you put up with a couple of forwarding functions?

Andrei
December 01, 2009
Leandro Lucarella wrote:
> Walter Bright, el 28 de noviembre a las 13:31 me escribiste:
>> retard wrote:
>>> Is this again one of those features that is supposed to hide the
>>> fact that dmd & optlink toolchain sucks? At least gcc can optimize
>>> the calls in most cases where the operator is defined to be
>>> virtual, but is used in non-polymorphic manner.
>> The gnu linker (ld) does not do any optimizations of virtual call =>
>> direct call. Optlink has nothing to do with it.
> 
> The *new* GNU Linker (gold) does (with plug-ins, both GCC and LLVM
> provides plug-ins for gold to do LTO).
> 
> See:
> http://gcc.gnu.org/wiki/LinkTimeOptimization
> http://llvm.org/docs/GoldPlugin.html
> 

I don't see that particular one in the links.
December 01, 2009
Walter Bright, el  1 de diciembre a las 11:17 me escribiste:
> Leandro Lucarella wrote:
> >Walter Bright, el 28 de noviembre a las 13:31 me escribiste:
> >>retard wrote:
> >>>Is this again one of those features that is supposed to hide the fact that dmd & optlink toolchain sucks? At least gcc can optimize the calls in most cases where the operator is defined to be virtual, but is used in non-polymorphic manner.
> >>The gnu linker (ld) does not do any optimizations of virtual call => direct call. Optlink has nothing to do with it.
> >
> >The *new* GNU Linker (gold) does (with plug-ins, both GCC and LLVM
> >provides plug-ins for gold to do LTO).
> >
> >See:
> >http://gcc.gnu.org/wiki/LinkTimeOptimization
> >http://llvm.org/docs/GoldPlugin.html
> 
> I don't see that particular one in the links.

Well, I was talking about link-time optimization in general, not virtual call elimination in particular :). I don't know exactly what kind of optimizations are supported currently, but bare in mind this is all very new (Gold and the LTO plug-ins)...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
- Que hacés, ratita?
- Espero un ratito...
December 01, 2009
On Tue, 01 Dec 2009 13:53:37 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Steven Schveighoffer wrote:
>> On Fri, 27 Nov 2009 18:32:21 -0500, Walter Bright <newshound1@digitalmars.com> wrote:
>>
>>> Making them not virtual would also make them not overridable, they'd all be implicitly final.
>>>
>>> Is there any compelling use case for virtual operator overloads? Keep in mind that any non-virtual function can still be a wrapper for another virtual method, so it is still possible (with a bit of extra work) for a class to have virtual operator overloads. It just wouldn't be the default.
>>  I use virtual operator overloads in dcollections.  Such as opCat and opAppend.
>>  collection1 ~= collection2; // 2 different collection types, using interfaces instead of templates to avoid code bloat.
>>  Also, opApply should be by default virtual, since it's not a true operator.
>
> Would you put up with a couple of forwarding functions?

Well, I'd certainly put up with it if I had no choice :)  But if I had a choice, I'd choose to keep them virtual.  I have little need for defining bulk operators with templates and mixins, my usage is mainly going to be separate implementations for each operator.  If the compiler could somehow optimize out all instances of the template function to reduce bloat, I think that would make it a little less annoying.

One more thing I wonder, can you alias template instantiations?  For example, I have code like this:

struct S
{
  alias opAdd add;

  void opAdd(int x);
}

How does one do that when opAdd is a template with an argument?

-Steve
December 01, 2009
== Quote from Steven Schveighoffer (schveiguy@yahoo.com)'s article
> If the compiler could somehow
> optimize out all instances of the template function to reduce bloat, I
> think that would make it a little less annoying.

What is the sudden obsession with code bloat here lately?  Check out this StackOverflow question that I posed a few weeks ago.  If anyone has a decent answer to it, I'd love to hear it.

http://stackoverflow.com/questions/1771692/when-does-template-instantiation-bloat-matter-in-practice
December 01, 2009
On Tue, 01 Dec 2009 16:28:14 -0500, dsimcha <dsimcha@yahoo.com> wrote:

> == Quote from Steven Schveighoffer (schveiguy@yahoo.com)'s article
>> If the compiler could somehow
>> optimize out all instances of the template function to reduce bloat, I
>> think that would make it a little less annoying.
>
> What is the sudden obsession with code bloat here lately?  Check out this
> StackOverflow question that I posed a few weeks ago.  If anyone has a decent
> answer to it, I'd love to hear it.

If I'm writing template code effectively as a "macro" meaning "call this virtual method", then there is no point in having template code whatsoever.

If I'm forced to write it because the compiler only will call a template, then I would like for the compiler to optimize out its "mistake".  Then I have no problem with it, because the net effect on the binary performance and size should be zero.  Even if I have to annotate the function to force it, that is fine with me.

Larger programs take more memory to run, and longer to load.  Not that my D programs need to squeeze every ounce of power out of the system, but I think nowadays there's too little emphasis on executable size optimization (or even memory consumption).

an ancecdote on bloatage:  I once had a driver for XP for my wireless USB network adapter that put an icon on the task tray, consuming roughly 10MB of memory.  Yep, to put an icon on the task tray, it needed 10MB.  Just in case I ever wanted to click on that icon to set up my wireless network (which I would never do because once it's set up, I'm done).  As a bonus, every week or so, some kind of memory leak would trigger, and it would consume about 200MB of memory before my system started thrashing and I had to kill the icon.  I tried to disable it and use Windows to configure my wireless card, and then it used 10MB to put a *grayed out icon* in the tray (which would continue the bonus plan).  I finally had to hunt down the offending executable and rename it to prevent it from starting.  And guess what?  the wireless adapter worked flawlessly.  It's shit like this that pisses me off when people say "oh, bloat is a think of the past, you get soo much memory and cpu now adays, you don't even notice it."  All those little 10MB programs add up pretty quickly.

-Steve
December 01, 2009
== Quote from Steven Schveighoffer (schveiguy@yahoo.com)'s article
> On Tue, 01 Dec 2009 16:28:14 -0500, dsimcha <dsimcha@yahoo.com> wrote:
> > == Quote from Steven Schveighoffer (schveiguy@yahoo.com)'s article
> >> If the compiler could somehow
> >> optimize out all instances of the template function to reduce bloat, I
> >> think that would make it a little less annoying.
> >
> > What is the sudden obsession with code bloat here lately?  Check out this
> > StackOverflow question that I posed a few weeks ago.  If anyone has a
> > decent
> > answer to it, I'd love to hear it.
> If I'm writing template code effectively as a "macro" meaning "call this
> virtual method", then there is no point in having template code whatsoever.
> If I'm forced to write it because the compiler only will call a template,
> then I would like for the compiler to optimize out its "mistake".  Then I
> have no problem with it, because the net effect on the binary performance
> and size should be zero.  Even if I have to annotate the function to force
> it, that is fine with me.
> Larger programs take more memory to run, and longer to load.  Not that my
> D programs need to squeeze every ounce of power out of the system, but I
> think nowadays there's too little emphasis on executable size optimization
> (or even memory consumption).
> an ancecdote on bloatage:  I once had a driver for XP for my wireless USB
> network adapter that put an icon on the task tray, consuming roughly 10MB
> of memory.  Yep, to put an icon on the task tray, it needed 10MB.  Just in
> case I ever wanted to click on that icon to set up my wireless network
> (which I would never do because once it's set up, I'm done).  As a bonus,
> every week or so, some kind of memory leak would trigger, and it would
> consume about 200MB of memory before my system started thrashing and I had
> to kill the icon.  I tried to disable it and use Windows to configure my
> wireless card, and then it used 10MB to put a *grayed out icon* in the
> tray (which would continue the bonus plan).  I finally had to hunt down
> the offending executable and rename it to prevent it from starting.  And
> guess what?  the wireless adapter worked flawlessly.  It's shit like this
> that pisses me off when people say "oh, bloat is a think of the past, you
> get soo much memory and cpu now adays, you don't even notice it."  All
> those little 10MB programs add up pretty quickly.
> -Steve

No, I agree.  Space efficiency does matter.  I've certainly jumped through some serious hoops to make my code more space efficient when dealing with large datasets.  The thing is that, at least in my experience, in any modern non-embedded program large enough for space efficiency to matter, the space requirements are dominated by data, not code.  Therefore, I use as many templates as I feel like and don't worry about it, and when I think about space efficiency, I think about representing my data efficiently.
December 02, 2009
Steven Schveighoffer wrote:
> On Tue, 01 Dec 2009 13:53:37 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Steven Schveighoffer wrote:
>>> On Fri, 27 Nov 2009 18:32:21 -0500, Walter Bright <newshound1@digitalmars.com> wrote:
>>>
>>>> Making them not virtual would also make them not overridable, they'd all be implicitly final.
>>>>
>>>> Is there any compelling use case for virtual operator overloads? Keep in mind that any non-virtual function can still be a wrapper for another virtual method, so it is still possible (with a bit of extra work) for a class to have virtual operator overloads. It just wouldn't be the default.
>>>  I use virtual operator overloads in dcollections.  Such as opCat and opAppend.
>>>  collection1 ~= collection2; // 2 different collection types, using interfaces instead of templates to avoid code bloat.
>>>  Also, opApply should be by default virtual, since it's not a true operator.
>>
>> Would you put up with a couple of forwarding functions?
> 
> Well, I'd certainly put up with it if I had no choice :)  But if I had a choice, I'd choose to keep them virtual.  I have little need for defining bulk operators with templates and mixins, my usage is mainly going to be separate implementations for each operator.  If the compiler could somehow optimize out all instances of the template function to reduce bloat, I think that would make it a little less annoying.

Most of the bloat in my experience comes from that ruddy int->ulong implicit conversion, which gets used in the function lookup rules. If ints didn't implicitly convert to ulong, 3/4 of my operator overloads would disappear -- because then 'long' would be able to do every integer type other than ulong.

> 
> One more thing I wonder, can you alias template instantiations?  For example, I have code like this:
> 
> struct S
> {
>   alias opAdd add;
> 
>   void opAdd(int x);
> }
> 
> How does one do that when opAdd is a template with an argument?
> 
> -Steve