How should a multithreaded povray work?

I guess the user specifies how many threads he/she wants, then what?

Should the threads render lines, or should it devide to picture in to
'imageheight devided by threads' blocks and render them?


 /j

Post a reply to this message

On Tue, 25 May 1999 14:30:43 +0200 (CDT), Jan Danielsson wrote:
>How should a multithreaded povray work?
>
>I guess the user specifies how many threads he/she wants, then what?
>
>Should the threads render lines, or should it devide to picture in to
>'imageheight devided by threads' blocks and render them?

Ignoring for a moment how hard any multithreaded design will be to 
implement in practice, I think a thread should always just do whichever
scanline is next when it gets ready to go.  For one thing, this will 
help minimize the amount of rendered information that is hanging 
around in memory without having been written to the file.  For another,
it will do a more effective job of balancing the load between the 
threads.  Skyvase, for example, spends most of its time in the bottom 
half of the image.

You could, of course, run a low-resolution test render first and 
assign blocks of the image based on the histogram results.

Okay, now let's stop ignoring how hard a multithreaded design is.  Can
I ask all of you "we need SMP so we need threads" people what's wrong 
with plain ol' fork?  Yeah, Winblows doesn't support fork natively, 
but that seems like something Mickeysoft should fix.  Or just install
a real OS on your fancy SMP machine.

Post a reply to this message

In article <374aa7a5.0@news.povray.org> , par### [at] fwicom (Ron Parker) 
wrote:

> Okay, now let's stop ignoring how hard a multithreaded design is.  Can
> I ask all of you "we need SMP so we need threads" people what's wrong
> with plain ol' fork?  Yeah, Winblows doesn't support fork natively,
> but that seems like something Mickeysoft should fix.  Or just install
> a real OS on your fancy SMP machine.

NT is POSIX compliant, and maybe Windows 2001 will be as well :-)


    Thorsten

Post a reply to this message

On Tue, 25 May 1999 18:03:03 +0200, Thorsten Froehlich wrote:
>In article <374aa7a5.0@news.povray.org> , par### [at] fwicom (Ron Parker) 
>wrote:
>
>> Okay, now let's stop ignoring how hard a multithreaded design is.  Can
>> I ask all of you "we need SMP so we need threads" people what's wrong
>> with plain ol' fork?  Yeah, Winblows doesn't support fork natively,
>> but that seems like something Mickeysoft should fix.  Or just install
>> a real OS on your fancy SMP machine.
>
>NT is POSIX compliant, and maybe Windows 2001 will be as well :-)

I'm running Win2K (AKA NT5) on this machine right now, as it happens,
writing device drivers and other hacks.  So I'm somewhat familiar with 
it...

Yes, NT has a POSIX compliant subsystem.  Presumably, one could build
a version of POV that runs in the POSIX subsystem.  It wouldn't have 
the Windows GUI, though, because the POSIX and Win32 subsystems are
completely independent from each other.  And of course it wouldn't 
run on Win9x, which still seems pretty popular for some reason.

If one wanted an SMP POV on any Windows machine, though, one could 
build the theoretical Unix SMP version (one using fork, of course) 
with the Cygwin toolkit.  It does have a usable implementation of 
fork.  With a little extra work you could even tie such an 
implementation to the existing GUI (though you couldn't distribute
the resulting product.)

Post a reply to this message

Ron Parker wrote:
> 
> And of course it wouldn't
> run on Win9x, which still seems pretty popular for some reason.

hehe, in my case, I'm running win 95 from the reason of... Size. the installed
size of 95 compared to either NT workstation(not an alternative due to driver
problems) and 98 is big. I hope win2k will address this a bit...

don't bother responding to this, since the discussion would probably end up in
the OS wars. and I'm too OT as it is.

-- 
//Spider    --  [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
And the meek'll inherit what they damn well please
	Get ahead, go figure, go ahead and pull the trigger
		Everything under the gun
			--"Sisters Of Mercy" -- "Under The Gun"

Post a reply to this message

[...]
>Okay, now let's stop ignoring how hard a multithreaded design is.

Are you talking about 'multithreading in general', or 'rewriting povray'?

Since I have written many multithreaded applications of various types I do
not have any problems controlling threads. However; if you're talking about
povray... You may be right. But I have some ideas. I don't think it should be
too hard.

>Can I ask all of you "we need SMP so we need threads" people what's wrong 
>with plain ol' fork?

And I ask; what's wrong with threads? (Now ask me what's wrong with forks; We
could do this until the sun explodes :-)

