Re: Query about monitor (passive) task optimization

[seas.gwu.edu!mfeldman@uunet.uu.net (Michael Feldman)]

In article <CB403J.74M@ddciiny.UUCP> jls@ddciiny.UUCP (Jonathan Schilling) writ
es:
>In article <23corr$a8g@schonberg.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) w
rites:
>>Mike assumes that automatic recognition of passive tasks is a good thing.
>>He is apparently unaware that this is by no means obvious, and indeed most
>>of the Ada folks in realtime areas that I have talked to do not AT ALL like
>>the idea of such automatic recognition, and much prefer explicit control
>>over thread structure.
>
>I've heard of these objections before, but I don't fully understand them. 
>Assuming the optimization is transparent to the programmer, and does not 
>in any way change the semantics of the program, what "control" is being
>lost?  From within the program, using only standard Ada, one wouldn't
>even be able to detect whether the optimization had happened or not 
>(this might be doable with CIFO-type interfaces, depending on the
>runtime system implementation).  The only difference is that the program
>runs faster.
>
Exactly. That's why I applauded DDC-I for doing it.

The reason for the objection is that people do not trust their compilers,
especially in the realtime business. As I said in my big long post yesterday,
this gives me a sense of deja vu. Back in the 70's the efficiency fanatics
hated procedure calls, especially with parameters. Some realtime guys still 
do, and - for their projects - they may have no choice. What has rankled
is that the Ada compiler folks have not gotten out in front and led their
customers instead of following them. If they had, maybe there would be
more customers outside the defense business.

Ada is a parallelism language, too, not just a realtime one. Where are the
code generators for the parallel machines? The Ada houses are, for the
most part, opting out of that market, preferring - as usual - the
comfortable realtime crowd in the defense industry.

Ada is, in its way, a very innovative language, especially in the tasking
area. No other major language has anything comparable. One of my biggest
disappointments, as a teacher and fan of concurrency, is that the Ada
houses have systematically neglected really exploiting these and other
innovative language constructs in Ada, preferring the tried and true.

Another example: are there any vendors out there who've tried to go after
a piece of the Fortran-oriented market by mapping its multidimensional
constrained arrays in column-major form? The LRM allows any old storage
mapping. Teachers like me explain this seeming gaffe by pointing out that
a compiler oriented at the Fortran crowd _could_ use column-major
storage to interface with old Fortran codes, while one for some
nonlinear architecture _could_ map the arrays nonlinearly (in a
tree structure as used, I think, on the old Univac architecture),
and a "classical" code generator could use the old row-major mapping.
Or indeed, with implementation-dependent pragmas, they could do all 3.

To my knowledge, everyone is sticking to the tried-and-true row major.
Yes, I know Ada9X is providing a pragma to cover this sort of
storage mapping. Did anybody do it without waiting for 9X? Not
to my knowledge. I'd _love_ to be wrong here...

If these things are so obvious to mere academics, what is keeping the
vendors from aggressively going after these markets with some real
innovation and leadership in Ada compilers? In my view, nothing but
the "beltway bandit" mentality is holding them back.

Verdix could do this instead of keeping their compiler folks busy by
giving them a C++ system to write...

Sure it costs money to get out in front. I have no business degree, but
somebody told me long ago that a good business person knows you have to
spend money to make money...

Mike Feldman