Thorsten Froehlich wrote:
>In article <web.3d5bf4e2b1abd86b9ecef47b0[at]news.povray.org> , "Andrew
>Schultz" <ajs### [at] eosncsuedu> wrote:
>
>> That is a hack has the potential to busticate external include files that
>> use "long" properly.
>
>But there are no such files if you use a compiler switch!

Are you saying that it won't include stdio.h if you use the compiler option?
If you compile with such an option and call fseek (which takes a long),
the compiler option would have it pass a 32-bit "long".  Wouldn't this (and
other situations throughout the code) cause major problems?

Additionally, gcc support for such an option is sparse and, for Alpha,
non-existent.

--------------
Andrew Schultz

Post a reply to this message

"Andrew Schultz" <ajs### [at] eosncsuedu> schrieb im Newsbeitrag
news:web.3d5c10e9b1abd86b9ecef47b0@news.povray.org...
> Are you saying that it won't include stdio.h if you use the compiler
option?
> If you compile with such an option and call fseek (which takes a long),
> the compiler option would have it pass a 32-bit "long".  Wouldn't this
(and
> other situations throughout the code) cause major problems?

Nope, it of course assume you link to the appropriate runtime libraries that
implement those calls in 32 bit.  Of course, this first of all assumes those
functions don't take arguments of a more abstract type (such as size_t)
already and those types are defined properly using compiler specific means.

> Additionally, gcc support for such an option is sparse and, for Alpha,
> non-existent.

Yes, on some platforms that habe been 64 bit "for a long time" it tends to
be not well supported anymore.  Other plaforms that had a vital 32 bit
predecessor such as Sparc at least did support it (haven't checked for years
though).

    Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Yes, on some platforms that habe been 64 bit "for a long time" it tends to
> be not well supported anymore.  Other plaforms that had a vital 32 bit
> predecessor such as Sparc at least did support it (haven't checked for years
> though).

  The UltraSparc processor can run processes in 32-bit or 64-bit mode
(in a similar way as Intel processors can run processes in 32-bit or 16-bit
mode). By default programs are compiled as 32-bit binaries by the Sun cc,
but can be compiled as 64-bit binaries with an architecture option. Gcc
can only compile 32-bit binaries.

  For some reason many people think that compiling a program as a 64-bit
binary would make it faster. That's not so, naturally. In fact, compiling
a program as 64-bit binary makes it slightly slower (this is most probably
because pointers and long integers are now 64 bits long instead of 32 bits,
and caches fill up faster). However, we are talking about only some percents
of slowdown.
  Even if the program uses the long long type (which is 64 bits regardless
of the compilation mode), compiling to a 64-bit binary makes it slightly
slower. Curiously gcc is really sloppy when optimizing long longs for Sparc.
A program which uses long longs a lot can be several times faster when
compiled with Sun cc than when compiled with gcc.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

On Thu, 15 Aug 2002 22:16:05 +0200, "Thorsten Froehlich"
<tho### [at] trfde> wrote:
>Oh really? ;-)  I never said there is no "real" solution.  But who is going
>to implement the "real" solution considering the size of the POV-Ray source
>code...? :-(

Someone with a lot of time on their hands ?? Technically it's not a
difficult task, just a tedious one. Since I work for a company that
has 64-bit machines (so I can test it) I'm qualified, the problem is
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. 

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
wrote some C parsing programs to facilitate a port to a mainframe, at
that time I had to mess with all the global names (functions and
variables) since the linker only supported 8 character external names.
Hmm, have to check if that limitation still exists as well.

/Erkki

Post a reply to this message

> 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