June 01, 2013
Am 01.06.2013 01:30, schrieb Manu:
> On 1 June 2013 09:15, bearophile <bearophileHUGS@lycos.com
> <mailto:bearophileHUGS@lycos.com>> wrote:
>
>     Manu:
>
>         On 1 June 2013 01:12, bearophile <bearophileHUGS@lycos.com
>         <mailto:bearophileHUGS@lycos.com>> wrote:
>
>             Manu:
>
>
>               Frankly, this is a textbook example of why STL is the
>             spawn of satan. For
>
>                 some reason people are TAUGHT that it's reasonable to
>                 write code like
>                 this.
>
>
>             There are many kinds of D code, not everything is a high
>             performance
>             ray-tracer or 3D game. So I'm sure there are many many
>             situations where
>             using the C++ STL is more than enough. As most tools, you
>             need to know
>             where and when to use them. So it's not a Satan-spawn :-)
>
>
>         So why are we having this conversation at all then if faster
>         isn't better in this instance?
>
>
>     Faster is better in this instance.
>     What's wrong is your thinking that the STL as the spawn of Satan in
>     general.
>
>
> Ah, but that's because it is ;)
> Rule of thumb: never use STL in tight loops. problem solved (well,
> mostly)...

I have to agree here. Whenever you have a codebase that has to work on 9 platforms and 6 compilers the S in STL vanishes. Also the implementations are so varying in quality that you might get really good performance on one platform but really bad on another. It seems like everyone in the games industry avoids STL like the plague.

Kind Regards
Benjamin Thaut
June 01, 2013
Hi Andrei,

I have summarized the results with LDC on Mac OSX in a previous posts:

orignal: 760ms
* change v = [x,x,x] to v[0]=x... in this(float) constructor - 540ms (220ms improvment)
* remove this(float[]) constructor and replace it with this(float,float,float) - 410ms (130ms improvment)
* "final" to all class methods - 350 (60ms improvment)
* hand unroll overloaded vector arithmetic operators, 260ms (90ms improvment)

However I retested on a windows 7 machine with GDC compiler and the results were very different.

orignal: 545ms
* the first 2 optimizations which helped the most on OSX with LDC has almost zero effect
* hand unroll overloaded vector arithmetic operators - 280ms (265ms improvment)
* "final" to all class methods - 200ms (80ms improvment)


On Saturday, 1 June 2013 at 13:36:44 UTC, Andrei Alexandrescu wrote:
>
> Would be great to collect a summary of the changes and their benefits.
>
> Thanks finalpatch and everyone else for this work.
>
>
> Andrei

June 01, 2013
Am 01.06.2013 16:24, schrieb Benjamin Thaut:
> Am 01.06.2013 01:30, schrieb Manu:
>> On 1 June 2013 09:15, bearophile <bearophileHUGS@lycos.com
>> <mailto:bearophileHUGS@lycos.com>> wrote:
>>
>>     Manu:
>>
>>         On 1 June 2013 01:12, bearophile <bearophileHUGS@lycos.com
>>         <mailto:bearophileHUGS@lycos.com>> wrote:
>>
>>             Manu:
>>
>>
>>               Frankly, this is a textbook example of why STL is the
>>             spawn of satan. For
>>
>>                 some reason people are TAUGHT that it's reasonable to
>>                 write code like
>>                 this.
>>
>>
>>             There are many kinds of D code, not everything is a high
>>             performance
>>             ray-tracer or 3D game. So I'm sure there are many many
>>             situations where
>>             using the C++ STL is more than enough. As most tools, you
>>             need to know
>>             where and when to use them. So it's not a Satan-spawn :-)
>>
>>
>>         So why are we having this conversation at all then if faster
>>         isn't better in this instance?
>>
>>
>>     Faster is better in this instance.
>>     What's wrong is your thinking that the STL as the spawn of Satan in
>>     general.
>>
>>
>> Ah, but that's because it is ;)
>> Rule of thumb: never use STL in tight loops. problem solved (well,
>> mostly)...
>
> I have to agree here. Whenever you have a codebase that has to work on 9
> platforms and 6 compilers the S in STL vanishes. Also the
> implementations are so varying in quality that you might get really good
> performance on one platform but really bad on another. It seems like
> everyone in the games industry avoids STL like the plague.
>
> Kind Regards
> Benjamin Thaut

