В данном случае предлагается не истина, а определенный взгляд. Очень весомый взгляд, т.к. принадлежит человеку, который занимается машинами со времен БЭСМа.
У Бабаяна есть и противники (их не мало), и сторонники. У меня есть идея проинтервьюировать некоторых из противников (правда, не блоггеров, а людей, сделавших весомый вклад в развитие техники). Тогда будет более полная картина.
Правда, пока даже противники (с которыми я успел пообщаться) сходятся в том, что Бабаян во многом опережает своими идеями время. По мнению одного из них, железо пока не дозрело (ну или было недозревшим) до того, чтобы идеи задышали в полную силу…
Спасибо, очень интересно. Только вот здесь непонятно:
Какие дополнительные плюшки есть в WiDi, но отсутствуют в Miracast? На сей день их три:
…
•поддержка системы защиты контента HDCP (High-bandwidth Digital Content Protection);
…
А на картинке с подписью «Архитектура Miracast (со стороны передатчика)» показана поддержка HDCP.
Может, имеется в виду, что для Miracast она необязательна?
Длительность можно измерять хоть в попугаях, если это будет удобно. Но при выборе частоты речь должна идти именно об астрономическом времени. Потому что длина такта выбирается на основе времени работы логических устройств, а не наоборот.
Представьте себе процессор, который должен уметь выполнять одну-единственную операцию. Например, логическое «И». Такой процессор будет состоять из транзистора и нескольких проводов. Задержки транзистора и проводов фиксированы. Повлиять на них могут только внешние условия, вроде влажности и температуры.
Длина такта для такого «компьютера» будет выбрана так, чтобы в него уместилось время работы элемента + некоторый допуск на внешние условия.
1) Под «помехами» автор понимает именно помехи. С ростом частоты, спектральный состав помех изменяется. Факт! На помехи расходуется мощность. Факт!
Дальше автор, видимо, пытается связать мощность помех с нагревом МП. Такая связь, очевидно, есть. В самых ужасных случаях до 10-20% полной мощности может уйти в помехи (т.е. 10-20% процентов нагрева происходит по вине помех).
Дальше я могу только задать вопрос: и что?
Самое страшное в помехах не то, что они греют процессор, а то, что из-за них деградирует сигнал.
И это проблема.
Но я все еще не понимаю, с чем именно вы спорите.
Нагрев МП — проблема. Деградирование фронта — проблема. Никто с этим не спорит. Куча других проблем еще есть.
Может, вы хотите сказать, что существует какое-то принципиальное ограничение на частоту МП, которое лежит в районе 3.8ГГц? Но ведь это не так. Даже оверклокеры гонят частоту до 8ГГц.
Поясните, пожалуйста, что вы хотите доказать.
2) Разгонять P4 дальше никакого смысла не было. Это был утюг с производительностью калькулятора. Успехи в области техпроцесса шли не на разгон, а на снижение мощности.
Не совсем понимаю, о каких выводах, «сделанных в топике», вы говорите.
В статье предлагается определенная точка зрения на проблему: частоту можно поднять, только уменьшив длину стадии. Иначе никак. Стадия обязана влезать в такт.
Каким образом уменьшать длину стадии — вопрос сложный и многогранный. Вы хотите зайти со стороны техпроцесса, как я понимаю.
Давайте зайдем со стороны техпроцесса. Никаких противоречий я здесь не вижу. Мы реально наблюдаем рост частоты при совершенствовании техпроцесса (при условии, что этот рост не разменивается на лучшую энергоэффективность; сейчас тенденции таковы, что в low-end и middle-сегментах такой размен может быть выгоден из-за того, что производительность там не очень интересна).
Теперь про вашу ссылку. Автор там делает то же самое, что и вы, — сравнивает несравнимое, т.е. ставит в один ряд принципиально разные микроархитектуры. Нельзя ставить в один ряд, например, процессоры семейства P4 и процессоры семейства Core, а затем сравнивать их исключительно с позиции техпроцесса.
По-хорошему, P4 с микронным процессом нужно сравнивать с P4 с нанометровым процессом (если бы такой был). При таком сравнении мы бы увидели приличный рост частоты (+ примерно линейный рост мощности + по-прежнему бестолковый IPC).
В скопированных вами сюда рассуждениях автор явно путает помехи (это то, что искажает фронт сигнала) с тепловыделением…
Мда… Вот что значит писать комменты во втором часу… Atom, конечно же, изначально суперскалярен. Я почему-то держал в голове OOO когда писал коммент. Прошу прощения.
По поводу x86 и суперскалярности. Все верно: x86 != суперскалярность. Но сейчас все представители семейства суперскалярны (даже Atom с недавних пор обрел это свойство), так что я не стал здесь вдаваться в детали.
Частота P4 не была «отвоевана». Она была завоевана. P4 из-за постоянного реплэя выделял мощность в соответствии со своей частотой, а IPC демонстрировал низкий. Эффективно он работал как процессор с более низкой частотой.
Тоже немного по нему ностальгирую. Технически он еще жив, т.к. все еще есть клиенты, которые его покупают. Но уже не развивается.
Itanium отлично показал себя на некоторых классах задач, но на некоторых оказался средненьким. В общем, не потянул на general purpose архитектуру.
Однако на нем были обкатаны некоторые интересные фишки (двоичная трансляция, например). Многие из этих фишек, подозреваю, получат новые воплощения, но уже с учетом полученных уроков.
Не стоит напрямую связывать обратную совместимость и возможность работать над длиной стадии. Однако действительно: отказ от совместимости позволяет работать над проблемой более эффективно.
Идеальная машина — это та, в которой единственные связи между инструкциями — это связи по данным (т.е. одни инструкции используют результаты работы других). Задача разработчиков архитектуры — постоянно приближаться к этому идеалу, устраняя все другие (кажущиеся искусственными) зависимости. Не думаю, что ARM сейчас ближе к этому идеалу, чем x86.
Зачем любители ARM хотят «похоронить» x86 (а они действительно хотят?), я не знаю. Я за разнообразие архитектур. Без конкуренции ничего хорошего не получается :)
И еще я бы не сказал, что единственная причина, по которой x86 жива, — это большое количество написанных программ. Все-таки, на сегодняшний день, это самая эффективная архитектура, которая все еще продолжает развиваться.
Софт со временем созреет. Сейчас многое для этого делается: синтаксические расширения языков программирования, библиотеки хорошие, обучение студентов в ключе «параллельного мышления».
Основная проблема как раз в этом и есть: нынешние поколения программистов не привыкли мыслить параллельно. Как говорит один мой знакомый, параллельно умеют мыслить только домохозяйки. У них в одном углу ребенок растет, в другом кастрюля кипит, а в третьем белье гладится. И ведь все синхронизовано! :)
Кстати, над автоматическим распараллеливанием программ работы тоже ведутся. Но здесь все как-то запредельно сложно получается пока что…
Вы, наверное, имеете в виду спецификатор «inline»?
Такой спецификатор является не «указанием», а скорее, пожеланием. Компилятор может отказаться выполнять подстановку функции, отмеченной этим спецификатором.
Помимо этого компилятор может выполнять подстановки функций, не отмеченных словом «inline» (если ему позволяет заданный опциями режим работы).
Так что «инлайнинг» — это действительно оптимизация, и довольно непростая во многих случаях.
Все верно: в общем случае такая оптимизация не пройдет. Но в общем случае вообще никакая оптимизация не пройдет. Задача компилятора во многом состоит в том, чтобы отыскивать возможности для оптимизации.
Приведенный пример служит лишь иллюстрацией (одной из самых простых). Но даже такие примеры на практике встречаются довольно часто. Программист редко работает лишь со внешними объектами. Как только он определяет что-то свое, у компилятора сразу возникает простор для творчества.
Попробую пояснить.
Я не хотел слишком подробно разбирать этот пример, что привело, видимо, к слишком сумбурному тексту.
Дело в том, что мы с вами вкладываем разный смысл в слово «поддерживает».
Конечно же, любой компилятор для C++ поддерживает полиморфизм в том смысле, что строго выполняет требования стандарта языка C++. Но я имел в виду немного другое.
Продолжим разбор примера.
Что происходит в динамике (т.е. во время выполнения программы), когда необходимо выполнить инструкцию «int value = ptr->func();»
А происходит примерно следующее:
1) из участка памяти, соответствующего экземпляру класса, на который указывает «ptr», берется указатель на таблицу виртуальных функций
2) из таблицы виртуальных функций достается указатель на функцию «func»
3) таким образом, мы получили указатель именно на ту версию виртуальной функции «func», которая соответствует конкретному типу класса. Лишь на этом этапе мы можем, наконец, вызвать «func».
Мы видим, что реализованный напрямую механизм виртуальных функций приводит к дополнительным косвенностям: в коде, вместо вызова конкретной функции, стоит вызов функции через указатель. Мало того, что это замедляет сам вызов, это не дает компилятору возможности выполнить подстановку вызова (inline) просто напросто потому, что мы не знаем, какой вызов подставлять (т.к. у нас есть несколько версий функции «func»).
Задача оптимизирующего компилятора состоит в том, чтобы как можно больше узнать о типе класса, для которого вызывается виртуальная функция. А это довольно нетривиальная (в общем случае) задача.
В рассмотренном выше примере компилятор мог действовать примерно так:
1) мы видим, что «ptr» может указывать только на класс типа «A»
2) значит, вызываться может только версия «func», определенная для класса «A»
3) заменяем вызов через таблицу виртуальных функций непосредственно на вызов нужной версии
4) теперь, когда у нас есть конкретный вызов, мы можем его попросту подставить.
Таким образом, у нас вообще не остается вызова. Остается просто присваивание «value = 5».
Данная запись является вводной для цикла постов о принципах работы оптимизирующих компиляторов, о сложностях их использования и о бонусах, которые можно получить от использования хорошего компилятора.
Если вам интересны какие-то определенные темы, оставляйте запросы. Попробуем рассмотреть то, что интересно именно вам.
В данном случае предлагается не истина, а определенный взгляд. Очень весомый взгляд, т.к. принадлежит человеку, который занимается машинами со времен БЭСМа.
У Бабаяна есть и противники (их не мало), и сторонники. У меня есть идея проинтервьюировать некоторых из противников (правда, не блоггеров, а людей, сделавших весомый вклад в развитие техники). Тогда будет более полная картина.
Правда, пока даже противники (с которыми я успел пообщаться) сходятся в том, что Бабаян во многом опережает своими идеями время. По мнению одного из них, железо пока не дозрело (ну или было недозревшим) до того, чтобы идеи задышали в полную силу…
Какие дополнительные плюшки есть в WiDi, но отсутствуют в Miracast? На сей день их три:
…
•поддержка системы защиты контента HDCP (High-bandwidth Digital Content Protection);
…
А на картинке с подписью «Архитектура Miracast (со стороны передатчика)» показана поддержка HDCP.
Может, имеется в виду, что для Miracast она необязательна?
Длительность можно измерять хоть в попугаях, если это будет удобно. Но при выборе частоты речь должна идти именно об астрономическом времени. Потому что длина такта выбирается на основе времени работы логических устройств, а не наоборот.
Представьте себе процессор, который должен уметь выполнять одну-единственную операцию. Например, логическое «И». Такой процессор будет состоять из транзистора и нескольких проводов. Задержки транзистора и проводов фиксированы. Повлиять на них могут только внешние условия, вроде влажности и температуры.
Длина такта для такого «компьютера» будет выбрана так, чтобы в него уместилось время работы элемента + некоторый допуск на внешние условия.
Так первичны абслютные времянки, а не такты…
Дальше автор, видимо, пытается связать мощность помех с нагревом МП. Такая связь, очевидно, есть. В самых ужасных случаях до 10-20% полной мощности может уйти в помехи (т.е. 10-20% процентов нагрева происходит по вине помех).
Дальше я могу только задать вопрос: и что?
Самое страшное в помехах не то, что они греют процессор, а то, что из-за них деградирует сигнал.
И это проблема.
Но я все еще не понимаю, с чем именно вы спорите.
Нагрев МП — проблема. Деградирование фронта — проблема. Никто с этим не спорит. Куча других проблем еще есть.
Может, вы хотите сказать, что существует какое-то принципиальное ограничение на частоту МП, которое лежит в районе 3.8ГГц? Но ведь это не так. Даже оверклокеры гонят частоту до 8ГГц.
Поясните, пожалуйста, что вы хотите доказать.
2) Разгонять P4 дальше никакого смысла не было. Это был утюг с производительностью калькулятора. Успехи в области техпроцесса шли не на разгон, а на снижение мощности.
В статье предлагается определенная точка зрения на проблему: частоту можно поднять, только уменьшив длину стадии. Иначе никак. Стадия обязана влезать в такт.
Каким образом уменьшать длину стадии — вопрос сложный и многогранный. Вы хотите зайти со стороны техпроцесса, как я понимаю.
Давайте зайдем со стороны техпроцесса. Никаких противоречий я здесь не вижу. Мы реально наблюдаем рост частоты при совершенствовании техпроцесса (при условии, что этот рост не разменивается на лучшую энергоэффективность; сейчас тенденции таковы, что в low-end и middle-сегментах такой размен может быть выгоден из-за того, что производительность там не очень интересна).
Теперь про вашу ссылку. Автор там делает то же самое, что и вы, — сравнивает несравнимое, т.е. ставит в один ряд принципиально разные микроархитектуры. Нельзя ставить в один ряд, например, процессоры семейства P4 и процессоры семейства Core, а затем сравнивать их исключительно с позиции техпроцесса.
По-хорошему, P4 с микронным процессом нужно сравнивать с P4 с нанометровым процессом (если бы такой был). При таком сравнении мы бы увидели приличный рост частоты (+ примерно линейный рост мощности + по-прежнему бестолковый IPC).
В скопированных вами сюда рассуждениях автор явно путает помехи (это то, что искажает фронт сигнала) с тепловыделением…
Частота P4 не была «отвоевана». Она была завоевана. P4 из-за постоянного реплэя выделял мощность в соответствии со своей частотой, а IPC демонстрировал низкий. Эффективно он работал как процессор с более низкой частотой.
Itanium отлично показал себя на некоторых классах задач, но на некоторых оказался средненьким. В общем, не потянул на general purpose архитектуру.
Однако на нем были обкатаны некоторые интересные фишки (двоичная трансляция, например). Многие из этих фишек, подозреваю, получат новые воплощения, но уже с учетом полученных уроков.
Идеальная машина — это та, в которой единственные связи между инструкциями — это связи по данным (т.е. одни инструкции используют результаты работы других). Задача разработчиков архитектуры — постоянно приближаться к этому идеалу, устраняя все другие (кажущиеся искусственными) зависимости. Не думаю, что ARM сейчас ближе к этому идеалу, чем x86.
Зачем любители ARM хотят «похоронить» x86 (а они действительно хотят?), я не знаю. Я за разнообразие архитектур. Без конкуренции ничего хорошего не получается :)
И еще я бы не сказал, что единственная причина, по которой x86 жива, — это большое количество написанных программ. Все-таки, на сегодняшний день, это самая эффективная архитектура, которая все еще продолжает развиваться.
Основная проблема как раз в этом и есть: нынешние поколения программистов не привыкли мыслить параллельно. Как говорит один мой знакомый, параллельно умеют мыслить только домохозяйки. У них в одном углу ребенок растет, в другом кастрюля кипит, а в третьем белье гладится. И ведь все синхронизовано! :)
Кстати, над автоматическим распараллеливанием программ работы тоже ведутся. Но здесь все как-то запредельно сложно получается пока что…
Такой спецификатор является не «указанием», а скорее, пожеланием. Компилятор может отказаться выполнять подстановку функции, отмеченной этим спецификатором.
Помимо этого компилятор может выполнять подстановки функций, не отмеченных словом «inline» (если ему позволяет заданный опциями режим работы).
Так что «инлайнинг» — это действительно оптимизация, и довольно непростая во многих случаях.
Приведенный пример служит лишь иллюстрацией (одной из самых простых). Но даже такие примеры на практике встречаются довольно часто. Программист редко работает лишь со внешними объектами. Как только он определяет что-то свое, у компилятора сразу возникает простор для творчества.
Я не хотел слишком подробно разбирать этот пример, что привело, видимо, к слишком сумбурному тексту.
Дело в том, что мы с вами вкладываем разный смысл в слово «поддерживает».
Конечно же, любой компилятор для C++ поддерживает полиморфизм в том смысле, что строго выполняет требования стандарта языка C++. Но я имел в виду немного другое.
Продолжим разбор примера.
Что происходит в динамике (т.е. во время выполнения программы), когда необходимо выполнить инструкцию «int value = ptr->func();»
А происходит примерно следующее:
1) из участка памяти, соответствующего экземпляру класса, на который указывает «ptr», берется указатель на таблицу виртуальных функций
2) из таблицы виртуальных функций достается указатель на функцию «func»
3) таким образом, мы получили указатель именно на ту версию виртуальной функции «func», которая соответствует конкретному типу класса. Лишь на этом этапе мы можем, наконец, вызвать «func».
Мы видим, что реализованный напрямую механизм виртуальных функций приводит к дополнительным косвенностям: в коде, вместо вызова конкретной функции, стоит вызов функции через указатель. Мало того, что это замедляет сам вызов, это не дает компилятору возможности выполнить подстановку вызова (inline) просто напросто потому, что мы не знаем, какой вызов подставлять (т.к. у нас есть несколько версий функции «func»).
Задача оптимизирующего компилятора состоит в том, чтобы как можно больше узнать о типе класса, для которого вызывается виртуальная функция. А это довольно нетривиальная (в общем случае) задача.
В рассмотренном выше примере компилятор мог действовать примерно так:
1) мы видим, что «ptr» может указывать только на класс типа «A»
2) значит, вызываться может только версия «func», определенная для класса «A»
3) заменяем вызов через таблицу виртуальных функций непосредственно на вызов нужной версии
4) теперь, когда у нас есть конкретный вызов, мы можем его попросту подставить.
Таким образом, у нас вообще не остается вызова. Остается просто присваивание «value = 5».
Если вам интересны какие-то определенные темы, оставляйте запросы. Попробуем рассмотреть то, что интересно именно вам.