I'm choosing threads because:
1) They are excellently implemented in OS/2.
2) They are native to OS/2.
3) If I remember correctly, the emx-package implements fork. However, I am
not a big fan of emx, and I have a compiler I like which only handles
threads... so.....

>Yeah, Winblows doesn't support fork natively, 
>but that seems like something Mickeysoft should fix.  Or just install
>a real OS on your fancy SMP machine.

Windows? Who's talking about Windows? I'm an OS/2 developer.



I would like to make a portable povray which would be SMP-aware. However; I
have lots of experince with threads, but _very_ little with forks..


 /j

Post a reply to this message

Certain types of image processing routines are almost trivial to break into
SMP threads under NT, especially if you can get all the performance from
just partitioning the image.  It can be done using only a thread control
structure, ResumeThread, SuspendThread, and Sleep functions and wrappers
around the needed image processing routines.  Alternating scanlines is
better because it minimizes paging at the various cache levels.

This doesn't give a very general solution but works great under NT and the
code can run fine in Win98.  It only gets messy when the multiple threads
have to access the same data, that is, if the changes made by one thread
depend on the changes made by the other thread.  Then the synchronization to
avoid exceptions destroys the performance or exception handling itself
becomes too complicated to manage.  If the core routines can be individually
treated, that's where all the performance gain is anyway.

--
Tim Hutcheson
w4l### [at] bellsouthnet


Ron Parker <par### [at] fwicom> wrote in message
news:374aa7a5.0@news.povray.org...
> On Tue, 25 May 1999 14:30:43 +0200 (CDT), Jan Danielsson wrote:
> >How should a multithreaded povray work?
> >
> >I guess the user specifies how many threads he/she wants, then what?
> >
> >Should the threads render lines, or should it devide to picture in to
> >'imageheight devided by threads' blocks and render them?
>
> Ignoring for a moment how hard any multithreaded design will be to
> implement in practice, I think a thread should always just do whichever
> scanline is next when it gets ready to go.  For one thing, this will
> help minimize the amount of rendered information that is hanging
> around in memory without having been written to the file.  For another,
> it will do a more effective job of balancing the load between the
> threads.  Skyvase, for example, spends most of its time in the bottom
> half of the image.
>
> You could, of course, run a low-resolution test render first and
> assign blocks of the image based on the histogram results.
>
> Okay, now let's stop ignoring how hard a multithreaded design is.  Can
> I ask all of you "we need SMP so we need threads" people what's wrong
> with plain ol' fork?  Yeah, Winblows doesn't support fork natively,
> but that seems like something Mickeysoft should fix.  Or just install
> a real OS on your fancy SMP machine.

Post a reply to this message

On Tue, 25 May 1999 20:37:49 +0200 (CDT), Jan Danielsson wrote:
>[...]
>>Okay, now let's stop ignoring how hard a multithreaded design is.
>
>Are you talking about 'multithreading in general', or 'rewriting povray'?

I'm talking about rewriting povray.

>>Can I ask all of you "we need SMP so we need threads" people what's wrong 
>>with plain ol' fork?
>
>And I ask; what's wrong with threads? (Now ask me what's wrong with forks; We
>could do this until the sun explodes :-)

"What's wrong with forks?"  I asked you first. :)

No, really, the main problem with threads is that POV has a lot of global
variables that are changed during a render.  If you can locate all of them
and make them threadsafe, then you'll be fine.  I did some of this when I
wrote my motion-blur hack, but there are a lot more that didn't affect me 
but would affect an attempt at multithreading.

I have nothing against threads in general; I love the flexibility they give
me (along with asynchronous I/O.)  I just think a forking model would be
easier to implement given what we have to work with, because it copies all
of the variables into another process space for the other processor.

Oh, and sorry if I appeared to imply that you were a Windows programmer.  I
was just trying to defuse the most likely response to my question, not 
necessarily from you.

Post a reply to this message

On 25 May 1999 12:53:38 -0500, Ron Parker wrote:
>And of course it wouldn't 
>run on Win9x, which still seems pretty popular for some reason.

Ron, you're an idiot.  Win9x doesn't support SMP anyway.

Post a reply to this message

