In article <3fdcfad6@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> If exceptions are slower than normal return, that won't hurt much
> because they are meant to be used as "exceptions". So, for exceptions
> my critisism was the size overhead.
>
> And for RTTI: I cannot imagine that a dynamic_cast has real little
> overhead but I honestly hope that it is the case until I run a test
> in the next days.

Effectively you only need it when using multiple inheritance.  Of course, if
you depend on dynamic_cast heavily, you probably have some serious problem
understanding C++.

> Okay, my observations quoted above were based on my experiences on the
> gcc-2.7.3.2 -> gcc-2.8 transition and may very well be outdated.

One of the slowest known compilers around ... and outdated by half a decade.

> So, RTTI and exceptions still introduce considerable overhead even if
> not used.

Shitty compiler => shitty code!  You should really use professional
compilers to base your comparisons on.  Gcc's main feature is portability,
not performance.

    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

Wolfgang Wieser <wwi### [at] gmxde> wrote:
> They _are_ less efficient. (Because even temporaries trigger allocatation 
> on the heap instead of the fast stack and because the con/destructors 
> are called all the time increasing and decreasing reference counters, 
> etc.) 

  How do using pointers directly alleviate the problem of temporaries
triggering allocation on the heap? I don't understand.

  And constructors and destructors are called when instances are copied.
The most common place to copy an instance is when a function takes such
data container by value.
  Usually you don't make functions which take big data containers by value,
but by reference, so no constructors/destructors are called.

> But _not_ for real simple types. For "I quickly need a vector", using 
> double v[3] is still faster than anything using operator new or 
> applying a fancy con/destructor.

  But that's a *static* data type, not a dynamic one. Why would you
want to use a dynamic data container for a table of static size? That's
like shooting flies with a cannon.

-- 
#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

Wolfgang Wieser <wwi### [at] gmxde> wrote:
> So, if you need a local variable of just such a type we're talking about, 
> i.e. a class which simply contains a pointer to an internal class, 
> then the class will be allocated on the stack (okay, fast) and the 
> internal class will be allocated using operator new on the heap. 

  I still not understand that if you want a container of static size
why would be use a dynamic container for that.
  Make a container with static size which does not allocate memory and
there you are.

> All that happens when you call the constructor and initialize your 
> class. For the normal use, this is just what you want because when 
> you pass the class to a function, it is quite fast (just increase 
> reference counter). But if the object is simply a local var you want 
> on the stack, then the overhead is considerably. 

  If the default constructor does nothing, then make it inline with an
empty implementation. The compiler will optimize the constructor call
away. Same goes for the destructor.

> Correct. But if your class behaves that way because you're doing reference 
> counting (see above), then there is little you can do against that. 

  Even if you used a dynamic data container, why would reference counting
kick in (unless you are making functions which take big data containers
by value, which is seldom a good idea)?

-- 
#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

Thorsten Froehlich <tho### [at] trfde> wrote:
> You clearly haven't done a lot of GUI programming. 

  That's true.

> If you acquire resources
> from the operating system, it is usually a good idea to keep them in a
> specialised container able to release the resource should i.e. an exception
> occur.  Likewise when it comes to passing data to the operating system.
> Frequently this does require a more low-level work on manually allocated
> memory with new, and then auto_ptr can be really helpful! *

  I would try to abstract whatever resources you are allocating from the OS
behind a class. Everything that is related to that resource would be handled
by that class and the public interface would be very abstract. You simply
tell the object "allocate the resources this way" and the object will
handle the system call, storing the pointer or whatever to the allocated
resource and freeing it when appropriate.
  This is more than a "smart pointer". It's a kind of "smart resource
allocator".

  Using a smart pointer sounds more like making system-dependant calls
in wrong places. Like taking system-dependant code higher than necessary
in the abstraction level. The pointer doesn't know what's behind the
pointer, that's left to higher levels to decide. Personally I don't
like that.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> if
> you depend on dynamic_cast heavily, you probably have some serious problem
> understanding C++.

  Actually it's a symptom of bad OO design (unless you are using
dynamic_cast for something else than downcasting...).

  The only cast which is "legit" is static_cast.
  dynamic_cast is, how would I call it, "half-legit". It's safe and OO-like,
but if you need to use it, there's usually something wrong with your whole
design (not always, though, but usually).

  The other two casts are very "illegit". They are very unsafe and only
needed for hacking things. (They still can be sometimes useful, though,
even though it's usually "dirty" code :P )

-- 
#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 <3fdd2009@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Using a smart pointer sounds more like making system-dependant calls
> in wrong places.

Well, if you only target one operating system for one reason or another, you
are usually not concerned about portability at all.  Or, like a task I am
currently dealing with, you don't get pointers back but ids that you even
want to reference in multiple places (OpenGL display lists).  Yet they
belong only to one particular object of a class (the OpenGL context that was
active when they were created).  So, when giving an object encapsulating a
display list to the user (of the OpenGL context object), you have to make
sure when you get them back that they belong to your object at all.

On the other hand, in many cases (like when using OpenGL) you need a rather
low-level interface at a fairly high application level.  The alternative
would be a total abstraction in many cases (i.e. if you want to support
another API like Direct3D), which ends up being a lot of very careful coding
to even only deal with a tiny subset of functionality.

>   I would try to abstract whatever resources you are allocating from the OS
> behind a class.

When dealing with an operating system C interface, sometimes there has to be
a compromise between good abstraction and feasibility.  For example,
supplying Get and Set methods for every possible OpenGL flag and state
variable would quickly result in several thousand member function template
based Get/Set methods - the OpenGL 1.5 API contains over 450 functions
offering access to about 1500 different flags and states!  Not even to
mention the optional feature extensions in OpenGL.  So, unless somebody
wants to implement this and update it for every new OpenGL version, you end
up using less abstraction.  While not in this particular case (you need ids
as outlined above), in many other cases a smart pointer is a really good
alternative to going all the way to a full abstraction layer.  In particular
if you only need certain system functions once.

    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

Thorsten Froehlich <tho### [at] trfde> wrote:
> if you only target one operating system for one reason or another

  In my opinion it's not good to think "I will be making this huge program
for (the current version of) Windows and that's it; I will never want to
port it to any other system and I will trust that newer Windows versions
will support this system call as it is now".
  The day you, for some reason or another, want to port it to another system
(or when a new windows version breaks that system call), you will curse
your decision, specially if you have ten thousands calls scattered all
over the place... ;)

  (Ok, that is a bit extreme, but I still like to encapsulate system-dependent
things as far as it is feasible and makes the code cleaner.)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

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

