Re: teraspace, user spaces, etc.

I see this situation a little differently than you do.

1) How one achieves the best performance may vary between hardware models,
even those concurrently supported by the same release. Further, I'd assert
that even if some performance difference could be achieved by using
detailed knowledge of internal implementations in some isolated case, that
improvement potential would be swamped by the overall code optimization and
system performance optimization that is possible because the MI is
maintained as a whole. This assertion is certainly true in the long term
and very likely true in the short term as well.

2) Exposing commonly needed MI functionality is more a function of compiler
implementation decisions than of the need to know details below the
published level of abstraction. As you point out, this case has been
cleared up and did not involve the need to know details of the
implementation of the MI.

3) There are certainly lots of smart people that could make contributions,
but IBM employs us to make systems run well and fast, and then the company
is free to try to profit by selling the systems.

Paul Godtland (speaking for me)


"M. Lazarus" <mlazarus@ttec.com>@midrange.com on 05/23/2001 11:00:02 AM

Please respond to MI400@midrange.com

Sent by:  owner-mi400@midrange.com


To:   MI400@midrange.com
cc:
Subject:  Re: teraspace, user spaces, etc.



Paul,

At 5/23/01 07:05 AM -0500, you wrote:
>Perhaps the high level of abstraction is frustrating for
>those who want to know the underlying details, but such abstraction is
>required for adaptability. Giving out details below the published level of
>abstraction would make change much more difficult, because then
>dependencies on one particular implementation could be developed.

  In theory, I agree w/ the above statement, but in practice I
disagree.  MI programmers have always known that a release or even a PTF
can break their code.  This is one of the risks of this type of
programming.

  The reasons to know about and utilize low-level functions are numerous,
but a few come to mind immediately:

1)  Performance.  Sometimes, for whatever reason, the supported interface
will not perform a particular task quickly enough.  This may be an unusual
scenario that IBM will address, due to the circumstances.

2)  Functionality.  All of the functionality of a particular function may
not be exposed by the official interface.  Case in point are the
trigonometric functions that have been directly available in MI since day
one, but only since the inception of ILE can they be directly accessed via
the HLLs.

3)  There are many smart people out there that can give the good folks in
IBM labs some implementation ideas and feedback.


  -mark

+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---