Проект «Future Systems» IBM: Исследование 1970-х годов.

Введение

Исследовательский проект 1970-х годов. Проект Future Systems (FS) был научно-исследовательской и опытно-конструкторской работой, выполненной в IBM в начале 1970-х годов, направленной на разработку революционной линейки компьютерных продуктов, включая новые программные модели, которые должны были упростить разработку программного обеспечения, используя возможности современного мощного оборудования.

Предыстория

До конца 1960-х годов IBM получала основную часть прибыли от аппаратного обеспечения, комплектуя системы сопроводительным программным обеспечением и услугами для повышения их привлекательности. Ценник был только на аппаратное обеспечение, но эти цены включали в себя надбавку на программное обеспечение и услуги. Другие производители начали предлагать совместимое оборудование, в основном периферийные устройства, такие как ленточные и дисковые накопители, по цене, значительно более низкой, чем у IBM, что уменьшало потенциальную базу для возмещения стоимости программного обеспечения и услуг. Ситуация резко изменилась, когда Джин Амдал покинул IBM и основал компанию, производящую совместимые с System/370 системы, которые были быстрее и дешевле предложений IBM. В начале 1971 года внутренняя целевая группа IBM, Project Counterpoint, пришла к выводу, что бизнес совместимых мэйнфреймов действительно жизнеспособен и что основание для включения стоимости программного обеспечения и услуг в цену аппаратного обеспечения быстро исчезнет. Другой стратегической проблемой было то, что стоимость вычислительных ресурсов неуклонно снижалась, а затраты на программирование и эксплуатацию, состоящие в основном из расходов на персонал, неуклонно росли. Следовательно, доля бюджета заказчика на ИТ, доступная поставщикам аппаратного обеспечения, значительно сократится в ближайшие годы, а вместе с ней и база доходов IBM. IBM необходимо было, решая вопросы стоимости разработки и эксплуатации приложений в своих будущих продуктах, одновременно снизить общую стоимость ИТ для клиентов и увеличить свою долю в этих затратах. В то же время IBM подвергалась юридическим преследованиям за свою доминирующую позицию и политику включения программного обеспечения и услуг в цену аппаратного обеспечения, поэтому любая попытка "повторного комплектования" части своих предложений должна была быть убедительно обоснована исключительно техническими причинами, чтобы выдержать любые юридические претензии.

Доступ к данным

Одним из принципов проектирования FS был "склад единого уровня", который расширил идею виртуальной памяти (VM) для охвата постоянных данных. В традиционных системах программы выделяют память для хранения значений, представляющих данные. Эти данные обычно исчезают при выключении машины или выходе пользователя из системы. Чтобы обеспечить доступность этих данных в будущем, требуется дополнительный код для записи их на постоянное хранилище, такое как жесткий диск, и последующего чтения. Для упрощения этих распространенных операций в 1960-х годах появилось несколько движков баз данных, позволявших программам передавать данные движку для сохранения и последующего извлечения по запросу. Параллельно развивалась концепция виртуальной памяти. В ранних системах объем памяти, доступный программе для выделения под данные, ограничивался объемом основной памяти системы, который мог меняться в зависимости от таких факторов, как перемещение системы с одного компьютера на другой или выделение памяти другими программами. Системы виртуальной памяти решали эту проблему, определяя максимальный объем памяти, доступный всем программам – как правило, очень большое число, значительно превышающее объем физической памяти. Если программа запрашивает выделение памяти, которая физически недоступна, блок основной памяти записывается на диск, а освободившееся пространство используется для нового выделения. При запросе программой данных из выгруженной ("страничной" или "свопированной") области памяти, они невидимо загружаются обратно в основную память. Склад единого уровня – это, по сути, расширение виртуальной памяти на всю память, внутреннюю и внешнюю. Системы VM невидимо записывают память на диск, что является той же задачей, что и файловая система, поэтому нет причин, по которым она не может быть использована в качестве файловой системы. Вместо того чтобы программы выделяли память из "основной памяти", которая затем, возможно, перемещалась в другое резервное хранилище VM, вся память выделяется VM немедленно. Это означает, что нет необходимости в сохранении и загрузке данных – простое выделение памяти в памяти приводит к тому же эффекту, поскольку система VM записывает данные на диск. Когда пользователь снова входит в систему, эти данные и программы, которые их использовали (также находящиеся в той же объединенной памяти), становятся доступны немедленно в том же состоянии, в котором они были ранее. Вся концепция загрузки и сохранения упраздняется, программы и целые системы продолжают работу с того места, где они были остановлены, даже после перезагрузки машины. Эта концепция была исследована в системе Multics, но оказалась очень медленной, что было связано с ограничениями доступного оборудования, где основная память была реализована на ферритовых сердечниках, а резервное хранилище – на жестких дисках или магнитных барабанах – было значительно медленнее. С появлением новых типов энергонезависимой памяти, в частности, пузырьковой памяти, симуляции показали, что выполнение собственных инструкций FS на высокопроизводительной машине было медленнее, чем эмуляция System/370 на той же машине. Проект FS был окончательно закрыт, когда IBM осознала, что принятие системы клиентами будет значительно ниже, чем предполагалось изначально, поскольку не существовало разумного пути миграции приложений для клиентов, использующих архитектуру 360. Чтобы обеспечить максимальную свободу при проектировании действительно революционной системы, простота миграции приложений не была одной из основных целей проекта FS, но предполагалось, что она будет решена с помощью программных средств миграции, учитывающих новую архитектуру. В конечном итоге оказалось, что стоимость переноса огромных инвестиций пользователей в приложения, написанные на COBOL и ассемблере, на FS во многих случаях, вероятно, превысит стоимость приобретения новой системы.