>   In my opinion it's not good to think "I will be making this huge program
> for (the current version of) Windows and that's it; I will never want to
> port it to any other system

Especially on Windos, but almost equally so on all others systems, there are
so many specific things, trying to abstract them is a true waste of time
unless a *very* small subset of all available functionality is used.  In
short, it is much better to do one thing well than three or four things
badly.

    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

"Mael" <mae### [at] hotmailcom> wrote:

>> I'll try again later on a more recent system
>
>This time I tried on windows (VC++ 6) and same (wrong) results for
>chess2.pov (you can render it without focal blur for faster test)
>I hope this is something easy to track down .. good luck :-/

I'll fix this and include the bbox tree.
This may take some days as i must change from my Notebook to a new PC.

Andreas

Post a reply to this message

>   The sad thing is that sometimes the "C-way" will be slower and less
> efficient than the "C++-way". For instance, compare C and C++ strings.
> (Most operations are much faster in C++, not to talk about C++ strings
> being a lot more secure with regard to memory leaking. C++ strings are
> also a lot easier to use.)

	But in what language the C++ streams are implemented internally ?
Isn't it mostly in C and asm ?  The C libraries usually are too.

	I'm interested in this particular point since my own projects
rely _a lot_ on labelled data (using my own C string "library").  Could you
give an example where C++ strings clearly outperform the equivalent C code
(if anything similar can be done) ?

>   (It's really sad that C++ streams are still slower than C streams in
> most compilers. When will they make an implementation which is at least
> as fast?)

	Ah ! Since I usually write GB of data, it seems that I still have
a good reason to "kiss" C a bit longer  ;-)

	- NC

Post a reply to this message

In article <3fdf63e3@news.povray.org> , Nicolas Calimet <pov### [at] freefr>
wrote:

>>   The sad thing is that sometimes the "C-way" will be slower and less
>> efficient than the "C++-way". For instance, compare C and C++ strings.
>> (Most operations are much faster in C++, not to talk about C++ strings
>> being a lot more secure with regard to memory leaking. C++ strings are
>> also a lot easier to use.)
>
>  But in what language the C++ streams are implemented internally ?
> Isn't it mostly in C and asm ?  The C libraries usually are too.

The C++ streams tend to be slow due to practically all libraries
implementing them in the simplest, not fastest manner.  Practically they
just put a layer on top of C streams, wrap it yet again, then they pull in
more locale and half of the rest of STL and easily you get a huge program if
you just use something as trivial as even a simple cout <sigh>

Guides have been written how to make C++ streams fast, but I don't think any
big STL or compiler vendor has implemented all of them yet.

>  I'm interested in this particular point since my own projects
> rely _a lot_ on labelled data (using my own C string "library").  Could you
> give an example where C++ strings clearly outperform the equivalent C code
> (if anything similar can be done) ?

The STL string, if implemented well, is extremely fast, especially if you
deal with dynamic string length and need to copy strings around.  In fact,
the strings are usually one of the best optimised things in current STL
library implementations...

>>   (It's really sad that C++ streams are still slower than C streams in
>> most compilers. When will they make an implementation which is at least
>> as fast?)
>
>  Ah ! Since I usually write GB of data, it seems that I still have
> a good reason to "kiss" C a bit longer  ;-)

It really depends.  Taker a look at povdocgen (in Perforce).  You will
notice that is reads and writes data very quickly, and it uses only STL
strings.  It really is only so "slow" processing everything because of the
massive applying of regular expressions.  The most important thing is that
STL strings make use of strings almost trivial just like it is in most
higher level languages (i.e. modern Basic variants).

    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

>> But in what language the C++ streams are implemented internally ?
>>Isn't it mostly in C and asm ?  The C libraries usually are too.
>
> The C++ streams

	Ooops, sorry, here I was refering to STRINGS, not streams...

> The STL string, if implemented well, is extremely fast, especially if you
> deal with dynamic string length and need to copy strings around.  In fact,
> the strings are usually one of the best optimised things in current STL
> library implementations...

	Indeed those dynamic strings are what I'm interested in.  So I should
have a look at the STL then...  Still don't see how they could be faster than
some equivalent functionality in a good implementation of the C library on the
same architecture.  Maybe thanks to faster, dedicated memory management ?

	- NC

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
>         But in what language the C++ streams are implemented internally ?
> Isn't it mostly in C and asm ?  The C libraries usually are too.

>         I'm interested in this particular point since my own projects
> rely _a lot_ on labelled data (using my own C string "library").  Could you
> give an example where C++ strings clearly outperform the equivalent C code
> (if anything similar can be done) ?

  I think you are confusing "string" and "stream" above. They are two
quite different things... :)

  I was talking about std::string.
  Almost *any* operation on a std::string is faster than an equivalent
operation on a C string. The simplest example is getting the size
of the string.
  std::string::size() is a constant-time operation (it simply returns
the value of a variable), while strlen() goes through the entire string
to get its size. Now, imagine that the string is 100 million characters
long...

>         Ah ! Since I usually write GB of data, it seems that I still have
> a good reason to "kiss" C a bit longer  ;-)

  If you do it right, you can change from one to the other by changing
just a few lines of code (no matter how many millions of lines long is
your whole program). That's what modularity is about.
  (If you do it wrong and you want to change it, you'll have to go
through the millions of lines and change every place where it's
used... Remember y2k?-) )

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

>   I think you are confusing "string" and "stream" above. They are two
> quite different things... :)

	Yes, it was a mistake: writing "stream" for "string" (see my answer
to Thorsten that I posted 3 minutes before your message  :-p )

>   I was talking about std::string.
>   Almost *any* operation on a std::string is faster than an equivalent
> operation on a C string. The simplest example is getting the size
> of the string.
>   std::string::size() is a constant-time operation (it simply returns
> the value of a variable)

	This example is very trivial, and you can easily implement the same
