Daniel Nilsson <pov### [at] daniel-nilssoncom> wrote:
> The thing to learn from this, and it's my experience from work too, is 
> that you should write code that is easy to read and maintain rather than 
> try to be clever with optimizations.

  IMO this:

    variable = someLengthyCalculation;
    useVariable(variable);
    useVariableForSomethingElse(variable);

is more readable than:

    useVariable(someLengthCalculation);
    useVariableForSomethingElse(someLengthCalculation);

especially if "someLengtyCalculation" is even a bit complicated. (Basically
the variable makes it very clear that the two expressions are, in fact, the
one and same, something which might not be visually obvious if the expression
is repeated.)

  As a bonus, you'll make absolutely sure the compiler won't calculate
it twice. (In some cases it might be that the compiler is forced to
calculate it twice because it can't know if some called function has
side-effects.)

-- 
                                                          - Warp

Post a reply to this message

On 30-Dec-08 13:00, Warp wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> On 29-Dec-08 23:58, Warp wrote:
>>> clipka <nomail@nomail> wrote:
>>>> So yes, that should do: A loop typically taking less than two iterations (the
>>>> most expensive part probably being the RNG) and a square root. Quite
>>>> inexpensive after all.
>>>   When you project the point to the hemisphere, you'll probably need three
>>> multiplications and a square root. That's going to be much more expensive
>>> than the RNG. (High-quality RNGs are very fast. They are faster than a LCG,
>>> which consists of one integer multiplication and addition.)
> 
>> but sin and cos are (much?) more costly than sqrt and multiplication is 
>> comparatively negligible.
> 
>   I was commenting to his estimation that the RNG would be the most
> expensive part of the calculation. Certainly not true. I would estimate
> that one single sqrt() call will be several times slower than pulling a
> value from a high-quality RNG.
> 
sqrt has at worst N/2 iteration, with N the number of significant bits. 
That is a naive implementation. I thought there are even faster 
algorithms. Cheap calculators often have a button for sqrt, implying 
probably that they have a (naive) hardware implementation. I don't know 
if it is available also on more complex processors.

Post a reply to this message

On 30-Dec-08 9:00, Thomas de Groot wrote:
> "andrel" <a_l### [at] hotmailcom> schreef in bericht 
> news:495### [at] hotmailcom...
>>> The redistribution of the beta source code is prohibited. There won't be 
>>> a permission for anyone to distribute the beta source code or binary in 
>>> any other form. The purpose of making the beta source code available is 
>>> to get submissions of bug fixes that will be added to the official beta 
>>> source code and beta binaries - assuming they work, of course ;-)
>>>
>> I think a relevant question here is: what is a distribution of source. If 
>> clipka sends the source or a binary by regular mail to e.g. Thomas is that 
>> distribution? or must it be publicly available to be one. If it is the 
>> first then collaboration to implement and test improvements of beta source 
>> is effectively impossible. I can think of reasons to do it that way. One 
>> would be that source in this beta (double beta?) stage should be 
>> coordinated by a POV team member. But, which one should that be? In this 
>> specific case of radiosity: who is coordinating that and would that person 
>> in this case give permission to create a test version for a selected group 
>> to use?
>>
>> Another one: if clipka had started from the 3.16 source would that have 
>> made a difference?
> 
> 
> Right. The Real World is tougher than I imagined (and rightly so, I suppose) 
> :-)
> 
> We need a creative solution to solve this conundrum, because it would be too 
> absurd if, for legal reasons, improvement testing of beta elements could 
> not proceed one way or another. 

The issue only raised it's head now because the beta source is 
available. Precisely for the reason that it can be improved by others 
that the regular POV team. It seems that they did not completely think 
through what the consequences would be if someone would actually do it. ;)
I'd be very interested in what Chris has to say about it. He seems a bit 
quite.


> I suppose that the best way to go would be 
> to implement Clipka's work in some beta, have it tested and reported back by 
> the community. Following which, decisions can be made about further 
> implementation or trashing.
> 
> My world view is simple, I know, but we have to start somewhere.

There are a number of ways to solve it, roughly in order of (my) preference:
- as you suggest, put it in a regular beta 3.17
- create a working group of clipka and a select group of beta testers to 
tackle this  radiosity issue under supervision of a team member.
- give clipka (and future similar cases) permission to do so for a 
limited time and only for this specific test (I think the legal wording 
allows for special permissions from the POV team)
- add clipka (temporarily) to the team.
- handle everything by regular (encrypted) mail and don't tell anyone.

Any more alternatives?

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> "Cleanup Parse Warning: This rendering uses the following experimental
> feature(s): radiosity. The desing and implementation of these features is likely
> to change in future version of POV-Ray. Full backward compatibility with the
> current implementation is NOT guarenteed."
>
> This tells me that, in future versions, the way to handle radiosity may change.
>
> This also tels me that the result may change from version to version, even if
> the parameters do stay the same.
>
> So, after seeing that warning, if any scene using radiosity, or photons, don't
> give the same final image between 3.6 end 3.7, i'd say that it's NORMAL and
> EXPECTED.

That message was part of 3.5 as well and perhaps earlier.  An "experimental"
feature that has been around for, what?, 10 years.  That's even longer than
Google eternal betas... :))

Post a reply to this message

