POV-Ray : Newsgroups : povray.general : Improving POV-Ray. Server Time
12 Aug 2024 19:35:52 EDT (-0400)
  Improving POV-Ray. (Message 21 to 30 of 32)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 2 Messages >>>
From: John M  Dlugosz
Subject: Re: Improving POV-Ray.
Date: 20 Feb 1999 11:55:24
Message: <36cee8fc.0@news.povray.org>
>I have personally seen the difference between a program written in pure
>C, another version in C+ASM, and a pure ASM version. Needless to say,
>the ASM version kicked the C version, but the combined version caught my



And I've seen the opposite:  My C++ version of a program with several
indirect function calls and a minimal ASM driver backend blew away a pure
ASM program by a factor of 3 or 4.


Post a reply to this message

From: John M  Dlugosz
Subject: Re: Improving POV-Ray.
Date: 20 Feb 1999 12:01:11
Message: <36ceea57.0@news.povray.org>
povray.org admin team wrote in message <36d233dd.6363046@news.povray.org>...
>Anthony Bennett <ben### [at] panamaphoenixnet> wrote:
>And remember, POV spends most of it's time during rendering waiting on the
>floating point co-processor. Optimisation isn't going to help that either
>(unless you can manage to do some useful integer-related work in parallel).


If someone wrote some low-level math routines, like matrix multiply, in ASM
to take advantage of specific special processor features, it =might= make a
difference.


Post a reply to this message

From: Spider
Subject: Re: Improving POV-Ray.
Date: 21 Feb 1999 10:13:53
Message: <36D01B22.30647A50@bahnhof.se>
Margus Ramst wrote:
> 
> Again, check out the Superpatch. It can do a procedural height field, 
> i.e. it takes an ordinary POV texture instead of a bitmap.
I think I will have to read more of the doc's in superpatch. I hadn't
found it yet :-)

-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);


Post a reply to this message

From: Spider
Subject: Re: Improving POV-Ray.
Date: 21 Feb 1999 10:13:55
Message: <36D01BE3.49F920CE@bahnhof.se>
Rudy Velthuis wrote:
> 
<snip>

Nifty basic :-)
 

> 
> A language like Inprise Borland Object Pascal and the component library VCL
> uses assembler in time-critical parts (sorting, string functions) or in
> parts, where a call couldn't easily be faked using high level Pascal
> (because something like non-standard stack handling is required). 
I know this about the Delphi environment, and that they used it partly
in OOP pascal.

> I've
> however seen one example, where optimized Pascal code was *faster* than the
> original hand-optimized assembler routine. This was also a string function.
> It was the improved algorithm which did the trick.

Show me that pascal code, please. 

-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);


Post a reply to this message

From: Rudy Velthuis
Subject: Re: Improving POV-Ray.
Date: 21 Feb 1999 11:35:32
Message: <36d035d4.0@news.povray.org>
Spider schrieb in Nachricht <36D01BE3.49F920CE@bahnhof.se>...


>Show me that pascal code, please.

If I can find it, I'll e-mail it to you. It was in one of the
news.inprise.com newsgroups (I think it was borland.objectpascal). It should
have been deleted from my disk by now (I only keep newsgroup messages for 60
days), but I might have saved it somewhere (if I only knew where). Otherwise
try Dejanews or the Delphi Super Page.

But it was the improved algorithm which made the routine faster, not Pascal
of course. I just mentioned this to show, that a clever algorithm is
sometimes better than a "blind" translation to assembler. And even the best
compilers don't develop algorithms yet.

BTW BBC-Basic was really a very nice and fast Basic interpreter. I have even
tested a PC version of it once (1985/86). Only the assembler was different,
of course. And it had problems with the PC graphic resolutions.
--
Rudy Velthuis


Post a reply to this message

From: Spider
Subject: Re: Improving POV-Ray.
Date: 21 Feb 1999 17:01:39
Message: <36D0602C.D635E4F6@bahnhof.se>
Rudy Velthuis wrote:
> 

> Spider schrieb in Nachricht <36D01BE3.49F920CE@bahnhof.se>...
> 

> >Show me that pascal code, please.
> 

> If I can find it, I'll e-mail it to you. It was in one of the
> news.inprise.com newsgroups (I think it was borland.objectpascal). It s
hould
> have been deleted from my disk by now (I only keep newsgroup messages f
or 60
> days), but I might have saved it somewhere (if I only knew where). Othe
rwise
> try Dejanews or the Delphi Super Page.
Ah, I can try, If I knew what to look for... :-)
 