in your own string library in C.  What I'd like to see is the performance of
creating a dynamical formatted string, similarly to vsprintf() -- but of course
without the static buffer passed as argument, which makes vsnprintf unecessary.

>   (If you do it wrong and you want to change it, you'll have to go
> through the millions of lines and change every place where it's
> used... Remember y2k?-) )

	'sed'  ;-)

	- NC

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
>         This example is very trivial, and you can easily implement the same
> in your own string library in C.

  The advantage of the C++-way is that a std::string is more secure
(forget about memory leaks) and its syntax is simpler.

>  What I'd like to see is the performance of
> creating a dynamical formatted string, similarly to vsprintf() -- but of course
> without the static buffer passed as argument, which makes vsnprintf unecessary.

  std::stringstream is for that.

  std::stringstream works like a std::ostream (and like a std::istream)
but instead of outputting to a file it stores things given to it onto
memory as a string. You can then get that string from it.

  Since std::stringstream is inherited from std::basic_iostream, you
can use it anywhere a std::istream or a std::ostream is expected.

-- 
#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 <3fdf9da3$1@news.povray.org> , Nicolas Calimet 
<pov### [at] freefr>  wrote:

>  This example is very trivial, and you can easily implement the same
> in your own string library in C.  What I'd like to see is the performance of
> creating a dynamical formatted string, similarly to vsprintf() -- but of
course
> without the static buffer passed as argument, which makes vsnprintf
unecessary.

If you really want to use printf-style formatting in C++ (I sure do so
often), take a look at <http://www.boost.org/libs/format/index.htm>.  While
I never used it (I have my own mini-utility function for that), it does
sound like a simple solution.

    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

Thorsten Froehlich wrote:
>> For inline functions this is true. Not so for extern linkage.
> 
> You cannot have external linkage for template functions.
> 
You can. You just have to make sure that a specialisation for the 
used type is linked in extenally. 

>> The result is lots of inline code which results in larger executables
>> and eventually even in slower code.
> 
> Only if you use containers of many different types!  Modern linkers will
> eliminate multiple identical template function instances, thus you only
> see the code bloat in the object files, but not in the final linked
> program.
> 
Correct. But all as you normally need to have all template stuff 
inline, this results in a lot of inline code duplication. 

>>>> But _not_ for real simple types. For "I quickly need a vector", using
>>>> double v[3] is still faster than anything using operator new or
>>>> applying a fancy con/destructor.
>>>
>>> Sorry, but if you need a local variable, who said you should use new???
>>>
>> So, if you need a local variable of just such a type we're talking about,
>> i.e. a class which simply contains a pointer to an internal class,
>> then the class will be allocated on the stack (okay, fast) and the
>> internal class will be allocated using operator new on the heap.
> 
> But only if there is data.  If properly designed, if there is no data, no
> memory should be allocated.  Unless you use fixed-size data in C, you will
> have exactly the same amount of work.  And there is nothing that keeps you
> from using fixed-size data in C++, except that it is bad style, in both
> languages.
> 
I have the feeling that we're not getting the point of what we want 
to tell each other... 

>> All that happens when you call the constructor and initialize your
>> class. For the normal use, this is just what you want because when
>> you pass the class to a function, it is quite fast (just increase
>> reference counter). But if the object is simply a local var you want
>> on the stack, then the overhead is considerably.
> 
> Why would you reference count the internal data of most classes?  You seem
> to be thinking about some special case, but even then, how would a
> reference counting C++ implementation be slower than a similar C
> implementation?
> 
Because the C construction does no reference counting. You allocate 
a pointer once and then use it. And the designer knows where it was 
allocated, "who" is responsible for the pointer and its lifetime. 

Yes, that's insecure like hell but faster and smaller. 
And for good designs, it even :) works...

> Well, you should really not be doing reference counting inside a class in
> the first place.  If you share data among several objects of the same
> class,
> most of the time you have a serious design problem.  And again, the
> reference counting would not work differently in C, so there is again no
> difference in overhead!
> 
I need to make an example. 

A fairly normal implementation of the class which just holds a 
pointer to an internal class. As the internal class may be shared 
among several instances, we use reference counting. 

class MyObject
{
        _MyInternalObject *o;
        MyObject(const MyObject &m) : o(m.o)
        {  if(o) o->add_reference();  }
        MyObject(params_for_obj)
        {  o=new _MyInternalObject(params_for_obj);  o->add_reference();  }
        ~MyObject()
        {  if(o) o->sub_reference();  }
};

This is fairly straight forward and how things like std::string, etc, 
work. 

Overhead at function call (call by value): just copying the pointer 
and adding a reference (i.e. ++ref_cnt;)
[Much better than call-by-value of the complete internal class but 
worse than simply passing a pointer/reference]

So, now say you need a temporary of that class: 

foo()
{
        MyObject obj(pbject_params);
        obj.do_sth();  return(obj.sth_else());
}

That will (1) allocate some bytes on the stack (fast) and then 
(2) allocate internal object using operator new (slow). 

That is what I had in mind. 

I still am the opinion that it is pretty hard if not (nearly?) impossible 
to design really fast C++ code (i.e. as fast as insecure C code) when one 
forces itself to stick to all the "good style" guidelines. (Depends on 
what one defines as "good style"). 

So, of course gained savety comes at some price. It's just to get it 
as cheap as possible. 

Wolfgang

Post a reply to this message

Thorsten Froehlich wrote:

> In article <3fddcfb2@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:
> Especially on Windos, but almost equally so on all others systems, there
> are so many specific things, trying to abstract them is a true waste of
> time
> unless a *very* small subset of all available functionality is used.  In
> short, it is much better to do one thing well than three or four things
> badly.
> 
Have a look at Qt. 

Wolfgang

Post a reply to this message

Thorsten Froehlich wrote:
>> And for RTTI: I cannot imagine that a dynamic_cast has real little
>> overhead but I honestly hope that it is the case until I run a test
>> in the next days.
> 
> Effectively you only need it when using multiple inheritance.  Of course,
> if you depend on dynamic_cast heavily, you probably have some serious
> problem understanding C++.
> 
I wouldn't say that. It depends on the problem. 
Of course, virtualisation should be preferred where possible. 
Virtual function calls are cheap and fast (the ovherhead compared to 
normal external calls is negliable unless it's a just-return-value 
function in some inner loop). 

