gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gzz] Benchmark experiments: what to do and what not


From: Tuomas Lukka
Subject: [Gzz] Benchmark experiments: what to do and what not
Date: Mon, 17 Mar 2003 21:37:19 +0200
User-agent: Mutt/1.4i

Ok, some things to point out to Matti and others about
how to design benchmark experiments to find out bottlenecks,
focused on OpenGL rendering.

1) Create a *SINGLE VOBSCENE* that shows the problem

2) Render it thousands of times and measure the time, in timeRender().

This is the only way to get really meaningful results.
The reasons are:

        - There's a LOT of noise in computers, due to other processes,
          other threads, cache, ...
                
                -> need to repeat a lot of times to average out
        
        - We don't want to measure vobscene generation + rendering
          Measuring some composite like that is ridiculous.
          You must find out *SEPARATELY* the time to generate it
          and the time to render it. NEVER measure both and assume
          that delays occur in one of them.

                -> generate the vobscene and then time the thousands
                   of renders

                -> measure the time to generate 1000 times the vobscene
                   (without any rendering)
        
        - We want a meaningful measure

                -> don't measure an animation from one place to another

                   The scene changes inbetween and this means that the
                   noise mentioned above will play a greater role.

                   Also, any change to the rendering code will change
                   the actual frames rendered and invalidate comparisons
                   to the earlier times.

                   Define *ONE* *SINGLE* *SCENE* that is slower to
                   either generate or render than it should be.
                
After this, vary parameters in the one scene and little by little,
isolate what the bottleneck in it is.

Then, make a simple benchmark that has just the bottleneck in one
scene. Again, using timeRender().

Once we have this, we can really start working on speeding up the
code. Anything less and we'll be shooting around blindly.

        Tuomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]