Программное обеспечение — заклинатели машин

«Конец программного обеспечения» был объявлен в 2000 году Salesforce.com. Затем он вышел на рынок и рекламировал себя как спасение для компаний, платящих большие деньги за продукты таким магнатам программного обеспечения, как, например, Oracle.

Вместо того, чтобы устанавливать дорогостоящие пакеты управления, клиенты стартапа запускали приложение Salesforce через Интернет, оплачивая только абонентскую плату, которая обычно составляла часть стоимости использования решений таких компаний, как SAP, PeopleSoft или Siebel Systems.

Однако приложения Salesforce.com все еще существуют. программное обеспечение. На самом деле речь шла не о какой-то цели, а об изменении модели использования программных продуктов. Лозунги «конца программного обеспечения» сейчас и там кажутся более радикальными. Однако может ли человечество на современном этапе развития технологий обойтись без кода и программирования? Сомнительно.

На протяжении десятилетий при проектировании всех видов систем была довольно распространенной тенденцией уделять больше внимания программированию, чем проектированию и настройке аппаратного обеспечения. Отсюда следуют пропорции состава рабочих бригад. В нашем технологическом мире практически ничего не существует без формы. Нередко в техническом проекте соотношение человеческих и нечеловеческих ресурсов между программистами и инженерами по аппаратному обеспечению составляет 10:1. Некоторые образно включают программное обеспечение в список основных элементов мира — так они добавляют код к огню, воде, земле и воздуху.

Джон фон Нейман и рабочий компьютер, 1952 г.

Архитектура фон Неймана стоит денег, но она работает

Каждое приложение и каждая система предназначены для решения проблем. В основном для этого используются алгоритм Ораз данные. Задача алгоритма — просто найти ответ в данных — максимально эффективно. Работа алгоритма имеет два аспекта: мягкий, т.е. программа (), и жесткий, т.е. оборудование (). Если алгоритм достаточно прост, программный слой можно пропустить. Таким образом, многие алгоритмы могут быть реализованы непосредственно в оборудовании, которое обрабатывает данные и находит решение без использования программного обеспечения. Этот подход использовался несколько десятилетий назад разработчиками оригинальных карманных калькуляторов, первых аркадных видеоигр и многих других электронных устройств. Если в машине нет ничего более сложного, чем простые операции, то интегральных схем TTL, которые уже использовались в 60-х годах, будет достаточно.

Однако проблема с реализацией алгоритмов непосредственно в аппаратном обеспечении заключается в том, что сложность требуемой аппаратной части быстро возрастает вместе со сложностью алгоритма. Каждое последующее вычисление или логический цикл требует увеличения числа физических логических вентилей. Традиционная архитектура использует закодированное в ней программное обеспечение, что позволяет работать с произвольно сложными алгоритмами без увеличения сложности устройств. Мы можем спроектировать одно стандартное оборудование — процессор, который можно использовать для выполнения любого количества произвольно сложных алгоритмов.

Этот удобный универсализм — великое изобретение, но, как и любая хорошая вещь, он имеет свою цену. По сравнению с программным обеспечением на обычном процессоре алгоритмы могут работать от 100 до 10 XNUMX. раз быстрее, если бы они были реализованы на правильно оптимизированном оборудовании. Рабочая нагрузка универсальных процессоров — если вы добавляете программные счетчики и загружаете инструкции — становится дорогостоящей в сочетании с эффективностью. Из-за последовательного характера программного обеспечения машины фон Неймана с трудом справляются с множеством задач.

Затраты на производительность архитектуры фон Неймана огромны, но до сих пор не перевешивают ее преимуществ. Алгоритм может быть реализован в нем в течение нескольких часов. Его разработка и аппаратная оптимизация, если это вообще возможно, могут занять месяцы. Своеобразный компромисс, достигнутый нами между аппаратным и программным обеспечением, кажется настолько привлекательным, что мир использует его уже более полувека, ничего принципиально не меняя, ограничиваясь лишь оптимизация.

