I have 2 weeks. a 4cpu YMP Cray. I have
compiled the pov3.1g and it runs, BUT I
could go faster with a 450 mhz pentII. 
Any one out there have a clue as to where
to tweak the code or compile options?
shapes.pov took ~20 min. @ 800x640 !!!!!

Post a reply to this message

In article <37E2EF67.DF18C8DE@pacbell.net> , lyonstb <lyo### [at] pacbellnet>
wrote:

> I have 2 weeks. a 4cpu YMP Cray. I have
> compiled the pov3.1g and it runs, BUT I
> could go faster with a 450 mhz pentII.
> Any one out there have a clue as to where
> to tweak the code or compile options?
> shapes.pov took ~20 min. @ 800x640 !!!!!

POV-Ray will only be a single threaded process and so it can only make use
of one processor.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany

Post a reply to this message

Thorsten Froehlich wrote:
> 
> In article <37E2EF67.DF18C8DE@pacbell.net> , lyonstb <lyo### [at] pacbellnet>
> wrote:
> 
> > I have 2 weeks. a 4cpu YMP Cray. I have
> > compiled the pov3.1g and it runs, BUT I
> > could go faster with a 450 mhz pentII.
> > Any one out there have a clue as to where
> > to tweak the code or compile options?
> > shapes.pov took ~20 min. @ 800x640 !!!!!
> 
> POV-Ray will only be a single threaded process and so it can only make use
> of one processor.
> 
>     Thorsten
> 
> ____________________________________________________
> Thorsten Froehlich, Duisburg, Germany
yes I understand that it is single
threaded but don't you think that number
crunchin code (like povray) would run
faster on a computer that was built for
utra fast number crunching??? or has
povray been so influenced by the intel
world that the code/algorithm has a "speed
limit"?

Post a reply to this message

lyonstb wrote:
> 
> yes I understand that it is single
> threaded but don't you think that number
> crunchin code (like povray) would run
> faster on a computer that was built for
> utra fast number crunching??? or has
> povray been so influenced by the intel
> world that the code/algorithm has a "speed
> limit"?

I'm inclined to question the compiler (or, as you did, to question
whether you have all the optimizations on).

-Mark Gordon

Post a reply to this message

In article <37E42D15.F0B1DDEF@pacbell.net> , lyonstb <lyo### [at] pacbellnet>
wrote:
> yes I understand that it is single
> threaded but don't you think that number
> crunchin code (like povray) would run
> faster on a computer that was built for
> utra fast number crunching??? or has
> povray been so influenced by the intel
> world that the code/algorithm has a "speed
> limit"?

Well, no, it is not "influenced by the intel". However, the whole
architecture runs best on memory based systems as storing vectors in arrays
can't be optimized into registers on load/store based architectures by
compilers available today.
Now the Cray (at least the model I know which is a Cray-X MP) actually have
a very fast processor <=> memory interface. So that should not hurt you.
But notice that the i.e. the Cray-X MP will give you only about 120 MIPS and
230 MFLOPS which is not much compared with modern CISC or RISC CPUs.
I assume you know the performance to expect from the YMP Cray and if what
you currently get is not what you expect, you will need to tune the compiler
settings (and make sure you link with the fastest memory management library
you can get).  If that doesn't give a major speedup it is either a bad
compiler or you are in fact at the peak of the system speed for this
particular application (POV-Ray).   Good luck!


     Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany

Post a reply to this message

lyonstb <lyo### [at] pacbellnet> wrote:
: yes I understand that it is single
: threaded but don't you think that number
: crunchin code (like povray) would run
: faster on a computer that was built for
: utra fast number crunching???

  The speed of the cray (and other super)computers is based on the amount of
processors (from hundreds to several thousands) and the amount of memory
(usually several gigabytes). The processors themselves are not very fast;
AFAIK the fastest P3 can beat one of them.
  What you should do is to get a version of povray that can be run in
several threads (eg. PVM-Pov). Then you will achieve speeds that can be
even hundreds of times faster than with a Pentium.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

<This may be a bit late for the original writer, but this text
 wouldn't have helped him anyway...>

lyonstb <lyo### [at] pacbellnet> wrote:
>yes I understand that it is single threaded but don't you think that number
>crunchin code (like povray) would run faster on a computer that was built for
>utra fast number crunching??? or has povray been so influenced by the intel
>world that the code/algorithm has a "speed limit"?

You have to see the difference between number crunching and number
crunching. While povray is very computing intensive it is not built
along the lines of most number crunching code out there. Many high-end
computers, such as Cray T90 and SV1, derive their main computing
power from their vector units. If the code is not adapted for vector
units, tough luck, because then your computing grinds to a halt.

Other posters have claimed "bad compiler", which in part is true. Sadly
enough it's awfully hard to make the compiler do the vectoring for you,
just like it's hard to create parallellized machine code from standard
sequential source code. Vectorized code is even harder to derive
automatically. As povray is sequential, the original poster is out
of luck.

Raytracing as such, however, may possibly[1] be vectorized. That would
of course require a (more or less) ground up redesign in order to
maximize vectorization.[2]

/Anders
[1] I can't say I'm sure, but I can't see any reason why not.
[2] In most vector machines, speed difference between vectorized and
    non-vectorized code is somwhere in the 10^2-10^3 range, iirc.
-- 
Right after Armageddon, using your temperature calibration instruments
may come in a little low on Maslow's hierarchy of needs. Food, shelter
and ISO 9000 compliance may come first...
    -- Hart Scientific unofficial y2k page

Post a reply to this message

Anders Henriksson wrote:
> 
> <This may be a bit late for the original writer, but this text
>  wouldn't have helped him anyway...>
> 
> lyonstb <lyo### [at] pacbellnet> wrote:
> >yes I understand that it is single threaded but don't you think that number
> >crunchin code (like povray) would run faster on a computer that was built for
> >utra fast number crunching??? or has povray been so influenced by the intel
> >world that the code/algorithm has a "speed limit"?
> 
> You have to see the difference between number crunching and number
> crunching. While povray is very computing intensive it is not built
> along the lines of most number crunching code out there. Many high-end
> computers, such as Cray T90 and SV1, derive their main computing
> power from their vector units. If the code is not adapted for vector
> units, tough luck, because then your computing grinds to a halt.
> 
> Other posters have claimed "bad compiler", which in part is true. Sadly
> enough it's awfully hard to make the compiler do the vectoring for you,
> just like it's hard to create parallellized machine code from standard
> sequential source code. Vectorized code is even harder to derive
> automatically. As povray is sequential, the original poster is out
> of luck.
> 
> Raytracing as such, however, may possibly[1] be vectorized. That would
> of course require a (more or less) ground up redesign in order to
> maximize vectorization.[2]
> 
> /Anders
> [1] I can't say I'm sure, but I can't see any reason why not.
> [2] In most vector machines, speed difference between vectorized and
>     non-vectorized code is somwhere in the 10^2-10^3 range, iirc.

I've done some more reading since my last response, and I suspect that
one or more of the existing unofficial parallel versions of POV-Ray
might take good advantage of a Cray, but I don't have a Cray sitting
around with which to test this hypothesis.  It's not specifically tuned
for a Cray, but Cray versions of some message passing libraries are, and
it may be sufficient to put the proper library calls in the right
places.

-Mark Gordon

Post a reply to this message