Что день грядущий нам готовит? …
Итак, поговорим о том, куда идёт индустрия программного обеспечения, и куда она может прийти через 20-30 лет.
Многие сейчас считают, что развитие компьютерной индустрии сейчас целиком и полностью описывается законом, гласящим, что все характеристики удваиваются раз в полтора года. Но, к сожалению, это не так, потому что этот закон справедлив только в среднесрочной перспективе и перестаёт действовать, как только наступает технологический предел. Так вот, предел производительности одного непрерывного потока исполнения кода очень близок. И бесполезно говорить, что будущее за 64х и 128ми разрядными кристаллами, потому что производительность в основном зависит от количества последовательно выполняемых операций в секунду, а не от количества данных, которое можно обработать за эту операцию, потому что при работе типичных приложений (речь не идёт о легко распараллеливаемых специальных приложениях) каждая следующая операция использует результат предыдущей. И если даже результат предыдущей операции не используется, то всё равно, приходится ждать её завершения, из-за несовершенства архитектуры.
Из всего вышесказанного следует простой вывод, что дальнейшее наращивание производительности возможно только посредством наращивания количества процессоров, и/или компьютеров, и/или процессорных ядер, одновременно выполняющих конкретную программу, но для получения реального прироста в производительности нужно изменять всю концепцию прикладного программирования, структуру исполняемого кода, а, следовательно, вносить изменения или создавать новые языки программирования и средства разработки, содержащие встроенные средства для распараллеливания вычислений, меж процессного взаимодействия и синхронизации. И все эти средства разработки должны быть столь же простыми в использовании, как и такие инструменты как Delphi и Microsoft VS.
Но, если уж менять все концепции, то почему бы ни вложить в новые концепции задатки на будущее. А таковыми задатками могут являться средства для распределения вычислений на несколько компьютеров, связанных высокоскоростными (или не очень) каналами передачи данных. Также необходимы встроенные средства удалённого вызова процедур, и средства прозрачного переноса объектов с одной системы на другую, встроенные в языки программирования средства асинхронного вызова процедур и т.д.
И все эти средства должны быть прозрачны (или почти прозрачны) для разработчика. И всем этим арсеналом должна управлять операционная система, а разработчик только должен давать рекомендации.
Как частным следствие данной концепции, например, будет удалённое управление (Просто код, обрисовывающий пользовательский интерфейс исполняется на одной машине, а вычисления на другой машине, или группе машин.). Второе частное следствие это возможность апгрейда всего комплекса не заменой рабочих станций, а включением в состав комплекса одного или нескольких высокопроизводительных серверов(чтобы часть кода исполнялась на сервере, в часть на рабочей станции). Третьим частным следствием будет полная независимость пользователя от конкретной рабочей станции, возможность смены рабочей станции не прерывая процесса исполнения программы. Возможность отключить часть рабочих станций, не прерывая исполнения приложений, которые на них были запущены. Но, всё это, правда, требует пересмотра самой идеи и принципов организации файловой системы, что тоже вполне возможно. Необходимо, лишь чтобы оставшиеся машины в пределах комплекса смогли в сумме предоставить программе все те ресурсы, которые она потеряет при отключении одной вычислительной системы (рабочей станции или сервера). Более того, можно отключить сервер, не прекращая исполнения запущенных на нём программ, при тех же условиях.
Многим может показаться, что такое ну, тогда приводите аргументы в защиту своей точки зрения, а я либо соглашусь или опровергну. А если вам после прочтения данного поста показалось, что всё это уже существует, то прочтите пост внимательно ещё раз, и подумайте, существует ли система, обладающая всеми вышеперечисленными особенностями одновременно, а не какой-то подгруппой особенностей.
Многие сейчас считают, что развитие компьютерной индустрии сейчас целиком и полностью описывается законом, гласящим, что все характеристики удваиваются раз в полтора года. Но, к сожалению, это не так, потому что этот закон справедлив только в среднесрочной перспективе и перестаёт действовать, как только наступает технологический предел. Так вот, предел производительности одного непрерывного потока исполнения кода очень близок. И бесполезно говорить, что будущее за 64х и 128ми разрядными кристаллами, потому что производительность в основном зависит от количества последовательно выполняемых операций в секунду, а не от количества данных, которое можно обработать за эту операцию, потому что при работе типичных приложений (речь не идёт о легко распараллеливаемых специальных приложениях) каждая следующая операция использует результат предыдущей. И если даже результат предыдущей операции не используется, то всё равно, приходится ждать её завершения, из-за несовершенства архитектуры.
Из всего вышесказанного следует простой вывод, что дальнейшее наращивание производительности возможно только посредством наращивания количества процессоров, и/или компьютеров, и/или процессорных ядер, одновременно выполняющих конкретную программу, но для получения реального прироста в производительности нужно изменять всю концепцию прикладного программирования, структуру исполняемого кода, а, следовательно, вносить изменения или создавать новые языки программирования и средства разработки, содержащие встроенные средства для распараллеливания вычислений, меж процессного взаимодействия и синхронизации. И все эти средства разработки должны быть столь же простыми в использовании, как и такие инструменты как Delphi и Microsoft VS.
Но, если уж менять все концепции, то почему бы ни вложить в новые концепции задатки на будущее. А таковыми задатками могут являться средства для распределения вычислений на несколько компьютеров, связанных высокоскоростными (или не очень) каналами передачи данных. Также необходимы встроенные средства удалённого вызова процедур, и средства прозрачного переноса объектов с одной системы на другую, встроенные в языки программирования средства асинхронного вызова процедур и т.д.
И все эти средства должны быть прозрачны (или почти прозрачны) для разработчика. И всем этим арсеналом должна управлять операционная система, а разработчик только должен давать рекомендации.
Как частным следствие данной концепции, например, будет удалённое управление (Просто код, обрисовывающий пользовательский интерфейс исполняется на одной машине, а вычисления на другой машине, или группе машин.). Второе частное следствие это возможность апгрейда всего комплекса не заменой рабочих станций, а включением в состав комплекса одного или нескольких высокопроизводительных серверов(чтобы часть кода исполнялась на сервере, в часть на рабочей станции). Третьим частным следствием будет полная независимость пользователя от конкретной рабочей станции, возможность смены рабочей станции не прерывая процесса исполнения программы. Возможность отключить часть рабочих станций, не прерывая исполнения приложений, которые на них были запущены. Но, всё это, правда, требует пересмотра самой идеи и принципов организации файловой системы, что тоже вполне возможно. Необходимо, лишь чтобы оставшиеся машины в пределах комплекса смогли в сумме предоставить программе все те ресурсы, которые она потеряет при отключении одной вычислительной системы (рабочей станции или сервера). Более того, можно отключить сервер, не прекращая исполнения запущенных на нём программ, при тех же условиях.
Многим может показаться, что такое ну, тогда приводите аргументы в защиту своей точки зрения, а я либо соглашусь или опровергну. А если вам после прочтения данного поста показалось, что всё это уже существует, то прочтите пост внимательно ещё раз, и подумайте, существует ли система, обладающая всеми вышеперечисленными особенностями одновременно, а не какой-то подгруппой особенностей.