Hi!

I would like to make PovRay faster ( and did it also, see 3D!Now ) and I
read the discussion about PovRay and OpenGL. So I thought about the
possibility to make PovRay with different methods of rendering. One would be
the normal, using double precision, precise & slow, the other would be the
fast, using single precision, not so precise but fast. Beause of that reason
I would like to make all necessary C files. They would contain all vector,
matricies and color calculations ( crosproduct, scale, add, sub, div, mul,
invers, linearcombination, square root, sin, cos, tan, exp, spuare etc.; all
of the function/macros which are in colour.c/h, matricies.c/h and vector.c/h
+ some additional functions/macros). But first I want to talk with the
PovRay team so this could be in the official PovRay. So how can I contact
them?

Post a reply to this message

Daniel Jungmann wrote:
> 
> Hi!
> 
> I would like to make PovRay faster ( and did it also, see 3D!Now ) and I
> read the discussion about PovRay and OpenGL. So I thought about the
> possibility to make PovRay with different methods of rendering. One would be
> the normal, using double precision, precise & slow, the other would be the
> fast, using single precision, not so precise but fast. Beause of that reason
> I would like to make all necessary C files. They would contain all vector,
> matricies and color calculations ( crosproduct, scale, add, sub, div, mul,
> invers, linearcombination, square root, sin, cos, tan, exp, spuare etc.; all
> of the function/macros which are in colour.c/h, matricies.c/h and vector.c/h
> + some additional functions/macros). But first I want to talk with the
> PovRay team so this could be in the official PovRay. So how can I contact
> them?

The first thing would probably to contact the TAG about that, they can
forward your suggestions.  Anyway, it probably will not be included in
Povray 3.5 so it could be a better idea to incorporate it into a version
of megapov based on 3.5.  

Concerning the idea itself, as someone already mentioned, single precision
is not much faster than double (although memory use is lower of course)
and therefore it would be only much difference if it used new features
like 3D!Now which would be problematic for portability reasons.  

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

> Concerning the idea itself, as someone already mentioned, single precision
> is not much faster than double (although memory use is lower of course)
> and therefore it would be only much difference if it used new features
> like 3D!Now which would be problematic for portability reasons.

3D!Now and other features make PovRay realy faster ( 50%++, but more then
200% is possible) and I said that you should choise ( in the programm
itselfs, at runtime ) to use fast single precision or slow double precision.
Every new AMD & Intel processor supports SIMD instructions ( SIMD = single
instruction multible data, e. g. 3D!Now or SSE ) and if the processor
doesn't supports this you must not use them. For example if you have an
Pentium II which doesn't have 3D!Now or SSE then the programm ( PovRay )
don't let you render the scene with single precision. I know this looks like
a lot of work, but I don't think so. I did not need 30h to convert most of
the colour calculation of PovRay from "normal" to 3D!Now. I would do the
"fast" version for 3D!Now, 3D!NowEx, SSE and SSE2 alone, that is no problem
for me. And the support is no OS problem, just the processor must support
the instruction and if it doesn't you can always render with double
precision. I hope you can understand, because my english is not so good.

Post a reply to this message

Daniel Jungmann wrote:
> 
> 3D!Now and other features make PovRay realy faster ( 50%++, but more then
> 200% is possible) and I said that you should choise ( in the programm
> itselfs, at runtime ) to use fast single precision or slow double precision.
> Every new AMD & Intel processor supports SIMD instructions ( SIMD = single
> instruction multible data, e. g. 3D!Now or SSE ) and if the processor
> doesn't supports this you must not use them. For example if you have an
> Pentium II which doesn't have 3D!Now or SSE then the programm ( PovRay )
> don't let you render the scene with single precision. I know this looks like
> a lot of work, but I don't think so. I did not need 30h to convert most of
> the colour calculation of PovRay from "normal" to 3D!Now. I would do the
> "fast" version for 3D!Now, 3D!NowEx, SSE and SSE2 alone, that is no problem
> for me. And the support is no OS problem, just the processor must support
> the instruction and if it doesn't you can always render with double
> precision. I hope you can understand, because my english is not so good.

