Разработчики дистрибутива Debian предупредили (https://lists.debian.org/debian-devel/2017/06/msg00308.html) о выявлении проблем с работой режима Hyper-threading в процессорах Intel, построенных на базе микроархитектур "Skylake" и "Kaby Lake", которые выражаются в непредсказуемом поведении системы (например, крах приложения или повреждение данных). Проблема проявляется в 6 и 7 поколении процессоров Intel Core для настольных, встраиваемых и мобильных систем, в серверных процессорах Xeon 5 и Xeon 6, а также в некоторых моделях, выпускаемых под брендом Intel Pentium.
Проблема выявлена разработчиками инструментария OCaml, которые столкнулись с крахами при работе компилятора OCaml, собранного при помощи GCC. Первые упоминания проблемы отмечаются начиная со второго квартала 2016 года. В ходе разбирательства стало ясно, что проблема проявляется только на некоторых процессорах Intel со включенным режимом Hyper-threading. Дальнейшее исследование условий возникновения крахов показало, что проблема вызвана некорректной обработкой определённой последовательности инструкций и вызвана дефектом процессоров Intel Skylake и Kaby Lake.
В частности, проблема проявляется, когда выполняются короткие циклы, включающие менее 64 машинных инструкций, использующих регистры AH, BH, CH или DH, а также их более длинные варианты (RAX, EAX и AX для AH, RBX, EBX и BX для BH и т.п.), при условии, что активны оба логических процессорах на том же физическом процессоре. Разработчики связались с компанией Intel, но не получили вразумительного ответа, при этом спустя несколько месяцев в списке изменений в очередном обновлении микрокода было замечено упоминание исправления, которое решало проблему в OCaml. После этого разработчики
OCaml связались с сопровождающими пакет intel-microcode в Debian и поделились своей информацией.
Пользователям Debian c процессорами Intel Skylake (model 78 или 94 со stepping = 3) рекомендуется как можно скорее установить пакет intel-microcode с обновлением микрокода (версия 3.20170511.1), доступный в репозитории non-free для веток unstable, testing, Debian 9 "stretch" и Debian 8 (jessie-backports). Для остальных моделей Intel Skylake и CPU Kaby Lake исправление через intel-microcode пока недоступно, поэтому им рекомендуется отключить режим работы Hyper-threading в BIOS/UEFI или установить обновление прошивки BIOS/UEFI от производителя оборудования, если оно уже выпущено (Intel erratа SKW144, SKL150, SKX150, SKZ7, KBL095, KBW095). Проблема не специфична для Debian и проявляется в любых других ОС.Для определения подвержена ли система проблеме следует выполнить
"grep name /proc/cpuinfo | sort -u" и сверить модель процессора со списками кодовых номеров процессоров Skylake (http://ark.intel.com/products/codename/37572/Skylake) и Kaby-Lake (http://ark.intel.com/products/codename/82879/Kaby-Lake), а также проверить наличие поддержки Hyper-threading (флаг "ht" в /proc/cpuinfo).$ grep -E 'model|stepping' /proc/cpuinfo | sort -u
model : 26
model name : Intel(R) Xeon(R) CPU E5530 @ 2.40GHz
stepping : 5$ grep -q '^flags.*[[:space:]]ht[[:space:]]' /proc/cpuinfo && echo "Hyper-threading is supported"
Hyper-threading is supported
URL: https://news.ycombinator.com/item?id=14630183
Новость: http://www.opennet.dev/opennews/art.shtml?num=46762
Оппа! Вовремя. А то я хотел переходить i9 за 2 кило "бакинских коммисаров"
Это тот который с соплями под крышкой? Который не может на заявленной частоте пройти тесты с AVX-512 инструкциями из-за температуры упирающейся в 99 °C?) Нафиг он вам?)
а чё уже тесты есть?
Ага, купить проц за 1-2 килодоллара, чтобы затем сидеть и не знать, как его охладить. Ни одна система охлаждения не поможет ЭТО постоянно адекватно охлаждать, т.к. тепло просто не доходит до крышки в достаточном объёме из-за долбаной термопасты.Интел совсем вкрай охренел. Ладно пользовательские процы с г-термопастой под крышкой (мол, не разгоняй) - это ещё понятное сегментирование, но уж специально предназначенные для разгона и HEDT-процы без припоя - это _просто_ абзац. Когда люди заменяют пасту на жидкий металл, то получают -20 -25 и более градусов.
P.S. ни разу не АМД-фан, сам сижу на i5-2500K, который *с* припоем под крышкой и при 4.5 ГГц температуры пристойные.
Паста под крышкой меняется на ЖМ на раз-два. Ну или заплатить тому, кто может это сделать на раз-два.P.S. Это, естественно, не отменяет того, что интел — уроды.
В свете новости, совет не слишком разумный: завтра обновлением микрокодов дело может не обойтись, а с заменой камня могут быть проблемы из-за слета гарантии после снятия крышки
> В свете новости, совет не слишком разумный: завтра обновлением микрокодов дело может
> не обойтись, а с заменой камня могут быть проблемы из-за слета
> гарантии после снятия крышки(пожав плечами) Вскрытие процессора вне зависимости от качества камня влечёт потерю гарантии, так что совет если и неразумный, то никак не в свете новости. Совет противоречивый, но не неразумный, потому что если есть возможность охладить камень на 20-30 градусов, получить возможность разгона и, следственно, большей постоянной производительности и рискнуть его ценой, то на второй чаше весов — только цена камня и уверенность в прямоте рук. Без всякого света от новости.
Да, можно заказать комплект делиддинга, но:
1. риск поломки пусть и крохотный, но есть. помял текстолит и до свидания.
2. как упомянули уже, гарантия тоже говорит "До свидания".
3. заниматься всем, описанным выше, покупая камень "премиум-сегмента" (а к нему и дорогую матплату, кстати) как-то неправильно.Покупая, например, часы Breitling или Omega абсурдно было бы лезть туда с отвёрткой, чтобы "подтянуть болтик - всего и делов" :-)
Вещи такой ценовой категории (а 1-2К долларов - это уже на некоторые пафосные часы хватит, наверное, не знаю цен точных) не должны допиливаться напильниками в принципе.
>3. заниматься всем, описанным выше, покупая камень "премиум-сегмента" (а к нему и дорогую матплату, кстати) как-то неправильно.Наоборот
>Вещи такой ценовой категории (а 1-2К долларов - это уже на некоторые пафосные часы хватит, наверное, не знаю цен точных) не должны допиливаться напильниками в принципе.
Это если сделаны нормально
>>Вещи такой ценовой категории (а 1-2К долларов - это уже на некоторые пафосные часы хватит, наверное, не знаю цен точных) не должны допиливаться напильниками в принципе.
> Это если сделаны нормальноВот поддержу, кстати.
Продам Москвич 2141. Раритет. Отвертка и фотболка "лего отдыхает" в подарок.
Лям грина. Копейки для такого премиума.
> Это если сделаны нормальноВы полагаете, что за указанную сумму должно идти кривое гуано, требующее обязательного вмешательства?
Я ничего не полагаю, просто смотрю правде в глаза.
Ну да. Если посмотреть правде в глаза, то брать гуанинтел за такие деньги сейчас смысла нет. Ryzen или TR (последний - для желающих ещё и обогревать квартиру компом) вполне себе годятся.
> Да, можно заказать комплект делиддинга, но:
> 1. риск поломки пусть и крохотный, но есть. помял текстолит и до
> свидания.Да, есть такой риск. Сдуру и МПХ сломать можно.
> 2. как упомянули уже, гарантия тоже говорит "До свидания".
Да.
> 3. заниматься всем, описанным выше, покупая камень "премиум-сегмента" (а к нему и
> дорогую матплату, кстати) как-то неправильно.Это выход из ситуации. Понимаете? Интел — козлы, делают хороший камень под плохим термоинтерфейсом. Выход? Покупать у них более дорогую платформу — 2011, например, и кормить их (косвенно) дальше или попробовать выжать больше из того, что есть. Всего лишь вопрос выбора. Тут не «правильно-неправильно», а скорее «могу — не могу», я бы так расценил.
> Покупая, например, часы Breitling или Omega абсурдно было бы лезть туда с
> отвёрткой, чтобы "подтянуть болтик - всего и делов" :-)Это статусный товар, а не рабочая лошадка. Сравнение мне кажется несколько некорректным. Среди любителей каких-то работающих вещей как раз много людей с руками, которые не чураются подтянуть, подкрутить и подстроить, и никто это зазорным не считает. С другой стороны, позиция «взял дорого и требую сервис» тоже имеет право на существование, только я что-то не видел демонстраций против хренового термоинтерфейса — скорее треды на форумах с рецептами переделки.
> Вещи такой ценовой категории (а 1-2К долларов - это уже на некоторые
> пафосные часы хватит, наверное, не знаю цен точных) не должны допиливаться
> напильниками в принципе.Не должны. Но допиливаются же?
ЗЫЖ Вы удивитесь, сколько вещей премиум-сегмента в таком ценовом диапазоне требуют допиливания и приколачивания — именно потому, что производство не массовое и, как ни странно, ручной труд уступает технологическому массовому производству в отношении качества к цене.
Можно просто подождать, пока "более дорогая платформа" станет дешевле, а это недоразумение уйдёт в историю. По идее - не слишком долго. В большинстве случаев подождать можно себе позволить - реальная необходимость апгрейдиться на такие штуки - это скорее исключение, чем правило.
> Можно просто подождать, пока "более дорогая платформа" станет дешевле, а это недоразумение
> уйдёт в историю. По идее - не слишком долго. В большинстве
> случаев подождать можно себе позволить - реальная необходимость апгрейдиться на такие
> штуки - это скорее исключение, чем правило.Дык я ж не против. Чаще ситуция такая, что хочется/нужно прямо сейчас. Говорю же — процесс выбора и компромиссов. Я топовые интеловские камни вообще никогда не рассматривал как цель, так, чисто про термопасту сказал.
> Можно просто подождатьЖдать придется очень долго, ибо у Интела просто нет причин возвращать припой. Вот вместо припоя ставить термопасту причины есть: дешевле, раннее устаревание камня, для рабочих температур в стоке хватает. Массовый разгон Интелу нафиг не нужен, а профессиональные оверклокеры не обломаются снять крышку. Недаром в новом поколении HEDT припой убрали, несмотря на "премиум продукт".
Да наплевать на разгон. Как только понадобится отводить тепло для штатного режима - вернут, куда они денутся. Особенно если "Который не может на заявленной частоте пройти тесты с AVX-512 инструкциями из-за температуры упирающейся в 99 °C". Например, если AMD выкатит приличного конкурента по быстродействию.А нештатные режимы - в пень в любом случае.
> Да наплевать на разгон. Как только понадобится отводить тепло для штатного режима
> - вернут, куда они денутся. Особенно если "Который не может на
> заявленной частоте пройти тесты с AVX-512 инструкциями из-за температуры упирающейся в
> 99 °C". Например, если AMD выкатит приличного конкурента по быстродействию.Штатный режим задает Интел, и уже много лет этот режим определяется TDP (во всяком случае, для массового продукта). Если не влезет по тепловыделению - зарежут частоты, HT и ядра. AVX2 работает на сниженной частоте (это описано в документации, ссылку сейчас не найду), не удивительно, что AVX-512 будет работать на еще более низкой частоте. Те частоты, которые вы видите в маркетинговых брошюрах и прайс-листах, это не более чем ориентир, а не гарантия.
> Те частоты, которые
> вы видите в маркетинговых брошюрах и прайс-листах, это не более чем
> ориентир, а не гарантия.Можно я буду использовать ваш эвфемизм "ориентир" к неблагозвучному термину "традиционное н@#&алово"? Спасибо.
Называйте как хотите, но от реалий не уйдешь. Производительность, энергопотребление/тепловыделение, цена - выберите два.
Вывод из всего этого - производительности хватает. Не хватало бы - были бы серии с увеличенным TDP, не у интела - так у AMD (хотя не знаю, как там с зеонами/оптеронами - может и есть). Тем меньше причин играться в разгон, тем более на топовых процах. Ради интереса разве что.
> Вывод из всего этого - производительности хватает. Не хватало бы - были
> бы серии с увеличенным TDPТак они и есть - вся серия Core i9 к вашим услугам. А раз вам разгон не нужен, то хватит и жвачки под крышкой.
> только я что-то не видел демонстраций против хренового термоинтерфейсаВот странно, кстати. Наверняка же должно помочь.
Покрышки жечь перед офисом Интела? xD
Гипетртединг отключи и переходи
Проверять HT командой grep -q '^flags.*[[:space:]]ht[[:space:]]' /proc/cpuinfo && echo "Hyper-threading is supported" неправильно. У меня i5 и типа HT есть, ага.Вот команда для проверки: egrep 'siblings|cpu cores' /proc/cpuinfo | head -2
Если значения совпадаю, HT не активно.
Да, верно, та команда в статье вводит в заблуждение. Да и на сайте Intel явно говорится, что i5 HT не поддерживает.
https://ark.intel.com/ru/products/43546/Intel-Core-i5-650-Pr... например
Ещё что древнее предложи.
Дружок, у тебя проблемы с логикой.Давность выпуска процессора i5 никак не влияет
на его вхождение во множество "все процессоры i5".Но ты не стесняйся, доказывай обратное, клоуны тоже нужны стране.
> i5 HT не поддерживает.Ноутбучные поддерживают.
А проблема в чем, в какой-то версии ядра или сугубо в железе?
Сугубо в проце, но последний микрокод исправляет косяки (покамис не всех процессоров)
Пока... Что??
Мис.
мисс - с двумя сс пишется, грамотеи...
А при чём тут мисс?
При том, что "пока не миссис"
Американсский шпиён чтоли?
> Сугубо в проце, но последний микрокод исправляет косяки (покамис не всех процессоров)покамест же
Микрокоды можно обновить в прошивке UEFI самостоятельно c помощью UBU:https://forums.overclockers.ru/viewtopic.php?f=25&t=479847
в шапке топика ссылка на последнюю версию скрипта + обновление (распаковать в папку со скриптом с заменой файлов)кроме того, придётся нагуглить MMTool 5.0.0.7, поскольку из-за претензий со стороны компании AMI он не прилагается
закинуть файл с прошивкой в папку со скриптом и запустить скрипт, дальше всё интуитивно понятно (остальные OROM-ы можно не трогать, достаточно микрокод)
а зачем такие сложности то? ядро и само умеет микрокод загружать — https://wiki.archlinux.org/index.php/Microcode_(%D0...)
тем более что в этом случае микрокод обновляется что называется "из портов".
кстати хорошо что затронули эту тему ("Archlinux и микрокод").напомню что Archlinux умеет корректно обновлять только микрокод для Intel-процессоров..
а вот AMD-процессоры в случае с Archlinux -- сосут лапу тихонько в сторонке.
а точнее -- для процессоров-AMD в Archlinux -- обновление микрокодов происходит в момент когда уже поздно -- когда загрузка компьютера уже практически полностью прошла (то бишь прошла НЕкорректно, так как все модули/драйвера инициализировались через неисправный вариант работы процессора. и даже когда уже успел инициироваться pid-0, разумеется также некорректно).
так что фанбои-AMD в этой теме -- тихонько краснеют
Че краснеть - у гавенного интела эрраты всегда мерялись многими сотнями страниц. Обновление микрокода от процессора не зависит, так как применяется один и тот же пакет - погуглил бы прежде чем позориться. обновление что при загрузке что до загрузки - до одного места. особенно если стоит глючный интель. у них там из-за багов уже давно не работает пол-проца - если нашли баг в под-системе, то первым делом ее выключают. нет подсистемы, нет проблем, бу-га-га..
> Обновление микрокода от процессора не зависит, так как применяется один и тот же пакет - погуглил бы прежде чем позоритьсяды ты может не в курсах просто?
нет такого пакета в archlinux.
есть пакет intel-ucode -- с микрокодами персонально для Интела.
и пакет linux-firmware -- который содержит различные прошивки и в том числе микрокоды AMD, которые заставляют AMD обновляться НЕ ВОВРЕМЯ..
где этот твой "один и тот же пакет", который от процессора не зависит?
> есть пакет intel-ucode -- с микрокодами персонально для Интела.Это случайно не тот, который ещё пару лет тому устарел и был на что-то другое заменён? (ну и да, логика "арчик ни при чём, это всё AMD" всё такая же детская)
> Это случайно не тот, который ещё пару лет тому устарел и был на что-то другое заменён?не понимаю о чём. врядли.
пару лет назад было только это -- https://www.archlinux.org/news/changes-to-intel-microcodeupd.../
> логика "арчик ни при чём, это всё AMD" всё такая же детская
Арчик он НЕ сам по себе -- Арчик это сообщество заинтересованных активистов.
ну и собственно вопрос -- где вы активисты и фанаты AMD?
1. вас не сущетвует? [врядли]
2. вы есть, но именно среди Archlinux вас нет? [врядли]
3. вы есть и даже есть среди Archlinux. но вы не можете увидить что у вас операционная система -- некорректно эксплуатирует ваш AMD-процессор? [я думаю что именно этот вариант: работает хоть-как-то и пофигу]
> Арчик это сообщество заинтересованных активистов.О, можно я буду использовать ваш термин "сообщество заинтересованных активистов" как эвфемизм к неблагозвучному и нецензурному (на опеннете) слову "школота"? Спасибо.
>> Арчик
> "школота"В догонку: https://bugs.archlinux.org/task/45657
Ты хочешь сказать, что инитрамфс в Арче не умеет в early microcode? Это арчеводы тогда краснеть должны, а не фанбои AMD.
> Ты хочешь сказать, что инитрамфс в Арче не умеет в early microcode?если подготовишь правильный initramfs , то наверняка ядро обновит микрокод (как это следует)... надо смотреть с какими флагами собрано ядро (при случае -- пересобрать с нужными флагами).
...но archlinux всеми силами будет тебе палки в колёса ставить -- чтобы сделать корректный initramfs для AMD у тебя либо не вышло вовсе, либо с офигеть какого маштабами костылями.
> Это арчеводы тогда краснеть должны, а не фанбои AMD.
ну а чтож -- не нашлось арчеводов среди файбоев AMD? почему они не пролабировали свои интересы? или может вовсе они даже и не поняли в каком месте их обманули для случая загрузки AMD на archlinux?
> Ты хочешь сказать, что инитрамфс в Арче не умеет в early microcode?
> Это арчеводы тогда краснеть должны, а не фанбои AMD.ты щас серьёзно? да у АМУДЕ их чудо 64битный процессоры не могли обновить микрокод из 64битного режыма годами!
> спустя несколько месяцев в списке изменений в очередном обновлении микрокода от Intel было замечено упоминание исправления, которое решало проблему в OCamlЭто что за обновления микрокода процессора? Как давно процессоры стали программируемыми?
С разморозкой, уже не первый десяток лет процессоры поддерживают обновление микрокода
Так это что получается, современные процессоры - это интерпретаторы?
какие нафиг современные
"в конце концов из конца в конец" зайди в вику и прочти
https://ru.wikipedia.org/wiki/%D0%9C%D0%...
пп "Причины появления и использования"
предложено было в 1953, реализовано в 1970х
Почитал, спасибо. У меня сложилось впечатление что меня снова обманули. Это даже "не просто резиновые женщины - это китайские резиновые из китайской резины. Печаль :(
Вообще любой процессор -- это интерпретатор. В простейшем варианте -- это декодер команд, который инициирует какие-то блоки, типа сумматоров, мультипликаторов, и прочих. Причём иногда это выливается в последовательности действий, типа загрузить значение из памяти на вход сумматора, после чего считать значение с выхода и записать в память. А, ещё флаги надо не забыть расставить в соответствии с.Но фишка ведь в том, что если есть последовательность действий, то можно организовать конвеер, то есть начинать выполнять следующую команду до того, как завершится предыдущая. Пока выполнение предыдущей команды возиться с сумматором, можно извлекать из памяти данные для следующей команды. И параллельно вычитывать из памяти третью команду, чтобы потом не тратить на это время. При этом, ведь, подчастую команда машинного кода в памяти, требует обширного препроцессинга, прежде чем её можно будет взять и выполнить. Скажем, команда которая добавляет к 64-битному регистру 8-битное значение -- это восьмибитное значение надо расширить до 64 бит, прежде чем загружать в сумматор. Это несложно -- надо же просто нулями забить 56 бит, но тем не менее это тоже требует времени, а процессорные такты не стоят на месте, убегают.
А некоторые команды можно выполнять параллельно, поэтому на один поток команд можно завести несколько конвееров.
И вот тут как раз, напрашивается появления всех этих микроопераций. Они простые, их не так много как в сложном CISC наборе команд x86, можно иметь много блоков для их выполняния и, скажем, выполнять параллельно сразу много сложений в рамках одновременно выполнения разных команд требующих сложения -- типа add, sub, inc, push, jmp... Не надо заводить отдельный сумматор на каждую возможную инструкцию CISC кода, в процессе выполнения которой надо складывать. Отдельных сумматоров, которые чаще будут простаивать, чем работать. Можно иметь один-два сумматора общего назначения на каждый конвеер, и этого вполне хватит.
Писать же в оперативку микрокод -- это себе дороже, потому что там запросто может выйти, что каждая инструкция будет занимать 128 бит или может в разы больше -- я не знаю, -- и код распухнет до невозможности. В процессоре и так кеш на кеше и кешом погоняет, но там будет ещё хуже.
https://books.google.ru/books?id=jKOsdJ8Rk6EC&pg=PA25&#v=one...
https://books.google.ru/books?id=Q1zSIarI8xoC&pg=PA72&dq=mic...
Скорее всего после вот этого бага:
https://en.wikipedia.org/wiki/Pentium_FDIV_bug
Но могу ошибаться, давно читал Архитектуру ЭВМ Таненбаума. Суть: был баг, из-за которого Intel потерпела огромные убытки на заменах процессора. После этого появился микрокод и процессоры уже давно программируемые. Т.е. при старте ОС может загрузить в процессор микрокод определённой версии. Именно так сейчас исправляются ошибки в процессорах (и не только).
'''
Первоначально микрокод был использован в качестве более лёгкого способа разработки контролирующего устройства процессора. Прежде набор инструкций задавался жёстко, каждая машинная инструкция (сложение, сдвиг, копирование) реализовывалась непосредственно в схеме. Это давало высокую скорость, но по мере того, как набор инструкций рос, всё сложнее становилось реализовать в виде схемы и отладить инструкции всё возрастающей сложности. Микрокод смягчил эту проблему тем, что позволил инженерам-проектировщикам при реализации сложной инструкции заменить создание сложной схемы на написание микропрограммы. Более того, микрокод можно было с лёгкостью изменить на поздних этапах проектирования, схему же изменить намного сложнее. Таким образом, микрокод облегчил проектирование процессоров, что привело к усложнению набора команд.
'''
Да, это понятно. Но как оно работает внутри? Получается что в процессоре есть своя память, есть некоторый реализованный аппаратно примитивный набор операции, а все что сложнее - это результат работы "процессора в процессоре" ?
В процессоре давно есть своя собственная память. Называется кэшем и работает с частотой процессора, из-за чего является очень дорогостоящей и по этой причине её в процессоре достаточно мало.Нашёл более менее понятный пример микрокода (у АМД) в качестве примера (команда MOVS):
https://www.dcddcc.com/docs/2014_paper_microcode.pdfListing 1: Implementation for MOVS in AMD processors
LDDF ;load direction flag to latch in functional unit OR ecx, ecx ;test if ECX is zero
JZ end ;terminate string move if ECX is zero loop :
MOVFM+ tmp0, [ esi ] ;move to tmp data from source and inc/dec ESI MOVTM+ [ edi ] , tmp0 ;move the data to destination and inc/dec EDI
DECXJNZ loop ;dec ECX and repeat until zero end :
EXIT
Это не то. Это написали логику работы команды MOVS на асме.Пример есть на вики:
Подсоединить Регистр 1 ко входу «А» арифметическо-логического устройства (АЛУ)
Подсоединить Регистр 7 ко входу «Б» АЛУ
Настроить АЛУ на выполнение операции сложения
Установить разряд переноса АЛУ в ноль
Сохранить результат операции в Регистр 8
Обновить «коды состояния» из флагов АЛУ
Установить указатель микрокоманд на микроинструкцию номер nnn
Могли бы зайти и почитать. Там чёрным по белому написано, что это реализация MOVS в микрокоде.Понятное дело, что это ассемблер, но ассемблер адаптированный для микрокода. Обычными компиляторами его не скомпилируешь, а производители никогда свои компиляторы микрокода не покажут (код закрытый). А даже если удастся скомпилировать, то на пути будет загрузка по цифровой подписи (делает невозможным загрузку неофициального микрокода).
Если непонятно, почему ассемблерная команда реализовывалась через микрокод, могу объяснить. Если для каждой команды выделять своё исполнительное устройство, то разработка и отладка сильно усложняются (код писать легче, чем проектировать кристалл), а последующие ошибки в исполнительных блоках может быть сложно исправить через микрокод (либо будет значительная потеря производительности на отдельных командах). Поэтому идёт максимальная унификация исполнительных блоков для использования в различных командах. А исправление ошибок достаточно просто будет сделать через тот же микрокод.
Ты так и не понял что такое микрокод.
До. Как раз хвастались, что теперь можем править баги в проце на лету. :)
Ну и первый же баг, ставший широко известным, не смог быть поправлен микрокодом. :)
> Ну и первый же баг, ставший широко известным, не смог быть поправлен микрокодом. :)Не наоборот ли? Первый же баг, который не смог быть поправлен микрокодом, стал широко известным? :)
два чая и плюсик этому господину!
Если совсем в первом приближении и на пальцах для первоклассника: современные CISC-процессоры семейства intel*86 на самом деле RISC внутри, а интерпретацией CISC-команд и их конвейеризацией занимается микрокод.
Да откуда ж вы такие знатоки лезете-то ?
Хоть бы почитали когда процессоры с микропрограммным управлением появились.
Речь о конкретном семействе x86, какая разница, где что появилось, когда еще Сталин был жив?Я ж говорю - на пальцах, в первом приближении. Домохозяйке достаточно. А интересующиеся более глубоко могут ознакомиться, для начала, c Intel Software Developer's Manual, и далее, например, с The microarchitecture of Intel, AMD and VIA CPUs [1].
Раньше мне попадалось определение как RISC/CISC архитектура и на давно уже не современных процессорах. Вот нашел по теме http://userpages.umbc.edu/~vijay/mashey.on.risc.html
Весело, а у меня инженерный семпл, обновление микрокодов для которого застряло ещё в 2014...
Я обновлял микрокод по сети и меня часть tcp-пакетов потерялись. Ползунок на прогрессбаре застрял в 2014 году, ждем tcp-пакеты.
Потруси ось пространства-времени. Может отклинит. У меня такое было, так я в 2005 году 2 года жил.
бажные они какие то, вот еще
"Ошибка процессора Intel Skylake приводит к зависанию компьютера во время сложных вычислений"
https://habrahabr.ru/company/pt/blog/274939/
'''
В сообщении компании никак не объясняются причины возникновения проблемы, однако подтверждается тот факт, что ей подвержены как Linux, так и Windows-системы.
'''
Обычно причины простые. Продукт выпускается сырой, чтобы быстрее начать получать с него прибыль и занять определённый сектор рынка раньше конкурентов. Тестирование - это иногда затраты и упущенная выгода.
упущенная выгода также может быть от того, что новый продукт будет каждый раз сырой и люди просто уйдут к др фирме где "стабильное гогно мамонта" но стабильное =)
>люди просто уйдут к др фирмВы верно уловили суть проблемы.
Уходить особо некуда. AMD, по большому счёту, ничем не лучше Intel-а, а больше игроков на x86-рынке не осталось. Другие архитектуры для десктопов и серверов были тщательно -----завинчены в мозг клоунов, которые запретили использовать половину русского языка на сайте-- , вот сейчас arm потихоньку набирают популярность, лет через 10, возможно, arm-процы смогут выполнять большую часть задач, ныне выполняемых на x86 (собственно, сейчас всё упирается в более низкую производительность, да в отстствие портов всевозможной проприетарщины), сейчас пока как частичная замена годятся. Вот только я б не ждал улучшения качества продуктов: есть и Qualcomm, и Samsung-овский Exynos, Allwinner, Broadcom. И я б не сказал, что среди них есть менее "сырые", чем последние Интелы.
>cобственно, сейчас всё упирается в более низкую производительностьТак в нее родимую все и упиралось. Да, кастрат может меньше есть, но как производитель он не очень. :)
Архитектура POWER тоже кастрат, но производительность не хуже Xeon'ов. Хуже то, что он дороже.
>>cобственно, сейчас всё упирается в более низкую производительность
> Так в нее родимую все и упиралось.Ещё в неё же на ватт.
> уйдут к др фирме где "стабильное гогно мамонта" но стабильное =)Как показывает практика, будут кушать кактус.
никогда не нравился этот НТ. прибавку в проихводительности он давал незначительную, а вот энергопотребление(нагрев) росло прилично.
Изначально он появился, когда Intel проигрывал AMD в борьбе за 1 место.В 1999 был выпущен AMD Athlon, который "уделывал" не только Pentium 2, но и ещё не вышедший Pentium 3. Интелы, стоит отдать им должное, не стали ничего менять в самый последний момент, и выпустили процессор "как есть". Но потом они выпустили Pentium 4, что было очень серьёзной ошибкой. Да, сиюминутная победа была одержана, но в долгосрочной перспективе...
Потом в 2003 был AMD64, вторая громкая победа AMD. Потом, в 2005, Athlon X2. И вот как раз на последнее был и выпущен в ответ Hyper Threading: "да, у нас по-прежнему одно ядро. Но мы сделали офигенную технологию, увеличивающую производительность от 10% до 25% засчёт того, что ядро прикидывается двумя!" Это было дно.
А в 2006 Intel взяла Pentium 3 и вдруг увидела, что потенциал технологии не был раскрыт и близко. Тогда как ядро Prescott изначально было выпущено без потенциала для дальнейшего развития, так как выпускалось в страшнейней спешке.
И поняла тогда Intel, почему сначала тратила в два раза больше денег, чем нужно, потом в три. И выпустила core2 на базе P3. Перенесла туда SSE2 и EM64T, а ещё технологию энергосбережения (изначально появившуюся в P4 потому что печ, разогревающаяся до 80° за секунды).
И поняла AMD, что проиграла, и приобрела компанию ATi, которая кормит из по сей день. Потом была удачная серия процессоров Phenom и Athlon II, но на это ушли последние деньги. Потом последовал Athlon FX, основным изменением в которой стал... гипертрединг! И тогда уже AMD бросилась убеждать весь мир, что гипертрединг реально увеличивает производительность, и что приложения уже давно многопоточные, тогда как во времена первого гипертрединга в основном были однопоточные - но никто уже не слушал.
> В 1999 был выпущен AMD AthlonВ 99 был провальный K6-III. Это был печальный год для AMD, K6-III на фоне intel смотрелся как последние пару лет FX.
> В 99 был провальный K6-III. Это был печальный год для AMD, K6-III
> на фоне intel смотрелся как последние пару лет FX.Но он работал на уже имеющихся платах и позволял увеличить производительность не очень задорого
> И выпустила core2 на базе P3.В твоей истории куда-то пропали Pentium M и Core (который был до Core 2).
Да, так и есть. Когда решили откатываться с P4 на P3, то взяли последний ноутбучный P3, а не десктопный или серверный. Потому что последняя модификация P3 была именно для ноутбуков.
да никто не откатывался "с P4 на P3" - просто P4 не пошел в ноуты, а в это время открыли новое подразделение в Хайфе и там уже сделали P*-М. Это выглядело неплохо, и им дали кард-бланш на core (как раз маркетологи решили убить марку P*) - тоже получилось.И тут стало ясно, что американскую команду P4 «питекантропы» надо разогнать :)))))))
о да, давайте теперь поклоняться глючному кор2 сколоченному наспех только из-за того что там 32битные игрульки "летали"
если бы там о каждом баге создавали по такой же новости, то опеннета не хватилобы
зато игрунов хлебом не корми - все знают о TLB баге у АМД
а печки Pentium D?
>> И выпустила core2 на базе P3.
> В твоей истории куда-то пропали Pentium M и Core (который был до
> Core 2).Да там вся "история": пересказы от прабабушки - дедушке, от дедушки - тётё, от тёти - трёхуродному брату и т.д.
Что-то не сходится про "Потом, в 2005, Athlon X2. И вот как раз на последнее был и выпущен в ответ Hyper Threading" : HTT появился в процессорах Intel Xeon в феврале 2002 и в ноябре 2002 добавленной в процессоры Pentium 4, это раз и "Потом последовал Athlon FX, основным изменением в которой стал... гипертрединг! " - Не гипертрединг а HyperTransport, и ничего общего с гипертрединг не имеет. А вот в ryzen появился аналог гипертрединг.
Почитал про Pentium M. Ты прав. В прошлом источнике утверждалось, что Pentium M прекратил существовать на несколько месяцев позже Pentium 3. А оказалось что он существовал параллельно P4 всё это время!Гипер-транспорт это немного не то. Это системная шина, ответ FSB от Intel, и появился в 2003. А в Athlon FX 2011 года появились "модули", когда на схеме проца явно видно 4 физических ядра, а BIOS пишет что их 8. "Но это не гипертрединг, это другое!", - уверяли нас маркетологи AMD.
"В прошоом источнике" = "В прошлом источнике, который я читал" быстрофикс
Физичеси ядра там отдельные, но используют один кеш. Так что это совсем не HTT
> Физичеси ядра там отдельные, но используют один кеш... и один FPU
А самое ужасное, из-за чего они и тормозили, - ОДИН ДЕКОДЕР ИНСТРУКЦИЙ!!!!Видимо инженеры AMD думали, что он один сможет прокормить L1 кэш микрокода обеих модулей, и похоже сильно прогадали.
Очевидно, что на бенчмарках, когда загружается небольшой кусок кода и гоняется в цикле, у него получалось. Но, как всегда, где бенчмарки, и где реальные приложения.
> "Потом последовал Athlon FX, основным изменением в которой стал... гипертрединг! " -
> Не гипертрединг а HyperTransportОн как бы ещё не в первых слотовых Athlon появился (неохота сверять, пусть лучше настоящие железячники напомнят -- заодно и про дековскую EV6).
> Изначально он появился, когда Intel проигрывал AMD в борьбе за 1 место.
> И поняла AMD, что проиграла, и приобрела компанию ATi, которая кормит из
> по сей день. Потом была удачная серия процессоров Phenom и AthlonВряд ли AMD проиграла - интел платит ей лицензионные отчисления за каждый проц, так как там используется набор инструкций amd64 - ведь интел эпично обоср#лся в свое время с итаниум и его гавенной системой команд. Вообще тот факт, что интел знатно похоронил S3 и то, что AMD сделала из ATI наводит меня на мысль, что интел начинает походить на мокрософт:
"В чем разница между микрософтом и царем Мидасом? Ответ: у царя все, к чему он прикасался, превращалось в золото, а у микрософта в гав#о.."
Кто бы там эпично не сра_лся, грелся и параллелился, но закон Мура соблюдался всегда. Так что: "сабаки лают, караван идет".
В современных условиях закон Мура наиболее точно формулируется как "со временем производительность процессоров растет".
Кол-во транзисторов же
> интел эпично обоср#лся в свое время с итаниум и его гавенной системой командВообще-то это пролёт не intel, а wintel -- на не-x86 винде были большие проблемы в т.ч. с архитектурнозависимыми драйверами печати, например, не считая "просто" приложений.
Ну и как бы не по Сеньке шапка, бывает.
Какой к черту гипертрейдинг, про архитектуру бульдозера почитай что ли
> В 1999 был выпущен AMD Athlon, который "уделывал" не только Pentium 2,
> но и ещё не вышедший Pentium 3. Интелы, стоит отдать им
> должное, не стали ничего менять в самый последний момент, и выпустили
> процессор "как есть". Но потом они выпустили Pentium 4, что было
> очень серьёзной ошибкой.Притом чисто маркетинговой -- держалось это недоразумение по большей части на условиях пропихивания "intel inside", насколько понимаю.
> И вот как раз на последнее был и выпущен в ответ Hyper Threading [...] Это было дно.
Угу, "гипербрединг".
> А в 2006 Intel взяла Pentium 3 и вдруг увидела, что потенциал
> технологии не был раскрыт и близко [...] И выпустила core2 на базе P3.Насколько помню, сперва израильское подразделение выпустило Pentium M -- надо отдать им должное, хоть у кого-то голова оказалась из нужного места и наглости хватило отодвинуть макетоидов в совсем плохом смысле слова.
А потом были "кукурузные" ядра от AMD и новые процессоры, каждый из которых был хуже предыдущего. По специфике работы знаю, как народ покупал себе "новые" AMD процы, а потом истерил что у них новые игрушки тормозят.Ну то есть AMD почти повторила историю Intel с Pentium 4, а теперь вот снова "очухалась" и вернулась к нормальной архитектуре.
Нет в FX SMT. Там пары честных целочисленных ядер, а вот модулей FPU - по одному на два ядра.
Зато SMT есть в райзенах.
Ну, я думаю, Интелу нужно потратить ещё 300 миллионов долларов на расовую диверсификацию в компании.
> Ну, я думаю, Интелу нужно потратить ещё 300 миллионов долларов на расовую
> диверсификацию в компании.Этого не достаточно. Пора стрейт уайт мэнов приносить в жертву на площади перед градоправлением.
Для FreeBSD есть порт sysutils/devcpu-data.
Кто-нибудь использовал его?
Можно его на работающей системе применять?
Ну как бы сам порт стартует из инит скриптов, уже относительно далеко после загрузки системы и ядра. В принципе был и опыт старта скрипта после обновления его версии и на рабочей системе с хорошим аптаймом. Все применялось штатно, без каких либо проблем.
pkg info -E devcpu-data
devcpu-data-1.10Из /var/run/dmesg.boot
CPU: Intel(R) Xeon(R) CPU E3-1240 v5 @ 3.50GHz (3504.17-MHz K8-class CPU)
Origin="GenuineIntel" Id=0x506e3 Family=0x6 Model=0x5e Stepping=3service microcode_update onestart
Updating cpucodes...
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl0 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl0 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl1 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl1 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl2 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl2 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl3 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl3 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl4 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl4 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl5 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl5 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl6 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl6 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl7 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl7 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
Done.
Похоже, нет модуля ядра "cpuctl"
root@uran:/boot/kernel # ls cpuctl*
cpuctl.ko
Причем нужен именно модулем ko, а не вкомпиленный в ядро.
kldstat | grep cpuctl
8 1 0xffffffff8263f000 325d cpuctl.ko[root@*** /boot/kernel]# ls cpuctl*
cpuctl.ko
> kldstat | grep cpuctl
> 8 1 0xffffffff8263f000 325d
> cpuctl.ko
> [root@*** /boot/kernel]# ls cpuctl*
> cpuctl.koА сами устройства есть?
root@uran:~ # ls /dev/cpuctl*
/dev/cpuctl0 /dev/cpuctl2 /dev/cpuctl4 /dev/cpuctl6
/dev/cpuctl1 /dev/cpuctl3 /dev/cpuctl5 /dev/cpuctl7
Конечно.
Помню, как-то в Glibc добавили оптимизации для memcpy() на SSE4. Если сделать поиск по коммитам в Glibc, то оптимизация этого вызова есть на всём, начиная с MMX. Но именно для SSE4 патч был некорректен.Товарищи Дебианщики, а на старых релизах проявляется?
Патч-то был корректен, но некоторые идиоты не читали маны и применяли memcpy там, где нужен был memmove. Так как среди этих идиотов были в том числе разработчики адски популярного тогда флеш-плеера, пришлось откатить назад.
Порядок байт слева направо и справа налево. 35 лет использовался порядок слева направо. 35. А потом вдруг внезапно стали практиковать оба направления, потому что иначе SSE4 не задействовать. Супер.
А потом компьютеры объдинили в сеть и встал вопрос как программам обмениваться данными, учитывая что одна и та же программа может быть запущена на разных процессорах разных компьютеров, каждый из которых хранит данные в своём порядке.Нашли аж два решения:
1. явно перекодировать данные в определённый порядок перед отправкой по сети, затем раскодировать обратно
2. отправлять признак порядка байтов перед отправкой каждой порции данныхДальше _вдруг_ оказалось, что видеокарта тоже может иметь порядок следования байт не такой, как у основного процессора и если ты хочешь писать напрямую в видеопамять используя MMX/SSE, то должен использовать это учитывать.
Поэтому современные процессоры "_внезапно_ (ага, в январе внезапно выпал снег) стали практиковать оба направления"
И чем это отменяет тот факт, что по стандарту memcpy не обязан корректно работать с перекрывающимися буферами, и специально для этого есть memmove? Причём это же банальная общеизвестная вещь, которая в мануале белым по чёрному написана, не где-то в тёмном углу спецификации.
> Порядок байт слева направо и справа налево. 35 лет использовался порядок слева
> направо. 35. А потом вдруг внезапно стали практиковать оба направления, потому
> что иначе SSE4 не задействовать. Супер.Неспроста memcpy была определена (вообще), и определена так как определена.
Потому что с самого начала кое-кому было ясно, что задействовать всё что потребуется по-другому может не получиться. На самом деле копирование памятей может ещё более удивительно происходить. Путём перенавешивания тегов к кэшу скажем... Или аналогично в основной памяти...
> Неспроста memcpy была определена (вообще), и определена так как определена.
> Потому что с самого начала кое-кому было ясно, что задействовать всё
> что потребуется по-другому может не получиться. На самом деле копирование памятей
> может ещё более удивительно происходить. Путём перенавешивания тегов к кэшу скажем...
> Или аналогично в основной памяти...Да можно и 4K-страницы COW'ать...
Да ясное дело, что неспроста. Жаль, что в результате тупость победила.
А по-моему, memcpy(), оптимизированный через SSE4, нафиг не нужен. На ARM-ах как-то живут без этого. Лично мне бы хватило оптимизаций через SSE3 - да чего уж там, MMX за глаза.
"640кб хватит всем"
> Разработчики дистрибутива Debian предупредили о выявлении проблем с работой режима Hyper-threading в процессорах Intel, которые выражаются в непредсказуемом поведении системы (например, крах приложения или повреждение данных)Просто дикий ужас какой-то. После прочтения этих строк у админов высоконагруженных серверов на Intel волосы встали дыбом на всех местах, руки вспотели и на лбу появилась испарина.
Вновинку что ли? У меня на одной конфигурации (intel broadwell) vmware ws, запущенная на centos7, при задействвании HT валится при нагрузке. Без нагрузки - норм. Я думал, может сабж как-то повлияет, но для бродвеля не нашел нового микрокода
>> Разработчики дистрибутива Debian предупредили о выявлении проблем с работой режима Hyper-threading в процессорах Intel, которые выражаются в непредсказуемом поведении системы (например, крах приложения или повреждение данных)
> Просто дикий ужас какой-то. После прочтения этих строк у админов высоконагруженных серверов
> на Intel волосы встали дыбом на всех местах, руки вспотели и
> на лбу появилась испарина.Админы высоконагруженных серверов? На Skylake и Kaby lake? Вы демонстрируете слабое знание серверного железа.
Админы высоконагруженных серверов на процессорах Intel не спешат переходить с EPIC (Itanium) на x86. Да, x86 процессоры мощнее в разы, но по надежности они всё ещё уступают. А это история, и история с TSX в Haswell никак на убеждает их переезжать.
Это которые не производятся уже?
Говорят что еще таки да: http://dma.livejournal.com/6302564.html
> Это которые не производятся уже?Вы про Itanium-ы? Про Kittson-ы слышали (http://ark.intel.com/products/codename/32203/Kittson)? Год выпуска видите? Так что живы они еще, хоть и гнобят их всякие ораклы.
Последние версии интеловских процессоров для высоконагруженных серверов (E5 и E7) — на ядре Broadwell. Скайлэйк и Кэби Лэйк успел пролезть только в E3, которые суть перепиленные гражданские коры. Выхода настоящих серверных Skylake-SP ждём в июне-июле.
> Последние версии интеловских процессоров для высоконагруженных серверов (E5 и E7) —
> на ядре Broadwell. Скайлэйк и Кэби Лэйк успел пролезть только в
> E3, которые суть перепиленные гражданские коры. Выхода настоящих серверных Skylake-SP
> ждём в июне-июле.Так о том и речь: нет высоконагруженных серверов на Skylake и Caby Lake. Я бы и Broadwell не относил к ним. Слишком новые. Haswell-E, которые ставят в Superdom X - еще может быть.
> Просто дикий ужас какой-то. После прочтения этих строк у админов высоконагруженных серверов
> на Intel волосы встали дыбом на всех местах, руки вспотели и на лбу появилась испарина.Неа. HT - всегда первый в очереди (на отключение). Даже до обновления фирмвари.
Почему? Потому что предсказуемость планировщика нужна.
Так что, можно запилить свои инструкции, поменяв микрокод?
> Так что, можно запилить свои инструкции, поменяв микрокод?Интель может, а тебе не даст.
HDD и USB/Flash тоже можно заменить микрокоды но без сервиса автообновления в ядре.
Многие вещи разлочить точно можно
> Многие вещи разлочить точно можноВот с "разлочить" могут быть поблемы: интель сделал одноразовые пережигаемые перемычки _в процессоре_ на "те биты" и рекомендовал производителям матерей/биосов/нотебуков "жечь по полной". Глаголом возможности пользователЕй...
""Purism’s Librem 15 will ship with an Intel CPU fused to run unsigned BIOS code, [...]" --https://puri.sm/posts/pioneering-cpu-efforts-to-liberate-lap.../
Как у вас там "точно" с подписать свой микрокод ключом интеля? "Точно можно"?...
:
:
https://puri.sm/posts/how-purism-avoids-critical-intel-secur.../
https://puri.sm/posts/how-purism-avoids-vault-7-dark-matter/
https://puri.sm/posts/efi-uefi-vault7-exploit-utilizing-nvra.../
.
.
https://puri.sm/learn/freedom-roadmap/
А вы попробуйте поменять. :)Все, что видно снаружи - это зашифрованный блоб.
Turbo Boost -> Speed Shift
Что ж, пичалька, особенно для пользователей i3, отключать HT не буду, но если что то в смерти моей системы прошу винить intel
> Что ж, пичалька, особенно для пользователей i3, отключать HT не буду, но
> если что то в смерти моей системы прошу винить intelТа када выкидывал ненужную кгижку-бумажку "лимитед глобал варанти" от проца/бука/... подписался совсем под обратным. Если есть вопросы -- оплати консультацию юриста.
>>особенно для пользователей
> Та када выкидывал ненужную кHижку-бумажку "лимитед глобал варанти"Утешает то, что продавцы кремния нас такхих
https://duckduckgo.com/?q=void-all-warranties&t=ffab&iar=ima...
очень любят! >/<
А вот на Атоме E3825 если CState в биосе не отключать, тачка колом встает после запуска, причем, что неприятно, может сразу, может на второй третий день...
у меня от mandelbulber проц колом встает
Знаменитый https://bugzilla.kernel.org/show_bug.cgi?id=109051 ?
> А вот на Атоме E3825 если CState в биосе не отключать, тачка колом встает после запуска,
> причем, что неприятно, может сразу, может на второй третий день...Он часом не baytrail?
Да, но эта таблетка не помогала. С =1 тоже встает, и с =2 встает. Только отключение в биосе стабилизирует. Видимо, зависит от характера внешнего питания, я до конца так и не разобрался, применений естественно пром.
> Видимо, зависит от характера внешнего питания, я до конца так и не разобрался,
> применение, естественно пром.А, ну питанием кого угодно уконтрапупить можно...
А как с этим на оффтопиках живут?
А что домашнему пользователю. Ну зависло - перезагрузись. Мало ли что там случилось, может винда, может видеокарта. Данные испортились? - поменяй шлейф. Поменял - успокоился, и так до следующего раза.
Тебе напомнить про неработающий ждущий режим, который "починили" лишь когда декомпилировали драйвер Майкрософт и вытащили из него список багнутых чипов? Пока одни болтают в духе "мы все умрём", другие работают с тем, что у них есть.
Во-первых, они не упоминают слов "дефект процессора", предпочитая более корректные формулировки.Во-вторых, ОС может управлять режимом НТ, даже если он включён в BIOS. И никто не мешает ОС определить некорректно работающую плату и отключить НТ.
В-третьих, на МС работают столько высококлассных спецов, что они могут и сами написать необходимое исправление микрокода.
Так что отлично живут. И главное: не забивают голову ерундой. Если ты проектируешь болиды Формулы-1, то ты должен проектировать болиды, а не думать на тему микрокода и НТ в процессорах.
>а не думать на тему микрокода и НТ в процессорахУ тебя, поди, и стул рабочий с гвоздями жалом вверх?
Да да... А по факту - может быть прилетит через месяц обновление, которое на баганых чипах отключит HT. И ты просто незаметно потеряешь оплаченные 10-25% от производительности. А еще через пару месяцев очень может быть, что прилетит новое обновление с микрокодами от Интела и включит все назад. Но скорее всего, что просто никто не будет заморачиваться если не пойдут сплошные жалобы от пользователей (а они - не пойдут, ибо, как тут было сказано выше, никто не знает почему зависла венда).
НТ не всегда увеличивает производительность. Большинство (вангую: 99%) покупателей топовых чипов его отключат.
>Большинство (вангую: 99%) покупателей топовых чипов его отключат.Зачем?
Топовые процы покупают для выполнения топовых (по сложности) задач.НТ использует простаивающие (!!!!) мощности одного процессора чтобы исполнять команды другого (виртуального).
Если задача полностью загружает процессор или активно работает с памятью (= топовые задачи), то НТ приведёт к замедлению потому что простаивающих мощностей нет.
Ключевые разделяемые ресурсы (по мере уменьшения важности):
- процессор
- кэш https://habrahabr.ru/post/248359/
- FPU (операции с плавающей точкой)
Вообще-то добиться раномерной загрузки всех ядер довольно сложно, так что "простаивающие мощности" останутся с хорошими шансами. Дело скорее в том, что современные процы при простое ядра умеют частоту для других задирать, и обычно это выгоднее.
Есть два врача (окулист и стоматолог) и одна очередь пациентов. Приём длится 10 минут. Процессор умеет выполнять больше, чем 2 операции, но для понимания сгодится.В случае однопоточного выполнения каждый такт работает один врач, а второй курит бамбук.
Разрешим людям вставать в две очереди (НТ). В лучшем случае пациент 1-ой очереди хочет к стоматологу, а 2-ой к окулисту. Оба врача загружены, у нас удвоение производительности. В худшем оба хотят к одному врачу и ситуация аналогична той, когда у нас была одна очередь и один врач курил бамбук.
Проблема вот в чём: чтобы попасть к врачу нужна медицинская карта. Максимум на столе у медсестры может лежать 6 карт. Медсестра одна, за картами ходит в соседнее здание, это занимает час и она приносит 6 карт. Пока она несёт 6 карт проходит 60 минут, за которые врача посещают 6 пациентов. В компе это называется "кэш-память".
В случае одной очереди всё отлично: медсестра оптимально загружена.
Если очередей две (НТ), то она, не зная кто к кому, возьмёт первых 3 пациентов из каждой очереди. Возможна ситуация, когда в очереди стоят пациенты, а карт нет и обе очереди ждут медсестру.
Медсестра - тот самый разделяемый ресурс, который общий и медленный.
Проблема возникает когда:
1. все хотят к одному врачу. В случае если выполняется одна задача, которая параллелится, оно так и получается. Есть операция (условно: возведение в степень), которая самая медленная в алгоритме и которая нужна всем потокам, а у нас есть лишь один такой врач.
2. нужны данные из памяти (сети, жёсткого диска, ..) = та самая медсестра, которую ждут в обеих очередях.Здесь кратко (!) об архитектуре почти что современных (2013 г.) процессоров:
https://habrahabr.ru/post/182002/
Давай без метафор, тем более таких обширных. Факт - чтобы потоки были полностью изолированы и не ждали ни друг друга, ни внешние ресурсы - надо здорово постараться. При ожидании внешних ресурсов нормальный процесс ждёт. Когда это ожидание не слишком долгое, а переключения происходят часто - HT даёт выигрыш за счёт сохранения контекста процессора. Примеры и "за", и "против" в гугле полно.
Потому что масса персонажей пугается всего, что связано с thin provisioning и прочим умным разделением ресурсов в любом виде. Предметное мышление, как оно есть.
> на МС работают столько высококлассных спецовНи одного.
> на МС работают столько высококлассных спецовМного. И ещё вторая половина Индии - запасные.
> Во-первых, они не упоминают слов "дефект процессора", предпочитая более корректные формулировки.предпочитая более некорректные формулировки.
> более корректные формулировки.
> столько высококлассных спецов
> ты должен [...] не думатьИ вот такие потом обижаются, что их измышления или поднимают на смех, или стирают нахрен.
Болезный, уши же торчат. Человеком пора становиться, а не утюгом.
Какова доля рынка у АльтЛинукс? Обижаться на тех, кто не смог дорасти даже на до 0.001%? Это шутка такая?У Альта и его сотрудников своё видение мира, рынок им говорит что оно неверное, но они продолжают идти этим путём.
У Майкрософт 80% рынка.
Когда глава Майкрософт говорит что-то, я ему доверяю с вероятностью 80%. Когда ты пишешь что-то, я доверяю тебе с вероятностью 0.001%.
Стирай дальше, обижай, оскорбляй, если считаешь что это позволит тебе и твоей компании достичь большего.
Как вы достали со своими воображаемыми "рынками". С точки зрения большинства людей занимающихся открытими технологиями майкрософт продаёт "навоз", и в целом большинству этих людей нет дела до этих "рынков навоза". И тут появляется некий Аноним и вопит "навоз форева, он лучший, я верю в него!". Анон, да ради бога, ты можешь доверять своей бабушке, микрософту, кока-коле, пьяному дяде в подворотне...
Открытый код, открытое сообщество это не о том, кто больше всех смог продать.
Большая часть народу притянута зауши в ваш "рынок", и как и на любом рынке обманута.
> Когда глава Майкрософт говорит что-то, я ему доверяю с вероятностью 80%.
> Когда ты пишешь что-то, я доверяю тебе с вероятностью 0.001%.Это значит всего лишь то, что Вы путаете доверие и "рыночную долю" (точнее даже оценки таковой, да ещё и не умея даже их делать или выбирать сколь-нибудь похожие на правду).
И да, я без малейших сомнений продолжу гонять таких "поссетителей" мокрыми тряпками.
> А как с этим на оффтопиках живут?Так же: обновляют микрокод при загрузке операционки.
> А как с этим на оффтопиках живут?Оне к стаданиям привычние....
маялся 2 года с этим г овном, пока не осенило и не обновил BIOS.
Compiling with Ryzen CPUs on Linux causing random segfaults, possible CPU bug
> рекомендуется как можно скорее установить пакет intel-microcodeА как же другие семейства процессоров вообще работают без этого пакета?
>> рекомендуется как можно скорее установить пакет intel-microcode
> А как же другие семейства процессоров вообще работают без этого пакета?Работают на микрокоде, загруженном UEFI/BIOS.
Был бы MISC вместо CISC - всё было бы куда лучше.
Вот тут пишут, что проблема проявляется в случае использования gcc.
То есть FreeBSD и MacOS получается, что не касается.
https://habrahabr.ru/post/332552/