Интервью AnandTech у Майка Кларка, главного архитектора AMD Zen

МЕНЮ


Главная страница
Поиск
Регистрация на сайте
Помощь проекту
Архив новостей

ТЕМЫ


Новости ИИРазработка ИИВнедрение ИИРабота разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика

Авторизация



RSS


RSS новости


Компания AMD называет это время года "5 лет Zen", указывая на то, что еще в 2016 году она начала знакомить прессу с новой микроархитектурой, которая, оглядываясь назад, в конечном итоге спасла компанию. Как именно Zen появился на свет, все эти годы было хитро скрыто от глаз, но некоторые ключевые люди время от времени всплывали: Джим Келлер, Майк Кларк и Сюзанна Пламмер чаще других попадали в заголовки газет. Но когда AMD начала раскрывать подробности о дизайне, именно Майк Кларк был в центре внимания на этих слайдах. В то время я помню, как расспрашивал его обо всех подробностях, но в рамках программы "5 лет сообщений" предложил Майку дать официальное интервью на эту тему.

Майкл Т. Кларк - корпоративный научный сотрудник AMD, он начал работать в компании в 1993 году, только что получив диплом в Иллинойсе Урбана-Шампейн. Он прошел путь от базового инженера по проектированию процессоров до ведущего архитектора нескольких ключевых процессоров AMD и вплоть до главного архитектора Zen. Чем именно Майк занимался в это время, остается загадкой, поэтому я хочу узнать у него и об этом! В настоящее время Майк отвечает за Zen и его дорожную карту, как для продуктов на рынке сегодня, так и на несколько поколений вперед. К сожалению, Майк пока не хочет раскрывать информацию о том, что будет в Zen 7, но спросить об этом стоило.

Иэн Катресс: Вы работаете в AMD с 1993 года, с момента окончания университета, то есть почти 30 лет. Было забавно попытаться найти какую-то документированную историю вашей работы в AMD - кроме ваших выступлений по представлению микроархитектуры Zen, там почти ничего нет! Не могли бы вы рассказать нам о некоторых проектах, над которыми вы работали, и о том, чем вы занимались на пути к Zen?

Майк Кларк: Я начал прямо со школы, прямо из Иллинойского университета, и начал работать над K5. Это был наш первый собственный дизайн на архитектуре x86, что было потрясающе. Когда я закончил университет, у меня было несколько предложений, но я выбрал AMD, потому что это была единственная компания, которая фактически позволила мне заниматься дизайном отдельных блоков процессора, что в те времена было безумием! Мне приходилось заниматься не только RTL (Register transfer language язык на котором описывается устройство процессора. Прим. перевод.), но также верификацией своего дизайна (и мы поняли, что это очень плохая идея). Кроме дизайна логики, у меня был человек который помогал мне сделать имплементацию моих блоков в кремнии, но синтез мне приходилось делать самому. Т.е. я получал задание на разработку какого-то блока процессора и от самого начала до самого конца делал это самостоятельно.

Вот на чем я в некотором роде поламал себе зубы, чтобы освоить эту дисциплину. Я также занимался TLB (Речь по всей видимости идет о translation lookaside buffer, вид кэш памяти в процессоре), а тогда никто не знал, как работает TLB в архитектуре x86. Так как мы до этого были дублером Intel, мне пришлось выяснить, как работает TLB x86, - это было очень весело! Я многому научился.

В итоге мы купили NexGen, получили K6, и я помог воплотить его в жизнь. Затем мы сделали K7, и я был ведущим специалистом по микрокоду в K7. Это было то, что я называю "командой мечты" - каждый руководитель блока в K7 был просто потрясающим. Я многому научился у этих ребят, и именно там я действительно узнал, как создать отличную микроархитектуру.

Затем я занимался ядром Greyhound (K9), я был ведущим архитектором, которое было производным от K8. Затем мы занимались микроархитектурой Bulldozer - я работал над этим. Я был ведущим архитектором версии Steamroller, но я работал над всеми этими версиями в разных ролях. Затем я стал ведущим архитектором Zen.

