«Мы сжигаем мосты, по которым сюда мчимся, не имея других доказательств своего движения, кроме воспоминаний о запахе дыма и предположения, что он вызывал слёзы» — «Розенкранц и Гильденштерн мертвы», абсурдистская пьеса Тома Стоппарда
15 марта д-р Дэвид Паттерсон выступил перед аудиторией из примерно 200 наевшихся пиццы инженеров. Доктор вкратце изложил им полувековую историю конструирования компьютеров с трибуны в большом конференц-зале здания E в кампусе Texas Instruments в Санта-Кларе во время лекции IEEE под названием «50 лет компьютерной архитектуры: от центральных процессоров до DNN TPU и Open RISC-V». Это история случайных взлётов и падений, провалов и чёрных дыр, поглотивших целые архитектуры.
Паттерсон начал с 1960-х годов и новаторского проекта IBM System/360, основанного на ранних работах Мориса Уилкса по микропрограммированию 1951 года. По меркам IT это было давным-давно… Ближе к концу выступления Паттерсон показал потрясающую диаграмму. Она наглядно демонстрирует, как именно смерть закона масштабирования Деннарда, за которой следует смерть закона Мура, полностью изменили методы проектирования компьютерных систем. В конце он объяснил посмертные технологические последствия этих потрясений.
Всегда приятно наблюдать, как настоящий мастер занимается любимым ремеслом, а Паттерсон — действительно знаток компьютерной архитектуры и тех сил, которые ею управляют. Он преподавал эту тему с 1976 года и стал соавтором настоящего бестселлера «Компьютерная архитектура. Количественный подход» вместе с доктором Джоном Хеннесси. Книга недавно пережила шестое издание. Так что Паттерсон на порядок превзошёл сформулированный Малкольмом Гладуэллом рубеж в 10 000 часов, необходимых для достижения мастерства в каком-либо предмете. И это видно.
Паттерсон захватил внимание аудитории на 75 минут, разделив выступление на четыре акта. Как и в абсурдистской пьесе Тома Стоппарда «Розенкранц и Гильденштерн мертвы», кажется, ничто в этой истории — вообще ничто — не идёт как было запланировано.
Д-р Дэвид Паттерсон на конференции IEEE Santa Clara Valley Section 15 марта 2018 г. перед вручением ему премии Тьюринга от ACM за 2017 год. Источник: Стив Лейбсон
Первый акт: IBM System/360, DEC VAX и прелюдия к CISC
В 1950-х и 1960-х прошли грандиозные эксперименты с архитектурами наборов команд (ISA) для мейнфреймов (в то время кроме мейнфреймов практически не проектировалось компьютеров). Почти у каждого мейнфрейма была «новая и улучшенная» ISA. К началу 1960-х только IBM выпустила четыре линейки компьютеров: 650, 701, 702 и 1401, предназначенных для бизнеса, научных приложений и приложений реального времени. Все они — со взаимно несовместимыми архитектурами наборов команд. Четыре несовместимых ISA означали, что IBM разрабатывает и обслуживает четыре полностью независимых набора периферийных устройств (ленточные накопители, диски/барабанные накопители и принтеры), а также четыре набора инструментов для разработки программного обеспечения (ассемблеры, компиляторы, операционные системы и т.д.).
Ситуация явно не казалась устойчивой. Поэтому IBM азартно сыграла по-крупному. Она решила разработать один бинарно-совместимый набор инструкций для всех своих машин. Один аппаратно-независимый набор инструкций для всего. Главный архитектор Джин Амдал и его команда разработали архитектуру System/360, предназначенную для реализации в линейке от недорогих до дорогостоящих серий с 8-, 16-, 32- и 64-битными шинами данных.
Чтобы упростить разработку процессора к IBM System/360, команда разработчиков решила для трудно поддающейся проектированию логики управления использовать микрокод. Морис Уилкс придумал микрокод в 1951 году, и его впервые применили для компьютера EDSAC 2 в 1958 году. В некотором смысле микрокод был уже проверенной технологией к моменту запуска проекта System/360. И он снова доказал свою состоятельность.
Микрокод процессора немедленно отразился в конструкции мейнфреймов, особенно когда полупроводниковые чипы памяти оседлали закон Мура. Пожалуй, величайшим примером массивного использования микрокода стал DEC VAX, представленный в 1977 году. VAX 11/780, инновационный миникомпьютер на TTL и чипах памяти, стал эталоном производительности до конца столетия.
Инженеры DEC создавали ISA для VAX в то время, когда преобладало программирование на ассемблере, отчасти из-за инженерной инерции («мы всегда так делали»), а отчасти потому что рудиментарные высокоуровневые компиляторы в то время генерировали машинный код, который проигрывал составленному вручную лаконичному коду ассемблера. Инструкции VAX ISA поддерживали огромное количество удобных для программиста режимов адресации и включали в себя отдельные машинные инструкции, выполнявшие сложные операции, такие как вставка/удаление очереди и вычисление полинома. Инженеры VAX были в восторге от разработки аппаратного обеспечения, облегчавшего жизнь программистов. Микрокод позволил легко добавлять новые инструкции к ISA — и 99-разрядные микропрограммное управление VAX раздулось до 4096 слов.
Этот фокус по постоянному расширению количества инструкций, чтобы облегчить жизнь программиста на ассемблере, оказался реальным конкурентным преимуществом VAX от DEC. Программистам нравились компьютеры, которые облегчают их работу. Для многих компьютерных историков VAX 11/780 знаменует рождение процессорной архитектуры CISC (с полным набором команд).
Второй акт: случайные успехи и большие неудачи
Миникомпьютер DEC VAX 11/780 достиг пика популярности, когда начался бум микропроцессоров. Почти все первые микропроцессоры были машинами CISC, потому что облегчение нагрузки на программиста оставалось конкурентным преимуществом даже когда компьютер сжался до одной микросхемы. Гордону Муру из Intel, который придумал закон Мура ещё в компании Fairchild, поручили разработать следующую ISA на замену случайно ставшей популярной ISA для 8-битного Intel 8080/8085 (и Z80). Взяв одну часть от чрезвычайно успешного проекта IBM System/360 (одна ISA для управления всем), а другую — от линейки CISC-миникомпьютеров VAX от DEC, Гордон Мур тоже постарался разработать универсальную архитектуру набора инструкций — единую Intel ISA, которая будет жить до скончания веков.
В то время 8-разрядные микропроцессоры работали в 16-разрядном адресном пространстве, а у новой окончательной архитектуры набора команд Intel ISA было 32-разрядное адресное пространство и встроенная защита памяти. Она поддерживала инструкции любой длины, которые начинаются с одного бита. И она программировалась на новейшем и величайшем высокоуровневом языке: Ада.
Эта ISA должен был стать частью процессора Intel iAPX 432, и это был очень большой, очень амбициозный проект для Intel.
Если изучить историю «революционного» iAPX 432, то вы обнаружите, что она завершилась жесточайшим провалом. Аппаратное обеспечение, необходимое для архитектуры IAPX 432, вышло чрезвычайно сложным. В результате микросхему удалось выпустить с большим опозданием. (Она требовала 6-летнего цикла разработки и появилась лишь в 1981 году.) И когда микропроцессор наконец появился, то оказался исключительно медленным.
Мур в самом начале проекта понял, что разработка iAPX 432 займёт много времени, поэтому в 1976 году для подстраховки запустил параллельный проект по разработке гораздо менее амбициозного 16-битного микропроцессора, основанного на расширении успешной 8-битной ISA от 8080, с совместимостью на уровне исходного кода. У разработчиков был всего год, чтобы выпустить чип, поэтому им выделили всего три недели на разработку ISA. Результатом стал процессор 8086 и одна универсальная ISA, по крайней мере, на ближайшие несколько десятилетий.
Была только проблема: по описанию собственных инсайдеров Intel, микропроцессор 8086 вышел очень слабеньким.
Производительность Intel 8086 отставала от производительности ближайших конкурентов: элегантного Motorola 68000 (32-битный процессор в 16-битном одеянии) и 16-битного Zilog Z8000. Несмотря на слабую производительность, IBM выбрала Intel 8086 для своего проекта IBM PC, потому что инженеры Intel в Израиле разработали вариант 8088 — это 8086 с 8-битной шиной. Микропроцессор 8088 работал немного медленнее, чем 8086, но его 8-битная шина казалась более совместимой с существующими периферийными чипами и уменьшила затраты на производство материнской платы ПК.
По прогнозам IBM, планировалось продать около 250 000 компьютеров IBM PC. Вместо этого продажи превысили 100 миллионов, а Intel 8088 стал случайным, но абсолютным хитом.
Третий акт: рождение RISC, VLIW и потопление «Итаника»
В 1974 году, сразу после появления первых коммерческих микропроцессоров, Джон Кок из IBM попытался разработать управляющий процессор для электронного телефонного коммутатора. Он подсчитал, что управляющему процессору необходимо выполнить около 10 миллионов инструкций в секунду (MIPS), чтобы соответствовать требованиям приложения. Микропроцессоры того времени были на порядок медленнее, и даже мэйнфрейм IBM System/370 не подходил для этой задачи: он выдавал около 2 MIPS.
Так команда Кока в рамках проекта 801 разработала радикально модернизированную архитектуру процессора с конвейерной шиной и быстрой схемой управления без микрокода — такое стало возможным за счёт уменьшения числа инструкций до минимума, чтобы упростить управление. (Машину назвали IBM 801, потому что её разработали в здании 801 Исследовательского центра IBM им. Томаса Дж. Уотсона). В проекте IBM 801 впервые реализовали архитектуру RISC (уменьшенный набор инструкций).
Прототип компьютера 801 был построен на мелких чипах Motorola MECL 10K, которые все вместе выдавали невиданную производительность 15 MIPS и легко вписывались в технические требования. Поскольку сокращённый набор инструкций менее удобен для программиста, чем набор инструкций CISC, команде Кока пришлось разработать оптимизирующие компиляторы. Они взяли на себя дополнительное бремя создания эффективного машинного кода из сложных алгоритмов, написанных на языках высокого уровня.
После этого Кок стал известен как «отец RISC». IBM так никогда и не выпустила телефонный коммутатор, но процессор 801 эволюционировал и в конечном итоге стал основой для большой линейки RISC-процессоров IBM, широко используемых в её мейнфреймах и серверах.
Позже несколько инженеров в DEC обнаружили, что около 20% инструкций CISC у VAX занимают около 80% микрокода, но составляют всего 0,2% общего времени выполнения программы. Такой расход! Учитывая результаты проекта IBM 801 и выводы инженеров DEC, можно было предположить, что архитектура CISC не такая уж замечательная.
Предположение подтвердилось.
В 1984 году Стэнфордский профессор Джон Хеннесси опубликовал в журнале IEEE Transactions on Computers знаковую статью под названием «Процессорная архитектура СБИС», где доказал превосходство архитектур и ISA на RISC для реализаций процессора СБИС (VLSI). Паттерсон резюмировал доказательство Хеннесси в своем выступлении: RISC по определению быстрее, потому что машинам CISC требуется в 6 раз больше тактов на инструкцию, чем машинам RISC. Даже хотя машине CISC требуется выполнить в два раза меньше инструкций для той же задачи, компьютер RISC выходит по сути втрое быстрее CISC.
Поэтому процессоры x86 в современных компьютерах только с виду выполняют программно-совместимые инструкции CISC, но как только эти инструкции из внешнего ОЗУ попадают в процессор, они тут же измельчаются/шинкуются на кусочки более простых «микрокоманд» (так Intel называет инструкции RISC), которые затем составляются в очереди и выполняются в нескольких RISC-конвейерах. Сегодняшние процессоры x86 стали быстрее, превратившись в машины RISC.
Несколько разработчиков процессорной архитектуры решили разработать ISA, которая станет намного лучше, чем RISC или CISC. С помощью очень длинных машинных команд (VLIW) стало возможным упаковать множество параллельных операций в одну огромную машинную инструкцию. Архитекторы окрестили этот вариант ISA как VLIW (Very Long Instruction Word). Машины VLIW заимствуют один из принципов работы RISC, возлагая на компилятор работу по планировке и упаковке в машинный код VLIW-инструкций, сгенерированных из высокоуровневого исходного кода.
Intel решила, что архитектура VLIW выглядит очень привлекательно — и начала разработку процессора VLIW, который станет её заявкой на вхождение в неминуемо наступающий мир 64-битных процессоров. Свою VLIW ISA компания Intel назвала IA-64. Как обычно, Intel разработала собственную номенклатуру и свои названия для привычных терминов. На интел-жаргоне VLIW превратилась в EPIC (Explicitly Parallel Instruction Computing). Архитектура EPIC не должна быть основана на наборе инструкций x86, отчасти для предотвращения копирования со стороны AMD.
Позже инженеры HP PA-RISC тоже решили, что у RISC потенциал развития почти исчерпан — и тоже заразились болезнью VLIW. В 1994 году компания HP объединила усилия с Intel для разработки совместной 64-битной архитектуры VLIW/EPIC. Результат назовут Itanium. Объявили цель выпустить первый процессор Itanium в 1998 году.
Однако вскоре стало ясно, что будет трудно разрабатывать процессоры и компиляторы VLIW. Intel не объявляла название Itanium до 1999 года (острословы в Usenet сразу же окрестили процессор «Итаником»), а первый рабочий процессор выпустили только в 2001 году. «Итаник» в итоге благополучно утонул в 2017 году, когда Intel объявила о завершении работ над IA-64. (См. «Intel потопила Itanium: возможно, самый дорогой в мире неудачный проект процессора»).
Архитектура EPIC тоже стала эпичным провалом — микропроцессорной версией Джа-Джа Бинкса из «Звёздных войн». Хотя в своё время казалась хорошей идеей.
Процессоры Itanium, EPIC и VLIW умерли по нескольким причинам, говорит Паттерсон:
- Непредсказуемые ветвления, усложняющие планирование и упаковку параллельных операций в командные слова VLIW.
- Непредсказуемые промахи кэша замедляли выполнение и приводили к переменным задержкам выполнения.
- Наборы команд VLIW раздували объём кода.
- Оказалось слишком сложно создать хорошие оптимизирующие компиляторы для машин VLIW.
Пожалуй, самый известный в мире специалист по компьютерным алгоритмам Дональд Кнут заметил: «Подход Itanium… казался таким великолепным — пока не выяснилось, что желанные компиляторы по сути невозможно написать».
Кажется, компиляторы лучше справляются с простыми архитектурами типа RISC.
Из архитектур VLIW не получились универсальные микропроцессоры. Но позже они всё-таки нашли своё призвание, что переносит нас в четвёртый акт пьесы.
Четвёртый акт: закон масштабирования Деннарда и закон Мура мертвы, но DSA, TPU, и Open RISC-V живы
В пьесе Тома Стоппарда «Розенкранц и Гильденштерн мертвы» два незначительных персонажа, выхваченных из шекспировского «Гамлета», в конце последнего акта наконец-то понимают, что в течение всей пьесы были мертвы. В заключительном акте истории процессоров от Паттерсона умерли закон масштабирования Деннарда и закон Мура. Вот рисунок из последнего издания книги Хеннесси и Паттерсона, который графически показывает всю историю:
Источник: Джон Хеннесси и Дэвид Паттерсон, «Компьютерная архитектура. Количественный подход», 6-e изд. 2018
На графике видно, что микропроцессоры RISC обеспечили почти двадцать лет быстрого прироста производительности с 1986 по 2004 год, поскольку они эволюционировали по закону Мура (вдвое больше транзисторов на каждом новом витке техпроцесса) и закону масштабирования Деннарда (удвоение быстродействия при двукратном снижении энергопотребления на транзистор на каждом новом ветке техпроцесса). Затем закон масштабирования Деннарда умер — и отдельные процессоры перестали ускоряться. Потребление энергии на транзистор также перестало уменьшаться вдвое на каждом этапе.
Промышленность компенсировала это, полагаясь исключительно на закон Мура по удвоению количества транзисторов — и быстро увеличивала количество процессоров на чипе, вступив в многоядерную эру. Интервал удвоения производительности вырос с 1,5 до 3,5 лет в течение этой эпохи, длившейся менее десяти лет, прежде чем вступил в силу закон Амдала (перефразированный как «в каждом приложении эксплуатируемый параллелизм ограничен»). Немногие приложения способны полностью загрузить десятки процессоров.
Тогда скончался и закон Мура.
По словам Паттерсона, результат такой, что с 2015 года рост производительности процессоров упал до ничтожных 3% в год. Удвоение по закону Мура теперь происходит на за 1,5 и даже не за 3,5 года. Теперь это двадцать лет.
Конец игры? «Нет», — говорит Паттерсон. В архитектуре процессоров можно попробовать ещё некоторые интересные вещи.
Один пример: специализированные архитектуры (DSA, Domain Specific Architectures) — специально разработанные процессоры, которые пытаются ускорить выполнение небольшого количества задач для конкретных приложений. Архитектуры VLIW не подошли для универсальных процессоров, но вполне имеют смысл для приложений DSP с гораздо меньшим числом ветвлений. Другой пример: Google TPU (Tensor Processing Unit), ускоряющий выполнение DNN (Deep Neural Network, глубокие нейросети) с помощью блока из 65 536 юнитов умножения-сложения (MAC) на одной микросхеме.
Оказывается, матричные вычисления с пониженной точностью — ключ к реализации действительно быстрых DNN. 65 536 восьмибитных блоков MAC в Google TPU работают на 700 МГц и выдают производительность 92 TOPS (тераопераций в секунду). Это примерно в 30 раз быстрее, чем серверный CPU и в 15 раз быстрее, чем GPU. Умножьте на сокращённое вдвое энергопотребление в 28-нанометровом TPU по сравнению с серверным CPU или GPU — и получите преимущество по энергопотреблению/мощности в 60 и 30 раз, соответственно.
По странному стечению обстоятельств, профессор Дэвид Паттерсон недавно уволился из Калифорнийского университета в Беркли после преподавания и работы там в течение 40 лет. Теперь он занимает должность «заслуженного инженера» в Google по проекту разработки TPU.
Еще одна интересная вещь — создание архитектур ISA с открытым исходным кодом, говорит Паттерсон. Предыдущие такие попытки, в том числе OpenRISC и OpenSPARC, не взлетели, но Паттерсон рассказал о совершенно новой ISA с открытым исходным кодом — это RISC-V, которую он помогал разрабатывать в Беркли. Посмотрите на SoC, говорит Паттерсон, и вы увидите много процессоров с разными ISA. «Почему?», — задаёт он вопрос.
Зачем нам универсальная ISA, ещё одна ISA для обработки изображений, а также ISA для видеообработки, для аудиообработки и DSP ISA на одном кристалле? Почему бы не сделать только одну или несколько простых ISA (и один набор инструментов разработки программного обеспечения), которые можно многократно использовать для конкретных приложений? Почему бы не сделать ISA с открытым исходным кодом, чтобы каждый мог использовать эту архитектуру безвозмездно и улучшать её? Единственный ответом Паттерсона на эти вопросы — RISC-V ISA.
Недавно сформирован Фонд RISC-V, похожий по концепции на успешный Linux Foundation. В него вошли уже более 100 компаний, и он взял на себя работу по стандартизации RISC-V ISA. Миссия Фонда — способствовать внедрению RISC-V ISA и её будущему развитию. Так совпало, что «отошедший от дел» доктор Дэвид Паттерсон занимает должность заместителя председателя Фонда RISC-V.
Как и Розенкранц и Гильденштерн, закон масштабирования Деннарда и закон Мура оказываются мёртвыми в конце исторической пьесы Паттерсона, но интересные события в компьютерной архитектуре только начинаются.
«Нет ничего более неубедительного, чем неубедительная смерть», — так говорилось в пьесе.
Эпилог: 21 марта, всего через неделю после выступления в IEEE, Ассоциация вычислительной техники (ACM) признала вклад Паттерсона и Хеннесси в компьютерную архитектуру, присудив им премию Тьюринга ACM 2017 года «за новаторский систематический, вычислительный подход к проектированию и оценке компьютерных архитектур, оказавший длительное влияние на микропроцессорную промышленность».
Комментарии (60)
ni-co
26.04.2018 17:05-3Скомпилировал мысль по теперешнему состоянию «закона Мура»:
Маркетологи не знают, собственно говоря для чего его поддерживать. Где те задачи, для которых необходимы огромнейшие затраты в научно исследовательские разработки?
Собственно нету сейчас спросу на этот закон. :))devlind
26.04.2018 17:27+5Где те задачи, для которых необходимы огромнейшие затраты в научно исследовательские разработки?
Собственно нету сейчас спросу на этот закон. :))
Ну конечно нету. А миллионы видосов с 4К котиками показать каждую секунду обывателям? VR в 240 градусов, 120 fps, 8K, всякие вычисления для ИИ и neural networks, моделирование процессов в научных целях. И это я подумал всего 10 секунд. Можно найти ещё 1000 и 1 способ и потребность в новых, более мощных процессорах. Ваш коммент звучит как знаменитая фраза Гейтса об кол-ве необходимой оперативки.ni-co
26.04.2018 18:04-3Для Вас лично может быть, а для остальных миллиардов пользователей?
У меня на работе в ЛВС еще работает сервер 2005 года и тянет свои задачи.
И собственно оставшуюся сотню компов в ближайшее время смысл менять только лишь для экономии электроэнергии.
В ИТ с 1989 года может поэтому так думаю?moooV
26.04.2018 19:05+5Да пригождается вообще все до последнего. Как в том советском анекдоте про «настолько много остается, что приходится доедать и аж не наедаемся».
У меня в подвале небольшая рендерферма из около десяти машин на разогнанных core i7-920 и xeon x5570. Они не первой свежести, но по цене грязи и фермочка не уступает паре последних i9 по цене сотен нефти.
А обслуживает ее кластер-менеджер на моем старющем компе с p4 2.4 northwood и 1 гигом оперативки. А гейтом в интернет, шейпером, и фаерволом (Mikrotik RouterOS) является старый celeron 1.7, который еще древнее пня 4. Ну и сделан NAS на p4 3.0, прекрасно справляющийся со всеми своими задачами (бекапы и архив порева с порнолаба).
В общем, прогресс по процам реально встал и меня это радует. Пока хомячки бегут за последними i7 в магазины, я могу на ту же сумму накупить древнейших i7 и получить в несколько раз большую производительность (распределенную).
Единственный минус/плюс — энергопотребление. Вся эта байда жрет около 2-3 киловатт под нагрузкой.
ЗЫ.
Пашу на японцев, делаю им для рекламы вот такое.
ЗЫЗЫ.
Гпу-рендеринг не подходит — используются взрослые продакшен-рендеры (Arnold), гпу-рендеры еще многое не умеют из критичного. Так что только хардкор, только цпу.Busla
26.04.2018 23:20Класс!
А сколько по времени эта картинка рендерилась на десятке i7?moooV
27.04.2018 06:29Ну, эта картинка считалась около 2 часов.
А по времени расклад такой обычно:
технически тяжелый плакат (около 500м полигонов и около 100гб текстур) в продакшен-качестве 6000х9000 считается ночь.
Кадр видео 1080p такой же сложности считается часа за 2.
Если что-то простое (без рассеиваний кожи, объемов, итд) — то минут 5-20 на кадр.
nidalee
27.04.2018 03:51Ну это вам повезло — ваша задача параллелится на много ядер и процессоров. Не всем они помогут — кому-то приходится покупать i9. Хомячки тут не при чем.
moooV
27.04.2018 06:38Ну как сказать.
Моя рабочая машина — серверная мать, dual x5570, 48 гб ддр3 ецц, видеокарта — gt520, пара hdd (причем на матери есть только сата2, даже саты3 нет). Работать с тяжелой графикой комфортно.
Недавно был в командировке у заказчиков, пару дней посидел на последнем i9 с двумя nvme в рейде 0 и двумя нвидия титанами — разницы по скорости и комфорту работы с моим компом из древнего говна и палок не заметил. Вот вообще.
Да, ядер дофига, можно прогрессив рендер раза в три быстрее гонять, но на этом все. Остальное — по ощущениям так же.nidalee
27.04.2018 14:44Честно говоря, у меня язык не повернется сказать, что «рендера в три раза быстрее» недостаточно.
Мои рабочие инструменты, например, даже топовый i9 уже не реализуют. То есть у 7940 производительность в программе больше, чем у 7980XE. При этом у i7-8700 — меньше. Значит, для максимальной производительности все же нужно покупать i9, хотя за его цену и можно собрать ферму. Я же не спорю, что ее можно собрать. Просто не всем нужно.
Warrangie
27.04.2018 07:16Уважаемый, скажите пожалуйста как это хотя бы гуглить? Как можно сделать такую распределенную систему вычислений?
moooV
27.04.2018 08:41Да просто обычные серваки под линуксом, грузящиеся по pxe, монтирующие сетевые шары и запускающие проприетарный рендер-движок скриптом. Ничего экстраординарного, обычные веб-серваки и те устроены сложнее.
Так как на всех машинах процы одного поколения, то собран один образ генты, самый минимальный, чтобы меньше жрал памяти — около 30 мб оперативки, там только ssh, smb, nfs. Все ноды бездисковые, грузят образ с nas по pxe (tftp+nfsroot), после чего монтируют виндовые шары с моего рабочего компа (файлы проекта + папка для готовых изображений), получают задание скриптом, и считают.
Как-то так. Каждый нод независимый, это не распределенный рендер: арнольд не умеет считать распределенно, тк это неэффективно — он используется большей частью в голливуде для фильмов, а там каждый нод считает свой кадр. Поэтому у меня тоже в случае видео каждый нод считает по своему кадру, а в случае статики (например, большой плакат) изображение распиливается на куски скриптом, они считаются независимо как отдельные кадры, после чего склеиваются в финальную картинку либо скриптом, либо в нюке, если нужна постобработка/композ.
Та картинка, что я привел, состояла из 25 кусков.
Warrangie
27.04.2018 09:35А какая мать используется в этих машинах?
moooV
27.04.2018 10:02Где какая. Что было с рук доступно за разумные деньги, то и стоит.
Asus p6t se
Gigabyte ga-ex58-ud5, ud3
Dell xps 9xxx motherboard
Безымянные китайцы двухсокетовые
Tyan что-то там
Aglaia что-то там двухсокетовая
Что вспомнил-написал, я с телефона сейчас.
Busla
27.04.2018 10:44Был уверен, что такое распараллеливание крайне неэффективно для реалистичного рендеринга, ведь для каждого фрагмента всё равно сцена чуть ли не целиком должна обсчитываться, чтобы учесть тени, рефлексы и т.д.
Поделитесь, пожалуйста, опытом: насколько 10 машин считают быстрее чем одна?moooV
27.04.2018 12:58Практически линейно — оверхед на построение сцены заново для каждого куска не больше 1% в арнольде, движок пишет всю статистику в логи. Единственное что — при каждом построении сцены геометрия и текстуры читаются по сети, гигабит забивается только так.
А вот если бы это был распределенный рендер, приросты были бы сильно меньше — синхронизация нод и прочий оверхед. До арнольда использовал mentay ray (с vray дела не имел, не знаю как там) — там был именно распределенный (все ноды совместно считают один кадр) и я в итоге пришел к той же схеме — раздельной. Распределенка сжирает до половины производительности.
А, забыл добавить. А тени, отражения, и прочее — там брутфорс рейтрейсер (path tracer, если точнее — есть различия), так что сцена всегда строится целиком — даже если считаем небольшой кусок. Принцип работы просто такой — нужна вся сцена.
И построение не больше 1% занимает, фигня.TrllServ
27.04.2018 14:19А может всё это в статейку оформите?
Думаю это будет интересно, не только десятку заметивших интересное в каментах.
VioletGiraffe
27.04.2018 08:44+1В общем, прогресс по процам реально встал и меня это радует.
Пытаюсь придумать какой-то необидный ответ, и не получается. Вы же взрослый человек, в арифметику умеете? Понимаете, что если бы прогресс в развитии ЦП шёл быстрее, ваша ферма, собранная по цене той же грязи, считала ваш кадр не за 2 часа, а за 30 минут, например?moooV
27.04.2018 09:09Это-то да, не спорю. Но в данном случае имеем, что имеем, и поэтому соотношение цена/мощность для старых процов сейчас очень вкусное. Я брал x5570 по 500 рублей с рук, хотя они всего на 30% медленнее потребительских скайлейков — разница компенсируется разгоном.
littorio
27.04.2018 11:12Проблема не столько в быстром прогрессе, как таковом, сколько в его мелкоступенчатости. Особенно если на каждом маленьком шажке добавляют несовместимости.
Утрируя, покупать каждый год новенький дорогущий топ-комп, и выкидывать его через год — врагу не пожелаешь. Вот если бы они раз лет в 5 весь накопленный прогресс выпускали, и потом его совместимость поддерживали…
batman12345
27.04.2018 13:02Присоеденюсь, Класс!
На вашей фермочке бы лица на порнуху накладывать под заказ… ;-)engine9
27.04.2018 13:39Ультрапередовой хайтек и спецы с глубочайшими знаниями в технологиях, обслуживающие вкусы онанистов, вот оно человечество будущего, вот она космическая эра, хах!
batman12345
27.04.2018 14:47К сожалению, да. Недавнее произведение Пелевина «iPhuck» указывает на этот тренд. Половые отношения сместятся в виртуальность, а рискнуших «по старинке» будут презрительно называть свинюками. Правда, подаётся это как результат эпидемий вирусов, но после «обители зла» уже никакой сценарий не выглядит фантастическим.
vitaliy2
28.04.2018 12:56Пока хомячки бегут за последними i7 в магазины, я могу на ту же сумму накупить древнейших i7 и получить в несколько раз большую производительность (распределенную).
А если бы прогресс не встал, Вы бы могли то же самое купить за 100$. Как минимум, на электричестве Вы сэкономили бы в разы больше. Но не забывайте, что кроме Вас есть ещё и много других людей, которые аналогичную мощность вынуждены покупать по ценам в 100 раз больше (даже покупая б/у). И мощность эта ограничена.
И кстати, если бы процы сейчас были в 100 раз мощнее, то те старые процы Вы бы могли купить ещё в 100 раз дешевле. Ну либо за такую же цену купили бы более новые процы и получили бы в 100 раз больше мощности и рендерили бы кадр не целую ночь, а 6 минут.vitaliy2
28.04.2018 13:02Ну и вообще, без разницы, какая была бы мощность новых процессоров — у Вас никто никогда не отнимет ту мощность, которую Вы уже купили. Т.?е. Вы никогда ничего не потеряете.
Зато когда Вам понадобится покупать новый процессор, Вы можете вместо 10000?$ потратить 100$. Мало кто откажется от такого. Я бы даже сказал так: большинство просто не смогут позволить себе потратить 10000?$ на процессор.
Daddy_Cool
26.04.2018 19:34Истина она… везде. На работе до последнего времени жил P166MMX — ради шины ISA, разыскали в хламе на даче P3 -600- сменили.
Рядом трудится комп с двумя 12-ти ядерными процами.
И вот… есть задачка — там надо шустренько вычислить 200+ штук эллиптических интегралов. (И делать это постоянно в процессе отладки). Maple задумывается на полминуты. На i5. Нервирует однако.
amarao
27.04.2018 10:44А вы пробовали запускать системы проактивного обнаружения отказов в инфраструктуре? Собирать все логи на центральный сервер, тренировать нейронную сеть на сбоях и спокойной работы для обнаружения аномалий?
Но смысл что-то менять, если сервер 2005 года всё ещё тянет свои задачи?ni-co
27.04.2018 11:39По количеству минусов я понял, что главную мысль я так и не донес.
Спрос рождает предложение.
То, что необходимы еще более быстрые процессоры я не опровергал.
Но, например факт того, что никто не перешел на 400 мм кремниевые пластины и то, что стоимость новых фабрик растет в геометрической прогрессии говорит о многом.
porn
26.04.2018 22:18Справедливости ради, доподлинно не известно: действительно ли эта фраза про 640 кБ принадлежала Гейтсу.
yarric
26.04.2018 18:11+2Это пока какой-нибудь очередной новомодный фреймворк JavaScript не выйдет, позволяющий вставлять котиков и видео в веб-страницы посредством нечёткой логики и зависимых типов.
Arxitektor
26.04.2018 20:35Пашу на японцев, делаю им для рекламы
Ммм это фото или рендер с ноля (имею в виду цифровая модель)?moooV
27.04.2018 05:55+1Это рендер.
hdfan2
27.04.2018 08:48-1Но зачем? Я ещё понимаю, отрендерить какую-нибудь пандорианку, но это? Неужели не проще/дешевле найти подходящую модель и сфотографировать её?
moooV
27.04.2018 09:15Очень много применений, но в моем случае жто японская специфика.
Обычно в фильмах это делают чтобы в случае факапов можно было не переснимать сцену, а просто перерендерить актера. Либо для невозможных шотов со спецэфыектами и всяким бешеным, что идкт в кинотеатрах. Или актер уже давно умер, а он нужен молодым (звёздные войны 7, бегущий 2049), итд. Примеров масса.
А у японцев своя атмосфера. Их айдолы — почти небожители и дергать звезду ради съемок в рекламе как-то неприлично. Поэтому им проще заказать модельку (и оплатить команду 3дшников), чтобы потом с ней делать рекламу, плакаты, итд.
hdfan2
27.04.2018 12:34Интересно, спасибо. Да уж, правильно говорят, что в каждой избушке свои погремушки.
batman12345
27.04.2018 13:17Это уже вовсю наступило будущее как в фильме «Симона», где режиссёр радовался, что виртуальные актрисы не капризничают, играют в точности как задумал режиссёр, безумных гонораров не требуют…
TrllServ
26.04.2018 21:16Закон мура вполне себе живет, если посмотреть на серверные процы интел.
То что интел не хочет их отдавать простым смертным по адекватной цене, уже совсем другая история.
Аргументацию про котиков вообще не понимаю, котики и няшечки тапают на планшетиках и телефончиках, ибо мобильно, модно, молодёжно.
asasasdd
26.04.2018 21:51Интересно, если Intel осознала недостатки архитектуры VLIW и перестала выпускать Itanium, то перестанет ли МЦСТ выпускать Эльбрусы?
TrllServ
26.04.2018 21:57МЦСТ не перестанет. Все исходные данные другие.
Альтернатива итаниуму была, эльбрусу — нет.
Закупки и производство эльбруса распланировано на много лет вперед.TyVik
28.04.2018 08:39Можете, пожалуйста, подробнее про исходные данные? Для меня как рядового пользователя процессора что там vliw, что там vliw… Хотелось бы более аргументировано отстаивать Эльбрусы в спорах.
TrllServ
28.04.2018 11:40Не очень понятен вопрос, уточните, если ответ не тот.
1. Эльбрус это гос.заказ для обеспечения безопасности. Что означает, вне зависимости от отставания от мировых аналогов на критичные по ИБ точки армии, фсб, мвд и тд будут ставить именно сервера на базе эльбрусов.
2. Практически не рекламируется особая функция компов на базе эльбрусов — двоичный транслятор. Вещь настолько крутая, что минимум по одному Эльбрусу должно быть в каждой компании разрабатывающей серьёзный софт.
3. Это бонус из-за наличия п.2. Совместимость с ПО x86(IA32) которого огромное кол-во. Причем причем эмуляция аппаратная, не видиммая для софта.
Насколько я знаю серийного аналога просто нет, максимум это использование софтовой виртуальной машины.
beeruser
26.04.2018 22:29Эльбрус III (основа современных Эльбрусов) проектировался в 80х годах, задолго до Merced (как Itanium называли в конце 90х).
Да, он сложный и медленный, но он работает и компилятор более-менее нормальный есть.
Во VLIW нет ничего плохого, если он используется на своём месте. Просто заточка под определённую микроархитектуру мешает её усовершенствованию и расширению.
myemuk
27.04.2018 07:16Читал на одном дыхании, не отрываясь. Вспомнились старые деньки в университете. Интересно, почему не была упомянута ARM архитектура? Я понимаю, что ARM — производная RISC, но все же заслуживает отдельного внимания, особенно в свете большой распространенности.
Viknet
28.04.2018 01:53Вот в этом выступлении он не пропускает ARM: Instruction Sets Want To Be Free: A Case for RISC-V
AlexanderS
27.04.2018 15:31У разработчиков был всего год, чтобы выпустить чип, поэтому им выделили всего три недели на разработку ISA.
Всего три недели на разработку архитектуры! )
Alter2
27.04.2018 16:54Мне кажется, если добавить к процессорам графические ускорители, то график выпрямится.
Viknet
28.04.2018 01:56Ускорители всё же не очень честно — они не являются процессорами общего назначения (те самые DSA).
Но зато можно туда пририсовать например Intel Xeon Phi и рост ещё немного продолжится.
Brak0del
28.04.2018 16:33Очень интересная статья. Странно (может я проглядел), что кроме использования DSA и специализированных Google TPU в качестве решения не упоминается использование логики ПЛИС на одном кристалле с процессорными ядрами, как сделано у Intel-Altera Stratix или Xilinx Zynq (ссылка на stratix: www.altera.com/products/fpga/stratix-series/stratix-10/overview.html, ссылка на zynq: www.xilinx.com/products/silicon-devices/soc/zynq-7000.html). В результате можно избавиться от статической специализации, которая присуща DSA, за счет реконфигурируемости под данную задачу и даже динамической реконфигурации на лету.
artskep
Вообще-то закон Мура был не про производительность per se (и вообще интересно в чем именно измерялась «производительность» на графике), а про количество транзисторов на чипе.
Хотя кому какая разница…
EDA
Moore, 1965: «The complexity for minimum component costs has increased at a rate of roughly a factor of two per year. Certainly over the short term this rate can be expected to continue, if not to increase.»
То есть и не производительность, и не плотность упаковки, а минимальная цена на транзистор.