W. F. Pokorny recently commented that floor () was "expensive"

I wanted to get some idea of HOW expensive any given function was, in the grand
scheme of things.

My code is real crap, since I had multiple functions, taking different numbers
of arguments, and being evaluated over different ranges, so I just whanged it
together in order to get SOME kind of result in a reasonable amount of time.
I'm sure this sort of thing could be massively improved, and I'd learn a lot
about both the functions and how to write code for such a project MUCH more
efficiently.

It's clear to me that some functions take monger to evaluate depending upon what
input you feed them.  Tanh() goes from "comparable to most other functions" to
over 100,000 times the cost of everything else.

I'm also interested in redoing sqrt, mod, pow, and iterative multiplication.  I
also completely neglected division.

Anyway, here are all the functions that I tested, with tanh() scaled WAY down so
that the relative costs of all the other functions is a bit clearer.

Each function is evaluated 100,000 times.

Post a reply to this message

Attachments:
Download 'functiontimer.png' (121 KB)

Preview of image 'functiontimer.png'

On 1/29/23 18:50, Bald Eagle wrote:
> W. F. Pokorny recently commented that floor () was "expensive"
> 
> I wanted to get some idea of HOW expensive any given function was, in the grand
> scheme of things.

Interesting. Measuring the cost of functions in POV-Ray can be tricky. 
For starters, usage falls roughly into three buckets. Namely:

1) Pure SDL calls to SDL internally wrapped C++ functions.
2) Calls from SDL of the VM implemented forms of functions.
3) Calls to VM functions from parse time 'compiled' code.

One happens while parsing; Two usually while parsing, but sometimes 
while rendering; Three usually while rendering, but this can be a 'parse 
phase' thing too.

At the bottom, for standard math functions, one usually calls the C++ 
implementation inside the VM too. There is always a C++ pow() 
invocation, for example, but the POV-Ray calling path/method and wrapper 
code around pow() changes.

I expect you are measuring purely SDL parse time performance - (1) - 
without any attempt at removing the SDL looping cost ?

Bill P.

Aside 1 : Somewhere I posted a chart where I measured a few functions 
with respect to (1) and (3). I had plans for something more complete, 
but the work long stalled...

Aside 2 : The handling of function call exceptions is varied in the SDL 
and VM implementations. If invalid calls are made, the execution might 
or might not stop as viewed by the user. I 'suspect' non-stopping, 
invalid calls could significantly skew performance measurements - 
depending also on how POV-Ray was compiled.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> Interesting. Measuring the cost of functions in POV-Ray can be tricky.

As I gathered.  But I just wanted to get some ballpark figures as a starting
point.

> 1) Pure SDL calls to SDL internally wrapped C++ functions.
> 2) Calls from SDL of the VM implemented forms of functions.
> 3) Calls to VM functions from parse time 'compiled' code.


> I expect you are measuring purely SDL parse time performance - (1) -
> without any attempt at removing the SDL looping cost ?

I'm assuming the looping cost is a standard additive value for all my results,
so yes, all of the data is of Type 1, uncorrected.


- BW

Post a reply to this message