[Top][All Lists]
[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gzz] Benchmark experiments: what to do and what not,
Tuomas Lukka <=