Slow performance compared to C++, ideas?

Paulo Pinto pjmlp at progtools.org
Sun Jun 2 05:29:19 PDT 2013


Am 02.06.2013 13:08, schrieb John Colvin:
> On Sunday, 2 June 2013 at 07:32:10 UTC, Manu wrote:
>> On 2 June 2013 01:19, Paulo Pinto <pjmlp at 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 at lycos.com
>>>>> <mailto:bearophileHUGS at lycos.**com <bearophileHUGS at lycos.com>>> wrote:
>>>>>
>>>>>     Manu:
>>>>>
>>>>>         On 1 June 2013 01:12, bearophile <bearophileHUGS at lycos.com
>>>>>         <mailto:bearophileHUGS at lycos.**com
>>>>> <bearophileHUGS at 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.
>
> In my experience, physicists are terrible programmers. I should know, I
> am one! As soon as you step outside the realm of simple, < 10kloc, pure
> procedural code, the supposed "HPC"
> guys don't generally have the first clue how to write something fast.
>
> CERN is responsible for the abomination that is ROOT, but to be fair to
> them there is a lot of good code from there too.

There was an office there that had the sentence "You can program Fortran 
in any language" on the door. :)

--
Paulo


More information about the Digitalmars-d mailing list