SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Sun, 3 Aug 2003 10:22:56 PDT7
From:	Peter Skye <pskye@peterskye.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Re: Warpstock 2003 Presentation

Content Type: text/plain

Lynn H. Maxson wrote:
>
> As HLL users it should be obvious from the performance
> differences that while we don't want to be bothered with
> knowing the underlying "commands" (to quote Peter), we
> would at least like to know that those who do bother with
> such things have done so in the most optimal manner. Yet
> it obvious from the performance differences of every HLL
> implementation relative to symbolic assembler that they
> haven't done so.

I use a lot of Rexx to augment my "batch" command files. Slow it is,
but I'm in a rush to get the answer.

> Further you have to ask yourself, in reference to Peter's
> use of inline symbolic assembler in PASCAL source, why
> after some 40+ years the performance difference not only
> continues to exist but with the advent of object-oriented
> it has gotten even worse?

Either this is a bad example or I don't understand your point. It isn't
the HLL per se that slows down the execution, it's the logic algorithm
in the compiler's library used to generate the machine instructions.

Simple things like "attach a task" and "wait for an event control block"
are OS-oriented and basically single instructions. But consider this
hypothetical HLL instruction:

DrawEllipse(x1,y1,x2,y2,f)

There are lots of algorithms, and probably a new one that I (and the
compiler!) haven't seen yet. Sometimes you find you want to use that
newly-discovered algorithm.

If you profile your code (measure the time used by various sections) and
determine that the HLL is doing a crummy job with something, you can
either redesign your HLL code or revert to a lower level (i.e. inline
assembler). In a perfect world you shouldn't have to do either but in
the real world you need to get the job done, and sometimes assembler
does that.

> Does anyone here seriously believe that any performance
> difference for equivalent function should exist between
> symbolic assembly and an HLL?

Yes, in the real world. A general-purpose code generation or
subroutine/function/procedure may contain escapes to process certain
parameter values which your particular situation will never have, may
contain unnecessary register saves and loads, may contain defensive
variable sets which you know not to be necessary, whatever. In the real
world this is necessary for the general purpose, and if while creating
these general purpose routines you try to program _every_ possible code
optimization into every routine then you will be writing your HLL
compiler forever. I mean, sometimes you want to count 1,2,3,4,5 and
sometimes you want to count 1,2,4,8,16 and sometimes you want to count
1,3,5,7,9 and sometimes you want to count 1,3,10,30,100 and sometimes
you want to count 0,2,4,6,8 -- every one of these counting options may
be optimized in a different way. I don't need the code optimized if I'm
only counting once per program execution (indeed the additional compile
time during development to "optimize" a given situation will likely
exceed the total wasted cpu time during all executions over the life of
the program), but the "occasional" case where I'm looping through the
code 100,000,000 times might make a custom optimization desirable.

If you want to push open source, fine by me. If you want to push a
more-encompassing HLL, fine by me. If you want to push algorithm
design, fine by me. If you want to push code optimization, fine by me.
But just like "cheaper, faster, better" when you can't have all three,
*you* can't have everything either! State what you want, Lynn, and
then also state the tradeoffs. :)

- Peter

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 03 | August | 2003 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.