> But it was the improved algorithm which made the routine faster, not Pa
scal
> of course. I just mentioned this to show, that a clever algorithm is
> sometimes better than a "blind" translation to assembler. And even the 
best
> compilers don't develop algorithms yet.
I agree with you. but, often a specific algorthim is better than a
general one, and most specific algorthims can be coded in asm once it is
in a fast High level language. What I mean is that you gain less if you
only trust that "asm is faster" and don't do a good algorithm first.
Bubble-sort is faster in asm than in pascal, but still slower than
ComboSort, SpeedSort or QuickSort. And theese algorithms would probably
be faster in asm than in pascal. (Don't know, I haven't tried. I'm not
_that_ interested in sorting speeds.)

> BTW BBC-Basic was really a very nice and fast Basic interpreter. I have
 even
> tested a PC version of it once (1985/86). Only the assembler was differ
ent,
> of course. And it had problems with the PC graphic resolutions.

Well, I can't disagree since I haven't tried it. But I can say that I
don't really enjoy BASIC as a language. If you are in need of an
interpreted language, JAVA is better, and If you want a progrmming
language, pascal or c/c++ will be better. pascal for the ease of
learning, and c/c++ for the flexibility of pointers. And, if you want a
visual development that is easy, I'd go for Delphi, since Visual C isn't
very easy to get started with, and a visual java development probably
isn't what you want then.



-- 

//Spider 

( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);


Post a reply to this message

From: Dick Balaska
Subject: Re: Improving POV-Ray.
Date: 21 Feb 1999 20:49:30
Message: <36D0B79E.D5AF47B0@buckosoft.com>
Spider wrote:
> 
> Rudy Velthuis wrote:

> 
> > I've
> > however seen one example, where optimized Pascal code was *faster* than the
> > original hand-optimized assembler routine. This was also a string function.
> > It was the improved algorithm which did the trick.
> 
> Show me that pascal code, please.

I agree.  I'll bet real money that i can code any algorithm in asm
to run faster than a high level language. Although it's been 10 years
since
i've done my last 80386 device driver, i still occasionally have to slop 
my way stepping through optimized compiler output.  I am always
surprised
to see array indexes calculated with multiplys instead of shifts.
Also, C function calls always pay the price of building a stack frame.
push ebp ; mov ebp, esp ; is a very slow operation.  Stack operations
are slow, passing arguments in registers is much faster. In the case
of the 8080 and all of it's descendents, the chip is designed to have
specific arguments passed in specific registers.
Now pentiums are designed with dual pipelines and prefetch queues,
most of whose advantage is negated by constant test-branch logic.

On the other hand, i don't want to ever write assembler again.
I'd rather just buy a faster computer :)

* No problem is too large that a faster clock rate can't fix.

dik


Post a reply to this message

From: Disnel
Subject: Re: Improving POV-Ray.
Date: 22 Feb 1999 05:36:36
Message: <36D13385.D98CC785@linux.itam.cas.cz>
No and I hope, that POV team will use C or C++ or another portable
language.
There are two reasons:

1) Now I'am very long time waiting for UNIX version of POV.
     With parts in ASM it will take much more time to release this version.

2) Its imposible to write good optimized code for new processor such as
     PII or Merced because its internal structure is too complicated for
     human programmer. Good compiler can do much better this task.


Post a reply to this message

From: Rudy Velthuis
Subject: Re: Improving POV-Ray.
Date: 22 Feb 1999 16:02:15
Message: <36d1c5d7.0@news.povray.org>
Spider schrieb in Nachricht <36D0602C.D635E4F6@bahnhof.se>...

>Rudy Velthuis wrote:
>>
>> Spider schrieb in Nachricht <36D01BE3.49F920CE@bahnhof.se>...
>>
>> >Show me that pascal code, please.
>>
>> If I can find it, I'll e-mail it to you. It was in one of the
>> news.inprise.com newsgroups (I think it was borland.objectpascal). It
should
>> have been deleted from my disk by now (I only keep newsgroup messages for
60
>> days), but I might have saved it somewhere (if I only knew where).
Otherwise
>> try Dejanews or the Delphi Super Page.
>Ah, I can try, If I knew what to look for... :-)

I've been looking in Gravity, but almost all my news was gone (I told you
about my self-imposed 60 day limit). I couldn't find it on Dejanews either.
But I'm 100% sure I've seen it somewhere.