On Tue, 25 May 1999 14:48:58 -0500, Tim Hutcheson wrote:
>Certain types of image processing routines are almost trivial to break into
>SMP threads under NT, especially if you can get all the performance from
>just partitioning the image.  It can be done using only a thread control
>structure, ResumeThread, SuspendThread, and Sleep functions and wrappers
>around the needed image processing routines.  Alternating scanlines is
>better because it minimizes paging at the various cache levels.
>
>This doesn't give a very general solution but works great under NT and the
>code can run fine in Win98.  It only gets messy when the multiple threads
>have to access the same data, that is, if the changes made by one thread
>depend on the changes made by the other thread.  Then the synchronization to
>avoid exceptions destroys the performance or exception handling itself
>becomes too complicated to manage.  If the core routines can be individually
>treated, that's where all the performance gain is anyway.

Raytracing in general is very parallelizable.  It's just POV in specific
that's a tough nut to crack, because the design did not anticipate threading.
Fix all of the global variables and other weirdness (like variable reuse) 
and then it would be a fairly easy task.

Post a reply to this message

> Fix all of the global variables and other weirdness (like variable reuse)
> and then it would be a fairly easy task.

Agreed.

But usually you can find some low level which sacrifices generality and
elegance (but avoids the globals problem) in critical routines that can be
threaded to yield 90 percent of the performance improvement without doing a
full-up SMP design.  Kind of a thread-lite approach.  I have had some
surprising results with a little effort on routines that I thought were
impossible to multi-thread, like fuzzy c-means clustering (FCM).  That
involved splitting the image work into two threads, synchronizing completion
and then doing a final pass to merge the results.  But it essentially
doubled the performance with two processors.

I have the source installed, what's a good candidate routine?

regards,

Tim Hutcheson
w4l### [at] bellsouthnet


Ron Parker <par### [at] fwicom> wrote in message
news:374b0039.0@news.povray.org...
> On Tue, 25 May 1999 14:48:58 -0500, Tim Hutcheson wrote:
> >Certain types of image processing routines are almost trivial to break
into
> >SMP threads under NT, especially if you can get all the performance from
> >just partitioning the image.  It can be done using only a thread control
> >structure, ResumeThread, SuspendThread, and Sleep functions and wrappers
> >around the needed image processing routines.  Alternating scanlines is
> >better because it minimizes paging at the various cache levels.
> >
> >This doesn't give a very general solution but works great under NT and
the
> >code can run fine in Win98.  It only gets messy when the multiple threads
> >have to access the same data, that is, if the changes made by one thread
> >depend on the changes made by the other thread.  Then the synchronization
to
> >avoid exceptions destroys the performance or exception handling itself
> >becomes too complicated to manage.  If the core routines can be
individually
> >treated, that's where all the performance gain is anyway.
>
> Raytracing in general is very parallelizable.  It's just POV in specific
> that's a tough nut to crack, because the design did not anticipate
threading.
> Fix all of the global variables and other weirdness (like variable reuse)
> and then it would be a fairly easy task.

Post a reply to this message

On Tue, 25 May 1999 16:24:14 -0500, Tim Hutcheson wrote:
>> Fix all of the global variables and other weirdness (like variable reuse)
>> and then it would be a fairly easy task.
>
>Agreed.
>
>But usually you can find some low level which sacrifices generality and
>elegance (but avoids the globals problem) in critical routines that can be
>threaded to yield 90 percent of the performance improvement without doing a
>full-up SMP design.  Kind of a thread-lite approach.  I have had some
>surprising results with a little effort on routines that I thought were
>impossible to multi-thread, like fuzzy c-means clustering (FCM).  That
>involved splitting the image work into two threads, synchronizing completion
>and then doing a final pass to merge the results.  But it essentially
>doubled the performance with two processors.
>
>I have the source installed, what's a good candidate routine?

That's the problem, there is no good candidate routine.  The best way to 
parallelize POV is by tracing different rays in different threads, but 
it's the code that traces a ray that isn't threadsafe, and the problems
are spread throughout the code.  Somewhere in excess of 90% of the code
is called from within the "trace a ray" function at one time or another.

As an example of some things that aren't thread safe:

o The crackle pattern generates an array of nearby centers to determine 
  where it is within the voronoi diagram.  This array is a global 
  variable and is cached from use to use.  If two threads are rendering
  a crackle pattern at the same time, one could refill this array while
  the other is trying to calculate with it.  If you serialize access to
  it, you may end up serializing some scenes entirely.  If you eliminate
  the caching, you will slow down the trace considerably.

o The area light code saves off the center of the light source into a
  local variable, "fiddles" with it during the calculations, then 
  restores it when it's done.  Hopefully it's obvious why this isn't
  threadsafe.

o The crackle pattern saves the current RNG seed before filling its array, 
  then restores it afterward.  While filling its array, it depends on the 
  sequence of "random" numbers being reproducible.  The black hole warp 
  is similarly dependent.  If one thread came in and grabbed a random
  number while another thread was inside this code, the image would be
  ruined in a very obvious manner.  

