 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> My 1.2GHz Athlon renders it in 18sec (didn't bother closing
> other programs while rendering).
> I think 1.4GHz with DDR could render it faster (mine has only
> SDRAM; or whatever it was called... I don't remember anymore).
At the store, they told me, that the support of DDR is not the
best yet, maybe with a new board, i could get better results.
At least I'm within this 18sec. The measurement by "int(seconds)"
isn't that exact anyway... (sigh)
thank you
cukk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Works great - Skyvase went from 24 seconds on my 1G Athlon to 13. Problem
is, all my stuff is done in MegaPOV. Anyone seen an optimized version of
0.7?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4 Sep 2001 03:29:07 -0400, Warp wrote:
>KalleK <kal### [at] gmx de> wrote:
>: I'm down to 17sec, now
>
> My 1.2GHz Athlon renders it in 18sec (didn't bother closing other programs
>while rendering).
> I think 1.4GHz with DDR could render it faster (mine has only SDRAM; or
>whatever it was called... I don't remember anymore).
My 1.4 with 256M of DDR does skyvase in 16 seconds using the 3.5 pre-beta.
I don't have 3.1 installed on this machine. I wondered how much of that time
was spent waiting for disk I/O, so I also rendered with -f instead of +ft,
but it was still about sixteen seconds.
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
: I wondered how much of that time
: was spent waiting for disk I/O, so I also rendered with -f instead of +ft,
: but it was still about sixteen seconds.
I think that even windows caches most disk writes and then flushes the
caches using DMA (ie. no CPU intervention needed) so that it doesn't affect
too much the performance of programs. Of course this AFAIK.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> My 1.4 with 256M of DDR does skyvase in 16 seconds using the
3.5 pre-beta.
> I don't have 3.1 installed on this machine. I wondered how
much of that time
> was spent waiting for disk I/O, so I also rendered with -f
instead of +ft,
> but it was still about sixteen seconds.
Thank you very much for those results to compare - now I just
need 3.5 beta...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> there is a new (second), unofficial Version of POVRAY at
> http://students.washington.edu/sschmitt/pov/ for download. This Version is
> optimized (with support from Intel) for PIII/Athlon and P4.
In case anybody wonders, it is also faster on Pentium II. My trusty old
300MHz PII takes 47 min to run the Chess2 benchmark with the standard
compile, but less than 31 min with Steve Schmitts PIII optimized
compile.
/Ib
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ib Rasmussen <ib### [at] ibrasdk> wrote:
: In case anybody wonders, it is also faster on Pentium II. My trusty old
: 300MHz PII takes 47 min to run the Chess2 benchmark with the standard
: compile, but less than 31 min with Steve Schmitts PIII optimized
: compile.
P-III is practically a P-II with more MHz. There are no drastical additions.
This means that optimizing for P-III is practically the same as optimizing
for P-II.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
[Warp <war### [at] tagpovrayorg>]
| P-III is practically a P-II with more MHz. There are no drastical additions.
Aren't you forgetting something? The Katmai instruction set for instance?
--
This message has not been scanned for viruses.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
: Aren't you forgetting something? The Katmai instruction set for instance?
Never heard of it.
And if there are new instructions in P-III, the optimized version mentioned
earlier certainly doesn't use them because it works fine in a P-II.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
[Warp <war### [at] tagpovrayorg>]
| Never heard of it.
Surprising.
| And if there are new instructions in P-III, the optimized version mentioned
| earlier certainly doesn't use them because it works fine in a P-II.
There are about 70 new instructions to the P-III compared to P-II,
including a new processor state which allows MMX operations to be performed
at the same time as normal floating points operations, which isn't possible
on the P-II.
I say "Normal floating points" operations because the P3 have a new
type in the so called KNI (Katmai New Instructions also known as MMX2), which
is a type of SIMD instructions. (Single Instruction Multiple Data)
The 70 new instructions are connected to eight new 128-bit 4*32-bit wite
single precision CPU registers that are tailor made for 3d vector operations.
I doubt they are used by the P3-optimized compile since 32-bit isn't wide
enough for POV-Ray, but a similar instruction set on the P4 have 64-bit
registers and could give POV-Ray quite a boost, if the compiler is willing.
For maximum speed one would have to rewrite the source code to take full
advantage of this.
I don't know you assume that asking a compiler to optimize a program for
a certain CPU will break all backwards support. It is quite possible to
include two bits of code for critical areas where new instructions are used
and have the runtime environment chose the correct one just prior to runtime.
--
This message has not been scanned for viruses.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