I used to have that experience even with C, when I started using it around 1994. C++ was even worse between CFront, ARM and ongoing standardization work.

As for STL, I can assure that HPC guys are huge fans of STL and Boost.

At least when I did my traineeship at CERN (2003-2004) that was the case.

--
Paulo
June 01, 2013
On 5/30/2013 7:56 PM, Andrei Alexandrescu wrote:
> On 5/30/13 9:26 PM, finalpatch wrote:
>> https://dl.dropboxusercontent.com/u/974356/raytracer.d
>> https://dl.dropboxusercontent.com/u/974356/raytracer.cpp
>
> Manu's gonna love this one: make all methods final.

I have another suggestion. class Sphere and class Ray should be structs. Neither class uses polymorphism in any way, so there's no reason to make them classes with virtual functions.

June 01, 2013
Am Fri, 31 May 2013 14:17:04 -0500
schrieb Sean Cavanaugh <WorksOnMyMachine@gmail.com>:

> On 5/31/2013 4:42 AM, Manu wrote:
> >
> > People already have to type 'override' in every derived class, and they're happy to do that. Requiring to type 'virtual' in the base is hardly an inconvenience by contrast. Actually, it's quite orthogonal. D tends to prefer being explicit. Why bend the rules in this case, especially considering the counterpart (override) is expected to be explicit? Surely both being explicit is what people would expect?
> >
> 
> Maybe the solution is to make everyone equally unhappy:
> 
> all (non constructor) class methods must be either final, override, or virtual, if you leave one of these off, you get an error :)

A method can be private, which means inherently final.

-- 
Marco

June 01, 2013
Am Sat, 01 Jun 2013 11:22:41 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 5/30/2013 7:56 PM, Andrei Alexandrescu wrote:
> > On 5/30/13 9:26 PM, finalpatch wrote:
> >> https://dl.dropboxusercontent.com/u/974356/raytracer.d https://dl.dropboxusercontent.com/u/974356/raytracer.cpp
> >
> > Manu's gonna love this one: make all methods final.
> 
> I have another suggestion. class Sphere and class Ray should be structs. Neither class uses polymorphism in any way, so there's no reason to make them classes with virtual functions.

Yes, that's the easiest (and for Ray the right(tm)) way to get
rid of virtual functions. But, I think it is safe to assume
that there will be different object classes in the big picture.

-- 
Marco

June 01, 2013
On Saturday, June 01, 2013 22:43:32 Marco Leise wrote:
> Am Sat, 01 Jun 2013 11:22:41 -0700
> 
> schrieb Walter Bright <newshound2@digitalmars.com>:
> > On 5/30/2013 7:56 PM, Andrei Alexandrescu wrote:
> > > On 5/30/13 9:26 PM, finalpatch wrote:
> > >> https://dl.dropboxusercontent.com/u/974356/raytracer.d https://dl.dropboxusercontent.com/u/974356/raytracer.cpp
> > > 
> > > Manu's gonna love this one: make all methods final.
> > 
> > I have another suggestion. class Sphere and class Ray should be structs. Neither class uses polymorphism in any way, so there's no reason to make them classes with virtual functions.
> 
> Yes, that's the easiest (and for Ray the right(tm)) way to get
> rid of virtual functions. But, I think it is safe to assume
> that there will be different object classes in the big picture.

If you don't need polymorphism, then in general, you shouldn't use a class (though sometimes it might make sense simply because it's an easy way to get a reference type). Where it becomes more of a problem is when you need a few polymorphic functions and a lot of non-polymorphic functions (e.g. when a class has a few methods which get overridden and then a lot of properties which it makes no sense to override). In that case, you have to use a class, and then you have to mark a lot of functions as final. This is what folks like Manu and Don really don't like, particularly when they're in environments where the extra cost of the virtual function calls actually matters.

- Jonathan M Davis
June 01, 2013
Am Sat, 01 Jun 2013 06:49:47 +0200
schrieb "deadalnix" <deadalnix@gmail.com>:

> On Saturday, 1 June 2013 at 02:58:59 UTC, Juan Manuel Cabo wrote:
> >
> > Making everything final by default would IMO kind of break
> > automated mock classes generation for unit testing,
> > automatic proxy class generation for DB entities, and
> > other OOP niceities.
> >
> 
> Yeah, everybody seems to ignore that. OOP is slow in general, due to excess of indirections, so if its loose its benefits . . .

Does it really change anything? Today people forget the
final keyword and tomorrow they forget the virtual
keyword? :D

What you prefer here depends on what languages you are used to do (e.g. C++, Java), how much you use OOP for anything, your use of unittesting and mock objects, your need for speed etc.

In any case D is often compared to C++ for memory management, speed, executable size etc. And D is trying to appeal to too many different fields of software development to be perfect for any of them. So maybe this should just be solved in a democratic vote after hearing the pros and cons. :)

