Re: teraspace, user spaces, etc.

There are certainly areas where providing more information about the system
would be helpful. Often not enough information is provided on how to use
new function just because time and energy has been focused on system
development instead of on documentation and sometimes because we don't
understand what information would be most helpful (an area where this forum
can shine). However, there are implementation details that there are no
plans to disclose, to preserve the high level abstraction that allows
change and also for proprietary reasons. We may disagree from time to time
on where the dividing line should be. :-)

Paul Godtland (not officially speaking for IBM)



"M. Lazarus" <mlazarus@ttec.com>@midrange.com on 05/24/2001 10:16:08 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/24/01 06:41 AM -0500, you wrote:
>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.

  While there may be some differences due to model implementations,
overall, the basic performance remedies will be the same.  IOW, just
because a particular model may handle a function better than another, I
will still follow prudent guidelines that apply almost across the board.


>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.

  I pointed out one example, that was corrected, but it took about 7 years
(17 if you count the S/38!) to get to that point.  We obviously can not
always rely on IBM to deliver enhancements on OUR schedule.

  By knowing block sizes, object sizes, how they are linked, what overhead
there is for that operation and many others will allow us to make better
implementation decisions.  Most, if not all of those values can be
softcoded, or at least centralized, to be flexible.


>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.

  We're not talking about charging IBM or having any strings
attached.  This board is has quite a few heavy techies that are willing to
contribute to making this OS even better.  For FREE!  On their own time!!


>Paul Godtland (speaking for me)

  -mark (speaking for me - and anyone else that agrees!)


+---
| 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
+---