[Mpi-22] New proposal: Support for large message counts

[Supalov, Alexander]

Terabytes are pushed back and forth already now, maybe not yet in one
piece. MPI-3 is a couple of years away, by which time who knows what may
happen. Anyway, you're right, this may not be an immediate concern.
 
At the moment, IBM Power apparently implements lp64 model. We typically
see the same thing on Intel 64 based platforms. Our compiler's long long
is 64 bit in that case, too. Same on Itanium. The latter already has
several multiply/add commands with an intermediate full 128-bit product
out of 64-bit int operands, and the corresponding compiler intrinsics,
however.

________________________________

From: mpi-22-bounces_at_[hidden]
[mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard
Treumann
Sent: Thursday, September 04, 2008 5:25 PM
To: MPI 2.2
Subject: Re: [Mpi-22] New proposal: Support for large message counts

Are there systems today that use a 128 bit long long? Are there virtual
memory systems or filesystems coming in the reasonable future that use a
128 bit address range?

On IBM Power we support both 32 bit and 64 bit executables. For both 32
bit and 64 bit executables, the C compilers treat int as 32 bits and
long long as 64 bit. C long differs so is 32 bits in a 32 bit executable
and 64 bits in a 64 bit executable (I.E. big enough to hold an
address/pointer). 

The jump from 32 bits to 64 bits is a factor of 4 billion so it may be
goodness in the abstract to think about what comes after 64 bits gives
way to 128 bits, should we consider this a real problem?

I do not see much reason to worry about the fact that multiplying 2
arbitrary 64 bit values can overflow a 64 bit result unless we think
some real situation will call for 128 bit results. 

Dick Treumann - MPI Team 
IBM Systems & Technology Group
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363

Alexander wrote
<snip>
> Another thing is that if we multiply to long values, the result may 
> potentially overflow a long. So, for a library that allows long 
> counts and long datatype extents, the internals of the library will 
> have to be long long. long long (128 bit) arithmetic may be rather 
> expensive on some CPUs. So, the 64-bit interface should probably be
optional.
<snip>

---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.





* 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-22/attachments/20080904/f33f74a1/attachment.html>