Вы читайте внимательнее, там есть во первых ссылочки, на твитты заверявшие 225 tf, а также есть внизу табличка где 2200 кН против 2090 кН у РД-181.
Так что читайте пожалуйста внимательнее то, на что ссылаетесь. Ну то есть да, вы кажется нашли опечатку в википедии, это конечно хорошо, но вы можете ее же цифры и проверить, благо для большинства из них указан источник.
Вы прекрасно проиллюстрировали мой довод, что Эльбрус сравнивали с чем-то совершенно не сопоставимым по задачам или целевым показателям.
Я в двигателях конечно ничего не понимаю, но кажется Вы перепутали РД-180 с чем-то еще. Он слишком отличается и от РД-181 и от Раптора чтобы их напрямую сравнивать (у РД-180 тяга выше в несколько раз, но тяга к массе намного хуже).
Касательно цифр - у РД-181 тяга 2090 кН, у Раптора в тестах 2200 кН.
Про давление в камере - опять же посмотрев на характеристики - скорее всего раптор сравнивают с рд-180 потому что у рд-180 оно выше чем у рд-181, чисто интересный показатель с точки зрения прочности материалов.
Буду признателен если Вы расширите мой кругозор и поясните где ошибка.
Эльбрус - сравнивают не по целевым показателям. Это как сравнивать производительность супер-компьютера с RTX3090 в игре Киберпанк, а потом заявить что раз СК проиграл RTX, то СК не нужен.
Дело в том что Эльбрус рекламируют как убийцу интела и процессор общего назначения еще с момента как его начали проектировать. Это автоматически делает любые прикладные задачи его целевыми задачами. И на практике выясняется что там он себя показывает не очень здорово.
На вопросы о каких-то более целевых задачах - ответов тоже не очень много звучит (полистайте эту тему, вопрос задавался многократно тут, а вот внятных ответов как не было, так и нет)
В этом докладе были некоторые цифры http://0x1.tv/20181012BC , но в целом - сильно сэкономили, потому что до альтернатива была в сверхдорогих решениях от IBM, и чтобы сползти с них, использовалось "импортозамещение".
Это смотрел, очень сильно удивлялся (в плохом смысле) качеству анализа. Если прям по пунктам:
Сами нагрузки достаточно смешные (я про 20 ТБ данных и 4 ТБ базы, как и 40 тысяч запросов в сутки)
Из цифр только "год обслуживания менйфрейма стоит как 130 серверов на Эльбрусах". Они не учитывают стоимость эксплуатации (электричество не бесплатное, адаптация кода под новую архитектуру не бесплатная и т.п.). Про это был слайд, но автор доклада его к сожалению пропустил.
Непонятно почему рассматривались только Эльбрусы, а не, например, сервера на x86 (притом даже брендовые). Как раз при таком редизайне системы напрашивается сравнение Эльбрус vs x86
Отсутствует какой либо анализ системы с точки зрения надежности данных. Но тут авторам benefit of a doubt дается и допустим их все устраивает. Но в рамках таких докладов интересно было бы услышать проводились ли сравнения касательно гарантий доставки сообщений, поведения системы в рамках нештатных ситуаций и т.п., потому что естественным образом IBMовский софт и аналоги обеспечивают немного разные гарантии для разных ситуаций и самое интересное в редизайне архитектуры приложения - как с этими несоответствиями поступили авторы. Точнее есть только про PostgreSQL и то что отказались от двухфазных транзакций, что намекает что консистентность данных стала в итоге хуже, но этому уделено слишком мало внимания.
p.s. собственно автор сказал что x86 лучше в рамках ответов на вопросы ("если взять современный процессор, то там 16 ядер на борту и 3 ГГц, естественно чудес не бывает"), то есть получится что цифрами не подтверждается, а мнением докладчика - опровергается.
Если вы знакомы с историей компиляторов, то знаете, что 80% производительности от LLVM/GCC для ограниченного набора архитектур может сделать единственный увлеченный энтузиаст за год-два.
Но дело в том, что в случаи с llc мы не видим хорошей работы даже в 80% случаев.
Более того, LLVM только в последние 3-4 года стал сравним с GCC, и это при том, что в LLVM вкладывают средства такие гиганты как Apple и Google.
А это уже немного подмена понятий начинается, к сожалению. Потому что компаний конечно много вкладывает деньги и силы, но каждая компания заинтересована в узком круге задач, который некорректно обобщать на C + оптимизации под x86, о которых сейчас речь.
Сотни людей делали научные карьеры на исследованиях в этом фреймворке.
Я вот затрудняюсь сказать что именно сотни, но десятки точно делали (опять же если мы выделяем общие оптимизаторы в бэкэнде). Вопрос только в другом - сколько из этих исследований реально были воплощены в жизнь (многие исследовательные работы так и остаются исследовательскими работами, к сожалению).
Команда же llc никогда даже рядом не стояла ни с LLVM, ни с GCC по вложенным человеко-годам.
Если сравнивать весь llc со всем llvm - не буду спорить, но речь идет о том чтобы выделить только оптимизатор под 1 архитектуру (e2k и x86 соответственно) и попытаться сравнить времязатраты на тот и другой в человекогодах.
На оптимизирующие компиляторы C для x86 было потрачено огромное количество ресурсов, чего нельзя сказать про Эльбрусы.
Не факт. LLVM относительно новый, с фокусом на множество языков и архитектур, 4сли смотреть на его развитие, то можно заметить что огдостаточно быстро достиг 90% скорости gcc (да, остальные 10% были трудными и заняли годы), в то же время llc делают лет 20 на практике (не тратя много сил на фронтэнд, он же там покупной), а если считать теоретические изыскания то лет 30. Притом это была команда full time разработчиков.
Чтобы скомпенсировать это неравенство, имеет смысл приложить максимум усилий разработчика теста для увеличения IPC путём подсказок компилятору и переписыванию некоторых кусочков кода вручную.
Только в реальной жизни разработчики крайне редко хотят таким заниматься (это будут буквально единицы людей). Так что для создания ситуации из реальной жизни ничего как раз компенсировать не нужно.
В области импортозащемления он вполне себе убийца интела
Беда в том, что его позиционировали как убийцу интела еще до того, как импортозамещение стало модным. А в той области, уж извините, и комдив на 800 мгц - убийца, так уж она сформирована.
Проблема только в том, что возможность очень теоретическая и потенциальная и не любой груз вообще влезет на кресла.
И продолжая аналогию - если река немного сезонно пересохла то с речным судном все по-прежнему будет плохо. А автомобиль в случае заборов на одной дороге достаточно легко найдёт альтернативный маршрут и все равно окажется быстрее.
Только фишка в том, что Эльбрус - это не процессор для корпоративных и индивидуальных потребителей.
Это расходится с заявлениями мцст, его изначально позиционировали как убийцу интела.
Эльбрус, в первую очередь нужен военным, чтобы ставить в умное оружие
Есть доказательства? А то в соседних темах жаловались что радстойкий на российских фабриках был сделан один раз и все. Тут ключевой вопрос будет что там с защитой от ЭМИ. Ну и в общем вопрос в каких установках у военных Эльбрус, который не sparc.
Плюс военные получают весь тот же набор проблем что и гражданские. А там возникнет вопрос, а не лучше ли взять решение от Элвиса.
Распаянная память свойство многих ноутбуков и на скорость это не так чтобы сильно влияет на производительность. Apple ее вообще на ту же подложку что и чип разместила, но не очень понятно как это влияет на производительность (тайминги памяти не публикуются же, а частоты вполне обыденные для LPDDR4X, ничего особенного в них нет). Плюс память - не является акселератором как таковая.
Поищите где используется Эльбрус-90Микро, на эту тему информации не очень много, но есть в том числе в видео с которых начался цикл статей (да и почти каждое видео с историей МЦСТ упоминает про них и их использование в вооруженных силах).
Можете перечислить VLIW-процессоры общего назначения, которые вы знаете? А потом сможете перечислить все живые VLIWы какие знаете? Собственно в этих перечислениях и будет ответ на ваш вопрос.
Не соглашусь. Ваша логическая ошибка в том что вы приравниваете наличие каких-то продаж к шансу на светлое будущие, полностью игнорируя техническую составляющую и то что даже у плохих товаров случаются продажи.
а лишь рассказали о том, что "вам кажется".
Можно цитату, это доказывающую?
На ошибку в вашей логике я указал как раз вам
И на это, можно, пожалуйста, цитату? Не помню чтобы вы указывали на какую-либо ошибку в логике.
Максимум 4 процессора в системе, как следствие ограничение на объёмы оперативной памяти, детские болезни ядра Linux - слабые диспетчеры задач, ввода/вывода, убогие ФС и менеджеры томов, отсутствие или зачаточное состояние асинхронного и прямого дискового io и т.п..
Смотрите, если мы говорим о timeline'е, то Merced вышел в 2001 году, через год вышел Itanium 2, но уже в 2003 году AMD представила x86-64 и Opteron'ы которые умели в 8-и процессорные системы и умели в много памяти. Таймлайн сам по себе был очень жесткий и не в пользу Итаниума.
Еще не стоит забывать что начало 2000-х как раз момент становления FAANG'а и им сопутствующих как IT компаний, которые изначально избрали подход в покупке commodity железа за дешево и делать ПО с учетом особенностей таких решений. Как раз эти моменты очень сильно перекроили рынок, потому что крупный Enterprise может и хотел себе привычное большое железо, но появилось много мелких игроков, которые умели использовать дешевое железо для достижения результата. И по объему продаж и прибыльности вскоре "много мелких" оказалось лучше чем "мало огромных".
А в какой момент, можно сказать, HP сдались и опустили руки? По косвенным признакам они еще в 2008 году платили интелу за разработку и выпуск новых моделей, то есть явно до 2008 года (включительно) считали что шансы есть.
В общем не знаю, кажется что это все таки технический провал в первую очередь, и связанный с тем что x86 оказался неплох и доступен (дешевое TCO), в то время как для специализированных процессоров практически не осталось места (сейчас те же банки постепенно уходят спокойно в облака на x86 со своих дорогих железок).
Я не слышал о PA-RISC ничего хорошего от людей, которые писали этот самый софт. Его ругали за странность архитектуры и то что это делало написание производительного кода крайне затруднительной.
Даже x86 можно было довести до сопоставимых цифр тюнингом ядра и правильным выбором файловой системы для БД.
Вот это кстати куда ближе к причине провала Itanium'а, PA-RISC'а и прочих. Зачем брать дорогое специализированное и очень закрытое железо (привязывая по сути себя к его производителю), когда есть дешевый и относительно открытый x86? Тем более не забывайте что Итаниум должен был выйти в 1998 году изначально, а вышел по факту в середине 2001.
Вы читайте внимательнее, там есть во первых ссылочки, на твитты заверявшие 225 tf, а также есть внизу табличка где 2200 кН против 2090 кН у РД-181.
Так что читайте пожалуйста внимательнее то, на что ссылаетесь. Ну то есть да, вы кажется нашли опечатку в википедии, это конечно хорошо, но вы можете ее же цифры и проверить, благо для большинства из них указан источник.
В каком месте?
Да, спасибо, иногда задумываюсь и пишу некорректно. Жаль только пост уже не поправить.
Я в двигателях конечно ничего не понимаю, но кажется Вы перепутали РД-180 с чем-то еще. Он слишком отличается и от РД-181 и от Раптора чтобы их напрямую сравнивать (у РД-180 тяга выше в несколько раз, но тяга к массе намного хуже).
Касательно цифр - у РД-181 тяга 2090 кН, у Раптора в тестах 2200 кН.
Про давление в камере - опять же посмотрев на характеристики - скорее всего раптор сравнивают с рд-180 потому что у рд-180 оно выше чем у рд-181, чисто интересный показатель с точки зрения прочности материалов.
Буду признателен если Вы расширите мой кругозор и поясните где ошибка.
Дело в том что Эльбрус рекламируют как убийцу интела и процессор общего назначения еще с момента как его начали проектировать. Это автоматически делает любые прикладные задачи его целевыми задачами. И на практике выясняется что там он себя показывает не очень здорово.
На вопросы о каких-то более целевых задачах - ответов тоже не очень много звучит (полистайте эту тему, вопрос задавался многократно тут, а вот внятных ответов как не было, так и нет)
Это смотрел, очень сильно удивлялся (в плохом смысле) качеству анализа. Если прям по пунктам:
Сами нагрузки достаточно смешные (я про 20 ТБ данных и 4 ТБ базы, как и 40 тысяч запросов в сутки)
Из цифр только "год обслуживания менйфрейма стоит как 130 серверов на Эльбрусах". Они не учитывают стоимость эксплуатации (электричество не бесплатное, адаптация кода под новую архитектуру не бесплатная и т.п.). Про это был слайд, но автор доклада его к сожалению пропустил.
Непонятно почему рассматривались только Эльбрусы, а не, например, сервера на x86 (притом даже брендовые). Как раз при таком редизайне системы напрашивается сравнение Эльбрус vs x86
Отсутствует какой либо анализ системы с точки зрения надежности данных. Но тут авторам benefit of a doubt дается и допустим их все устраивает. Но в рамках таких докладов интересно было бы услышать проводились ли сравнения касательно гарантий доставки сообщений, поведения системы в рамках нештатных ситуаций и т.п., потому что естественным образом IBMовский софт и аналоги обеспечивают немного разные гарантии для разных ситуаций и самое интересное в редизайне архитектуры приложения - как с этими несоответствиями поступили авторы. Точнее есть только про PostgreSQL и то что отказались от двухфазных транзакций, что намекает что консистентность данных стала в итоге хуже, но этому уделено слишком мало внимания.
p.s. собственно автор сказал что x86 лучше в рамках ответов на вопросы ("если взять современный процессор, то там 16 ядер на борту и 3 ГГц, естественно чудес не бывает"), то есть получится что цифрами не подтверждается, а мнением докладчика - опровергается.
Но дело в том, что в случаи с llc мы не видим хорошей работы даже в 80% случаев.
А это уже немного подмена понятий начинается, к сожалению. Потому что компаний конечно много вкладывает деньги и силы, но каждая компания заинтересована в узком круге задач, который некорректно обобщать на C + оптимизации под x86, о которых сейчас речь.
Я вот затрудняюсь сказать что именно сотни, но десятки точно делали (опять же если мы выделяем общие оптимизаторы в бэкэнде). Вопрос только в другом - сколько из этих исследований реально были воплощены в жизнь (многие исследовательные работы так и остаются исследовательскими работами, к сожалению).
Если сравнивать весь llc со всем llvm - не буду спорить, но речь идет о том чтобы выделить только оптимизатор под 1 архитектуру (e2k и x86 соответственно) и попытаться сравнить времязатраты на тот и другой в человекогодах.
Не факт. LLVM относительно новый, с фокусом на множество языков и архитектур, 4сли смотреть на его развитие, то можно заметить что огдостаточно быстро достиг 90% скорости gcc (да, остальные 10% были трудными и заняли годы), в то же время llc делают лет 20 на практике (не тратя много сил на фронтэнд, он же там покупной), а если считать теоретические изыскания то лет 30. Притом это была команда full time разработчиков.
Только в реальной жизни разработчики крайне редко хотят таким заниматься (это будут буквально единицы людей). Так что для создания ситуации из реальной жизни ничего как раз компенсировать не нужно.
Есть статистика, показывающая процент таких проектов?
Беда в том, что его позиционировали как убийцу интела еще до того, как импортозамещение стало модным. А в той области, уж извините, и комдив на 800 мгц - убийца, так уж она сформирована.
Проблема только в том, что возможность очень теоретическая и потенциальная и не любой груз вообще влезет на кресла.
И продолжая аналогию - если река немного сезонно пересохла то с речным судном все по-прежнему будет плохо. А автомобиль в случае заборов на одной дороге достаточно легко найдёт альтернативный маршрут и все равно окажется быстрее.
Тем печальнее положение дел.
Это расходится с заявлениями мцст, его изначально позиционировали как убийцу интела.
Есть доказательства? А то в соседних темах жаловались что радстойкий на российских фабриках был сделан один раз и все. Тут ключевой вопрос будет что там с защитой от ЭМИ. Ну и в общем вопрос в каких установках у военных Эльбрус, который не sparc.
Плюс военные получают весь тот же набор проблем что и гражданские. А там возникнет вопрос, а не лучше ли взять решение от Элвиса.
Распаянная память свойство многих ноутбуков и на скорость это не так чтобы сильно влияет на производительность. Apple ее вообще на ту же подложку что и чип разместила, но не очень понятно как это влияет на производительность (тайминги памяти не публикуются же, а частоты вполне обыденные для LPDDR4X, ничего особенного в них нет). Плюс память - не является акселератором как таковая.
Вопрос в том на каких Эльбрусах. А то 90микро - это спарк.
Поищите где используется Эльбрус-90Микро, на эту тему информации не очень много, но есть в том числе в видео с которых начался цикл статей (да и почти каждое видео с историей МЦСТ упоминает про них и их использование в вооруженных силах).
Это миф кстати. Специализированных ускорителей там не так много и их наличие не объясняет почему он быстрее, например, в компиляции софта.
Даже в таких зонах будет напрашиваться сравнение с различными ускорителями и другими системами, рассчитанными на эти задачи.
Можете перечислить VLIW-процессоры общего назначения, которые вы знаете? А потом сможете перечислить все живые VLIWы какие знаете? Собственно в этих перечислениях и будет ответ на ваш вопрос.
Не соглашусь. Ваша логическая ошибка в том что вы приравниваете наличие каких-то продаж к шансу на светлое будущие, полностью игнорируя техническую составляющую и то что даже у плохих товаров случаются продажи.
Можно цитату, это доказывающую?
И на это, можно, пожалуйста, цитату? Не помню чтобы вы указывали на какую-либо ошибку в логике.
Смотрите, если мы говорим о timeline'е, то Merced вышел в 2001 году, через год вышел Itanium 2, но уже в 2003 году AMD представила x86-64 и Opteron'ы которые умели в 8-и процессорные системы и умели в много памяти. Таймлайн сам по себе был очень жесткий и не в пользу Итаниума.
Еще не стоит забывать что начало 2000-х как раз момент становления FAANG'а и им сопутствующих как IT компаний, которые изначально избрали подход в покупке commodity железа за дешево и делать ПО с учетом особенностей таких решений. Как раз эти моменты очень сильно перекроили рынок, потому что крупный Enterprise может и хотел себе привычное большое железо, но появилось много мелких игроков, которые умели использовать дешевое железо для достижения результата. И по объему продаж и прибыльности вскоре "много мелких" оказалось лучше чем "мало огромных".
А в какой момент, можно сказать, HP сдались и опустили руки? По косвенным признакам они еще в 2008 году платили интелу за разработку и выпуск новых моделей, то есть явно до 2008 года (включительно) считали что шансы есть.
В общем не знаю, кажется что это все таки технический провал в первую очередь, и связанный с тем что x86 оказался неплох и доступен (дешевое TCO), в то время как для специализированных процессоров практически не осталось места (сейчас те же банки постепенно уходят спокойно в облака на x86 со своих дорогих железок).
Я не слышал о PA-RISC ничего хорошего от людей, которые писали этот самый софт. Его ругали за странность архитектуры и то что это делало написание производительного кода крайне затруднительной.
Вот это кстати куда ближе к причине провала Itanium'а, PA-RISC'а и прочих. Зачем брать дорогое специализированное и очень закрытое железо (привязывая по сути себя к его производителю), когда есть дешевый и относительно открытый x86? Тем более не забывайте что Итаниум должен был выйти в 1998 году изначально, а вышел по факту в середине 2001.