-- 
Marco

June 02, 2013
On 2 June 2013 01:19, Paulo Pinto <pjmlp@progtools.org> wrote:

> Am 01.06.2013 16:24, schrieb Benjamin Thaut:
>
>  Am 01.06.2013 01:30, schrieb Manu:
>>
>>> On 1 June 2013 09:15, bearophile <bearophileHUGS@lycos.com <mailto:bearophileHUGS@lycos.**com <bearophileHUGS@lycos.com>>> wrote:
>>>
>>>     Manu:
>>>
>>>         On 1 June 2013 01:12, bearophile <bearophileHUGS@lycos.com
>>>         <mailto:bearophileHUGS@lycos.**com <bearophileHUGS@lycos.com>>>
>>> wrote:
>>>
>>>             Manu:
>>>
>>>
>>>               Frankly, this is a textbook example of why STL is the
>>>             spawn of satan. For
>>>
>>>                 some reason people are TAUGHT that it's reasonable to
>>>                 write code like
>>>                 this.
>>>
>>>
>>>             There are many kinds of D code, not everything is a high
>>>             performance
>>>             ray-tracer or 3D game. So I'm sure there are many many
>>>             situations where
>>>             using the C++ STL is more than enough. As most tools, you
>>>             need to know
>>>             where and when to use them. So it's not a Satan-spawn :-)
>>>
>>>
>>>         So why are we having this conversation at all then if faster
>>>         isn't better in this instance?
>>>
>>>
>>>     Faster is better in this instance.
>>>     What's wrong is your thinking that the STL as the spawn of Satan in
>>>     general.
>>>
>>>
>>> Ah, but that's because it is ;)
>>> Rule of thumb: never use STL in tight loops. problem solved (well,
>>> mostly)...
>>>
>>
>> I have to agree here. Whenever you have a codebase that has to work on 9 platforms and 6 compilers the S in STL vanishes. Also the implementations are so varying in quality that you might get really good performance on one platform but really bad on another. It seems like everyone in the games industry avoids STL like the plague.
>>
>> Kind Regards
>> Benjamin Thaut
>>
>
> I used to have that experience even with C, when I started using it around 1994. C++ was even worse between CFront, ARM and ongoing standardization work.
>
> As for STL, I can assure that HPC guys are huge fans of STL and Boost.
>

The funny thing about HPC guys though, at least in my experience (a bunch
of researchers from Cambridge who I often give _basic_ optimisation tips),
is they don't write/run 'high performance software', they're actually
pretty terrible programmers and have a tendency to write really low
performing software, but run it on super high performance computers, and
then call the experience high performance computing...
It bends my mind to see them demand an order of magnitude more computing
power to run an algorithm that's hamstrung by poor choices of containers or
algorithms that probably cost them an order of magnitude in performance ;)
And then the Universities take their demands seriously and deliver them
more hardware! O_O

At least when I did my traineeship at CERN (2003-2004) that was the case.
>

I hope CERN has better software engineers than Cambridge University ;) Most of these guys are mathematicians and physicists first, and programmers second.


June 02, 2013
On Saturday, 1 June 2013 at 21:14:43 UTC, Marco Leise wrote:
> Does it really change anything? Today people forget the
> final keyword and tomorrow they forget the virtual
> keyword? :D
>
> What you prefer here depends on what languages you are used to
> do (e.g. C++, Java), how much you use OOP for anything, your
> use of unittesting and mock objects, your need for speed etc.
>

I actually use that quite a lot. Additionally compiler technology exists now to finalize methods that aren't overriden. It is also possible to generate code that replace the virtual dispatch by an simple if if only 2 overrides exists, or even provide a fast path for the most common override, only conditionally doing the virtual dispatch.

In other terms, as long as the compiler know about all the overrides, it can do better than the programmer manually annotating final/virtual.