Сейчас я отвечаю за всю дорожную карту Zen, но здесь, в AMD, ведущий архитектор проходит путь от высокоуровневого проектирования до кремния, затем до посткремния, взаимодействуя с клиентами. Вы действительно узнаете, какие из ваших решений были хорошими, а какие - плохими. Вы чувствуете боль, когда слышите, что на сообщество разработчиков программного обеспечения возложена работа [в которой не было необходимости], и поэтому в следующий раз вы сделаете лучше. Вы действительно работаете над проектом в течение длительного времени, и я действительно верю в то, что нельзя просто работать на этапе до кремния или даже на этапе проектирования и просто двигаться дальше - вы должны чувствовать боль от всего в вашем проекте, чтобы стать лучшим архитектором.

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

IC: Как называется ваша должность официально?

MC: Лидер Core Architecture, или лидер Core Roadmap, я бы сказал. На самом деле я не так часто думал об этом.

Zen: Начало
IC: Этот квартал для AMD посвящен пятилетию Zen и Ryzen, начиная с первого упоминания в прессе микроархитектуры на Hot Chips в августе 2016 года. Реально, когда для вас начался путь Zen - кто был главными, и были ли вы ведущим архитектором с самого начала?

MC: Ну, для меня все началось в 2012 году. Мы поняли, что нам нужно сделать что-то отличное от линейки Bulldozer. Джим (Келлер. Прим. перевод.) пришел и помог реорганизовать команду, а я стал ведущим архитектором. Так что для меня прошло почти 10 лет.

А насчет разработчиков, с тех пор как мы начали работать в 2012 году, здесь так много людей, и команда просто потрясающая. Я очень благодарен за то, что могу представлять работу стольких замечательных инженеров". Сюзанна Пламмер была лидером команды Zen, управляла командой и просто держала команду вместе, она была просто потрясающей. А также Майк Туук, Тим Уилкинс, Джей Флейшман, Лесли Барнс - самые разные люди, которые вносили свой вклад со всех концов компании, чтобы Zen стал успешным.

Забавно говорить, что я работаю над ним с 2012 года - если вернуться назад, у меня до сих пор хранится наша первая схема HLD (High-Level Design), которую мы сделали для Zen. Вы не поверите, насколько по-другому она выглядит после пяти лет, потраченных на то, чтобы довести что-то до ума. Я имею в виду, что скелет там тот же, вы видите это, но так много вещей изменилось со временем. Это один из ключевых моментов в этом бизнесе - быть динамичным, чтобы все менялось, срок разработки очень долгий. Но при этом уметь создавать конкурентоспособный дизайн - это что-то потрясающе. Время от времени, когда мы только начинали, когда команды волновались или чувствовали себя неуверенно по поводу их HLD, я был тем, кто приходил и говорил: "Посмотри как выглядел Zen, ничто не будет идеально после HLD, но все изменится, и станет лучше". Так что в этом и заключается искусство этой работы.

IC: Реально ли когда-нибудь иметь возможность изменить дизайн, основываясь на том, что только что выпустили конкуренты? Или у вас все еще есть двухлетний запас времени на изменения?

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

IC: Одна из интересных историй из саги о Ryzen заключается в том, что финансирование разработки процессоров было заморожено и отделено от остального бизнеса в то время, когда AMD испытывала финансовые трудности. Как это пошло вам на пользу, или какие-либо ограничения проявились с вашей точки зрения, практические или эмоциональные?

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

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

IC: В недавнем интервью, которое я взял у Джима Келлера, Джим упоминает о большом совещании по дизайну чипов в 8 утра - много разногласий, но он упомянул, что вы были одним из тех, кто твердо верил, что вы сможете добиться успеха. Каково это было - быть вызванным на то собрание, обсуждать эти идеи и оглядываться на успех, которого добилась Zen?

МС: Для меня это потрясающе! Этот инженерный обмен - то, что мы называем "концепцией", которую мы делаем для каждого большого проекта. В то время, для таких больших изменений, которые предполагала микроархитектура Zen, я бы сказал, что споров было, наверное, больше, чем обычно.

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

С кэшем микроопераций мы делали подобное в проекте, который был отменен, а на самом деле мы должны были сделать это в Bulldozer 2. Для Zen нам нужно было сделать это, чтобы достичь нашей агрессивной цели - поднять IPC на 40%. Я думаю, что после таких обсуждений люди, которые увидели, что это возможно, остались, а некоторые из тех, кто считал, что это невозможно, решили пойти своим путем.

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