Warp wrote:
> Daniel Nilsson <pov### [at] daniel-nilssoncom> wrote:
>> The thing to learn from this, and it's my experience from work too, is 
>> that you should write code that is easy to read and maintain rather than 
>> try to be clever with optimizations.
> 
>   IMO this:
> 
>     variable = someLengthyCalculation;
>     useVariable(variable);
>     useVariableForSomethingElse(variable);
> 
> is more readable than:
> 
>     useVariable(someLengthCalculation);
>     useVariableForSomethingElse(someLengthCalculation);
> 
> especially if "someLengtyCalculation" is even a bit complicated. (Basically
> the variable makes it very clear that the two expressions are, in fact, the
> one and same, something which might not be visually obvious if the expression
> is repeated.)
> 
>   As a bonus, you'll make absolutely sure the compiler won't calculate
> it twice. (In some cases it might be that the compiler is forced to
> calculate it twice because it can't know if some called function has
> side-effects.)
> 

Yes, I agree that in this case the code with the variable is the most 
readable. My point is that in general you should not bother with 
optimization. The compiler is most of the time clever enough to figure 
it out. Only try to optimize if profiling shows some inefficiency.

-- 
Daniel Nilsson

Post a reply to this message

Daniel Nilsson <pov### [at] daniel-nilssoncom> wrote:
> > This can be optimized to:
> >     [...]
> > Or maybe this is even a bit faster (and actually a tiny bit more defensively
> > coded):
> >     [...]
>
> No need to optimize the code, that's the job of the compiler. Any modern
> compiler will notice the common subexpressions and optimize them. I just
> did a small test with all three versions above compiled with "gcc -S
> -O2" (gcc 4.1.2 on x86_64 linux). The produced assembly is virtually
> identical for all three cases, the last one actually has the most
> instructions generated (extra moves mostly).

Hm... well, maybe I'm showing my age... I'm actually not too deep into
compiler-based optimizations. It has been a while since I last looked at what
an x86 compiler makes of my C/C++ code.

I'd still consider using the last version though, because I know it cannot run
into number precision issues with the sqrt(). But then agan, I'm not a learned
floating-point expert either, so maybe I'm a bit over-defensive here.

(My job is usually to write robust and easy-to-maintain software (or fix less
robust and more-difficult-to-maintain software), with some hardware jockeys
making sure that the small black boxes it is flashed into provide safe margins
of computing power.)

> Oh, and happy new year!

Same to you, and everyone else around.

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> sqrt has at worst N/2 iteration, with N the number of significant bits.
> That is a naive implementation. I thought there are even faster
> algorithms. Cheap calculators often have a button for sqrt, implying
> probably that they have a (naive) hardware implementation. I don't know
> if it is available also on more complex processors.

From the "Intel(R) 64 and IA-32 Architectures Software Developer's Manual,
Volume 1: Basic Architecture":

------------------------
8.3.5 Basic Arithmetic Instructions

The following floating-point instructions perform basic arithmetic operations on
floating-point numbers. Where applicable, these instructions match IEEE Standard
754:

FADD/FADDP Add floating point
FIADD Add integer to floating point
FSUB/FSUBP Subtract floating point
FISUB Subtract integer from floating point
FSUBR/FSUBRP Reverse subtract floating point
FISUBR Reverse subtract floating point from integer
FMUL/FMULP Multiply floating point
FIMUL Multiply integer by floating point
FDIV/FDIVP Divide floating point
FIDIV Divide floating point by integer
FDIVR/FDIVRP Reverse divide
FIDIVR Reverse divide integer by floating point
FABS Absolute value
FCHS Change sign
FSQRT Square root                          <--
FPREM Partial remainder
FPREM1 IEEE partial remainder
FRNDINT Round to integral value
FXTRACT Extract exponent and significand

[...]

8.3.7 Trigonometric Instructions

The following instructions perform four common trigonometric functions:

FSIN Sine
FCOS Cosine
FSINCOS Sine and cosine
FPTAN Tangent
FPATAN Arctangent

[...]

8.3.9 Logarithmic, Exponential, and Scale

The following instructions provide two different logarithmic functions, an
exponential function and a scale function:

FYL2X Logarithm
FYL2XP1 Logarithm epsilon
F2XM1 Exponential
FSCALE Scale

[...]

------------------------

Don't expect all these to be "naive hardware implementation" in the same sense
as, say, an integer addition, shift, bit-wise AND/OR/XOR or whatever. Even a
floating-point addition is a non-trivial thing. Rather consider the FPU
(Floating Point Unit) a computer in the computer: You feed some data into it,
give it an instruction what to do with that data, and then basically wait for
the (fast and highly optimized) hard-wired FPU "programlets" to complete. Or do
some other usefull stuff in the meantime.

To my knowledge, a lot of work is saved by using Look-up-tables (like people
used in old times before pocket calculators had a "sin", "log" or "sqrt"
button) to optimize away a few iterations of the algorithms.

BTW, your typical pocket calculator will do just about the same. AFAIK there is
no non-iterative algorithm for computing the square root of an arbitrary
floating point number.

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> - as you suggest, put it in a regular beta 3.17

(I guess you mean 3.7 ;))

Clearly my favorite as well. The POV team has a copy of my code.

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> That message was part of 3.5 as well and perhaps earlier.  An "experimental"
> feature that has been around for, what?, 10 years.  That's even longer than
> Google eternal betas... :))

But it was well deserved - from what I see, it was obviously too crappy in 3.6
to remove that warning :)

Post a reply to this message

Jaime Vives Piqueres posted an interesting radiosity test scene in
p.b.images, where he basically improved the quality of the radiosity
calculations by rendering the same image many times, each time
decrementing the error_bound, and saving/loading the radiosity data
to a file for the next render. The quality of the radiosity lighting
got very significantly improved this way, with a surprisingly moderate
overall render time.

  Given how much this technique improves the quality of the lighting
I think it should be seriously considered to be studied further and
implemented as an internal feature of POV-Ray, so that POV-Ray can be
made to do this automatically, without the need for the save files nor
setting animation rendering manually.

-- 
                                                          - Warp

Post a reply to this message