Performance Prediction
Linas Vepstas (linas@innerdoor.austin.ibm.com)
Thu, 8 Sep 1994 22:19:06 -0500
> From: ellson@hotsand.att.com (John Ellson)
> To: linas@innerdoor.austin.ibm.com, mddoyle@netcom.com, unitcirc@netcom.com
> Cc: www-vrml@wired.com
> Date: Thu, 8 Sep 94 20:43:35 EDT
> Subject: Re: Scripts vs APIs
>
> > The nervousness, possibly unfounded, is this:
> >
> > 1) Performance.
> > a) Algorithmic scene descriptions can take unbounded,
> > non-polynomial amounts of CPU time digest.
> > b) I don't feel like writing a compiler to digest the language,
> > but history shows that for a proceedural language, I
> > eventually will.
> > c) I'm worried about downloading the VRML script that
> > turns out to be a program that computes the first million
> > digits of pi. I guess poeple could do this in postscript,
> > but they don't ...
> >
> > 2) Unpredicatability -- I can't predict what a program does
> > until I run it. That includes how much memory it'll use.
> > That means that graceful recovery from overflows & run-time
> > errors become hard.
>
> Perhaps VRML should address this issue directly, and perhaps
> independently of language style? I wonder if VRML should
> borrow the idea of a computation quantity like "Teleclicks" from
> Telescript? (ref: "Agents Away," Peter Wayner, Byte, May 1994, pp 113-118)
>
> The VRML file could be required to contain an estimate
> of the computational requirements of the structure in some normalized
> measurement unit. This doesn't have to be a burden on the human, it
> can be measured by the author's VRML editor or viewer and simply
> appended to the file.
>
> You could also have separate estimates for each component in a
> composite scene and possibly alternate representations of each
> component each with different estimates. Using this information a
> browser could use a rendering technique that is within its display time
> budget and which is appropriate for the size of each component from
> the current viewpoint.
Yes !! Precisely !!!
I beleive that it should be fairly straightforward to count the
number of each kind of object in a VRML page while parsing the page
-- number of flat-shaded polygons, number of gouraud-shaded polygons,
number of spheres, number of head-to-tail lines, whatever.
Now, previously, you will have built up a performance profile
of your local machine -- how many flat shaded polygons-per-second
it can draw, how many ... etc. .. per second, etc.
You take the dot-product of these two, and you have a pretty good
estimate for how long it will take you to draw the scene. Real-life
experience indicates that you can get within about 10 percent of
actual drawing time. In fact, the OpenGL Performance Characterization
Committee is using a scheme much like this. The counts are called
"buckets".
The laundry-list of geometric things that are counted is some 200
or 300 long, mostly varieties of polygons, lines, triangles, dots,
with no lights, with one light, with 2 lights, flat shaded vs.
gouraud shaded, color-per-vertex, or color-per-object, texture on
or off, etc. etc. I looked at the list, and I don't think it's
useful for VRML in the form that its in; but once the primitives
in VRML are spec'ed out, then one can figure out what the list
should be.
> John Ellson
> AT&T Bell Labs
--linas