IC: Я спросил Джима, является ли он отцом Zen, и он ответил, что он один из "сумасшедших дядек". Являетесь ли вы отцом дзен?

MC: Я определенно согласен с Джимом, что для создания Zen потребовалось много людей. Но да, я считаю себя отцом Zen - в том смысле, что я дал ему название. Я был там в 2012 году в первый день, и я был с ним все время. Я знаю о нем все хорошее и плохое, как родители знают своих детей - вы знаете, в чем они хороши, а в чем не очень, и я чувствовал боль от всех наших промахов, и я видел радость от всех наших успехов. Но так же как и с ребенком, с чипом есть такой момент, когда его приходится отпустить в свет. Ты больше не можешь контролировать это! Другие люди критикуют и ты воспринимаешь это как твою персональную критику. Я был так долго с ним, что полностью эмоционально поглощен ним. Из-за этого, знаете, другие люди могут приходить, уходить и двигаться дальше, но я был с Zen от начала и до конца. Так что в этом отношении я действительно считаю себя отцом. Но, как я уже сказал, для того, чтобы это произошло, потребовалась удивительная команда - я не смог сделать это в одиночку, так же как и воспитанием ребенка не занимается один человек. Для этого нужно очень много людей.

IC: Недавно CMO AMD Джон Тейлор упомянул, что за названиями Zen и Ryzen скрывается интересная история. Что это за история?

MC: С архитектурой Bulldozer я понял, что за все эти годы создание ядер x86 сводится к поиску правильного баланса в архитектуре между частотой, IPC, мощностью и площадью. С Bulldozer мы не достигли этого, и поэтому я почувствовал, что нашему новому проекту нужно название, которое говорит о нашей истинной цели - сбалансированной архитектуре. Название "Zen" как нельзя лучше подходило к тому, что мы делаем.

Я думаю, что с точки зрения Ryzen, когда они показали мне его в первый раз, они немного нервничали, так как переживали по поводу того, что оно мне может не понравиться. Но когда я увидел его, когда я увидел Enzo (буддийский символ круг нарисованный кистью, который лёг позже в основу логотипа. Прим. перевод.), когда я увидел, что это открытый Enzo, с красотой несовершенства (а мы знаем, что Zen не совершенен, у всех ядер есть свои проблемы), он просто идеально представлял то, о чем я думал, когда назвал его в 2012 году. Казалось, что это просто идеальная синергия. Никто не говорил со мной об этом, пока не показал мне его, я думаю, они нервничали. Когда они показали его мне, я понял, что это потрясающе. Это было именно то, о чем я думал, даже не говоря им об этом.

IC: А когда юристы вернулись и сказали, что да, мы можем запатентовать это, вы подняли два больших пальца вверх! (тут идет игра слов, поднимать по-английски rising, что созвучно с названием процессора Ryzen. Прим. перевод.)

MC: [смеется] Мне нравится то, что оно звучит очень похоже на rising, как Ryzen и rising. В нем есть эта вторичность - я подумал, что это блестяще, что AMD снова поднимается вверх. На мой взгляд, это просто гениальный маркетинг и нейминг.

IC: Наряду с Zen мы узнали о Project Skybridge, возможности установки x86 SoC и Arm SoC на одном сокете. Знаете ли вы, как далеко продвинулась в разработке версия Skybridge для Arm, проект более известный как K12, до того, как AMD полностью перешла на Ryzen?

MC: Первоначально Zen и K12 были, я думаю, мы называем их родственными проектами. У них были примерно одинаковые цели, только разные ISA (Instruction Set Architecture, набор инструкций. Прим. перевод.). Собственно ядро было таким, а иерархия L2/L3 могла быть любой. Затем, конечно, в Skybridge, Data Fabric могла быть любой. Целая команда занималась K12, и мы делились многими вещами, чтобы быть эффективными, и провели много хороших дебатов об архитектуре. Хотя я работал на x86 в течение 28 лет, это всего лишь ISA, и вы можете создать маломощный или высокопроизводительный дизайн на любом ISA. Я имею в виду, что ISA имеет значение, но это не главный компонент - вы можете изменить ISA, если вам нужны какие-то специальные инструкции для работы, но на самом деле микроархитектура во многом не зависит от ISA. Есть некоторые интересные причуды в различных ISA, но в конце концов, все дело в микроархитектуре. Но на самом деле я был полностью вовлечен в создание Zen'а.