No problem with the english, but remember that Povray is not only used on
x86 machines, but also on Mac, Amiga, Sparc, Alpha, ... just to mention
some.  It's a main goal of the Pov-Team to maintain usability for
different platforms which right now is supported through portable c code.
So even if 3D!Now & co were supported by all PC C-Compilers (most
important gcc) this would not be enough.  

Of course you could add a whole lot of '#ifdef' to avoid such problems,
but that would be quite difficult to modify the code, becuase it would
essentially mean two code bases in some parts.  

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

> Of course you could add a whole lot of '#ifdef' to avoid such problems,
> but that would be quite difficult to modify the code, becuase it would
> essentially mean two code bases in some parts.

Why not just make a special, PC-optimized SIMD compile and offer it as a
separate patch? That way, you could optimize all you want, and forget about
users of other platforms. Then, when POV 4.0 comes around, we just merge
your compile in with the standard.

Post a reply to this message

On 2001-01-29 20:02, Daniel Jungmann <DSJ### [at] gmxnet> wrote:
>> new features like 3D!Now which would be problematic for portability
>> reasons.
>
>Every new AMD & Intel processor supports SIMD instructions ( SIMD =
>single instruction multible data, e. g. 3D!Now or SSE ) and if the
>processor doesn't supports this you must not use them. For example
>if you have an Pentium II which doesn't have 3D!Now or SSE then
>the programm ( PovRay ) don't let you render the scene with single
>precision. I know this looks like a lot of work, but I don't think
>so. I did not need 30h to convert most of the colour calculation of
>PovRay from "normal" to 3D!Now. I would do the "fast" version for
>3D!Now, 3D!NowEx, SSE and SSE2 alone, that is no problem for me. And
>the support is no OS problem, just the processor must support the
>instruction

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.

    	hp

-- 
   _  | Peter J. Holzer    | All Linux applications run on Solaris,
|_|_) | Sysadmin WSR       | which is our implementation of Linux.
| |   | hjp### [at] wsracat      | 
__/   | http://www.hjp.at/ |	-- Scott McNealy, Dec. 2000

Post a reply to this message

Daniel Jungmann wrote:

> I would like to make PovRay faster ( and did it also, see 3D!Now ) and I
> read the discussion about PovRay and OpenGL. So I thought about the
> possibility to make PovRay with different methods of rendering. One would be
> the normal, using double precision, precise & slow, the other would be the
> fast, using single precision, not so precise but fast. Beause of that reason
> I would like to make all necessary C files. They would contain all vector,
> matricies and color calculations ( crosproduct, scale, add, sub, div, mul,
> invers, linearcombination, square root, sin, cos, tan, exp, spuare etc.; all
> of the function/macros which are in colour.c/h, matricies.c/h and vector.c/h
> + some additional functions/macros). But first I want to talk with the
> PovRay team so this could be in the official PovRay. So how can I contact
> them?

I think if you do this it should be a patch or something. I don't like the idea
of official POV becoming bloatware. Would it not add considerably to the
program?

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

Christoph Hormann wrote:

> No problem with the english, but remember that Povray is not only used on
> x86 machines, but also on Mac, Amiga, Sparc, Alpha, ... just to mention
> some.  It's a main goal of the Pov-Team to maintain usability for
> different platforms which right now is supported through portable c code.
> So even if 3D!Now & co were supported by all PC C-Compilers (most
> important gcc) this would not be enough.

No problem with Macs... I would _love_ to see a Velocity Engine (on the G4)
version of POV-Ray, which is not possible without using single precision.  In
terms of the Sparc or Alpha, well, ... maybe keep the official source the way it
is, and put these fun new speedups in the platform-specific versions.

...Chambers

Post a reply to this message

David Fontaine wrote:

> I think if you do this it should be a patch or something. I don't like the idea
> of official POV becoming bloatware. Would it not add considerably to the
> program?

You are right, it would add considerably to POV-Ray... It would add the number of
pixels I can render in the same amount of time!!!
By all means, speed it up!!! =)
...Chambers

Post a reply to this message

Ben Chambers wrote:

> You are right, it would add considerably to POV-Ray... It would add the number of
> pixels I can render in the same amount of time!!!
> By all means, speed it up!!! =)
> ...Chambers

If you want roundoff error.