o Some code apparently depends on the RNG being repeatable, as one of the
  changes in a recent update was the saving and restoring of the RNG seed
  mentioned in the previous point.  If two or more threads are using the
  same RNG, it will not be repeatable.

o The radiosity code saves some global settings, modifies them, and then 
  restores them later.

o Determine_Apparent_Colour - a very important, central function - saves
  the texture, weight, and light lists before doing whatever it does, then
  restores them afterward.

Post a reply to this message

Interesting...and I see the problem now.  tnx

--
Tim Hutcheson
w4l### [at] bellsouthnet


Ron Parker <par### [at] fwicom> wrote in message
news:374b1d23.0@news.povray.org...
> On Tue, 25 May 1999 16:24:14 -0500, Tim Hutcheson wrote:
> >> Fix all of the global variables and other weirdness (like variable
reuse)
> >> and then it would be a fairly easy task.
> >
> >Agreed.
> >
> >But usually you can find some low level which sacrifices generality and
> >elegance (but avoids the globals problem) in critical routines that can
be
> >threaded to yield 90 percent of the performance improvement without doing
a
> >full-up SMP design.  Kind of a thread-lite approach.  I have had some
> >surprising results with a little effort on routines that I thought were
> >impossible to multi-thread, like fuzzy c-means clustering (FCM).  That
> >involved splitting the image work into two threads, synchronizing
completion
> >and then doing a final pass to merge the results.  But it essentially
> >doubled the performance with two processors.
> >
> >I have the source installed, what's a good candidate routine?
>
> That's the problem, there is no good candidate routine.  The best way to
> parallelize POV is by tracing different rays in different threads, but
> it's the code that traces a ray that isn't threadsafe, and the problems
> are spread throughout the code.  Somewhere in excess of 90% of the code
> is called from within the "trace a ray" function at one time or another.
>
> As an example of some things that aren't thread safe:
>
> o The crackle pattern generates an array of nearby centers to determine
>   where it is within the voronoi diagram.  This array is a global
>   variable and is cached from use to use.  If two threads are rendering
>   a crackle pattern at the same time, one could refill this array while
>   the other is trying to calculate with it.  If you serialize access to
>   it, you may end up serializing some scenes entirely.  If you eliminate
>   the caching, you will slow down the trace considerably.
>
> o The area light code saves off the center of the light source into a
>   local variable, "fiddles" with it during the calculations, then
>   restores it when it's done.  Hopefully it's obvious why this isn't
>   threadsafe.
>
> o The crackle pattern saves the current RNG seed before filling its array,
>   then restores it afterward.  While filling its array, it depends on the
>   sequence of "random" numbers being reproducible.  The black hole warp
>   is similarly dependent.  If one thread came in and grabbed a random
>   number while another thread was inside this code, the image would be
>   ruined in a very obvious manner.
>
> o Some code apparently depends on the RNG being repeatable, as one of the
>   changes in a recent update was the saving and restoring of the RNG seed
>   mentioned in the previous point.  If two or more threads are using the
>   same RNG, it will not be repeatable.
>
> o The radiosity code saves some global settings, modifies them, and then
>   restores them later.
>
> o Determine_Apparent_Colour - a very important, central function - saves
>   the texture, weight, and light lists before doing whatever it does, then
>   restores them afterward.

Post a reply to this message

With next generation of processors and 4-way chip sets coming down the pike,
quad motherboards may begin to show up just like the duals we have around
now and the argument for SMP Povray is going to become very interesting and
compelling...Maybe a major rewrite to do it though, if it can be done.  tnx
agn

--
Tim Hutcheson
w4l### [at] bellsouthnet


Jan Danielsson <Jan### [at] falunmailteliacom> wrote in message
news:wnaqnavryffbasnyhaznvygryvnpbz.fcawr70.pminews@news.povray.org...
> How should a multithreaded povray work?
>
> I guess the user specifies how many threads he/she wants, then what?
>
> Should the threads render lines, or should it devide to picture in to
> 'imageheight devided by threads' blocks and render them?
>
>
>  /j
>
>
>

Post a reply to this message

The majority of these 'cached' variables could be put in the thread's scope
instead of the global scope.  But I had to go and introduce even more global
variables in my photon mapping stuff (so that I could pass values around
without adding more parameters to the existing functions).  Of course, you'd
have to find all of these, but that's not impossible.  In fact, I'm going to
label the ones I make in future releases of the photon patch with the
comment:
  /* not thread safe */