Дизайн ядер

IC: Когда мы говорим о ядрах и продуктах, всегда самое время выйти на рынок и уложиться в сроки. На самом деле, после того как продукт вышел в свет, как быстро вы начинаете думать о своих просчетах, и о том что можно было сделать лучше?

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

Но именно в этом мы видим нашу стратегию. Мы знаем, что когда мы проводим редизайн [ядра], у нас будет много возможностей улучшить то, что мы сделали раньше [в новой версии (поколении)]. Поэтому мы хотим, чтобы наш исходный дизайн (первая производная) который ляжет в основу нового чипа был как можно более гибким, и чтобы он стоил тех 12-18 месяцев, которые потребуются для его создания. Затем, сделав это, мы знаем, что создание второй производной обычно не стоит затраченных усилий - с точки зрения производительности/мощности вы мало что можете получить от этого. Вы всегда можете добавить к ней больше, но у вас больше мощности, и вы скорее прикручиваете что-то сбоку, чем действительно влезаете и переделываете внутренности машины.

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

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

Первый A0 Zen нуждался в охлаждении

IC: Являетесь ли вы тем архитектором, который первый видит воплощение новых идей в кремнии? И если да, то каково это? Какая атмосфера в лаборатории при этом?

MC: Я бы с удовольствием, но часто меня к этому даже не подпускают! Я прихожу туда позже. Когда привозят первые инженерные образцы, там много работы с BIOS и прошивкой, которые на самом деле даже не связаны с ядром. Поэтому в то время нет особой необходимости в моем участии или участии ведущего архитектора этой конкретной микроархитектуры. Но очень быстро, когда команда доводит его до ума и запускает и загружает, это становится важным.

Что касается оригинального Zen, то одна из удивительно забавных историй, которая у меня есть, это то, что с первым кремнием A0, у нас определенно были некоторые проблемы. Нам приходилось запускать его очень холодным, чтобы он заработал. Мы ждали, когда нам привезут исправленный A1, или даже A0+, чтобы решить проблемы, и нам не нужно было запускать его холодным. Один из инженеров сказал: "Вы уже опробовали патч на нем?" - я ответил: "Нет, я сижу здесь и жду, пока он высохнет". Когда мы держим его настолько холодным, что образуется конденсат, время от времени нам приходится останавливаться, чтобы дать ему высохнуть. "Как только он высохнет, я сообщу вам, сработал ли ваш патч." Это безумие, но я люблю работающую лабораторию - я определенно архитектор, который любит пачкать руки. К сожалению, мне не удается испачкать их так сильно, как раньше, и я обычно подключаюсь гораздо позже, когда возникают действительно сложные проблемы.

IC: Забавно, что вы вспомнили эту историю, потому что она меня заинтересовала. Когда вы получаете кремний A0, и он не работает при нормальной температуре, что подсказывает вам, что его нужно его охладить? Кто об этом думает? Как человек приходит к мысли, что это то, что ему нужно сделать для нормальной работы? И как тогда найти исправление для A0? Плюс, это конструкторское исправление? Или это производственное исправление? Как найти разницу между ними?

MC: В этом случае у нас есть множество способов тестирования кремния. У нас есть команды DFT (design for test), чтобы понять, что схемы низкого уровня не работают должным образом. У нас есть сильная команда разработчиков схем, которая занимается отладкой подобных проблем, и они понимают, что это проблема с температурой, но затем предлагают, что если бы было холодно, то можно было бы еще поработать над этим. Они также говорят, что не так со схемой, чтобы ее можно было исправить и построить A0+, чтобы получить вещи, которые могут работать при нормальных температурах. Повторюсь, количество отличных инженеров, работающих над любым продуктом в AMD, просто поражает, и мне нравится считать себя всесторонне развитым, но есть люди, которые во многих вещах разбираются гораздо лучше меня!

Дизайн будущих чипов

