> Any specific reason the change couldn't be done with a couple of
> search & replaces pr source file ?? Back around POV-Ray 1.0 I actually

that would be easy.
sed scripts for "long"=>"int32", "unsigned long" => "u_int32".

the problem is that there are going to be places where a true long is needed.
Also, after the switch, someone that knows what they're doing would need to test 
everything to make sure it still works.  It could introduce subtle (perhaps 
platform-specific) problems.

-- 
------------------------------------------------------------------
  Andrew Schultz                    | The views expressed might
  ajs### [at] eosncsuedu             | not represent those of NCSU.
  http://www4.ncsu.edu/~ajschult/   | They are however, correct.

Post a reply to this message

On Fri, 16 Aug 2002 14:50:53 -0400, Andrew Schultz
<ajs### [at] eosncsuedu> wrote:
>that would be easy.
>sed scripts for "long"=>"int32", "unsigned long" => "u_int32".
>
>the problem is that there are going to be places where a true long is needed.
>Also, after the switch, someone that knows what they're doing would need to test 
>everything to make sure it still works.  It could introduce subtle (perhaps 
>platform-specific) problems.

And thus a quick search & replace won't work. It'll require fairly
extensive knowledge of the POV-Ray internals, an area where I'm
definitely not up-to-date (haven't delved deeply into the source since
1.0 and much has changed since).

/Erkki

Post a reply to this message

Erkki.Sondergaard wrote:
>the time. Ok, I also have to check if we have the right compiler for
>my usual platform, IBM Z-series mainframes, I know we're at the right
>OS level to have 64-bit support, I belive we have at least the
>run-time libs, but it's no good without the right compiler.

I heard somewhere that mainframes are not particular good at floating point
stuff and if I remember correctly the IBM one's are only IEEE (floating
point standard(can't remember the number)) compitable since a few
generation (S/390 G3 or G4?).

I tried to run 3.1 in 64 bits sometime ago on IBM Power machines. no speed
difference. And I never tried to let pov use more then 4 gigs of memory
either.

Also there are two bugs at least in 64 bit versions of pov 3.1: The time at
the end of the render is negative  and radiosity does not work at all. I
tried to report it as a bug, but the Pov-team wasn't interested.

I haven't tried to get 64 bit compile with 3.5, haven't even managed to get
a 32 bit version on AIX (but that has more to do with me than with pov ;)

Thomas

Post a reply to this message

On Mon, 19 Aug 2002 12:27:24 EDT, "Thomas" <tho### [at] gmxnet> wrote:

>Erkki.Sondergaard wrote:
>>the time. Ok, I also have to check if we have the right compiler for
>>my usual platform, IBM Z-series mainframes, I know we're at the right
>>OS level to have 64-bit support, I belive we have at least the
>>run-time libs, but it's no good without the right compiler.
>
>I heard somewhere that mainframes are not particular good at floating point
>stuff and if I remember correctly the IBM one's are only IEEE (floating
>point standard(can't remember the number)) compitable since a few
>generation (S/390 G3 or G4?).

You're right, if you don't have the right hardware floating point
calculations are emulated in software, not in hardware (in other
words, slow as molasses). When I ported POV-Ray 1.0 to S/370 I didn't
do it for the speed (at that time about 7 times faster than a
486/50MHz, _with_FP_emulated_) but for the memory as we had 256 MB on
the mainframe and I only had 4 MB on my 386 workstation. Actually I
think my first port was DBW-Render, it had fractal subdivision
surfaces, they ate storage _very_ fast (4* for each level of
subdivision.

>I tried to run 3.1 in 64 bits sometime ago on IBM Power machines. no speed
>difference. And I never tried to let pov use more then 4 gigs of memory
>either.

The main advantage in running POV-Ray (or other sw) in 64 bits isn't
speed but the available memory space. In other words, it's only
interesting if your scene takes more than 2 GB storage to trace. I
belive that G. Tran has passed the 1 GB mark on some of his scenes and
I think that some of the IRTC images has come close to hitting the 2
GB limit. As for speed, well, all your pointers double in length and
that isn't good for speed as you have to load twice as much data. 

>Also there are two bugs at least in 64 bit versions of pov 3.1: The time at
>the end of the render is negative  and radiosity does not work at all. I
>tried to report it as a bug, but the Pov-team wasn't interested.

Well, if the POV-Team doesn't have the hardware to test on they can't
do much. Remember that the POV-Team mostly only have our personal
hardware to test on and 64-bit systems aren't that common (yet). I
have access to 64-bit hw at work (IBM, newest Z-Series), but I still
have to check if we have the right compiler. 

In my first raytracing test on S/370 I bombed out on the 16 MB limit
until I learned how to compile/link in 31-bit mode, in 64-bit mode I
better warn the performance guys before I allocate a couple of GB
storage (virtual or real).

/Erkki

Post a reply to this message

Erkki.Sondergaard wrote:

>The main advantage in running POV-Ray (or other sw) in 64 bits isn't
>speed but the available memory space. In other words, it's only
>interesting if your scene takes more than 2 GB storage to trace. I
>belive that G. Tran has passed the 1 GB mark on some of his scenes and
>I think that some of the IRTC images has come close to hitting the 2
>GB limit. As for speed, well, all your pointers double in length and
>that isn't good for speed as you have to load twice as much data.

The biggest machine we have here has got 8 Gigs of RAM, so it would be a
nice candidate for some testing on it ;) And hopefully 64 bit machines
become "normal" once the AMD processor hit the streets.

But running pov on a mainframe sounds very cool.

Thomas

Post a reply to this message

On Thu, 22 Aug 2002 07:58:55 EDT, "Thomas" <tho### [at] gmxnet> wrote:
>But running pov on a mainframe sounds very cool.

Back then I was a systems programmer in a fairly small company (only
400-600 users) and after hours I could use all the ressources I wanted
to. The mainframes are very character-centric, no image tools at all,
can't even display an image, so I had to download the finished image
in order to view it. I never did do much real tracing on the mainframe
once I got a PC at home, what I saved in time tracing on the mainframe
was mostly lost when I had to download the finished images on a 2400
baud connection.

/Erkki

Post a reply to this message