(j3.2006) [Fwd: Fortran 2008 query]

Bill Long longb
Thu Oct 26 17:47:54 EDT 2017


> On Oct 26, 2017, at 4:07 PM, Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov> wrote:
> 
> Not on any systems acquired at NASA.    Granted we?re no longer doubling memory-per-core with each generation of our cluster, but it is still growing.   Previous machine wast 128 GB on 28 cores.  Next machine is 256 GB on 40 cores.    And this is primarily driven by the requirements of our Earth system model (including data assimilation).

Well, this is today. Van was taking about the future.  Memory-cpu bandwidth and latency are increasing  a bottleneck.  The current DIMM model for memory will not last on high-performance  systems.   Future memory schemes will involve (faster) memory incorporated into the processor chip, or stacked very close.  And less memory/chip.  With more cores, definitely less memory/core.   Has your favorite Intel salesman not mentioned the 72-core chips? 

> 
> We of course wish to reduce the memory footprint, as it would likely mean we could buy (and use) more cores.   But in practice it is very hard to make headway.

Indeed, changing the memory layout is hard. Basically it's equivalent to writing better parallelism into to the code so that the data can be distributed over a larger set of nodes.  This takes thought, and sometimes a disruptive redesign.   Fortunately, Fortran is better designed for this than other languages. 

Cheers,
Bill

>    
> 
>> On Oct 26, 2017, at 4:27 PM, Bill Long <longb at cray.com> wrote:
>> 
>> 
>>> On Oct 26, 2017, at 2:58 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
>>> 
>>>> 
>>>> We could say that it is a processor-dependent value greater or equal to 1023.
>>> 
>>> Ridiculously small.  Why design a language for machines that were obsolete twenty years ago?  We should be designing for the future, not the past.
>> 
>> You mean the real future where the amount of memory/core continues to decline, and where broadcasting the executable out to all the participating processors becomes slower as the size of the executable increases (because of initialized arrays)?    The better option in cases like this is usually to read the data in from an unformatted file when the program starts.  Maybe just to image 1 and broadcast it from there. 
>> 
>> Cheers,
>> Bill
>> 
>> 
>> Bill Long                                                                       longb at cray.com
>> Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
>> Bioinformatics Software Development                      fax:  651-605-9143
>> Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425
>> 
>> 
>> _______________________________________________
>> J3 mailing list
>> J3 at mailman.j3-fortran.org
>> http://mailman.j3-fortran.org/mailman/listinfo/j3
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425





More information about the J3 mailing list