 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] bahnhof se ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rudy Velthuis wrote:
> 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
A word from Ken:
Let's examine that speed improvement for just a moment. The items
in the scene were a quadratic spline using sturm, this had a 6 layer
semitransparent texture applied, and a hand full of superellipsoids.
As I watched the scene render it was evident that the most time
consumed during the render operation was spent on the lathe object.
I would discount the superellipsoids from the speed improvement as
their addition to the render time was not much more than the other
versions.
There is also the case where I simply used objects from shapesq.inc,
with and without sturm, that don't show near the increase in performance
you would expect as seen with the quadratic spline late object. While
there was improvement in general it wasn't on so high an order.
There were also several bug fixes in this version and who is to say
what impact they may have had been having. I think the test data I
provided is good general indication of what can be expected as far as
increased performance from v3.1b and v3.1d. It only implies the reasons
the speed has been improved without disclosing why it is better.
What were the contributing factors involved in this performance increase ?
I don't know, but the data should not have unsubstantiated value added
to it. What I presumed I was testing, and what the results indicate, may
be improperly assigned to the wrong attribute and should be taken into
consideration when examining the data.
Obviously they have been reworking some of the code to make it ready
to become a full c++ compliant program (as mentioned in Chris Young's bug
fix report) and that may be what is adding to the performance. Without
direct knowledge of the changes and their implementation would be idle
speculation and not worthy of serious discussion.
My point is don't try to read too much into that data I provided because
it may be full of traps.
One more thing: Don't worry - Be happy.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rudy Velthuis wrote:
<snippety>
>
> I've been looking in Gravity, but almost all my news was gone (I told y
ou
> about my self-imposed 60 day limit). I couldn't find it on Dejanews eit
her.
> But I'm 100% sure I've seen it somewhere.
ok :-) Thanx anyway.
> >> But it was the improved algorithm which made the routine faster, not
> Pascal
> >> of course.
>
<snappety>
> 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 t
o
> 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
.
Yup, that Is what I have said in my own little way... or tried to
anyway..
I've never done anything more advanced in asm than to transform a
highoptimized pascal routine(screen melt thingy) into asm... lost a
helluva lot of procedure-calls, and the loop was far faster as well...
> >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 da
ys,
> BBC-Basic was all I had. It even taught me procedural programming, beca
use
> it had procedures and functions and local variables.
ok. I started in BASIC on a SVI computer. Then got on to turbo-pascal
4....
>
> How many Euro-Cents would that be?
Hmm, I think it's something like 0,003-0,002. But I haven't looked at
the exchange rates.
--
//Spider
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
