Oppolzer - Informatik / Blog

PL/1 especially has some problems regardings optimization, because it has some
language properties which prevent aggressive optimization. For example, on
units. If there are some on units in effect, you have to take into account, that
these on units could be fired between each and every statement which in theory
can produce this condition, and so you (as a compiler writer) can not move these
statements at another position for optimization reasons without affecting the
semantics of the program.

The C language, for example, does not have these restrictions on optimization,
because it is much much simpler. So "in general" C programs are faster than PL/1
programs.

I don't want to start a religious war on programming languages; it is just fact.
Ask any compiler builder about that. The simpler the programming language is,
the more powerful the optimization can be (I hope, this is correct english).

The Multics PL/1 compiler was an exception in history, IMHO, because it did an
unbelievable good job in optimization. Our today's EP PL/1 compilers are only
some years old (less than ten) and still can (or need to) be improved. Maybe
PL/X is different; I have no experience with PL/X, unfortunately.

Kind regards

Bernd



F.W. schrieb:
>>     The counter examples have all been of the variety that I
>>     described as my "12 instructions" beat yours or your HLL
>>     code. As I explained, they don't count. I, too, can come
>>     up with data structures and a small inner loop of machine
>>     code that can't be bettered by a compiler. So what? That's
>>     not the issue at hand at all. If you think it is, then you
>>     are missing the point.
>>
>
> I really tried to resist writing another reaction because I am well
> aware that no good will come from it anyway, but I couldn't....
>
> You may argue that I am missing the point with my '12 instructions
> example' but it seems that you are missing my point as well. You have
> stated some general principle about the relative performance of HLL
> compilers versus assembler programmers that simply isn't valid in the
> general sense at all. In the real world I'm living in there is *no* HLL
> compiler that outperforms assembler programmers. We have PL/I for OS and
> MVS (powerful language, poor optimization) and Enterprise COBOL (a poor
> language to begin with and anaemic optimizations). If that 'doesn't
> count' the points put forward in this discussion however interesting
> they might be become rather irrelevant...
>
> F.
>