so if you search for that, you'll find them.

-Nathan


Ron Parker wrote:
> 
> On Tue, 25 May 1999 16:24:14 -0500, Tim Hutcheson wrote:
> >> Fix all of the global variables and other weirdness (like variable reuse)
> >> and then it would be a fairly easy task.
> >
> >Agreed.
> >
> >But usually you can find some low level which sacrifices generality and
> >elegance (but avoids the globals problem) in critical routines that can be
> >threaded to yield 90 percent of the performance improvement without doing a
> >full-up SMP design.  Kind of a thread-lite approach.  I have had some
> >surprising results with a little effort on routines that I thought were
> >impossible to multi-thread, like fuzzy c-means clustering (FCM).  That
> >involved splitting the image work into two threads, synchronizing completion
> >and then doing a final pass to merge the results.  But it essentially
> >doubled the performance with two processors.
> >
> >I have the source installed, what's a good candidate routine?
> 
> That's the problem, there is no good candidate routine.  The best way to
> parallelize POV is by tracing different rays in different threads, but
> it's the code that traces a ray that isn't threadsafe, and the problems
> are spread throughout the code.  Somewhere in excess of 90% of the code
> is called from within the "trace a ray" function at one time or another.
> 
> As an example of some things that aren't thread safe:
> 
> o The crackle pattern generates an array of nearby centers to determine
>   where it is within the voronoi diagram.  This array is a global
>   variable and is cached from use to use.  If two threads are rendering
>   a crackle pattern at the same time, one could refill this array while
>   the other is trying to calculate with it.  If you serialize access to
>   it, you may end up serializing some scenes entirely.  If you eliminate
>   the caching, you will slow down the trace considerably.
> 
> o The area light code saves off the center of the light source into a
>   local variable, "fiddles" with it during the calculations, then
>   restores it when it's done.  Hopefully it's obvious why this isn't
>   threadsafe.
> 
> o The crackle pattern saves the current RNG seed before filling its array,
>   then restores it afterward.  While filling its array, it depends on the
>   sequence of "random" numbers being reproducible.  The black hole warp
>   is similarly dependent.  If one thread came in and grabbed a random
>   number while another thread was inside this code, the image would be
>   ruined in a very obvious manner.
> 
> o Some code apparently depends on the RNG being repeatable, as one of the
>   changes in a recent update was the saving and restoring of the RNG seed
>   mentioned in the previous point.  If two or more threads are using the
>   same RNG, it will not be repeatable.
> 
> o The radiosity code saves some global settings, modifies them, and then
>   restores them later.
> 
> o Determine_Apparent_Colour - a very important, central function - saves
>   the texture, weight, and light lists before doing whatever it does, then
>   restores them afterward.

Post a reply to this message

Its been an interesting discussion about the problems with multithreading
the current version of POV.  However, I agree with the point Tim made about
future machines going more and more to SMP (or similar) systems.

In the planning for POV v4, is there any attempt to rewrite the code so that
multithreading could be more easily implemented?  I've caught hints in this
newsgroup that v4 will be recast in C++ so, if that much of a rewrite is
going to occur, wouldn't it make sense to make sure it was multithreadable
too?

--
Jim

Check out my web site http://www.kressworks.com/
It'll blow your mind (politically), stimulate your senses (artistically)
and provide scientific insights that boggle the mind!!


Jan Danielsson wrote in message ...
>How should a multithreaded povray work?
>
>I guess the user specifies how many threads he/she wants, then what?
>
>Should the threads render lines, or should it devide to picture in to
>'imageheight devided by threads' blocks and render them?
>
>
> /j
>
>
>

Post a reply to this message

Spider wrote:

> Ron Parker wrote:
> >
> > And of course it wouldn't
> > run on Win9x, which still seems pretty popular for some reason.
>
> hehe, in my case, I'm running win 95 from the reason of... Size. the installed
> size of 95 compared to either NT workstation(not an alternative due to driver
> problems) and 98 is big. I hope win2k will address this a bit...
>
> don't bother responding to this, since the discussion would probably end up in
> the OS wars. and I'm too OT as it is.

Win2K?? He he he he. Poor guy (not trying to continue an OS war, just bring up a
few facts).

Win2k is just Windows NT 5. They had been hoping to be able to drop the 95 OS and
force everyone up to NT, but it aint going to happen this round. Win9x is alive
for a while. Of course, since Win2K is just NT 5 renamed, you can then take from
that the info that it will require even more resources than NT 4, and thus you
will not be wanting to run that either.

