00:17 Введение
03:35 Порядки величин
06:55 Этапы оптимизации цепей поставок
12:17 S-кривые аппаратного обеспечения
15:52 До сих пор
17:34 Вспомогательные науки
20:25 Современные компьютеры
20:57 Задержка 1/2
27:15 Задержка 2/2
30:37 Вычисление, тактовая частота
36:36 Вычисление, конвейеризация, 1/3
39:11 Вычисление, конвейеризация, 2/3
40:27 Вычисление, конвейеризация, 3/3
46:36 Вычисление, суперскалярность 1/2
49:55 Вычисление, суперскалярность 2/2
56:45 Память 1/3
01:00:42 Память 2/3
01:06:43 Память 3/3
01:11:13 Хранение данных 1/2
01:14:06 Хранение данных 2/2
01:18:36 Пропускная способность
01:23:20 Заключение
01:27:33 Предстоящая лекция и вопросы аудитории
Описание
Современные цепи поставок требуют вычислительных ресурсов для работы, так же как моторизованные конвейеры требуют электричества. Однако, медленные системы цепей поставок остаются повсеместными, в то время как вычислительная мощность компьютеров увеличилась более чем в 10 000 раз с 1990 года. Недостаток понимания основных характеристик современных вычислительных ресурсов - даже среди IT- или кругов данных исследований - в значительной степени объясняет эту ситуацию. Программное обеспечение, лежащее в основе численных методов, не должно противоречить основному вычислительному субстрату.
Полный текст
Добро пожаловать на эту серию лекций по цепям поставок. Я Йоанн Верморель, и сегодня я буду рассказывать о “Современных компьютерах для цепей поставок”. Западные цепи поставок были цифровизированы уже давно, иногда до трех десятилетий назад. Компьютерные решения повсюду, и связанные с ними числовые методы имеют различные названия, такие как точки перезаказа, запасы по минимуму и максимуму и резервные запасы, с различной степенью контроля со стороны человека.
Тем не менее, если мы посмотрим на крупные компании, которые в настоящее время управляют эквивалентно крупными цепями поставок, мы увидим миллионы решений, которые по сути являются компьютерными и определяют эффективность цепи поставок. Таким образом, когда речь идет об улучшении эффективности цепи поставок, это быстро сводится к улучшению числовых методов, которые управляют цепью поставок. Здесь, неизменно, когда мы начинаем рассматривать более совершенные числовые методы любого вида, где мы хотим более точные модели и более точные прогнозы, эти более совершенные методы требуют гораздо больше вычислительных ресурсов.
Вычислительные ресурсы были проблемой для цепей поставок, так как они стоят много денег, и всегда есть следующий этап эволюции для следующей модели или следующей системы прогнозирования, которая требует в десять раз больше вычислительных ресурсов, чем предыдущая. Да, это может привести к дополнительной эффективности цепи поставок, но это связано с увеличением вычислительных затрат. За последние несколько десятилетий вычислительное оборудование продвигалось огромными темпами, но, как мы увидим сегодня, этот прогресс, хотя он все еще продолжается, часто противодействуется программному обеспечению предприятия. В результате программное обеспечение не становится быстрее с более современным оборудованием; наоборот, оно очень часто может становиться медленнее.
Цель этой лекции - внушить аудитории некоторую степень механического сочувствия, чтобы вы могли оценить, соответствует ли программное обеспечение предприятия, которое должно реализовывать числовые методы, предназначенные для достижения более высокой эффективности цепи поставок, вычислительному оборудованию, которое уже существует и будет существовать через десять лет, или оно противодействует и, следовательно, фактически не использует наиболее эффективно вычислительное оборудование, которое у нас есть сегодня.
Одним из самых загадочных аспектов современных компьютеров является диапазон порядков величин, которые в них задействованы. С точки зрения управления цепями поставок, у нас обычно есть около пяти порядков величин, и это уже предельно; обычно это даже не так. Пять порядков величин означает, что мы можем перейти от одной единицы к 100 000 единицам. Помните, я рассказывал об этом в предыдущих лекциях - это закон малых чисел в действии. Если у вас большое количество единиц, вы не будете обрабатывать их индивидуально; вы будете упаковывать их в коробки, и таким образом у вас останется гораздо меньшее количество коробок. Аналогично, если у вас есть много коробок, вы будете упаковывать их на поддоны и т.д., чтобы у вас было гораздо меньшее количество поддонов. Экономия масштаба позволяет прогнозировать количество, и с точки зрения управления цепями поставок, когда мы имеем дело с потоком физических товаров, 10% неэффективности уже считается довольно значительным.
В мире компьютеров все совсем иначе; мы имеем дело с 15 порядками величин, что абсолютно гигантская цифра. Мы переходим от одной единицы к одному миллиону миллиардов единиц, число настолько большое, что его даже очень сложно представить. Мы переходим от одного байта, который состоит всего из восьми бит и может использоваться для представления буквы или цифры, до петабайта, который составляет миллион гигабайтов. Петабайт - это примерный объем данных, которыми в настоящее время управляет Lokad, и крупные компании, занимающиеся управлением большими цепями поставок, также работают с наборами данных порядка петабайта.
Мы переходим от одной операции с плавающей запятой в секунду (FLOP) до одного петафлопа, что составляет миллион гигафлопсов. Эти порядки величин абсолютно гигантские и очень обманчивые. В результате, в области управления цепями поставок, где 10% считается неэффективностью, то, что обычно происходит в мире компьютеров, заключается не в том, чтобы быть неэффективным на 10%, а скорее в том, чтобы быть неэффективным в 10 раз, а иногда и на несколько порядков величин больше. Таким образом, если вы делаете что-то неправильно в терминах производительности в мире компьютеров, ваше наказание не будет составлять 10%; вместо этого ваша система будет работать в 10 раз медленнее, или в 100 раз, а иногда даже в тысячу раз медленнее, чем должна была бы работать. Вот что на самом деле находится на кону: достижение истинного соответствия, которое требует некоего механического сочувствия между корпоративным программным обеспечением и базовым вычислительным оборудованием.
При рассмотрении численного алгоритма, который должен обеспечивать более высокую производительность цепи поставок, существует ряд стадий зрелости, которые концептуально представляют интерес. Очевидно, на практике все может быть иначе, но это обычно то, что мы выявили в Lokad. Эти стадии можно суммировать следующим образом: заставить это работать, сделать это правильно, сделать это быстро и сделать это дешево.
“Заставить это работать” означает оценку того, действительно ли прототип численного алгоритма достигает заданных результатов, таких как более высокий уровень обслуживания, меньше мертвого запаса, лучшее использование активов или любая другая цель, которая является ценной с точки зрения управления цепями поставок. Целью является в первую очередь убедиться, что новый численный алгоритм действительно работает на первой стадии зрелости.
Затем вам нужно “сделать это правильно”. С точки зрения управления цепями поставок, это означает превращение того, что по сути был уникальным прототипом, в нечто с качеством производства. Обычно это включает в себя придание численному алгоритму определенной степени правильности по дизайну. Цепи поставок огромны, сложны и, что более важно, очень беспорядочны. Если у вас есть численный алгоритм, который очень хрупок, даже если численный метод хороший, очень легко сделать что-то неправильно, и в результате вы создаете гораздо больше проблем по сравнению с пользой, которую вы намеревались принести в первую очередь. Это не выигрышное предложение. Сделать это правильно - значит убедиться, что у вас есть нечто, что может быть развернуто в масштабе с минимальным трением. Затем вы хотите сделать этот численный алгоритм быстрым, и когда я говорю быстрым, я имею в виду быстрым с точки зрения времени настенных часов. Когда вы запускаете вычисление, вы должны получить результаты в течение нескольких минут, или, возможно, нескольких часов, но не более. Цепи поставок беспорядочны, и в истории вашей компании обязательно будет момент, когда возникнут нарушения, такие как застрявшие контейнерные суда в середине Суэцкого канала, пандемия или затопленный склад. Когда это происходит, вам нужно иметь возможность быстро реагировать. Я не говорю о реакции в следующие миллисекунды, но если у вас есть численные алгоритмы, которые занимают несколько дней для завершения, это создает огромное операционное трение. Вам нужны вещи, которые можно управлять в рамках короткого временного интервала для человека, поэтому они должны быть быстрыми.
Помните, что современное корпоративное программное обеспечение работает на облачных платформах, и вы всегда можете платить за больше вычислительных ресурсов на облачных вычислительных платформах. Таким образом, ваше программное обеспечение может быть быстрым только потому, что вы арендуете большую вычислительную мощность. Не обязательно, чтобы само программное обеспечение было правильно разработано для использования всей вычислительной мощности, которую может предоставить облако, но оно может быть быстрым и очень неэффективным только потому, что вы арендуете так много вычислительной мощности у своего провайдера облачных вычислений.
Следующий этап - сделать метод дешевым, то есть не использовать слишком много вычислительных ресурсов облачных вычислений. Если вы не перейдете к этой последней стадии, это означает, что вы никогда не сможете улучшить свой метод. Если у вас есть метод, который работает, правильный и быстрый, но потребляет много ресурсов, когда вы захотите перейти к следующей стадии численного алгоритма, которая неизбежно потребует больше вычислительных ресурсов, чем то, что вы используете в настоящее время, вы застрянете. Вам нужно сделать ваш метод очень эффективным, чтобы вы могли начать экспериментировать с численными алгоритмами, которые менее эффективны, чем то, что у вас есть в настоящее время.
Эта последняя стадия - это момент, когда вам действительно нужно использовать доступное в современных компьютерах аппаратное обеспечение. Вы можете обойтись первыми тремя стадиями без особой привязанности, но последняя стадия является ключевой. Помните, что если вы не достигнете стадии “сделать это дешево”, вы не сможете проводить итерации, и поэтому вы застрянете. Поэтому, даже если это последняя стадия, это итеративная игра, и важно пройти через все стадии, если вы хотите повторно итерировать.
Аппаратное обеспечение продолжает прогрессировать, и это выглядит как экспоненциальное развитие, но на самом деле это экспоненциальное развитие вычислительного оборудования состоит из тысяч S-кривых. S-кривая - это кривая, где вы вводите новый дизайн, процесс, материал или архитектуру, и изначально он не лучше того, что у вас было раньше. Затем начинает действовать эффект предполагаемого инновационного решения, и у вас происходит нарастание, за которым следует плато после того, как вы извлекли все преимущества инновации. Плато S-кривых характерно для прогресса в области компьютерного оборудования, которое состоит из тысяч таких кривых. С точки зрения простого человека это выглядит как экспоненциальный рост. Однако эксперты видят, что отдельные S-кривые достигают плато, что может привести к пессимистическому взгляду. Даже эксперты не всегда видят появление новых S-кривых, которые удивляют всех и продолжают экспоненциальный рост прогресса.
Хотя аппаратное обеспечение продолжает прогрессировать, темпы прогресса ни в какое сравнение не идут с тем, что мы испытали в 1980-х или 1990-х годах. Темпы развития теперь намного медленнее и довольно предсказуемы, в основном из-за массовых инвестиций, необходимых для строительства новых заводов по производству вычислительного оборудования. Эти инвестиции часто составляют сотни миллионов долларов, обеспечивая прозрение на пять-десять лет вперед. Хотя прогресс замедлился, у нас все еще есть довольно точное представление о том, что произойдет в области развития вычислительного оборудования в следующее десятилетие.
Урок для предприятий, реализующих численные методы в своем программном обеспечении, заключается в том, что вы не можете пассивно ожидать, что будущее аппаратное обеспечение сделает все лучше для вас. Аппаратное обеспечение все еще продвигается, но для захвата этого прогресса требуется усилие со стороны программного обеспечения. Вы сможете делать больше с аппаратным обеспечением, которое будет существовать через десять лет, но только если архитектура ядра вашего предприятийного программного обеспечения будет соответствовать основному вычислительному оборудованию. В противном случае вы можете сделать хуже, чем делаете сегодня, что не так неразумно, как может показаться.
Эта лекция является первой главой в этой серии лекций о цепочках поставок. Я еще не закончил третью главу о персонажах цепочек поставок. В следующих лекциях я, вероятно, буду чередовать между настоящей главой, где я рассказываю о вспомогательных науках цепочек поставок, и третьей главой о персонажах цепочек поставок.
В самой первой главе пролога я представил свои взгляды на цепочку поставок как на область исследования и практику. Мы видели, что цепочка поставок в основном представляет собой совокупность сложных проблем, в отличие от простых проблем, страдающих от враждебного поведения и конкурентных игр. Поэтому мы должны уделять большое внимание методологии, потому что наивные прямые методологии плохо справляются в этой области. Вот почему вторая глава была посвящена методологии, необходимой для изучения цепочек поставок и установления практик для их улучшения со временем.
Третья глава, “Персонажи цепочек поставок”, сосредоточена на характеристиках самих проблем цепочек поставок, с девизом “влюбиться в проблему, а не в решение”. Четвертая глава, которую мы открываем сегодня, посвящена вспомогательным наукам цепочек поставок.
Вспомогательные науки - это дисциплины, которые поддерживают изучение другой дисциплины. Здесь нет суждения о ценности; это не о том, что одна дисциплина превосходит другую. Например, медицина не превосходит биологию, но биология является вспомогательной наукой для медицины. Взгляд на вспомогательные науки хорошо установлен и распространен во многих областях исследований, таких как медицинские науки и история.
В медицинских науках вспомогательными науками являются биология, химия, физика и социология, среди других. Современный врач не будет считаться компетентным, если у него нет знаний физики. Например, понимание основ физики необходимо для интерпретации рентгеновского снимка. То же самое верно и для истории, у которой есть долгий ряд вспомогательных наук.
Когда речь идет о цепочке поставок, одна из моих самых больших критик ципочек поставок - это то, что они рассматривают эту тему, не углубляясь в вспомогательные науки. Они рассматривают цепочку поставок, как если бы она была изолированным, самостоятельным куском знаний. Однако я считаю, что современная практика цепочки поставок может быть достигнута только путем полного использования вспомогательных наук цепочек поставок. Одной из таких вспомогательных наук, и фокусом сегодняшней лекции, является вычислительное оборудование.
Эта лекция не является строго лекцией о цепочке поставок, а скорее о вычислительном оборудовании с учетом применения в цепочке поставок. Я считаю, что это фундаментально для практики цепочки поставок в современном стиле, в отличие от того, как это делалось сто лет назад.
Давайте рассмотрим современные компьютеры. В этой лекции мы рассмотрим, что они могут сделать для цепочки поставок, особенно сосредоточившись на аспектах, которые имеют огромное влияние на производительность корпоративного программного обеспечения. Мы рассмотрим задержку, вычисление, память, хранение данных и пропускную способность.
Скорость света составляет около 30 сантиметров в наносекунду, что относительно медленно. Если учесть характерное расстояние интереса для современного ЦП, работающего на частоте 5 гигагерц (5 миллиардов операций в секунду), расстояние, которое свет может пройти за 0,2 наносекунды, составляет всего 3 сантиметра. Это означает, что из-за ограничения скорости света взаимодействия не могут происходить на расстоянии более 3 сантиметров. Это жесткое ограничение, накладываемое законами физики, и неясно, сможем ли мы когда-нибудь его преодолеть.
Задержка - это чрезвычайно жесткое ограничение. С точки зрения цепочки поставок, у нас есть как минимум два распределения вычислительного оборудования. Когда я говорю о распределенном вычислительном оборудовании, я имею в виду вычислительное оборудование, которое включает множество устройств, не могущих занимать одно и то же физическое пространство. Очевидно, вам нужно держать их отдельно только потому, что они имеют свои размеры. Однако первая причина, по которой нам нужно распределенное вычислительное оборудование, - это характер цепочек поставок, которые географически распределены. По световой скорости, даже если у вас есть устройства, которые находятся всего в трех метрах друг от друга, это уже очень медленно, потому что для совершения кругового пути требуется 100 тактов. Три метра - это довольно большое расстояние с точки зрения скорости света и тактовой частоты современных ЦП.
Еще один тип распределения - это горизонтальное масштабирование. Современный способ иметь больше вычислительных ресурсов в нашем распоряжении - это не иметь вычислительное устройство, которое в 10 или миллион раз мощнее; так оно не спроектировано. Если вам нужно больше вычислительных ресурсов, вам нужны дополнительные вычислительные устройства, больше процессоров, больше чипов памяти и больше жестких дисков. Именно накоплением аппаратных средств вы можете иметь больше вычислительных ресурсов в своем распоряжении. Однако все эти устройства занимают место, и поэтому вы распределяете свое вычислительное оборудование только потому, что не можете централизовать его в компьютере шириной в сантиметр.
Что касается задержек, рассмотрим такие задержки, которые есть в профессиональном интернете (задержки, которые можно получить в дата-центре, а не через Wi-Fi дома), мы уже находимся в пределах 30% от скорости света. Например, задержка между дата-центром недалеко от Парижа, Франция, и Нью-Йорком, США, составляет всего 30% от скорости света. Это невероятное достижение для человечества; информация передается через интернет почти со скоростью света. Да, есть еще место для улучшений, но мы уже близки к жестким ограничениям, накладываемым физикой.
В результате даже сейчас есть компании, которые хотят проложить кабель через дно Северного Ледовитого океана, чтобы соединить Лондон с Токио с помощью кабеля, который пройдет под Северным полюсом, только чтобы сократить несколько миллисекунд задержки для финансовых транзакций. В основе задержки и скорости света лежат очень реальные проблемы, и интернет, который у нас есть, по сути, настолько хорош, насколько он когда-либо будет, если не произойдут прорывы в физике. Однако ничего подобного не грозит в ближайшее десятилетие.
В связи с тем, что задержка является очень сложной проблемой, это имеет значительные последствия для корпоративного программного обеспечения. Передачи информации в виде потока являются смертельными, и производительность вашего корпоративного программного обеспечения в значительной степени будет зависеть от количества передач между различными подсистемами, существующими в вашем программном обеспечении. Количество передач будет характеризовать несжимаемую задержку, которую вы испытываете. Минимизация передач и улучшение задержек является, для большинства частей корпоративного программного обеспечения, включая те, которые посвящены предиктивной оптимизации цепей поставок, главной проблемой. Смягчение задержек часто равносильно достижению более высокой производительности.
Интересный трюк, хотя и нечто, что не все в этой аудитории будут использовать в производстве, заключается в решении проблем, вызванных задержкой. Время само по себе становится неуловимым и размытым, когда вы входите в область наносекундных вычислений. Точные часы трудно найти в распределенных вычислениях, и их отсутствие вводит сложности в распределенное корпоративное программное обеспечение. Для синхронизации различных частей системы требуется множество передач. Из-за отсутствия точных часов вы приходите к альтернативным алгоритмическим решениям, таким как векторные часы или многокомпонентные временные метки, которые являются структурами данных, отражающими частичное упорядочение часов устройств в вашей системе. Эти дополнительные передачи могут негативно сказаться на производительности.
Умное решение, применяемое Google более десяти лет назад, заключалось в использовании атомных часов микрочипового масштаба. Разрешение этих атомных часов значительно превосходит разрешение кварцевых часов, которые используются в электронных часах или компьютерах. NIST продемонстрировал новую установку атомных часов микрочипового масштаба с еще более точным ежедневным дрейфом. Google использовал внутренние атомные часы для синхронизации различных частей своей глобально распределенной SQL-базы данных, Google Spanner, чтобы сэкономить передачи и улучшить производительность на глобальном уровне. Это способ обойти задержку с помощью очень точных измерений времени.
Взглянув вперед на десятилетие, Google, вероятно, не будет последней компанией, которая будет использовать подобный умный трюк, и они относительно доступны, стоимость атомных часов микрочипового масштаба составляет около 1500 долларов за штуку.
Теперь давайте рассмотрим вычисления, которые связаны с выполнением вычислений на компьютере. Скорость часов была волшебным ингредиентом улучшения в 80-х и 90-х годах. Действительно, если бы вы могли удвоить скорость часов вашего компьютера во всех областях, вы бы эффективно удвоили производительность вашего компьютера, независимо от того, какое программное обеспечение используется. Все программное обеспечение стало бы линейно быстрее в соответствии со скоростью часов. Увеличение скорости часов является чрезвычайно интересным, и оно все еще улучшается, хотя улучшение с течением времени замедлилось. Почти 20 лет назад скорость часов составляла около 2 ГГц, а сейчас она составляет 5 ГГц.
Основной причиной замедления улучшения является проблема энергетической стены. Проблема заключается в том, что при увеличении скорости часов на чипе вы примерно вдвое увеличиваете энергопотребление, а затем вам приходится рассеивать эту энергию. Проблема заключается в тепловом рассеивании, потому что, если вы не можете рассеять энергию, ваше устройство нагревается до такой степени, что повреждает само устройство. В настоящее время полупроводниковая промышленность перешла от увеличения количества операций в секунду к увеличению количества операций на ватт.
Это правило увеличения на 30% удвоения энергопотребления имеет двойственный характер. Если вы готовы отказаться от четверти мощности вашего процессора за единицу времени на ЦПУ, вы фактически можете разделить энергопотребление пополам. Это особенно интересно для смартфонов, где энергосбережение крайне важно, а также для облачных вычислений, где одним из ключевых факторов стоимости является энергия сама по себе. Чтобы иметь экономически эффективную вычислительную мощность облачных вычислений, дело не в том, чтобы иметь супербыстрые ЦПУ, а в том, чтобы иметь ЦПУ с пониженной тактовой частотой, которые могут быть медленными, как 1 ГГц, так как они обеспечивают большее количество операций в секунду для вашего энергетического вложения.
Стена мощности является такой проблемой, что современные архитектуры ЦПУ используют все виды уловок, чтобы смягчить ее. Например, современные ЦПУ могут регулировать тактовую частоту, временно повышая ее на секунду или около того, а затем снижая ее для рассеивания тепла. Они также могут использовать то, что называется темным кремнием. Идея заключается в том, что если ЦПУ может чередовать горячие области на чипе, то энергию легче рассеивать, чем всегда иметь активную одну и ту же область на каждом тактовом цикле. Это очень важный элемент современного дизайна. С точки зрения корпоративного программного обеспечения это означает, что вы действительно хотите иметь возможность масштабироваться. Вы хотите иметь возможность делать больше с гораздо большим количеством ЦПУ, но индивидуально эти процессоры будут слабее, чем предыдущие, которые у вас были. Речь не идет о том, чтобы получить лучшие процессоры в том смысле, что все лучше во всех отношениях; речь идет о том, чтобы иметь процессоры, которые дают вам больше операций на ватт, и этот тренд будет продолжаться.
Возможно, через десять лет мы с трудом достигнем семи или восьми гигагерц, но я даже не уверен, что мы туда доберемся. Когда я смотрю на тактовую частоту в 2021 году в большинстве облачных провайдеров вычислений, она больше соответствует обычно 2 ГГц, поэтому мы вернулись к тактовой частоте, которую мы имели 20 лет назад, и это самое экономичное решение.
Достижение текущей производительности ЦПУ требовало ряда ключевых инноваций. Я собираюсь представить несколько из них, особенно тех, которые оказывают наибольшее влияние на разработку корпоративного программного обеспечения. На этом экране вы видите поток инструкций последовательного процессора, так как процессоры были сделаны в основном до начала 80-х годов. У вас есть ряд инструкций, которые выполняются от верхней части графа к нижней, представляя время. Каждая инструкция проходит через ряд этапов: получение, декодирование, выполнение и запись обратно.
Во время этапа получения вы получаете инструкцию, регистр, берете следующую инструкцию, увеличиваете счетчик инструкций и готовите ЦПУ. Во время этапа декодирования вы декодируете инструкцию и генерируете внутренний микрокод, который ЦПУ выполняет внутренне. Этап выполнения включает получение соответствующих входных данных из регистров и выполнение фактического вычисления, а этап записи обратно включает получение результата, который вы только что вычислили, и помещение его в один из регистров. В этом последовательном процессоре каждый этап требует одного тактового цикла, поэтому для выполнения одной инструкции требуется четыре тактовых цикла. Как мы видели, очень сложно увеличить частоту тактовых циклов из-за множества осложнений.
Основной трюк, который используется с начала 80-х годов и далее, называется конвейеризацией. Конвейеризация может значительно ускорить вычисление вашего процессора. Идея заключается в том, что, благодаря тому, что каждая инструкция проходит через ряд этапов, мы будем перекрывать этапы, и сам ЦПУ будет иметь целый конвейер инструкций. На этой диаграмме вы можете увидеть ЦПУ с конвейером глубиной четыре, где всегда выполняются четыре инструкции одновременно. Однако они не находятся в одном и том же этапе: одна инструкция находится на этапе получения, одна - на этапе декодирования, одна - на этапе выполнения, а одна - на этапе записи обратно. С помощью этого простого трюка, представленного здесь в виде конвейерного процессора, мы увеличили эффективность процессора в четыре раза, просто конвейеризовав операции. Все современные ЦПУ используют конвейеризацию.
Следующий этап этого улучшения называется суперконвейеризацией. Современные ЦПУ выходят далеко за рамки простой конвейеризации. На самом деле количество этапов, вовлеченных в реальный современный ЦПУ, составляет около 30 этапов. На графике вы можете увидеть ЦПУ с 12 этапами в качестве примера, но на самом деле их будет около 30. С этим более глубоким конвейером может выполняться одновременно 12 операций, что очень хорошо для производительности, при этом используя тот же тактовый цикл.
Однако возникает новая проблема: следующая инструкция начинается до того, как завершится предыдущая. Это означает, что если у вас есть операции, которые зависят друг от друга, у вас возникает проблема, потому что вычисление входных данных для следующей инструкции еще не готово, и вам приходится ждать. Мы хотим использовать весь доступный нам конвейер, чтобы максимизировать вычислительную мощность. Таким образом, современные ЦПУ получают не только одну инструкцию за раз, а примерно 500 инструкций за раз. Они заглядывают далеко вперед в списке предстоящих инструкций и переупорядочивают их, чтобы смягчить зависимости, переплетая потоки выполнения, чтобы использовать полную глубину конвейера.
Есть много вещей, которые усложняют эту операцию, наиболее заметными из которых являются ветви. Ветвь - это просто условие в программировании, например, когда вы пишете оператор “if”. Результат условия может быть истинным или ложным, и в зависимости от результата ваша программа выполнит одну логическую часть или другую. Это усложняет управление зависимостями, потому что ЦП должен угадать направление будущих ветвей. Современные ЦП используют предсказание ветвления, которое включает в себя простые эвристики и имеет очень высокую точность прогнозирования. Они могут предсказывать направление ветвей с точностью более 99%, что лучше, чем то, что большинство из нас могут сделать в реальном контексте цепочки поставок. Эта точность необходима для использования сверхглубоких конвейеров.
Чтобы дать вам представление о том, какие эвристики используются для предсказания ветвления, очень простой эвристикой является сказать, что ветвь пойдет таким же путем, в том же направлении, что и в прошлый раз. Эта простая эвристика дает вам примерно 90% точности, что довольно хорошо. Если вы добавите к этой эвристике некоторую особенность, которая заключается в том, что ветвь пойдет в том же направлении, что и в прошлый раз, но вы должны учесть источник, то получите примерно 95% точности. Современные ЦП фактически используют довольно сложные перцептроны, которые являются техникой машинного обучения, для предсказания направления ветвей.
При правильных условиях вы можете достаточно точно предсказывать ветви и, таким образом, использовать полный конвейер, чтобы получить максимальную производительность современного процессора. Однако с точки зрения разработки программного обеспечения вам нужно хорошо взаимодействовать с вашим процессором, особенно с предсказанием ветвления. Если вы не взаимодействуете должным образом, это означает, что предсказатель ветвления ошибется, и когда это происходит, ЦП предсказывает направление ветви, организует конвейер и начинает выполнять вычисления заранее. Когда ветвь фактически встречается и вычисление фактически выполняется, ЦП понимает, что предсказание ветвления было неверным. Неправильное предсказание ветвления не приводит к неправильному результату; это приводит к потере производительности. ЦП не имеет другого выбора, кроме как очистить весь конвейер или большую его часть, подождать, пока будут выполнены другие вычисления, а затем снова запустить вычисление. Потеря производительности может быть очень значительной, и вы легко можете потерять один или два порядка производительности из-за логики корпоративного программного обеспечения, которое не взаимодействует должным образом с логикой предсказания ветвления вашего ЦП.
Еще один заметный трюк помимо конвейеризации - это суперскалярная инструкция. ЦП обычно обрабатывает скаляры или пары скаляров одновременно - например, два числа с плавающей запятой с точностью 32 бита. Они выполняют скалярные операции, в основном обрабатывая одно число за раз. Однако современные ЦП на протяжении последнего десятилетия практически все оснащены суперскалярной инструкцией, которая может фактически обрабатывать несколько векторов чисел и выполнять векторные операции непосредственно. Это означает, что ЦП может взять вектор, скажем, восемь чисел с плавающей запятой, и второй вектор из восьми чисел с плавающей запятой, выполнить сложение и получить вектор чисел с плавающей запятой, представляющий результаты этого сложения. Все это делается за один такт.
Например, специализированные наборы инструкций, такие как AVX2, позволяют выполнять операции с учетом 32 бит точности с пакетами из восьми чисел, в то время как AVX512 позволяет делать это с пакетами из 16 чисел. Если вы способны использовать эти инструкции, это означает, что вы буквально можете получить порядок увеличения скорости обработки, потому что одна инструкция, один такт, выполняет гораздо больше вычислений, чем обработка чисел по одному. Этот процесс известен как SIMD (Single Instruction, Multiple Data) и очень мощен. Он был основным двигателем прогресса за последнее десятилетие в терминах вычислительной мощности, и современные процессоры все больше основаны на векторах и суперскалярных инструкциях. Однако с точки зрения корпоративного программного обеспечения это относительно сложно. С конвейеризацией ваше программное обеспечение должно вести себя хорошо, и, возможно, оно случайно ведет себя хорошо с предсказанием ветвления. Однако, когда речь идет о суперскалярной инструкции, ничего случайного нет. Вашему программному обеспечению действительно нужно явно выполнять некоторые действия, в большинстве случаев, чтобы использовать эту дополнительную вычислительную мощность. Вы не получаете ее бесплатно; вам нужно принять этот подход, и, как правило, вам нужно организовать сами данные так, чтобы у вас была параллельность данных, и данные организованы таким образом, чтобы быть подходящими для SIMD-инструкций. Это не ракетная наука, но это не происходит случайно, и это дает вам огромный прирост в вычислительной мощности.
Теперь современные процессоры могут иметь множество ядер, и одно ядро процессора может давать вам отдельный поток инструкций. С очень современными процессорами, которые имеют множество ядер, типично современные процессоры могут достигать до 64 ядер, то есть 64 независимых параллельных потока выполнения. Вы можете достичь примерно одного терафлопса, что является верхним пределом производительности, которую вы можете получить от очень современного процессора. Однако, если вы хотите превзойти это, вы можете посмотреть на графические процессоры (GPU). Несмотря на то, что вы можете подумать, эти устройства могут использоваться для задач, не имеющих ничего общего с графикой.
Графический процессор, например, от NVIDIA, является суперскалярным процессором. Вместо того, чтобы иметь до 64 ядер, как у высокопроизводительных процессоров, у графических процессоров может быть более 10 000 ядер. Эти ядра гораздо проще и не такие мощные или быстрые, как обычные ядра процессоров, но их гораздо больше. Они поднимают SIMD на новый уровень, где вы можете обрабатывать не только пакеты из 8 или 16 чисел за раз, но буквально тысячи чисел за раз для выполнения векторных инструкций. С помощью графических процессоров вы можете достичь диапазона от 30 терафлопсов на одном устройстве, что является огромным. Лучшие процессоры на рынке могут дать вам один терафлопс, в то время как лучшие графические процессоры дадут вам более 30 терафлопсов. Это более чем порядок разницы, что очень значительно.
Если вы даже превысите это, для специализированных типов вычислений, таких как линейная алгебра (кстати, такие вещи, как машинное обучение и глубокое обучение, по сути, являются матрично-связанной линейной алгеброй повсюду), вы можете иметь процессоры, такие как TPU (Tensor Processing Units). Google решила назвать их тензорами из-за TensorFlow, но на самом деле TPUs было бы лучше назвать процессорами матричного умножения. Интересно то, что при умножении матриц не только вовлечено множество параллелизма данных, но также вовлечено огромное количество повторений, потому что операции являются высоко повторяющимися. Организуя TPU как систолический массив, который по сути является двумерной сеткой с вычислительными блоками на сетке, вы можете преодолеть барьер петафлопса - достигнуть более 1000 терафлопсов на одном устройстве. Однако есть одно но: Google делает это с помощью 16-битных чисел с плавающей запятой вместо обычных 32-битных. С точки зрения цепочки поставок, 16 бит точности не плохо; это означает, что у вас есть около 0,1% точности в ваших операциях, и для многих операций машинного обучения или статистических операций 0,1% точности вполне достаточно, если делать правильно и без накопления смещения.
То, что мы видим, это то, что путь прогресса в терминах вычислительного оборудования, когда речь идет только о вычислениях, заключается в том, чтобы использовать более специализированные и более жесткие устройства. Благодаря этой специализации вы можете достичь огромного прироста вычислительной мощности. Если вы переходите от суперскалярной инструкции, вы получаете порядок разницы; если вы используете графическую карту, вы получаете один или два порядка разницы; и если вы используете чистую линейную алгебру, вы получаете в основном два порядка разницы. Это очень значительно.
Кстати, все эти аппаратные конструкции являются двумерными. Современные микросхемы и структуры обработки очень плоские. Современный процессор не включает более 20 слоев, и поскольку эти слои имеют толщину всего несколько микрон, ЦПУ, графические процессоры или TPU по сути являются плоскими структурами. Вы можете подумать: “А что насчет третьего измерения?” Оказывается, что из-за проблемы стены мощности, которая заключается в проблеме отвода энергии, мы не можем действительно перейти к третьему измерению, потому что мы не знаем, как эвакуировать всю энергию, которая вливается в устройство.
То, что мы можем предсказать на следующее десятилетие, заключается в том, что эти устройства останутся по сути двумерными. С точки зрения корпоративного программного обеспечения, самый важный урок заключается в том, что вам нужно инженерировать параллелизм данных прямо в ядре вашего программного обеспечения. Если вы этого не сделаете, то вы не сможете использовать весь прогресс, который происходит в отношении сырой вычислительной мощности. Однако это не может быть после мыслей. Это должно происходить на самом базовом уровне архитектуры, на уровне, на котором вы организуете все данные, которые должны быть обработаны в ваших системах. Если вы этого не сделаете, вы застрянете с процессорами, которые были два десятилетия назад.
Теперь, в начале 80-х годов, память была такой же быстрой, как процессоры, что означает, что один такт был равен одному такту для памяти и одному для ЦП. Однако это уже не так. С течением времени, начиная с 80-х годов, соотношение между скоростью памяти и задержками при доступе к данным, уже находящимся в регистрах процессора, только увеличивалось. Мы начали с соотношения один к одному, и теперь у нас обычно соотношение больше тысячи. Эта проблема известна как проблема памятной стены, и она только увеличивается на протяжении последних четырех десятилетий. В настоящее время она все еще увеличивается, хотя и очень медленно, в основном потому, что тактовая частота процессоров увеличивается очень медленно. В связи с тем, что процессоры не продвигаются сильно в плане тактовой частоты, проблема памятной стены больше не увеличивается. Однако место, на котором мы находимся в данный момент, крайне несбалансировано, где доступ к памяти фактически на три порядка медленнее, чем доступ к данным, которые уже удобно находятся внутри процессора.
Эта перспектива полностью разрушает все классические алгоритмы, так как они все еще преподаются в большинстве университетов. Классическая алгоритмическая точка зрения предполагает, что у вас есть одинаковое время доступа к памяти, что означает, что доступ к любому биту памяти занимает одинаковое количество времени. Но в современных системах это совершенно не так. Время доступа к определенной части памяти очень сильно зависит от того, где находятся фактические данные физически в вашей компьютерной системе.
С точки зрения корпоративного программного обеспечения оказывается, что, к сожалению, большинство конструкций программного обеспечения, которые были созданы в 80-х и 90-х годах, полностью игнорировали эту проблему, потому что она была очень незначительной в течение первого десятилетия. Она действительно увеличилась только за последние два десятилетия, но в результате большинство шаблонов, которые можно наблюдать в современном корпоративном программном обеспечении, полностью противоречат этому дизайну, потому что они предполагают, что у вас есть постоянное время доступа ко всей памяти.
Кстати, если вы начнете думать о языках программирования, таких как Python (впервые выпущен в 1989 году) или Java (в 1995 году) с поддержкой объектно-ориентированного программирования, они очень сильно противоречат тому, как работает память в современных компьютерах. Когда у вас есть объекты, и это еще хуже, если у вас есть позднее связывание, как в Python, это означает, что для выполнения любых операций вам придется следовать указателям и делать случайные переходы в памяти. Если один из этих переходов окажется неудачным, потому что это часть, которая уже не находится в процессоре, это может быть в тысячу раз медленнее. Это очень большая проблема.
Чтобы лучше понять масштаб памятной стены, интересно посмотреть на типичные задержки в современном компьютере. Если мы пересчитаем эти задержки в человеческих терминах, предположим, что процессор работает с одним тактом в секунду. При таком предположении типичная задержка ЦП будет составлять одну секунду. Однако, если мы хотим получить доступ к данным в памяти, это может занять до шести минут. Таким образом, в то время как вы можете выполнять одну операцию в секунду, если вы хотите получить доступ к чему-то в памяти, вам придется ждать шесть минут. И если вы хотите получить доступ к чему-то на диске, это может занять до месяца или даже целого года. Это невероятно долго, и в этом заключается то, о чем я упоминал в самом начале этой лекции, когда говорил о порядках производительности. Когда вы имеете дело с 15 порядками производительности, это очень обманчиво; вы не всегда осознаете огромный удар по производительности, который может возникнуть, когда вам приходится ждать эквивалента человеческого времени в месяцы, если вы не помещаете информацию в правильное место. Это абсолютно гигантская проблема.
Кстати, инженеры корпоративного программного обеспечения не единственные, кто борется с этой эволюцией современного аппаратного обеспечения. Если мы посмотрим на задержки, которые мы получаем с помощью сверхбыстрых SSD-карт, таких как серия Intel Optane, можно увидеть, что половина задержки при доступе к памяти на этом устройстве на самом деле вызвана накладными расходами самого ядра, в данном случае ядра Linux. Это сама операционная система, которая генерирует половину задержки. Что это означает? Это означает, что даже у людей, которые разрабатывают Linux, есть еще некоторая работа, чтобы догнать современное оборудование. Тем не менее, это большой вызов для всех.
Однако это действительно вредит корпоративному программному обеспечению, особенно при мысли о оптимизации цепочки поставок, из-за того, что у нас есть огромное количество данных для обработки. Уже с самого начала это довольно сложное предприятие. С точки зрения корпоративного программного обеспечения вам действительно нужно принять дизайн, который хорошо работает с кэшем, потому что кэш содержит локальные копии, к которым доступ происходит быстрее и ближе к ЦП.
Суть заключается в том, что при доступе к байту в основной памяти вы не можете получить доступ только к одному байту в современном программном обеспечении. Когда вы хотите получить доступ даже к одному байту в ОЗУ, аппаратное обеспечение фактически скопирует 4 килобайта, по сути, всю страницу размером 4 килобайта. Основное предположение состоит в том, что когда вы начинаете читать байт, следующий байт, который вы запросите, будет следующим. Это принцип локальности, что означает, что если вы придерживаетесь этого правила и обеспечиваете доступ, сохраняющий локальность, то у вас может быть память, которая работает почти так же быстро, как ваш процессор.
Однако для этого требуется соответствие между доступом к памяти и локальностью данных. В частности, существует множество языков программирования, таких как Python, которые не обеспечивают такие вещи изначально. Напротив, они представляют собой огромную проблему для достижения какой-либо степени локальности. Это огромная борьба, и в конечном итоге это битва, где у вас есть язык программирования, разработанный вокруг паттернов, которые полностью противоречат доступному аппаратному обеспечению. Эта проблема не изменится в ближайшее десятилетие; она только ухудшится.
Таким образом, с точки зрения корпоративного программного обеспечения вы хотите обеспечить локальность данных, но также минимизацию. Если вы сможете уменьшить размер данных, они будут работать быстрее. Это не очень интуитивно, но если вы сможете уменьшить размер данных, обычно устраняя некоторую избыточность, ваша программа будет работать быстрее, потому что вы будете более дружелюбны к кэшу. Вы сможете поместить больше актуальных данных в более низкие уровни кэша с гораздо более низкими задержками, как показано на этом дисплее.
Наконец, давайте обсудим конкретно случай DRAM. DRAM буквально является физическим компонентом, который составляет ОЗУ, которое вы используете для своего настольного рабочего места или сервера в облаке. DRAM также называется основной памятью, которая состоит из чипов DRAM. За последнее десятилетие в терминах цены DRAM едва уменьшилась. Мы перешли от 5 долларов за гигабайт до 3 долларов за гигабайт через десять лет. Цена ОЗУ все еще снижается, хотя и не очень быстро. Она застаивается на следующие несколько лет, и из-за того, что на этом рынке есть только три крупных игрока, которые имеют возможность производить DRAM в масштабе, очень маловероятно, что в этом рынке произойдет что-то неожиданное в ближайшее десятилетие.
Но это даже не самая большая проблема. Есть также потребление энергии на гигабайт. Если посмотреть на потребление энергии, оказывается, что современная ОЗУ потребляет немного больше энергии на гигабайт, чем десять лет назад. Причина в том, что у нас сейчас более быстрая ОЗУ, и применяется та же самая правило стены мощности: если вы увеличиваете тактовую частоту, вы значительно увеличиваете потребление энергии. Кстати, ОЗУ потребляет довольно много энергии, потому что DRAM фундаментально активный компонент. Вам нужно постоянно обновлять ОЗУ из-за электрической утечки, поэтому если вы выключите питание ОЗУ, вы потеряете все данные. Вам нужно постоянно обновлять ячейки.
Таким образом, заключение для корпоративного программного обеспечения заключается в том, что DRAM - это единственный компонент, который больше не прогрессирует. Есть множество вещей, которые все еще прогрессируют очень быстро, например, вычислительная мощность; однако это не относится к DRAM - он очень застаивается. Если учесть потребление энергии, которое также составляет значительную часть затрат на облачные вычисления, ОЗУ практически не делает никакого прогресса. Поэтому, если вы выбираете дизайн, который слишком сильно акцентирует внимание на основной памяти, и это обычно то, что вы получите, когда у вас есть поставщик, который говорит: “О, у нас есть дизайн в памяти для программного обеспечения”, запомните эти ключевые слова.
Когда вы слышите от поставщика, что у него есть дизайн в памяти, то поставщик говорит вам - и это не очень убедительное предложение - что его дизайн полностью зависит от будущего развития DRAM, где мы уже знаем, что стоимость не снизится. Так что, если мы учтем тот факт, что через 10 лет ваша цепочка поставок, вероятно, будет обрабатывать примерно в 10 раз больше данных только потому, что компании становятся все лучше и лучше в сборе большего количества данных в своих цепочках поставок и сотрудничестве по сбору большего количества данных от своих клиентов и поставщиков, то не разумно ожидать, что через десять лет любая крупная компания, управляющая большой цепочкой поставок, будет собирать в 10 раз больше данных, чем сейчас. Однако цена за гигабайт оперативной памяти останется прежней. Так что, если вы посчитаете, вы можете столкнуться с расходами на облачные вычисления или ИТ-расходами, которые по сути будут в десять раз дороже, просто чтобы делать практически то же самое, только потому, что вам приходится справляться с постоянно растущим объемом данных, которые не помещаются в память. Ключевое понимание заключается в том, что вы действительно хотите избежать всех видов дизайнов в памяти. Эти дизайны очень устарели, и мы увидим в следующем, какие альтернативы у нас есть.
Теперь давайте рассмотрим хранение данных, которое связано с постоянным хранением данных. По сути, у вас есть два класса широко распространенного хранения данных. Первый - это жесткие диски (HDD) или вращающиеся диски. Второй - это твердотельные накопители (SSD). Интересно то, что задержка на вращающихся дисках ужасна, и когда вы посмотрите на эту картину, вы легко поймете почему. Эти диски буквально вращаются, и когда вы хотите получить доступ к любой случайной точке данных на диске, в среднем вам нужно будет ждать половину оборота диска. Учитывая, что самые современные диски вращаются примерно 10 000 оборотов в минуту, это означает, что у вас есть встроенная задержка в три миллисекунды, которую нельзя сжать. Это буквально время, которое требуется для вращения диска и чтения точки интереса на диске. Это механическое устройство и не будет улучшаться дальше.
Жесткие диски ужасны по задержке, но у них также есть другая проблема - потребление энергии. Как правило, HDD и SSD потребляют примерно три ватта в час на устройство. Это типичное текущее положение дел. Однако, когда жесткий диск работает, даже если вы не активно читаете что-либо с жесткого диска, вы будете потреблять три ватта просто потому, что вам нужно поддерживать вращение диска. Достичь 10 000 оборотов в минуту занимает много времени, поэтому вам нужно поддерживать вращение диска все время, даже если вы используете диск очень редко.
С другой стороны, когда речь идет о твердотельных накопителях, они потребляют три ватта при доступе к ним, но когда вы не обращаетесь к данным, они почти не потребляют энергию. У них есть остаточное потребление энергии, но оно крайне мало, порядка милливатт. Это очень интересно, потому что у вас может быть множество SSD; если вы их не используете, вы не платите за потребляемую ими энергию. Весь отрасль постепенно переходит от HDD к SSD за последнее десятилетие.
Чтобы понять это, мы можем посмотреть на эту кривую. Мы видим, что цена за гигабайт как для HDD, так и для SSD снижается за последние несколько лет. Однако цена сейчас стабилизируется. Данные немного устарели, но они не сильно менялись за последние несколько лет. За последние 10 лет мы видим, что десять лет назад SSD были чрезвычайно дорогими - $2,400 за терабайт, в то время как жесткие диски стоили всего $60 за терабайт. Однако на сегодняшний день цена жестких дисков уменьшилась в три раза, примерно до $20 за терабайт. Цена SSD уменьшилась более чем в 25 раз, и тенденция снижения цен на SSD не останавливается. SSD в настоящее время и, вероятно, в течение следующего десятилетия, являются компонентом, который прогрессирует наиболее интенсивно, и это очень интересно.
Кстати, я говорил вам, что дизайн современных вычислительных устройств (ЦП, ГП, ТПУ) по сути является двумерным с максимум 20 слоями. Однако, когда речь идет о твердотельных накопителях (SSD), дизайн становится все более трехмерным. У самых новых SSD есть около 176 слоев. Мы приближаемся, по порядку, к 200 слоям. Поскольку эти слои невероятно тонкие, не является неразумным ожидать, что в будущем у нас будут устройства с тысячами слоев и потенциально с порядками большей емкости хранения. Очевидно, хитрость будет в том, что вы не сможете постоянно получать доступ ко всем этим данным, снова из-за темного кремния и потери энергии.
Оказывается, если вы играете хорошо, большая часть данных запрашивается очень редко. SSD включает в себя очень специфический аппаратный дизайн, который сопровождается множеством особенностей, таких как то, что вы можете только включать биты, но не выключать их. Представьте себе, что у вас изначально все нули; вы можете превратить ноль в единицу, однако вы не можете локально превратить эту единицу в ноль. Если вы хотите сделать это, вам нужно сбросить весь блок, который может быть размером до восьми мегабайт, что означает, что при записи вы можете превращать биты из нуля в единицу, но не из единицы в ноль. Чтобы превратить биты из единицы в ноль, вам нужно сбросить весь блок и перезаписать его, что приводит к множеству проблем, известных как усиление записи.
За последнее десятилетие внутри SSD-накопителей есть слой, называемый слоем перевода флеш-памяти, который может устранить все эти проблемы. Эти слои перевода флеш-памяти становятся все лучше и лучше со временем. Однако есть большие возможности для дальнейшего улучшения, и в терминах корпоративного программного обеспечения это означает, что вам действительно нужно оптимизировать свой дизайн, чтобы максимально использовать возможности SSD. SSD уже являются гораздо более выгодным вариантом, чем DRAM, когда речь идет о хранении данных, и если вы играете умно, вы можете ожидать, что через десять лет вы получите порядки увеличения производительности, которые будут достигнуты благодаря прогрессу в области аппаратного обеспечения, что не относится к DRAM.
Наконец, давайте поговорим о пропускной способности. Пропускная способность, вероятно, является наиболее решенной проблемой в технологии. Однако, даже если пропускная способность может быть достигнута, мы можем достичь таких пропускных способностей, которые абсолютно безумны на сегодняшний день. Коммерчески, телекоммуникационная отрасль очень сложна, и есть множество проблем, поэтому конечные потребители фактически не видят всех преимуществ прогресса, достигнутого в области оптической связи.
В отношении оптической связи с оптоволоконными трансиверами прогресс абсолютно безумный. Это, вероятно, одна из тех вещей, которые прогрессируют, как это было с ЦП в 80-х или 90-х годах. Просто чтобы дать вам представление, с помощью мультиплексирования по длине волны (WDM) или мультиплексирования по пространству (SDM), теперь мы можем достигать десятых долей терабайт данных, передаваемых в секунду по одному кабелю оптического волокна. Это абсолютно огромно. Мы приближаемся к тому моменту, когда один кабель сможет передавать достаточно данных, чтобы питать целый центр обработки данных. Что еще более впечатляет, так это то, что телекоммуникационная отрасль смогла разработать новые трансиверы, которые могут обеспечивать эти абсолютно безумные характеристики на основе старых кабелей. Вам даже не нужно развертывать новое оптоволокно на улицах или физически; вы буквально можете взять оптоволокно, которое было развернуто десять лет назад, развернуть новый трансивер и получить порядки увеличения пропускной способности на том же самом кабеле.
Интересно то, что существует общий закон оптической связи: каждое десятилетие расстояние сокращается, на котором замена электрической связи оптической связью становится интересной. Если мы вернемся на несколько десятилетий назад, два десятилетия назад, потребовалось около 100 метров, чтобы оптическая связь превзошла электрическую связь. Таким образом, если у вас были расстояния меньше 100 метров, вы использовали медь; если у вас было больше 100 метров, вы использовали оптоволокно. Однако в настоящее время, с последним поколением, мы можем иметь расстояние, где оптика побеждает даже на расстояниях всего в три метра. Если мы посмотрим на следующее десятилетие, я не удивлюсь, если мы увидим ситуации, когда оптическая связь побеждает даже при расстояниях всего в полметра. Это означает, что в какой-то момент меня не удивит, если внутри компьютеров будут использоваться оптические каналы, просто потому что они более производительны, чем электрические каналы.
С точки зрения предприятийного программного обеспечения это также очень интересно, потому что это означает, что если вы смотрите вперед, пропускная способность будет существенно снижаться в стоимости. Это в значительной степени субсидируется компаниями, такими как Netflix, которые имеют огромное потребление пропускной способности. Это означает, что для уменьшения задержки вы можете делать такие вещи, как предварительная загрузка огромного количества данных к пользователю, а затем позволить пользователю взаимодействовать с данными, которые были приближены к нему с гораздо меньшей задержкой. Даже если вы приводите данные, которые не нужны, то то, что убивает вас, это задержка, а не пропускная способность. Лучше сказать: “У меня есть сомнения о том, какие данные понадобятся; я могу взять в тысячу раз больше данных, чем мне действительно нужно, просто приблизить их к конечному пользователю, позволить пользователю или программе взаимодействовать с этими данными и минимизировать круговой оборот, и я буду выигрывать в терминах производительности”. Это снова имеет глубокое влияние на решения архитектуры, которые принимаются сегодня, потому что они будут определять, сможете ли вы повысить производительность с развитием этого класса оборудования через десять лет.
В заключение, задержка - это большая битва нашего времени в области программной инженерии. Это действительно определяет все виды производительности, которые у нас есть и будут. Производительность абсолютно ключевая, потому что она будет определять не только стоимость ИТ, но и производительность людей, работающих в вашей цепочке поставок. В конечном итоге, это также повлияет на производительность самой цепочки поставок, потому что если у вас нет этой производительности, вы не сможете даже реализовать численный рецепт, который действительно был бы умным и обеспечивал бы передовую оптимизацию и предсказуемые события оптимизации - это то, что мы ищем. Однако, в целом, эта борьба за лучшую производительность не выигрывается, по крайней мере, не в области предприятийного программного обеспечения. Новые системы могут быть, и часто являются, медленнее старых. Это острая проблема. Медленная производительность программного обеспечения генерирует огромные затраты для компаний, которые поддаются ей.
Просто чтобы дать вам пример, не следует считать данностью, что лучшее вычислительное оборудование дает вам лучшую производительность. Некоторые люди в интернете решили измерить задержку ввода, или задержку ввода, которая является временем, которое проходит после нажатия клавиши до отображения соответствующей буквы на экране. С Apple II в 1983 году, который имел процессор с тактовой частотой 1 МГц, это занимало 30 миллисекунд. В 2016 году, с Lenovo X1, оснащенным процессором с тактовой частотой 2,6 ГГц, очень хорошим ноутбуком, задержка оказалась 110 миллисекунд. Таким образом, у нас есть вычислительное оборудование, которое в несколько тысяч раз лучше, но мы получаем задержку, которая почти в четыре раза медленнее. Это характерно для того, что происходит, когда у вас нет механического сочувствия и вы не обращаете внимания на вычислительное оборудование, которое у вас есть. Если вы противостоите вычислительному оборудованию, оно отвечает вам плохой производительностью.
Проблема очень реальна. Мое предложение состоит в том, чтобы, когда вы начинаете рассматривать любое предприятийное программное обеспечение для вашей компании, будь то открытое или нет, помните элементы механического сочувствия, которые вы узнали сегодня. Посмотрите на программное обеспечение и тщательно подумайте, соответствует ли оно глубоким тенденциям вычислительного оборудования или игнорирует их полностью. Если оно их игнорирует, это означает, что не только производительность не улучшится со временем, но, скорее всего, она ухудшится. Большинство улучшений в наши дни достигаются за счет специализации, а не тактовой частоты. Если вы упустите эту возможность, вы выбираете путь, который со временем станет все медленнее и медленнее. Избегайте таких решений, потому что они обычно являются результатом ранних ключевых проектных решений, которые нельзя отменить. Вы останетесь с ними навсегда, и с каждым годом будет только хуже. Думайте о десятилетии вперед, когда начинаете рассматривать эти аспекты.
Теперь давайте посмотрим на вопросы. Это была довольно длинная лекция, но это сложная тема.
Вопрос: Каково ваше мнение о квантовых компьютерах и их применимости для решения сложных задач оптимизации цепочки поставок?
Очень интересный вопрос. Я зарегистрировался на бета-тестирование квантового компьютера IBM 18 месяцев назад, когда они открыли доступ к своему квантовому компьютеру в облаке. Мое мнение заключается в том, что это захватывающе, так как эксперты могут видеть, как все S-кривые выравниваются, но не видят новых кривых, появляющихся из ниоткуда. Квантовые компьютеры - одно из таких явлений. Однако я считаю, что квантовые компьютеры представляют очень сложные задачи в контексте цепочек поставок. Во-первых, как я уже сказал, битва нашего времени в области корпоративного программного обеспечения - это задержка, и квантовые компьютеры ничего не делают с этим. Квантовые компьютеры дают вам потенциально до 10 порядков ускорения для сверхтрудных вычислительных задач. Таким образом, квантовые компьютеры будут следующим этапом после TPUs, где можно выполнять сверхтрудные операции невероятно быстро.
Это очень интересно, но, если быть честным, сейчас очень мало компаний, насколько мне известно, даже управляют использованием суперскалярных инструкций в своем корпоративном программном обеспечении. Это означает, что весь рынок упускает возможность ускорения в 10-28 раз, которое предоставляют суперскалярные графические процессоры. В мире цепочки поставок очень мало людей этим занимаются; возможно, Lokad, возможно, нет. Что касается TPUs, я думаю, что их никто не использует. Google активно работает с ними, но я не знаю ни одного случая использования TPUs в контексте цепочки поставок. Квантовые процессоры будут следующим этапом после TPUs.
Я определенно очень внимательно следю за тем, что происходит с квантовыми компьютерами, но я считаю, что это не главная проблема, с которой мы сталкиваемся. Это захватывающе, потому что мы пересматриваем дизайн фон Неймана, установленный около 70 лет назад, но это не проблема, с которой мы или цепочка поставок будем сталкиваться в ближайшее десятилетие. После этого ваше предположение так же хорошо, как и мое. Да, это потенциально может изменить все или нет.
Вопрос: Облачные и SaaS-предложения позволяют организациям использовать и преобразовывать фиксированные затраты. Работают ли компании, предлагающие такие услуги, также над снижением своих фиксированных затрат и связанных рисков?
Ну, это зависит. Если я являюсь платформой облачных вычислений и продаю вам вычислительную мощность, действительно ли мне выгодно сделать ваше корпоративное программное обеспечение максимально эффективным? Не совсем. Я продаю вам виртуальные машины, гигабайты пропускной способности и хранилище, поэтому, на самом деле, наоборот. Мне выгодно убедиться, что у вас есть программное обеспечение, которое максимально неэффективно, чтобы вы потребляли и платили за огромное количество ресурсов по мере их использования.
Внутри крупных технологических компаний, таких как Microsoft, Amazon и Google, очень агрессивно оптимизируют свои вычислительные ресурсы. Но они также агрессивны, когда речь идет о том, чтобы оплатить счет, когда они выставляют клиенту счет за аренду виртуальной машины. Если клиент арендует виртуальную машину, которая в 10 раз больше, чем должна быть, просто потому что используемое им корпоративное программное обеспечение является крайне неэффективным, им не выгодно прерывать ошибку клиента. Для них это нормально, это хороший бизнес. Когда вы понимаете, что системные интеграторы и платформы облачных вычислений часто работают вместе в качестве партнеров, вы понимаете, что эти категории людей не всегда имеют ваше лучшее интересы в виду. Однако, когда речь идет о SaaS, ситуация немного иная. Действительно, если вы платите по пользователю поставщику SaaS, то это в интересах компании, и это такой случай, например, для Lokad. Мы не взимаем плату за использование вычислительных ресурсов, мы обычно взимаем плату у наших клиентов в соответствии с фиксированными ежемесячными тарифами. Таким образом, поставщики SaaS обычно очень агрессивны, когда речь идет о собственном потреблении вычислительных ресурсов.
Однако будьте осторожны, есть предвзятость: если вы являетесь компанией SaaS, вы можете быть довольно неохотными делать что-то, что было бы намного лучше для ваших клиентов, но намного дороже в терминах аппаратного обеспечения для вас. Не все так просто и безоблачно. Существует своего рода конфликт интересов, который затрагивает всех поставщиков SaaS, работающих в сфере цепочки поставок. Например, они могли бы инвестировать в переинжиниринг всех своих систем для достижения лучшей задержки и более быстрых веб-страниц, но дело в том, что это требует ресурсов, и их клиенты не будут естественным образом платить им больше за это.
Проблема обычно усугубляется, когда речь идет о корпоративном программном обеспечении. Почему так происходит? Потому что человек, который покупает программное обеспечение, обычно не является тем, кто его использует. Вот почему так много корпоративных систем работают невероятно медленно. Человек, который покупает программное обеспечение, не страдает так сильно, как бедный планировщик спроса или менеджер запасов, который вынужден справляться с крайне медленной системой каждый день в течение всего года. Так что в области корпоративного программного обеспечения есть еще один аспект. Вам действительно нужно проанализировать ситуацию, рассмотреть все стимулы, которые действуют, и при работе с корпоративным программным обеспечением обычно существует множество противоречивых стимулов.
Вопрос: Сколько раз Lokad пришлось пересматривать свой подход, учитывая прогресс в области аппаратного обеспечения? Можете ли вы привести пример, если возможно, чтобы просто поставить этот контент в контекст решаемых реальных проблем?
Я считаю, что Lokad полностью перестраивала свой технологический стек примерно полдюжины раз. Однако Lokad была основана в 2008 году, и у нас было полдюжины крупных переписываний всей архитектуры. Это не потому, что программное обеспечение продвинулось настолько сильно; программное обеспечение продвинулось, да, но большую часть наших переписываний вызвало не столько продвижение аппаратного обеспечения. Это больше похоже на то, что мы приобрели понимание аппаратного обеспечения. Все, что я сегодня представил, было известно людям, которые уже обращали внимание десять лет назад. Так что, видите ли, аппаратное обеспечение действительно развивается, но это происходит очень медленно, и большинство тенденций можно предсказать даже за десять лет вперед. Это долгая игра.
Lokad пришлось пройти через массовые переписывания, но это было скорее отражением того, что мы постепенно становились менее несостоятельными. Мы приобретали компетенцию, и поэтому мы лучше понимали, как использовать аппаратное обеспечение, а не то, что аппаратное обеспечение меняло задачу. Это не всегда было так; были конкретные элементы, которые действительно изменили игру для нас. Самым заметным из них были твердотельные накопители (SSD). Мы перешли с жестких дисков на SSD, и это полностью изменило нашу производительность, с огромными последствиями для нашей архитектуры. Что касается очень конкретных примеров, весь дизайн Envision, языка программирования, специфичного для домена, который предоставляет Lokad, основан на знаниях, которые мы получили на уровне аппаратного обеспечения. Это не только одно достижение; это о том, чтобы делать все, о чем вы можете подумать, просто быстрее.
Вы хотите обработать таблицу с миллиардом строк и 100 столбцами, и вы хотите сделать это в 100 раз быстрее с теми же вычислительными ресурсами? Да, вы можете это сделать. Вы хотите иметь возможность объединять очень большие таблицы с минимальными вычислительными ресурсами? Да, снова. Можно ли создать сложные панели управления с буквально сотней таблиц, отображаемых конечному пользователю менее чем за 500 миллисекунд? Да, мы достигли этого. Это обычные достижения, но именно благодаря им мы можем внедрять довольно сложные оптимизационные рецепты в производство. Нам нужно убедиться, что все шаги, которые привели нас к этому, выполнены с очень высокой производительностью.
Самая большая проблема, когда вы хотите сделать что-то очень изысканное для цепочки поставок в терминах числовых рецептов, это не этап “сделать это работающим”. Вы можете взять студентов колледжа и создать серию прототипов, которые улучшат производительность цепочки поставок в течение нескольких недель. Просто возьмите Python и любую случайную библиотеку машинного обучения с открытым исходным кодом, и если эти студенты умны и готовы, они создадут работающий прототип в течение нескольких недель. Однако вы никогда не сможете масштабировать это в производство. Вот в чем проблема. Речь идет о том, как пройти все эти этапы зрелости: “сделать это правильно”, “сделать это быстро” и “сделать это дешево”. Вот где действительно проявляется аффинность аппаратного обеспечения и ваша способность итерировать.
Здесь нет одного единственного достижения. Однако все, что мы делаем, например, когда мы говорим, что Lokad занимается вероятностным прогнозированием, не требует такой большой вычислительной мощности. То, что действительно требует вычислительной мощности, это использование обширных распределений вероятностей и рассмотрение всех возможных будущих событий и сочетание всех возможных будущих событий с возможными решениями, которые вы можете принять. Таким образом, вы можете выбрать лучшие из них с помощью финансовой оптимизации, что становится очень дорого. Если у вас нет чего-то, что очень оптимизировано, вы застряли. Тот факт, что Lokad может использовать вероятностное прогнозирование в производстве, свидетельствует о том, что у нас была обширная оптимизация на уровне аппаратного обеспечения на всех этапах для всех наших клиентов. Сейчас мы обслуживаем около 100 компаний.
Вопрос: Лучше иметь собственный сервер для корпоративного программного обеспечения (ERP, WMS), чем использовать облачные сервисы, чтобы избежать задержек?
Я бы сказал, что в наше время это не имеет значения, потому что большинство задержек, с которыми вы сталкиваетесь, происходят внутри системы. Это не проблема задержки между вашим пользователем и ERP. Да, если у вас очень плохая задержка, вы можете добавить около 50 миллисекунд задержки. Очевидно, если у вас есть ERP, вы не хотите, чтобы он находился в Мельбурне, когда вы работаете в Париже, например. Вы хотите, чтобы центр обработки данных находился рядом с местом вашей работы. Однако современные облачные вычислительные платформы имеют десятки центров обработки данных, поэтому нет большой разницы в задержке между собственным хостингом и облачными сервисами.
Обычно собственный хостинг не означает размещение ERP на полу в середине фабрики или склада. Вместо этого это означает размещение ERP в центре обработки данных, где вы арендуете вычислительное оборудование. Я считаю, что с позиции современных облачных вычислительных платформ с центрами обработки данных по всему миру, практически нет разницы между собственным хостингом и облачными вычислениями.
То, что действительно имеет значение, - это то, насколько ваш ERP минимизирует все обращения. Например, то, что обычно замедляет работу ERP, - это взаимодействие между бизнес-логикой и реляционной базой данных. Если у вас есть сотни обратных взаимодействий для отображения веб-страницы, ваш ERP будет работать ужасно медленно. Поэтому вам нужно рассматривать дизайны корпоративного программного обеспечения, которые не имеют огромного количества обращений. Это внутреннее свойство корпоративного программного обеспечения, на которое вы обращаете внимание, и оно не зависит от того, где вы размещаете программное обеспечение.
Вопрос: Вы считаете, что нам нужны новые языки программирования, которые бы в полной мере использовали новый аппаратный дизайн на уровне ядра, используя возможности аппаратной архитектуры?
Да, и да. Но полный отказ, у меня здесь есть конфликт интересов. Именно это сделала Lokad с Envision. Envision родился из наблюдения, что сложно использовать всю вычислительную мощность, доступную в современных компьютерах, но это не должно быть сложным, если вы разрабатываете сам язык программирования с учетом производительности. Вы можете сделать его сверхъестественным, и вот почему в лекции 1.4 о парадигмах программирования для цепочки поставок я сказал, что если вы выберете правильные парадигмы программирования, такие как программирование с использованием массивов или программирование с использованием фреймов данных, и создадите язык программирования, который объединяет эти концепции, вы получите практически бесплатную производительность.
Ценой, которую вы платите, является то, что вы не так выразительны, как язык программирования, такой как Python или C++, но если вы готовы принять уменьшенную выразительность и охватить все случаи использования, связанные с цепочкой поставок, то да, вы можете достичь значительного улучшения производительности. Это мое убеждение, и поэтому я также заявил, что, например, объектно-ориентированное программирование с точки зрения оптимизации цепочки поставок ничего не дает.
Напротив, это своего рода парадигма, которая только противоречит основному вычислительному оборудованию. Я не говорю, что объектно-ориентированное программирование плохо; это не то, что я говорю. Я говорю, что есть области программной инженерии, где это имеет смысл, но это не имеет смысла в контексте предсказательной оптимизации цепочки поставок. Так что да, очень сильно да, нам нужны языки программирования, которые действительно воплощают это.
Я знаю, что я склонен повторять это, но Python был создан в конце 80-х годов, и они пропустили все, что можно было увидеть о современных компьютерах. У них есть что-то, что по своей сути не позволяет использовать многопоточность. У них есть этот глобальный замок, поэтому они не могут использовать несколько ядер. Они не могут использовать локальность. У них есть позднее связывание, которое действительно усложняет доступ к памяти. Они очень переменные, поэтому они потребляют много памяти, что означает, что это будет работать против кэша и т.д.
Это те проблемы, при использовании Python, которые означают, что вам предстоит борьба в течение десятилетий, и борьба будет только усиливаться со временем. Они не станут лучше.
Следующая лекция состоится через три недели, в тот же день недели, в то же время. Она пройдет в 15:00 по парижскому времени, 9 июня. Мы будем обсуждать современные алгоритмы для цепочки поставок, которые являются своего рода аналогом современных компьютеров для цепочки поставок. Увидимся в следующий раз.
