Well, this is not directly about the current POV-Ray, but as some may know,
POV-Ray 4.0 will be a rewrite in C++.  And I am also sure some people may
have read claims elsewhere that C++ is slower or have other misconceptions
about C++ speed (no matter which compiler is used). So this is kind of
on-topic :-)

I found an interesting (draft) paper that provides a fairly detailed
analysis of the C++ standard library performance regrading speed, code size
and many other aspects.  This is of course a very dry topic, but to write
any program with general performance and of course most importnat speed
requirements, in particular POV-Ray, it is really informative.  What is most
important is that this paper is under review of the real C++ experts of the
C++ Standards Committee, and thus little of the information contained
therein (once the paper is final) will be questionable, I think.

Paper:
<http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1355.pdf>
C++ Standards Committee, aka JTC1/SC22/WG21 - C++
<http://anubis.dkuug.dk/jtc1/sc22/wg21/>


    Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> I found an interesting (draft) paper that provides a fairly detailed
> analysis of the C++ standard library performance regrading speed

  We should distinguish between C++ performance and C++ standard library
performance.
  This is an important difference. Saying that "C++ is slow" when in reality
it is the standard library which is slow is very misleading.
  If the libraries are slow, you can change to another library without
having to change the language.

  The C++ streams is one example of this. For some reason the C++ streams
are considerably slower than the equivalent C streams in practically all
existing C++ compilers (even though there are no technical nor theoretical
reasons for this).
  If your program uses a lot of file-I/O, switching from C++ streams to
C streams can seriously improve the performance of the program (even though
you lose the abstraction of the C++ streams; however, wrapping the C streams
usage inside proper abstraction is always a good idea).
  This was done in POV-Ray because it makes heavy use of file-I/O during
parsing, and using C++ streams made it really slow.

  (Please note that the C++ streams are not bad per se, as I said above.
There is no theoretical or technical reason for them to be slower; they just
are, for one reason or another. In fact, theoretically C++ streams could be
faster than C streams due to the fact that more things can be done at
compilation time instead of having to do them at runtime (eg. printf vs. cout))

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <3cb1d1b5@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>> I found an interesting (draft) paper that provides a fairly detailed
>> analysis of the C++ standard library performance regrading speed
>
>   We should distinguish between C++ performance and C++ standard library
> performance.

Yes, and after posting I noticed I wasn't too precise about this :-)

The paper discusses both topics in context and it also discusses what I would
call "implicit C++ standard library" like the functions behind dynamic_casts,
exception handling and rtti, which are after all the most speed determining
parts of a C++ compiler because they are by far called most often.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message