IC: Дизайн современных х86 процессоров основан на наборе инструкций переменной длинны - все высокопроизводительные микроархитектуры и Intel, и AMD имели возможность одновременной расшифровки 4-х инструкций за такт. Но как мы видели, что не проблема создать дизайн с двумя модулями расшифровки по 3 инструкции за такт или даже один модуль с 6-ю инструкциями. Для Zen 1 декодер с 4-мя инструкциями был очень хорош, но если мы взглянем на Zen 3 то там используется тот же самый модуль. Какие дальнейшие планы в этом направлении? Как вообще увеличение ширины декодера может изменить рост показателя IPC?

MC: Я думаю нужно вспомнить то, что я говорил про баланс. Увеличение ширины декодера очень сильно увеличит необходимость в транзисторном бюджете, а так же нам придется разрабатывать новый предсказатель ветвлений и изучать новые схемы и алгоритмы выборки инструкций. На сегодня это все сбалансированно. У нас на всё есть транзисторный бюджет, и на сегодня не самый оптимальный вариант тратить его на развитие front end'а. Да это правда, бюджет всё время растет, и позволяет нам улучшать весь дизайн увеличивая IPC.

IC: Насколько вы полагаетесь на свои команды по конкурентному анализу и прогнозированию рабочих нагрузок, когда речь заходит о ваших планах? Если бы вы вернулись в 2012 год, пытаясь предсказать вычислительную мощность необходимую в 2016 году, были ли эти предсказания реалистичными?

MC: У нас отличные команды, и в каком-то смысле проблема, которую вы обозначили, не зависит от команды. Либо вы пытаетесь построить процессор на сегодняшнем программном обеспечении, либо на программном обеспечении которое появится через пять лет. Это та область, где многое зависит от опыта архитектора, понимания того, каким образом будут расти и распределяться рабочие нагрузки, у тут необходим определенный дар предвидения. Например, при ширине декодера в 4 инструкции многие компиляторы проводят оптимизацию, потому что у вас четырехполосный декодер. Но когда мы дадим им что-то более широкое, придётся разрабатывать новые компиляторы, чтобы понять, как скомпилировать код, чтобы сделать его еще лучше. Таким образом, мы увидим, что нам удалось получить только 10-15% IPC для программ скомпилированных старыми компиляторами, но по мере развития компиляторов преимущества от более широких декодеров будет значительно больше, и разница в производительности для программ скомпилированных новыми компиляторами будет значительно больше тех 10-15%.

IC: Что касается концепции кэша - анонс 3D-кэша от AMD, продукты с которым будут представлены в следующем году, несомненно, очень важен. Я не собираюсь спрашивать вас о конкретных продуктах, но вопрос скорее в том, какой объем кэша является правильным? Вопрос наверное глупый, но не могу его не спросить.

MC: Это отличный вопрос! Дело даже не только в том, сколько нужно кэша, но и в том, сколько на каком уровне, какие задержки, что разделяет кэш и так далее. Как вы знаете, тут очень много компромиссов, из которых мы должны выбрать, как сделать, и понять, как на это отреагирует программное обеспечение.

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

Так что это очень интересная область - исследования компромиссов в кэш-памяти продолжаются всегда, и они будут продолжаться вечно - как сбалансировать иерархию кэш-памяти для ядра.

IC: Забавно, что вы заговорили о L2, потому что я не уверен, видели ли вы недавнее объявление IBM о чипе z16 / Telum. У них очень большие кэши L2, но они также используют их в качестве виртуального L3. Изучали ли вы этот вопрос, и кажется ли он вам привлекательным?

MC: Да, мы определенно изучали этот вопрос. Уилл Уокер - глава нашей команды кэширования, и он потрясающий архитектор. Как я уже сказал, каждый HLD (High Level Design) мы проходим через одни и те же вопросы, одни и те же проекты, рассматриваем различные аспекты дизайна, а затем должны выбрать один из различных вариантов. Даже иногда после HLD ситуация меняется, и если мы решили перейти к другому варианту дизайна, мы можем это сделать. Так что да, это постоянно развивающаяся архитектура.

IC: TSMC продемонстрировала возможность укладки 12 матриц с помощью TSV, аналогично концепции V-Cache. Реально, сколько слоев может поддерживаться, прежде чем возникнут такие проблемы, как тепловые нагрузки на базовую матрицу?

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