>> Okay, my observations quoted above were based on my experiences on the
>> gcc-2.7.3.2 -> gcc-2.8 transition and may very well be outdated.
> 
> One of the slowest known compilers around ... and outdated by half a
> decade.
> 
True. I just did not re-examine my observations from the past, so I am 
doing that now. 

>> So, RTTI and exceptions still introduce considerable overhead even if
>> not used.
> 
> Shitty compiler => shitty code!  You should really use professional
> compilers to base your comparisons on.  Gcc's main feature is portability,
> not performance.
> 
Heeee. gcc is by all means no "shitty compiler". But we may try using 
e.g. the intel compiler (it has -fno-rtti but no -fno-exceptions). 

Do you know how RTTI internally works? (I.e. in an "non-shitty" 
compiler.)

Wolfgang

Post a reply to this message

Thorsten Froehlich wrote:

> In article <3fdce9c8@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
> 
>> First of all, the copy constructor and assignment operators will
>> introduce overhead:
>>
>> tempate<classT>
>>  auto_ptr<T>& auto_ptr<T>::operator=(auto_ptr<T>& rhs)
>>  {
>>    if (this != &rhs)
>>    {
>>      delete pointer;   // <-- if(pointer) { destruct & free }
>>      pointer = rhs.pointer;
>>      rhs.pointer = 0;
>>    }
>>    return *this;
>>  }
> 
> No, what you show introduces no overhead when used.  If you would do the
> same without an auto_ptr you would need to write exactly the same code.
> Consequently, there is no overhead - the code is just created for you
> rather than you having to write it.
> 
Well, there is no normally need to zero the pointer in the 
caller function and do all that fancy stuff. A raw pointer or reference 
will do in most cases. 

And I even can imagine situations where the fact that the pointer value 
in the caller it cleared during the call will lead to NULL ptr deref. 
Having sait that, you'll yell at me about bad design but one finds oneself 
much faster in that situation as one may think -- especially when using 
an auto_ptr as a class member. 

Wolfgang

Post a reply to this message

Warp wrote:

> Wolfgang Wieser <wwi### [at] gmxde> wrote:
>> So, if you need a local variable of just such a type we're talking about,
>> i.e. a class which simply contains a pointer to an internal class,
>> then the class will be allocated on the stack (okay, fast) and the
>> internal class will be allocated using operator new on the heap.
> 
>   I still not understand that if you want a container of static size
> why would be use a dynamic container for that.
>   Make a container with static size which does not allocate memory and
> there you are.
> 
Please have a look at the example code in the other posting nearby. 

Wolfgang

Post a reply to this message

In article <3fe1f73d@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

>>> For inline functions this is true. Not so for extern linkage.
>>
>> You cannot have external linkage for template functions.
>>
> You can. You just have to make sure that a specialisation for the
> used type is linked in extenally.

Well, you still need the whole template source code for the compiler to
work.  So, the code would still be generated locally and the linker may then
indeed decide to throw the local instance of the template functions away and
use the one from the outside, but this will hardly gain you anything but
problems with most compilers.

>> Only if you use containers of many different types!  Modern linkers will
>> eliminate multiple identical template function instances, thus you only
>> see the code bloat in the object files, but not in the final linked
>> program.
>>
> Correct. But all as you normally need to have all template stuff
> inline, this results in a lot of inline code duplication.

No, only the very common bad programming habit of placing template
implementation code inside classes instead outside causes template code to
be inlined (also a compiler is *not* required to inline anything!).

>> But only if there is data.  If properly designed, if there is no data, no
>> memory should be allocated.  Unless you use fixed-size data in C, you will
>> have exactly the same amount of work.  And there is nothing that keeps you
>> from using fixed-size data in C++, except that it is bad style, in both
>> languages.
>>
> I have the feeling that we're not getting the point of what we want
> to tell each other...

Could well be the case.

> Because the C construction does no reference counting. You allocate
> a pointer once and then use it. And the designer knows where it was
> allocated, "who" is responsible for the pointer and its lifetime.
>
> Yes, that's insecure like hell but faster and smaller.

Of course, nothing keeps you from doing this in C++ as well...


> That will (1) allocate some bytes on the stack (fast) and then
> (2) allocate internal object using operator new (slow).
>
> That is what I had in mind.

I almost assumed you did.  However, node that having just a pointer to an
"internal" object is just terrible design, and if you use this to hide
something "private" behind another interface, C++ is not the language you
want to be using!

Second, if you really have a valid need to frequently create temporary
copies of a specific class of objects, you will gain a really lot if you use
a memory pool (i.e. boost::pool for C++).  And of course, you will still
have the same problems when doing something similar in C.

> I still am the opinion that it is pretty hard if not (nearly?) impossible
> to design really fast C++ code (i.e. as fast as insecure C code) when one
> forces itself to stick to all the "good style" guidelines. (Depends on
> what one defines as "good style").

Yet, but you are making two major mistakes in your logic here: Just because
C++ allows you to use more secure programming methods does not imply in any
way that C++ is slow or slower than C.  It simply implies that a
well-programmed piece of code will have a tiny bit of overhead over a fast
hack.  And the languages features for good programming style only exist in
C++ but not C.  Thus you can only use them in C++, while you are stuck with
unstable code in C.

However, this is the case for any higher language level.  You can claim
exactly the same for C and your native assembler.  Of course, if you know
what you are doing you can still outperform even a very good compiler (the
SSE2 noise code in POV-Ray is a good example for this) by using lower level
programming languages, but that doesn't say anything about the higher level
languages!

    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

In article <3fe1f82f@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

>> In article <3fddcfb2@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:
>> Especially on Windos, but almost equally so on all others systems, there
>> are so many specific things, trying to abstract them is a true waste of
>> time
>> unless a *very* small subset of all available functionality is used.  In
>> short, it is much better to do one thing well than three or four things
>> badly.
>
> Have a look at Qt.

