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