On Thu, 01 Feb 2001 15:26:39 +0100, A.B. wrote:
>I think the whole discussion is obsolete. In the time an cpu optimized
>version of POV Ray runs stable and without a few errors more the the
>original version, there is a new processor under which the original POV
>will run faster than the optimised. Therefor I value all the work for
>cpu-optimized POV versions for lost time. 

Except that the optimized version will run still faster under the new
processor than the original version.  There's a place for optimization,
but it has to be done carefully, with an eye to portability.


-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

For 1 I need not to rewrite the compiler, I need to write a lot of macros
( not exactly the same, a lot of work) and I need to analyse the source
code, because the code must bee "parallel" so the SIMD instructions can
work. This changes are "native" C and won't speed down the "normal" version
of PovRay. And a special compiler which supports MMX, 3D!Now and SSE. I just
have a beta version of this compiler, the full version cost 499.-- US
dollar.

Post a reply to this message

I think every new processor will have SIMD instrctions and a
codeoptimization in that direction would speed up PovRay without processor
dependent instructions.

Post a reply to this message

> And a special compiler which supports MMX, 3D!Now and SSE. I just
> have a beta version of this compiler, the full version cost 499.-- US
> dollar.

I am searching around the web for compilers that you can use... I've found
the following

http://www.cs.virginia.edu/~lcc-win32/
Free. Supports MMX and 3DNow.

http://developer.intel.com/software/products/compilers/c50/index.htm
Free for 30 days. Works if you have Visual Studio. Supports all the stuff in
Intel processors.

http://www.codeplay.com/
"VectorC" with support for MMX, 3DNow! and Intel SIMD. Also integrates into
Visual Studio. There doesn't seem to be a free version (that we could use to
compile POV-Ray), but it's cost ranges from $80 for the special version (no
Athlon or Pentium 4 support, slower compiling and less frequent updates), to
$750 for the pro. version. This one if listed on AMD's developer area.

That's pretty much it. I can't find any more free/sharware compilers that
will do optimizations for this stuff you're adding. Keep up the good work!

Post a reply to this message

Thank you, I will try try them.

Post a reply to this message

About the DLL problem (I was already flamed to death in past for this
subject).

DLLs are binary modules which contain code loadable and callable at runtime.
Windows has DLLs. Linux, BSD, Solaris etc.etc. have shared libraries (look
into /usr/lib for all those .so files...). VMS has shared libraries. I
presume that Mac's have a similar mechanism, OSX being a Mach kernel + GNU
tools is in the U*X pack.

The only OS which I know for sure that 1) has a pov version 2) has nothing
like DLLs is MS-DOS. So, should you decide that MSDOS is dead (well,
actually it was never alive...) you can assume that you have the .dll/.so
capability in ANY case.

With respect to optimizations, you should not put too-atomic ops into
separate code, but try to create macro-ops which, even with the added
overhead of call, gain speed (I don't know if it is possible). A proposal
for a custom compile: create a multithreaded engine which can take advantage
of multi CPU boards (render a different set of lines on each CPU and merge
the result.). The speedup would be almost linear (what about a quad 1GHz
Athlon PC?)

Bye!!!

Alessandro Coppo
a.c### [at] iolit

Post a reply to this message

In article <3a79f7f5@news.povray.org>, "Alessandro Coppo" 
<a.c### [at] iolit> wrote:

> DLLs are binary modules which contain code loadable and callable at 
> runtime. Windows has DLLs. Linux, BSD, Solaris etc.etc. have shared 
> libraries (look into /usr/lib for all those .so files...). VMS has 
> shared libraries. I presume that Mac's have a similar mechanism, OSX 
> being a Mach kernel + GNU tools is in the U*X pack.

However, they all do things in their own platform/OS-specific way, so 
you still have to (re)write code for handling the libraries for each 
platform. Handling the Linux/BSD Unix/Mac OS X group might not be too 
difficult, but add in Mac OS versions before and including 9.1, and the 
various Windows versions, and other OS's, and you have a problem. There 
is no standard C mechanism for doing this kind of thing.


> A proposal for a custom compile: create a multithreaded engine which 
> can take advantage of multi CPU boards (render a different set of 
> lines on each CPU and merge the result.). The speedup would be almost 
> linear (what about a quad 1GHz Athlon PC?)

This is a different matter completely...and very difficult to do 
properly, because POV-Ray was never designed to have multiple threads. 
Even if you ignore cross-platform differences, you have problems getting 
it to share data among the different threads properly (for example, 
radiosity, maybe photon maps, etc.). If you don't do this, you end up 
with visible artifacts where parts of the image rendered on different 
threads join together. You would need to do a lot of reworking on the 
source code to get it to work at all.
I think there is a multithreaded version of POV-Ray available (PVM-POV), 
but I don't know much about it, and I don't think it works well with 
radiosity. I don't even know if it does things on a per-image basis, it 
may just distribute different frames to different processors, or give 
different chunks of the image to different processors.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <3a79f7f5@news.povray.org> , "Alessandro Coppo" <a.c### [at] iolit>
wrote:

> About the DLL problem (I was already flamed to death in past for this
> subject).
>
> DLLs are binary modules which contain code loadable and callable at runtime.
> Windows has DLLs. Linux, BSD, Solaris etc.etc. have shared libraries (look
> into /usr/lib for all those .so files...). VMS has shared libraries. I
> presume that Mac's have a similar mechanism, OSX being a Mach kernel + GNU
> tools is in the U*X pack.
>
> The only OS which I know for sure that 1) has a pov version 2) has nothing
> like DLLs is MS-DOS. So, should you decide that MSDOS is dead (well,
> actually it was never alive...) you can assume that you have the .dll/.so
> capability in ANY case.

Nobody said you cannot (easily) overcome the "DLL problem", but you have to
keep POVLegal in mind!

     Thorsten

Post a reply to this message

On Thu, 01 Feb 2001 22:01:10 -0500, Chris Huff <chr### [at] maccom>
wrote:

>I think there is a multithreaded version of POV-Ray available (PVM-POV), 
>but I don't know much about it, and I don't think it works well with 
>radiosity. I don't even know if it does things on a per-image basis, it 
>may just distribute different frames to different processors, or give 
>different chunks of the image to different processors.

If you mean PMP (PVM MegaPOV), it does work with radiosity. Francois
Dispot was so kind as to keep me informed about the progress while he
and the original PVM-POV author were developing it and from what I've
seen, PMP does a pretty decent job with radiosity. It shares octree
data among the slaves. However, all rad calcs have to be done on
preview stage. Luckily, there are rad options to ensure that.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Here's some useful links for 3dNow! optimization:

Part 1 of the tutorial:
http://www.amdzone.com/articleview.cfm?articleID=282

Part 2 of the tutorial:
http://www.pcstats.com/articleview.cfm?articleID=354

Microsoft provides an MSVC++ 6 processor pack for 3DNow:
http://msdn.microsoft.com/vstudio/downloads/ppack/download.asp

Cheers
Rk

Post a reply to this message