<duck> Same reason CDs suck. <cover>

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

On Mon, 29 Jan 2001 20:44:18 -0600, David Fontaine wrote:
><duck> Same reason CDs suck. <cover>

What, that old canard again?

That's not why CDs are said to suck.  The impossibly gifted people who
claim vinyl sounds better are claiming that the linear scale used to
digitize the music is a poor match for the logarithmic scale our ears 
actually hear on.  This has nothing to do with roundoff error.

Followups to povray.off-topic. :)

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

Post a reply to this message

Hear, hear! I think it's time we POVers got more serious about speed. We
*need* platform-specific versions. Each platform would have a
Platform-Specific (PS) POV-Team, and the main POV-Team would work just like
it does now. When they release the generic version, the PSPOV-Teams get to
work tweaking and improving the regular POV-Ray. I volunteer for the
VaporWare®-Team. :)

Post a reply to this message

Ron Parker wrote:

> Followups to povray.off-topic. :)

? <G>

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

On Mon, 29 Jan 2001 22:23:05 -0600, Tony[B] wrote:
>Hear, hear! I think it's time we POVers got more serious about speed. We
>*need* platform-specific versions. Each platform would have a
>Platform-Specific (PS) POV-Team, and the main POV-Team would work just like

We have those.  How do you think the Windows and Mac versions got those neato
GUIs?

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

Post a reply to this message

> We have those.  How do you think the Windows
> and Mac versions got those neato GUIs?

Erm, I kinda meant in the direction of hardware-specific optimizations, not
so much GUI.

Post a reply to this message

"Tony[B]" wrote:
> 
> > We have those.  How do you think the Windows
> > and Mac versions got those neato GUIs?
> 
> Erm, I kinda meant in the direction of hardware-specific optimizations, not
> so much GUI.

And thus the reason Chris Cason offers two compiles for Windows. One with
Watcom the other MSVC6++ both pentium II optimized. The price of each of
these two compilers is not cheap and requires that the developer has access
to equipment with archetecture the compiler is optimized for.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

As there is no OT I will try to make this a short lived thread.

Ron Parker wrote:

> What, that old canard again?
>
> That's not why CDs are said to suck.  The impossibly gifted people who
> claim vinyl sounds better are claiming that the linear scale used to
> digitize the music is a poor match for the logarithmic scale our ears
> actually hear on.  This has nothing to do with roundoff error.

Aside from that, any mathematician will tell you the sample rate is
insufficient. The highest frequency a person can hear is around 20kHz. The
sample rate of a CD is 44kHz. It should be at least double that, 5x the
highest frequency. Think about it, you could be sampling near the zero
point every time.

And records sound better <g> ;)

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


> Followups to povray.off-topic. :)

;)

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

David Fontaine wrote:

> > That's not why CDs are said to suck.  The impossibly gifted people who
> > claim vinyl sounds better are claiming that the linear scale used to
> > digitize the music is a poor match for the logarithmic scale our ears
> > actually hear on.  This has nothing to do with roundoff error.
>
> Aside from that, any mathematician will tell you the sample rate is
> insufficient. The highest frequency a person can hear is around 20kHz. The
> sample rate of a CD is 44kHz. It should be at least double that, 5x the
> highest frequency. Think about it, you could be sampling near the zero
> point every time.

That is of course not to imply that I agree linear scales lead to roundoff
error. I'd be somewhat hard to convince 65536 volume intervals is
insufficient. :)

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

> That's not why CDs are said to suck.  The impossibly gifted people who
> claim vinyl sounds better are claiming that the linear scale used to
> digitize the music is a poor match for the logarithmic scale our ears 
> actually hear on.  This has nothing to do with roundoff error.
> 

Well actually the problem has to do with the repeated processing
of a digital audio signal. The more effects ie. reverb, flange
etc. the more the rounding error adds up and becomes a kind of
distortion which IS audible. But your not going to hear the differnce
on your home stereo so much, however if you have a pro studio and
a set of nice reference monitors there is a difference.

Another thing you would notice is the lack of bottom end from the
vinyl. Bass frequencies are often rolled off in mastering because
it can cause the needle to jump right out of the groove. I used to
tape pennies above the needle to add some extra weight on for this
reason.