One design principle of FS was a "single level store" which extended the idea of virtual memory (VM) to cover persistent data. In traditional designs, programs allocate memory to hold values that represent data. This data would normally disappear if the machine is turned off, or the user logs out. In order to have this data available in the future, additional code is needed to write it to permanent storage like a hard drive, and then read it back in the future. To ease these common operations, a number of database engines emerged in the 1960s that allowed programs to hand data to the engine which would then save it and retrieve it again on demand. Another emerging technology at the time was the concept of virtual memory. In early systems, the amount of memory available to a program to allocate for data was limited by the amount of main memory in the system, which might vary based on such factors as it is moved from one machine to another, or if other programs were allocating memory of their own. Virtual memory systems addressed this problem by defining a maximum amount of memory available to all programs, typically some very large number, much more than the physical memory in the machine. In the case that a program asks to allocate memory that is not physically available, a block of main memory is written out to disk, and that space is used for the new allocation. If the program requests data from that offloaded ("paged" or "spooled") memory area, it is invisibly loaded back into main memory again. A single level store is essentially an expansion of virtual memory to all memory, internal or external. VM systems invisibly write memory to a disk, which is the same task as the file system, so there is no reason it cannot be used as the file system. Instead of programs allocating memory from "main memory" which is then perhaps sent to some other backing store by VM, all memory is immediately allocated by the VM. This means there is no need to save and load data, simply allocating it in memory will have that effect as the VM system writes it out. When the user logs back in, that data, and the programs that were running it as they are also in the same unified memory, are immediately available in the same state they were before. The entire concept of loading and saving is removed, programs, and entire systems, pick up where they were even after a machine restart. This concept had been explored in the Multics system but proved to be very slow, but that was a side effect of available hardware where the main memory was implemented in core with a far slower backing store in the form of a hard drive or drum. With the introduction of new forms of non volatile memory, most notably bubble memory, Moreover, simulations showed that the execution of native FS instructions on the high end machine was slower than the System/370 emulator on the same machine. The FS project was finally terminated when IBM realized that customer acceptance would be much more limited than originally predicted because there was no reasonable application migration path for 360 architecture customers. In order to leave maximum freedom to design a truly revolutionary system, ease of application migration was not one of the primary design goals for the FS project, but was to be addressed by software migration aids taking the new architecture as a given. In the end, it appeared that the cost of migrating the mass of user investments in COBOL and assembly language based applications to FS was in many cases likely to be greater than the cost of acquiring a new system.