Which does an extremely miserable job!  In fact, Qt is just one of the worst
GUI abstraction layers that exist (I am sure that is why it is so popular!).
It does not abstract most of the GUI elements at all, it just draws them on
its own.  Apart from that, Qt is hardly a good example for use of C++.  Its
signal implementation is a perfect example.  As is is non-existent
thread-safety - even if a native API used is fully thread-safe, Qt in
general is not thread-safe.  And its OpenGL widget for Windows is full of
very obvious bugs (also this is only available with the expensive commercial
code license); even M$ sample code shows how to properly create a correct
Z-buffered contexts.

    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

Thorsten Froehlich wrote:

> In article <3fe1f82f@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
> 
>>> In article <3fddcfb2@news.povray.org> , Warp <war### [at] tagpovrayorg> 
>>> wrote: Especially on Windos, but almost equally so on all others
>>> systems, there are so many specific things, trying to abstract them is a
>>> true waste of time
>>> unless a *very* small subset of all available functionality is used.  In
>>> short, it is much better to do one thing well than three or four things
>>> badly.
>>
>> Have a look at Qt.
> 
> Which does an extremely miserable job!  In fact, Qt is just one of the
> worst GUI abstraction layers that exist (I am sure that is why it is so
> popular!). 
>
Your opinion. There are a lot of people who see that the opposite 
way. 

And if you ever did GUI with Java, you will find Qt like heaven...

> It does not abstract most of the GUI elements at all, it just
> draws them on its own. 
>
Correct. So what?

> Apart from that, Qt is hardly a good example for use of C++. 
>
That's 50% true (max). 

> Its signal implementation is a perfect example. 
>
The signal implementation is indeed a strange thingy. 

> As is is non-existent
> thread-safety - even if a native API used is fully thread-safe, Qt in
> general is not thread-safe. 
>
I cannot comment on that. But I recall that early versions of Ot were 
single threaded. And adding thread support to a single threaded design 
often runs into trouble when system near components are involved. 

> And its OpenGL widget for Windows is full of
> very obvious bugs (also this is only available with the expensive
> commercial code license); even M$ sample code shows how to properly create
> a correct Z-buffered contexts.
> 
Hell, don't use Qt for OpenGL. 
Either you want performance or you want Qt. But a factor of 3..5 in 
GUI performance loss is acceptable in the most cases. (And still much 
better than swing...)

Wolfgang

Post a reply to this message

In article <3fe1fac3@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

>>> So, RTTI and exceptions still introduce considerable overhead even if
>>> not used.
>>
>> Shitty compiler => shitty code!  You should really use professional
>> compilers to base your comparisons on.  Gcc's main feature is portability,
>> not performance.
>>
> Heeee. gcc is by all means no "shitty compiler". But we may try using
> e.g. the intel compiler (it has -fno-rtti but no -fno-exceptions).
>
> Do you know how RTTI internally works? (I.e. in an "non-shitty"
> compiler.)

It is very simple (of course there are other ways to do it).  In essence,
all you need is a single static type_info object for every class.  So, you
create one static instance of such an object (ideally you have the linker
fold multiple instances). Every virtual function table gets a pointer to the
type information. For PODs and structs you know the type at compile-time
anyway. So, all you need it one pointer per class to determine its type,
plus 50 or so bytes (depending on what the name string of type_info returns)
per class (not per object!). And of course, the compiler will only need to
generate this data if type information is required for a particular class.

    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

Thorsten Froehlich wrote:

>> Correct. But all as you normally need to have all template stuff
>> inline, this results in a lot of inline code duplication.
> 
> No, only the very common bad programming habit of placing template
> implementation code inside classes instead outside causes template code to
> be inlined (also a compiler is *not* required to inline anything!).
> 
(Yes but good compilers do when told so...)

>> Because the C construction does no reference counting. You allocate
>> a pointer once and then use it. And the designer knows where it was
>> allocated, "who" is responsible for the pointer and its lifetime.
>>
>> Yes, that's insecure like hell but faster and smaller.
> 
> Of course, nothing keeps you from doing this in C++ as well...
> 
We were talking about what is faster... and what safer...

>> That will (1) allocate some bytes on the stack (fast) and then
>> (2) allocate internal object using operator new (slow).
>>
>> That is what I had in mind.
> 
> I almost assumed you did.  However, node that having just a pointer to an
> "internal" object is just terrible design, and if you use this to hide
> something "private" behind another interface, C++ is not the language you
> want to be using!
> 
Ah really?! Have fun reading the STL code :p

> Second, if you really have a valid need to frequently create temporary
> copies of a specific class of objects, you will gain a really lot if you
> use
> a memory pool (i.e. boost::pool for C++). 
>
I tried things like that. Stack allocation is still fastest for 
small amounts of memory. 

> And of course, you will still
> have the same problems when doing something similar in C.
>
One would not use a desing like that in plain C. 
 
>> I still am the opinion that it is pretty hard if not (nearly?) impossible
>> to design really fast C++ code (i.e. as fast as insecure C code) when one
>> forces itself to stick to all the "good style" guidelines. (Depends on
>> what one defines as "good style").
> 
> Yet, but you are making two major mistakes in your logic here: Just
> because C++ allows you to use more secure programming methods does not
> imply in any
> way that C++ is slow or slower than C.  It simply implies that a
> well-programmed piece of code will have a tiny bit of overhead over a fast
> hack. 
>
I was making no mistake in my reasoning. I just wanted to express 
what you stated above in your own words...
No discrepancy there. 

> And the languages features for good programming style only exist in
> C++ but not C.  Thus you can only use them in C++, while you are stuck
> with unstable code in C.
> 
You could implement similar (not-so-safe) things in C. Don't understand 
me wrong: 
I do _not_ propose that, it's just what I extracted from your frequent 
replies stating "you would have the same overhead in C when implementing 
that in C". 

> However, this is the case for any higher language level.  You can claim
> exactly the same for C and your native assembler.  Of course, if you know
> what you are doing you can still outperform even a very good compiler (the
> SSE2 noise code in POV-Ray is a good example for this) by using lower
> level programming languages, but that doesn't say anything about the
> higher level languages!
> 
Correct. Assuming that one could implement the core parts of an 
application in assembler gaining speed increases of factor 2 or above 
it may seem irrelevant to talk about <=5% loss at a C -> C++ transition. 
Especially if there are benifits (better maintainability, etc)

Wolfgang