(Not trying to OS bash, but getting frustrated having to program on Windows. Oy,
my head)

Now, as far as size... You might just want to get good ol' Linux on your box (if
by size of the OS you mean performance overhead in general). A couple of months
ago I switched my home system from Win95 to dual boot to Linux and ended up
staying in Linux most the time, especially for POVRay. This was on a 133 w/ 48 MB
RAM.

Oh, and like you I had stayed away from NT (despite having a few legal copies for
home) due to the weakness of my system. Once I put on Linux & Enlightenment it
seemed so much more responsive than with 95 (OSR/2).

(Oh, one other major reason for 9x staying around is becuase of WinNT's
archetecture just not allowing decent performance for games on lower end systems.
But then again, you all already knew that)

I almost forgot. To get things back on topic: Linux, of course, does SMP. And
clustering. (smiling as I dangle these extra carrots). A "Cray-matching Linux
cluster" anyone??? http://slashdot.org/articles/99/03/10/109215.shtml (drool,
drool)

Post a reply to this message

On Tue, 25 May 1999 23:29:39 -0700, "Jon A. Cruz"
<jon### [at] geocitiescom> wrote:

>Of course, since Win2K is just NT 5 renamed, you can then take from
>that the info that it will require even more resources than NT 4, and thus you
>will not be wanting to run that either.

I am running it.  PII/333, 128M RAM.  Barely acceptable performance.
When I had 64M RAM in that machine, it was ridiculously slow and
swapped all the time.

There's a reason the people who pay to be in the "beta program" get a
coupon good for a discount on more memory.

Post a reply to this message

Jim Kress wrote:
> 
> Its been an interesting discussion about the problems with multithreading
> the current version of POV.  However, I agree with the point Tim made about
> future machines going more and more to SMP (or similar) systems.
> 
> In the planning for POV v4, is there any attempt to rewrite the code so that
> multithreading could be more easily implemented?  I've caught hints in this
> newsgroup that v4 will be recast in C++ so, if that much of a rewrite is
> going to occur, wouldn't it make sense to make sure it was multithreadable
> too?
> 
<...>

Hi,
I heard a rumored yes on efforts/thoughts of the POV Team to include SMP
into the rewrite. But don't cite me on that one.
I would bet quite a lot, that such an effort like parallizing POVRay
will be much more simple with 4.0. And that the efforts done on the 3.x
branch would be most presumably lost.

As this point comes up every second week (or was it twice a week),
someone powerfull should explain the special kind of 'maybe' to warp, so
it can be included in the vfaq.

I wonder how much of 4.0 is fixed already. The overall plan posted here
some months ago is propably a bit more precise by now.

Axel

Post a reply to this message

"Ronald L. Parker" wrote:

> On Tue, 25 May 1999 23:29:39 -0700, "Jon A. Cruz"
> <jon### [at] geocitiescom> wrote:
>
> >Of course, since Win2K is just NT 5 renamed, you can then take from
> >that the info that it will require even more resources than NT 4, and thus you
> >will not be wanting to run that either.
>
> I am running it.  PII/333, 128M RAM.  Barely acceptable performance.
> When I had 64M RAM in that machine, it was ridiculously slow and
> swapped all the time.
>
> There's a reason the people who pay to be in the "beta program" get a
> coupon good for a discount on more memory.

Argh!
One year ago I had checked it out on a system with only 32MB (pretty decent at the
time). Just opening Word (not any docs, just Word) caused it to begin almost
constant disk-thrashing. I had hoped they had corrected that. Guess not. Good to
know what practical requirements are (remember Win95 saying '8MB'??? Yeah, right)

With Linux now officially supported, it's looking more and more like a great
choice for POVRay users. And, it does SMP (just to keep things a tiny bit on
topic).

Post a reply to this message

On Wed, 26 May 1999 08:51:05 -0700, Jon A. Cruz wrote:
>Argh!
>One year ago I had checked it out on a system with only 32MB (pretty decent at the
>time). Just opening Word (not any docs, just Word) caused it to begin almost
>constant disk-thrashing. I had hoped they had corrected that. Guess not. Good to
>know what practical requirements are (remember Win95 saying '8MB'??? Yeah, right)

If I shut down all my optional services (apache, rc5des) and everything else, 
the base system takes up somewhere around 75M, according to Task Manager.  
Kernel memory alone is about half that.  So it looks like 96M is a minimal 
system for this version of NT.  Disclaimers: I'm not running the official 
beta 3, but I'm only about 15 builds behind.  I'm also running some under-
development dlls and drivers that will push the total up a bit.  But, as 
you say, we're way off topic here.

