> It is also a compiler problem. You didn't say which compiler you used or
> how you got it to produce 3D!Now code. Essentially there are 3
> possibilities:
>
> 1) You have a compiler which can generate 3D!Code out of "natural" C
>     code. This is the ideal case. The same code can be used for 3D!Now
>     platforms and for others.
>
> 2) You have a compiler which can generate 3D!Now code, if the C code
>    follows a certain pattern. This lets you still write portable C code,
>    but it may be arranged unintuitively and therefore hard to maintain
>    and even slower than the "natural" code on other platforms.
>
> 3) You used inline assembly. This is very compiler specific. gcc
>     definitely uses a different syntax than VC++, and what I remember
>     from my DOS programming days, there were differences between MS C
>     and Borland C, too. This means a lot of code duplication: Not only
>     for different processor types, but for different compilers, too.
>
>     So, just to maintain the 4 types of SIMD instructions you mentioned,
>     on the main Intel platforms, you may have to maintain 9 or 13
>     versions of the same code! And not only you have to maintain it, but
>     everybody else who wants to change anything in the affected code.
>     Unless this is very localized, the chances that somebody who wants
>     to implement a new pattern or media type, has to worry about some
>     assembler code he can't even read, seem high to me.

The question is not 1, 2 or 3, the question is for answer 3 you need not
verry mucht time, but answer 1 is also possible, but verry much more work!

Post a reply to this message

I also want to say that PovRay has a lot of "speed bugs". The plain C code
is not very fast. You can speed it up without using 3D!Now etc., just
programming a little different!

Post a reply to this message

Daniel Jungmann wrote:
> 
> I also want to say that PovRay has a lot of "speed bugs". The plain C code
> is not very fast. You can speed it up without using 3D!Now etc., just
> programming a little different!

I'm sure there are possibilities and some parts of the code are quite old
and nobody understands them any more :-) But remember that the Pov-Team is
right now working on a new version that will not only contain new features
but also optimize existing things.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Is it worth the efforts to make this huge amount of work just to
optimize one executable binary for one CPU?

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

On Tue, 30 Jan 2001 17:01:12 +0100, Christoph Hormann wrote:
>
>
>Daniel Jungmann wrote:
>> 
>> I also want to say that PovRay has a lot of "speed bugs". The plain C code
>> is not very fast. You can speed it up without using 3D!Now etc., just
>> programming a little different!
>
>I'm sure there are possibilities and some parts of the code are quite old
>and nobody understands them any more :-) But remember that the Pov-Team is

There's nothing in there that nobody on the POV-Team understands.  Except
for the occasional "I don't understand why they did it this way" sort.

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

Post a reply to this message

Daniel Jungmann <DSJ### [at] gmxnet> wrote:
: The plain C code is not very fast.

  There are three main stages of optimization when optimizing a program:

  1. Optimization of algorithms and data containers. Choosing one algorithm
or data container instead of another can have an enormous effect in
performance.
  I have a very good example of this from my personal experience: The first
version of my triangle mesh compressor used a list data container to store
all the vertex vectors of the triangles. When a new vector was added to the
list, the program searched through the whole list to see if the same vector
was already in there.
  This was very slow. It took more than 2 minutes to read a triangle mesh
with about 40000 smooth triangles.
  Then I decided to replace the list with a binary tree. After that the
program was able to read the same mesh in less than 10 seconds.

  2. Optimization of the code.
  It's quite usual to hear that "you don't need to optimize the code, the
compiler will make it for you much better than you". This is a lie.
  Yes, the compiler can make very good optimizations, but it isn't a genius.
It can't optimize many things that a human can optimize.
  For example this:

    unsigned res = 0;
    for(unsigned i = 1; i <= 10000; ++i) res += i;
    return res;

can be optimized to:

    return 50005000;

  However, it's quite rare that any compiler can do this. I have tested this
with two compilers (gcc and Sun's own cc) and they weren't able to optimize
that loop away (not even with -funroll-loops).
  It's quite clear that the optimized version is extremely much faster than
the unoptimized version.
  There are virtually endless amount of cases where a compiler is unable
to optimize something that can be optimized by hand. Another good example,
very similar to the above, is the following:
  This:

unsigned Sum(unsigned minval, unsigned maxval)
{
    unsigned res = 0;
    for(unsigned i = minval; i <= maxval; ++i) res += i;
    return res;
}

can be optimized to this:

unsigned Sum(unsigned minval, unsigned maxval)
{
    return (maxval-minval+1)*(minval+maxval)/2;
}

  No compiler can do that.


  3. Optimization of the machine code, usually with inline assembler.
This is the last resort when everything else fails and speed in a very
tight loop is critical and there's a cpu-dependant optimization that
the compiler is unable to generate.
  This is usually not a good way to go since it not only makes the
program cpu-dependant (and usually compiler-dependant), but also it
makes the code less maintainable.
  Sometimes you just have to do it (for example the Linux source code
has inline assembler in several places because you can't make everything
with pure C).
  You should only use this kind of optimization when the two first
optimizations have been done and they don't help.

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

Ron Parker wrote:
> 
> There's nothing in there that nobody on the POV-Team understands.  Except
> for the occasional "I don't understand why they did it this way" sort.
> 

I concluded that from the discussion about the mesh code / tesselation
patch.  

Anyway i think 'understanding' is quite a non precise word when talking
about programming.  I often don't understand code i wrote 5 days ago :-)

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Was ever POV put under profiling to look for hotspots?

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

P.S.: I once read some C code and asked myself who had been so idiot to
write it that way. After a few seconds, I remebered. It was me.... six
months before.

Post a reply to this message

>   Is it worth the efforts to make this huge amount of work just to
> optimize one executable binary for one CPU?

IMMHO, yes. If not as official compiles, MegaPOV style patches with
optimizations of this sort would be greatly welcomed by the community (I
don't know about the rest of you, but I sure would like this sort of thing).
Man, I've got to start learning C++...

Post a reply to this message

David Fontaine wrote:
>...
> And records sound better <g> ;)

I think that the lowest bass frequencies on a 
vinyl is only recorded in mono.


> Now if they could just make records that last a decent number of
> playings...

If you read the vinyl optically it will last 
much longer.


-- 
Best regards,

Tor Olav

mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html

Post a reply to this message