Post a reply to this message

In article <3fe1fd24@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> Well, there is no normally need to zero the pointer in the
> caller function and do all that fancy stuff. A raw pointer or reference
> will do in most cases.

BTW, given you assigned "0" to a pointer, take a look at
<http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1488.pdf>
It has some important news about "0" and "NULL"...

    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

Thorsten Froehlich wrote:

>> Do you know how RTTI internally works? (I.e. in an "non-shitty"
>> compiler.)
> 
> It is very simple (of course there are other ways to do it).  In essence,
> all you need is a single static type_info object for every class.  So, you
> create one static instance of such an object (ideally you have the linker
> fold multiple instances). Every virtual function table gets a pointer to
> the type information. For PODs and structs you know the type at
> compile-time anyway. So, all you need it one pointer per class to
> determine its type, plus 50 or so bytes (depending on what the name string
> of type_info returns) per class (not per object!). And of course, the
> compiler will only need to generate this data if type information is
> required for a particular class.
> 
Okay, that explains all the strings one sees in the binary when turning 
on RTTI. It is probably responsible for most of the size overhead when 
using RTTI. 

But what do we need the type name string for? (..in a binary!) 
[Apart from an error message.]

What you did not mention is some sort of tree structure. I'm not 
sure about the details, but isn't there the need for a tree traversal 
to decide if the dynamic_cast is valid? (Think of multiple inheritance...)

Wolfgang

Post a reply to this message

In article <3fe20f31@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

>> Which does an extremely miserable job!  In fact, Qt is just one of the
>> worst GUI abstraction layers that exist (I am sure that is why it is so
>> popular!).
>>
> Your opinion. There are a lot of people who see that the opposite
> way.

Many people also like Windows, apparently ;-)

> And if you ever did GUI with Java, you will find Qt like heaven...

I wrote a tiny program in Java once, and it didn't even have a GUI.  Since
that day, programming in Java is something I will do voluntarily experience
again!

>> It does not abstract most of the GUI elements at all, it just
>> draws them on its own.
>>
> Correct. So what?

If the GUI look changes, Qt does not.  So you end up with a really ugly
application full of (for the user) odd redraw errors.  And it many cases the
Qt widgets don't behave exactly as their native counterparts, resulting in a
plain usability nightmare <sigh>

>> As is is non-existent
>> thread-safety - even if a native API used is fully thread-safe, Qt in
>> general is not thread-safe.
>>
> I cannot comment on that. But I recall that early versions of Ot were
> single threaded. And adding thread support to a single threaded design
> often runs into trouble when system near components are involved.

The problem is still there in the 3.x line of Qt.  And one major problem is
the signal implementation.  Another big problem is the self-made drawing
code for GUI elements.

>> And its OpenGL widget for Windows is full of
>> very obvious bugs (also this is only available with the expensive
>> commercial code license); even M$ sample code shows how to properly create
>> a correct Z-buffered contexts.
>>
> Hell, don't use Qt for OpenGL.

Hmm, I think you don't know how the Qt OpenGL widget works: It only allows
you to create OpenGL contexts (and a few other system specific things like
fonts).  The OpenGL drawing and such is all native, you simply make the
native OpenGL calls from inside a Qt OpenGL widget.

    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

In article <3fe2128a@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

>> No, only the very common bad programming habit of placing template
>> implementation code inside classes instead outside causes template code to
>> be inlined (also a compiler is *not* required to inline anything!).
>>
> (Yes but good compilers do when told so...)

No, good compilers will have mechanisms t detect where inlining will be
beneficial that are more intelligent than any user can be 99% of the time.
They will also be able to inline functions not marked explicitly or
implicitly as inline.

    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

In article <3fe2128a@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

>> I almost assumed you did.  However, node that having just a pointer to an
>> "internal" object is just terrible design, and if you use this to hide
>> something "private" behind another interface, C++ is not the language you
>> want to be using!
>>
> Ah really?! Have fun reading the STL code :p

It really depends on which STL you are talking about.  Certainly the M$ STL
implementation is rather ugly.  There are much better ones.

    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

In article <3fe21524@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> Okay, that explains all the strings one sees in the binary when turning
> on RTTI. It is probably responsible for most of the size overhead when
> using RTTI.
>
> But what do we need the type name string for? (..in a binary!)
> [Apart from an error message.]

Nothing, really, except debugging (hand hardly for that).  One problem in
the C++ standard is that the string is completely implementation defined.  A
compiler could even return an empty string and conform to the standard.  Or
return the same string for every class.  Only the type_ info comparison
functions are of any real use.  Another big problem is that the C++ standard
does not guarantee that there only will be one type_info object for one
class.

That said, most compilers supply the class name in the name string.

> What you did not mention is some sort of tree structure. I'm not
> sure about the details, but isn't there the need for a tree traversal
> to decide if the dynamic_cast is valid? (Think of multiple inheritance...)

No, you just search through a list.  That list is (in general, but
necessarily for every case - it may be shorter) as long as the total number
number of classes a class inherited from.  This has to do with the common
vtable structure.  How exactly it is implemented of course all depends on
your compiler runtime library implementation.  You may want to check if
source code is provided for it (many vendors do provide source code).

    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

In fact, the 'inline' keyword is obsolete with regard to inlining.
In most current compilers this keyword has no effect whatshoever on
the behaviour of the compiler: If the compiler can inline a function
and its inlining algorithm tells it that it will be beneficial, it will
inline it, else it won't. And this is completely regardless of whether the
'inline' keyword appears or not.

  The 'inline' keyword has a quite different task, however, which means
that it isn't completely obsolete in C++. It's actually a command for
the linker (and has nothing to do with inlining).

-- 
#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

On Thu, 18 Dec 2003 21:32:49 +0100, Wolfgang Wieser <wwi### [at] gmxde> wrote:
> > It does not abstract most of the GUI elements at all, it just
> > draws them on its own. 
>
> Correct. So what?

So it is not user-friendly for native GUI users (which of course is not
related to C++ internal design discuted here nor to improved intersection
routine). See screenshots of native minimal sample under wxWindows:

OS2:    http://www.wxwindows.org/images/screens/wxos2.jpg
Win9x:  http://www.wxwindows.org/images/screens/minimal_win95sm.gif
Motif:  http://www.wxwindows.org/images/screens/minimal_motifbig.gif
MacOSX: http://www.wxwindows.org/images/screens/minimal_macosx.gif
GTK+:   http://www.wxwindows.org/images/screens/minimal_gtk.gif
WinCE:  http://www.wxwindows.org/images/screens/wxwince_minimal.jpg
http://cvs.wxwindows.org/viewcvs.cgi/wxWindows/samples/minimal/minimal.cpp

and screenshots of more advanced application of wxWindows under MacOSx,
Windows, Linux: http://mahogany.sourceforge.net/screenshots.html

ABX

Post a reply to this message

Thorsten Froehlich wrote:
>> What you did not mention is some sort of tree structure. I'm not
>> sure about the details, but isn't there the need for a tree traversal
>> to decide if the dynamic_cast is valid? (Think of multiple
>> inheritance...)
> 
> No, you just search through a list.  That list is (in general, but
> necessarily for every case - it may be shorter) as long as the total
> number
> number of classes a class inherited from.  This has to do with the common
> vtable structure.  How exactly it is implemented of course all depends on
> your compiler runtime library implementation.  You may want to check if
> source code is provided for it (many vendors do provide source code).
> 
Okay, and do you think that explains how the following code 
works: 

-----------------------------
#include <iostream>

struct A
{
        int a;
        A():a(1){}
        virtual ~A(){}
};

struct B
{
        int b;
        B():b(2){}
        virtual ~B(){}
};

struct C : A,B
{ };

int main()
{
        C c;
        A *a=&c;
        std::cerr << (dynamic_cast<B*>(a))->b << std::endl;
}
-----------------------------

Obviously, you can cast A to B without either one being derived 
from the other one just because they share a common parent. 

I must admit that I did not spend a lot of time on thinking but 
as for now, I cannot imagine any algoritm which can perform the 
above dymanic_cast without doing tree traversal. 

Wolfgang

Post a reply to this message

Thorsten Froehlich wrote:
>>> It does not abstract most of the GUI elements at all, it just
>>> draws them on its own.
>>>
>> Correct. So what?
> 
> If the GUI look changes, Qt does not.  So you end up with a really ugly
> application full of (for the user) odd redraw errors.  And it many cases
> the Qt widgets don't behave exactly as their native counterparts,
> resulting in a plain usability nightmare <sigh>
> 
Okay. As I am only using Qt under Linux, I do not see that problem. 
But regarding MS Windows, you may well be right. 

And well... probably ABX is right: We're off-topic here. 

But as we're talking about GUI, I'd favour complete separation 
of the raytracing core and the GUI for future POVRay versions. 
It should be possible to build a non-GUI POVRay for render farms. 

Wolfgang

Post a reply to this message

In article <3fe21f39@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> > And if you ever did GUI with Java, you will find Qt like heaven...
> 
> I wrote a tiny program in Java once, and it didn't even have a GUI.  Since
> that day, programming in Java is something I will do voluntarily experience
> again!

The language isn't that bad, actually...though it is missing a few 
things that I'd really like to have. The standard frameworks, however...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <3fe42e74@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> But as we're talking about GUI, I'd favour complete separation
> of the raytracing core and the GUI for future POVRay versions.

You will be surprised ... this is already possible with POVMS. Not that it
is easy to use in the 3.5.0 source code...

    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

In article <3fe42517@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> Obviously, you can cast A to B without either one being derived
> from the other one just because they share a common parent.
>
> I must admit that I did not spend a lot of time on thinking but
> as for now, I cannot imagine any algoritm which can perform the
> above dymanic_cast without doing tree traversal.

You may recall one can keep binary trees in an array.  Essentially, if you
take away the need to add and remove elements (as C++ class inheritance is
fixed this requirement is fulfilled), you actually have to fold the whole
"tree" to a list.  The exact rules, while well defined, are a bit
complicated, but what exactly has to happen is specified in the ISO C++
specification...

    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

"Mael" <mae### [at] hotmailcom> wrote:

>> I'll try again later on a more recent system
>
>This time I tried on windows (VC++ 6) and same (wrong) results for
>chess2.pov (you can render it without focal blur for faster test)
>I hope this is something easy to track down .. good luck :-/

I've got it (sorry for the long delay but i was on holiday together
with my children).

I'll post the fixed version of csg.cpp to povray.binaries.programming.

Andreas

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:

>Mael wrote:
>>>Hmm, but this isn't benchmark.pov...
>> 
>> 
>> Does benchmark.pov have lot of intersections csg ? It seems fair to me to
>> test this patch on a scene that uses it (and perhaps even a lot of it to
>> clearly show the effect of the new algorithm)
>
>The benchmark scene uses a reasonable amount of CSG, a comparison with 

I don't think so.
Both of my private builds take about 38min for benchmark.pov (PIV
2.8GHz, 1GB RAM, options are -w384 -h384 +a0.3 +v -d -f -x).

Setting use_photons = use_area_light = show_clouds = show_objects to
false				==> about 114sec both.
Additionally remove the Sockets ==> about  79sec both.
So as a rough estimate the intersection objects only take about 2% of
the total time.

>this scene would show how much gain you can expect in a typical scene.
>You can of course construct a scene where POV-Ray spends 90% of the time 
>with CSG calculations but this would not be very realistic.

Yes and no.
Give me a ratio old version <-> new version and i'll give you a scene
that shows a better ratio :-).
This is a problem with benchmarks or measurements generally, you have
to have a close look at the boundary conditions.
IMHO benchmark.pov can be used to benchmark the hardware it is running
on but i wouldn't use it to profile/compare different versions of
POV-Ray on the same hardware.

Andreas

Post a reply to this message

> Yes and no.
> Give me a ratio old version <-> new version and i'll give you a scene
> that shows a better ratio :-).
> This is a problem with benchmarks or measurements generally, you have
> to have a close look at the boundary conditions.
> IMHO benchmark.pov can be used to benchmark the hardware it is running
> on but i wouldn't use it to profile/compare different versions of
> POV-Ray on the same hardware.
>
> Andreas

