View mode: basic / threaded / horizontal-split · Log in · Help
November 29, 2009
Re: Should operator overload methods be virtual?
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
Re: Should operator overload methods be virtual?
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
Re: Should operator overload methods be virtual?
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
Re: Should operator overload methods be virtual?
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
Re: Should operator overload methods be virtual?
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
Re: Should operator overload methods be virtual?
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
Re: Should operator overload methods be virtual?
== 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
Re: Should operator overload methods be virtual?
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
Re: Should operator overload methods be virtual?
== 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
Re: Should operator overload methods be virtual?
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
1 2 3
Top | Discussion index | About this forum | D home