Comments 56
По их подсчетам, на каждый потраченный доллар (а стоимость процессора составляет $1995) пользователь получит производительность в 4 раза.
Бессмыслица какая-то.
Кроме того, на графиках интеловские процессоры сравниваются в неким Falkor. Какое он имеет отношение к рассматриваемому Qualcomm Centriq 2400 вообще не понятно.
Falkor — микроархитектура ядер CPU, Centriq — название процессора. Аналогично у Intel — Skylake и Xeon или у AMD Zen и EPYC.
Перейдите по ссылке на оригинал статьи там есть таблица характеристик сравниваемых процессоров, почти в самом вверху.
blog.cloudflare.com/arm-takes-wing
Centriq это название процессора — Falkor это архитектура или название версии. Так же как и Skylake у интела. Автор почему-то про это не написал. Тоесть Falkor на графиках это и есть Centriq.
blog.cloudflare.com/arm-takes-wing
Centriq это название процессора — Falkor это архитектура или название версии. Так же как и Skylake у интела. Автор почему-то про это не написал. Тоесть Falkor на графиках это и есть Centriq.
Не осилил. Текст изобилует ошибками. Ощущение, что это не правленый он-лайн перевод.
Хорошая попытка. Но для того чтобы убедить перейти с Xeon`a к примеру, то Qualcomm`у нужно предоставить какую-то более убедительную информацию, чем «немного быстрее и экономичнее».
Пока что выглядит не очень, если честно. Даже на графиках (которые тоже не очень понятны, где там быстрее всех и лучше).
Пока что выглядит не очень, если честно. Даже на графиках (которые тоже не очень понятны, где там быстрее всех и лучше).
Отсутствие Meltdown?
Думаю для многих ДЦ весьма важный фактор энергопотребления. Т.к. это сильно увеличивает стоимость как самого ДЦ (система кондиционирования) так и обслуживание (расзоды на электрику как самого чипа так и системы кондиционирования).
Думаю тут все будет упираться в цену продукта и потом ДЦ посчитают каждый для себя, что ему выгоднее ставить.
Если производительность будет даже просто на том же уровне при той же цене, то уже за счет меньшего энергопотребления и соответственно меньшие расходы обсулживание, то уже имеет смысл.
Думаю тут все будет упираться в цену продукта и потом ДЦ посчитают каждый для себя, что ему выгоднее ставить.
Если производительность будет даже просто на том же уровне при той же цене, то уже за счет меньшего энергопотребления и соответственно меньшие расходы обсулживание, то уже имеет смысл.
Да, возможно. Но смотря какие будут расходы на переход от постоянных решений на новые.
Если реально проще и дешевле будет платить за электричество хотя бы, то никто этим заниматься не будет. И не забываем про контракты, которые предусматривают всякие вот такие вот моменты. Нельзя так просто взять и перейти к новому поставщику железа, потому что так захотелось.
Без вопросов. Когда есть выбор и новый игрок на рынке железа, это приведёт к переставновке сил и цены поползут вниз. Но для того чтобы это случилось, то что показали в прессрелизе, маловато будет для революции на таком уже устоявшемся рынке. :)
Если реально проще и дешевле будет платить за электричество хотя бы, то никто этим заниматься не будет. И не забываем про контракты, которые предусматривают всякие вот такие вот моменты. Нельзя так просто взять и перейти к новому поставщику железа, потому что так захотелось.
Без вопросов. Когда есть выбор и новый игрок на рынке железа, это приведёт к переставновке сил и цены поползут вниз. Но для того чтобы это случилось, то что показали в прессрелизе, маловато будет для революции на таком уже устоявшемся рынке. :)
Сначала все о Centriq 2400, а потом лихо появляется какой-то Фалкор)
Производственная версия Centriq SoC будет содержать 48 Falkor ядер,— в самом конце мы узнаем что это так микроархитектура ядер(?) называется (вроде как есть Pentium 4 а есть ядра NetBurst)
Со слов про Влада Краснова начинается blog.cloudflare.com/arm-takes-wing. Причем пропущено начало поста Влада где объяснение терминов.
А с уязвимостями-то что?
скорей всего, то же самое — ARM тоже подвержен.
На сайте ARM нет информации об уязвимости ядер Falkor и все, что нам удалось нагуглить — это одну заметку на networkworld. Автор считает, что так как процессор активно использует инструменты спекулятивного исполнения инструкций, проц почти наверняка в той или иной мере подвержен Spectre/Meltdown.
Кольцевая внутренняя шина — признак примитивности конструкции. При числе ядер больше 4-6 необходима уже сетевая топология
Смотрите какой 22-ядерный примитив:
www.anandtech.com/show/10158/the-intel-xeon-e5-v4-review/2
Ой, это же Интел породил. Ну тогда это гениальное произведение инженерного исскуства!
К слову задержки межядерного обмена при grid-топологии у Skylake-X выше, хотя и равномернее.
forum.ixbt.com/topic.cgi?id=8:25158:4965#4965
www.anandtech.com/show/10158/the-intel-xeon-e5-v4-review/2
Ой, это же Интел породил. Ну тогда это гениальное произведение инженерного исскуства!
К слову задержки межядерного обмена при grid-топологии у Skylake-X выше, хотя и равномернее.
forum.ixbt.com/topic.cgi?id=8:25158:4965#4965
Qualcomm Centriq 2400 работает только в одиночку.
Cavium Thunderx2 можно использовать в двухпроцессорных нодах, плюс он поддерживает больше памяти.
Но как бы не приключилась та же история, как с Cavuim… Объявили год назад, внятного плана отгрузки до сих пор нет.
У нас уже почти год готовы серверы по Cavium Thunderx2:
2U 4x нодовый сервер,
1U двухпроцессорный сервер.
OpenPower9 тоже выглядит неплохо. В феврале приедет пара нод, будем тестить.
Cavium Thunderx2 можно использовать в двухпроцессорных нодах, плюс он поддерживает больше памяти.
Но как бы не приключилась та же история, как с Cavuim… Объявили год назад, внятного плана отгрузки до сих пор нет.
У нас уже почти год готовы серверы по Cavium Thunderx2:
2U 4x нодовый сервер,
1U двухпроцессорный сервер.
OpenPower9 тоже выглядит неплохо. В феврале приедет пара нод, будем тестить.
Неужели лицензионная политика Intel довела ситуацию до того, что ARM уже всерьёз рассматривают для серверов? Или тут в другом причины? Мне вот казалось, что всё что не x86 — это либо какие-то промышленные/энтерпрайзные мейнфреймы, либо контроллеры для всяких телефонов/планшетов и прочего embedded.
С разморозкой в новом веке! ARM уже давно пытается занять свое место в этой нише, пока не очень, но надеюсь у них получится. Устали уже от этого мусора 8086, который упорно тащат десятилетиями.
А как там в ARM с мусором в наборе инструкций, не интересовались?
Можно поинтересоваться, почему конкретно вы считаете x86 «мусорной архитектурой», то есть, вот ваша личная практика, гипотетический полный переход на ARM — что бы парк вашей компании выиграл от него?
Минус 40% трат на электричество.
Плюс 9000% трат на замену оборудования, адаптацию существующего и написание нового софта под него, поддержку нестандартного решения.
Вот когда они все свои сервера на свои процессоры переведут, тогда и поговорим :)
Вообще, в случае с Centriq нельзя забывать, что это 10-нм процессоры, а в бенчмарках они сравниваются с 14-нм зионами, которые вскоре могут быть заменены новыми моделями. Было бы странно, если бы соотношение производительности к энергоэффективности у них было бы идентичным. На сегодня 10-нм конкурентов на x86 у Centriq, конечно же, нет, но они будут. И вопрос вот в чем, когда будут представлены x86-процессоры с 10-нм техпроцессом для серверов, насколько они будут отставать от Centriq по соотношению производительности к энергоэффективности, и будут ли отставать, вообще? Сиюминутная выгода от перехода на ARM вроде как понятна при условии готовности софта. Но готов ли софт, который актуален для вашего конкретного предприятия? Идентичен ли он про производительности его версиями под x86? И сколько времени и средств уйдет на подготовку софта и инфраструктуры для перехода — не проще ли дождаться новых серверников на x86? Отсюда и остается первоначальный вопрос — «а вам оно зачем», если производительность и энергоэффективность решений на x86 и arm будут условно идентичными? И почему именно ARM, а не какая-нибудь другая не менее замечательная, прогрессивная и «не мусорная», как выразился предыдущий оратор, архитектура?
У ARM нет _своих_ серверных процессоров. К тому же они чипы в принципе не выпускают.
x86 тянет за собой обратную совместимость со старыми процессорами, что очень мешает оптимизации такого важного параметра как производительность на ватт. Выкинуть бы оттуда кучу лишних инструкций и процессор станет быстрее, энергоэффективней и т.д. но это поломает обратную совместимость и тогда ARM-ы точно выиграют. Хотя чем тогда новый процессор будет отличаться от ARM-ов? На принципиальном уровне — ничем.
То есть, вы считаете, что отключение возможности исполнения инструкций, потерявших актуальность, при исполнении современных адекватно составленных приложений, может значительно повлиять на производительность или энергоэффективность процессоров, которые уже давно исполняют x86-инструкции лишь на уровне МОДИФИЦИРУЕМОГО микрокода, а фактически преобразуют их в более простые инструкции при исполнении? Ваше предположение подкреплено каким-то исследованиями, тестами?
Одно отключение не поможет. Просто само наличие инструкций не позволяет оптимизировать работу конвеера, например. А это за собой тянет проблемы с энергоэффективностью. Когда-то давно была статья, когда ещё появились процессоры на ARM-ядре, там было достаточно интересное исследование по их энергоэффективности и сделан вывод о том что сама архитектура x86 не позволяет делать энергоэффективные процессоры из-за наличия некоторого процента малоиспользуемых команд, в которых уже нет никакой насущной необходимости но обратная совместимость не позволяет их убрать с чистой совестью.
Еще раз хочу обратить ваше внимание на то, что в СОВРЕМЕННЫЕ x86 процессоры микрокод с набором инструкций x86 не вшит физически. Сложные инструкции преобразуются в более простые инструкции через конвертер микроопераций и вот уже они физически исполняются процессором, таким образом производителям x86-процессоров удалось сохранить совместимость со старыми приложениями, получив при этом набор преимуществ, характерный для RISC-процессоров, что впервые было представлено еще в Pentium Pro, и развивалось с каждым последующим поколением процессоров. Если ваша точка зрения подкреплена «давнишним», как вы выразились материалом, о противостоянии CISC и RISC образца 95 года и ранее, то данная информация устарела. Из более «современных» материалов можете загуглить заметку 2009 года — «Intel x86 Processors – CISC or RISC? Or both??». Также рекомендую тестовый материал, который доступен на сайте ARM — «The final ISA showdown: Is ARM, x86, or MIPS intrinsically more power efficient?». Если же я неправильно вас понял, пожалуйста, разверните вашу точку зрения подробнее и дайте названия статей и тестовых материалов, которые рекомендуете изучить, на которые ссылаетесь, чтобы обосновать ее.
У х86 сложнее блок декодирования инструкций, неравномерная и непредсказуемая плотность их (не помню по памяти, но, вроде, инструкция вместе с аргументами занимает от 1 до 16 байт?), что затрудняет упреждающее чтение/выполнение. Кроме того, инструкций банально много, а рантайм-трансляция инструкций по умолчанию не может не занимать времени/отнимать производительности/расходовать энергию.
Модифицируемость микрокода обновлениями серьезно ограничена.
Есть описание AMD K8 — основной микрокод зашит в ROM, обновления попадают в небольшую RAM. Патчи микрокода могут изменить лишь 8 адресов ROM (т.е. пропатчить микрокод/"отбросить ненужные" можно только для очень ограниченного числа команд): https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-koppe.pdf стр 6 Figure 1
По интелу — обновления микрокода имеют размер до 16 КБ https://www.dcddcc.com/docs/2014_paper_microcode.pdf (стр 16) и, вероятно, также являются лишь частичными патчами для ROM-микрокода.
Также следует помнить, что большинство простых операций декодируются без микрокода, аппаратными декодерами (3-4 шт), т.е. "конвертер" вшит физически. (https://www.dcddcc.com/docs/2014_paper_microcode.pdf — Simple instructions are directly decoded into a short sequence of fixed-length RISC-like operations… by hardware, whereas complex instructions are decoded by microcode ROM. Examples of the former include ADD, XOR, and JMP, while the latter include MOVS, REP, and CPUID.; http://www.agner.org/optimize/ http://www.agner.org/optimize/instruction_tables.pdf ops<=3, μops<=3 вероятно directly decoded аппаратурой)
А софт переписывать кто будет, и платить за всё это?
Где-то мелькала новость, что сервера на ARM выгоднее из-за энергоэффективности.
Всего на 45%, судя по заявлениям Qualcomm. Результаты тестов в обзоре тоже похожий результат показывают. Учитывая то, на сколько Intel и AMD продвинулись в последнее время в снижении энергопотребления, возможно отставание ещё сократится. А сложности с переходом на новый тип оборудования останутся в любом случае. Однопоточная производительность Falkor тоже не впечатляет.
Неплохо, но если сравнивать с каким-нибудь AMD EPYC 7501/7401 — выходит уже не так интересно по цене ЦПУ. Transistor count тоже близок. При этом EPYC вероятно быстрее в single-threaded.
Раз уж тут про процессоры — объясните мне пожалуйста, почему предсказение перетащили на уровень процессора вместо того, чтобы делать его на уровне компилятора и ключевых слов указывающих какой код вероятно будет исполняться чаще, а какой реже?
Ведь тогда и никакого случайного исполнения критического кода бы не было и производительность была бы выше, т.к. процессор не пытался бы угадать что исполнять тратя на это ресурсы и угадывая криво, а исполнял бы заранее заданные ветки.
Да и сложность программирования бы не выросла. Статический анализатор вполне способ понять, каокй код будет выполняться чаще и расставить соответствующие метки.
Плюс и сейчас программист пищущий важный код должен учитывать особенности работа кэша и спекулятивного исполнения, вместо того, чтобы просто указать что исполнять чаще.
Ведь тогда и никакого случайного исполнения критического кода бы не было и производительность была бы выше, т.к. процессор не пытался бы угадать что исполнять тратя на это ресурсы и угадывая криво, а исполнял бы заранее заданные ветки.
Да и сложность программирования бы не выросла. Статический анализатор вполне способ понять, каокй код будет выполняться чаще и расставить соответствующие метки.
Плюс и сейчас программист пищущий важный код должен учитывать особенности работа кэша и спекулятивного исполнения, вместо того, чтобы просто указать что исполнять чаще.
То, что вы описали называется VLIW. Не взлетел, потому что пришлось долго пилить компиляторы под каждый проц + динамическое предсказание все же даёт некоторые преимущества, а статическое и так все популярные компиляторы делают (-march, вот это всё)
Вроде бы достаточно всего одного дополнительного бита в инструкции перехода? Как «if (likely(x))» в ядре линукс. Возможно как раз процессоры без legacy смогут себе такое позволить.
Такое было в x86, но выпилили.
stackoverflow.com/questions/14332848/intel-x86-0x2e-0x3e-prefix-branch-prediction-actually-used?lq=1
stackoverflow.com/questions/14332848/intel-x86-0x2e-0x3e-prefix-branch-prediction-actually-used?lq=1
Itanium не взлетел, но Эльбрус ещё пытается.
Ну, если очень диванно, будь вы процессором, вы бы в какой кеш хотели бы чаще попадать?
Который подальше, или который поближе?
Который подальше, или который поближе?
Добавить manual prefetch и управление кэшем, вроде в Эльбрусе оно даже есть. Программирование станет сложнее, компиляция дольше, но теоретически программы станут шустрее.
0F 18 / 01 PREFETCHT0 m8 Move data from m8 closer to processor using T0 hint
0F 18 / 81 RETIRET0 m8 Mark data from m8 as evictable from T0 to T1,T2,RAM
0F 18 / 02 PREFETCHT1 m8 Move data from m8 closer to processor using T1 hint
0F 18 / 82 RETIRET1 m8 Mark data from m8 as evictable from T0,T1 to T2,RAM
0F 18 / 03 PREFETCHT1 m8 Move data from m8 closer to processor using T2 hint
0F 18 / 83 RETIRET1 m8 Mark data from m8 as evictable from T0,T1,T2 to RAM
0F 18 / 81 RETIRET0 m8 Mark data from m8 as evictable from T0 to T1,T2,RAM
0F 18 / 02 PREFETCHT1 m8 Move data from m8 closer to processor using T1 hint
0F 18 / 82 RETIRET1 m8 Mark data from m8 as evictable from T0,T1 to T2,RAM
0F 18 / 03 PREFETCHT1 m8 Move data from m8 closer to processor using T2 hint
0F 18 / 83 RETIRET1 m8 Mark data from m8 as evictable from T0,T1,T2 to RAM
Мне кажется, про это ответили чуть выше, про VLIW, itanium и вот это все.
К сожалению, замечаю тенденцию, когда людям надо бы что по-проще, в том числе в области программирования.
Пусть лучше где-то там (махнув рукой в сторону железа) будет сложно.
К сожалению, замечаю тенденцию, когда людям надо бы что по-проще, в том числе в области программирования.
Пусть лучше где-то там (махнув рукой в сторону железа) будет сложно.
Вопрос в том, насколько усложняется компилятор(а это еще ж баги) и насколько лучше он предсказывает, по сравнению с динамическим предсказанием.
Пока соотношение — не очень. Не взлетает.
Пока соотношение — не очень. Не взлетает.
Мм… а как на счет сравнения с Xeon Phi и его 72 ядрами? Да, там 14нм, но все же интересно…
Sign up to leave a comment.
Процессор-пионер Qualcomm Centriq 2400. Убийца Intel?