Working Group 2 - Addendum concerning memory and ops vs. flops



Massive data requirements



The second aspect of massive data requirements is memory. Early in 

the workshop the n**3/4 "law" for memory was put forth. The

implications for a petaflops computer of the law are profound; only 32

terabytes of memory are required rather than a petabyte under the usual

megabyte/megaflop rule. If memory costs truely acount for over 99% of

the cost of the machine, such a reduction in memory represents a

reduction in cost by a factor of over 30.



Unfortunately the n**3/4 law does not apply to all applications. Indeed

there was a consensus that many of our users are more

concerned with memory than with processors. Applications that require

significant amounts of memory include cryptography, automatic test

pattern generation (ATPG), and the "visible earth".



Uses of the memory are diverse. Examples include very large table

table-driven execution (crypto) and  maintaince of extensive state spaces

during heuristic search (ATPG). The availability of additional memory

allows these algorithms to trade space for time, reducing execution

time more effectively with the additional memory than may be possible

simply by adding more processor power. One should note that the

trade-off between space and time is not unique to these two examples.



A second issue concerning memory is exploitation of the memory heirarhy.

The architecture group

has indicated that when using silicon technology that the memory will

be the most expensive part of the petaflops machine. At petaflops I in

Pasadena optical RAM memory (Sterling et. al., pp. 83-99) was presented

as a possible solution to the bulk RAM problem. The 10 year projection

(ibid p. 92) is for 0.1 petabit memories, with 1uS access times, and 10**15

b/s transfer rates. While the access time is too high for all access,

it may be possible to use optical memories as an additional layer in

the storage heirarchy, providing applications access to bulk memories

without driving the cost of the machine too high. Such "slow memory"

would not be useful to all applications. Indeed, only applications

whose access pattern could be predicted in advance, and which used a

fair portion of the accessed data, would benefit.



Balance of floating point versus integer operations



Working group 2 is concerned with the focus on petaFLOPS. Many

applications are not floating point intensive, but are integer, bit,

and byte operation intensive. For example, cryptography, protein and

DNA sequence comparison, and ATPG are all integer and bit/byte

computations. Let's not ignore their needs. Similarly variable

preceision floating point and integer arithmetic is needed for several

applications, particularly some cryptographic problems.