IC: В какой степени AMD внедрила машинное обучение в свои инструменты EDA? Как на данный момент, так и в будущем?

MC: Я не думаю, что мне позволено говорить об этом определенно, но я думаю, можно предположить, что все используют ту или иную форму машинного обучения на основе данных для улучшения всех наших бизнес-процессов.

IC: Это очень осторожный ответ!

IC: Изначально в Zen использовался 4-ядерный модуль CCX, а теперь базой в Zen 3 является 8-ядерный комплекс. Есть ли ограничения на то, насколько большим может быть комплекс в его нынешней форме, например, кольцевая шина, и что должно измениться по мере роста этого комплекса?

MC: Иерархия кэша для различных сегментов существенно отличается, мы создаем процессоры которые используются от high-end серверов, до ноутбуков. В различных средах требуется больше или меньше ядер, и попытка эффективно удовлетворить их потребности при минимальном количестве конструкций - это еще одна интересная архитектурная задача. Хотелось бы думать, что можно просто сосредоточиться на одном дизайне для каждого сегмента, например, у нас есть дорожная карта ядер X для серверов и Y для ноутбуков, но это не так. Мы должны понять, как использовать одну микроархитектуру на всех этих рынках. Некоторые рынки, такие как высокопроизводительные серверы, требуют все большего и большего количества ядер сумасшедшими темпами, в то время как другие сегменты не нуждаются в увеличении количества ядер такими же темпами. Мы видим, что количество ядер растет, и мы будем продолжать увеличивать количество ядер в нашем комплексе ядер, которые совместно используют L3. Как вы отметили, обмен данными через него имеет проблемы с задержками и когерентностью, но, хотя это и есть архитектура, и это то, но для того мы и работаем. Это то, ради чего мы живем - решение этих проблем. Поэтому я просто скажу, что команда уже изучает, что нужно для того, чтобы внедрить комплекс с количеством ядер, намного превосходящий тот, который мы используем сегодня, и как обеспечить это в будущем.

IC: Видите ли вы, что какая-то часть приобретения Xilinx станет частью будущего Ryzen?

МС: О, безусловно. Я не могу комментировать что-то конкретное. Мы продаем SoC, но мы, безусловно, интегрируем в них большое количество различных систем. Если вы посмотрите на их IP и наши IP, вы, вероятно, увидите естественный синергетический эффект, который, скорее всего, проявится в будущем. Я с нетерпением жду, когда эти ребята придут в компанию и будут работать с нами дальше. Это отличная команда.

IC: IPC всегда является золотой целью при проектировании высокопроизводительных процессоров, и одним из преимуществ более тонких техпроцессов является большее количество транзисторов, большие буферы, больше портов исполнения и большие кэши. Как вы подходите к тому, чтобы сделать ядро "умнее", а не просто "больше", и какие ключевые элементы в современных x86-процессорах являются ограничивающими факторами?

MC: Я думаю, что вся слава достается IPC! На самом деле, я называю это "колесом производительности", потому что есть четыре основных принципа - производительность, частота, площадь и мощность. Все они в определенном смысле равны, и для получения хорошего дизайна необходимо сбалансировать их все. Так, если вы будете стремиться к действительно высокой частоте, но не будете обращать внимание на IPC, то в итоге получите действительно плохой дизайн и большую площадь кристалла. Если вы очень сильно повысите IPC, но при этом увеличите площадь и мощность, вы так же можете оказаться в проигрыше. Так что это действительно очень важный вопрос, как мы уже сказали, мы пытаемся получить IPC, но мы должны получить его таким образом, чтобы оптимизировать использование транзисторов для площади и мощности, а также частоты. Если мы хотим иметь возможность установить кучу ядер и просто добавить IPC и увеличить площадь, мы не добьемся реального прогресса.

Я понимаю, это моя работа, и это работа моих ведущих архитекторов - пытаться найти правильный баланс. Я думаю, это была одна из самых важных особенностей Zen - потребляемая мощность была его сильной стороной, на которую мы обращали много внимания. Мы смотрели на мощность, как на все остальное в комплексе, и от симуляций нашего процессора мы получали еженедельную обратную связь о том, как у нас идут дела, знали, как изменились характеристики, и знали, каков наш IPC. На самом деле, у нас не было подходящих инструментов на ранних этапах проектирования, которые позволяли бы нам знать, где мы находимся по питанию, и к тому времени, когда мы узнали, мы мало что могли сделать - дизайн отвечающий за энергопотребление не получится легко и быстро переделать. Если бы мы воплотили наш процессор в кремнии и поняли бы, что энергопотребление не сбалансированно - у нас не было бы шанса его переделать.

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

