а x86 ограничен уже тепловыделением на многоядерную загрузку в районе 3,5 то так ли велика разница?
Вы делаете мне грустно тем, что проигнорировали важные вопросы и примерно 3/4 комментария, в том числе на этом фокусирующихся.
Перечитайте еще раз, пожалуйста, что я написал. Более того - я совсем не понимаю откуда вы берете упорно 3.5 ГГц, когда для Intel'а есть понятия Single core boost, All Core boost, AVX2 Boost, AVX512 Boost и все это даст разный набор множителей в разных ситуациях, притом ни в одной из них он не опустится до base.
Я попробовал примерно обрисовать проблемы в соседней ветке. Не совсем точно но все таки (повторю оттуда - точное объяснение это около трети курса цифровой схемотехники и еще немного знаний из смежных областей, впрочем можете попробовать приобрести какую-то часть самостоятельно - для этого хватит FPGA и желания поедалть на нем всякого разного, например попроходить курсы по дизайну микросхем, благо их в открытом доступе полно)
К тому же про 3-3.5 ГГц на все ядра вы не совсем правы (я тоже пояснил почему не стоит смотреть на базовую частоту у современных процессоров). Хотя тут повторюсь - вот у меня Ryzen 3900X в десктопе, у него базовая 3.8, буст 4.6. На все ядра он работает на 4.2 и на практике до базовой никогда не опускается. Без какого либо разгона и модификаций (если заморочится можно поднять частоту на все ядра еще чуть-чуть). У интелов современных также - у десктопных i9-10900k официальный all-core boost - 4.9 ГГц, при Turbo в 5.3, а базовая при этом 3.7 (такие параметры если мат плата умеет в thermal velocity boost и вся система имеет хорошую систему охлаждения)
Параметр базовой частоты в первую очередь важен для систем лимитированных чем-либо внешним (например системой охлаждения, притом как процессора, так и системы питания на мат плате или просто зарезанными лимитами на общее энергопотребление системы). И второй момент тут юридический - падение частоты под нагрузкой ниже базовой являются гарантийным случаем, в то время как Turbo частота в 5.3 ГГц жарким летом в плохопроветриваемом помещении на штатном кулере - не гарантируется.
Тем не менее разрыв уже гораздо меньше чем у Эльбрус с его 1.5.
Тут тоже есть своя цена - вы не забывайте о том что TDP Itanium'а практически вдвое больше (170 Вт против ~90-100 у Эльбруса). Это как минимум. Во вторых тут опыт и умение инженеров Intel, которые архитектуру вылизывали максимально.
если вообще не остановился, у тех же Epyc на 7 нм максимальная частота те же 4 ГГц, а базовая в районе 2-3
Не очень понятно почему Вы взяли не более близкий по параметрам Ryzen 5950X (с его теоретической частотой в 4.9 и практическими 5.05-5.1 на 1 ядро без разгона со стороны пользователя), а Epyc? Ну или почему не посмотрели на тот же Xeon W-1390P (5.3 GHz - альтернативно можно взять Core i9-10900k, если конечно хочется) как доказательство того, что частота меняется не сильно?
По поводу частоты важным является ответ на вопрос "что же ее ограничивает?" - к сожалению тут полноценный ответ это примерно треть курса цифровой схемотехники с хорошим шансом влезть в соседствующие разделы физики (физики полупроводников, например, но не только). Очень упрощенно - ограничивающими факторами являются и тепловыделение и дизайн схем. Не любая схема у которой есть пространство по TDP сможет разогнаться до больших частот (простым языком можно сослаться на английскую вики).
И в связи с этим начинаются приколы (очень упрощенно) - время выполнения инструкции будет ограничено самым медленным куском команды (в то время как OoO процессор теоретически может загрузить), чем более параллельная схема тем больше сложности идет в шедулер, тем меньше получится частота (1 цикл работы для всей схемы будет занимать больше времени), длинное слово повышает тербования к подсистеме кэша и памяти (чем менее плотный код будет, тем важнее будет подсистема памяти), большой кэш тоже сложнее масштабировать по частоте (притом первого уровня сложнее). И чем больше проблем из списка ты будешь решать тем ближе придешь к OoO RISC процессору.
В то же время для x86 у тебя ограничение по питанию (кстати не очень верно брать просто базовую частоту, у каждого CPU своя формула в зависимости от типов нагрузки и типа процессора - некоторые десктопные могут держать буст частоту на всех ядрах при достаточном охлаждении, или могут сбрасывать частоты только в каких-то определенных задачах, например SIMD нагрузка, но обычно тоже не до базовой частоты).
Но как только они об этом объявили, на них пошла волна «да ничего они не сделают никогда» и «да ваш риск5 — неспособное говно».
Сейчас дно упорно пробивают новой риторикой: "да это все для инклюзивности, ну вы понели, да?" (последний на текущий момент пост в официальном телеграмм-канале МЦСТ)
Вопрос кстати спорный. Коммерческие компании более жизнеспособны за счет большего рынка сбыта, например. А госконтракты вообще палка о двух концах и не всегда компании рады что в них ввязываются.
Тем более сейчас как раз идет речь о создании процессоров для импортозамещения и борьбы за госконтракты.
Не совсем понимаю как Гипотеза Коллатца относится к развитию решений, если честно.
А про продукт - так они и развивают собственно говоря. Просто как продукты стали достаточно взрослые и о них начали говорить, то другая сторона решила что ей надо начать защищать свои контракты (интересно, с чего бы это, если у них такие сильные позиции?)
Люди в принципе, пусть и не очень много, но влияют на то что происходит. Поэтому чем больше правильных вопросов задается ко всем, тем больше шанс что чаша весов качнется в сторону более технически адекватного решения.
Не просто "хулиганы рынка лишают", а явные попытки дискредитировать идеи конкурентов на базе вырванных из контекста цитат (там товарищ Трушкин в телеграмме мини-опус в формате "ну вы понимаете" писал как раз недавно, про OpenPower и risc-v, такой что за это прям стыдно)
Не менее чем с Эльбрусами. Собственно шансов у Syntacore и Cloudbear чуть больше на практике. По сути они за пару лет сделали то, на что МЦСТ потратили 30 лет, это, кажется, о чем-то да говорит.
Мнение интересное, но есть пара фактических ошибок:
В России ограниченный ресурс для разработки микроархитектуры с динамическим распараллеливанием инструкций, Россия просто не потянет и никогда не сможет отладить такой процессор
Эльбрус на текущий момент чуть ли не более сложный, чем многие OoO процессоры. Там в общем свои проблемы возникают чтобы архитектура как-то масштабировалась, и это все решается не так чтоб просто. Посмотрите на принципиальную его схему. В общем нету там "в 100 раз проще". Увы. К тому же людей способных написать уникальный быстрый компилятор очень не факт что больше, чем тех кто способен разработать быстрый процессор.
то все равно, чтобы быть на хорошем уровне производительности, прийдется разрабатывать свою микроархитектуру с динамическим распараллеливанием инструкций, что в свою очередь невозможно - см. пункт 2. Купить лицензию на ARM с уже готовой микроархитектурой с динамическим распараллеливанием инструкций (как у Apple), не хватит денег, не позволит гордость, и это уже не будет своим процессором - противоречит пункту 1.
Посмотрите на Cloudbear с их OoO risc-v, посмотрите на то что в презентациях показывал Syntacore в 2018 году.
Чтобы в типичных юзерских задачах обогнать Эльбрус не нужна мегапроизводительность, достаточно иметь что-то уровня Cortex-A72 на той же частоте, а это очень достижимо (а проблемы в плавучке решались бы хорошо проработанным внешним акселератором, раз уж все равно руками оптимизировать, который, кстати, был бы как раз относительно простым).
Касательно же ARM и лицензирования - производительности Apple M1 у них конечно нет, но Neoverse N1/N2 лицензировать вполне по силам и по кошельку было бы. Собственно у Байкала следующие продукты будут на Cortex-A73 и позже на A75, они конечно помедленее, но если выйдут в срок то отставание по микроархитектуре от текущего bleeding edge сильно сократят. Впрочем посмотрите сравнение результатов Эльбруса с теми же A73 или A75 в имеющихся известных тестах. Там опять же не так все плохо.
и никаких перепалок не будет.
Перепалки идут в первую очередь от неверного позиционирования. Процессор для военных? Да пожалуйста, никого не волнует ни закрытость, ни скорость (это проблемы заказчика). А вот как только он пошел в "да мы сейчас все импортозаместим на него" так начинаются проблемы, потому что он в пользовательских задачах уступает телефону 5-и летней давности.
когда вы заменя что-то заявляете прямо — «это другое»!
Покажите где я меняю на ходу аргументацию. Вот прям со ссылками на комментарии и цитаты.
Ага, так и запишем, примеров не было, пытался аргумент списать, заявляя про демагогию другого. А у меня в примерах 7700k и 8600k, всё. Где +6-7% на один поток для первого вырождается в +10-15% в мультипотоке для второго. 4/8 vs 6. Прямое сравнение.
Так и к чему вы это все говорите?
Ну так во многих игровых тестах k выигрывали именно махинацией через разгоны. Поэтому и указал, что без подобных «нечестных сравнений».Но вам же нужно обязательно начать рассказывать про демагогию чужую, а не аргументами с числами.
Так доказательство-то где, что k всегда разгон?
Конкретно с Вами - демагогия с вашей стороны это действительно большой и важный момент, просто потому что Вы практически сразу в нее скатываетесь (что явно видно в этом тредике) и только и ждете удобный повод как бы в чем-нибудь обвинить других (желательно в том же, что делали сами уже неоднократно).
О, точно, у 8600k, на которые я так долго и прямо намекал ещё и частоты ниже аж на 0,2 Ггц максимальных.
И к чему это вы сейчас? Выражайте свои мысли точнее.
Если для них были найдены новые уязвимости. ВЫ прекрасно знали, что уже в 10-м поколении эти уязвимости частично закрыты были аппаратно.
Конечно знаю, но условиями которые Вы поставили не запрещено брать даже 11-ое поколение.
Очередная игра словами, чтоб не признавать очевидного нарушения логики, что процессор, имеющий аппаратные заплатки, естественно не будет так страдать от программных, а так же даже с отключенными не будет показывать производительность такую же, как если бы аппаратные не завезли. Сравнение некорректно изначально, как бы вы демагогичненько не отрицали этот факт.
Извините, но нарушения логики нет. Вы поставили такие условия в которых допустимо взять 10900 или 11900, а теперь по ходу спора начали "да я не это имел в виду", "очевидно что я говорил о" и так далее.
О да, ведь это не вы за меня додумали подобное:
Нет, это то что Вы сказали вот тут и подтвердили вот тут, да и собственно в комментарии же вашем выше. Как-то некрасиво выходит, не находите?
Я допускаю что я могу не понимать подтекстов или скрытых смыслов ваших же слов, поэтому я и настаиваю уже несколько сообщений подряд, что писать надо четко и ясно, оговаривая что вы имеете в виду, или потом уметь признавать свои ошибки.
Интел заявил, что единственные способ точно решить проблему — такой. Вы отрицаете слова Интела?
Я же правильно понимаю, что Вы так интерпретируете INTEL-SA-00233? Вот цитата от туда легко подтвердит Ваши слова, если там такое есть. Так что жду ссылочку на документ на intel.com с подтверждением (новости не в счет, потому что начальные рекомендации по быстрому закрытию уязвимости могут отличаться от итоговых, после того как микрокод был обновлен и ОС были пропатчены).
Касательно "единственный способ точно решить проблему" - были слова не Intel'а нескольких экспертов в области безопасности, там было в духе "даже после патча мы не можем быть уверены что такое не повторится, вон что было со спектрами, так что если прям важна безопасность - лучше выключите SMT", но сторонние эксперты таки не являются Интелом.
То есть вы отрицаете тесты, по которым у людей падали иопсы?
Я кажется однозначно написал: Вы неверно описали проблему.
На базе неверного понимания естественно делаете неверные выводы и упускаете настоящее объяснение. У вас есть достаточно указателей чтобы почитать как дела обстоят на самом деле.
Я всего лишь указал, что тесты не могут быть оторваны от железа, а процессоры уже давно упираются в работу с подсистемой памяти, имеющей кучу уровней, каждый из которых чаще всего тормознее предыдущей.Заплатки от уязвимостей конкретно имели побочку в, процитирую не себя:
Ок, спасибо что решили дилемму. Жаль только что в сторону непонимания, а не чрезмерного упрощения.
Тогда я дам Вам совет на этот случай - прочитайте в деталях почему проблемы возникли с I/O из-за заплаток. Ваше описание в корне не верно, отсюда Вы переоцениваете значимость идентичных условий в плане подсистемы памяти и дисковой подсистемы. Начать можете с чтения википедии про уязвимости, разделов про Mitigation (Spectre, Meltdown и теперь вот ZombieLoad). В целом по запросу "The Impact of Meltdown/Spectre for Storage" прям на первой странице будет статья описывающая механизм (в целом Вы его можете попытаться вывести из тестов на phoronix'е и описания уязвимостей на википедии, но это сложнее).
Впрочем это не отменяет того что Phoronix публикует и исходники тестового пакета и описания тестовых стендов, так что ответ на Ваш изначальный вопрос есть в статье. Читайте внимательнее.
Ещё раз, я указываю, что по данным тестам сделать выводы для всех процов можно только в случае, если условия при прочем — равны. Если системы кардинально различные, одни процессоры имеют уже аппаратные заплатки, а другие нет, то делать по сему выводы, опираясь только на крайние модели даже не после выявления проблемы, а после обнародования (она там сколько лет была известна, как и то, что её всем расскажут?) — некорректно чуть более, чем полностью. Да, вы показываете, что для имеющих аппаратные заплатки падение меньше. Но это ничего не значит, так как вы не можете показать «чистую» производительность решения без этих заплаток. Так что смотреть надо лишь на те, которые было до заплаток. Всё.
Я повторю в уже который раз - я занимаюсь сравнением в условиях которые поставили Вы сами. Если вам что-то не нравится - ну формулируйте мысли лучше или иначе, а не разводите демагогию на пустом месте.
А уж под эгидой этого рассказывать, что демагог тут не вы, а другой, при этом раз за разом отворачиваясь даже от простого сравнения 7700k и 8600k…
Я от него отворачиваюсь потому что до сих пор не понимаю какое отношение оно имеет к Вашим же первоначальным условиям. Не говоря про то, что вообще чем дальше, тем сложнее читать Ваши сообщения. Вздохните глубоко, напишите четко по пунктам, может тогда будет о чем предметно поговорить.
P.S. С вашей стороны уже было достаточно подлогов и попыток переврать что я говорю, поэтому с данного комментария я буду Вам давать максимум поисковые запросы, но не ссылки. Прекращу это делать когда будет несколько ответов мне с нормальным уровнем аргументации и без попыток разводить демагогию. Притом сразу предупреждаю - если прекратите пытаться приводить нормально аргументацию то я не буду видеть смысла в продолжении беседы в принципе, как по мне демагогия с вашей стороны очевидна, низкий технический уровень аргументации тоже (и замечу - это ровно то, в чем вы любите обвинять других людей в комментариях тут и там).
Я методички интела даже не читал, что характерно, а взял то, что в среднем из всяких тестрований в играх и бенчмарках получается. Дальше что?
В каких? Я вот открыл два по запросу "Core i9 Hyperthreading Enabled Disabled" и увидел что разброс там такой что усредненные 30% не выходят вообще никак (а вот "до 30%" - легко, но у Вас "до" нету).
недопустимо никогда использовать циферки, которые у людей в тестах и играх получается, допустимо тогда, когда вам удобно в одни тест из множества? Отличная логика.
Не вижу логической связи с тем что я сказал.
О да, то есть теперь нельзя сравнивать процы между собой в тестировании игрорьках, круто. А манипулирую здесь типа я?
Чистой воды демогогия с вашей стороны, потому что вы делаете за меня утверждения и с ними спорите.
Демагогия — это у вас. Если вы покажете мне, как после отключения потоков 4 ядерный рвёт 6 ядерный не в паре задач и не потому что он «k» с разгоном, то тогда вы ещё как-то сможете аргументировать свои слова
Простите, демагогия в чистом виде у вас. Вы на ходу меняете условия, делаете за оппонента какие-то выводы, игнорируете неудобные вам вопросы (или части утверждений). Примерно то, в чем вы обычно обвиняете своих оппонентов.
и не потому что он «k» с разгоном, то тогда вы ещё как-то сможете аргументировать свои слова
Ок, если вы считаете что k - с разгоном, то о каком предметном споре может идти речь дальше? Я намекну что k значит разблокированный множитель, а вот разгон из коробки не включен нигде, потому что по мнению Intel'а он ведет к потере гарантии (как доказать это - оставим за скобками). Но на случай если я не прав я приму любую ссылку на сайт intel'а где будет сказано что k процессор - overclocked (а не unlocked).
однако, я повторюсь, интел выпустил с минимальными изменениями несколько поколений процов, в которых постепенно наращивал ядра, так как на ядро производительность росла на уровне погрешности, а при этом в много потоке 8 потоков не рвали 6 чистых ядер, то рассказы о том, что заплатки, от которых требуется вырубание многопоточности, ну никак не влияют на проиводительность «в среднем» — это прям сильное колдунство.
Вы опять переобуваетесь на ходу, прочитайте ваши заявления изначальные, о которых мы ведем речь сейчас.
Но опять же я Вам уже сказал - в вашей постановке вопроса я беру 6 ядер на низкой частоте, 4 ядра на высокой и показываю что 4 практически всегда (если не всегда) быстрее.
То есть вы демагогично отказываетесь читать:
Я Вам сказал что Вы попросту переобулись на ходу, в изначальном Вашем утверждении ничего такого не было. Но если заметите, я спорю как с изначальным утверждением, так и с переобутым (переобутое чуть ближе к истине, но не совсем).
А это не демагогия? Она, родненькая. Ибо выпуск после уязвимостей таки логично, что будет подпилен, то есть там прирост мог быть выше, если б не заранее дыркозатыканием его не понизили. Доказывайте, что это не так. Что без аппаратных заплаток 10900k не был бы производительнее, чем то, что выпущено.А то как демагогие чужие слова — вы первые, а как свои аргументы на логику проверять внутреннюю — так сразу бревна в глазу не видать.
Это не демагогия, потому что я не умею читать Ваши мысли. Я могу поговорить про Ваши высказывания, которые были как я их привел.
Любые Ваши переобувания по ходу спора - это какое-то странное действие (тем более недостаточно переобуваетесь), могли бы просто сказать "был не прав, в таком виде как я написал изначально - конечно ничего такого не будет" и закончить дискуссию на этом.
Касательно же выбора 10900k - Вашими изначальными аргументами такой выбор не запрещен (более того, формально можно взять и 11-ую серию).
Доказывать про "10900k бы бы производильнее" - не вижу смысла, потому что я подобных утверждений не делал. А докаживать Ваши мысли мне не интересно.
Нет, я указываю, что его в принципе необходимо было отключать, как единственное решение проблемы.
Что противоречит тому, на что вы ссылаетесь.
О, вы про те, которые отрицаете, когда на заявление про 30% смотрите? Опять двойная логика пошла? Тут юзаем, тут нет?
Опять приписывание мне вещей, которые я не говорил. Я не отрицаю прирост от HT, я утверждаю что он неоднородный и зависит от задачи, в том числе что есть класс задач где есть падение скорости от его включения. Я кажется это открытым текстом Вам говорю с самого начала.
Напомню Вам лишь то, что додумывать за оппонента - попадает под определение демагогии.
А так как собственно дырки были в том, что есть данные в кэше или нет и их надо грузить из оперативки и/или с жесткого, то чем быстрее память, то тем меньше падение будет из-за патчей, влияющих на ввод-вывод, как бы.
У меня дилемма. С одной стороны то что Вы написали - неверно и показывает непонимание что такое Spectre и Meltdown. С другой - хочется дать вам benefit of a doubt последний раз и сказать что упрощения которые вы делаете - недопустимы. Перестаньте упрощать и тогда Вам станет ясно почему Ваше объяснение является ложным.
Единственный вариант, что все тесты оторваны от реальности и того, что в фоне работает ОС, которая активно юзает жесткий и оперативку, а данные тестов в кэш, размером которого (вроде у чем новее ядра, тем его больше), кстати, так же могут часть проблем нивелировать, ага.Особенно в общих-то задачах
Касательно методологии - вы первым начали ссылаться на Phoronix. Значит ли это, что когда Вы даете ссылку - это истина и методология корректна, а когда кто-то другой - она не верна?
В любом случаи, раз Вы ссылались, то должны знать что PTS - опенсорсный продукт, можете проверить что конкретно они делают в каких случаях.
И в конце концов, Вы всегда можете прочитать последние пару параграфов в статье, найти ссылку на описание тестовых систем, а также, раз Вы сами решили ссылаться на Phoronix, почитать как они делают тесты. Как по мне, вы сейчас пытаетесь найти хоть что-то чтобы сказать "ага, тесты неправомерны" и отмести результат, который Вам не нравится. Если так, то Вы просто можете просто прекратить дискуссию, а если хочется таки оставить последнее слово за собой, то напишите "Ваши тесты мне просто не нравятся, я верю в то что сказал". О вере я спорить не буду и от Вас отстану.
Вы бредите, даже в той же мцст разработкой софта (всего - библиотеки, компиляторы дистрибутив) занимается 20 человек, а железом 200
Вы так говорите, как будто МЦСТ тут вообще показательные. К тому же еще вопрос, точно ли вы правы про 20 человек и 200 и распределение задач? Откуда у вас инфа?
Во вторых какая бы железка не была, хоть за 100 хоть за 500 миллионов, под нее все равно придется софт портировать и ускорять под новые инструкции, автоматом к процессору ничего не прилогается.
То есть если сделать armv8.2 (или rv64g, как удобнее) совместимый процессор, то на нем ничего не запустится и софт на него придется портировать? Расскажите почему так?
Потому что использовал обобщённую оценку, что 8 потоков интела хуже 6 чистых ядер интела без потоков.
Хорошо, и что?
Это ваша логика, не моя.
Нет, это именно что ваша логика. Вы взяли цифру из маркетинговой брошюры интела, которая звучала как "up to 30%" (первое место где 30% встречается если искать) и опустили "up to". По такой же логике я имею полное право найти один тест где HT проигрывает и сказать что "смотрите, он же медленее".
Я замечу, что вы продолжая гнуть свою линию занимаетесь обычной демагогией.
Так как класс задач большой, то в целом на обычных компах оценивают в среднем.
Минуточку, в целом на обычных компах выделяют категории по задачам и оценивают в среднем по ним (подходы несколько отличаются у разных обзорщиков). Усреднять яблоки с кирпичами допустимо только когда речь идет о производных характеристиках (например объем или вес ящиков с грузом), также и с задачами. Иначе у вас открывается просто непаханное поле для манипуляции данными - главное подобрать набор тестов так чтобы усреднение показало нужные результаты.
Если на 6 ядрах без сильного изменения внутренностей (у интела были такие отличные примеры оного, что наглядно) куча бенчей оказывается на уровне 4/8, то получаем, что 2 потока дают прирост менее 1,5 в общих задачах.Отключение же HT сразу в общих задачах тем более ваш 4/8 превращает просто в 4-ку, которая проигрывает 6-ке… сколько-сколько, говорите, процентов?
Это опять же чистой воды демагогия. Почему - см. объяснение выше.
Хотя я говорил про половину «успеха» — то есть разницу между процом без предсказаний и с ними.
Да, спасибо что указали на то что вы еще и переобувались на ходу. Изначально речи о "разницы между процом без предсказаний и с ними" не было. Я вам напомню фразу вашу же:
Далее, половина успехов интелов прошлых лет сожрали заплатки от выявленных дыр.
И отмечу что в ее написании речь не идет о "в рамках одного процессора с и без заплаток", а прямая трактовка это "начиная с какого-то момента времени весь прирост между поколениями был сожран заплатками". Из чего правильным тестом будет взять например i7-2600k (без заплаток) и i9-10900k (с заплатками) и сравнить, если будет разница в пользу 10900k, то ваше изначальное утверждение в корне неверно. Остальное вокруг - демагогия.
Ещё вопросы?
Кажется я вам наглядно показал что там нету 50%, а только 25 для старых процессоров и 5% для новых. Так что жду фразы "я был не прав" с вашей стороны.
И который таки вышел через год после выявления ошибок?
Вы не оговаривали условия, значит допустимо взять 10900k и даже 11900k.
А давайте тогда лучше поглядим наоборот, на core i3 и пеньки, а не топовые процы, как более распространённые, какие на них у вас будут
Глядите, увидите ту же самую картину в процентном соотношении. Значение имеет поколение процессора (какое количество аппаратный заплаток было).
Again, this is just the default/out-of-the-box mitigation cost compared to booting with «mitigations=off» and isn't even looking at the penalties incurred if disabling SMT/HT out of security concerns — on that front, core scheduling and other initiatives remain a work-in-progress particularly among the data center / cloud operators.
Опять же, это лишь стандартная (изкоробочная) цена заплаток, по сравнению с загрузкой с mitigations=off и не учитывает цену отключения SMT/HT из-за опасений касательно безопасности - на этом поприще, шедулеры (речь конкретно о https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/core-scheduling.html - что само по себе интересное чтиво) и другие инициативы по прежнему в разработке, особенно среди облачных провайдеров и владельцев датацентров.
Но кстати хорошее замечание, потому что вы предполагаете что HT нужно отключать всегда и всем (не было укзааний на обратное), а если вчитаетесь в описание проблем то узнаете что далеко не всем это важно, и как вы сами предлагали, в общих задачах выключать его не нужно, что делает всю вашу логическую цепочку про "а как же HT?" бессмысленной. Good catch.
Ага, когда вам угодно, то среднее вам не подходит, когда удобно — то аргументация к среднему… шикардос.
У вас учусь :) Но вообще я выше объяснил - есть величины которые допустимо усреднять с оговорками, есть которые недопустимо вообще никогда.
Давайте ещё уточним по поводу того, были ли все тесты на прочем равном железе сделаны? Ну там чтоб не было, что core 4770k с жестким диском и медленной памятью, а 10900k на pcie ссдшках с разогнанной оперативке топовой текущей?
Давайте лучше уточним, точно ли вы понимаете о чем в статье идет речь? Предложите методику каким образом медленная память или не-PCIe SSD будет влиять на overhead от заплаток? Опишите вот прям механизм.
Pypy почти никогда взять не получается, ибо какие-то зависимости на нем работать не будут.
У меня опыт обратный, почти что ни имело смысл брать - все работало адекватно и местами давало нужное время чтобы сделать более правильное решение. Так что скорее зависит от области и конкретных задач.
Мне вот интересно можно ли cython использовать с Эльбрусом?
Cython же, если я все еще правильно помню, это чуть ли не путь по-умолчанию для создания C-extention'ов для питона и тот же SciPy на нем (а еще все биндинги к сишным библиотекам, которые народ делал до рассвета cffi)? Так что если я помню правильно то было бы странно видеть проблемы в этом месте и было бы еще страннее заявлять наличие работающего питона если cython не работает.
Но прошу обращаю внимание именно широкую команду он считает плохой а не эльбрус
Вы так говорите как будто Эльбрус не широкая команда. Перечитайте еще раз что конкретно написано, там банально исходя из правил русского языка негативно высказано и про Эльбрус в частности и про VLIW в целом. Если хотите с этим поспорить - говорите об этом с Бабаяном.
при других настройках происходит компиляция всего цикла в одну широкую команду.
Внутреннего цикла, ценой разрастания внешнего. И как скомпилировал, так и прибьет гвоздями до следующей перекомпиляции.
В итоге можно попытаться костылями (там в общем из треда-то следует что это не ошибка компиляции, а осознанное взвешенное решение для общего случая) сделать лучше в тестовом примере, испортив жизнь во всех других случаях (так как, строго говоря, разрастется внешний цикл в разы). Поэтому выводы человек выше делает верные, просто Вы недочитали что говорили в тредике.
но Бабаян там прежде говорит о несостоятельности суперскалярности
Только это уже не контекст (контекстом конкретной фразы является мнение про VLIW, суперскаляр выпадает из него, также как выпадают идеи куда двигаться дальше), но так да, он там рассказывает свое мнение. Конкретно важный в рамках всего спора вокруг МЦСТ момент в том, что Бабаян разочаровался в VLIW (как в реализации Эльбруса, так и в реализации Itanium).
Вы делаете мне грустно тем, что проигнорировали важные вопросы и примерно 3/4 комментария, в том числе на этом фокусирующихся.
Перечитайте еще раз, пожалуйста, что я написал. Более того - я совсем не понимаю откуда вы берете упорно 3.5 ГГц, когда для Intel'а есть понятия Single core boost, All Core boost, AVX2 Boost, AVX512 Boost и все это даст разный набор множителей в разных ситуациях, притом ни в одной из них он не опустится до base.
Я попробовал примерно обрисовать проблемы в соседней ветке. Не совсем точно но все таки (повторю оттуда - точное объяснение это около трети курса цифровой схемотехники и еще немного знаний из смежных областей, впрочем можете попробовать приобрести какую-то часть самостоятельно - для этого хватит FPGA и желания поедалть на нем всякого разного, например попроходить курсы по дизайну микросхем, благо их в открытом доступе полно)
К тому же про 3-3.5 ГГц на все ядра вы не совсем правы (я тоже пояснил почему не стоит смотреть на базовую частоту у современных процессоров). Хотя тут повторюсь - вот у меня Ryzen 3900X в десктопе, у него базовая 3.8, буст 4.6. На все ядра он работает на 4.2 и на практике до базовой никогда не опускается. Без какого либо разгона и модификаций (если заморочится можно поднять частоту на все ядра еще чуть-чуть). У интелов современных также - у десктопных i9-10900k официальный all-core boost - 4.9 ГГц, при Turbo в 5.3, а базовая при этом 3.7 (такие параметры если мат плата умеет в thermal velocity boost и вся система имеет хорошую систему охлаждения)
Параметр базовой частоты в первую очередь важен для систем лимитированных чем-либо внешним (например системой охлаждения, притом как процессора, так и системы питания на мат плате или просто зарезанными лимитами на общее энергопотребление системы). И второй момент тут юридический - падение частоты под нагрузкой ниже базовой являются гарантийным случаем, в то время как Turbo частота в 5.3 ГГц жарким летом в плохопроветриваемом помещении на штатном кулере - не гарантируется.
Тут тоже есть своя цена - вы не забывайте о том что TDP Itanium'а практически вдвое больше (170 Вт против ~90-100 у Эльбруса). Это как минимум. Во вторых тут опыт и умение инженеров Intel, которые архитектуру вылизывали максимально.
Не очень понятно почему Вы взяли не более близкий по параметрам Ryzen 5950X (с его теоретической частотой в 4.9 и практическими 5.05-5.1 на 1 ядро без разгона со стороны пользователя), а Epyc? Ну или почему не посмотрели на тот же Xeon W-1390P (5.3 GHz - альтернативно можно взять Core i9-10900k, если конечно хочется) как доказательство того, что частота меняется не сильно?
По поводу частоты важным является ответ на вопрос "что же ее ограничивает?" - к сожалению тут полноценный ответ это примерно треть курса цифровой схемотехники с хорошим шансом влезть в соседствующие разделы физики (физики полупроводников, например, но не только). Очень упрощенно - ограничивающими факторами являются и тепловыделение и дизайн схем. Не любая схема у которой есть пространство по TDP сможет разогнаться до больших частот (простым языком можно сослаться на английскую вики).
И в связи с этим начинаются приколы (очень упрощенно) - время выполнения инструкции будет ограничено самым медленным куском команды (в то время как OoO процессор теоретически может загрузить), чем более параллельная схема тем больше сложности идет в шедулер, тем меньше получится частота (1 цикл работы для всей схемы будет занимать больше времени), длинное слово повышает тербования к подсистеме кэша и памяти (чем менее плотный код будет, тем важнее будет подсистема памяти), большой кэш тоже сложнее масштабировать по частоте (притом первого уровня сложнее). И чем больше проблем из списка ты будешь решать тем ближе придешь к OoO RISC процессору.
В то же время для x86 у тебя ограничение по питанию (кстати не очень верно брать просто базовую частоту, у каждого CPU своя формула в зависимости от типов нагрузки и типа процессора - некоторые десктопные могут держать буст частоту на всех ядрах при достаточном охлаждении, или могут сбрасывать частоты только в каких-то определенных задачах, например SIMD нагрузка, но обычно тоже не до базовой частоты).
Не говорит. На том же самом 32нм техпроцессе Core i7 EE достигали 4 ГГц (не-HEDT Core i7 достигали 3.9 ГГц, Xeon'ы - 4.0 если E3, 3.9 если E5)
Сейчас дно упорно пробивают новой риторикой: "да это все для инклюзивности, ну вы понели, да?" (последний на текущий момент пост в официальном телеграмм-канале МЦСТ)
Вопрос кстати спорный. Коммерческие компании более жизнеспособны за счет большего рынка сбыта, например. А госконтракты вообще палка о двух концах и не всегда компании рады что в них ввязываются.
Тем более сейчас как раз идет речь о создании процессоров для импортозамещения и борьбы за госконтракты.
Может конечно, но также и не со стартапом, а с компанией которая не очень взлетает.
Не совсем понимаю как Гипотеза Коллатца относится к развитию решений, если честно.
А про продукт - так они и развивают собственно говоря. Просто как продукты стали достаточно взрослые и о них начали говорить, то другая сторона решила что ей надо начать защищать свои контракты (интересно, с чего бы это, если у них такие сильные позиции?)
Люди в принципе, пусть и не очень много, но влияют на то что происходит. Поэтому чем больше правильных вопросов задается ко всем, тем больше шанс что чаша весов качнется в сторону более технически адекватного решения.
Не просто "хулиганы рынка лишают", а явные попытки дискредитировать идеи конкурентов на базе вырванных из контекста цитат (там товарищ Трушкин в телеграмме мини-опус в формате "ну вы понимаете" писал как раз недавно, про OpenPower и risc-v, такой что за это прям стыдно)
Не менее чем с Эльбрусами. Собственно шансов у Syntacore и Cloudbear чуть больше на практике. По сути они за пару лет сделали то, на что МЦСТ потратили 30 лет, это, кажется, о чем-то да говорит.
Мнение интересное, но есть пара фактических ошибок:
Эльбрус на текущий момент чуть ли не более сложный, чем многие OoO процессоры. Там в общем свои проблемы возникают чтобы архитектура как-то масштабировалась, и это все решается не так чтоб просто. Посмотрите на принципиальную его схему. В общем нету там "в 100 раз проще". Увы. К тому же людей способных написать уникальный быстрый компилятор очень не факт что больше, чем тех кто способен разработать быстрый процессор.
Посмотрите на Cloudbear с их OoO risc-v, посмотрите на то что в презентациях показывал Syntacore в 2018 году.
Чтобы в типичных юзерских задачах обогнать Эльбрус не нужна мегапроизводительность, достаточно иметь что-то уровня Cortex-A72 на той же частоте, а это очень достижимо (а проблемы в плавучке решались бы хорошо проработанным внешним акселератором, раз уж все равно руками оптимизировать, который, кстати, был бы как раз относительно простым).
Касательно же ARM и лицензирования - производительности Apple M1 у них конечно нет, но Neoverse N1/N2 лицензировать вполне по силам и по кошельку было бы. Собственно у Байкала следующие продукты будут на Cortex-A73 и позже на A75, они конечно помедленее, но если выйдут в срок то отставание по микроархитектуре от текущего bleeding edge сильно сократят. Впрочем посмотрите сравнение результатов Эльбруса с теми же A73 или A75 в имеющихся известных тестах. Там опять же не так все плохо.
Перепалки идут в первую очередь от неверного позиционирования. Процессор для военных? Да пожалуйста, никого не волнует ни закрытость, ни скорость (это проблемы заказчика). А вот как только он пошел в "да мы сейчас все импортозаместим на него" так начинаются проблемы, потому что он в пользовательских задачах уступает телефону 5-и летней давности.
Покажите где я меняю на ходу аргументацию. Вот прям со ссылками на комментарии и цитаты.
Так и к чему вы это все говорите?
Так доказательство-то где, что k всегда разгон?
Конкретно с Вами - демагогия с вашей стороны это действительно большой и важный момент, просто потому что Вы практически сразу в нее скатываетесь (что явно видно в этом тредике) и только и ждете удобный повод как бы в чем-нибудь обвинить других (желательно в том же, что делали сами уже неоднократно).
И к чему это вы сейчас? Выражайте свои мысли точнее.
Конечно знаю, но условиями которые Вы поставили не запрещено брать даже 11-ое поколение.
Извините, но нарушения логики нет. Вы поставили такие условия в которых допустимо взять 10900 или 11900, а теперь по ходу спора начали "да я не это имел в виду", "очевидно что я говорил о" и так далее.
Нет, это то что Вы сказали вот тут и подтвердили вот тут, да и собственно в комментарии же вашем выше. Как-то некрасиво выходит, не находите?
Я допускаю что я могу не понимать подтекстов или скрытых смыслов ваших же слов, поэтому я и настаиваю уже несколько сообщений подряд, что писать надо четко и ясно, оговаривая что вы имеете в виду, или потом уметь признавать свои ошибки.
Я же правильно понимаю, что Вы так интерпретируете INTEL-SA-00233? Вот цитата от туда легко подтвердит Ваши слова, если там такое есть. Так что жду ссылочку на документ на intel.com с подтверждением (новости не в счет, потому что начальные рекомендации по быстрому закрытию уязвимости могут отличаться от итоговых, после того как микрокод был обновлен и ОС были пропатчены).
Касательно "единственный способ точно решить проблему" - были слова не Intel'а нескольких экспертов в области безопасности, там было в духе "даже после патча мы не можем быть уверены что такое не повторится, вон что было со спектрами, так что если прям важна безопасность - лучше выключите SMT", но сторонние эксперты таки не являются Интелом.
Я кажется однозначно написал: Вы неверно описали проблему.
На базе неверного понимания естественно делаете неверные выводы и упускаете настоящее объяснение. У вас есть достаточно указателей чтобы почитать как дела обстоят на самом деле.
Ок, спасибо что решили дилемму. Жаль только что в сторону непонимания, а не чрезмерного упрощения.
Тогда я дам Вам совет на этот случай - прочитайте в деталях почему проблемы возникли с I/O из-за заплаток. Ваше описание в корне не верно, отсюда Вы переоцениваете значимость идентичных условий в плане подсистемы памяти и дисковой подсистемы. Начать можете с чтения википедии про уязвимости, разделов про Mitigation (Spectre, Meltdown и теперь вот ZombieLoad). В целом по запросу "The Impact of Meltdown/Spectre for Storage" прям на первой странице будет статья описывающая механизм (в целом Вы его можете попытаться вывести из тестов на phoronix'е и описания уязвимостей на википедии, но это сложнее).
Впрочем это не отменяет того что Phoronix публикует и исходники тестового пакета и описания тестовых стендов, так что ответ на Ваш изначальный вопрос есть в статье. Читайте внимательнее.
Я повторю в уже который раз - я занимаюсь сравнением в условиях которые поставили Вы сами. Если вам что-то не нравится - ну формулируйте мысли лучше или иначе, а не разводите демагогию на пустом месте.
Я от него отворачиваюсь потому что до сих пор не понимаю какое отношение оно имеет к Вашим же первоначальным условиям. Не говоря про то, что вообще чем дальше, тем сложнее читать Ваши сообщения. Вздохните глубоко, напишите четко по пунктам, может тогда будет о чем предметно поговорить.
P.S. С вашей стороны уже было достаточно подлогов и попыток переврать что я говорю, поэтому с данного комментария я буду Вам давать максимум поисковые запросы, но не ссылки. Прекращу это делать когда будет несколько ответов мне с нормальным уровнем аргументации и без попыток разводить демагогию. Притом сразу предупреждаю - если прекратите пытаться приводить нормально аргументацию то я не буду видеть смысла в продолжении беседы в принципе, как по мне демагогия с вашей стороны очевидна, низкий технический уровень аргументации тоже (и замечу - это ровно то, в чем вы любите обвинять других людей в комментариях тут и там).
В каких? Я вот открыл два по запросу "Core i9 Hyperthreading Enabled Disabled" и увидел что разброс там такой что усредненные 30% не выходят вообще никак (а вот "до 30%" - легко, но у Вас "до" нету).
Не вижу логической связи с тем что я сказал.
Чистой воды демогогия с вашей стороны, потому что вы делаете за меня утверждения и с ними спорите.
Простите, демагогия в чистом виде у вас. Вы на ходу меняете условия, делаете за оппонента какие-то выводы, игнорируете неудобные вам вопросы (или части утверждений). Примерно то, в чем вы обычно обвиняете своих оппонентов.
Ок, если вы считаете что k - с разгоном, то о каком предметном споре может идти речь дальше? Я намекну что k значит разблокированный множитель, а вот разгон из коробки не включен нигде, потому что по мнению Intel'а он ведет к потере гарантии (как доказать это - оставим за скобками). Но на случай если я не прав я приму любую ссылку на сайт intel'а где будет сказано что k процессор - overclocked (а не unlocked).
Вы опять переобуваетесь на ходу, прочитайте ваши заявления изначальные, о которых мы ведем речь сейчас.
Но опять же я Вам уже сказал - в вашей постановке вопроса я беру 6 ядер на низкой частоте, 4 ядра на высокой и показываю что 4 практически всегда (если не всегда) быстрее.
Я Вам сказал что Вы попросту переобулись на ходу, в изначальном Вашем утверждении ничего такого не было. Но если заметите, я спорю как с изначальным утверждением, так и с переобутым (переобутое чуть ближе к истине, но не совсем).
Это не демагогия, потому что я не умею читать Ваши мысли. Я могу поговорить про Ваши высказывания, которые были как я их привел.
Любые Ваши переобувания по ходу спора - это какое-то странное действие (тем более недостаточно переобуваетесь), могли бы просто сказать "был не прав, в таком виде как я написал изначально - конечно ничего такого не будет" и закончить дискуссию на этом.
Касательно же выбора 10900k - Вашими изначальными аргументами такой выбор не запрещен (более того, формально можно взять и 11-ую серию).
Доказывать про "10900k бы бы производильнее" - не вижу смысла, потому что я подобных утверждений не делал. А докаживать Ваши мысли мне не интересно.
Что противоречит тому, на что вы ссылаетесь.
Опять приписывание мне вещей, которые я не говорил. Я не отрицаю прирост от HT, я утверждаю что он неоднородный и зависит от задачи, в том числе что есть класс задач где есть падение скорости от его включения. Я кажется это открытым текстом Вам говорю с самого начала.
Напомню Вам лишь то, что додумывать за оппонента - попадает под определение демагогии.
У меня дилемма. С одной стороны то что Вы написали - неверно и показывает непонимание что такое Spectre и Meltdown. С другой - хочется дать вам benefit of a doubt последний раз и сказать что упрощения которые вы делаете - недопустимы. Перестаньте упрощать и тогда Вам станет ясно почему Ваше объяснение является ложным.
Касательно методологии - вы первым начали ссылаться на Phoronix. Значит ли это, что когда Вы даете ссылку - это истина и методология корректна, а когда кто-то другой - она не верна?
В любом случаи, раз Вы ссылались, то должны знать что PTS - опенсорсный продукт, можете проверить что конкретно они делают в каких случаях.
И в конце концов, Вы всегда можете прочитать последние пару параграфов в статье, найти ссылку на описание тестовых систем, а также, раз Вы сами решили ссылаться на Phoronix, почитать как они делают тесты. Как по мне, вы сейчас пытаетесь найти хоть что-то чтобы сказать "ага, тесты неправомерны" и отмести результат, который Вам не нравится. Если так, то Вы просто можете просто прекратить дискуссию, а если хочется таки оставить последнее слово за собой, то напишите "Ваши тесты мне просто не нравятся, я верю в то что сказал". О вере я спорить не буду и от Вас отстану.
Вы так говорите, как будто МЦСТ тут вообще показательные. К тому же еще вопрос, точно ли вы правы про 20 человек и 200 и распределение задач? Откуда у вас инфа?
То есть если сделать armv8.2 (или rv64g, как удобнее) совместимый процессор, то на нем ничего не запустится и софт на него придется портировать? Расскажите почему так?
Хорошо, и что?
Нет, это именно что ваша логика. Вы взяли цифру из маркетинговой брошюры интела, которая звучала как "up to 30%" (первое место где 30% встречается если искать) и опустили "up to". По такой же логике я имею полное право найти один тест где HT проигрывает и сказать что "смотрите, он же медленее".
Я замечу, что вы продолжая гнуть свою линию занимаетесь обычной демагогией.
Минуточку, в целом на обычных компах выделяют категории по задачам и оценивают в среднем по ним (подходы несколько отличаются у разных обзорщиков). Усреднять яблоки с кирпичами допустимо только когда речь идет о производных характеристиках (например объем или вес ящиков с грузом), также и с задачами. Иначе у вас открывается просто непаханное поле для манипуляции данными - главное подобрать набор тестов так чтобы усреднение показало нужные результаты.
Это опять же чистой воды демагогия. Почему - см. объяснение выше.
Да, спасибо что указали на то что вы еще и переобувались на ходу. Изначально речи о "разницы между процом без предсказаний и с ними" не было. Я вам напомню фразу вашу же:
И отмечу что в ее написании речь не идет о "в рамках одного процессора с и без заплаток", а прямая трактовка это "начиная с какого-то момента времени весь прирост между поколениями был сожран заплатками". Из чего правильным тестом будет взять например i7-2600k (без заплаток) и i9-10900k (с заплатками) и сравнить, если будет разница в пользу 10900k, то ваше изначальное утверждение в корне неверно. Остальное вокруг - демагогия.
Кажется я вам наглядно показал что там нету 50%, а только 25 для старых процессоров и 5% для новых. Так что жду фразы "я был не прав" с вашей стороны.
Вы не оговаривали условия, значит допустимо взять 10900k и даже 11900k.
Глядите, увидите ту же самую картину в процентном соотношении. Значение имеет поколение процессора (какое количество аппаратный заплаток было).
Опять же, это лишь стандартная (изкоробочная) цена заплаток, по сравнению с загрузкой с
mitigations=offи не учитывает цену отключения SMT/HT из-за опасений касательно безопасности - на этом поприще, шедулеры (речь конкретно о https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/core-scheduling.html - что само по себе интересное чтиво) и другие инициативы по прежнему в разработке, особенно среди облачных провайдеров и владельцев датацентров.Но кстати хорошее замечание, потому что вы предполагаете что HT нужно отключать всегда и всем (не было укзааний на обратное), а если вчитаетесь в описание проблем то узнаете что далеко не всем это важно, и как вы сами предлагали, в общих задачах выключать его не нужно, что делает всю вашу логическую цепочку про "а как же HT?" бессмысленной. Good catch.
У вас учусь :) Но вообще я выше объяснил - есть величины которые допустимо усреднять с оговорками, есть которые недопустимо вообще никогда.
Давайте лучше уточним, точно ли вы понимаете о чем в статье идет речь? Предложите методику каким образом медленная память или не-PCIe SSD будет влиять на overhead от заплаток? Опишите вот прям механизм.
У меня опыт обратный, почти что ни имело смысл брать - все работало адекватно и местами давало нужное время чтобы сделать более правильное решение. Так что скорее зависит от области и конкретных задач.
Cython же, если я все еще правильно помню, это чуть ли не путь по-умолчанию для создания C-extention'ов для питона и тот же SciPy на нем (а еще все биндинги к сишным библиотекам, которые народ делал до рассвета cffi)? Так что если я помню правильно то было бы странно видеть проблемы в этом месте и было бы еще страннее заявлять наличие работающего питона если cython не работает.
Вы так говорите как будто Эльбрус не широкая команда. Перечитайте еще раз что конкретно написано, там банально исходя из правил русского языка негативно высказано и про Эльбрус в частности и про VLIW в целом. Если хотите с этим поспорить - говорите об этом с Бабаяном.
Внутреннего цикла, ценой разрастания внешнего. И как скомпилировал, так и прибьет гвоздями до следующей перекомпиляции.
В итоге можно попытаться костылями (там в общем из треда-то следует что это не ошибка компиляции, а осознанное взвешенное решение для общего случая) сделать лучше в тестовом примере, испортив жизнь во всех других случаях (так как, строго говоря, разрастется внешний цикл в разы). Поэтому выводы человек выше делает верные, просто Вы недочитали что говорили в тредике.
Только это уже не контекст (контекстом конкретной фразы является мнение про VLIW, суперскаляр выпадает из него, также как выпадают идеи куда двигаться дальше), но так да, он там рассказывает свое мнение. Конкретно важный в рамках всего спора вокруг МЦСТ момент в том, что Бабаян разочаровался в VLIW (как в реализации Эльбруса, так и в реализации Itanium).