>> But it was the improved algorithm which made the routine faster, not
Pascal
>> of course.

>I agree with you. but, often a specific algorthim is better than a
>general one, and most specific algorthims can be coded in asm once it is
>in a fast High level language. What I mean is that you gain less if you
>only trust that "asm is faster" and don't do a good algorithm first.
>Bubble-sort is faster in asm than in pascal, but still slower than
>ComboSort, SpeedSort or QuickSort. And theese algorithms would probably
>be faster in asm than in pascal. (Don't know, I haven't tried. I'm not
>_that_ interested in sorting speeds.)

Of course if you would implement a good algorithm in (good) assembler, you'd
propably gain some more speed. This can be done for simple algos. But to
optimize a huge program and rewrite it in assembler is not seeking for
speed, it is asking for trouble (bugs). Optimizers are not perfect, but
consistent. Humans are perhaps cleverer, but very inconsistent, make
mistakes, forget things, etc. Optimizers do not have these human traits.

>But I can say that I
>don't really enjoy BASIC as a language.

Neither do I, I'm a Delphi freak. And if, for some highly unimaginable
reason, I would have to dispose Delphi, I'd turn to C/C++. But those days,
BBC-Basic was all I had. It even taught me procedural programming, because
it had procedures and functions and local variables.



How many Euro-Cents would that be?



--
//Spider
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);


Post a reply to this message

From: Rudy Velthuis
Subject: Re: Improving POV-Ray.
Date: 22 Feb 1999 16:02:17
Message: <36d1c5d9.0@news.povray.org>
Dick Balaska schrieb in Nachricht <36D0B79E.D5AF47B0@buckosoft.com>...
>Spider wrote:
>>
>> Rudy Velthuis wrote:
>
>>
>> > I've
>> > however seen one example, where optimized Pascal code was *faster* than
the
>> > original hand-optimized assembler routine. This was also a string
function.
>> > It was the improved algorithm which did the trick.
>>
>> Show me that pascal code, please.
>
>I agree.  I'll bet real money that i can code any algorithm in asm
>to run faster than a high level language.

Sure, so could I. But if the algo stinks, turning it into asm is not much
use either.

>I am always surprised
>to see array indexes calculated with multiplys instead of shifts.

Now I don't know of any good WIntel based 32bit compiler which wouldn't use
the *2, *4 indexing the x386 and higher offer, if optimizations are on.

>Stack operations are slow, passing arguments in registers is much faster.
In the case
>of the 8080 and all of it's descendents, the chip is designed to have
>specific arguments passed in specific registers.

Many C compilers can use register based passing of parameters nowadays.
Delphi's Pascal has it as a preset (but it has other calling conventions
too).

But the normal calling convention for dlls is still the stdcall convention,
which uses the stack.

>Now pentiums are designed with dual pipelines and prefetch queues,
>most of whose advantage is negated by constant test-branch logic.

I can't comment on that, but you'd propably need the Intel compilers to get
the most of them.

>On the other hand, i don't want to ever write assembler again.
>I'd rather just buy a faster computer :)

That's exactly what most programmers think - and they're more or less right.
Now, using RAD, and application frameworks and GUI frameworks etc., it is
impossible to fine tune everything using assembler. It's more combining
building blocks (mind you, I'm not saying that is not a skill - it certainly
is), and even the people writing the building blocks (the component writers)
hardly ever use assembler, unless for some tricky hardware access or some
tricky stack/register handling.

--
Rudy Velthuis

But the only thing I wrote was, that the Pascal algorithm displayed was
faster than the original string handling function written in assmbler. It
was the design which made it faster, not the fact it was written in
optimized Pascal (on the contrary). Propably converting this algorithm to
assembler would even make it (a bit) faster.

But for some applications and purposes, a rethinking of the algorithm will
do more than just converting everything to assembler. Especially a large app
like POV-Ray would be very hard to convert to assembler without introducing
millions of bugs. Optimizers still don't produce the best possible code (how
could they- they're way too general to do that), but they do their work also
on very large projects with the same quality. Humans can't do that.

Have a look at the dramatic speed improvements achieved in POV-Ray 3.1d for
some higher order objects (cubics, quartics, superelllipsoids, etc). I don't
think they suddenly turned to assembler, but they must have redesigned some
algorithms.

>* No problem is too large that a faster clock rate can't fix.

>dik


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 2 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.