 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Gordon wrote:
> On Thu, 01 Aug 2002 12:46:28 -0400, Micha Riser wrote:
>
>
>> I have compiled a version of pov-ray with gcc 3.1
>
> Hmm... I found a gcc 3.2 in rawhide. Maybe I should give that a whirl...
>
gcc 3.2 is not released yet.. get 3.1 form gcc.gnu.org.
--
http://objects.povworld.org - the POV-Ray Objects Collection
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well I am willing to try your Duron-compiled version
Fabien
>
> > Thanks for it
> > File : orient.pov
> > parameters : +w800 +h600 -f +a +dgt +v
> > Linux Mandrake 8.2 Kernel 2.4.18
> > Windows 2000 Pro
> > It is also optimized for my Duron !
> > AMD Duron 700 Mhz 512 Mo Memory
> >
>
> Nice to hear.
>
> >
> > But the optimised version does not work with soft.pov
> > I get an error
> >
>
> Works fine here with soft.pov. This is probably because amd duron does not
> support 'SSE' instruction what pentium 3 does. (Athlon XP does it). I can
> try to make a version for amd duron as well - though if I don't have such a
> processor I cannot test it..
>
> - Micha
>
> --
> http://objects.povworld.org - the POV-Ray Objects Collection
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Well I am willing to try your Duron-compiled version
>
Can you post or email me a print of 'cat /proc/cpuinfo' on your system to
give me the exact details of your cpu?
- Micha
--
http://objects.povworld.org - the POV-Ray Objects Collection
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
There it is as an attachment
Thanks
Fabien HENON
Micha Riser wrote:
>
>
>>Well I am willing to try your Duron-compiled version
>>
>
>
> Can you post or email me a print of 'cat /proc/cpuinfo' on your system to
> give me the exact details of your cpu?
>
> - Micha
>
Post a reply to this message
Attachments:
Download 'us-ascii' (1 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have done further trials to speed povray up. You can expect a up to 10%
faster gcc compile from me in the next few days. While GCC 3.1 uses MMX
registers it does not actually use SIMD instructions :( One would have to
add these by hand but this is quite tiring.
Currently I am testing Intel's compiler... and had to find that the POV-Ray
coders did a great deal in making it impossible to auto-vecotrise the
colour-operations for icc :/
- Micha
--
http://objects.povworld.org - the POV-Ray Objects Collection
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
If people are continue improving algorithmic changes that are compiler and
platform independent, wouldn't it be a good thing to keep track of those
changes and work on a 3.5.1 or a 3.6 version?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 01 Aug 2002 21:19:53 +0200, Mark Gordon wrote:
>
> On Thu, 01 Aug 2002 12:46:28 -0400, Micha Riser wrote:
>
>
>> I have compiled a version of pov-ray with gcc 3.1
>
> Hmm... I found a gcc 3.2 in rawhide. Maybe I should give that a
whirl...
gcc 3.2 is gcc 3.1.1 with a new c++ ABI (c++ v3 multivendor) which is what
we are aiming for with our 1.4 Gentoo release :)
gcc 3.1.1 is released, and has finally made -march=pentium4 stable (it
was bad juju in 3.1 ) and should have some further speedups. avaiable from
http://gcc.gnu.org/
for those asking about optimization flags, gcc/make should automatically
rebuild whats needed when you just do :
export CFLAGS="optimziation";export CXXFLAGS="${CFLAGS}"; ./configure
--with-foo --enable-bar; make clean ;make all
//Spider
--
begin .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Micha Riser <mri### [at] gmx net> wrote:
> Currently I am testing Intel's compiler... and had to find that the POV-Ray
> coders did a great deal in making it impossible to auto-vecotrise the
> colour-operations for icc :/
This reminds me of something else: Seemingly patch makers have not followed
the strict programming guidelines in the POV-Ray source code, which has
caused a big problem: The code is extremely hard to optimize for RISC
processors, which means that POV-Ray is quite slow in them, even though
it could be a lot faster if the patches were coded in the right way.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d4b341f@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> This reminds me of something else: Seemingly patch makers have not followed
> the strict programming guidelines in the POV-Ray source code, which has
> caused a big problem: The code is extremely hard to optimize for RISC
> processors, which means that POV-Ray is quite slow in them, even though
> it could be a lot faster if the patches were coded in the right way.
What "strict programming guidelines" are you talking about?!?
The Source is very messy and inconsistent, badly commented, with
different coding styles in different areas and often doing things the
hard way when an existing function does the same thing. It isn't just
the patches that have this problem, some of the worst code is very old:
The leopard pattern (and several others) could be a 1-liner[1], but it
uses 4 temporary variables. The onion pattern has a (unnecessary)
variable named "noise" and the following comment:
/* The variable noise is not used as noise in this function */
The code is littered with unused variables and produces huge amounts of
warnings.
And there is no documentation other than the source code itself,
definitely no strict guidelines. And I don't think the code has ever
been good on RISC machines...it has been like that from the beginning.
[1] Specifically:
return Sqr((sin(EPoint[X]) + sin(EPoint[Y] + sin(EPoint[Z])))/3.0);
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> return Sqr((sin(EPoint[X]) + sin(EPoint[Y] + sin(EPoint[Z])))/3.0);
You probably mean Sqr((sin(EPoint[X])+sin(EPoint[Y])+sin(EPoint[Z]))/3);
Temporary variables are do not affect the performance mostly though. The
has to use several registers anyways. But to show the vector nature of this
calculation it should be written as:
DBL value=0;
for(int i=0; i<3; i++) value+=sin(EPoint[i]);
return Sqr(value/3.0);
Of course this assumes that X,Y,Z are 0-2 index.
--
http://objects.povworld.org - the POV-Ray Objects Collection
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