Обратная связь - это как любая другая часть дизайна. Возможность обеспечить 40% IPC в более эффективном дизайне с Zen - это был один из первых камней преткновения, о которых мы говорили, но рост IPC в 40% достигнутый увеличением на 40% энергопотреблением - дорога в никуда.

IC: В недавнем видеоролике AMD, посвященном празднованию 5 лет Zen, говорилось о том, что более масштабируемое ядро является предпочтительным подходом в будущем по сравнению с гибридным гетерогенным дизайном. В чем заключаются трудности при создании ядра с таким масштабом, от милливатт до десятков ватт на ядро - это связано с проектированием логики, питанием или производством?

МС: Всё вместе! Как архитектор, мы должны учитывать все рынки, на которых мы хотим сосредоточиться. Если я хочу достичь такого-то IPC на такой-то частоте при такой-то мощности, мы не можем думать о ядре как об одной вещи и одном наборе целей - это должно быть много наборов целей, и мы должны планировать его таким образом с самого начала. Еще одной составляющей успеха Ryzen и Zen стало то, что мы не просто пытались использовать технологию для разных рынков. Мы думали о том, как масштабировать технологию на все эти рынки, и заранее разработали ее так, чтобы она была способна делать это. Таким образом, бэкенду будет легко изменить продукт для этих разных рынков и выполнить свою работу.

IC: Долгосрочные дорожные карты НИОКР обычно указываются на временном интервале 3/5/7 лет. По мере роста AMD, особенно в последнее время, как изменилась ситуация внутри AMD для вас?

МС: Не совсем. Я имею в виду, что еще в 2012 году мы думали далеко за пределами Zen, тем более что ваши клиенты требуют этого, верно? Они не перейдут к вам, если у вас нет долгосрочной дорожной карты. Наши клиенты требуют этого, когда хотят иметь с нами дело, и, конечно же, наши собственные команды требуют этого - наши команды хотят видеть дорожную карту! Было много людей, даже внутри компании, которые беспокоились, что мы не сможем поддерживать такие темпы прогресса. Это очень рискованная стратегия - переписывать все ядро с нуля каждые три года - это рискованно. Но, как мне кажется, мне удалось убедить всех, и это то, чего требует рынок. Если мы этого не сделаем, это сделает кто-то другой".

Zen 5, Zen 8 и все остальное

IC: В апреле 2018 года в рекламном ролике для AMD вы упомянули, что работаете над Zen 5. Прошло три года - значит ли это, что сейчас вы работаете над Zen 8?

МК: Вы очень хорошо посчитали, я так скажу! Кстати, я тогда за это получил небольшую взбучку (в 2018 году), но я думаю, вы знаете, насколько тяжел этот бизнес. Как я уже говорил ранее, вы должны быть динамичными и готовыми к тому, чтобы иметь процесс, который вы можете менять по мере того, как меняется рынок вокруг вас. Если вы построите именно то, что собирались сделать в первый день, вы выпустите что-то, что никому не нужно.

IC: И наконец, чего стоит ожидать пользователям AMD?

МС: Все будет замечательно! Хотел бы я рассказать вам обо всем, что нас ждет. У меня есть ежегодная встреча по архитектуре, на которой мы обсуждаем все, что происходит, и на одной из них (не буду говорить когда) мы с командой рассмотрели Zen 5. Я узнал много нового, потому что сейчас, когда я занимаюсь больше дорожной картой, я не так близко знаком с дизайном, как хотелось бы. Выходя с той встречи, я просто хотел закрыть глаза, заснуть, а потом проснуться и купить эту штуку. Я хочу быть в будущем, эта вещь потрясающая, и она будет такой замечательной - я не могу этого дождаться". Самое сложное в этом бизнесе - знать, сколько времени потребуется, чтобы довести то, что вы задумали, до того уровня, когда это можно будет производить.


Источник: vk.com

Комментарии: