Комментарии 59
Какой приятный литературный язык…
По поводу «нагрузки на процессор» в сравнении Graviton и Intel — а какой процент задач, из всех крутящихся в AWS, плохо масштабируется и требует именно мощных CPU?
Я думаю, достаточно маленький, чтобы частичный отказ от Intel был ощутимым для обеих сторон.
По поводу «нагрузки на процессор» в сравнении Graviton и Intel — а какой процент задач, из всех крутящихся в AWS, плохо масштабируется и требует именно мощных CPU?
Я думаю, достаточно маленький, чтобы частичный отказ от Intel был ощутимым для обеих сторон.
Тут какое дело, можно сидеть на интелах и получать загрузку условной страницы за 1 секунду, а можно на arm и довольствоваться в лучшем случае 2-3 секундами. А если брать высокопроизводительные инстансы типа c4 и c5 с частотой под 3ггц то там еще больше разница.
Ради интереса пробовал на 3b+ малине проект. Разница в 3-5 раз по сравнению с сервером и еще больше по сравнению с i7.
Ради интереса пробовал на 3b+ малине проект. Разница в 3-5 раз по сравнению с сервером и еще больше по сравнению с i7.
Какая-то странная математика у вас. Вы тогда и учитывайте, что загрузка одной страницы на АРМ будет вам (владельцу приложения) стоить условно доллар, а на Интеле — пять.
Смысл моего комментария был в том, что немалая часть потребителей AWS это простые е-коммерсы и иже с ними, которые переход на АРМ не заметят. Только по цене.
А тот, у кого страница грузится секунду (имеется в виду нагрузка сервера) может и на Интел остаться.
Оптимизация расходов (для Амазон).
Смысл моего комментария был в том, что немалая часть потребителей AWS это простые е-коммерсы и иже с ними, которые переход на АРМ не заметят. Только по цене.
А тот, у кого страница грузится секунду (имеется в виду нагрузка сервера) может и на Интел остаться.
Оптимизация расходов (для Амазон).
В относительных значений так и выходит, но абсолютных разницы особой нет: что $5 в месяц, что $25.
Может быть для простых сайтов и подойдет, я не тестировал конкретно a1. Уже средние сайты требуют нормального cpu.
Для понимания масштаба экономии: как известно, amd возвращается на рынок предлагая серверные эпики по цене до двух раз меньше чем у конкурента. Для ec2 появляются новые предложение c их процессорами… на 10% дешевле.
Так что я бы особо не надеялся на какое-то удешевление.
Может быть для простых сайтов и подойдет, я не тестировал конкретно a1. Уже средние сайты требуют нормального cpu.
Для понимания масштаба экономии: как известно, amd возвращается на рынок предлагая серверные эпики по цене до двух раз меньше чем у конкурента. Для ec2 появляются новые предложение c их процессорами… на 10% дешевле.
Так что я бы особо не надеялся на какое-то удешевление.
Вы тогда и учитывайте, что загрузка одной страницы на АРМ будет вам (владельцу приложения) стоить условно доллар, а на Интеле — пять.
Там разница 50%. Что-то я сомневаюсь, что там будет какая-то выгода для обычных клиентов. Если у вас есть возможности и силы протестировать различные конфигурации для каждой роли, и выбрать оптимальное, может вы и получите какую-то выгоду.
На малине кроме процессора ещё схд на micro-sd, что явно не добавляет производительности, а возможно, является узким местом. Правильно сравнивать северные решения на разных CPU, когда периферия приблизительно одного уровня.
Помимо этого, ядра малинки далеко не самые быстрые и по старому техпроцессу сделаны.
Не говоря про кэши и прочие характеристики, которые в малинке не так важны, как важно её удобство для разработки.
Не говоря про кэши и прочие характеристики, которые в малинке не так важны, как важно её удобство для разработки.
Я для этого прикупил ssd и тупняки исчезли.
Вчера посмотрел arm в aws. Ради интереса выбрал максимальный вариант с 16 ядрами. Могу сказать что по ощущениям быстрее малины, но далеко не х86.
Вчера посмотрел arm в aws. Ради интереса выбрал максимальный вариант с 16 ядрами. Могу сказать что по ощущениям быстрее малины, но далеко не х86.
Тут какое дело, можно сидеть на интелах и получать загрузку условной страницы за 1 секунду, а можно на arm и довольствоваться в лучшем случае 2-3 секундами.
Думаю на фоне тормозов js и многомегабайтных страничек время генерации информации на бакенде в большинстве случаев ничтожно.
загрузку условной страницы за 1 секунду, а можно на arm и довольствоваться в лучшем случае 2-3 секундамиПри равном количестве клиентов на ядро, я полагаю?
nginx с node масштабируются хорошо.
Бизнес-приложения — вряд ли, если кто-то этим очень внимательно не озаботился.
Та же 1С умрёт на 8 ядрах по 2Ghz, но будет хорошо жить на 2-х ядрах по 3.4 Ghz.
Думаю, в AWS крутится немало такого же требовательного к частоте одного ядра корпоративного софта.
Гравитоны для Lightsail пойдут скорее всего.
Бизнес-приложения — вряд ли, если кто-то этим очень внимательно не озаботился.
Та же 1С умрёт на 8 ядрах по 2Ghz, но будет хорошо жить на 2-х ядрах по 3.4 Ghz.
Думаю, в AWS крутится немало такого же требовательного к частоте одного ядра корпоративного софта.
Гравитоны для Lightsail пойдут скорее всего.
кроме попугаев скорости ядра есть еще такой параметр как цена.
если 16 ядерный арм будет работать как 5 ядерный интел, а стоит будет в несколько раз дешевле. то рынок скажет свое слово.
х86 архитектура перегружена дополнениями и расширениями, а также поддержкой всех наследованных команд, а это все выражается в площади кристалла и цене :(
арм стартует с более более высокого старта, не таща воз старья за собой.
и пока еще сильно новичок на «стероидном» рынке процов.
посмотрим.
если 16 ядерный арм будет работать как 5 ядерный интел, а стоит будет в несколько раз дешевле. то рынок скажет свое слово.
х86 архитектура перегружена дополнениями и расширениями, а также поддержкой всех наследованных команд, а это все выражается в площади кристалла и цене :(
арм стартует с более более высокого старта, не таща воз старья за собой.
и пока еще сильно новичок на «стероидном» рынке процов.
посмотрим.
Ох, со времён п4/к7 эту песню слышу. Ничего поддержка команд не стоит, это по сути часть прошивки — «словаря» для декодера команд, который их во внутренние микрооперации переводит.
В общем, нужно быстрые ядра — делаются быстрые ядра. Нужно много слабых — делается много слабых. Архитектура не так много роли играет, как кажется, и каких-либо чудес, за исключением случаев, когда задача грамотно использует особенности архитектуры, не случается. Добавили к АРМ всю «ненужную» обвеску х86 — получили похожую производительность с похожими проблемами, см современные процессоры телефонов/планшетов что х86, что арм — по факту, на вкус и цвет.
В общем, нужно быстрые ядра — делаются быстрые ядра. Нужно много слабых — делается много слабых. Архитектура не так много роли играет, как кажется, и каких-либо чудес, за исключением случаев, когда задача грамотно использует особенности архитектуры, не случается. Добавили к АРМ всю «ненужную» обвеску х86 — получили похожую производительность с похожими проблемами, см современные процессоры телефонов/планшетов что х86, что арм — по факту, на вкус и цвет.
А вы смотрели эти кристаллы в разрезе? Там подавляющая часть занята кэшами всех уровней.
Кэшами и разными внешними контроллерами периферией, которая уже давно тоже в процессор переехала. А часто еще и GPU.
Если это оттуда вытряхнуть, получится вот так примерно:
Прототип от AMD — в каждом из 8 маленьких квадратиков по 8 штук мощных современных x86 ядер (включая все кэши L1-L2-L3). А в центральном большом — контроллеры(памяти, PCI-E) и периферия.
Если это оттуда вытряхнуть, получится вот так примерно:
Фото
Прототип от AMD — в каждом из 8 маленьких квадратиков по 8 штук мощных современных x86 ядер (включая все кэши L1-L2-L3). А в центральном большом — контроллеры(памяти, PCI-E) и периферия.
В медиа любят набрасывать
Упаковал весь смысл в 3 слова.
Есть ли смысл Интелу выкатывать 10нм если параллельно и даже с большим успехом продвигается разработка 7нм, может перескочить?
На 10 нм они хотят получить плотность выше, чем на 7 нм. А чем выше плотность, тем больше поместится транзисторов на пластину кремния. А для настольного сегмента, количество транзисторов скорее всего важнее некоторых преимуществ меньшего техпроцесса — например сниженного энергопотребления. Плюс производственные линии с глубоким ультрофиолетом это очень дорого и, поговаривают, их не так легко сделать в нужном количестве. А закон Мура это не о техпроцессе, а о цене транзистора.
закон Мура о количестве транзисторов
Не хотят. x2 плотности транзисторов на 7нм это 2 раза больше от плановых показателей 10нм, которые в свою очередь должны были быть х2.7 от 14 нм.
Хотя эти «иксы» у Итела сильно маркетинговые. Если не голую теорию взять, а реальные чипы выходившие в продажу, то показатели будут намного скромнее. Между 45нм и 14нм нет 12 кратного увеличения плотности транзисторов на мм2 чипа как должно было бы быть, если верить красивым графикам, нарисованным маркетологами Intel (45нм==>32нм==>22нм==>14нм: 2.3*2.1*2.5 = 12.075x)
Например:
Core 2 Duo (ядро wolfdale): 45 нм, 411 млн транзисторов, 107 mm² ==> 3.84М / mm²
или
8-core Xeon Nehalem-EX 45 нм, 2300 млн, 684 mm² ==> 3.36 М / mm²
и современный
Core i7 (ядро Skylake K) 14 нм, 1750 млн, 122 mm² ==> 14.34 М / mm²
Хорошо если 5 кратное увеличение плотности размещения транзисторов с трудом натянется, а вовсе не 12 кратное.
Маркетинговые попугаи они такие маркетинговые…
Вот примерно как более-менее реальный график (что характерно от маркетологов той же самой компании) должен выглядеть:
Сокращения площади одного и того же чипа с 100 мм2 до 17.7 мм2. Или 100/17.7 = 5.6 раз увеличения плотности упаковки элементов. Никаких х12 и в помине нет.
Хотя эти «иксы» у Итела сильно маркетинговые. Если не голую теорию взять, а реальные чипы выходившие в продажу, то показатели будут намного скромнее. Между 45нм и 14нм нет 12 кратного увеличения плотности транзисторов на мм2 чипа как должно было бы быть, если верить красивым графикам, нарисованным маркетологами Intel (45нм==>32нм==>22нм==>14нм: 2.3*2.1*2.5 = 12.075x)
Например:
Core 2 Duo (ядро wolfdale): 45 нм, 411 млн транзисторов, 107 mm² ==> 3.84М / mm²
или
8-core Xeon Nehalem-EX 45 нм, 2300 млн, 684 mm² ==> 3.36 М / mm²
и современный
Core i7 (ядро Skylake K) 14 нм, 1750 млн, 122 mm² ==> 14.34 М / mm²
Хорошо если 5 кратное увеличение плотности размещения транзисторов с трудом натянется, а вовсе не 12 кратное.
Маркетинговые попугаи они такие маркетинговые…
Вот примерно как более-менее реальный график (что характерно от маркетологов той же самой компании) должен выглядеть:
Сокращения площади одного и того же чипа с 100 мм2 до 17.7 мм2. Или 100/17.7 = 5.6 раз увеличения плотности упаковки элементов. Никаких х12 и в помине нет.
В статье все-таки немного упущено, что AWS начало использование AMD EPYC в новом поколении инстансов (M5, R5).
в угоду этой самой энергоэффективности ARM-чипам приходится отказываться «грубой силы», которой обладают «старшие братья» от той же Intel или AMD
Что? Я может что-то не понимаю?
ARM — это RISC. Он рациональнее делает задачи, разбивая их на примитивы, потому ему и не надо энергии так много, как процессорам на CISC (Intel/AMD), которые километровые инструкции выполняют.
«Грубая сила» — какой-то странный показатель для процессора. При абсолютно равных физических параметрах, ARM будет работать:
- быстрее
- энергоэффективнее.
НЛО прилетело и опубликовало эту надпись здесь
Подробнее?
ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D0%BA%D0%BE%D0%B4
Исходные инструкции транслируются процессором в микрокод, и микрокод уже оптимизируется и выполняется. Здесь же можно вспомнить и о том, что у современных х86 процессоров уже давно не 8 регистров общего назначения, а около 150 (меняется от поколения к поколению), и сложные техники register renaming для эффективного распихивания данных из восьми «виртуальных» регистров, которыми оперирует исходная программа, в эти 150 физических.
Исходные инструкции транслируются процессором в микрокод, и микрокод уже оптимизируется и выполняется. Здесь же можно вспомнить и о том, что у современных х86 процессоров уже давно не 8 регистров общего назначения, а около 150 (меняется от поколения к поколению), и сложные техники register renaming для эффективного распихивания данных из восьми «виртуальных» регистров, которыми оперирует исходная программа, в эти 150 физических.
Я знаю, что такое микрокод.
Речь идет про другое:
"x86 процессоры тоже уже давно RISC, выполняющие только одну программу: эмулирование x86."
Этот момент никак не покрыт в этой статье. Я даже не понял, что человек сказать хотел. Вы поняли? Можете сформулировать это по другому? Увязать x86, регистры и RISC?
Речь идет про другое:
"x86 процессоры тоже уже давно RISC, выполняющие только одну программу: эмулирование x86."
Этот момент никак не покрыт в этой статье. Я даже не понял, что человек сказать хотел. Вы поняли? Можете сформулировать это по другому? Увязать x86, регистры и RISC?
Микрокодовая архитектура это и есть RISC. Трансляция ISA x86 в микрокод — эмуляция CISC-архитектуры х86 на RISC-железе. Я так понимаю, по крайней мере, если вы так не считаете — давайте обсуждать, мне интересно разобраться.
Давайте опустимся до деталей.
Есть управляющие регистры и есть теневые регистры. К последним у вас нет доступа программно. Задача микрокода разложить сложную операцию на атомарные. Их может быть много — и тогда используются теневые регистры. Является ли это эмуляцией? Вот не согласен. Это реальные физические регистры, просто они недоступны извне.
Теперь посмотрим на RISC — в современных версиях, например в IV-й, конечно же есть сложные операции, которые надо разложить (и микрокод тут пришел на помощь). То есть когда надо RISC-вые процессоры используют микрокод, а когда можно обойтись без него — не используют.
Теперь CISC. В распоряжении у CISC-процессоров те же регистры. И тот же микрокод. И CISC использует его тоже. Только более широко — все же он тем и отличается от RISC, что у него добавляются сложные инструкции, которые надо раскладывать на примитивы.
Но RISC — это не микрокод. Хотя бы потому, что RISC — это просто список инструкций. Очень абстрактная вещь, которую не потрогать. Другими словами, RISC — это «умеренный подход».
А микрокод — это программа. А еще потому, что есть микрокод без RISC, а есть RISC без микрокода.
Есть управляющие регистры и есть теневые регистры. К последним у вас нет доступа программно. Задача микрокода разложить сложную операцию на атомарные. Их может быть много — и тогда используются теневые регистры. Является ли это эмуляцией? Вот не согласен. Это реальные физические регистры, просто они недоступны извне.
Теперь посмотрим на RISC — в современных версиях, например в IV-й, конечно же есть сложные операции, которые надо разложить (и микрокод тут пришел на помощь). То есть когда надо RISC-вые процессоры используют микрокод, а когда можно обойтись без него — не используют.
Теперь CISC. В распоряжении у CISC-процессоров те же регистры. И тот же микрокод. И CISC использует его тоже. Только более широко — все же он тем и отличается от RISC, что у него добавляются сложные инструкции, которые надо раскладывать на примитивы.
Но RISC — это не микрокод. Хотя бы потому, что RISC — это просто список инструкций. Очень абстрактная вещь, которую не потрогать. Другими словами, RISC — это «умеренный подход».
А микрокод — это программа. А еще потому, что есть микрокод без RISC, а есть RISC без микрокода.
Люди, которые минусуют в карму — если вы не объясняете, за что вы это делаете, очень скоро тут останется одно быдло, а нормальные люди уйдут. Совершенно очевидно, что я один тут разработчик из Intel, а вокруг меня огромная толпа, напичканная стереотипами, готовая стереть любого целой сворой только лишь за альтернативное мнение.
Вы тут не один разработчик из Интел, это очевидно)
Это не меняет сути. Лучше не писать ничего. Меня вон за вопрос «Подробнее?» даже заминусовали (и, какая внезапность, ответить по сути ему было нечего).
Тут просто ад какой-то творится. Еще пару неудачных вопросов и я вообще не смогу тут писать. Так что, коллега, извините, не могу тратить свои посты на общение с вами при всем моем желании пообщаться.
Тут просто ад какой-то творится. Еще пару неудачных вопросов и я вообще не смогу тут писать. Так что, коллега, извините, не могу тратить свои посты на общение с вами при всем моем желании пообщаться.
ARM — это RISC. Он рациональнее делает задачи, разбивая их на примитивыВ результате получается, что вместо одной инструкции, условно перемножающей два произвольных операнда, вам потребуется выполнить две инструкции для загрузки определённых регистров, затем выполнить инструкцию умножения, а потом по вкусу добить всё инструкциями для раскладывания результатов в нужные места.
Верно. С той лишь разницей, что у CISC дополнительные инструкции — это не тоже самое, что вы привели в пример «условно перемножающей два произвольных операнда». Там очень сложные коплексные инструкции, которые тоже надо разбивать. Только итерация остается одна — а это значит, что нагрузка ложится на работу микрокода, который скрывает реализацию «под капотом».
Нет, вы неправильно понимаете суть различий между RISC и CISC. Они в основном отличаются не «дополнительными инструкциями» (хотя конечно и этим тоже), а вариативностью операндов. То есть грубо говоря ARM умеет умножать только два регистра из ограниченного набора, а x86 умножает между собой условно говоря любые регистры, константы, память с косвенной адресацией, и так далее. В результате RISC-код получается раздутым быссмысленными инструкциями предзагрузки регистров, а RISC-процессор для такого кода — получается ну, скажем так, простым в исполнении.
вы верно путаете с VLIW ??
Суть ещё в том, что декодер инструкций хорошо знает особенности семейства, на котором выполняется, за счёт чего разбивает инструкции более эффективно (и, например, с учётом предсказателя условных переходов). Цена этому — чуть большее энегропотребление декодера, но тем самым достигается бОльшая загрузка собственно исполнительных блоков и в конечном итоге энергоэффективность может быть даже выше — см. атомы первых поколений и более современные.
и новый способ литографии в глубоком ультрафиолете (EUV).Ага, «новую» технологию планировали выкатить совсем недавно в 2007 году. Новая прям как первый айфон, процессоры Core 2 Duo и премьер Путин.
Дык не для всех задач CPU нужен — если там раз в день получаются результаты и считаются (пока писал коммент понял, что тут вообще проще лямбдами все сделать)
Дык не для всех задач CPU нужен
Да, не зря в старых
Забавно, в статье говориться про то что арм дешевле, (я так понял в эксплуатации) но на конечную стоимость это не очень повлияло — там выходит даже дороже чем «эквивалент» от x86.
a1.large дороже чем t3.medium при одинаковых числе ядер и памяти. Непонятно, почему он позиционируется как дешевый.
У t3 есть burst по CPU или если его выключить, то надо платить. Так что a1 все равно дешевле будет.
Уже есть готовые бенчмарки и сравнение с амд и интелом от того же амазон. Если коротко — на данный момент нет профита и потенциальные возможные проблемы с софтом под арм.
в зависимости от задач 16 ядер Graviton дают производительность на уровне всего 5 интеловских ядер XeonЭто как? «Значение бывает разным и строго равно пяти»?
Есть же готовый OpenPower 9, который примерно в 2 раза дешевле Intel теми же характеристиками.
Есть готовый ARM Cavium ThunderX2.
Но Amazon сначала гордо идет своей дорогой, и только потом присоединяется к сообществу.
Есть готовый ARM Cavium ThunderX2.
Но Amazon сначала гордо идет своей дорогой, и только потом присоединяется к сообществу.
Да, если уж отказываться (или использовать как альтернативу) от архитектуры х86, то выбор большой и необходимости изобретать собственный велосипед нет.
Просто ИМХО такие мегакомпании как Амазон уже чисто рефлекторно пытаются все «грести под себя», даже особо не задумываясь — а надо ли это? а эффективно ли это делать самостоятельно?
Просто ИМХО такие мегакомпании как Амазон уже чисто рефлекторно пытаются все «грести под себя», даже особо не задумываясь — а надо ли это? а эффективно ли это делать самостоятельно?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что происходит у Intel и почему Amazon не переведет AWS целиком на свои чипы вопреки громким заголовкам