-- 
Phil
...coffee?...yes please! extra sugar,extra cream...Thank you.

Post a reply to this message

On Mon, 29 Jan 2001 22:52:47 -0600, David Fontaine wrote:
>Aside from that, any mathematician will tell you the sample rate is
>insufficient. The highest frequency a person can hear is around 20kHz. The
>sample rate of a CD is 44kHz. It should be at least double that, 5x the
>highest frequency. Think about it, you could be sampling near the zero
>point every time.

Careful... I am a mathematician, though I don't practice anymore.  The
Nyquist Theorem says a sampling frequency of twice the highest expected
frequency is sufficient to recreate anything at or below that expected
frequency.  Thus, CDs can accurately reproduce sounds at 22050 Hz and 
below.

It is important, though, to filter out anything above 22050 Hz before 
the digitizing stage, due to aliasing.  I suspect most professionals do
so as a matter of course.

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

Post a reply to this message

> 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

Ron Parker wrote:
> 
> On Mon, 29 Jan 2001 22:52:47 -0600, David Fontaine wrote:
> >Aside from that, any mathematician will tell you the sample rate is
> >insufficient. The highest frequency a person can hear is around 20kHz. The
> >sample rate of a CD is 44kHz. It should be at least double that, 5x the
> >highest frequency. Think about it, you could be sampling near the zero
> >point every time.
> 
> Careful... I am a mathematician, though I don't practice anymore.  The
> Nyquist Theorem says a sampling frequency of twice the highest expected
> frequency is sufficient to recreate anything at or below that expected
> frequency.  Thus, CDs can accurately reproduce sounds at 22050 Hz and
> below.
> 
> It is important, though, to filter out anything above 22050 Hz before
> the digitizing stage, due to aliasing.  I suspect most professionals do
> so as a matter of course.

Careful... I am a "electronician", though I don't practice analog 
electronics anymore.  ;-)

This is one of the problems with CD players:

It's difficult to design good and cheap 
filters that has a very sharp cut-off 
frequency that lies right above this 
22 kHz frequency.

But if the sampling frequency had been chosen 
higher for CD's, then one could have used 
cheaper and more "relaxed" filters with higher 
cut off frequencies that would not make 
distortions to the sound (within the "audible"
range).


-- 
Best regards,

Tor Olav

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

Post a reply to this message

On Tue, 30 Jan 2001 21:21:10 +0100, Tor Olav Kristensen wrote:
>> 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.

Unfortunately, without the needle to push the dust out of the way,
they also sound much worse.

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

Post a reply to this message

On Tue, 30 Jan 2001 21:37:57 +0100, Tor Olav Kristensen wrote:
>This is one of the problems with CD players:

Not with CD players, per se, since the filtering should happen in the 
studio, but it is a problem.

>It's difficult to design good and cheap 
>filters that has a very sharp cut-off 
>frequency that lies right above this 
>22 kHz frequency.

I'd considered mentioning that, but left it out so as to not make an 
already off-topic conversation even more so.  (I don't have a degree
or anything in electronics, but the FCC did see fit to grant me a 
radio amateur's license lo these many years ago.)

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

Post a reply to this message

in <slr### [at] fwicom> Ron Parker wrote:

>Unfortunately, without the needle to push the dust out of the way,
>they also sound much worse.

What? You don't have a Nitty Gritty Record Cleaning Machine??

http://www.lowther.nl/wwwpages/nitty.html

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

Ron Parker wrote:
> 
> On Tue, 30 Jan 2001 21:37:57 +0100, Tor Olav Kristensen wrote:
> >This is one of the problems with CD players:
> 
> Not with CD players, per se, since the filtering should happen in the
> studio, but it is a problem.

You may search for the this sentence:

"The need for placing a filter after the DAC in 
the player may not be intuitively obvious."

(Within the Aliasing section.)

at this page:

http://www.totse.com/en/technology/science_technology/cd_audio.html

to get an explanation of why such a filter
also are necessary in a CD-player.


> >It's difficult to design good and cheap
> >filters that has a very sharp cut-off
> >frequency that lies right above this
> >22 kHz frequency.

But I wasn't quite right about it STILL 
being difficult to perform this filtering 
in todays CD players. (See the "Digital-to
-analog Converters" section in the same 
document.)

DSPs seems to be the solution now.


Best regards,

Tor Olav

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

Post a reply to this message

Ron Parker wrote:

> Careful... I am a mathematician, though I don't practice anymore.  The
> Nyquist Theorem says a sampling frequency of twice the highest expected
> frequency is sufficient to recreate anything at or below that expected
> frequency.

I don't buy it.

http://members.aol.com/ajaynejr/nyquist.htm

This is about video but much of it can apply to audio as well.

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

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

As someone who owns an Athlon machine I consider that a silly question :)

