I have been following this for a while, so maybe this helps you understand a 
bit better what you need to do.  While I respond to everything in your 
message, the important part is in the last two paragraphs.

> Nope, not all code can handle all levels of optimisations well. Lets
> assume, for the sake of argument, that Gcc 3.4.3 is stable, since we all
> use it ;).

Note that there are 166 bugs in 3.4.3 which were fixed in 3.4.4 alone.  Of 
course, if gcc is buggy or not has nothing to do with the problem at hand.

> Yet I know know numerous programs which can only be compiled
> using special flags, or without any Ox-flag at all.

Which is 99.9% of all cases indicates either a bug in the programs, the 
compiler performing certain optimizations or a user misunderstanding the 
proper configuration of compiler optimization options.  Of course, this also 
has nothing to do with the problem at hand.

> I did some physical modelling with a program called, p3d, which
> generated completely different results when compiled with different
> settings. This program too, like MegaPov, was dealing with floating
> numbers which could differ only in order of magnitude like 1e-7.
> Suddenly compiler option are not trivial anymore, although
> theoretically, it should be just fine.

Your statement, while being correct in the observation that certain compiler 
options may influence floating-point precision (for various reasons, non of 
which are bugs at all), has nothing to do with the problem at hand. In fact, 
it shows a clear misunderstanding of the nature of the problem.

> Always look in the mirror first. Especially if you compile with
> "-ffast-math". The compiler generates code which directly accesses the
> FPU to perform i.e sin,cos operations 

This is plain wrong, this is not what "-ffast-math" is about.  "-ffast-math" 
is nothing more than shortcut to enable various generally non-IEEE/ISO 
conforming floating-point optimizations (and the example you mention isn't 
one of them).  And it has, just like all the things you mentioned so far, 
nothing to do with the problem at hand.

> en there is no checking for NaN of
> Zero; this is responsibility of the programmer. Strange things can &
> will happen !!

Nothing strange can happen, the behavior is complete deterministic (except 
of certain generations of P1s, of course ;-) ) and completely predictable. 
And this also has nothing to do with the problem at hand.

> Anyway, interesting to see that all no-one (!) accepts the possibility
> that the MegaPov distribution could contain a error.

No, it is you who does not understand what many people have told you so far: 
  Somehow you have run into a dead end and are now pushing against a wall, 
not listing to anybody else who is trying to tell you to just turn around to 
get out of the deadened and find a solution to your problem ;-)

Nobody can reproduce your bug and you cannot expect help if you refuse to 
get a fixed kernel.  It has already been pointed out to you that you need to 
get a fixed kernel first.  A kernel panic isn't pov's fault no matter how 
you twist and turn it.

Once your kernel is fixed, one of two things can happen: Either MegaPOV 
works, or you get a reasonable crash of MegaPOV without a kernel panic.  In 
the former case you can just be happy, in the later you will need to come 
back with a bug report.  The neat thing is once your kernel no longer 
panics, and if there should indeed be a problem in MegaPOV, you can include 
a stack trace and other relevant information along with your report.

	Thorsten Froehlich, POV-Team

Post a reply to this message

Oops,

I clearly forgot to mention that I indeed was worried
about the system crash. Although the kernel served me well for months, I
discarded it and I switched to a "official" stable kernel,
recompiled Gcc & Glibc just for good measure. Nor more
system crashes as noted in my first post last week. The feedback was
right; a program crash should be handled by the OS.

That is why I promised to do a follow-up. I purposely installed two
clean distributions, with proper, stable, non-patched kernels.
Unfortunately the MegaPov behaviour persisted, but those collapses were
handled correctly by the O.S. I did not mention "system crashes" at all
in my follow-up.

Thorsten Froehlich wrote:
> Which is 99.9% of all cases indicates either a bug in the programs, the
> compiler performing certain optimizations or a user misunderstanding the
> proper configuration of compiler optimization options.  Of course, this
> also has nothing to do with the problem at hand.
Could you please explain? This could be exactly the problem we deal
with. MegaPov could have bugs; 1.2.1 is a bug-release, and the
./configure script could have generated compiler flags which uncovers
these bugs. Remember, ./configure is dynamic script, trying to make
educated guess to which compiler flags are best for your specific
Unix-box. Thats why I started hard-coding these flags, in order to make
sure I could produce a correct binary for my machine.

> Nothing strange can happen, the behavior is complete deterministic
> (except of certain generations of P1s, of course ;-) ) and completely
> predictable. And this also has nothing to do with the problem at hand.
Sorry, joyfull language obscured the message: it is deterministic: it dies.

> No, it is you who does not understand what many people have told you so
> far:  Somehow you have run into a dead end and are now pushing against a
> wall, not listing to anybody else who is trying to tell you to just turn
> around to get out of the deadened and find a solution to your problem ;-)
See first paragraph. I did address the kernel issue right away. I try to
be open-minded.

> Nobody can reproduce your bug 
No-one has either confirmed, nor rejected the bug.

> ..include a stack trace....
I'd love to. I will google for a HowTo.

