софту плевать на то, какой проц, прибиты к x86 только программы под винду
Вы подменяете "необходимо" из оригинального поста на "прибито". Это разные вещи, так как для опровержения "необходимо" достаточно показать наличие возможности сборки софта под Windows на другой архитектуре (то есть Win RT, Win 10 и Win 11 удовлетворяют этому требованию). Поэтому вообще все твои претензии основаны на неправильном прочтении сообщения (или на додумывании).
Дальше по существу остального сообщения:
А ничего не значит, то, что писалось под 8-ку арм можно выбросить — в 10-ке там всё переписали, так что те универсальные приложения уже на свалке вроде.
Если почитаете MSDNчик, то увидите что совместимость не нарушалась. Приложения, которые разработчик 1 раз сделал для Windows RT по заверению Microsoft работают на Windows 10 и Windows 11. Вот наоборот - да, все сломано, собрал UWP под 10+ и на старом планшете на Windows RT ты его уже не запустишь. Так что твое утверждение фактически неверно.
То что писалось с прибитием к 32 битному режиму работы самой ОС — уже можно выбросить в 64 битных
Я на Windows 11 ARM запускал пару 32-х битных бенчмарков родом из 2004-ого (просили прогнать Crystalmark). Сейчас ради интереса скачал 3D Mark 2000, как ни сложно догадаться 2000-ого года, и он на удивление работает. Кажется что двух примеров достаточно, чтобы опровергнуть твой тезис.
грубо говоря, если есть сервис и его не скомпилировали под 64, то уй вам, а не возможность установить и запустить приложение правильно
Вот с сервисом не знаю, могу проверить если знаешь какое-нибудь приложение которое все еще доступно на сайте производителя в архиве и которое в систему ставит сервис.
а введение транслятора добавят ещё кучу вещей, которые придётся выбросить
Теоретически могут, да. На практике требуется доказательство, в том числе и того что Microsoft не будет работать над исправлением проблем транслятора. Иначе утверждение преждевременно.
а уже тем более не переходят на арм с трансляторами те, кому нужно вот ту приблуду запустить, которую написали кучу лет назад.
Обычно люди на конкретном железе тестируют нужный им софт и смотрят как он работает, после чего принимают решение могут ли они перейти, нужно ли им переделать старый софт или проще закупить где-нибудь железо где его еще можно запустить. Так между версиями Windows всегда есть как минимум какой-то процент софта, который перестает работать или перестает работать корректно, поэтому до сих пор есть организации которые крутят у себя Windows 3.x потому что даже на 9x уже есть нерешаемые проблемы. Ровно поэтому твой аргумент в рамках всей дискуссии не имеет смысла, так как он легко переносится на любой апгрейда версии винды.
Поэтому ваши ответы так же полезны, как поддержка итаниума виндой
То есть имеет ограниченный успех и занял свою нишу? (я напомню что Windows на Itanium выходила вплоть до 2008 R2 и имела свою нишу, пусть и не очень большую) Спасибо за комплемент.
То есть настолько RT была не «ещё одна редакция», что весь процесс объединения до сих пор не окончился…
Это предполагает какие-то незаконченные процессы, о которых я и спросил выше. Вы привели примеры того что ядро уже унифицировано (и как не сложно заметить - до выпуска Windows 10 On ARM), приложения - есть UWP. Дальше две цитаты не имеющие отношения к моему вопросу.
Так какие процессы еще не закончены?
Собственно то, о чем вы написали тут я примерно помню, поэтому спросил что вы понимаете под унификацией. Кстати, ответа на это так и не последовало пока что.
Я абсолютно не вижу, в каком месте то что ты сейчас написал расходится с тем что я написал выше. Процитирую что я говорил:
Не знаю как у него на счет совместимости, но есть основания предполагать что все что запустится на x86 на Win 11 запустится и под транслятором.
Твоя фраза про "не сможет работать не из-за арм архитектуры вообще, особенно под 11" является частичным более грубым перефразированием того что я сказал.
А я отвечал другому человеку, на тему "я хочу запустить воооон ту софтину" и состояния дел на текущий момент. В общем твоя претензия как обычно мимо. Читай внимательнее на что люди отвечают.
Сначала вышла Windows RT (8 и 8.1) где работали только собранные Microsoft'ом нативные приложения на ARM, либо приложения из Windows Store (вроде были какие-то лазейки для энтерпрайз клиентов подгружать свои, но я не помню какие проблемы там были). Народ это относительно быстро расковырял и проверку подписи смог выключить (но я не следил, поправили ли лазейку с патчами или нужно было никогда не обновлять Win RT), тогда стало возможным собирать Windows приложения под ARM. Строго говоря Windows RT больше похожа на еще одну редакцию Win 8 (как Starter Edition, только еще более огороженный) и когда народ нашел способ поменять нужный ключик, они ее превращали в полноценную 8-ку. То есть "отдельная ветка" конечно можно сказать, но немного с натяжкой.
Потом была Windows 10 ARM, притом только в 2017 году, насколько я помню бета-версия эмулятора x86 была там чуть ли не из коробки.
64-х битная эмуляция появилась в Insider Preview в декабре 2020, но на 10-ке так и не была зарелизена. У 11-ой винды на ARM 64-х битный эмулятор из коробки.
в свободной продаже что байкалы что эльбрусы (несмотря на всеобщее мнение) есть
Про эльбрусы ответ от МЦСТ простой - "нет". Есть пара компаний которые не совсем официально и с вопросами к законности такого действия, готовы либо закупить у МЦСТ Эльбрус, все подписать, а потом тебе его передать, уже без обязательств, либо даже готовы напрямую продать ПК или сервер на Эльбрусе, который они сами и производят (но за соответствующую цену).
Там возникает еще много вопросов, на которые нет ответа - например возможен ли экспорт такого изделия (кто-то говорит "да", кто-то "нет", кажется никто не проверял) и каков юридический статус софта, который тебе с ним передали (диска с исходниками и компилятора). Так как одно время сотрудники МЦСТ высказывались, что такие схемы с точки зрения МЦСТ - промышленный шпионаж.
А так если есть деньги (естественно больше чем ценник на сайте МЦСТ), то в любом чате про Эльбрусы найдутся добрые люди кто подскажет контакты этих компаний.
Скажите, вы специально фокусируетесь не на том, о чем я пишу, отвечая мне?
не тестируют по полному "подходу" на сайте SPEC.
Я вел речь о сравнении несравнимого. Как добьетесь того, чтобы на spec.org об этом явно упоминало (разрешало сравнивать результаты тестов в заведомо разных и неравных условиях) - можем продолжить данную беседу. Всего доброго.
P.S. И нет, в индустрии не принято сравнивать то, что сравнивать не верно. Иногда случается по ошибке, конечно, но это не общепринятая практика.
Эти мелкие ключи у Байкала для peak на общий результат не должны сильно влиять.
Этому утверждению требуется доказательство.
Например, вот у Altra разница между Peak и Base менее 2%:
Если присмотритесь, у Альтры даже в base дофига платформ-зависимых оптимизаций. В отличии от Байкала которые туда только -march=native воткнули и понадеялись что будет ок.
Но Байкал и anandtech этого не делали. В этом они схожи.
Схожи. Различие только в том, что на anandtech вообще никаких телодвижений по подбору опций не было. Поэтому без формального доказательства для каждой платформы (в данном случаи в том числе с учетом версий компиляторов и микроархитектур) что эти опции не влияют на производительность SPECа, сравнение между ними невозможно.
Честно не понимаю зачем вы спорите с подходом общепринятым в индустрии и описанном на сайте SPEC'а. Если вы правы - уговорите SPEC изменить требования к публикациям, раз у них там явная ошибка и они заморачиваются на несущественные вещи (предполагая что вы правы, а все остальные ошибаются). Скажите, как изменения попадут в официальную документацию, до тех пор смысла в продолжении диалога нет.
И зачем они это делают годами, если так ни одного оформленного результата Spec эта команда так и не выдала за все эти годы?
Спрашивайте эту команду.
Где результаты всех этих "красивых" оптимизаций?
Судя по сливам от сотрудников МЦСТ, у них результаты в SPEC'е подросли для 8С/8СВ с момента первых же сливов (извините, но цифры из презентаций и которые тут говорили в комментах я кроме как сливами назвать не могу, так как публикации формальной не было). Так что видимо МЦСТ это устраивает.
Так почему же все они не выдали на-гора оптимизации для нагрузок Spec, которые могли бы подтянуть в тесты Байкалы?
Спрашивайте Байкал об этом. Они кстати, это видно в отчете по М1, попытались как минимум, поэтому их публичные результаты надо либо воспроизводить в том же виде, либо нельзя сравнивать с другими, кто даже не попытался (например anandtech).
Так можно ли сравнивать те результаты Spec 2017 на сайте Anandtech?
Можно сравнивать со всеми результатами теста, которые были сделаны в равных условиях. То есть когда настройки системы были одинаковые и проводилась одинаковая работа по оптимизации опций запуска (в случаи anandtech'а - никакая, стандартные опции).
и можно сравнивать их с байкалами
Нет, у Байкала-М1 опубликованы настройки и они сильно отличаются от того что используется на anandtech'е (у Байкала будут чуть выше результаты чем если его протестировать с теми же настройками как на anandtech для M1 и 12900k). С Эльбрусами также нельзя, потому что там в принципе неизвестно что делалось теми кто проводили тесты, также как нельзя с резлуьтатами Байкала-S1 по тем же причинам. Скорее всего можно (но крайне осторожно) между Байкалом-S1, M1 и Эльбрусом, но только исходя из предположений что Байкал и МЦСТ сделали все что смогли.
В общем посмотрите на приложение к отчету по Байкалу-М1, а потом посмотрите как запускает тесты anandtech,после чего должно быть очевидно (если вы работали с компиляторами на уровне пользователя) почему сравнение некорректно будет.
заинтересованы занести в компиляторы оптимизации, которые выдадут высокую производительность на разных нагрузках, включая Spec 2017.
Вы так и не поняли о чем я. Перечитайте, а потом прочитайте Run Rules спека.
Подсказка - обратите внимание на то какие параметры могут варьировать запускающие бенчмарк. Подумайте потом почему это важно для производительности и оценки.
Там для Эльбрусов только несколько человек занимаются компиляторами C++ / Fortran.
Строго говоря есть свидетельства что в МЦСТ есть команда людей, которая занимается получением красивых результатов в SPEC. К тому же нормальной публикации результатов от МЦСТ нет (см. правила по публикации на spec.org). Кстати по Байкалу-М1 есть. По Байкалу-S тоже нет (но тут я надеюсь что она случится в будущем как было с эмкой, было бы интересно поизучать).
против всего остального мира оптимизаторов под ARM на массовых ядрах A57/A75.
Подсказка: вы уперлись в оптимизацию компилятора, но игнорируете другие допустимые оптимизации при запуске SPECов. Также игнорируете то что я уже вам несколько раз объяснил, почему нельзя цифры с Anandtech сравнивать с тем что публикует производитель (точнее можно, при условии что производитель не тратил время и силы на оптимизацию параметров запуска теста, но во всех случаях когда это не публикуется - сравнение некорректно).
Нет, не корректно. Я кажется объяснил выше почему. Аргументации почему корректно кроме "все так делают", к тому же бездоказательной, я с вашей стороны не услышал.
Но они не выдали.
Вы упустили суть той части что я сказал и сосредоточились на не имеющем значения.
Суть была в том, что SPEC такой бенчмарк, который требует аккарутного обращения (как и все бенчмарки), и если у тебя результаты получены из разных источников, то их надо обязательно анализировать то как бенчмарки собирались. Если в одном источнике авторы потратили уйму времени на оптимизацию результата, а в другом просто собрали первым попавшимся компилятором со стандартными параметрами сборки, то сравнивать результаты будет нельзя.
В ситуации когда хотя бы один из источников не публикует детали (и детализацию по тестам и параметры сборки, то есть нарушает принцип воспроизводимости, на который я выше ссылался), то сравнивать его с результатами из других источников таже нельзя. Теоретически можно очень аккуратно сравнивать показатели, которые публикует производитель, исходя из того что они потратят достаточно времени на оптимизацию, но не более того.
Приводя упрощенную аналогию - представьте себе что вы сравниваете машины на гоночной трассе. Один производитель взял просто в магазине младший вариант машины из тест драйвовых и приехал на ней, а другой заказал вариант с самым мощным двигателем, навесил максимум опций для уменьшения сопротивления воздуха, подбором шин, бензина и вообще всяческой оптимизацией под конкретную трассу. Корректно ли публиковать результаты, умалчивая о деталях конфигурации и насколько допустимо будет сравнение результатов в таком случаи?
Свободы выбора из двух вариантов по цифрам никто пока не давал. Поэтому и ошибиться нельзя.
Поэтому сравнение проводить некорректно.
Да, там есть результат байкала на 2.5 GHz на 32 ядра. Но это баловство "на попробовать".
Оно тем не менее есть. И кстати на 24 ядра, а не на 32.
Частота зависит от техпроцесса.
Частота зависит от техпроцесса И микроархитектуры. Поэтому сравнивать нормируя по частоте - некорректно.
такую производительность можно замерить даже на эмуляторе до появления реального продукта.
Почти согласен. На эмуляторе можно, но поэтому вы и получтие "больше чем". К сожалению, тесты зависят еще от кучи параметров, например от скорости памяти, кэшей (и их количества) и так далее. Собственно это одна из причин почему производитель IP ядер тут дает именно такие формулировки (обычно у sifive вы можете сконфигурировать ядро достаточно гибко), а вот производители конкретного процессора обычно не опускаются до нормирования по частоте. Поэтому аргумент не верен.
Также не забывайте, что обычно у производителя есть возможность подбирать параметры сборки и играться с компилятором, поэтому spec настоятельно требует публиковать детали окружения чтобы результаты были валидны. И тут брать цифру от случайных обзорщиков и от производителя - нельзя (будет как в презентации сбербанка с интелом).
Ну так смотрите на детилизацию в том числе. Про недопустимость учета частоты тут - я уже сказал.
Для эльбрусов и байкалов взял цифры из этой статьи
Повторюсь еще раз - вы взяли Spec Rate или Spec Base? Если не в курсе, то почему вы думаете что сравниваете одну и ту же величину?
Так предложил считать "микроархитектурную скорость" Armmaster
Как я уже сказал, так как частота определяется в том числе микроархитектруными особенностями, то не надо на нее нормировать, вы получаете величину которая в каких-то сравнениях может сказать что-нибудь, но в целом бесполезна.
Пока же исходим из того, что официально будет по 2.0 GHz у них.
По косвенным признакам у них будет процессор с частотой выше чем 2.0 ГГц, как минимум такое решение тестируется (но с меньшим количеством ядер). К сожалению geekbench такие мелочи как частоты ядер не показывает.
И в этом Geekbench прирост получился в 9 раз у Байкал-S относительно Байкал-М. А число ядер увеличилось в 6 раз.
Вы возьмите просто результат single core, в нем прирост в 1.866 раза (в зависимости от теста от 1.6 до 2.5 раз), а то пересчет из Multicore - дело немного неблагодарное, когда мы говорим о микроархитектурной скорости.
Добавлю еще Apple M1 Max в табличку микроархитектурной скорости Spec2017:
Говоря о Spec2017 говорите пожалуйста что конкретно вы опубликовали (я напомню что spec это int, fp и у каждого еще разбивка на base и peak), а также вашу методику и источники рассчета "микроархитектурной" скорости SPEC'а, а то вдруг вы как выше с geekbench'ем сделали все неверно?
И, кажется, я вам уже задавал этот вопрос в прошлом, но почему вы таки считаете что частота (а я предполагаю по низким цифрам, хоть и не знаю откуда они, что вы нормировали результаты по частоте) не является микроархитектурной особенностью? Я вполне возьмусь утверждать что нормирование по частоте тут недопустимо в принципе, когда речь идет о микроархитектурной скорости (либо прошу ссылку на сайт spec'а с определением, где дается точная методика).
Вы не забывайте, что по условиям лицензии на x86, VIA может разрешать производство своим дочерним компаниям (subsidiary), которой и является Zhaoxin. Так что "поделилась наработками" это лишь о продаже каких-то конкретных IP блоков или в случаи Intel - про перекупку сотрудников.
Вопрос в том что и в каких условиях будет на практике. А то теория это прекрасно, но это всегда проблемы чтоб этого достичь на практике хоть где нибудь.
Производство ssd в России есть, дорогие, но вполне конкурентноспособные по характеристикам решения
У gs group по виду тех ссд что публиковалось - одна из ревизий референсной платы silicon motion'а, соответствующий контроллер и микроновская память в корпусировке gs group'а. Было бы странно если бы они работали как то иначе.
У других производителей непонятно, на тех фото что публикуются не видно маркировок чипов.
Вы подменяете "необходимо" из оригинального поста на "прибито". Это разные вещи, так как для опровержения "необходимо" достаточно показать наличие возможности сборки софта под Windows на другой архитектуре (то есть Win RT, Win 10 и Win 11 удовлетворяют этому требованию). Поэтому вообще все твои претензии основаны на неправильном прочтении сообщения (или на додумывании).
Дальше по существу остального сообщения:
Если почитаете MSDNчик, то увидите что совместимость не нарушалась. Приложения, которые разработчик 1 раз сделал для Windows RT по заверению Microsoft работают на Windows 10 и Windows 11. Вот наоборот - да, все сломано, собрал UWP под 10+ и на старом планшете на Windows RT ты его уже не запустишь. Так что твое утверждение фактически неверно.
Я на Windows 11 ARM запускал пару 32-х битных бенчмарков родом из 2004-ого (просили прогнать Crystalmark). Сейчас ради интереса скачал 3D Mark 2000, как ни сложно догадаться 2000-ого года, и он на удивление работает. Кажется что двух примеров достаточно, чтобы опровергнуть твой тезис.
Вот с сервисом не знаю, могу проверить если знаешь какое-нибудь приложение которое все еще доступно на сайте производителя в архиве и которое в систему ставит сервис.
Теоретически могут, да. На практике требуется доказательство, в том числе и того что Microsoft не будет работать над исправлением проблем транслятора. Иначе утверждение преждевременно.
Обычно люди на конкретном железе тестируют нужный им софт и смотрят как он работает, после чего принимают решение могут ли они перейти, нужно ли им переделать старый софт или проще закупить где-нибудь железо где его еще можно запустить. Так между версиями Windows всегда есть как минимум какой-то процент софта, который перестает работать или перестает работать корректно, поэтому до сих пор есть организации которые крутят у себя Windows 3.x потому что даже на 9x уже есть нерешаемые проблемы. Ровно поэтому твой аргумент в рамках всей дискуссии не имеет смысла, так как он легко переносится на любой апгрейда версии винды.
То есть имеет ограниченный успех и занял свою нишу? (я напомню что Windows на Itanium выходила вплоть до 2008 R2 и имела свою нишу, пусть и не очень большую) Спасибо за комплемент.
Теперь стало еще менее понятно. Вы писали:
Это предполагает какие-то незаконченные процессы, о которых я и спросил выше. Вы привели примеры того что ядро уже унифицировано (и как не сложно заметить - до выпуска Windows 10 On ARM), приложения - есть UWP. Дальше две цитаты не имеющие отношения к моему вопросу.
Так какие процессы еще не закончены?
Собственно то, о чем вы написали тут я примерно помню, поэтому спросил что вы понимаете под унификацией. Кстати, ответа на это так и не последовало пока что.
Я абсолютно не вижу, в каком месте то что ты сейчас написал расходится с тем что я написал выше. Процитирую что я говорил:
Твоя фраза про "не сможет работать не из-за арм архитектуры вообще, особенно под 11" является частичным более грубым перефразированием того что я сказал.
Ок, а что ты вкладываешь в "процесс объединения" в таком случаи?
А я отвечал другому человеку, на тему "я хочу запустить воооон ту софтину" и состояния дел на текущий момент. В общем твоя претензия как обычно мимо. Читай внимательнее на что люди отвечают.
Сначала вышла Windows RT (8 и 8.1) где работали только собранные Microsoft'ом нативные приложения на ARM, либо приложения из Windows Store (вроде были какие-то лазейки для энтерпрайз клиентов подгружать свои, но я не помню какие проблемы там были). Народ это относительно быстро расковырял и проверку подписи смог выключить (но я не следил, поправили ли лазейку с патчами или нужно было никогда не обновлять Win RT), тогда стало возможным собирать Windows приложения под ARM. Строго говоря Windows RT больше похожа на еще одну редакцию Win 8 (как Starter Edition, только еще более огороженный) и когда народ нашел способ поменять нужный ключик, они ее превращали в полноценную 8-ку. То есть "отдельная ветка" конечно можно сказать, но немного с натяжкой.
Потом была Windows 10 ARM, притом только в 2017 году, насколько я помню бета-версия эмулятора x86 была там чуть ли не из коробки.
64-х битная эмуляция появилась в Insider Preview в декабре 2020, но на 10-ке так и не была зарелизена. У 11-ой винды на ARM 64-х битный эмулятор из коробки.
И какое отношение это имеет ко мне? Я отвечал на другой пост и другой набор утверждений. Читайте внимательнее.
Про эльбрусы ответ от МЦСТ простой - "нет". Есть пара компаний которые не совсем официально и с вопросами к законности такого действия, готовы либо закупить у МЦСТ Эльбрус, все подписать, а потом тебе его передать, уже без обязательств, либо даже готовы напрямую продать ПК или сервер на Эльбрусе, который они сами и производят (но за соответствующую цену).
Там возникает еще много вопросов, на которые нет ответа - например возможен ли экспорт такого изделия (кто-то говорит "да", кто-то "нет", кажется никто не проверял) и каков юридический статус софта, который тебе с ним передали (диска с исходниками и компилятора). Так как одно время сотрудники МЦСТ высказывались, что такие схемы с точки зрения МЦСТ - промышленный шпионаж.
А так если есть деньги (естественно больше чем ценник на сайте МЦСТ), то в любом чате про Эльбрусы найдутся добрые люди кто подскажет контакты этих компаний.
Скажите, вы специально фокусируетесь не на том, о чем я пишу, отвечая мне?
Я вел речь о сравнении несравнимого. Как добьетесь того, чтобы на spec.org об этом явно упоминало (разрешало сравнивать результаты тестов в заведомо разных и неравных условиях) - можем продолжить данную беседу. Всего доброго.
P.S. И нет, в индустрии не принято сравнивать то, что сравнивать не верно. Иногда случается по ошибке, конечно, но это не общепринятая практика.
Этому утверждению требуется доказательство.
Если присмотритесь, у Альтры даже в base дофига платформ-зависимых оптимизаций. В отличии от Байкала которые туда только -march=native воткнули и понадеялись что будет ок.
Схожи. Различие только в том, что на anandtech вообще никаких телодвижений по подбору опций не было. Поэтому без формального доказательства для каждой платформы (в данном случаи в том числе с учетом версий компиляторов и микроархитектур) что эти опции не влияют на производительность SPECа, сравнение между ними невозможно.
Честно не понимаю зачем вы спорите с подходом общепринятым в индустрии и описанном на сайте SPEC'а. Если вы правы - уговорите SPEC изменить требования к публикациям, раз у них там явная ошибка и они заморачиваются на несущественные вещи (предполагая что вы правы, а все остальные ошибаются). Скажите, как изменения попадут в официальную документацию, до тех пор смысла в продолжении диалога нет.
Спрашивайте эту команду.
Судя по сливам от сотрудников МЦСТ, у них результаты в SPEC'е подросли для 8С/8СВ с момента первых же сливов (извините, но цифры из презентаций и которые тут говорили в комментах я кроме как сливами назвать не могу, так как публикации формальной не было). Так что видимо МЦСТ это устраивает.
Спрашивайте Байкал об этом. Они кстати, это видно в отчете по М1, попытались как минимум, поэтому их публичные результаты надо либо воспроизводить в том же виде, либо нельзя сравнивать с другими, кто даже не попытался (например anandtech).
Можно сравнивать со всеми результатами теста, которые были сделаны в равных условиях. То есть когда настройки системы были одинаковые и проводилась одинаковая работа по оптимизации опций запуска (в случаи anandtech'а - никакая, стандартные опции).
Нет, у Байкала-М1 опубликованы настройки и они сильно отличаются от того что используется на anandtech'е (у Байкала будут чуть выше результаты чем если его протестировать с теми же настройками как на anandtech для M1 и 12900k). С Эльбрусами также нельзя, потому что там в принципе неизвестно что делалось теми кто проводили тесты, также как нельзя с резлуьтатами Байкала-S1 по тем же причинам. Скорее всего можно (но крайне осторожно) между Байкалом-S1, M1 и Эльбрусом, но только исходя из предположений что Байкал и МЦСТ сделали все что смогли.
В общем посмотрите на приложение к отчету по Байкалу-М1, а потом посмотрите как запускает тесты anandtech,после чего должно быть очевидно (если вы работали с компиляторами на уровне пользователя) почему сравнение некорректно будет.
Вы так и не поняли о чем я. Перечитайте, а потом прочитайте Run Rules спека.
Подсказка - обратите внимание на то какие параметры могут варьировать запускающие бенчмарк. Подумайте потом почему это важно для производительности и оценки.
Строго говоря есть свидетельства что в МЦСТ есть команда людей, которая занимается получением красивых результатов в SPEC. К тому же нормальной публикации результатов от МЦСТ нет (см. правила по публикации на spec.org). Кстати по Байкалу-М1 есть. По Байкалу-S тоже нет (но тут я надеюсь что она случится в будущем как было с эмкой, было бы интересно поизучать).
Подсказка: вы уперлись в оптимизацию компилятора, но игнорируете другие допустимые оптимизации при запуске SPECов. Также игнорируете то что я уже вам несколько раз объяснил, почему нельзя цифры с Anandtech сравнивать с тем что публикует производитель (точнее можно, при условии что производитель не тратил время и силы на оптимизацию параметров запуска теста, но во всех случаях когда это не публикуется - сравнение некорректно).
Run rules содержит ответ почему это не так.
Нет, не корректно. Я кажется объяснил выше почему. Аргументации почему корректно кроме "все так делают", к тому же бездоказательной, я с вашей стороны не услышал.
Вы упустили суть той части что я сказал и сосредоточились на не имеющем значения.
Суть была в том, что SPEC такой бенчмарк, который требует аккарутного обращения (как и все бенчмарки), и если у тебя результаты получены из разных источников, то их надо обязательно анализировать то как бенчмарки собирались. Если в одном источнике авторы потратили уйму времени на оптимизацию результата, а в другом просто собрали первым попавшимся компилятором со стандартными параметрами сборки, то сравнивать результаты будет нельзя.
В ситуации когда хотя бы один из источников не публикует детали (и детализацию по тестам и параметры сборки, то есть нарушает принцип воспроизводимости, на который я выше ссылался), то сравнивать его с результатами из других источников таже нельзя. Теоретически можно очень аккуратно сравнивать показатели, которые публикует производитель, исходя из того что они потратят достаточно времени на оптимизацию, но не более того.
Приводя упрощенную аналогию - представьте себе что вы сравниваете машины на гоночной трассе. Один производитель взял просто в магазине младший вариант машины из тест драйвовых и приехал на ней, а другой заказал вариант с самым мощным двигателем, навесил максимум опций для уменьшения сопротивления воздуха, подбором шин, бензина и вообще всяческой оптимизацией под конкретную трассу. Корректно ли публиковать результаты, умалчивая о деталях конфигурации и насколько допустимо будет сравнение результатов в таком случаи?
Не очевидно.
Поэтому сравнение проводить некорректно.
Оно тем не менее есть. И кстати на 24 ядра, а не на 32.
Частота зависит от техпроцесса И микроархитектуры. Поэтому сравнивать нормируя по частоте - некорректно.
Почти согласен. На эмуляторе можно, но поэтому вы и получтие "больше чем". К сожалению, тесты зависят еще от кучи параметров, например от скорости памяти, кэшей (и их количества) и так далее. Собственно это одна из причин почему производитель IP ядер тут дает именно такие формулировки (обычно у sifive вы можете сконфигурировать ядро достаточно гибко), а вот производители конкретного процессора обычно не опускаются до нормирования по частоте. Поэтому аргумент не верен.
Также не забывайте, что обычно у производителя есть возможность подбирать параметры сборки и играться с компилятором, поэтому spec настоятельно требует публиковать детали окружения чтобы результаты были валидны. И тут брать цифру от случайных обзорщиков и от производителя - нельзя (будет как в презентации сбербанка с интелом).
Ну так смотрите на детилизацию в том числе. Про недопустимость учета частоты тут - я уже сказал.
Повторюсь еще раз - вы взяли Spec Rate или Spec Base? Если не в курсе, то почему вы думаете что сравниваете одну и ту же величину?
Как я уже сказал, так как частота определяется в том числе микроархитектруными особенностями, то не надо на нее нормировать, вы получаете величину которая в каких-то сравнениях может сказать что-нибудь, но в целом бесполезна.
По косвенным признакам у них будет процессор с частотой выше чем 2.0 ГГц, как минимум такое решение тестируется (но с меньшим количеством ядер). К сожалению geekbench такие мелочи как частоты ядер не показывает.
Вы возьмите просто результат single core, в нем прирост в 1.866 раза (в зависимости от теста от 1.6 до 2.5 раз), а то пересчет из Multicore - дело немного неблагодарное, когда мы говорим о микроархитектурной скорости.
Говоря о Spec2017 говорите пожалуйста что конкретно вы опубликовали (я напомню что spec это int, fp и у каждого еще разбивка на base и peak), а также вашу методику и источники рассчета "микроархитектурной" скорости SPEC'а, а то вдруг вы как выше с geekbench'ем сделали все неверно?
И, кажется, я вам уже задавал этот вопрос в прошлом, но почему вы таки считаете что частота (а я предполагаю по низким цифрам, хоть и не знаю откуда они, что вы нормировали результаты по частоте) не является микроархитектурной особенностью? Я вполне возьмусь утверждать что нормирование по частоте тут недопустимо в принципе, когда речь идет о микроархитектурной скорости (либо прошу ссылку на сайт spec'а с определением, где дается точная методика).
В винде есть x86->ARM транслятор, а в бете есть x86-64 -> ARM транслятор. В целом по производительности конечно звезд с неба не хватает, но работает.
Не знаю как у него на счет совместимости, но есть основания предполагать что все что запустится на x86 на Win 11 запустится и под транслятором.
Вы не забывайте, что по условиям лицензии на x86, VIA может разрешать производство своим дочерним компаниям (subsidiary), которой и является Zhaoxin. Так что "поделилась наработками" это лишь о продаже каких-то конкретных IP блоков или в случаи Intel - про перекупку сотрудников.
Вопрос в том что и в каких условиях будет на практике. А то теория это прекрасно, но это всегда проблемы чтоб этого достичь на практике хоть где нибудь.
У gs group по виду тех ссд что публиковалось - одна из ревизий референсной платы silicon motion'а, соответствующий контроллер и микроновская память в корпусировке gs group'а. Было бы странно если бы они работали как то иначе.
У других производителей непонятно, на тех фото что публикуются не видно маркировок чипов.