I agree. Just because a patch does not appreciably speed up benchmark.pov 
does not mean that the patch isn't worthwhile. Why is benchmark.pov 
arbitrarily declared to be the ideal or typical POV-Ray scene, anyway? 
With so many possibilities of doing things in POV-Ray, is there even such 
a thing as "the typical scene" ?


George


-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Post a reply to this message

George Pantazopoulos wrote:

> I agree. Just because a patch does not appreciably speed up benchmark.pov
> does not mean that the patch isn't worthwhile. Why is benchmark.pov
> arbitrarily declared to be the ideal or typical POV-Ray scene, anyway?
> With so many possibilities of doing things in POV-Ray, is there even such
> a thing as "the typical scene" ?

Benchmark.pov was not "arbitrarily declared" a typical scene. It was carefully
designed to test a wide variety of feature sets present in the program and to
pose as a reasonable challenge to modern computing architectures. There is no
way a single scene is going to create a high level performance test for every
feature the program offers and even if you could it would take forever to
render. Instead we decided to craft a scene with a balanced set of features
that could reasonably be expected to test both the performance of the program
and the computers it is operated on while at the same time maintaining an
acceptable rending time. To date the developers have used it extensively for
fine tuning the performance of the program both internally and at compile
time and if it does nothing else it has performed beyond expectations for
accomplishing that.

-- 
Ken Tyler

Post a reply to this message

I fully agree with Ken.
  benchmark.pov has been designed to mearure the rendering speed of typical
scenes in average.

  However, I agree with George as well: If a feature does not slow down
benchmark.pov but considerably speeds up some feature which is rather
often used, in my opinion it's worth adding.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <4006229C.572F22AE@pacbell.net> , Ken <tyl### [at] pacbellnet>  
wrote:

> Benchmark.pov was not "arbitrarily declared" a typical scene. It was carefully
> designed to test a wide variety of feature sets present in the program and to
> pose as a reasonable challenge to modern computing architectures. There is no
> way a single scene is going to create a high level performance test for every
> feature the program offers and even if you could it would take forever to
> render. Instead we decided to craft a scene with a balanced set of features
> that could reasonably be expected to test both the performance of the program
> and the computers it is operated on while at the same time maintaining an
> acceptable rending time. To date the developers have used it extensively for
> fine tuning the performance of the program both internally and at compile
> time and if it does nothing else it has performed beyond expectations for
> accomplishing that.

While all you say is correct and remains valid, it has to be admitted that
benchmark.pov has one little bias as it does give a rather heavy weight to
the noise function due to the clouds.  Another thing is that while it is a
realistic benchmark for comparing POV-Ray performance of roughly similar
systems (same architecture) when using them to do "real" work with POV-Ray,
it is not suitable to compare the performance of any particular
processor/system with a specific other one to determine which one is
"faster".

The reason is that such a comparison is not optimal with the default
benchmark.pov is that automatic bounding is turned on, which makes the major
task while rendering searching the bounding volumes.  This to a major part
depends on memory access.  It is really a lot of searching, but not so much
computing at all...

    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

Andreas Kaiser wrote:
>>
>>The benchmark scene uses a reasonable amount of CSG, a comparison with 
> 
> 
> I don't think so.
> Both of my private builds take about 38min for benchmark.pov (PIV
> 2.8GHz, 1GB RAM, options are -w384 -h384 +a0.3 +v -d -f -x).
> 
> Setting use_photons = use_area_light = show_clouds = show_objects to
> false				==> about 114sec both.
> Additionally remove the Sockets ==> about  79sec both.
> So as a rough estimate the intersection objects only take about 2% of
> the total time.

Which is exactly the case for an average 'real' scene (real meaning not 
a technical test scene but a true final scene for a real image).  I 
guess if you do a statistical analysis of some of the better POV-Ray 
generated IRTC submissions you will find this confirmed.  This is not 
the case for scenes that make heavy use of isosurfaces and other objects 
with expensive intersection tests.

I agree with Warp though that a weak performance in rendering 
benchmark.pov is not at all a reason not to integrate this improvement. 
  The patch you posted in p.b.p. will make it quite difficult though 
since you did not clearly mark your changes.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Thorsten Froehlich wrote:
> 
> While all you say is correct and remains valid, it has to be admitted that
> benchmark.pov has one little bias as it does give a rather heavy weight to
> the noise function due to the clouds.

Heavy use of the noise function is quite common for a typical POV-Ray 
scene, even without media, due to procedural textures and geometry.  In 
a typical isosurface landscape scene it is even more excessive than in 
benchmark.pov.

> The reason is that such a comparison is not optimal with the default
> benchmark.pov is that automatic bounding is turned on, which makes the major
> task while rendering searching the bounding volumes.  This to a major part
> depends on memory access.  It is really a lot of searching, but not so much
> computing at all...

Surely the use for comparing processors is limited by this but for 
comparing the performance of whole computers concerning POV-Ray use this 
is exactly what's needed - a typical POV-Ray render will spend much time 
with memory access (in addition to bounding slabs just think of large 
meshes, photon maps, radiosity, image maps).

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

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

>   However, I agree with George as well: If a feature does not slow down
> benchmark.pov but considerably speeds up some feature which is rather
> often used, in my opinion it's worth adding.

I agree as well. The benefit will be moderate for most scenes, but many 
scenes will render considerably faster. I'd say this is definitely a 
worthwhile optimization.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:

>[...]
>
>I agree with Warp though that a weak performance in rendering 
>benchmark.pov is not at all a reason not to integrate this improvement. 
>  The patch you posted in p.b.p. will make it quite difficult though 
>since you did not clearly mark your changes.

What's the preferred way to submit/mark changes?

For the posted csg.cpp:

function All_CSG_Union_Intersections, 
	lines 148 - 167, 183 - 185

function All_CSG_Intersection_Intersections completely,

function All_CSG_Merge_Intersections,
	lines 436 - 438

BTW evaluation of 'tstPoint' at lines 277 and 278 is loop invariant
and should be moved just before the for-loop.

Andreas

Post a reply to this message

On Fri, 16 Jan 2004 13:58:38 GMT, kai### [at] siemenscom (Andreas Kaiser)
wrote:
> What's the preferred way to submit/mark changes?

http://megapov.inetart.net/manual/internals.html#markup

ABX

Post a reply to this message