Вывод из путаницы

Закон Мура речь шла о взрыве оборудования. Количество компонентов, из которых состоят интегральные схемы, увеличилось примерно на восемь порядков с 1965 года. Программное обеспечение, хотя его сложность тоже росла, менялось по другим правилам, которые сложно описать в короткой статье, но уж точно не прогрессирует в этой области за счет увеличения количества строк кода. И если именно это происходит по мере развития систем, количество не обязательно означает качество.

Okładka książki «Создание более безопасного мира: применение системного мышления к безопасности»

Программное обеспечение сильно отличается от старых добрых механических и электромеханических систем, которыми человек легко управляет с помощью простых инструкций и личного опыта. В мире программ небольшое редактирование текста в файле означает, что такое же количество кремния может превратиться из автопилота в самолете в систему управления запасами на складе.

Owa гибкость это одновременно и замечательная вещь в программном обеспечении, и его проклятие. Низкая стоимость изменений приводит к тому, что программное обеспечение постоянно меняется, и со временем программы имеют тенденцию к неограниченному росту.

«Проблема, — писала Нэнси Левесон, профессор аэронавтики и астронавтики Массачусетского технологического института в своей книге «Создание более безопасного мира: применение системного мышления к безопасности», — заключается в том, что мы создаем системы, которые выходят за рамки человеческого понимания. их».

Традиционно программисты писали программное обеспечение в виде набора жестких правил: когда происходит X, выполняется Y. Человек шаг за шагом указывает машине, что делать. Однако проблемы возникают, когда код усложняется, а затем наслаивается последующими исправлениями и дополнениями последующих авторов, не обязательно контактирующих друг с другом. В конечном счете действия машины становятся как бы равнодействующей всех инструкций в коде, ее самостоятельным выводом из этой программной мешанины. И машинный вывод может не иметь ничего общего с человеческими намерениями, отсюда системные сбои, остановки или несчастные случаи, иногда даже со смертельным исходом.

Пусть машины программируют себя

Конец традиционно понимаемого программирования, в котором человек пытается все предугадать и спроектировать, означает, в том числе, системы искусственного интеллекта. В случае методов машинного обучения этап программирования обычно опускается. Идея состоит в том, чтобы иметь нейронную сеть он разработал сам алгоритм.

Когда дело доходит до традиционного кода, написанного человеком, вы можете увидеть, как работает алгоритм. Между тем, в большинстве случаев мы толком не знаем, как работает машинный алгоритм, созданный искусственным интеллектом. Во многих отношениях нейронная активность системы ИИ для нас подобна коробке с неизвестным содержимым. Например, система просматривает тысячи изображений лиц и указывает, какие люди лгут, но мы не знаем, угадывает ли ИИ это по рисунку бровей, количеству пота на коже, хмурому взгляду или надуванию ноздрей. Однако после проверки мы видим, что система оценивает его правильно.

Таким образом, вместо традиционного программирования, когда программист пишет инструкции, которые шаг за шагом говорят компьютеру, что делать, программисты обучают машины распознавать ситуации и реагировать так, как мы хотим. Легко видеть, что развитие искусственного интеллекта предполагает согласие на независимость машины и отказ от попыток предсказать все, что было присуще старому. Мы не пытаемся постоянно держать систему за руку, а тренируем ее на следующих примерах. Мы учим автомобили ездить автономно. Компьютеры — распознавание лиц на фотографиях. Смартфоны — идентификация по почерку. Программа, отвечающая за работу этих систем, создается машиной.

И вот мы подошли к сути дела.

В результате этой процедуры исчезают проблемы, вызванные сложным кодом. Машина, несомненно, понимает созданный ею алгоритм. Мы лишь следим за тем, чтобы результат этого алгоритма соответствовал нашим намерениям. Программисты вместо того, чтобы писать код, станут менеджерами данных или кураторами, а заодно, конечно, хранителями и заклинателями машин.