Subject: proposal -- context and tag limits

From: [email-masked]
Date: Fri, 9 Apr 93 19:43:26 PDT

Lyndon et.al. write:

> ...  This seems to say that the bit
> length of the envelope is fixed to some number of bits and the more
> fields we want to cram into the envelope the shorter the bit lengths of
> fields must be.  Is there a good reason why the bit length of the
> envelope shoud be fixed in this fashion, or perhaps are you arguing
> that the bit length of the envelope should be as short as possible?
> 
> > This is a question vendors might answer: how many
> > context values and tag values are you willing to support on future
> > platforms and how many are you willing to back fit on existing ones?
> 
> Yes, this would be a good question for the vendors indeed.  
> 
> VENDORS - PLEASE PLEASE PLEASE DO ADVISE US ON THIS ONE. 

I wonder what kind of useful advice vendors could really give us.

Hardware support boils down to a question of getting faster
performance in exchange for some relatively small resource limit.

But in almost every case I can think of, such limits are made
functionally transparent to the user by automatic fallback to
some slower mechanism without the resource limit.  Thus we have..
  fixed size register sets with compilers that spill to memory,
  fixed size caches with automatic flush/reload from main memory,
  fixed size TLB's with cpu traps for TLB reload, 
  fixed size physical memory with virtual memory support, 
and so on.

The only counterexample that pops to mind is fixed-length numeric
values, for which reasonably well established conventions exist.

No such conventions currently exist regarding tag and context
values.

============  PROPOSAL TO ENVIRONMENT COMMITTEE ==============

The MPI specification should 

1. require that all MPI implementations provide functional
   support for specified generous limits (e.g., 32 bits) on tag
   and context values, and

2. suggest that vendors provide a system-specific mechanism by
   which the user can optionally specify tag and context limits
   that the program agrees to abide by.  Even the form of
   these limits should remain unspecified since they may vary
   from system to system.
   
======================== END PROPOSAL ========================

Further discussion...

If a vendor wishes to provide hardware support to enhance
performance for some stricter limits, and if some people are able
and willing to write programs within those limits, that's great.
Those people on those machines will be lark happy.  If the
performance increase is substantial, and I'm on one of those
machines, and my program is simple enough, I'll probably be one
of those people.

However, I am not aware of any system on which generous limits
could not be supported, albeit with some loss of performance
compared to staying within the (currently hypothetical)
hardware-supported limits.

Everyone I know would MUCH prefer suboptimal performance 
over HAVING to rewrite applications to conform to varying and
inconsistent hard limits.

Yes, I recall the many arguments against mandating specific
limits.  But, I claim that those arguments are misdirected.
They are based on analogy to things like word length and memory
size, which I again note are subject to well established
conventions and principles.  (You can't run big programs on small
machines, and we pretty much agree about what "big" and "small"
mean.)  In the case of context and tag values, such conventions
do not exist, and a very wide range of conflicting limits have
been discussed at various times and places.

I believe that we will not meet our goal of portability 
if we do not specify usable limits on tag and context values.

--Rik

----------------------------------------------------------------------
[email-masked] (alias 'd39135')   Rik Littlefield
Tel: 509-375-3927                         Pacific Northwest Lab, MS K1-87
Fax: 509-375-6631                         P.O.Box 999, Richland, WA  99352

---

From: L J Clarke <[email-masked]>
Date: Tue, 20 Apr 93 19:06:06 BST

> ============  PROPOSAL TO ENVIRONMENT COMMITTEE ==============

Yes, I support the spirit and detail of the proposal.

> inconsistent hard limits.

Yes, this claim is true of everyone I know except for one very small
community of academic scientists who will write their relatively simple
programs from scratch for every machine on which they will do major
scientific production runs.  I know a whole lot more academics and
commercials who just will not write programs from scratch in this way. 

> limits.  But, I claim that those arguments are misdirected.

Indeed I believe that your claim is valid.

> if we do not specify usable limits on tag and context values.

I have the same belief.  I also believe that if we fail on portability
then we fail period. 

Best Wishes
Lyndon

         /--------------------------------------------------------\
    e||) | Lyndon J Clarke    Edinburgh Parallel Computing Centre | e||) 
    c||c | Tel: 031 650 5021  Email: [email-masked]  | c||c 
         \--------------------------------------------------------/