A1170 работал с повышенным напряжением. И поэтому там было 2.0 GHz.
Какие именно напряжения у A1170, у Байкала-М1 и у Эльбруса-8СВ? Пожалуйста со ссылочками на источники.
Но даже так - это никоим образом не опровергает довод. Есть пример процессора, который в рамках схожего TDP (32 Вт у А1170) работал на частотах порядка 2 ГГц. Есть примеры мобильных процессоров на А57, работавших на 1.7-1.9 ГГц. Ваше заявление про "1.5 это предел" - на проходит проверку на практике.
Это же касается A75 и Эльбрус-16С на 16 нм. На схожих напряжениях работы получается примерно одинаковые частоты у них.
Точно такой же вопрос - какие напряжения у 16С (одно или несколько, не знаю как уж там по архитектуре). Давайте Вы приведете источники, а потом посмотрим.
Так ядро A75 у Qualcomm работало до 3.0 GHz, но Mediatek клепает свои массовые процессоры Helio P65/G70/G80/G85 на ядрах A75 на 2.0 GHz, как и Байкал-S. Значит это некий оптимальный режим для нормального (низкого) потребления этого ядра на техпроцессах 12-16 нм.
Строго говоря в разгноворе выше не имеет значения что и почему делает mediatek.
Но в целом намекну - посмотрите на TDP топового снапдрагона на A75 и на TDP топового медиатека на A75. В этом и будет ответ.
Нет. Рассматривали производительность всего процессора на всех потоках для fp нагрузок. И там никаких 3.5 ГГц не будет у Epyc, а будет близко к базовой частоте, или чуть выше.
Звучит так, словно вы пытаетесь сейчас подобрать такие данные, чтобы получить нужный вам вывод (потому что абсолютно игнорируете все остальные доводы).
Для микроархитектурной скорости (и прежде чем заявлять что-то про частоты) стоит посмотреть на 1-поточную производительность на максимально доступных частотах - то есть на Ryzen 5950X с его 5.05 ГГц. Давайте тогда так возьмем, чтобы честно было.
Есть более полный источник с тестами SCR7 на Spec 2017:
Я вам привел ссылку на презентацию и Coremark, по которому SCR7 лучше чем A57 (пусть и не очень значительно). Так и что дальше?
что у A57 производительность сильно выше этого уровня SCR7.
Мне кажется, это стоит подкрепить цифрами в SpecINT 2017 по A53 и A57, иначе заявление спорное (синтетические бенчмарки тем и плохи, что показывают местами разный результат).
Не видел такого сравнения. Я в тех, которые видел, получается примерно равенство с A73.
Теперь видели. А по чистой FP производительности получаются результаты выше чем у практически любого существующего официального ARM-ядра.
Эти RISC-V тестировали только на симуляторах на отдельных узких бенчмарках. На реальном железе A57 вероятно будет быстрее.
Почему вероятно? Какой-то очень неочевидный вывод. Если почитаете статью про SonicBOOM - там симулировали процессор полность., а не отдельные блоки, также как для моделировали показатели для частоты 3.2 ГГц (раздел 7 соответствующей статьи). Эти отдельные узкие бенчмарки это CoreMark и SpecInt 2006 и 2017 Rate и получали показатели лучше чем Cortex-A73 (а в отдельных бенчмарках лучше чем Skylake).
Извините, но не вижу никаких обоснований тому почему бы в реальном железе это ядро показывало бы худший результат на МГц чем при моделировании.
Но в Spec CPU2017 FP Эльбрусы показывают высокий результат - в 2 раза выше, чем A57, а в Spec CPU2017 INT - тоже на 30% выше, чем A57.
Ну это полезный показатель, если вы работаете в SpecFP.
В остальных случаях - полезнее смотреть в целом на различные тесты, в том числе в реальных приложениях. Например посмотрите по приведенной ссылке на результаты в Блендере, где А57 показал почти такой же результат как Э-8СВ (при разнице в SpecFP в 2.5 раза, а блендер был в основе одного из под-тестов). Посмотрите на linpack (который не совсем бенчмарк в общем-то) и увидите что 2.5 раза в нем превращаются в 1.5 раза в линпаке. Посмотрите на более интересные бенчмарки в софте что будут использовать люди - то есть на интерпретируемые языки (веб-сервер), javascript (браузер) и прочее - там байкал превосходит эльбрус в 2 с лишним раза.
Опять выглядит так, что вы выбрали одну конкретную метрику и пытаетесь ее использовать как единственно верную, но реальная жизнь она сложнее чем несколько бенчмарков.
после любого вылета программы запускать суточный тест памяти?
Если прям есть уверенность в безбажности софта - то не такой и плохой вариант. Так у подсистемы памяти характерная проблема в том что софт вылетает случайны и случайным образом и чаще всего всегда чуть по-разному (включая выдачу некорректных результатов).
вот буквально этим летом столкнулся с ошибками на домашнем компьютере, определение сбойного модуля, потом тестирование после замены — на это ушло в сумме не меньше 2 дней.
Да, это не очень удобно и не очень приятно, но я для себя не вижу проблем потратить два дня раз в несколько лет (я за несколько десятков лет владения ПК и ноутами помню ровно три случая неожиданных проблем с памятью (один раз было неприятно, на рабочем ноуте, но довольно очевидно - бит-флипы приводили к изменению текста в том числе в dmesg :), но так как это был ноут с распаяной памятью я так никогда и не узнал это память или что-то еще было виновато), а один раз проблемы были ожидаемы (умерший БП с искрами и дымом, который повредил вообще почти все, включая память, процессор и мать и половину жестких дисков).
В принципе еще лайф-хак - это махнуть память с какой-нибудь соседней системой, если возникли подозрения на проблемы. Иногда бывает проще чем гонять мем-тест.
Серверный EPYC 7763 имеет те же 2450 MHz базовой частоты
Вы делаете ту же ошибку что и другие люди, оперирующие базовой частотой - считаете что процессор всегда работает только на ней и никак иначе. А это в корне не верно (поищите в прошлых темах тред про это, tldr - надо смотреть на частотную формулу и что конкретное приложение утилизирует и в каком объеме). Строго говоря в таком контексте Ваш рассчет 100% неверный, потому что для 1 ядра у Epyc'ов boost гарантирован и вы получите там свои 3.5 ГГц (кстати непонятно почему вы не взяли 7713, у которого буст до 3.675 ГГц).
Опустим пока то, что у МЦСТ планы с реальностью не всегда соотносились и говорить о том что раз в роадмапе стоит для 6нм процессора цель в 2.5 ГГц, то ее обязательно достигнут - это немного преждевременно.
Ну и вам повторяли уже несколько раз - то что делаете вы - это в принципе некорректно, но вы продолжаете...
Компания ARM разрабатывает ядра более 20 лет. И они в итоге сделали Cortex-A57 для Байкала. Почему же они такие слабаки? У них тоже слабые инженеры?
ARM разрабатывает мобильные ядра более 20 лет. Строго говоря в серверный сегмент они начали смотреть только последние пару лет (а A57, который кстати делали не для байкала, а для телефонов, вообще ядро 2014 года). Те же A57 на 1.5-2 ГГц стояли в телефонах в 2014-2015 годах и прекрасно себя показывали в рамках теплопакета в 9-12 Вт (надо по процессорам смотреть, но это типичные значения для флагманов). Притом на 28-20 нм техпроцессах, еще и вкупе с видеоядром. Так что совсем непонятно к чему вопрос.
A75 - это очень хорошее ядро, но ядро Эльбрус-16С все равно быстрее на FP.
Я в комменте выше привел ссылочку на тестирование Эльбрус-8СВ и Байкал-М1. Посмотрите на более реальные приложения в нем (хотя там тоже хватает синтетики). Дело просто в том, что при очень хорошей теоретической пиковой производительности, ее еще нужно достичь в реальном использовании, а то иначе получится то что вы там можете видеть в Linpack и Blender - когда производительность Э8СВ и Байкал-М1 отличается далеко не вдвое.
Нет, ядра Syntacore слабее, чем A57.
Про них есть презентация 2019 года, где SCR7 показывает 5.00 Coremark/mhz, если посмотрите на байкал-м1 - у него 4.94 coremark/mhz. Понятно что это только 1 бенчмарк, но все таки.
Самое производительное RISC-V ядро в мире - это новое ядро P550 от SiFive.
Тут тоже не так все однозначно. Есть MicroMagic'овское ядро, которое выбивает 13000 coremark'ов суммарно.
Есть Alibaba XT910 - который они правда сравнивают с Cortex-A73, но он практически везде показывает результаты лучше, на десятки процентов. Еще и 150 GFLOP (FP32) на кластер (до 4-х кластеров в рамках одного чипа) заявляют.
Так что надо опять же определять критерии, по которым сравнение идет.
А про сложность создания эффективных OoO ядер - посмотрите на SonicBOOM - opensource risc-v ядро, которое делают в berkely, которое в среднем обгоняет Cortex-A73.
Ядро Эльбрус-8СВ производительнее ядра Cortex-A57. А частоты у них совпадают на одинаковом техпроцессе.
Строго говоря не везде. Если посмотреть по тем тестам, то тот же 7zip - не очень отличается, время в блендере (не смотря на превосходство в 2 с лишним раза в specfp) - тоже, бенчмарки в JS вообще на Эльбрусе в разы хуже. А если посмотреть на соседние статьи то в интерпретируемых языках на Эльбрусе все совсем печально.
Так что я бы не делал таких строгих заявлений.
А частоты у них совпадают на одинаковом техпроцессе.
Строго говоря нет, потому что были другие процессоры на A57 на 28нм, которые работали на частотах в районе 2 ГГц (конкретно Opteron A1170), поэтому некорректно обобщать результаты Байкала на всю микроархитектуру.
Почему именно такие цифры? Это в законе написанно?
Спросите у автора выше, я использовал его пример с 4-я ошибками в день.
Про 1 ошибку за сутки - если обращаться по гарантии к производителям памяти напрямую это примерно практическая граница когда они готовы поменять модули памяти без вопросов (речь идет о десктопных модулях). Так строго говоря я не удивлюсь, если по закону даже 1 ошибка за неделю будет основанием для гарантийного случая, если ты сможешь доказать что причиной ее возникновения является память.
Обычный закон о защите прав потребителя в стране вашего проживания. 4 ошибки в день если вы их можете показать - основание для гарантийного случая (строго говоря 1 ошибка в день тоже), так как устройство нерабочее и если дело дойдет до суда то суд вы выиграете без проблем.
К счастью, эти битфлипы легко проверить. Я написал простенькую программку, с огромным массивом на 2 миллиарда 64-bit integer-ов. Было бы интересно воочию увидеть хотя бы один битфлип )
Строго говоря memtest такое умеет. Обычно для пользовательского железа достаточно воспроизводимых результатов на 24-х часовом прогоне теста, чтобы сервис-центр признал это проблемой.
Легко. Всю статью читать не обязательно важные выдержки следующие:
correctable errors among machines at the end of this section. To compare against prior work, we measured the correctable error incidence rate over the course of twelve months (7/13 up to and including 7/14, excluding 1/14) and found that, cumulatively across all months, around 9.62% of servers experience correctable memory errors. This is much lower than the yearly correctable error incidence rate reported in work from the field seven years ago
Figure 2 (left) shows the distribution of correctable errors among servers that had at least one correctable error. The x axis is the normalized device number, with devices sorted based on the number of errors they had during a month. The y axis shows the total number of errors a server had during the month in log scale. Notice that the maximum number of logged errors is in the millions. We observe that a small number of servers have a large number of errors. For example, the top 1% of servers with the most errors have over 97.8% of all observed correctable errors
However, if we examine the error rate for the majority of servers (by taking the median errors per server per month), we find that most servers have at most 9 correctable errors per server per mont
То есть на базе этого - для работоспособного железа 9 CE в месяц или 1 ошибка примерно раз в 3 дня.
В целом советую почитать исследование, оно обстоятельное и чуть ли не первое, которое пытается корректно отделить ошибки памяти от ошибок всего остального (например контроллера памяти). Чего не было в той работе, на которую Вы ссылались.
Не надо путать on-die ECC с side-band ECC, почитайте небольшой обзор. Первое - да, будет в DDR5, так как первый покрывает бит-флипы в рамках чипа, но не в рамках передачи данных (когда про память говорят ECC то это именно inline ECC).
Осталось подождать лет 10.
Интеловский Alder Lake с DDR5 будет в этом году, AMDшный Zen 4 по слухам в начале следующего. Это таки меньше 10 лет.
мне нужен. именно потому, что я хочу работать на компьютере, не не тестировать сутками память.
Ну так и не тестируйте. Для домашнего использования ошибки памяти достаточно редки, что ими можно пренебречь.
каких-то специфичных симптомов, говорящих о том, что память надо бы протестировать, нет (симптомами могут быть и редкие вылеты программ, и зависания/перезагрузки, и порча файлов — всё это может вызываться кучей разных причин).
И да и нет - когда система была стабильна, а потом перестала - это повод усомниться в качестве оперативной памяти. Опять же это случается не так часто, чтобы на этот счет волноваться в рамках единичных компьютеров.
Вы не учитываете условия и что старые статьи (статья гугла это 2009 год) не разделяла типы сломанного железа (ошибки контроллера памяти принимались за ошибки планки памяти). Есть более новая статья Facebook'а где эта проблема в методологии исправлена. И с ее учетом (после исключения из данных тех железок, где были проблемы с другими частями железа) выходит примерно 1 CE в 3 с небольшим дня на сервер (не на гигабайт).
И эта статистика в общем-то коррелирует с тем, что я наблюдал на прошлых работах (когда проблемы с железом были в моей зоне ответственности, статистики там конечно не так много - сотни и в лучшем случаи тысячи серверов и в среднем 128 ГБ всего оперативки на сервер).
Никто не гарантирует корректную работу не-ECC памяти.
Гарантирует закон. 4 бит-флипа в сутки - повод обратиться в гарантийку, вам не откажут и новая память будет работать лучше. Так было всегда и так остается до сих пор. Для не-ECC памяти должно быть строго меньше 1 бит-флипа в сутки.
Согласно статистике, космическое излучение вызывает 4 переключения битов в день и это не много, а самый что ни на есть стандарт.
Согласно современной статистике меньше 1 бит-флипа в день. В зависимости от исследования люди замечали от 1 ошибки в 2 дня (технически в 41 час) до 9 ошибок в месяц, на современном железе (1 ошибка в 3 дня).
Потому что для решения такой проблемы есть замечательное слово: гарантия.
Для 32 ГБ 4 ошибки за день это чрезмерно много (должно быть около 0) и свидетельствует о проблемах с настройкой системы или битом железе. В такой же ситуации с ECC следует понимать, что шанс на более чем 1 одновременную ошибку - тоже очень не нулевой.
У AMD, кроме их APUшек, поддержка ECC есть везде. Этим они отличаются.
Дальше про массовые процессоры - каждому Core i есть соответствующий Xeon, у которого с ECC проблем нет. Например тому же i9-9900k соответствует Xeon E2288G и разница в рекомендованных ценах у них 50$ (539$ против 489$).
Плюс "детскость" относительная. Дома ECC не то чтобы нужен обычным пользователям.
Я могу предположить, что этот кадавр появился только потому, что Эльбрус - редкий зверь. Так можно попытаться представить что он стоит дешевле (в 4, кажется, раза, на 1 рабочее место). Главное не обострять внимание на том, что это обычное разделение одной машины (и на том, что это не уникальная для Эльбрусов вещь).
Вы же понимаете, что у видеокарты гораздо более предсказуемый поток инструкций, и там вероятность сброса длинного конвейера радикально меньше, чем у процессора общего назначения? В видеокарте-VLIW наращивать глубину конвейера действительно ничего не мешает.
Там человек фактически неправ даже (есть разница в 2 раза, но в пользу RISC чипа от nVidia, а не как он пытается выставить). Так что и дальше аргументы у него все такого же уровня, к сожалению.
АМД видимо не знали про критические цепи, поэтому у их видеокарт на VLIW частоты были раза этак в 2-3 выше чем у конкурента.
Вы доказательство то приводите, а то я открыл табличку с характеристиками карт и вижу что R2900 XTX - по Core Clock'ам обгоняли на 10%, а по Shader Clock'у отставали в 2 с небольшим раза от GeForce 8800 Ultra (напомню что VLIWовость в первую очередь относилась к унифицированным шейдерным ядрам, а не к TMU и прочей обвязке, а тут у nVidia в те времена частоты были 1.5 ГГц, в то время как у AMD частота была 743 МГц), имея при этом более современный техпроцесс (80нм TSMC против 90нм TSMC у nVidia).
Отлистываю потом в последнее поколение - fermi у нвидии (GTX 580) 772 МГц частоту ядра имел (по прежнему для шейдерных процессоров нужно было умножать на 2, то есть 1544 МГц в итоге), у AMD их Terascale - 880 МГц (6970). Как-то, извининте, на 2-3 раза совсем не тянет. Так что, извольте, не вводить людей в заблуждение. В последнем поколении техпроцесс был одинаковый - 40 нм и там и там.
Пример АМД показателен еще и тем, что первые поколения этой архитектуры (R2000/3000) не давали впечатляющих результатов мягко говоря, но амд продолжала работать дорабатывать архитектуру, кодогенератор, пока в итоге не оказалось что middle-end радеон на уровне или даже обгоняет топ нвидии, и разрыв этот сохранялся вплоть до перехода на GCN
Тут Вы фактически тоже не правы. AMDшный 6970 который был одночиповым топом, отставал почти во всех играх где была высокая шейдерная нагрузка от GTX 580 (не сильно, процентов на 5, но тем не менее).
Почитайте тестытех (к сожалению на ixbt графики на флеше, но выводы те же что у anandtech) времен. Его плюс был цена - которая была между GTX 570 и GTX 580, но при этом карта позиционировалась как топ, а на топ она недотягивала (не забываем что в моде были еще и двухчиповые топы в те времена, но на них можно не смотреть в контексте разговора про частоты)
Про Compute вы тоже не совсем правы. В OpenCL средние карты от AMD обгоняли топы nVidia, это как раз одна из причин почему nVidia поработала позже над Kepler и Maxwell именно в разрезе Compute производительности. Но вот реализовать пиковые 2.7 ТФлопс на амдшках было крайне сложно и в реальном мире получалось как попало все (были тесты как по ссылке где AMD рвали нвидию в клочья и где производительность была близка к теоретически достижимой, но в ряде тестов эффективность архитектуры заметно падала и они начинали резко отставать от нвидии).
Давайте Вы все таки возьмете за правило давать доказательства своих слов, ладно? А то пока что вы тотально ошибаетесь в каждом посте за последние несколько дней.
что у нвидиа архитектура не позволяла сделать частоты выше
Опять же - кажется это Ваша задача доказать что это так. Пока у всех Tesla/Fermi частоты были порядка 600-800 МГц (удвоенные для шейдерных процессоров соответственно) и даже разгон не позволял прям принципиально поменять картину: игнорируя TDP стабильная работа была возможна на 850-860 МГц при хорошем охлаждении и без повышения напряжения на чипе. В свете этого - мне кажется нужно доказательство что архитектура позволяла больше.
От влив ушли потому что для GPGPU старые ядра не подходили
От VLIW ушли потому что на бумаге он был крут, и если разработчик действительно заморочился и писал на AMD IL то получался хороший результат (по сути ручная оптимизация кода так как ближе к железу чем AMD IL не было возможности опуститься). Но людям хотелось портируемости решений, а значит языки более высокого уровня, а вот код просто скомпилированный выполнялся почему-то не очень эффективно, особенно если там было много ветвлений (а это как раз то время когда начался активный переход на DX 10 и 11, с более сложными шейдерами, в том числе и появление вычислительных шейдеров в DirectX сказалось на развитии карт). То есть причины те же что автор озвучивает в статье против General Purpose CPU для VLIWов - без ручной оптимизации получается фигня какая-то.
Когда утверждаете что-то, расходящееся с общепринятым пониманием, неплохо бы приводить доказательства собственным словам. Впрочем вы еще про прошлый пост не ответили про независимость частот от архитектур мне и соседнему комментатору про готовые блоки.
Какие именно напряжения у A1170, у Байкала-М1 и у Эльбруса-8СВ? Пожалуйста со ссылочками на источники.
Но даже так - это никоим образом не опровергает довод. Есть пример процессора, который в рамках схожего TDP (32 Вт у А1170) работал на частотах порядка 2 ГГц. Есть примеры мобильных процессоров на А57, работавших на 1.7-1.9 ГГц. Ваше заявление про "1.5 это предел" - на проходит проверку на практике.
Точно такой же вопрос - какие напряжения у 16С (одно или несколько, не знаю как уж там по архитектуре). Давайте Вы приведете источники, а потом посмотрим.
Строго говоря в разгноворе выше не имеет значения что и почему делает mediatek.
Но в целом намекну - посмотрите на TDP топового снапдрагона на A75 и на TDP топового медиатека на A75. В этом и будет ответ.
Звучит так, словно вы пытаетесь сейчас подобрать такие данные, чтобы получить нужный вам вывод (потому что абсолютно игнорируете все остальные доводы).
Для микроархитектурной скорости (и прежде чем заявлять что-то про частоты) стоит посмотреть на 1-поточную производительность на максимально доступных частотах - то есть на Ryzen 5950X с его 5.05 ГГц. Давайте тогда так возьмем, чтобы честно было.
Я вам привел ссылку на презентацию и Coremark, по которому SCR7 лучше чем A57 (пусть и не очень значительно). Так и что дальше?
Мне кажется, это стоит подкрепить цифрами в SpecINT 2017 по A53 и A57, иначе заявление спорное (синтетические бенчмарки тем и плохи, что показывают местами разный результат).
Теперь видели. А по чистой FP производительности получаются результаты выше чем у практически любого существующего официального ARM-ядра.
Почему вероятно? Какой-то очень неочевидный вывод. Если почитаете статью про SonicBOOM - там симулировали процессор полность., а не отдельные блоки, также как для моделировали показатели для частоты 3.2 ГГц (раздел 7 соответствующей статьи). Эти отдельные узкие бенчмарки это CoreMark и SpecInt 2006 и 2017 Rate и получали показатели лучше чем Cortex-A73 (а в отдельных бенчмарках лучше чем Skylake).
Извините, но не вижу никаких обоснований тому почему бы в реальном железе это ядро показывало бы худший результат на МГц чем при моделировании.
Ну это полезный показатель, если вы работаете в SpecFP.
В остальных случаях - полезнее смотреть в целом на различные тесты, в том числе в реальных приложениях. Например посмотрите по приведенной ссылке на результаты в Блендере, где А57 показал почти такой же результат как Э-8СВ (при разнице в SpecFP в 2.5 раза, а блендер был в основе одного из под-тестов). Посмотрите на linpack (который не совсем бенчмарк в общем-то) и увидите что 2.5 раза в нем превращаются в 1.5 раза в линпаке. Посмотрите на более интересные бенчмарки в софте что будут использовать люди - то есть на интерпретируемые языки (веб-сервер), javascript (браузер) и прочее - там байкал превосходит эльбрус в 2 с лишним раза.
Опять выглядит так, что вы выбрали одну конкретную метрику и пытаетесь ее использовать как единственно верную, но реальная жизнь она сложнее чем несколько бенчмарков.
Если прям есть уверенность в безбажности софта - то не такой и плохой вариант. Так у подсистемы памяти характерная проблема в том что софт вылетает случайны и случайным образом и чаще всего всегда чуть по-разному (включая выдачу некорректных результатов).
Да, это не очень удобно и не очень приятно, но я для себя не вижу проблем потратить два дня раз в несколько лет (я за несколько десятков лет владения ПК и ноутами помню ровно три случая неожиданных проблем с памятью (один раз было неприятно, на рабочем ноуте, но довольно очевидно - бит-флипы приводили к изменению текста в том числе в dmesg :), но так как это был ноут с распаяной памятью я так никогда и не узнал это память или что-то еще было виновато), а один раз проблемы были ожидаемы (умерший БП с искрами и дымом, который повредил вообще почти все, включая память, процессор и мать и половину жестких дисков).
В принципе еще лайф-хак - это махнуть память с какой-нибудь соседней системой, если возникли подозрения на проблемы. Иногда бывает проще чем гонять мем-тест.
Вы делаете ту же ошибку что и другие люди, оперирующие базовой частотой - считаете что процессор всегда работает только на ней и никак иначе. А это в корне не верно (поищите в прошлых темах тред про это, tldr - надо смотреть на частотную формулу и что конкретное приложение утилизирует и в каком объеме). Строго говоря в таком контексте Ваш рассчет 100% неверный, потому что для 1 ядра у Epyc'ов boost гарантирован и вы получите там свои 3.5 ГГц (кстати непонятно почему вы не взяли 7713, у которого буст до 3.675 ГГц).
Опустим пока то, что у МЦСТ планы с реальностью не всегда соотносились и говорить о том что раз в роадмапе стоит для 6нм процессора цель в 2.5 ГГц, то ее обязательно достигнут - это немного преждевременно.
Ну и вам повторяли уже несколько раз - то что делаете вы - это в принципе некорректно, но вы продолжаете...
ARM разрабатывает мобильные ядра более 20 лет. Строго говоря в серверный сегмент они начали смотреть только последние пару лет (а A57, который кстати делали не для байкала, а для телефонов, вообще ядро 2014 года). Те же A57 на 1.5-2 ГГц стояли в телефонах в 2014-2015 годах и прекрасно себя показывали в рамках теплопакета в 9-12 Вт (надо по процессорам смотреть, но это типичные значения для флагманов). Притом на 28-20 нм техпроцессах, еще и вкупе с видеоядром. Так что совсем непонятно к чему вопрос.
Я в комменте выше привел ссылочку на тестирование Эльбрус-8СВ и Байкал-М1. Посмотрите на более реальные приложения в нем (хотя там тоже хватает синтетики). Дело просто в том, что при очень хорошей теоретической пиковой производительности, ее еще нужно достичь в реальном использовании, а то иначе получится то что вы там можете видеть в Linpack и Blender - когда производительность Э8СВ и Байкал-М1 отличается далеко не вдвое.
Про них есть презентация 2019 года, где SCR7 показывает 5.00 Coremark/mhz, если посмотрите на байкал-м1 - у него 4.94 coremark/mhz. Понятно что это только 1 бенчмарк, но все таки.
Тут тоже не так все однозначно. Есть MicroMagic'овское ядро, которое выбивает 13000 coremark'ов суммарно.
Есть Alibaba XT910 - который они правда сравнивают с Cortex-A73, но он практически везде показывает результаты лучше, на десятки процентов. Еще и 150 GFLOP (FP32) на кластер (до 4-х кластеров в рамках одного чипа) заявляют.
Так что надо опять же определять критерии, по которым сравнение идет.
А про сложность создания эффективных OoO ядер - посмотрите на SonicBOOM - opensource risc-v ядро, которое делают в berkely, которое в среднем обгоняет Cortex-A73.
Строго говоря не везде. Если посмотреть по тем тестам, то тот же 7zip - не очень отличается, время в блендере (не смотря на превосходство в 2 с лишним раза в specfp) - тоже, бенчмарки в JS вообще на Эльбрусе в разы хуже. А если посмотреть на соседние статьи то в интерпретируемых языках на Эльбрусе все совсем печально.
Так что я бы не делал таких строгих заявлений.
Строго говоря нет, потому что были другие процессоры на A57 на 28нм, которые работали на частотах в районе 2 ГГц (конкретно Opteron A1170), поэтому некорректно обобщать результаты Байкала на всю микроархитектуру.
Спросите у автора выше, я использовал его пример с 4-я ошибками в день.
Про 1 ошибку за сутки - если обращаться по гарантии к производителям памяти напрямую это примерно практическая граница когда они готовы поменять модули памяти без вопросов (речь идет о десктопных модулях). Так строго говоря я не удивлюсь, если по закону даже 1 ошибка за неделю будет основанием для гарантийного случая, если ты сможешь доказать что причиной ее возникновения является память.
Обычный закон о защите прав потребителя в стране вашего проживания. 4 ошибки в день если вы их можете показать - основание для гарантийного случая (строго говоря 1 ошибка в день тоже), так как устройство нерабочее и если дело дойдет до суда то суд вы выиграете без проблем.
Строго говоря memtest такое умеет. Обычно для пользовательского железа достаточно воспроизводимых результатов на 24-х часовом прогоне теста, чтобы сервис-центр признал это проблемой.
Легко. Всю статью читать не обязательно важные выдержки следующие:
То есть на базе этого - для работоспособного железа 9 CE в месяц или 1 ошибка примерно раз в 3 дня.
В целом советую почитать исследование, оно обстоятельное и чуть ли не первое, которое пытается корректно отделить ошибки памяти от ошибок всего остального (например контроллера памяти). Чего не было в той работе, на которую Вы ссылались.
Не надо путать on-die ECC с side-band ECC, почитайте небольшой обзор. Первое - да, будет в DDR5, так как первый покрывает бит-флипы в рамках чипа, но не в рамках передачи данных (когда про память говорят ECC то это именно inline ECC).
Интеловский Alder Lake с DDR5 будет в этом году, AMDшный Zen 4 по слухам в начале следующего. Это таки меньше 10 лет.
Ну так и не тестируйте. Для домашнего использования ошибки памяти достаточно редки, что ими можно пренебречь.
И да и нет - когда система была стабильна, а потом перестала - это повод усомниться в качестве оперативной памяти. Опять же это случается не так часто, чтобы на этот счет волноваться в рамках единичных компьютеров.
Вы не учитываете условия и что старые статьи (статья гугла это 2009 год) не разделяла типы сломанного железа (ошибки контроллера памяти принимались за ошибки планки памяти). Есть более новая статья Facebook'а где эта проблема в методологии исправлена. И с ее учетом (после исключения из данных тех железок, где были проблемы с другими частями железа) выходит примерно 1 CE в 3 с небольшим дня на сервер (не на гигабайт).
И эта статистика в общем-то коррелирует с тем, что я наблюдал на прошлых работах (когда проблемы с железом были в моей зоне ответственности, статистики там конечно не так много - сотни и в лучшем случаи тысячи серверов и в среднем 128 ГБ всего оперативки на сервер).
Гарантирует закон. 4 бит-флипа в сутки - повод обратиться в гарантийку, вам не откажут и новая память будет работать лучше. Так было всегда и так остается до сих пор. Для не-ECC памяти должно быть строго меньше 1 бит-флипа в сутки.
Согласно современной статистике меньше 1 бит-флипа в день. В зависимости от исследования люди замечали от 1 ошибки в 2 дня (технически в 41 час) до 9 ошибок в месяц, на современном железе (1 ошибка в 3 дня).
Потому что для решения такой проблемы есть замечательное слово: гарантия.
Для 32 ГБ 4 ошибки за день это чрезмерно много (должно быть около 0) и свидетельствует о проблемах с настройкой системы или битом железе. В такой же ситуации с ECC следует понимать, что шанс на более чем 1 одновременную ошибку - тоже очень не нулевой.
У AMD, кроме их APUшек, поддержка ECC есть везде. Этим они отличаются.
Дальше про массовые процессоры - каждому Core i есть соответствующий Xeon, у которого с ECC проблем нет. Например тому же i9-9900k соответствует Xeon E2288G и разница в рекомендованных ценах у них 50$ (539$ против 489$).
Плюс "детскость" относительная. Дома ECC не то чтобы нужен обычным пользователям.
Я могу предположить, что этот кадавр появился только потому, что Эльбрус - редкий зверь. Так можно попытаться представить что он стоит дешевле (в 4, кажется, раза, на 1 рабочее место). Главное не обострять внимание на том, что это обычное разделение одной машины (и на том, что это не уникальная для Эльбрусов вещь).
Теперь о роскосмосе либо хорошо, либо никак? (не удержался от такого комментария)
Но вообще печально конечно.
Там человек фактически неправ даже (есть разница в 2 раза, но в пользу RISC чипа от nVidia, а не как он пытается выставить). Так что и дальше аргументы у него все такого же уровня, к сожалению.
Вы доказательство то приводите, а то я открыл табличку с характеристиками карт и вижу что R2900 XTX - по Core Clock'ам обгоняли на 10%, а по Shader Clock'у отставали в 2 с небольшим раза от GeForce 8800 Ultra (напомню что VLIWовость в первую очередь относилась к унифицированным шейдерным ядрам, а не к TMU и прочей обвязке, а тут у nVidia в те времена частоты были 1.5 ГГц, в то время как у AMD частота была 743 МГц), имея при этом более современный техпроцесс (80нм TSMC против 90нм TSMC у nVidia).
Отлистываю потом в последнее поколение - fermi у нвидии (GTX 580) 772 МГц частоту ядра имел (по прежнему для шейдерных процессоров нужно было умножать на 2, то есть 1544 МГц в итоге), у AMD их Terascale - 880 МГц (6970). Как-то, извининте, на 2-3 раза совсем не тянет. Так что, извольте, не вводить людей в заблуждение. В последнем поколении техпроцесс был одинаковый - 40 нм и там и там.
Тут Вы фактически тоже не правы. AMDшный 6970 который был одночиповым топом, отставал почти во всех играх где была высокая шейдерная нагрузка от GTX 580 (не сильно, процентов на 5, но тем не менее).
Почитайте тесты тех (к сожалению на ixbt графики на флеше, но выводы те же что у anandtech) времен. Его плюс был цена - которая была между GTX 570 и GTX 580, но при этом карта позиционировалась как топ, а на топ она недотягивала (не забываем что в моде были еще и двухчиповые топы в те времена, но на них можно не смотреть в контексте разговора про частоты)
Про Compute вы тоже не совсем правы. В OpenCL средние карты от AMD обгоняли топы nVidia, это как раз одна из причин почему nVidia поработала позже над Kepler и Maxwell именно в разрезе Compute производительности. Но вот реализовать пиковые 2.7 ТФлопс на амдшках было крайне сложно и в реальном мире получалось как попало все (были тесты как по ссылке где AMD рвали нвидию в клочья и где производительность была близка к теоретически достижимой, но в ряде тестов эффективность архитектуры заметно падала и они начинали резко отставать от нвидии).
Давайте Вы все таки возьмете за правило давать доказательства своих слов, ладно? А то пока что вы тотально ошибаетесь в каждом посте за последние несколько дней.
Опять же - кажется это Ваша задача доказать что это так. Пока у всех Tesla/Fermi частоты были порядка 600-800 МГц (удвоенные для шейдерных процессоров соответственно) и даже разгон не позволял прям принципиально поменять картину: игнорируя TDP стабильная работа была возможна на 850-860 МГц при хорошем охлаждении и без повышения напряжения на чипе. В свете этого - мне кажется нужно доказательство что архитектура позволяла больше.
От VLIW ушли потому что на бумаге он был крут, и если разработчик действительно заморочился и писал на AMD IL то получался хороший результат (по сути ручная оптимизация кода так как ближе к железу чем AMD IL не было возможности опуститься). Но людям хотелось портируемости решений, а значит языки более высокого уровня, а вот код просто скомпилированный выполнялся почему-то не очень эффективно, особенно если там было много ветвлений (а это как раз то время когда начался активный переход на DX 10 и 11, с более сложными шейдерами, в том числе и появление вычислительных шейдеров в DirectX сказалось на развитии карт). То есть причины те же что автор озвучивает в статье против General Purpose CPU для VLIWов - без ручной оптимизации получается фигня какая-то.
Когда утверждаете что-то, расходящееся с общепринятым пониманием, неплохо бы приводить доказательства собственным словам. Впрочем вы еще про прошлый пост не ответили про независимость частот от архитектур мне и соседнему комментатору про готовые блоки.
Кажется, тут нужно предоставить доказательство этому утверждению.