Besides there are now more than just one person using this CPU. Lots of
people are buying them.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

I often have to finish all part of my code or the next day I show up at work
I spend a few hours just to get the hang of where I was..............

BR.Saadat

"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3A76F066.BDA07E2F@gmx.de...
>
>
> 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

Alessandro Coppo <a.c### [at] iolit> wrote:
: Was ever POV put under profiling to look for hotspots?

  I have done that, but didn't find anything easy to optimize.

  Perhaps I'll try it again some day.

: 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.

  This happens probably to almost everyone. In a half year you learn so much
that you would have done the same code much better if you had known.

-- 
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

Ken <tyl### [at] pacbellnet> wrote:
: As someone who owns an Athlon machine I consider that a silly question :)

  Sure, but I don't own one, so I wouldn't get any benefit from this kind
of patch... ;)

-- 
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

In article <slr### [at] fwicom> , ron### [at] povrayorg (Ron
Parker) wrote:

> Unfortunately, without the needle to push the dust out of the way,
> they also sound much worse.

Mount a small fan in fron of the optical reader ;-)


     Thorsten

Post a reply to this message

In article <3A777C01.EFB12667@pacbell.net> , Ken <tyl### [at] pacbellnet>  
wrote:

> As someone who owns an Athlon machine I consider that a silly question :)
>
> Besides there are now more than just one person using this CPU. Lots of
> people are buying them.

Yes, but who handles all the support coming from more than _one_ version?
If you offer something like ten versions optimised for the ten (or more) x86
processors in common use today, and half of them are slow on another four
and do not run on the other five of the ten processors, you will have a lot
of confused users.  Remember that not everybody knows what processor they
use - why should a user know?


      Thorsten

Post a reply to this message

In article <3a77e52a@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   I have done that, but didn't find anything easy to optimize.
>
>   Perhaps I'll try it again some day.
>
> : 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.
>
>   This happens probably to almost everyone. In a half year you learn so much
> that you would have done the same code much better if you had known.

You are right, this happens to me all the time, too.  Not to mention that
the quality of the code usually increases with the understanding of the
problem, which is usually better after one has worked on the problem for a
few month.


     Thorsten

Post a reply to this message

> Yes, but who handles all the support coming from more than _one_ version?
> If you offer something like ten versions optimised for the ten (or more)
x86
> processors in common use today, and half of them are slow on another four
> and do not run on the other five of the ten processors, you will have a
lot
> of confused users.  Remember that not everybody knows what processor they
> use - why should a user know?
>
>
>       Thorsten

That is realy no problem! The program can find out which CPU is there and
load a DLL which renders the scene file. Or you can find out the processor
at instalation time and install the right exe.

Post a reply to this message

On Wed, 31 Jan 2001 15:19:24 +0100, Daniel Jungmann wrote:
>That is realy no problem! The program can find out which CPU is there and
>load a DLL which renders the scene file. Or you can find out the processor
>at instalation time and install the right exe.

What's a DLL?  One of our primary goals is to keep the core code platform
independent.  This doesn't bode well for big piles of #ifdefs and such,
and it pretty much nixes any idea of using dynamically loaded code, which 
doesn't exist on every platform we support.

The detect-CPU-at-install method doesn't work if you upgrade your computer
a piece at a time (frex, the computer I have now is a K6-2/350, but three
months ago it was a K6/233, and a year or two before that it was a 486SLC2/66.
The hard drive has also been replaced, but not at the same time as either 
of the processors.)

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

Post a reply to this message

In article <3a781e9c@news.povray.org> , "Daniel Jungmann" <DSJ### [at] gmxnet> 
wrote:

> That is realy no problem! The program can find out which CPU is there and
> load a DLL which renders the scene file.

So people would have to download 1.5*10 + 5 = 20 MB of files?


     Thorsten

Post a reply to this message

> So people would have to download 1.5*10 + 5 = 20 MB of files?

1. You can compress these files.
2. You can choose wich you need for your processor.
3. PovRay would check every time you start the processor and it something
had changed it would tell you where you can get the "correct" version for
your processor.

That is realy no problem!

Post a reply to this message

On 2001-01-30 15:04, Daniel Jungmann <DSJ### [at] gmxnet> wrote:
>> 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.
>>
>> 2) You have a compiler which can generate 3D!Now code, if the C code
>>    follows a certain pattern.
>>
>> 3) You used inline assembly.
>
>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!
>

I have trouble interpreting this sentence. Can you repeat in German? :-)

If I understood it correctly, quite the reverse is true.

For possibility 1 you need only the time to recompile the source - a
few minutes. (Unless you have to write the compiler first, but I didn't
think you did that).

For possibility 3 you need to analyse povray source code to see where
you can speed it up and replace C code by inline assembly. That's quite
a bit of work (you wrote something about 30 hours, IIRC), it must be
repeated for every CPU type (and possibly compiler), and everybody else
who is going to maintain that code in the future will have more work,
too.

	hp

-- 
   _  | Peter J. Holzer    | All Linux applications run on Solaris,
|_|_) | Sysadmin WSR       | which is our implementation of Linux.
| |   | hjp### [at] wsracat      | 
__/   | http://www.hjp.at/ |	-- Scott McNealy, Dec. 2000

Post a reply to this message

On 2001-01-31 15:15, Thorsten Froehlich <tho### [at] trfde> wrote:
>In article <3a781e9c@news.povray.org> , "Daniel Jungmann" <DSJ### [at] gmxnet> 
>wrote:
>
>> That is realy no problem! The program can find out which CPU is there and
>> load a DLL which renders the scene file.
>
>So people would have to download 1.5*10 + 5 = 20 MB of files?

How did you compute that?

The code segment of povray for linux/intel is about 550 kB. Following
the rule of thumb that 90 percent of the time is spent in 10 % of the
code, a dll with the time critical routines would be about 55 kB. So for
each supported processor variant the executable package would increase
by about 55 kB.

Of course this assumes that the time critical routines can be moved to a
dll. It is possible that these code fragments are so short that function
calls (as opposed to inlining) add more overhead than can be saved by
carefully hand-crafting them in assembler.

I am also ignoring the trouble of generating and loading dlls on
different platforms since these optimizations are platform dependent
anyway.

	hp


-- 
   _  | Peter J. Holzer    | All Linux applications run on Solaris,
|_|_) | Sysadmin WSR       | which is our implementation of Linux.
| |   | hjp### [at] wsracat      | 
__/   | http://www.hjp.at/ |	-- Scott McNealy, Dec. 2000

Post a reply to this message

In article <slr### [at] tealhhjpat> , 
hjp### [at] SiKituwsracat (Peter J. Holzer) wrote:

> The code segment of povray for linux/intel is about 550 kB. Following
> the rule of thumb that 90 percent of the time is spent in 10 % of the
> code, a dll with the time critical routines would be about 55 kB. So for
> each supported processor variant the executable package would increase
> by about 55 kB.

pvengine.exe (at least the VC 6 one) is 1622016 bytes.  On the Mac you get
about the same size.

> Of course this assumes that the time critical routines can be moved to a
> dll. It is possible that these code fragments are so short that function
> calls (as opposed to inlining) add more overhead than can be saved by
> carefully hand-crafting them in assembler.

The question is how much overhead does calling DLL function introduce?  At
least on Macs a shared library call is done by addressing the function via a
table. In total about 10 instructions. For simple operations this would
eliminate the benefit.  Plus, vector and color math are not done with
functions in POV-Ray (they are C macros).  This benefit together with the
compiler optimisations that come along with it would be lost.

> I am also ignoring the trouble of generating and loading dlls on
> different platforms since these optimizations are platform dependent
> anyway.

True.


    Thorsten

Post a reply to this message