|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.