Post a reply to this message

Whoppa whoppa..

How glad I am I have Linux up and running, ain't I ?


"Jon A. Cruz" wrote:
> Win2k is just Windows NT 5. They had been hoping to be able to drop the 95 OS and
> force everyone up to NT, but it aint going to happen this round. Win9x is alive
> for a while. Of course, since Win2K is just NT 5 renamed, you can then take from
> that the info that it will require even more resources than NT 4, and thus you
> will not be wanting to run that either.
Yep yep.  I sorta know ... It won't go too well wit ha lower end system either..
(I'm running at 200Mhz)

> (Not trying to OS bash, but getting frustrated having to program on Windows. Oy,
> my head)
Welcome to the gang.. I sorta miss the good 'ol' times when I had to use a
hackkk in assembler to get more than 16 Mb avaiable in pascal p-mode.. it was
fun, and I knew what was going on...
 
> Now, as far as size... You might just want to get good ol' Linux on your box (if
> by size of the OS you mean performance overhead in general). A couple of months
> ago I switched my home system from Win95 to dual boot to Linux and ended up
> staying in Linux most the time, especially for POVRay. This was on a 133 w/ 48 MB
> RAM.
Same here. I now have a few other os'es that I dualboot as well (BeOS really is
nice, but it doesn't really do anything.. *hehe*)

> Oh, and like you I had stayed away from NT (despite having a few legal copies for
> home) due to the weakness of my system. Once I put on Linux & Enlightenment it
> seemed so much more responsive than with 95 (OSR/2).
Well, I had a illegal NT4 copy here as a test.. Can't say it worked all that
great, esp. not with my hardware... it really complained and misbehaved a lot.
fdisk again and bye bye NT.

> (Oh, one other major reason for 9x staying around is becuase of WinNT's
> archetecture just not allowing decent performance for games on lower end systems.
> But then again, you all already knew that)
Yep. And here Linux is really ruling things.
 
> I almost forgot. To get things back on topic: Linux, of course, does SMP. And
> clustering. (smiling as I dangle these extra carrots). A "Cray-matching Linux
> cluster" anyone??? http://slashdot.org/articles/99/03/10/109215.shtml (drool,
> drool)
Yes... I seem to recall a lot of cluster networks using linux in the past year
or so. always interesting.. perhaps I'll go for it if I get my hands on some
more pc's.. or perhaps not ;)

-- 
//Spider    --  [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
And the meek'll inherit what they damn well please
	Get ahead, go figure, go ahead and pull the trigger
		Everything under the gun
			--"Sisters Of Mercy" -- "Under The Gun"

Post a reply to this message

Ron Parker wrote:

> On Wed, 26 May 1999 08:51:05 -0700, Jon A. Cruz wrote:
> >Argh!
> >One year ago I had checked it out on a system with only 32MB (pretty decent at the
> >time). Just opening Word (not any docs, just Word) caused it to begin almost
> >constant disk-thrashing. I had hoped they had corrected that. Guess not. Good to
> >know what practical requirements are (remember Win95 saying '8MB'??? Yeah, right)
>
> If I shut down all my optional services (apache, rc5des) and everything else,
> the base system takes up somewhere around 75M, according to Task Manager.
> Kernel memory alone is about half that.  So it looks like 96M is a minimal
> system for this version of NT.  Disclaimers: I'm not running the official
> beta 3, but I'm only about 15 builds behind.  I'm also running some under-
> development dlls and drivers that will push the total up a bit.  But, as
> you say, we're way off topic here.

One of the things I've heard about MS OS's is that they use whatever physical memory
you have. That is, if you have the memory, the OS will go ahead and utilize it untill
some apps need it, then get paged out. The real test seems to be what is the point
that it starts excessive swapping.

Post a reply to this message

Wasn't there something in the news recently about Linux getting blobbered by NT on a
Quad Xeon machine?

Last I heard the rebels were regrouping on endor...

-Mike

> I almost forgot. To get things back on topic: Linux, of course, does SMP. And
> clustering. (smiling as I dangle these extra carrots). A "Cray-matching Linux
> cluster" anyone??? http://slashdot.org/articles/99/03/10/109215.shtml (drool,
> drool)

Post a reply to this message

On Thu, 27 May 1999 01:49:08 -0500, Mike wrote:
>Wasn't there something in the news recently about Linux getting blobbered by NT on a
>Quad Xeon machine?
>
>Last I heard the rebels were regrouping on endor...