Are you realy sure about the --fast-math ? It is just so typical for
MegaPov, with all the physics code and the ininitesimal calculations
associated. I have seen so many physical simulations die because the
approximations were approaching Zero en there was just not enough
boudary checking..because there never is time/imagination to prevent
them all... I hated it too when wrote those programs.

Anyway, I try to cooperate :)

Post a reply to this message

Willem wrote:
> That is why I promised to do a follow-up. I purposely installed two
> clean distributions, with proper, stable, non-patched kernels.
> Unfortunately the MegaPov behaviour persisted, but those collapses were
> handled correctly by the O.S. I did not mention "system crashes" at all
> in my follow-up.

Hmm, five hours ago you said something different ;-)


-------- Original Message --------
Subject: Re: Megapov 1.2.1 Linux - Followup
Date: Mon, 12 Sep 2005 18:23:03 +0200
From: Willem <Willem>
Newsgroups: povray.unofficial.patches

nomail wrote:
 > Willem <Willem> wrote:
 >
 >>It's your kernel/glibc etc. !!
 >>No. Got a free Suse 9.3 disk from a magazin, installed on free
 >>partition: same errors. Installed new Gentoo 2005.1 release: same errors.
 >
 >
 > So there is still a kernel panic when you run MegaPOV with any of those
 > kernels?

On my machine, yes.

Post a reply to this message

Willem wrote:
> 
> Anyway, interesting to see that all no-one (!) accepts the possibility
> that the MegaPov distribution could contain a error. Although it most
> probably does not contain serious bugs,

This is completely wrong.  Everyone who has some basic knowledge about
programming knows that there are bugs in a program as large as MegaPOV
and esp. in new and partly experimental patches like in MegaPOV there
can be serious bugs.

Yet there has been absolutely no indication that any of the problems you
reported is caused by a fault in MegaPOV.

>  not too many people use it on a linux-box, so there could always be
> "something" if compiled on a different Unix-box.

That's wrong as well - why would you think that?

The fact that no one was able to reproduce any of the problems you
reported does not mean no one tried.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.tu-bs.de/~y0013390/ (Last updated 24 Jul. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Thorsten Froehlich wrote:
> Willem wrote:
>
> Hmm, five hours ago you said something different ;-)
Aargh,
You are right, sorry. I even mentioned kernel panic it in the original
post.

NO, just MegaPov crashing, kernel stay ok.

-----------------------------------
Lesson learned: ..Do not try to answer questions while having a
phone-conf at the same time...

Post a reply to this message

Christoph Hormann wrote:
> Everyone who has some basic knowledge about
> programming knows that there are bugs in a program as large as MegaPOV
> and esp. in new and partly experimental patches like in MegaPOV there
> can be serious bugs.
Please don not mistake my kindness for dumbness. Of course it contains
bugs, but to bluntly state that, whilst you are spending serious time on
this program, is not going to help anyone is it ?


> The fact that no one was able to reproduce any of the problems you
> reported does not mean no one tried.
One has to live with the evidence presented. One cannot assume that
verything is allright, or totally wrong, just because you hear
nothing...that where these newsgroups come in: communication !!

Post a reply to this message

> If I run ./configure without options the following flags are produced in
> the Makefile:
> CXXFLAGS =  -pipe -Wno-multichar -s -O3 -ffast-math -malign-double
> -minline-all-stringops -m3dnow -march=athlon-xp -mtune=athlon-xp

	Note that the -ffast-math and -m3dnow options are not part of
the official povray-3.6.1 configure script, but were most likely added
by the gentoo folks.  The former will be in official 3.6.2 - it was not
included so far, but indeed works without problem.  The latter has no
effect at all (identical binaries with and without the option on AMD
K7/K8 platforms) and is therefore useless; same for -mmmx.

	- NC

Post a reply to this message

Willem <Willem> wrote:
> -march=athlon-xp -mtune=athlon-xp

  AFAIK the -march option automatically turns the equivalent -mtune (and also
the equivalent -mcpu) on, so there's no need to specify it explicitly.

-- 
                                                          - Warp

Post a reply to this message

>   AFAIK the -march option automatically turns the equivalent -mtune (and also
> the equivalent -mcpu) on, so there's no need to specify it explicitly.

	Yes, this is known and the change was done already for the next release.

	- NC

Post a reply to this message

Nicolas Calimet wrote:

>     Note that the -ffast-math and -m3dnow options are not part of
> the official povray-3.6.1 configure script, but were most likely added
> by the gentoo folks.  The former will be in official 3.6.2 - it was not
> included so far, but indeed works without problem.  The latter has no
> effect at all (identical binaries with and without the option on AMD
> K7/K8 platforms) and is therefore useless; same for -mmmx.
> 
>     - NC

No. --fast-math was not added by Gentoo package maintainer.
Using the Gentoo version got me in trouble with
Christoph....so I downloaded & used the default tarball.

It was the Megapov script from Christoph which supplied
the --fast-math.

WdW

Post a reply to this message