Very Computer

by **harri..** » Fri, 19 Apr 1996 04:00:00

Hello Povers.
I have been attempting to run a large (21 megs w/ 96,540 objects) Pov
file through Pov ray 3.0 beta 6 for MS-DOS on a 486dx2/66 w/ a 128 meg
povray causeway swap file, and it seems to die when ever I try to parse it.
I can seem to get it to run through just about every step of the parsing stage
in about a day, but it just CHOKES big time when it comes to the light
buffer. I left my machine on for THREE days and it was still creating the
buffers!!! Is there some way I can turn these buffers off, or will I save
time in the long run by letting it sit in the coner chuging away?
Any help would be apriciated,

Thank you,
Neil Herriford

--ps, anyone have a p6 200mhz that I can, ah, borrow for a few weeks to
run this file through? <g>
--

Public Access UNIX and Internet at (503) 220-1016 (2400-28800, N81)

by **Andreas Dilg** » Sun, 21 Apr 1996 04:00:00

>Hello Povers.
>I have been attempting to run a large (21 megs w/ 96,540 objects) Pov
>file through Pov ray 3.0 beta 6 for MS-DOS on a 486dx2/66 w/ a 128 meg
>povray causeway swap file, and it seems to die when ever I try to parse it.
>I can seem to get it to run through just about every step of the parsing stage
>in about a day, but it just CHOKES big time when it comes to the light
>buffer. I left my machine on for THREE days and it was still creating the
>buffers!!!

I think you'll find that the rendering won't complete in your lifetime. The
problem is in the swapping to disk. Considering that you already have a
large file that would take many hours (days?) to render, even if it all fit
in memory, then add the fact that hard-drive swapping is many thousands of
times slower than RAM, you have a rendering that will take many thousands of
days to complete. You didn't mention how much real memory memory you have.

I had a similar situation using Gforge a week or so ago, where I tried to make
a 1000 x 1000 heightfield (needs over 8MB of RAM - I only have 8MB), and it
ran for a whole day and hadn't shown any sign of finishing. I reduced the size
to 600 x 600, (needs about 3MB), and it completed in about 15 mins.

Quote:>Is there some way I can turn these buffers off, or will I save
>time in the long run by letting it sit in the coner chuging away?

You can turn the light and vista buffers off by using -UL -UV (read the docs),
but I'm not sure it will help in the long run or not. I would suggest making
the scene less complex, or getting a lot more memory (pretty cheap these days).

Cheers, Andreas.
--
Andreas Dilger University of Calgary \"If a man ate a pound of pasta and
(403) 220-8792 Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \ cancel out, leaving him still
http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert

by **Bjarne Nygaa** » Thu, 02 May 1996 04:00:00

hi..
I have rendered a scene with 47000 objects (mostly soft triangles) on a
DX2/66 with 32Mb and 16MB under Linux with 100Mb swapfile using pov3.06b.
During the run 50-55MB of swap is used for the structures.
As you say it is the parsing that takes time. But it is not CPU activity
wich causes the bottleneck, -it is disk I/O. Most of the parsing time the
CPU workload is down to 1-5%. When going from 16MB to 32MB the parsing
time went 1 hour to 25min. The picture itself was rendered in ca. 12 hours.
Using earlier versions of POV than 3 would spend must more time rendering.
With a scene as mine I would say that time has gone down to 1/3 or 1/4.

That is a performance boost that I like :)
Congratulations POV-team.

Bjarne Nygaard

: Hello Povers.
: I have been attempting to run a large (21 megs w/ 96,540 objects) Pov
: file through Pov ray 3.0 beta 6 for MS-DOS on a 486dx2/66 w/ a 128 meg
: povray causeway swap file, and it seems to die when ever I try to parse it.
: I can seem to get it to run through just about every step of the parsing stage
: in about a day, but it just CHOKES big time when it comes to the light
: buffer. I left my machine on for THREE days and it was still creating the
: buffers!!! Is there some way I can turn these buffers off, or will I save
: time in the long run by letting it sit in the coner chuging away?
: Any help would be apriciated,

: Thank you,
: Neil Herriford

: --ps, anyone have a p6 200mhz that I can, ah, borrow for a few weeks to
: run this file through? <g>
: --

: Public Access UNIX and Internet at (503) 220-1016 (2400-28800, N81)

by **Andreas Dilg** » Sat, 04 May 1996 04:00:00

>I have rendered a scene with 47000 objects (mostly soft triangles) on a
>DX2/66 with 32Mb and 16MB under Linux with 100Mb swapfile using pov3.06b.
>During the run 50-55MB of swap is used for the structures.
>As you say it is the parsing that takes time. But it is not CPU activity
>wich causes the bottleneck, -it is disk I/O. Most of the parsing time the
>CPU workload is down to 1-5%. When going from 16MB to 32MB the parsing
>time went 1 hour to 25min. The picture itself was rendered in ca. 12 hours.

The question I had for the originaly poster was how much real memory he had.
He mentions a 128 MB swap file, but how much RAM? You are correct that the
disk I/O will take by FAR the most time when swapping to disk. You will be
happy to know that the parsing speed has been dramatically improved by
Dieter for the next version of the beta (Linux beta already available). We
now use hasing tables for doing keyword matches rather than linear or
(for a brief period binary subdivision) searches. This speeds up the parsing
time for scenes with many objects by 25-50%. There have also been some
other parsing speedups. Of course, nothing will help if you don't have enough
real memory to do the job...

Cheers, Andreas.
--
Andreas Dilger University of Calgary \"If a man ate a pound of pasta and
(403) 220-8792 Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \ cancel out, leaving him still
http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert

Very Computer

Big Pov Files

Big Pov Files

Big Pov Files

Big Pov Files

Big Pov Files