You don't want to bring that up.  Really.

Post a reply to this message

OK, I promise - no more star wars threads. ;)

-Mike

Ron Parker wrote:

> >Last I heard the rebels were regrouping on endor...
>
> You don't want to bring that up.  Really.

Post a reply to this message

I farted around with my own SMP raytracer and, while RT is theoretically
easy to parallelize, in practice its much harder (of course, maybe I'm too
dense to figure out the right way). Avoiding malloc is very important to
rendering speed so you need pools of pre-alloc'd temporaries. Thread-safing
these pools is fairly costly. The best solution I found is to use MSVC's TLS
storage since it only uses an FS: instruction to access TLS data. This is
non-portable in the extreme so its out for POVRay.

The # of threads should be automatically determined by the # of processors
installed.

The best answer is for a thread to start rendering the next free line. The
problems start when antialiasing. Again I my be dense but in my aa code I
reuse the topmost subpixels in a line while subdividing to avoid
recalculating the same ray. This creates a linkage between lines which
requires thread-safing and/or buffering. Since the reason for SMP is a speed
advantage, this thread-safing gets in the way.

Mutithreaded initialization is another, less important area. Some time is
spent crunching heightfields and other objects so that tracing is faster.
Photon mapping would benefit the most here. This would be a low priority
item.

There are other issues like random number generation that can affect output
images between single and multithreaded implementations. This would be last
on my list of issues, though.

Mike


Jan Danielsson <Jan### [at] falunmailteliacom> wrote in message
news:wnaqnavryffbasnyhaznvygryvnpbz.fcawr70.pminews@news.povray.org...
> How should a multithreaded povray work?
>
> I guess the user specifies how many threads he/she wants, then what?
>
> Should the threads render lines, or should it devide to picture in to
> 'imageheight devided by threads' blocks and render them?
>
>
>  /j
>
>
>

Post a reply to this message

No, they use at least 16Mb, and if you have more it will use 50% of it.
(I'vetested to get this numbers, not guessing or secondhand info. Brutal "remove
a chipp, reboot, look and see" )

"Jon A. Cruz" wrote:
> 
> Ron Parker wrote:
> 
> > On Wed, 26 May 1999 08:51:05 -0700, Jon A. Cruz wrote:
> > >Argh!
> > >One year ago I had checked it out on a system with only 32MB (pretty decent at
the
> > >time). Just opening Word (not any docs, just Word) caused it to begin almost
> > >constant disk-thrashing. I had hoped they had corrected that. Guess not. Good to
> > >know what practical requirements are (remember Win95 saying '8MB'??? Yeah, right)
> >
> > If I shut down all my optional services (apache, rc5des) and everything else,
> > the base system takes up somewhere around 75M, according to Task Manager.
> > Kernel memory alone is about half that.  So it looks like 96M is a minimal
> > system for this version of NT.  Disclaimers: I'm not running the official
> > beta 3, but I'm only about 15 builds behind.  I'm also running some under-
> > development dlls and drivers that will push the total up a bit.  But, as
> > you say, we're way off topic here.
> 
> One of the things I've heard about MS OS's is that they use whatever physical memory
> you have. That is, if you have the memory, the OS will go ahead and utilize it
untill
> some apps need it, then get paged out. The real test seems to be what is the point
> that it starts excessive swapping.

-- 
//Spider    --  [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
And the meek'll inherit what they damn well please
	Get ahead, go figure, go ahead and pull the trigger
		Everything under the gun
			--"Sisters Of Mercy" -- "Under The Gun"

Post a reply to this message

Ronald L. Parker wrote in message <374be437.44517686@news.povray.org>...
>On Tue, 25 May 1999 23:29:39 -0700, "Jon A. Cruz"
><jon### [at] geocitiescom> wrote:
>
>>Of course, since Win2K is just NT 5 renamed, you can then take from
>>that the info that it will require even more resources than NT 4, and thus
you
>>will not be wanting to run that either.
>
>I am running it.  PII/333, 128M RAM.  Barely acceptable performance.
>When I had 64M RAM in that machine, it was ridiculously slow and
>swapped all the time.
>
>There's a reason the people who pay to be in the "beta program" get a
>coupon good for a discount on more memory.
>

I had heard about its deadful minimal requirements (PII/300 + 128 MB) but I
was hoping
they were not true. So I will stick to Nt4+ Linux even on the PII/400 I am
in the process of buying.
By the way, do you know that I work almost well with Linux on a 486/DX4
(i.e. about a Pentium 75)
with 64 MB?

Post a reply to this message