Slow performance compared to C++, ideas?

John Colvin john.loughran.colvin at gmail.com
Sun Jun 2 04:08:21 PDT 2013


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.


More information about the Digitalmars-d mailing list