Comments 133
Молодцы, что признали проблему сразу. По последним новостям, некоторые из производителей плат уже получили доступ к обновлённой сборке AGESA на этой неделе.
«Но на данный момент ни среди бинарных сборок под Windows, ни под Linux нет версии для тестирования Zen.»
«то можете сами взять и скомпилировать бинарник в Visual Studio» (рекурсия на предыдущюю цитируемую строчку)
«простой и малоизвестной утилите для тестирования ЦП.»
«В других бенчмарках баг так и не проявился.»
Простой PR «простой и малоизвестной утилите»…?
«то можете сами взять и скомпилировать бинарник в Visual Studio» (рекурсия на предыдущюю цитируемую строчку)
«простой и малоизвестной утилите для тестирования ЦП.»
«В других бенчмарках баг так и не проявился.»
Простой PR «простой и малоизвестной утилите»…?
«сейчас для тестирования Ryzen применяли бинарники других архитектур, а именно наиболее близкой Haswell.»
да блин, у меня старый atom, если я на нем скомпилирую gentoo с флагами от другого камня — тоже наверное заглючит и уйдет в мертвый перезагруз… а так — на fx64 с «проблемой» TLB — годами и рендерил и в нфс и батлфиелд гонял…
«наиболее близкой „
мягкое с теплым
мягкое с теплым
Одно дело — ядро ОС под другую архитектуру. Другое дело — пользовательская программа. Для пользовательской программы, собранной под другую архитектуру, допустимым является только одно поведение — аварийное завершение процесса, но никак не зависание компьютера!
пользовательская программа «в идеале» запускается под api os и по барабану железо, камень.
а совсем в идеале это дум3 — вот как накарябыли, а до сих пор идет, и под ХР и w7 и w10
а совсем в идеале это дум3 — вот как накарябыли, а до сих пор идет, и под ХР и w7 и w10
API OS не дает абстракций над инструкциями процессора.
Какое API вы вообще предлагаете использовать для сложения двух чисел? А умножения? Округления?
Да, для этого дела уже придумали всякие байт-коды и MSIL.
Но пока производительность нативного кода в разы выше, от процессоро-зависимого кода никуда не деться.
Тогда надо на яве все писАть.
Ух как тормозить то будет.
Ух как тормозить то будет.
писал я както на недокументированных особенностях opengl — на риве работало на жтикс стоко гемора вылезло, но, на рива тнт можно было почти джефикс про получить
UFO just landed and posted this here
бинарники-не исходники, а компилировать можно и gcc
Утилита может и малоизвестна, но y-cruncher от него же любители бенчмарков знать должны.
К счастью, такой баг можно исправить без замены железа, а просто обновлением микрокода.
d = round(a × b + c)
Будет три такта вместо одного, ну вы поняли. Мне даже стало интересно, что там исправляют в intel-microcode.
Скорее всего ничего не будет.
Современные процессоры у давно гораздо сложнее чем просто правильно посчитать тот же самый FMA, но еще и очень навороченный power management. Power management мониторит все основные узлы ядра и пытается открывать и закрывать блоки которые на данный момент не используются, чтобы потреблять меньше энергии. А еще нужно заботиться о возможно перегреве — нельзя дать FMA unit без остановки молотить числа потому что он может банально перегреться и транзисторы начнуть давать сбои. Еще нужно заботиться о скачках напряжения которые могут возникать при быстрых переходах от полной нагрузки до idle и многом другом.
Большинство багов связано как раз с power management — в лаборатории на тестах AMD может все работало а тут у вас дома на никому не извесном бенчмарке может выявляться баг. И патче проблему решают фиксом power management алгоритмов или clock gating логики.
Похожая проблема была у Skylake когда он вышел.
Плохая новость в том, что его могут использовать злоумышленники для DoS-атак.
Кстати, а как? Это надо найти сервер на райзене и пропихнуть туда зловреда с нужным кодом, чтобы его уронить. Но если уж нам чего-то исполняемое удалось пропихнуть на сервер, то уронить его не такая проблема. Да и вообще ронять такой хороший сервер уже незачем :)
Сейчас любят на сервера ставить виртуализацию, и продавать по кусочкам. Как написано в статье система упадёт даже если код исполнят на виртуалке. Вот если кто то сделает VPS на Ryzen, вы можете купить один инстанс за 100 рублей в месяц и ронять целый сервер. А если предположит что JS например при своём выполнении может выполнять эту команду, то можно ронять страницы всех посетителей сайта где сможете разместить нужный код.
Найти софт, в котором есть эта команда и найти способ заставить её выполниться нужным образом. Путём передачи определённого запроса, например. Сам понимаю, насколько это кажется трудным и невероятным, но когда народ ухитряется эксплуатировать rowhammer из javascript можно уже ничему не удивляться.
уроните сервак в «мертвый перезагруз» — ну и че? если только онлайн-сервис уронить.
«У нас вася вчера сервак уронил — крутой хакер? — да не, просто дятел, он его себе на ногу уронил»
«У нас вася вчера сервак уронил — крутой хакер? — да не, просто дятел, он его себе на ногу уронил»
Это можно рассматривать и как спланированную акцию «черного пиара» — очень много внимания привлекается в последнее время к «новейшим недорогим процессорам AMD».
По этой логике продажи телефонов Самсунга, после недавних событий, должны были взлететь.
Уверены что полностью поняли логику комментария?
Если вы имели ввиду историю про аккумуляторы — то вы сравнили теплое с фиолетовым.
Аппаратные проблемы, взрывающиеся телефоны, пострадавшие люди, отзыв партий телефонов, отмена продаж — ущерб компании.
Софтовая проблема в бенчмарке, быстрая реакция компании, программный фикс — пиар и профит.
Если вы имели ввиду историю про аккумуляторы — то вы сравнили теплое с фиолетовым.
Аппаратные проблемы, взрывающиеся телефоны, пострадавшие люди, отзыв партий телефонов, отмена продаж — ущерб компании.
Софтовая проблема в бенчмарке, быстрая реакция компании, программный фикс — пиар и профит.
Если хотите, рассматривайте как пиар (непонятно почему чёрный), в конце концов развитие ЦПУ в современных реалиях это немалая заслуга маркетинга. Порой, умелое поведение в критической ситуации может сыграть на руку, а безалаберное отношение к деталям провалить даже, казалось бы, непотопляемую компанию.
непонятно почему чёрный
Ок не черный. Но саму ситуацию «Ryzen намертво вешают операционную систему» трудно назвать повыщающей имидж компании.
в конце концов развитие ЦПУ в современных реалиях это немалая заслуга маркетинга
Разве я спорю или говорю что это плохо?
Всего лишь констатирую факт — описанная ситуация я считаю в целом не столько бросает тень на процессоры AMD, сколько все таки привлекает внимание к новой линейке. И это вполне могло быть обыграно маркетологами AMD на несколько ходов вперед.
Не понятно только за что фанаты-минусаторы борются. Пригорает от того что AMD умеет грамотно использовать маркетинговый ресурс?
мб (асус) для ам3+ 6тр, камень (8320Е) 6 тр, — райзен 22700 + память… — нет дров для ХР…
Я упорно не понимаю, почему производители никак не могут один раз подумать и сделать законченную систему команд процессора. А вместо этого постоянно допиливают систему команд, добавляют новые команды — и вносят новые баги.
Неужели так сложно сформировать систему команд по типу ARM (ну или другого RISC-процессора, хотя принципы у них одинаковые), но с 64-битной адресацией памяти. Размер регистра нужен не менее, чем разрядность адресации памяти; но можно делать и больше, есть варианты использования больших регистров, особенно при копировании больших массивов.
А развиваться процессоры будут за счёт увеличения тактовой частоты, снижения числа таков на исполнение каждой команды, увеличения числа ядер, увеличения размера кэша, изменения архитектуры кэша, etc.
Неужели так сложно сформировать систему команд по типу ARM (ну или другого RISC-процессора, хотя принципы у них одинаковые), но с 64-битной адресацией памяти. Размер регистра нужен не менее, чем разрядность адресации памяти; но можно делать и больше, есть варианты использования больших регистров, особенно при копировании больших массивов.
А развиваться процессоры будут за счёт увеличения тактовой частоты, снижения числа таков на исполнение каждой команды, увеличения числа ядер, увеличения размера кэша, изменения архитектуры кэша, etc.
Дело не в системе команд, а в невероятной сложности процессора.
Если бы возможность наращивания частоты была, ею бы пользовались. Но сейчас добиваются роста производительности как раз за счёт снижения числа тактов на исполнение команд и суперскалярности. Неудивительно, что вероятность ошибки накапливается многократно.
UFO just landed and posted this here
Кажется, что вы упорно не ищите ответы на свой вопрос почему.
«Я упорно не понимаю, почему производители никак не могут один раз подумать и сделать самый быстрый процессор. А вместо этого постоянно допиливают архитектуру процессора, уменьшают техпроцесс, выпускают новые модели».
«Я упорно не понимаю, почему производители никак»
«Дело не в системе команд, а в невероятной сложности процессора.»
вывод: инструмент стал сложнее создателя, не, я не призываю вернутся на ВМ38,
«Дело не в системе команд, а в невероятной сложности процессора.»
вывод: инструмент стал сложнее создателя, не, я не призываю вернутся на ВМ38,
Концепция RISC-процессора предполагает, что редко используемые команды вообще ликвидируются (не реализуются ни аппаратно, ни в микрокоде), а программист-ассемблерщик или компилятор реализует нужную функциональность через простой набор команд. Соответственно, процессор становится проще — требует меньше транзисторов и соединительных линий. А значит, вероятность ошибок проектирования снижается.
Т.е. я утверждаю, что сложность процессора в первую очередь определяется системой команд. Например, процессор без сопроцессора — заведомо проще.
Т.е. я утверждаю, что сложность процессора в первую очередь определяется системой команд. Например, процессор без сопроцессора — заведомо проще.
И зачем такое нужно? Это из серии «давайте везде использовать сортировку пузырьком, зачем плодить алгоритмы».
Пузырёк с переменным шагом имеет предельную (теоретически возможную) скорость сортировки. Что Вам не так?
Вы серьезно?
Во первых что за «пузырек с переменным шагом»? Вы о Comb Sort? Так он в худшем случае O(n2)
Во вторых — асимптотическая сложность — далеко не единственный показатель, который важен в алгоритме
В третьих — есть специализированные случаи, когда используя знания о входных данных можно достичь гораздо лучших показателей чем используя общие методы
Во первых что за «пузырек с переменным шагом»? Вы о Comb Sort? Так он в худшем случае O(n2)
Во вторых — асимптотическая сложность — далеко не единственный показатель, который важен в алгоритме
В третьих — есть специализированные случаи, когда используя знания о входных данных можно достичь гораздо лучших показателей чем используя общие методы
Современные процессоры уже давно являются RISC-процессорами на низком уровне: процессор разбирает команды на элементарные. Да, это усложняет процессор, но вклад в общую сложность здесь невелик.
Большую часть площади кристалла (около половины) занимает кэш. Думаете в RISC-процессорах нет кэша? Ещё как есть. Хотите отказаться от кэша? Придумайте быструю замену DRAM.
Далее идёт суперскалярность. Раз нельзя наращивать частоту, приходится увеличивать пропускную способность конвейера за счёт увеличения числа блоков, работающих параллельно. Предсказание переходов, out of order execution — всё это будет нагружать как RISC, так и традиционный процессор.
Ну и вишенка на торте — неравномерность нагрузки. AVX/FMA-инструкции очень сильно нагружают процессор, и переходом на RISC-арихитектуру проблему не решить — вычислений меньше не станет.
Современные процессоры уже давно являются RISC-процессорами на низком уровне: процессор разбирает команды на элементарные. Да, это усложняет процессор, но вклад в общую сложность здесь невелик.Вы говорите странные и непонятные вещи. Ведь именно преобразователь традиционной системы команд в RISC-систему и является одним из наиболее сложных и тормозных элементов. И из-за этого преобразования приходится строить сложный кэш для кода, т.к. надо хранить преобразованный код. И хранить много, т.к. преобразование — процесс достаточно сложный
Большую часть площади кристалла (около половины) занимает кэш.Я как-то сильно сомневаюсь, что кэш может повлиять на ошибки в процессоре типа той, что описана в статье. Да и ошибка деления Пентиума тоже никак не касалась кэша.
Хотите отказаться от кэша? Придумайте быструю замену DRAM.Совсем отказаться от кэша невозможно т.к. производители, ориентируясь на кэш, не разрабатывают быстрой памяти. Однако, есть несколько вариантов снижения потребности в кэше:
- Увеличение количества регистров — одна из главных фишек RISC-процессоров.
- Использование регистрового файла (т.е. фактически создание для каждого ядра своего собственного пула памяти в схеме NonMA).
- Выделение каждому процессору собственной памяти в полноценной схеме NonMA.
- Отказ от прозрачного для программ совместного использования памяти. Теперь, чтобы программа на одном ядре могла записать в память данные, а программа на другом ядре могла прочитать эти данные — программы должны явно указать кэшам своих ядер факт передачи памяти в распоряжение другого ядра.
- Ну или хотя бы ввести в дескрипторы страниц указание на то, используется ди эта страница монопольно или совместно несколькими ядрами. Для монопольных страниц не надо синхронизировать кэши.
Наверно, Вы уже заметили, что большинство пунктов требуют отказаться от совместимости с системой команд *86.
Далее идёт суперскалярность. Раз нельзя наращивать частоту, приходится увеличивать пропускную способность конвейера за счёт увеличения числа блоков, работающих параллельно.Увеличивать параллельность можно увеличением количества ядер. Правда, для этого надо разрабатывать теорию параллельных вычислений — а с этим туго, т.к. за последние четверть века с распада СССР образование деградировало.
А чтобы построить нормальную суперскалярность — опять же надо менять систему команд процессора: надо не заставлять процессор на ходу угадывать, что можно суперскалярить, а что нельзя — а явно прописать это в командах процессора.
Предсказание переходов, out of order execution — всё это будет нагружать как RISC, так и традиционный процессор.А Вы разве не в курсе, что система команд ARM существенно снижает количество переходов? Соответственно, меньше потребность их предсказывать.
Да и конвейер у него тупо короче.
Ну и вишенка на торте — неравномерность нагрузки. AVX/FMA-инструкции очень сильно нагружают процессор, и переходом на RISC-арихитектуру проблему не решить — вычислений меньше не станет.RISC-арихитектура позволяет достаточно эффективно реализовать AVX программно.
Что же касается FMA — то мне вообще непонятно, зачем так носятся с плавающей арифметикой. Для значительной части задач она не нужна вообще.
Идеальный мир недостижим.
Ведь именно преобразователь традиционной системы команд в RISC-систему и является одним из наиболее сложных и тормозных элементов.
Насчёт сложных — полностью согласен. И хранение преобразованного кода в кэше тоже не идёт на пользу.
Однако, есть несколько вариантов снижения потребности в кэше:
1. Так и есть. Больше регистров — меньше потребность в L1 кэша. Сейчас логические регистры маппятся преобразованием на значительно большее число реальных регистров. Но напрямую реальные регистры не использовать.
2-5. Вы представляете, насколько это усложнит программирование многопоточных приложений? Возможно, для вычислительных задач это и будет актуально, но для реальных — совсем нет.
Ну и наконец, DRAM можно тупо ускорить внешним кэшем, расположенным на мат.плате — часть сложности процессора выносится наружу.
А лет 20 назад так и делали, кстати. Но учитывая, что в современном мире имеется тенденция к SoC, скорее, память просто встроят внутрь процессора.
А чтобы построить нормальную суперскалярность — опять же надо менять систему команд процессора: надо не заставлять процессор на ходу угадывать, что можно суперскалярить, а что нельзя — а явно прописать это в командах процессора.
Не надо. VLIW (а именно он подразумевает явное прописывание задач для ФУ) — плохое решение.
А Вы разве не в курсе, что система команд ARM существенно снижает количество переходов? Соответственно, меньше потребность их предсказывать.
Да и конвейер у него тупо короче.
Система команд AVX мне напоминает ARM — там тоже есть условное выполнение.
А длину конвейера сравнивать нет смысла — если производители ARM-процессоров захотят увеличить производительность за счёт повышения исполняемых за такт инструкций, они будут вынуждены использовать длинный конвейер.
RISC-арихитектура позволяет достаточно эффективно реализовать AVX программно.
Предлагаете научить процессор выполнять по полсотни инструкций за такт? Наверное, это возможно, если в процессор поместить соответствующее количество FPU блоков и заюзать суперскалярность, только объём кода вырастет на пару порядков — никаких кэшей не хватит и планировщик в процессоре сдохнет.
Отказ от прозрачного для программ совместного использования памяти. Теперь, чтобы программа на одном ядре могла записать в память данные, а программа на другом ядре могла прочитать эти данные — программы должны явно указать кэшам своих ядер факт передачи памяти в распоряжение другого ядра.Это сюр какой-то. Зачем оно все нужно? Вместо того чтобы иметь сложность в одном месте при разработке ЦП вы хотите ее вынести во все многопоточные программы? Нафиг надо.
Ну или хотя бы ввести в дескрипторы страниц указание на то, используется ди эта страница монопольно или совместно несколькими ядрами. Для монопольных страниц не надо синхронизировать кэши.
Увеличивать параллельность можно увеличением количества ядер. Правда, для этого надо разрабатывать теорию параллельных вычислений — а с этим туго, т.к. за последние четверть века с распада СССР образование деградировало.1) Ядрами нельзя заменить все, SIMD полностью по ядрам раскидывать — неэффективное варварство.
2) При чем тут ссср? Как бы параллельные вычисления живут и без него.
А чтобы построить нормальную суперскалярность — опять же надо менять систему команд процессора: надо не заставлять процессор на ходу угадывать, что можно суперскалярить, а что нельзя — а явно прописать это в командах процессора.Нужно и то и то. Ну или вы готовы заставить всех переписать все тонны уже существующего кода? Ну или хотя бы переписать все компиляторы и перекомпилировать все.
RISC-арихитектура позволяет достаточно эффективно реализовать AVX программноНу и кому этот монстр нужен? Так то можно вместо AVX все в цикле написать, только суть как раз в том что используются очень низкоуровневые хардварные оптимизации для повышения производительности.
Что же касается FMA — то мне вообще непонятно, зачем так носятся с плавающей арифметикой. Для значительной части задач она не нужна вообще.Тут я даже поперхнулся. Предлагаю еще умножение выкинуть, оно не особо нужно, а те кому нужно — напишут цикл по сложению.
Вместо того чтобы иметь сложность в одном месте при разработке ЦП вы хотите ее вынести во все многопоточные программы?Видите ли, развитие технология однозначно вывели нас на необходимость многопоточных вычислений. Ибо одноядерные процессоры перестали развиваться, им дальше не могут наращивать быстродействие, и основное направление роста быстродействия — в увеличении числа ядер.
Ядрами нельзя заменить все, SIMD полностью по ядрам раскидывать — неэффективное варварство.Я не предлагаю разбросать SIMD по ядрам. Я предлагаю отказаться от SIMD вообще, потеряв на этом часть производительности. Но наверстать это за счёт увеличения числа ядер — благо отказ от SIMD понизит потребность в «транзисторах на ядро»; а значит, количество ядер можно будет увеличить.
При чем тут ссср?Распад СССР привёл к деградации образования. Во всех областях.
Ну или вы готовы заставить всех переписать все тонны уже существующего кода? Ну или хотя бы переписать все компиляторы и перекомпилировать все.Э-э-э…
Наверно, Вы не заметили — но компиляторы постоянно переписываются. Последняя большая переделка была при появлении AMD-64. Но и сейчас переделки не прекращаются: "Intel рекомендует отказаться от старых SSE инструкций в пользу новых 128-битных AVX-инструкций, даже если достаточно двух операндов.".
Так то можно вместо AVX все в цикле написать, только суть как раз в том что используются очень низкоуровневые хардварные оптимизации для повышения производительности.Интересно было бы посмотреть исходный код высокоуровневого языка, для которого компилятор генерирует AVX-коды.
Тут я даже поперхнулся.А зря!
Ну, например, в ядре операционки — где нужен FPU? (Ну, разве что в видеодрайвере.)
Web-сервер, Proxy-сервер (Apache, Squid, Ngnix).
Файловый сервер Samba.
DNS-сервер? DHCP-сервер.
В ряде случаев имеет смысл проводить вычисления с фиксированной точкой.
Другого решения не существует, в принципе не понятно какое другое решение может быть.Чтобы не надо было преобразовывать внешние команды во внутренние — надо просто чтобы компилятор изначально создавал код во внутреннем представлении. И сложность процессора сразу на порядок снижается — а значит, растёт надёжность (и в плане ошибок разработки, и в плане поломок), повышается скорость каждого ядра, можно сделать больше ядер.
Я предлагаю отказаться от SIMD вообще, потеряв на этом часть производительности. Но наверстать это за счёт увеличения числа ядер — благо отказ от SIMD понизит потребность в «транзисторах на ядро»; а значит, количество ядер можно будет увеличить.
Преимущество SIMD в первых двух буквах (Single Instruction). Ваш подход приведёт к увеличению ядер в 16-32 раз для получения аналогичной производительности: хотите писать код под 2048-ядерные процессоры? Ничего хорошего из этого не выйдет.
Суммарное количество транзисторов только увеличится: количество вычислительных ФУ останется прежним, а но вот количество декодеров команд и конвейеров увеличится пропорционально числу ядер.
Можете ради интереса взглянуть на архитектуру современных видеокарт. Куча ядер, никаких SIMD-инструкций, единственная "мелочь" — нельзя работать с потоками независимо.
Мне кажется, Вы говорите «в 16-32 раз», исходя из предположения «программа в основном состоит из SIMD-инструкций». А в реальности надо смотреть, сколько этих SIMD-инструкций.
Я вовсе не сторонник безудержного увеличения числа ядер в одном процессоре. Наоборот — надо возвращаться к многочиповой архитектуре, и каждому чипу выделять собственный модуль памяти. Отказ от общей памяти снизит потребность в кэше.
Дальше надо отказываться от SMP и принудительно распределять работу между процессорами. Например, драйвер файловой системы д.б. на отдельном процессоре, и там же — драйвер RAID-контроллера с кэшированием (т.е. функции файловой системы, кэширования диска и RAID-контроллера надо интегрировать в одном программном модуле). И этому процессору FPU точно не потребуется.
Ваша ссылка — слишком большая. Какое именно место читать?
Если в видеокартах не сделали независимую работу с потоками — это не значит, что это невозможно сделать в принципе.
Я вовсе не сторонник безудержного увеличения числа ядер в одном процессоре. Наоборот — надо возвращаться к многочиповой архитектуре, и каждому чипу выделять собственный модуль памяти. Отказ от общей памяти снизит потребность в кэше.
Дальше надо отказываться от SMP и принудительно распределять работу между процессорами. Например, драйвер файловой системы д.б. на отдельном процессоре, и там же — драйвер RAID-контроллера с кэшированием (т.е. функции файловой системы, кэширования диска и RAID-контроллера надо интегрировать в одном программном модуле). И этому процессору FPU точно не потребуется.
Ваша ссылка — слишком большая. Какое именно место читать?
Если в видеокартах не сделали независимую работу с потоками — это не значит, что это невозможно сделать в принципе.
Мне кажется, Вы говорите «в 16-32 раз», исходя из предположения «программа в основном состоит из SIMD-инструкций». А в реальности надо смотреть, сколько этих SIMD-инструкций.
Достаточно, чтобы в некоторых задачах скорость FPU стала узким местом. Любая обработка изображений (типа фотошопа) или видео будет сильно требовательна к SIMD.
Дальше надо отказываться от SMP и принудительно распределять работу между процессорами.
Данное решение будет плохим из-за потери универсальности. Пользователю придётся покупать систему строго под свои задачи. Такое допустимо в серверных платформах, но не в десктопном сегменте.
Универсальность — это хорошо. Чем массовое продукт, тем он дешевле и доступнее. Выгоднее клепать одинаковые процессоры и просто отключать модули из маркетинговых соображений, чем делать по процессору под каждую задачу.
Ваша ссылка — слишком большая. Какое именно место читать?
Да собственно, я просто хотел привести пример сильно многоядерной архитектуры, и текущие технические проблемы в ней (один поток команд для нескольких вычислительных потоков).
Любая обработка изображений (типа фотошопа) или видео будет сильно требовательна к SIMD.Осталось узнать, много ли компьютеров крутят на себе Фотошоп и обработку видео.
Ну и почему я должен платить за счастье для фотошоперов? Может, пусть они лучше приобретают себе отдельный вычислительный модуль?
Данное решение будет плохим из-за потери универсальности.Где Вы видите потерю универсальности?
Может, Вы против того, что у видеокарты — свой процессор? Ой-вэй, универсальность потеряна!!!
Пользователю придётся покупать систему строго под свои задачи.Вы так говорите. как будто в этом есть что-то плохое. Как будто плохо выбрать компьютер с аппаратным RAID-контроллером, если он нужен, или без оного, если он не нужен.
Выгоднее клепать одинаковые процессоры и просто отключать модули из маркетинговых соображений, чем делать по процессору под каждую задачу.Странно, что в смартфонах и планшетах какие-то ARM, а не те же процессоры, что и в серверах.
А отключение модулей из маркетинговых соображений — это настоящее вредительство.
Осталось узнать, много ли компьютеров крутят на себе Фотошоп и обработку видео.
Ну и почему я должен платить за счастье для фотошоперов? Может, пусть они лучше приобретают себе отдельный вычислительный модуль?
А теперь представьте себе головную боль программистов: им придётся писать кучу вариантов программы для каждого из процессоров. Стоимость разработки, а значит, и стоимость софта подорожает.
Вот захочется вам отредактировать фотографию, что будете делать? Захотелось посмотреть видео — а кодек требует векторных инструкций и т.д. Заранее запланировать набор функционала очень сложно, особенно для десктопов.
Вы так говорите. как будто в этом есть что-то плохое. Как будто плохо выбрать компьютер с аппаратным RAID-контроллером, если он нужен, или без оного, если он не нужен.
Вот только мне будет плевать на то, будет ли процессор контроллера иметь избыточный функционал (FPU и SIMD) или нет. Главное, чтобы он работал.
Странно, что в смартфонах и планшетах какие-то ARM, а не те же процессоры, что и в серверах.
Потому что спрос на процессоры для мобильных устройств настолько высок, что экономически оправдано выпускать специализированные процессоры.
А отключение модулей из маркетинговых соображений — это настоящее вредительство.
Нет, это экономическая оправданность. Хотите платить за процессор в два раза больше?
Осталось узнать, много ли компьютеров крутят на себе Фотошоп и обработку видео.
Ну и почему я должен платить за счастье для фотошоперов? Может, пусть они лучше приобретают себе отдельный вычислительный модуль?
Потому что разработка двух разных процессоров параллельно сделает каждый из них дороже — такое вот у них интересное ценообразование...
Осталось понять, почему тогда на рынке есть два разных процессора *86/AMD-64 — от Intel и AMD; да и внутри каждого есть несколько моделей (например, Xeon и Pentium даже имеют разные сокеты).
Плюс к тому есть ARM, MIPS и ещё ряд процессоров (например, у IBM есть свои процессоры).
Плюс к тому есть ARM, MIPS и ещё ряд процессоров (например, у IBM есть свои процессоры).
почему тогда на рынке есть два разных процессора *86/AMD-64 — от Intel и AMD
Наверное, потому что это две конкурирующие компании и поэтому они выпускают разные процессоры, а не работают сообща над одним? И это хорошо: конкуренция — двигатель прогресса.
да и внутри каждого есть несколько моделей (например, Xeon и Pentium даже имеют разные сокеты).
Экономическая оправданность. Пока что невыгодно клепать одни Xeon-ы и просто обрезать их. Посмотрите цены на 10+ -ядерные Xeon-ы — вот и цена для менее массового производства.
Плюс к тому есть ARM, MIPS и ещё ряд процессоров (например, у IBM есть свои процессоры).
ARM, MIPS — это не процессоры, а архитектуры. И пока что нет производителей процессоров на подобных архитектурах, способных создать процессор, который может потеснить процессоры от Intel и AMD.
И это хорошо: конкуренция — двигатель прогресса.Конкуренция хороша для потребителей и плоха для производителей.
Вероятно, Вы не понимаете механизма, по которому продолжают существовать два разработчика. А механизм этот — государственный.
Экономическая оправданность. Пока что невыгодно клепать одни Xeon-ы и просто обрезать их.А с чего Вы вообще взяли, что процессоры обрезаются специально? Лично я полагаю, что скорее процессоры делаются как получится, а портом испытываются; и те участки кэша, те ядра, которые не прошли тестирования — выжигаются (точнее, выжигаются провода, идущие к ним; или они отключаются каким-то иным способом).
Однако, Вы так и не объяснили мне, почему выгодно разрабатывать несколько разных сокетов. Мало того, что Xeon и Pentium имеют разные сокеты — так Intel постоянно меняет сокеты, так что в продаже имеются два или даже три актуальных сокета для Pentium.
Вообще, похоже, что здесь Intel не столько развивает процессоры, сколько дурит пользователей и выкачивает из них деньги. А некоторые пользователи радостно говорят, что это экономически оправдано.
Ну да, оправдано — с т.з. маркетологов. А с т.з. потребителей и общества в целом это чистое разорение, т.к. инвестиции тратятся не в совершенствование процессоров, а в ухищрения по выкачиванию денег…
ARM, MIPS — это не процессоры, а архитектуры. И пока что нет производителей процессоров на подобных архитектурах, способных создать процессор, который может потеснить процессоры от Intel и AMD.Я так понимаю, про Raspberry Pi Вы не слышали.
Конкуренция хороша для потребителей и плоха для производителей.
Да, конкуренция заставляет бедных и несчастных производителей вертеться и придумывать новые продукты.
Вероятно, Вы не понимаете механизма, по которому продолжают существовать два разработчика. А механизм этот — государственный.
Да, существует соглашение об обмене технологиями. Но конкуренция между ними вполне рыночная.
А с чего Вы вообще взяли, что процессоры обрезаются специально? Лично я полагаю, что скорее процессоры делаются как получится, а портом испытываются; и те участки кэша, те ядра, которые не прошли тестирования — выжигаются (точнее, выжигаются провода, идущие к ним; или они отключаются каким-то иным способом).
А почему бы и нет? Сложно случайным образом получить нужное число процессоров с нужной конфигурацией, приходится ещё и вредить. А у AMD вообще ядра можно было программно включить.
Вы так и не объяснили мне, почему выгодно разрабатывать несколько разных сокетов.
Чтобы люди, покупая новый процессор, меняли и материнку, и наоборот. AMD, например, сокеты не меняет и предпочитает сохранять обратную совместимость.
Ну да, оправдано — с т.з. маркетологов. А с т.з. потребителей и общества в целом это чистое разорение, т.к. инвестиции тратятся не в совершенствование процессоров, а в ухищрения по выкачиванию денег…
Intel как частная компания имеет на это полное право. Если вас это не устраивает — голосуйте рублём, не покупайте процессоры от Intel, а пользуйтесь Raspberry Pi. Вы же правда считаете эту платформу конкурентом Intel?
Отказ от общей памяти снизит потребность в кэше.Смех да и только. Видимо вы никогда код не писали. Вы представляете последствия? Это значит что вместо того чтобы реализовать что-то в ЦП вы заставите программистов писать не только многопоточный хардкорно оптимизированный код, но и еще заниматься кучей дополнительной синхронизации из-за неразделяемой памяти.
И получится у вас… просто несколько полностью независимых систем на одной плате. А смысл?
Раньше программисты для достижения высокой производительности писали на ассемблере. Сейчас пишут на языках высокого уровня, а оптимизирует программу компилятор; причём чем выше уровень языка, тем больше возможностей оптимизации имеет компилятор.
Точно так же надо поступить и с распараллеливанием: создавать языки высокого уровня, а раскидывать работу на много потоков будет компилятор. Ну и для начала сделать параллельными популярные библиотеки подпрограмм.
Синхронизации не особо нужны, если использовать систему обмена сообщениями. Давно разработано — вроде, в QNX является базовым элементом операционки.
Точно так же надо поступить и с распараллеливанием: создавать языки высокого уровня, а раскидывать работу на много потоков будет компилятор. Ну и для начала сделать параллельными популярные библиотеки подпрограмм.
Синхронизации не особо нужны, если использовать систему обмена сообщениями. Давно разработано — вроде, в QNX является базовым элементом операционки.
Точно так же надо поступить и с распараллеливанием: создавать языки высокого уровня, а раскидывать работу на много потоков будет компилятор. Ну и для начала сделать параллельными популярные библиотеки подпрограмм.Вы понимаете же, что ни один компилятор без как минимум зачатков ИИ не сделает из произвольного однопоточного алгоритма многопоточный? Компиляторам доступно очень немного информации и они обязаны принимать консервативные решения. Да и часто даже неконсервативные решения даже потенциально не смогут помочь распараллелить, ибо алгоритм не параллелится. Компилятор может распараллелить код только если он написан так, что его можно распараллелить, к подавляющему большинству кода который пишется это не относится. Компилятор автоматом сможет распареллелить только то что он может потенциально сделать сейчас, например вместо векторизации он будет генерить параллельный код. Но от этого все станет намного медленнее, зачем так делать вообще?
Синхронизации не особо нужны, если использовать систему обмена сообщениями.А обмен сообщениями — это не синхронизация? Да и вообще, серьезно? Для того чтобы распараллелить умножение вектора на 1000 элементов — делать обмен сообщениями? Как я уже сказал — на сообщеиня уйдет больше времени чем на полезную работу.
Честно — даже смешно, насколько вы далеки от темы, о которой рассуждаете.
Видите ли, развитие технология однозначно вывели нас на необходимость многопоточных вычислений.С этим никто не спорил, не понятно откуда вы это взяли.
, и основное направление роста быстродействия — в увеличении числа ядер.Не только, еще как минимум в специализированнх инструкциях, в улучшении архитектуры.
Я не предлагаю разбросать SIMD по ядрам. Я предлагаю отказаться от SIMD вообщеНу вы полегче, я же подавлюсь опять. Какой профит выкидывать SIMD?
Но наверстать это за счёт увеличения числа ядер — благо отказ от SIMD понизит потребность в «транзисторах на ядро»; а значит, количество ядер можно будет увеличить.Серьезно? А затраты на синхронизацию вы в расчет не берете? Если все что параллелится в программе — это небольшие циклы — то векторизация с этим справится на ура, а вот раскидать это на множество ядер — там потери на синхронизацию будут больше чем выигрыш.
Распад СССР привёл к деградации образования. Во всех областях.Это не единственная страна и далеко не лидер была в области вычислительных технологий, поэтому и непонятно к чему вы ее привели, еще Демократическую Республику Конго приведите.
Э-э-э…Вы, видимо, не в курсе, но кроме ваших уютненьких популярных языков программирования есть нечто старое и не особо поддерживаемое. Но даже с современными программами — как вы всех заставите все перекомпилировать когда для многого даже исходников нету уже.
Наверно, Вы не заметили — но компиляторы постоянно переписываются.
Интересно было бы посмотреть исходный код высокоуровневого языка, для которого компилятор генерирует AVX-коды.И к чему это вообще?
Ну, например, в ядре операционки — где нужен FPU? (Ну, разве что в видеодрайвере.)Смешно. Во первых — FPU используется в каждом домашнем компьютере, если исключения и есть — они просто единичны и это очень вычурные случаи. Во вторых — зачем выкидывать FPU когда это принесет только проблемы?
Web-сервер, Proxy-сервер (Apache, Squid, Ngnix).
Файловый сервер Samba.
DNS-сервер? DHCP-сервер.
В ряде случаев имеет смысл проводить вычисления с фиксированной точкой.
Чтобы не надо было преобразовывать внешние команды во внутренние — надо просто чтобы компилятор изначально создавал код во внутреннем представлении.Ага, и зачем? Идеал — это когда процессор содержит доплонительные инструкции позволяющие компилятору давать «подсказки» наравне с существующими расширениями типа AVX, шифрования, кодеков и подобного.
И сложность процессора сразу на порядок снижаетсяИ повышается сложность всех компиляторов, и кому это нужно?
а значит, растёт надёжностьСовершенно не факт
и в плане поломокВо первых вообще не понятно как это влияет, во вторых — когда у вас последний раз ЦП из строя выходил?
повышается скорость каждого ядраКак раз таки понижается, потому что теперь ядро может выполнять только что-то примитивное и все что всякие AVX делают быстро оно будет теперь делать медленно.
можно сделать больше ядер.Ага, особенно учитывая что далеко не все хорошо параллелится. И даже то что параллелится — это же абсурдно, вместо того чтобы сделать быстрый ЦП — заставлять всех разработчиков софта делать хардкорную многопоточную оптимизацию алгоритмов.
Вы говорите странные и непонятные вещи. Ведь именно преобразователь традиционной системы команд в RISC-систему и является одним из наиболее сложных и тормозных элементов. И из-за этого преобразования приходится строить сложный кэш для кода, т.к. надо хранить преобразованный код. И хранить много, т.к. преобразование — процесс достаточно сложный
Это уже решенная проблема.
Про память, сейчас уже есть проблема с физическим расстоянием от планки ddr до кристалла cpu, т.к. скорость света в нашу вселенную слишком маленькую завезли.
Хм-м-м, я сейчас прикинул, взяв расстояние от процессора до память в десять сантиметров (учитывая размер модуля и тот факт, что сигнал по проводам идёт медленнее света). Получилось (300e3 km/s)/(0.1 m) = 3e9 s^-1
Т.е. это три гигагерца. А сейчас частота доступа к памяти перешла за один гигагерц.
Остаётся надеяться на увеличение hit rate (процент попаданий в кэш) — а это достигается увеличением кэша, что тоже малоприятно.
Правда, есть ещё вариант, за который я агитирую:
Отказаться от концепции «один многоядерный процессор и один пул памяти на все процессоры». Построить систему из множества процессоров — каждый в отдельном чипе, в каждом немного ядер, и в том же чипе (на том же кристалле или на отдельном кристалле в том же чипе) находится память.
Причём эта концепция предполагает существенную переделку программирования — надо будет учить компиляторы создавать многопоточные программы, да ещё работающие с раздельной памятью. Вероятно, надо будет создавать новые языки программирования, вынуждающие программиста создавать код так, что этот код будет легко распараллеливаться; или как минимум, библиотечные функции надо будет переписать в виде параллельных вычислений.
В существующих языках эту проблему можно будет решить примерно так:
Сейчас есть функция copystr, которая возвращает управление в программу после своего завершения. А надо будет сделать функцию parallel_copystr, которая возвращает дескриптор операции и выполняется в фоновом режиме. Когда программист хочет выяснить, в каком состоянии находится запрос — он вызывает функцию get_status (декскриптор_операции) и получает ответ типа «ещё выполняется» (м.б., с процентами выполнения) или «уже закончилась».
Далее программист вызывает wait_finish(декскриптор_операции) — эта функция ждёт завершения операции и делает декскриптор_операции бессмысленным (подобно тому, как декскриптор открытого файла становится бессмысленным после закрытия файла).
Короче говоря, традиционные методы увеличения скорости буксуют. А обсуждение новых методов тут минусуют.
Т.е. это три гигагерца. А сейчас частота доступа к памяти перешла за один гигагерц.
Остаётся надеяться на увеличение hit rate (процент попаданий в кэш) — а это достигается увеличением кэша, что тоже малоприятно.
Правда, есть ещё вариант, за который я агитирую:
Отказаться от концепции «один многоядерный процессор и один пул памяти на все процессоры». Построить систему из множества процессоров — каждый в отдельном чипе, в каждом немного ядер, и в том же чипе (на том же кристалле или на отдельном кристалле в том же чипе) находится память.
Причём эта концепция предполагает существенную переделку программирования — надо будет учить компиляторы создавать многопоточные программы, да ещё работающие с раздельной памятью. Вероятно, надо будет создавать новые языки программирования, вынуждающие программиста создавать код так, что этот код будет легко распараллеливаться; или как минимум, библиотечные функции надо будет переписать в виде параллельных вычислений.
В существующих языках эту проблему можно будет решить примерно так:
Сейчас есть функция copystr, которая возвращает управление в программу после своего завершения. А надо будет сделать функцию parallel_copystr, которая возвращает дескриптор операции и выполняется в фоновом режиме. Когда программист хочет выяснить, в каком состоянии находится запрос — он вызывает функцию get_status (декскриптор_операции) и получает ответ типа «ещё выполняется» (м.б., с процентами выполнения) или «уже закончилась».
Далее программист вызывает wait_finish(декскриптор_операции) — эта функция ждёт завершения операции и делает декскриптор_операции бессмысленным (подобно тому, как декскриптор открытого файла становится бессмысленным после закрытия файла).
Короче говоря, традиционные методы увеличения скорости буксуют. А обсуждение новых методов тут минусуют.
Ваши методы пригодны для спец процессоров, даже для декодирования jpeg + цветокоррекции под монитор уже не очень подходит, увы обмен данными между потоками очень важная штука, и современные компиляторы в т.ч. умеют делать так чтобы он иногда вмешался внутри процессора.
Да и ещё, хотя тут наверное уже приводили аргументы, распараллелить можно только небольшую часть алгоритмов, в случае же обработки больших объёмов данных спасает только огромный кэш и монструозные универсальные АЛУ.
Век risk в чистом виде, на мой взгляд, закончился на dec alpha у которых была сумасшедшая по тем временам тактовая частота, далее основное развитие пошло по увеличению количества выполняемых действий за такт (сейчас уже упёрлись в физические законы) и уже никак за счёт упрощения инструкций не вылезти. С увеличением разрядности тоже по сути достигли предела, просто некуда больше 4х каналов памяти пихать на материнку.
Про arm там не всё так хорошо с производительностью, но из-за особенностей устройств некоторые "стандартные" функции выносятся практически в отдельные устройства(блоки), для desktop-а таких возможностей меньше, т.к. процессор должен пережить несколько волн обновления ПО, и, к примеру, должен переварить новую версию алгоритма декодирования видео, а для арм достаточно встроенного полуаппаратного декодера который даже на момент покупки устройства уже не все алгоритмы(в том числе и подуровни одного h264) поддерживает.
Обратите внимание на декларативное программирование: там компилятор достаточно легко может обеспечить параллельность вычислений.
Собственно, оптимизирующий компилятор обычных языков тоже сначала пытается выделить декларативные куски программы. А дальше уже параллелит как минимум на уровне конвейера.
Чем Вам ARM — не RISC в чистом виде? А ARM разрабатывается до сих пор.
Кодековый сопроцессор — вещь вполне предсказуемая. Правда, лучше бы вместо него сделали дополнительное ядро, с отдельным кэшем и памятью.
А что «нехорошо с производительностью» у ARM? Ну, понятно, что с ограничениями мобильных устройств по энергопотреблению — производительность приходится ужимать. Но что мешает сделать настольный вариант ARM?
Собственно, оптимизирующий компилятор обычных языков тоже сначала пытается выделить декларативные куски программы. А дальше уже параллелит как минимум на уровне конвейера.
Чем Вам ARM — не RISC в чистом виде? А ARM разрабатывается до сих пор.
Кодековый сопроцессор — вещь вполне предсказуемая. Правда, лучше бы вместо него сделали дополнительное ядро, с отдельным кэшем и памятью.
А что «нехорошо с производительностью» у ARM? Ну, понятно, что с ограничениями мобильных устройств по энергопотреблению — производительность приходится ужимать. Но что мешает сделать настольный вариант ARM?
UFO just landed and posted this here
Я не очень понял, о каких задачах Вы говорите.
Обход дерева можно делать разными способами. Это не говоря о том, что деревья бывают разными. Да и цели обхода различаются.
Ну, рассмотрим случай поиска в двоичном дереве некого значения (уникального или повторяющегося). Очевидно, что просмотр корня не распараллеливается, а вот дальше можно параллельно обрабатывать левую и правую половины.
Обход дерева можно делать разными способами. Это не говоря о том, что деревья бывают разными. Да и цели обхода различаются.
Ну, рассмотрим случай поиска в двоичном дереве некого значения (уникального или повторяющегося). Очевидно, что просмотр корня не распараллеливается, а вот дальше можно параллельно обрабатывать левую и правую половины.
UFO just landed and posted this here
Выдадим каждому процессору свой диапазон номеров, чтобы диапазоны не пересекались. И пусть каждый нумерует.
А потом, когда будем знать, какой процессор сколько номеров использовал, напишем функцию преобразования номеров так, чтобы они были последовательными.
Или так: каждый процессор берёт номера из общего пула и присваивает их вершинам. Правда, порядок выборки будет другой — ну так иногда это можно.
Или раскидаем задачу поиска вершин по процессорам и составим список найденных вершин. А потом по списку занумеруем.
А потом, когда будем знать, какой процессор сколько номеров использовал, напишем функцию преобразования номеров так, чтобы они были последовательными.
Или так: каждый процессор берёт номера из общего пула и присваивает их вершинам. Правда, порядок выборки будет другой — ну так иногда это можно.
Или раскидаем задачу поиска вершин по процессорам и составим список найденных вершин. А потом по списку занумеруем.
Вы посчитали некую абстрактную частоту… причем судя по всему на этой частоте будет уже полное рассогласование — у процессора тактовый импульс уже прошел а до модуля памяти он только начал добираться. Т.е. нормальная синхронная работа в таких условиях попросту уже невозможна. А если учесть что для адресации ячейки в DRAM необходимо пройти 4 стадии, всё становится ещё печальнее. Поэтому память нынче пытается переходить на асинхронные последовательные интерфейсы.
Что касается параллельной обработки, то на рядовых задачах ваш параллельный процессор будет в сотню раз медленней классического.
Попробуйте ускорить за счет параллельных вычислений вычисление факториала.
Поэтому сейчас существует(и который год уже) разделение на центральный процессор и видеоускоритель — это как пример разных подходов к вычислениям. И почему-то который год ни один из этих подходов не может похоронить другой. Более того, делают ещё и специальные ASIC для математических вычислений которые уделывают по скорости счета как первые так и вторые, но полностью бесполезны в рядовых задачах.
Попробуйте ускорить за счет параллельных вычислений вычисление факториала.
Плохой пример. Его как раз можно распараллелить:
- Перемножать K (N + K) (2N K) … на каждом из N параллельных устройств.
- Итоговое перемножение длинных чисел тоже легко параллелится.
А вот хороший пример — регрессионные методы обработки изображений с использованием довольно большого словаря. С одной стороны, методы легко параллелятся — попиксельная обработка независима, но с другой отказаться от использования общей памяти (словаря) невозможно, т.к. его размер слишком большой для размещения в локальной памяти каждого из вычислительных потоков.
хранением довольного большого словаря.
Отказаться от концепции «один многоядерный процессор и один пул памяти на все процессоры». Построить систему из множества процессоров — каждый в отдельном чипе, в каждом немного ядер, и в том же чипе (на том же кристалле или на отдельном кристалле в том же чипе) находится память.
Суперкомпьютеры так и делают. Разве что память обычно все-таки находится рядом, а не на том же кристалле.
Но для обычных компьютеров или даже серверов такая архитектура попросту избыточна. Для такого числа ядер не найдется задач.
Если Вы внимательно посмотрите на историю компьютеров, то увидите в ней некую ступенчатость.
Что касается задач — это вообще не проблема. Нужное количество задач сгенерит компилятор; а чтобы ему было проще — под это дело придумают языки программирования со встроенной парадигмой параллельных вычислений.
Да собственно, работы в этом направлении уже имеются — в виде вычислений, производимых на видеокарте.
- Этап ламповых компьютеров мы опустим, я его плохо знаю.
- Первые большие ЭВМ по своей функциональности были похожи на программируемые компьютеры. Потом они получили кэш, многопроцессорность, многозадачность, многопользовательскость и вирт.машины.
- Потом появились мини-ЭВМ. Ну, размером где-то с большой платяной шкаф, примерно четыре девятнадцатидюймовые стойки. Они тоже начали с уровня программируемых калькуляторов (ну, может, чуть повыше) и доросли до Unix.
- Затем появились настольные компьютеры — сначала восьмибитные, потом дальше больше, и доросли до кэша, многопроцессорности (в т.ч. в виде многоядерности), многозадачности, многопользовательскости и вирт.машин.
- Сейчас идёт этап носимых компьютеров (смартфонов, планшетов). Кэш и многозадачность там есть, многопользовательскости и вирт.машин пока нет.
Что касается задач — это вообще не проблема. Нужное количество задач сгенерит компилятор; а чтобы ему было проще — под это дело придумают языки программирования со встроенной парадигмой параллельных вычислений.
Да собственно, работы в этом направлении уже имеются — в виде вычислений, производимых на видеокарте.
Компьютер с новым процессором Ryzen может подвесить любая вредоносная программа. Возможно, даже через браузер.Если у пользователя через браузер что-то самопроизвольно запускается (как раз в свежем Firefox закрыли такую уязвимость с автоматическим выполнением произвольного кода при посещении веб-страницы), то уже, честно говоря, всё равно, зависает оно, файлы шифрует или ПК как бота в ddos-ботнете использует. В этом случае всё уже плохо, независимо от процессора, и нужно скорее обновлять браузер.
Скорее речь о том, что сам браузер для каких-то подсчетов задействует эту инструкцию и упадет.
UFO just landed and posted this here
> Если у пользователя через браузер что-то самопроизвольно запускается
Какой процент пользователей имеет активный noscript? Остальных списывать в утиль?
Какой процент пользователей имеет активный noscript? Остальных списывать в утиль?
фтопку такой браузер от анб
*Здесь должна быть шутка про слоупоков*
Вчерашняя новость с полей:
«Гига уже пофиксила:
От человека который нашёл эту ошибку:
http://forum.hwbot.org/showpost.php?p=4… stcount=41
Цитата:
As an update, I'm now using the Gigabyte GA-AB350M.
With BIOS version F2, the system crashes on the flops benchmark.
With BIOS version F3c, it no longer crashes.
So indeed, this does appear to be fixed.»
Вчерашняя новость с полей:
«Гига уже пофиксила:
От человека который нашёл эту ошибку:
http://forum.hwbot.org/showpost.php?p=4… stcount=41
Цитата:
As an update, I'm now using the Gigabyte GA-AB350M.
With BIOS version F2, the system crashes on the flops benchmark.
With BIOS version F3c, it no longer crashes.
So indeed, this does appear to be fixed.»
Интересно, а AGESA наглухо закрыт всякими NDA и прочими 1024 битными AES ключами?
https://en.wikipedia.org/wiki/AGESA
AGESA source code was open-sourced in early 2011 to gain track in coreboot.
Раньше AGESA поставлялась в исходниках и была доступна для модификации любому желающему, но теперь AMD ударилась в PSP, начиная с Beema/Mullins для APU и Ryzen для CPU, прошивка которого в свою очередь подписана и зашифрована, и занимается он на этих процессорах не только реализацией fTPM, но и тренировкой памяти, т.е. ни отключить его, ни заменить его прошивку своей нельзя. В итоге от AGESA осталась теперь только обертка вокруг PSP и его встроенной ОС, которая с каждым новым поколением все тоньше.
А ещё, АМД в очередной раз ткнула Интел мордочкой в… салат, приварив 1331 ножку на подложку :D.
А можно подробней рассказать о чём речь? Звучит интересно — но сути не понимаю.
Ноги же, лапы! :)
Ладно уж, поясню ;).
Интел на сокетах J и T (LGA 771 и 775) жаловалась — ай, как много контактов, ну никак нельзя столько ног приварить к подложке — «сложна», поэтому мы сделали суперудобную вещь — ноги в сокете, а не на камне, вы ни за что больше не погнёте ноги у процессора при установке… вылилось (и продолжает выливаться) в десятки и сотни (а скорее тысячи) матерей с мятыми и оторванными контактами в сокетах (там чуть зацепил и всё, тем более контакты — крючки).
АМД, в то же время, продолжает выпускать сокеты 754, 939 и 940 (PGA-ZIF), AM2, AM2+, AM3, AM3+, FM1, FM2, с нормальными дырками, сказав, Штеуд — рукожопы (не совсем так, но близко к тексту).
Только на серверных F, F+, С32 (1207) и G34 (1974), АМД всё же использовала LGA. А теперь и в новом камне снова использует ноги — 1331 штука, у Интел же — 1150 (и 1356), но крючков (которые, я напоминаю, продолжают отрывать и мять). (про Socket R LGA2011 пока не говорю, хотя там они ещё меньше, а значит мягче)
Ладно уж, поясню ;).
Интел на сокетах J и T (LGA 771 и 775) жаловалась — ай, как много контактов, ну никак нельзя столько ног приварить к подложке — «сложна», поэтому мы сделали суперудобную вещь — ноги в сокете, а не на камне, вы ни за что больше не погнёте ноги у процессора при установке… вылилось (и продолжает выливаться) в десятки и сотни (а скорее тысячи) матерей с мятыми и оторванными контактами в сокетах (там чуть зацепил и всё, тем более контакты — крючки).
АМД, в то же время, продолжает выпускать сокеты 754, 939 и 940 (PGA-ZIF), AM2, AM2+, AM3, AM3+, FM1, FM2, с нормальными дырками, сказав, Штеуд — рукожопы (не совсем так, но близко к тексту).
Только на серверных F, F+, С32 (1207) и G34 (1974), АМД всё же использовала LGA. А теперь и в новом камне снова использует ноги — 1331 штука, у Интел же — 1150 (и 1356), но крючков (которые, я напоминаю, продолжают отрывать и мять). (про Socket R LGA2011 пока не говорю, хотя там они ещё меньше, а значит мягче)
маркетинг:
если люди жуют "там могла бы быть ваша реклама", то давайте по телеку рекламировать в роликах как нечто закидывает в рот 2 подушечки жвачки — профит! — продажи жвачки выросли на 40%… насчет ножек — себестоимость (без RN&D) кристалла для штеуд около 5$, ножки стоят 40 центов, профит!
если люди жуют "там могла бы быть ваша реклама", то давайте по телеку рекламировать в роликах как нечто закидывает в рот 2 подушечки жвачки — профит! — продажи жвачки выросли на 40%… насчет ножек — себестоимость (без RN&D) кристалла для штеуд около 5$, ножки стоят 40 центов, профит!
Но ведь сокеты-то делает не Интел, а… Foxconn, например (хм, чой-то и правда не знаю, кто им современные сокеты делает). И явно не по себестоимости, да ещё и учитывая бОльшую сложность и «технологичность», деньги же уплывают мимо… :).
Хотя, может именно этим объясняется (помимо временно отсутствовавшей конкуренции) всё не снижающаяся цена на камни?
Хотя, может именно этим объясняется (помимо временно отсутствовавшей конкуренции) всё не снижающаяся цена на камни?
Так во первых помять ножки на материнской плате все же труднее, во вторых — она зачастую стоит дешевле процессора, поэтому переместить ножки на сокет — здравая идея.
Ножки не на материнской плате, а в сокете на ней. Нет, нисколько не труднее, я уже рассказал, что и как происходит тысячами (я не шучу). Поверьте на слово, ножки на самом процессоре хоть и тоже гнутся, но и выправляются сильно проще, даже криворуким чайником. И даже оторванные, паяются в разы проще… и даже… в общем, «расскажите супруге, как борщ правильно варить» :P.
Чем хороши ножки на таких сокетах (открытых), расскажите «маркетологам» Штеуд, вдруг они чего-то не знают.
Чем хороши ножки на таких сокетах (открытых), расскажите «маркетологам» Штеуд, вдруг они чего-то не знают.
Ножки не на материнской плате, а в сокете на ней.А сокет значит не на материнской плате или как? Смысл то один и тот же.
Нет, нисколько не труднееТаки труднее, ножки там можно погнуть по сути только в процессе установки процессора, остальные случаи достаточно вычурные. Да и в процессе установки — это надо умудриться чтобы воткнуть процессор так чтобы ножки погнуть. В любом случае это пол беды, ибо те кто так втыкает — потом воткнут молотком DVI в USB.
я уже рассказал что и как происходит тысячами случаев.А, ну тогда конечно. Я тогда рассказываю что на процессорах ножки гнулись миллионами случаев, а на материнских платах как вы говорите — тысячами, вот и разобрались.
«расскажите супруге, как борщ правильно варить» :P.Что за сексизм?
А сокет значит не на материнской плате или как?
ну что за… ведь нарочно написал:
а в сокете на ней
Нет, смысл разный! В сокете они как бы должны быть защищены, как защищены такие же контакты в других сокетах и слотах, память, видеокарты, карты расширения, да даже дополнительные гнёзда для задней и передней панели — часто находятся в более менее защищающем их корпусе.
ножки там можно погнуть по сути только в процессе установки процессора...
А ножки самого процессора можно погнуть в любое время дня и ночи… ага! Пофигу, что до установки он находится в блистере и коробке, а после, к нему точно так же нет доступа.
Да, именно так и гнут и вырывают ножки и там и там. Но, ещё раз, — ножки в сокете — крючки. Аналогично липучке Velcro (то стороне, что с крючками) цепляется за любой ворс, за ногти, за заусенцы на коже… и т.п. Вы хотите поспорить о статистике? А я не хочу. Потому что я указал только на мифическую сложность приваривания лап, на которую напирала Штеуд.
Что за сексизм?
Это вообще-то известная «пословицы и поговорки народов мира» — «Поучи жену щи варить».
Нет, смысл разный!Это чисто придирка к словам. Давайте я тоже попридираюсь — не в сокете, а в сокете под крышечкой. Это как бы тоже в сокете, но под крышечкой. То же самое как в сокете на материнской плате — это тоже на материнской плате, но в сокете.
А ножки самого процессора можно погнуть в любое время дня и ночи… ага! Пофигу, что до установки он находится в блистере и коробке, а после, к нему точно так же нет доступа.Только вот маленький лежащий где-то процессор намного больше подвержен поломке ножек.
цепляется за любой ворс, за ногти, за заусенцы на коже… и т.п.Вот уж какие страсти расказываете.
Вы хотите поспорить о статистике? А я не хочу.Ну тогда и не приводите свои «тысячи» взятые с потолка. Да и при том не понятно «тысячи» от какого числа.
Потому что я указал только на мифическую сложность приваривания лапТак делать пины на материнской плате можно и маленькие, потому что они более защищены, а на процессоре маленькие пины — это проблема, особенно учитывая что процессор обычно дороже материнской платы.
на которую напирала Штеуд.У вас кнопки переключения раскладки клавиатуры зацепились за ворс/ногти/заусенцы на коже и не работают?
У меня стойкое ощущение, что вы не читаете комментарии до комментирования или вообще общаетесь с кем-то в собственной голове, который пересказывает вам окружающую действительность.
Каждый раз, предвосхищая возможное возражение, пишу поясняющую фразу, но в итоге…постоянно одно и то же.
Нет! А знаете почему?
Как и сокет, защищёный крышкой, но только в первый раз, если мы не работаем с владельцем, отчего-то сохранившим, а не выломавшим крышку. Вот только, в третий раз:
погнутые и даже оторванные ножки — ремонтируются легче, потому что:
— находятся на не то чтобы свободном, но достаточно открытом пространстве в несколько квадратных сантиметров, сильно доступнее паяльнику, пинцету и т.п.
— сокет же, расположенный на материнской плате, при необходимости ремонта — сложнее, в том числе, потому что?
— расположен на материнской плате, в окружении других деталей и местный нагрев большой платы, с кучей меди — штука не сильно полезная, его ножки-крючки находятся среди других, таких же крючков,
Статистика ремонтов, в том числе из нескольких сц. В общем-то я и не собирался её доказывать, потому что, в третий раз:
показательное отношение, всего-то.
Каждый раз, предвосхищая возможное возражение, пишу поясняющую фразу, но в итоге…
маленький лежащий где-то процессор намного больше подвержен поломке ножек
Нет! А знаете почему?
до установки он находится в блистере и коробке, а после, к нему точно так же нет доступа.
Как и сокет, защищёный крышкой, но только в первый раз, если мы не работаем с владельцем, отчего-то сохранившим, а не выломавшим крышку. Вот только, в третий раз:
ножки процессора — не крючки
погнутые и даже оторванные ножки — ремонтируются легче, потому что:
— находятся на не то чтобы свободном, но достаточно открытом пространстве в несколько квадратных сантиметров, сильно доступнее паяльнику, пинцету и т.п.
— сокет же, расположенный на материнской плате, при необходимости ремонта — сложнее, в том числе, потому что?
— расположен на материнской плате, в окружении других деталей и местный нагрев большой платы, с кучей меди — штука не сильно полезная, его ножки-крючки находятся среди других, таких же крючков,
взятые с потолка
Статистика ремонтов, в том числе из нескольких сц. В общем-то я и не собирался её доказывать, потому что, в третий раз:
указал только на мифическую сложность приваривания лап, на которую напирала Штеуд.
кнопки переключения раскладки клавиатуры зацепились
показательное отношение, всего-то.
У меня стойкое ощущение, что вы не читаете комментарии до комментирования или вообще общаетесь с кем-то в собственной голове, который пересказывает вам окружающую действительность.У меня стойкое ощущение что у вас обида на Intel и вы пытаетесь выдумать статистику из воздуха чтобы хоть как-то подтвердить свое мнение.
Нет! А знаете почему?Ну вам виднее, конечно. Везде все говорят о преимуществе LGA потому что ножки на процессоре не ломаются, а на материнской плате сломать сложнее и она стоит дешевле. Но вам виднее. Когда вы вытащите процессор из блистера — он уже подвержен поломкам если там ножки. Вы его уронили — ножка может сломаться, еще он маленький, его можно случайно задеть. Это очевидные вещи.
Как и сокет, защищёный крышкой, но только в первый раз, если мы не работаем с владельцем, отчего-то сохранившим, а не выломавшим крышку.Что значит «в первый раз»? Если кто-то меняет процессор, то у него как бы в сокете прошлый процессор стоит. При этом если заменять процессор — к старому надо или блистер сохранять или класть в пакетик, а материнская плата даже при замене без замены процессора (и как часто это происходит?) — все равно в большей безопасности. Это если рассматривать ваши «вторые разы».
погнутые и даже оторванные ножки — ремонтируются легчеПри чем тут сложность ремонта (вообще официальные СЦ ремонтируют ножки процессоров?), когда речь о том что поломок меньше.
Статистика ремонтов, в том числе из нескольких сц. В общем-то я и не собирался её доказывать, потому что, в третий раз:Статистику в студию. И не плохо было бы еще посмотреть статистику поломок процессоров с ножками.
показательное отношение, всего-то.Это примерно как в начальных классах школы дети коверкают фамилии тех кто им не симпатичен? Понятно.
Нет никакой обиды, но…
Хотите поспорить, поспорьте с этим:
Хотите поспорить, поспорьте с этим:
АМД в очередной раз ткнула Интел мордочкой в… салат
Статистику в студию
..\|/
../.\
./...\
/.|||.\
Понятно, т.е. аргументов нету — можно и шалашики рисовать?
Есть! И озвучен уже 5 раз.
АМД приварила к подложке 1331 лапу. Интел «не шмагла», ещё вопросы?
АМД приварила к подложке 1331 лапу. Интел «не шмагла», ещё вопросы?
Да кто сказал что «не смогла»? Что за бред? Это осознанное решение, потому что оно лучше. С чего бы Intel возвращаться к старому решению, которое они уже улучшили?
Тогда это AMD не смогла сделать контактные площадки.
Тогда это AMD не смогла сделать контактные площадки.
«мальчик, ты дурак?»
Ezhyg 23 марта 2017 в 12:58 (комментарий был изменён) #
Но ведь сокеты-то делает не Интел, а… Foxconn, например
Вот смешно. Во первых аргументы кончились — начались переходы на личности.
А во вторых:
А во вторых:
АМД приварила к подложке 1331 лапу. Интел «не шмагла», ещё вопросы?Т.е. у вас у самого с собой противоречие. Вы уж определитесь, или «Intel не смогла» можно говорить, а «AMD не смогла» нельзя?
аргументы кончились — начались переходы на личности.
всего-лишь пытаюсь взывать к зайчаткам разума
Не хотите выглядеть глупо? Не надо в восемнадцатый раз вопрошать ответы на вопросы, которые были отвечены ещё до вашего врывания в этот тред.
Тезисно.
Лапы к процессору приваривает сам производитель процессоров.
Ноги в сокете — производитель сокета.
То что одна фирма смогла припаять ноги к процессору, не значит, что она может или не может, надо ей или не надо уметь делать это же с сокетом. Патамушта ей даже сокет не нужно иметь, от слова совсем. Его производят другие фирмы (даже не одна, да) и ставить будут, каким бы странным вам это ни казалось, другие производители, материнских плат.
Отказаться от ног не сложно, у АМД есть такое, я уже приводил примеры, но вы же опять «чукча не читатель, чукча писатель».
За сим я заканчиваю беседу, ибо чуйствую, что разговариваю с глупцом, вынуждающим меня повторять по восемь раз уже сказанное.
P.S. «карма» там =>
Вот вам как раз не надо в десятый раз путаться в трех соснах, у вас какая-то слепая обида на Intel похоже. Intel делает LGA — они «не могут сделать ноги», а AMD делает ноги — это не «не могут делать LGA» — это «им не надо». Смешно же, такая махровая предвзятость.
Уже 10 раз вам одно и то же пишут, никак вы осознать не можете.
То что одна фирма смогла припаять ноги к процессору, не значит, что она может или не может, надо ей или не надо уметь делать это же с сокетом. Патамушта ей даже сокет не нужно иметь, от слова совсем. Его производят другая фирма и ставить будут, каким бы странным вам это ни казалось, другие производители, материнских плат.Ну вот, опять сами себе противоречите. Т.е. Intel тоже ведь ничто не мешает ноги к процессору сделать. И то что они сейчас не делают, потому что у них есть решение получше — опять же никак не значит что они не могут делать, просто им это не нужно, от слова совсем, потому что у них, опять же — есть решение лучше.
Отказаться от ног не сложно, у АМД есть такое, я уже приводил примеры, но вы же опять «чукча не читатель, чукча писатель».Так и у Intel были процессоры с ногами раньше, нашли решение лучше и отказались от этого. Вернуть ноги не сложно, просто у Intel отработано решение получше.
Уже 10 раз вам одно и то же пишут, никак вы осознать не можете.
Банально при снятии кулера в LGA верхняя крышка держит процессор и не дает ему «прилипнуть» на термопасте к радиатору. А вот обычные процессоры с ногами довольно часто вынимаются из сокета вместе с радиатором, т.к. ногами-же за сокет и держутся. Некоторые, особо удачливые, ещё и ногу в сокете забыть при этом могут.
UFO just landed and posted this here
На мой взгляд — чистый пи-ар, побуждающий купить проц и потестить баг — «чистая капуста»!
AMD «прочухали» предыдущий «кипиш» по поводу ошибки в TLB в Фенах 9х00 и вполне себе прилично выдали 9х50,
Но! — сколько шума было поднято! — а это крути — не крути а всё же «раскрутка».
Ну и как вариант — что баг по TLB, что текущее зависание по FMA3 —
механизм влияния на покупателя —
вот он, нормуль проц!, раньше стоил 500$, вполне себе конкурент интелам за 500$ — они практически равны — амд даже обгоняет, НО!, там есть случайный баг — вы его никогда не заметите и никогда в жизни не встретите, но какой-то криво написанный тест не для виндовса — «подвешивает» систему при запуске в виндовсе — вы точно такого не увидите за всю жизнь, НО!, мы теперь написали патч, исправляющий эти ошибки, + к этому ещё снизили цену на процы на 20% —
— выбирайте: или интелы за 500, или наши, более быстрые, за 400 с пофиксенным багом
Выдали пробный шар — «зарядили» цены вровень с конкурентами — посмотрели на интенсивность и потенциал спроса — технично, лаконично, и раздуто-рекламно понизили цены — ПРОФИТ!
AMD «прочухали» предыдущий «кипиш» по поводу ошибки в TLB в Фенах 9х00 и вполне себе прилично выдали 9х50,
Но! — сколько шума было поднято! — а это крути — не крути а всё же «раскрутка».
Ну и как вариант — что баг по TLB, что текущее зависание по FMA3 —
механизм влияния на покупателя —
вот он, нормуль проц!, раньше стоил 500$, вполне себе конкурент интелам за 500$ — они практически равны — амд даже обгоняет, НО!, там есть случайный баг — вы его никогда не заметите и никогда в жизни не встретите, но какой-то криво написанный тест не для виндовса — «подвешивает» систему при запуске в виндовсе — вы точно такого не увидите за всю жизнь, НО!, мы теперь написали патч, исправляющий эти ошибки, + к этому ещё снизили цену на процы на 20% —
— выбирайте: или интелы за 500, или наши, более быстрые, за 400 с пофиксенным багом
Выдали пробный шар — «зарядили» цены вровень с конкурентами — посмотрели на интенсивность и потенциал спроса — технично, лаконично, и раздуто-рекламно понизили цены — ПРОФИТ!
Ох уж эти разоблачения.
Самсунг наверное тоже взрывающиеся телефоны сделал, чтобы попиариться.
Самсунг наверное тоже взрывающиеся телефоны сделал, чтобы попиариться.
И такие комментарии тоже были.
а может зря Вы так скептически настроены?
— «Есть многое на свете, друг Горацио, что и не снилось нашим мудрецам»
тут не столько разоблачения и сами процессоры и их показатели, сколько вирусно-раздуваемая шумиха о них, сами-же процессоры могут быть от отвратительно глючных, до обалденно высокопроизводительных, НО!, без «шумихи» — о них никто не узнает, и к сборщикам не будут бегать с «хотелками»: «хотю» только RYZEN!
К примеру, пусть даже nVidia выпустит процессор, обгоняющий ТОП от Intel на 30%, за ту же цену, но без рекламы и раскрутки — это будет просто инженерный семпл, который никому не известен и нафиг никому не нужен, пока о нём молчат.
— «Есть многое на свете, друг Горацио, что и не снилось нашим мудрецам»
тут не столько разоблачения и сами процессоры и их показатели, сколько вирусно-раздуваемая шумиха о них, сами-же процессоры могут быть от отвратительно глючных, до обалденно высокопроизводительных, НО!, без «шумихи» — о них никто не узнает, и к сборщикам не будут бегать с «хотелками»: «хотю» только RYZEN!
К примеру, пусть даже nVidia выпустит процессор, обгоняющий ТОП от Intel на 30%, за ту же цену, но без рекламы и раскрутки — это будет просто инженерный семпл, который никому не известен и нафиг никому не нужен, пока о нём молчат.
Sign up to leave a comment.
Инструкции FMA3 в Ryzen намертво вешают операционную систему