| Food Composition Data: A User's Perspective (1987) |
|Systems considerations in the design of INFOODS|
System architecture and linkages
As systems become large, basic issues of organization assume an importance of their own. As long as the total size of the system is much smaller than the effective size of the machine, one can be fairly cavalier about simply putting things together and running them. But with very large systems new issues arise as to how the codes are to be accommodated on the machine. Depending on the size and characteristics of both the system and the machine, the consequences of trying to ignore the impact of size may be as gross as vastly increased costs or inability to run at all, or as subtle as slightly reduced performance or response. Independently of what the host machine or operating system looks like, it is generally desirable to keep as low as possible the host system's perception of how large the applications system is in operation (the working set). At the same time, the user's perception of application system size should be one of a vast and growing collection of capabilities and functions. While the user will be happy to see more facilities in the system, that happiness will disappear quickly if the presence of additional facilities causes last year's task to operate more slowly or at higher cost. A system may be thought of as having two separate "sizes," one determined by the machine resources required to execute its individual programs, and the other determined by its total extent when stored. If a system has many and diverse capabilities, no single user is going to use more than a small fraction of the system on any given day or even in one lifetime. As a result, the first of these sizes must depend on what the user is doing in a particular session - the programs being run - rather than on the total system size (the second type of measurement). Very few operating systems provide facilities that make this easy, and simulating it in an application is quite difficult. An application can simulate it, however, and a few existing systems and packages have managed to do so, but it is not to be taken lightly and requires an intimate understanding of the operating environment that must be tricked.
An application that provides linkage facilities that depend only on what programs the user asks for, as they are asked for, has several advantages in addition to keeping the bills down, the performance up, and the machine requirements at a minimum for the user's application. Among the most important of these is the ability to utilize user-supplied codes to supplement system facilities without having to create private copies of the system or major components of it. Such copies are a liability, not merely because of the costs or inefficiency they entail and the burdens they place on the user, but because they promote retention of ancient versions of systems and codes and subsequent conversion problems.
Very large virtual memories may provide some of the facilities that will help in tricking an operating system into behaving well when confronted with large systems, but they are not in themselves a solution. Misuse of such memories can introduce severe performance degradation. The major benefit of large virtual memories, in addition to programming convenience, is that as application size limits are reached the system degrades more or less gracefully; in the absence of virtual memories, the same situation leads to catastrophic system collapse. The goal and the challenge should be to avoid both alternatives, especially when the amount of software and data actually being used fall well within the host system's natural limits for application sizes.