Как выяснилось, выполнение некоторых специфичных инструкций FMA3 на процессоре AMD Ryzen приводит к критическому сбою ОС.
Инструкции типа FMA3 (Fused-Multiply-Add) поддерживаются и Intel (в Haswell), и AMD. Это инструкции типа
d = round(a ? b + c), где d должна быть в том же регистре, что и a, b или c. Для сравнения, инструкции FMA4 поддерживает только AMD (в процессорах Buldozer и более поздних). Там a, b, c и d могут быть в разных регистрах.Баг в процессоре обнаружен во Flops version2 — простой и малоизвестной утилите для тестирования ЦП. Следует заметить, что разработчик этой утилиты Александр "Mystical" Йи (Alexander «Mystical» Yee) позиционирует её как специфическую утилиту тестирования, которая чувствительна к микроархитектуре процессоров. В других бенчмарках баг так и не проявился.
С утилитой Flops version2 поставляются специфические бинарники для всех основных архитектур x64 (Core2, Bulldozer, Sandy Bridge, Piledriver, Haswell, Skylake). Но на данный момент ни среди бинарных сборок под Windows, ни под Linux нет версии для тестирования Zen. Поэтому сейчас для тестирования Ryzen применяли бинарники других архитектур, а именно наиболее близкой Haswell. Вышеупомянутая ошибка с инструкциями FMA3 обнаружена две недели назад самим автором программы Flops, когда он запустил тест со стоковым бинарником для Haswell на компьютере следующей конфигурации:
- Ryzen 7 1800X
- Asus Prime B350M-A (BIOS 0502)
- 4 x 8GB Corsair CMK32GX4M4A2400C14 @ 2133 MHz
- Windows 10 Anniversary Update
Внезапно обнаружилось, что система обычно зависает при выполнении следующей операции:
Single-Precision - 128-bit FMA3 - Fused Multiply Add:Иногда тест проходит эту операцию успешно, но всё равно зависает на какой-нибудь другой операции в дальнейшем.
Разработчик объясняет, что его тест — с открытым исходным кодом, и если вы не доверяете результатам, то можете сами взять и скомпилировать бинарник в Visual Studio, и перепроверить результаты.
Александр понимал, какое внимание привлечёт, сообщая об ошибке в разрекламированном процессоре. Поэтому он многократно перепроверил результаты. Процессор вешал систему на всех тактовых частотах. А при работе в однопотоковом режиме систему вешало каждое ядро.
Оставались какие-то вероятности, что причина сбоя может быть всё-таки не в процессоре, а в чём-то другом. Например, в специфической материнской плате, в специфическом BIOS, в специфической операционной системе… Что ещё может быть?
Разработчик поделился результатами с коллегами, чтобы они проверили другие версии Zen на своих компьютерах. Сбои подтвердились и для других процессоров, на разных материнских платах, под разными версиями Windows и под Linux.
В первые дни после призыва Алекса тесты запустили пять владельцев процессоров Ryzen. Вот какие получены результаты:
Подтверждённые сбои:
- 1800X + Asus Prime B350M-A (BIOS 0502)
- 1700 + Asus Prime B350M-A (BIOS ???)
- 1700 + Asus Crosshair VI Hero
- 1700 + Asus Crosshair VI Hero (BIOS 5803) (два банка памяти G.Skill + Kingston)
- 1800X + Asus Crosshair VI Hero (Windows 7) — один раз прошёл тест, многократно не прошёл.
Подтверждённая бессбойная работа:
- Пока нет
Разработчик бенчмарка проверил все варианты FMA (128 бит, 256 бит, одинарная точность, двойная точность чисел). Во всех случаях компьютер намертво зависал.
Ему не давала покоя только одна деталь: хотя тест написан правильно, но почему-то зависания не присходило в других бенчмарках, таких как prime95 и y-cruncher, хотя они тоже используют FMA в тестировании.
Так что некоторая неопределённость оставалась.
В конце концов, 16 марта было получено официальное сообщение от представителя AMD, что баг будет исправлен в новом коде AGESA (AMD Generic Encapsulated Software Architecture) — протокола, который используется в том числе для инициализации ядер процессоров AMD. Другими словами, специалисты компании проверили и подтвердили баг. Позже представители AMD официально подтвердили баг в комментариях для СМИ.
К счастью, такой баг можно исправить без замены железа, а просто обновлением микрокода. Баг незначительный, так что он не вызовет отзывы процессоров или какие-то другие проблемы для компании. Фактически, в реальных условиях работы вряд ли кто-то когда-либо может столкнуться с этим багом, он никак не сказывается ни на работе компьютера, ни на производительности процессора.
Плохая новость в том, что его могут использовать злоумышленники для DoS-атак. То есть главным образом эта ошибка — проблема информационной безопасности. Ведь обычная пользовательская программа, работающая в user mode, а не на уровне ядра ОС, никак не должна намертво вешать систему. Но это происходит.
То, что тест запускали на бинарнике для другой архитектуры — не так принципиально. Любой процессор должен успешно воспроизводить тесты из любого бинарника, если он поддерживает соответствующий набор инструкций, пишет автор бенчмарка. Но даже если запустить тест с использованием несовместимых инструкций, программа не должна вешать систему намертво.
Опасность уязвимости в безопасности усугубляется тем, что вредоносный код можно запустить даже из-под виртуальной машины, он всё равно подвесит всю систему. Компьютер с новым процессором Ryzen может подвесить любая вредоносная программа. Возможно, даже через браузер.
Как уже было сказано, AMD работает над обновлением протокола AGESA. После этого патчи будут выпущены для всех версий BIOS во всех материнских платах.
Комментарии (127)
dimitry78
22.03.2017 19:40-9«Но на данный момент ни среди бинарных сборок под Windows, ни под Linux нет версии для тестирования Zen.»
«то можете сами взять и скомпилировать бинарник в Visual Studio» (рекурсия на предыдущюю цитируемую строчку)
«простой и малоизвестной утилите для тестирования ЦП.»
«В других бенчмарках баг так и не проявился.»
Простой PR «простой и малоизвестной утилите»…?zikasak
22.03.2017 19:46«сейчас для тестирования Ryzen применяли бинарники других архитектур, а именно наиболее близкой Haswell.»
dimitry78
23.03.2017 12:31-3да блин, у меня старый atom, если я на нем скомпилирую gentoo с флагами от другого камня — тоже наверное заглючит и уйдет в мертвый перезагруз… а так — на fx64 с «проблемой» TLB — годами и рендерил и в нфс и батлфиелд гонял…
mayorovp
23.03.2017 13:26+1Одно дело — ядро ОС под другую архитектуру. Другое дело — пользовательская программа. Для пользовательской программы, собранной под другую архитектуру, допустимым является только одно поведение — аварийное завершение процесса, но никак не зависание компьютера!
dimitry78
23.03.2017 13:41-2пользовательская программа «в идеале» запускается под api os и по барабану железо, камень.
а совсем в идеале это дум3 — вот как накарябыли, а до сих пор идет, и под ХР и w7 и w10mayorovp
23.03.2017 13:43+1API OS не дает абстракций над инструкциями процессора.
Какое API вы вообще предлагаете использовать для сложения двух чисел? А умножения? Округления?
dimitry78
23.03.2017 13:52-3предпочитаю абак — для сложения двух чисел.
в пост-индустриальную эпоху:
блин, тогда на асме
для софта, некритичного к качеству и скорости апи-ос, если известна архитектура камня, то с учетом регистров,
DistortNeo
23.03.2017 14:29Да, для этого дела уже придумали всякие байт-коды и MSIL.
Но пока производительность нативного кода в разы выше, от процессоро-зависимого кода никуда не деться.
dimitry78
23.03.2017 13:46-2писал я както на недокументированных особенностях opengl — на риве работало на жтикс стоко гемора вылезло, но, на рива тнт можно было почти джефикс про получить
0xd34df00d
24.03.2017 03:43Заглючит только в том случае, если там будут неподдерживаемые инструкции (и в юзерспейсе вы получите SIGILL). Если вы соберете с флагами от i386, то ничего страшного не будет.
mikhaelkh
22.03.2017 20:32Утилита может и малоизвестна, но y-cruncher от него же любители бенчмарков знать должны.
geisha
22.03.2017 19:47К счастью, такой баг можно исправить без замены железа, а просто обновлением микрокода.
d = round(a ? b + c)Будет три такта вместо одного, ну вы поняли. Мне даже стало интересно, что там исправляют в intel-microcode.
stanislavshwartsman
22.03.2017 20:57+8Скорее всего ничего не будет.
Современные процессоры у давно гораздо сложнее чем просто правильно посчитать тот же самый FMA, но еще и очень навороченный power management. Power management мониторит все основные узлы ядра и пытается открывать и закрывать блоки которые на данный момент не используются, чтобы потреблять меньше энергии. А еще нужно заботиться о возможно перегреве — нельзя дать FMA unit без остановки молотить числа потому что он может банально перегреться и транзисторы начнуть давать сбои. Еще нужно заботиться о скачках напряжения которые могут возникать при быстрых переходах от полной нагрузки до idle и многом другом.
Большинство багов связано как раз с power management — в лаборатории на тестах AMD может все работало а тут у вас дома на никому не извесном бенчмарке может выявляться баг. И патче проблему решают фиксом power management алгоритмов или clock gating логики.
lizarge
22.03.2017 20:35-1Плохая новость в том, что его могут использовать злоумышленники для DoS-атак.
Wizard_of_light
22.03.2017 21:15Кстати, а как? Это надо найти сервер на райзене и пропихнуть туда зловреда с нужным кодом, чтобы его уронить. Но если уж нам чего-то исполняемое удалось пропихнуть на сервер, то уронить его не такая проблема. Да и вообще ронять такой хороший сервер уже незачем :)
VBKesha
22.03.2017 21:57+3Сейчас любят на сервера ставить виртуализацию, и продавать по кусочкам. Как написано в статье система упадёт даже если код исполнят на виртуалке. Вот если кто то сделает VPS на Ryzen, вы можете купить один инстанс за 100 рублей в месяц и ронять целый сервер. А если предположит что JS например при своём выполнении может выполнять эту команду, то можно ронять страницы всех посетителей сайта где сможете разместить нужный код.
pda0
23.03.2017 00:15+4Найти софт, в котором есть эта команда и найти способ заставить её выполниться нужным образом. Путём передачи определённого запроса, например. Сам понимаю, насколько это кажется трудным и невероятным, но когда народ ухитряется эксплуатировать rowhammer из javascript можно уже ничему не удивляться.
dimitry78
23.03.2017 12:36-1уроните сервак в «мертвый перезагруз» — ну и че? если только онлайн-сервис уронить.
«У нас вася вчера сервак уронил — крутой хакер? — да не, просто дятел, он его себе на ногу уронил»
Dee3
22.03.2017 21:30-3Это можно рассматривать и как спланированную акцию «черного пиара» — очень много внимания привлекается в последнее время к «новейшим недорогим процессорам AMD».
evilrussian
23.03.2017 09:37+2По этой логике продажи телефонов Самсунга, после недавних событий, должны были взлететь.
Dee3
23.03.2017 10:01-3Уверены что полностью поняли логику комментария?
Если вы имели ввиду историю про аккумуляторы — то вы сравнили теплое с фиолетовым.
Аппаратные проблемы, взрывающиеся телефоны, пострадавшие люди, отзыв партий телефонов, отмена продаж — ущерб компании.
Софтовая проблема в бенчмарке, быстрая реакция компании, программный фикс — пиар и профит.Ra-Jah
23.03.2017 10:11Если хотите, рассматривайте как пиар (непонятно почему чёрный), в конце концов развитие ЦПУ в современных реалиях это немалая заслуга маркетинга. Порой, умелое поведение в критической ситуации может сыграть на руку, а безалаберное отношение к деталям провалить даже, казалось бы, непотопляемую компанию.
Dee3
23.03.2017 10:31непонятно почему чёрный
Ок не черный. Но саму ситуацию «Ryzen намертво вешают операционную систему» трудно назвать повыщающей имидж компании.
в конце концов развитие ЦПУ в современных реалиях это немалая заслуга маркетинга
Разве я спорю или говорю что это плохо?
Всего лишь констатирую факт — описанная ситуация я считаю в целом не столько бросает тень на процессоры AMD, сколько все таки привлекает внимание к новой линейке. И это вполне могло быть обыграно маркетологами AMD на несколько ходов вперед.
Не понятно только за что фанаты-минусаторы борются. Пригорает от того что AMD умеет грамотно использовать маркетинговый ресурс?
dimitry78
23.03.2017 13:08-2мб (асус) для ам3+ 6тр, камень (8320Е) 6 тр, — райзен 22700 + память… — нет дров для ХР…
Karpion
22.03.2017 21:33-8Я упорно не понимаю, почему производители никак не могут один раз подумать и сделать законченную систему команд процессора. А вместо этого постоянно допиливают систему команд, добавляют новые команды — и вносят новые баги.
Неужели так сложно сформировать систему команд по типу ARM (ну или другого RISC-процессора, хотя принципы у них одинаковые), но с 64-битной адресацией памяти. Размер регистра нужен не менее, чем разрядность адресации памяти; но можно делать и больше, есть варианты использования больших регистров, особенно при копировании больших массивов.
А развиваться процессоры будут за счёт увеличения тактовой частоты, снижения числа таков на исполнение каждой команды, увеличения числа ядер, увеличения размера кэша, изменения архитектуры кэша, etc.DistortNeo
22.03.2017 21:44+2Дело не в системе команд, а в невероятной сложности процессора.
Если бы возможность наращивания частоты была, ею бы пользовались. Но сейчас добиваются роста производительности как раз за счёт снижения числа тактов на исполнение команд и суперскалярности. Неудивительно, что вероятность ошибки накапливается многократно.
Maccimo
23.03.2017 09:20+7«Я упорно не понимаю, почему производители никак не могут один раз подумать и сделать самый быстрый процессор. А вместо этого постоянно допиливают архитектуру процессора, уменьшают техпроцесс, выпускают новые модели».
Alexeyslav
23.03.2017 15:21-1А давайте… вот чего физики медлят? Пусть один раз подумают хорошенько и сразу выдадут нам и термояд, и телепортацию… а, чего они тянут резину?
Не от того ли это, что все новинки это постоянно передовая технология, и выше головы не прыгнешь хоть 2 года перед этим силы копи.mayorovp
23.03.2017 16:50Пожалуйста, почините свой сарказм-детектор. Ваши слова стоило бы адресовать юзеру Karpion, а не Maccimo.
dimitry78
23.03.2017 13:02«Я упорно не понимаю, почему производители никак»
«Дело не в системе команд, а в невероятной сложности процессора.»
вывод: инструмент стал сложнее создателя, не, я не призываю вернутся на ВМ38,Karpion
23.03.2017 21:03Концепция RISC-процессора предполагает, что редко используемые команды вообще ликвидируются (не реализуются ни аппаратно, ни в микрокоде), а программист-ассемблерщик или компилятор реализует нужную функциональность через простой набор команд. Соответственно, процессор становится проще — требует меньше транзисторов и соединительных линий. А значит, вероятность ошибок проектирования снижается.
Т.е. я утверждаю, что сложность процессора в первую очередь определяется системой команд. Например, процессор без сопроцессора — заведомо проще.
VenomBlood
23.03.2017 21:34И зачем такое нужно? Это из серии «давайте везде использовать сортировку пузырьком, зачем плодить алгоритмы».
Karpion
23.03.2017 22:08-2Пузырёк с переменным шагом имеет предельную (теоретически возможную) скорость сортировки. Что Вам не так?
VenomBlood
23.03.2017 22:30Вы серьезно?
Во первых что за «пузырек с переменным шагом»? Вы о Comb Sort? Так он в худшем случае O(n2)
Во вторых — асимптотическая сложность — далеко не единственный показатель, который важен в алгоритме
В третьих — есть специализированные случаи, когда используя знания о входных данных можно достичь гораздо лучших показателей чем используя общие методы
DistortNeo
23.03.2017 23:01+3Современные процессоры уже давно являются RISC-процессорами на низком уровне: процессор разбирает команды на элементарные. Да, это усложняет процессор, но вклад в общую сложность здесь невелик.
Большую часть площади кристалла (около половины) занимает кэш. Думаете в RISC-процессорах нет кэша? Ещё как есть. Хотите отказаться от кэша? Придумайте быструю замену DRAM.
Далее идёт суперскалярность. Раз нельзя наращивать частоту, приходится увеличивать пропускную способность конвейера за счёт увеличения числа блоков, работающих параллельно. Предсказание переходов, out of order execution — всё это будет нагружать как RISC, так и традиционный процессор.
Ну и вишенка на торте — неравномерность нагрузки. AVX/FMA-инструкции очень сильно нагружают процессор, и переходом на RISC-арихитектуру проблему не решить — вычислений меньше не станет.
Karpion
24.03.2017 01:55-2Современные процессоры уже давно являются RISC-процессорами на низком уровне: процессор разбирает команды на элементарные. Да, это усложняет процессор, но вклад в общую сложность здесь невелик.
Вы говорите странные и непонятные вещи. Ведь именно преобразователь традиционной системы команд в RISC-систему и является одним из наиболее сложных и тормозных элементов. И из-за этого преобразования приходится строить сложный кэш для кода, т.к. надо хранить преобразованный код. И хранить много, т.к. преобразование — процесс достаточно сложный
Большую часть площади кристалла (около половины) занимает кэш.
Я как-то сильно сомневаюсь, что кэш может повлиять на ошибки в процессоре типа той, что описана в статье. Да и ошибка деления Пентиума тоже никак не касалась кэша.
Хотите отказаться от кэша? Придумайте быструю замену DRAM.
Совсем отказаться от кэша невозможно т.к. производители, ориентируясь на кэш, не разрабатывают быстрой памяти. Однако, есть несколько вариантов снижения потребности в кэше:- Увеличение количества регистров — одна из главных фишек RISC-процессоров.
- Использование регистрового файла (т.е. фактически создание для каждого ядра своего собственного пула памяти в схеме NonMA).
- Выделение каждому процессору собственной памяти в полноценной схеме NonMA.
- Отказ от прозрачного для программ совместного использования памяти. Теперь, чтобы программа на одном ядре могла записать в память данные, а программа на другом ядре могла прочитать эти данные — программы должны явно указать кэшам своих ядер факт передачи памяти в распоряжение другого ядра.
- Ну или хотя бы ввести в дескрипторы страниц указание на то, используется ди эта страница монопольно или совместно несколькими ядрами. Для монопольных страниц не надо синхронизировать кэши.
Наверно, Вы уже заметили, что большинство пунктов требуют отказаться от совместимости с системой команд *86.
Далее идёт суперскалярность. Раз нельзя наращивать частоту, приходится увеличивать пропускную способность конвейера за счёт увеличения числа блоков, работающих параллельно.
Увеличивать параллельность можно увеличением количества ядер. Правда, для этого надо разрабатывать теорию параллельных вычислений — а с этим туго, т.к. за последние четверть века с распада СССР образование деградировало.
А чтобы построить нормальную суперскалярность — опять же надо менять систему команд процессора: надо не заставлять процессор на ходу угадывать, что можно суперскалярить, а что нельзя — а явно прописать это в командах процессора.
Предсказание переходов, out of order execution — всё это будет нагружать как RISC, так и традиционный процессор.
А Вы разве не в курсе, что система команд ARM существенно снижает количество переходов? Соответственно, меньше потребность их предсказывать.
Да и конвейер у него тупо короче.
Ну и вишенка на торте — неравномерность нагрузки. AVX/FMA-инструкции очень сильно нагружают процессор, и переходом на RISC-арихитектуру проблему не решить — вычислений меньше не станет.
RISC-арихитектура позволяет достаточно эффективно реализовать AVX программно.
Что же касается FMA — то мне вообще непонятно, зачем так носятся с плавающей арифметикой. Для значительной части задач она не нужна вообще.DistortNeo
24.03.2017 02:41+1Идеальный мир недостижим.
Ведь именно преобразователь традиционной системы команд в RISC-систему и является одним из наиболее сложных и тормозных элементов.
Насчёт сложных — полностью согласен. И хранение преобразованного кода в кэше тоже не идёт на пользу.
Однако, есть несколько вариантов снижения потребности в кэше:
1. Так и есть. Больше регистров — меньше потребность в L1 кэша. Сейчас логические регистры маппятся преобразованием на значительно большее число реальных регистров. Но напрямую реальные регистры не использовать.
2-5. Вы представляете, насколько это усложнит программирование многопоточных приложений? Возможно, для вычислительных задач это и будет актуально, но для реальных — совсем нет.
Ну и наконец, DRAM можно тупо ускорить внешним кэшем, расположенным на мат.плате — часть сложности процессора выносится наружу.
А лет 20 назад так и делали, кстати. Но учитывая, что в современном мире имеется тенденция к SoC, скорее, память просто встроят внутрь процессора.
А чтобы построить нормальную суперскалярность — опять же надо менять систему команд процессора: надо не заставлять процессор на ходу угадывать, что можно суперскалярить, а что нельзя — а явно прописать это в командах процессора.
Не надо. VLIW (а именно он подразумевает явное прописывание задач для ФУ) — плохое решение.
А Вы разве не в курсе, что система команд ARM существенно снижает количество переходов? Соответственно, меньше потребность их предсказывать.
Да и конвейер у него тупо короче.Система команд AVX мне напоминает ARM — там тоже есть условное выполнение.
А длину конвейера сравнивать нет смысла — если производители ARM-процессоров захотят увеличить производительность за счёт повышения исполняемых за такт инструкций, они будут вынуждены использовать длинный конвейер.
RISC-арихитектура позволяет достаточно эффективно реализовать AVX программно.
Предлагаете научить процессор выполнять по полсотни инструкций за такт? Наверное, это возможно, если в процессор поместить соответствующее количество FPU блоков и заюзать суперскалярность, только объём кода вырастет на пару порядков — никаких кэшей не хватит и планировщик в процессоре сдохнет.
NaHCO3
24.03.2017 03:33-1В спор «красное или зелёное» хочется добавить, что есть ещё и оранжевое, т.е. VLIW. Кстати, все три сосуществуют в современных технологиях вполне мирно.
VenomBlood
24.03.2017 03:29+1Отказ от прозрачного для программ совместного использования памяти. Теперь, чтобы программа на одном ядре могла записать в память данные, а программа на другом ядре могла прочитать эти данные — программы должны явно указать кэшам своих ядер факт передачи памяти в распоряжение другого ядра.
Это сюр какой-то. Зачем оно все нужно? Вместо того чтобы иметь сложность в одном месте при разработке ЦП вы хотите ее вынести во все многопоточные программы? Нафиг надо.
Ну или хотя бы ввести в дескрипторы страниц указание на то, используется ди эта страница монопольно или совместно несколькими ядрами. Для монопольных страниц не надо синхронизировать кэши.
Увеличивать параллельность можно увеличением количества ядер. Правда, для этого надо разрабатывать теорию параллельных вычислений — а с этим туго, т.к. за последние четверть века с распада СССР образование деградировало.
1) Ядрами нельзя заменить все, SIMD полностью по ядрам раскидывать — неэффективное варварство.
2) При чем тут ссср? Как бы параллельные вычисления живут и без него.
А чтобы построить нормальную суперскалярность — опять же надо менять систему команд процессора: надо не заставлять процессор на ходу угадывать, что можно суперскалярить, а что нельзя — а явно прописать это в командах процессора.
Нужно и то и то. Ну или вы готовы заставить всех переписать все тонны уже существующего кода? Ну или хотя бы переписать все компиляторы и перекомпилировать все.
RISC-арихитектура позволяет достаточно эффективно реализовать AVX программно
Ну и кому этот монстр нужен? Так то можно вместо AVX все в цикле написать, только суть как раз в том что используются очень низкоуровневые хардварные оптимизации для повышения производительности.
Что же касается FMA — то мне вообще непонятно, зачем так носятся с плавающей арифметикой. Для значительной части задач она не нужна вообще.
Тут я даже поперхнулся. Предлагаю еще умножение выкинуть, оно не особо нужно, а те кому нужно — напишут цикл по сложению.Karpion
26.03.2017 19:09-3Вместо того чтобы иметь сложность в одном месте при разработке ЦП вы хотите ее вынести во все многопоточные программы?
Видите ли, развитие технология однозначно вывели нас на необходимость многопоточных вычислений. Ибо одноядерные процессоры перестали развиваться, им дальше не могут наращивать быстродействие, и основное направление роста быстродействия — в увеличении числа ядер.
Ядрами нельзя заменить все, SIMD полностью по ядрам раскидывать — неэффективное варварство.
Я не предлагаю разбросать SIMD по ядрам. Я предлагаю отказаться от SIMD вообще, потеряв на этом часть производительности. Но наверстать это за счёт увеличения числа ядер — благо отказ от SIMD понизит потребность в «транзисторах на ядро»; а значит, количество ядер можно будет увеличить.
При чем тут ссср?
Распад СССР привёл к деградации образования. Во всех областях.
Ну или вы готовы заставить всех переписать все тонны уже существующего кода? Ну или хотя бы переписать все компиляторы и перекомпилировать все.
Э-э-э…
Наверно, Вы не заметили — но компиляторы постоянно переписываются. Последняя большая переделка была при появлении AMD-64. Но и сейчас переделки не прекращаются: "Intel рекомендует отказаться от старых SSE инструкций в пользу новых 128-битных AVX-инструкций, даже если достаточно двух операндов.".
Так то можно вместо AVX все в цикле написать, только суть как раз в том что используются очень низкоуровневые хардварные оптимизации для повышения производительности.
Интересно было бы посмотреть исходный код высокоуровневого языка, для которого компилятор генерирует AVX-коды.
Тут я даже поперхнулся.
А зря!
Ну, например, в ядре операционки — где нужен FPU? (Ну, разве что в видеодрайвере.)
Web-сервер, Proxy-сервер (Apache, Squid, Ngnix).
Файловый сервер Samba.
DNS-сервер? DHCP-сервер.
В ряде случаев имеет смысл проводить вычисления с фиксированной точкой.
Другого решения не существует, в принципе не понятно какое другое решение может быть.
Чтобы не надо было преобразовывать внешние команды во внутренние — надо просто чтобы компилятор изначально создавал код во внутреннем представлении. И сложность процессора сразу на порядок снижается — а значит, растёт надёжность (и в плане ошибок разработки, и в плане поломок), повышается скорость каждого ядра, можно сделать больше ядер.DistortNeo
26.03.2017 19:43Я предлагаю отказаться от SIMD вообще, потеряв на этом часть производительности. Но наверстать это за счёт увеличения числа ядер — благо отказ от SIMD понизит потребность в «транзисторах на ядро»; а значит, количество ядер можно будет увеличить.
Преимущество SIMD в первых двух буквах (Single Instruction). Ваш подход приведёт к увеличению ядер в 16-32 раз для получения аналогичной производительности: хотите писать код под 2048-ядерные процессоры? Ничего хорошего из этого не выйдет.
Суммарное количество транзисторов только увеличится: количество вычислительных ФУ останется прежним, а но вот количество декодеров команд и конвейеров увеличится пропорционально числу ядер.
Можете ради интереса взглянуть на архитектуру современных видеокарт. Куча ядер, никаких SIMD-инструкций, единственная "мелочь" — нельзя работать с потоками независимо.
Karpion
26.03.2017 20:42-2Мне кажется, Вы говорите «в 16-32 раз», исходя из предположения «программа в основном состоит из SIMD-инструкций». А в реальности надо смотреть, сколько этих SIMD-инструкций.
Я вовсе не сторонник безудержного увеличения числа ядер в одном процессоре. Наоборот — надо возвращаться к многочиповой архитектуре, и каждому чипу выделять собственный модуль памяти. Отказ от общей памяти снизит потребность в кэше.
Дальше надо отказываться от SMP и принудительно распределять работу между процессорами. Например, драйвер файловой системы д.б. на отдельном процессоре, и там же — драйвер RAID-контроллера с кэшированием (т.е. функции файловой системы, кэширования диска и RAID-контроллера надо интегрировать в одном программном модуле). И этому процессору FPU точно не потребуется.
Ваша ссылка — слишком большая. Какое именно место читать?
Если в видеокартах не сделали независимую работу с потоками — это не значит, что это невозможно сделать в принципе.DistortNeo
26.03.2017 22:28Мне кажется, Вы говорите «в 16-32 раз», исходя из предположения «программа в основном состоит из SIMD-инструкций». А в реальности надо смотреть, сколько этих SIMD-инструкций.
Достаточно, чтобы в некоторых задачах скорость FPU стала узким местом. Любая обработка изображений (типа фотошопа) или видео будет сильно требовательна к SIMD.
Дальше надо отказываться от SMP и принудительно распределять работу между процессорами.
Данное решение будет плохим из-за потери универсальности. Пользователю придётся покупать систему строго под свои задачи. Такое допустимо в серверных платформах, но не в десктопном сегменте.
Универсальность — это хорошо. Чем массовое продукт, тем он дешевле и доступнее. Выгоднее клепать одинаковые процессоры и просто отключать модули из маркетинговых соображений, чем делать по процессору под каждую задачу.
Ваша ссылка — слишком большая. Какое именно место читать?
Да собственно, я просто хотел привести пример сильно многоядерной архитектуры, и текущие технические проблемы в ней (один поток команд для нескольких вычислительных потоков).
Karpion
27.03.2017 21:10-1Любая обработка изображений (типа фотошопа) или видео будет сильно требовательна к SIMD.
Осталось узнать, много ли компьютеров крутят на себе Фотошоп и обработку видео.
Ну и почему я должен платить за счастье для фотошоперов? Может, пусть они лучше приобретают себе отдельный вычислительный модуль?
Данное решение будет плохим из-за потери универсальности.
Где Вы видите потерю универсальности?
Может, Вы против того, что у видеокарты — свой процессор? Ой-вэй, универсальность потеряна!!!
Пользователю придётся покупать систему строго под свои задачи.
Вы так говорите. как будто в этом есть что-то плохое. Как будто плохо выбрать компьютер с аппаратным RAID-контроллером, если он нужен, или без оного, если он не нужен.
Выгоднее клепать одинаковые процессоры и просто отключать модули из маркетинговых соображений, чем делать по процессору под каждую задачу.
Странно, что в смартфонах и планшетах какие-то ARM, а не те же процессоры, что и в серверах.
А отключение модулей из маркетинговых соображений — это настоящее вредительство.DistortNeo
27.03.2017 22:52Осталось узнать, много ли компьютеров крутят на себе Фотошоп и обработку видео.
Ну и почему я должен платить за счастье для фотошоперов? Может, пусть они лучше приобретают себе отдельный вычислительный модуль?А теперь представьте себе головную боль программистов: им придётся писать кучу вариантов программы для каждого из процессоров. Стоимость разработки, а значит, и стоимость софта подорожает.
Вот захочется вам отредактировать фотографию, что будете делать? Захотелось посмотреть видео — а кодек требует векторных инструкций и т.д. Заранее запланировать набор функционала очень сложно, особенно для десктопов.
Вы так говорите. как будто в этом есть что-то плохое. Как будто плохо выбрать компьютер с аппаратным RAID-контроллером, если он нужен, или без оного, если он не нужен.
Вот только мне будет плевать на то, будет ли процессор контроллера иметь избыточный функционал (FPU и SIMD) или нет. Главное, чтобы он работал.
Странно, что в смартфонах и планшетах какие-то ARM, а не те же процессоры, что и в серверах.
Потому что спрос на процессоры для мобильных устройств настолько высок, что экономически оправдано выпускать специализированные процессоры.
А отключение модулей из маркетинговых соображений — это настоящее вредительство.
Нет, это экономическая оправданность. Хотите платить за процессор в два раза больше?
mayorovp
28.03.2017 08:39+1Осталось узнать, много ли компьютеров крутят на себе Фотошоп и обработку видео.
Ну и почему я должен платить за счастье для фотошоперов? Может, пусть они лучше приобретают себе отдельный вычислительный модуль?Потому что разработка двух разных процессоров параллельно сделает каждый из них дороже — такое вот у них интересное ценообразование...
Karpion
28.03.2017 22:59-1Осталось понять, почему тогда на рынке есть два разных процессора *86/AMD-64 — от Intel и AMD; да и внутри каждого есть несколько моделей (например, Xeon и Pentium даже имеют разные сокеты).
Плюс к тому есть ARM, MIPS и ещё ряд процессоров (например, у IBM есть свои процессоры).DistortNeo
28.03.2017 23:46+2почему тогда на рынке есть два разных процессора *86/AMD-64 — от Intel и AMD
Наверное, потому что это две конкурирующие компании и поэтому они выпускают разные процессоры, а не работают сообща над одним? И это хорошо: конкуренция — двигатель прогресса.
да и внутри каждого есть несколько моделей (например, Xeon и Pentium даже имеют разные сокеты).
Экономическая оправданность. Пока что невыгодно клепать одни Xeon-ы и просто обрезать их. Посмотрите цены на 10+ -ядерные Xeon-ы — вот и цена для менее массового производства.
Плюс к тому есть ARM, MIPS и ещё ряд процессоров (например, у IBM есть свои процессоры).
ARM, MIPS — это не процессоры, а архитектуры. И пока что нет производителей процессоров на подобных архитектурах, способных создать процессор, который может потеснить процессоры от Intel и AMD.
Karpion
29.03.2017 03:16-2И это хорошо: конкуренция — двигатель прогресса.
Конкуренция хороша для потребителей и плоха для производителей.
Вероятно, Вы не понимаете механизма, по которому продолжают существовать два разработчика. А механизм этот — государственный.
Экономическая оправданность. Пока что невыгодно клепать одни Xeon-ы и просто обрезать их.
А с чего Вы вообще взяли, что процессоры обрезаются специально? Лично я полагаю, что скорее процессоры делаются как получится, а портом испытываются; и те участки кэша, те ядра, которые не прошли тестирования — выжигаются (точнее, выжигаются провода, идущие к ним; или они отключаются каким-то иным способом).
Однако, Вы так и не объяснили мне, почему выгодно разрабатывать несколько разных сокетов. Мало того, что Xeon и Pentium имеют разные сокеты — так Intel постоянно меняет сокеты, так что в продаже имеются два или даже три актуальных сокета для Pentium.
Вообще, похоже, что здесь Intel не столько развивает процессоры, сколько дурит пользователей и выкачивает из них деньги. А некоторые пользователи радостно говорят, что это экономически оправдано.
Ну да, оправдано — с т.з. маркетологов. А с т.з. потребителей и общества в целом это чистое разорение, т.к. инвестиции тратятся не в совершенствование процессоров, а в ухищрения по выкачиванию денег…
ARM, MIPS — это не процессоры, а архитектуры. И пока что нет производителей процессоров на подобных архитектурах, способных создать процессор, который может потеснить процессоры от Intel и AMD.
Я так понимаю, про Raspberry Pi Вы не слышали.DistortNeo
29.03.2017 10:44+1Конкуренция хороша для потребителей и плоха для производителей.
Да, конкуренция заставляет бедных и несчастных производителей вертеться и придумывать новые продукты.
Вероятно, Вы не понимаете механизма, по которому продолжают существовать два разработчика. А механизм этот — государственный.
Да, существует соглашение об обмене технологиями. Но конкуренция между ними вполне рыночная.
А с чего Вы вообще взяли, что процессоры обрезаются специально? Лично я полагаю, что скорее процессоры делаются как получится, а портом испытываются; и те участки кэша, те ядра, которые не прошли тестирования — выжигаются (точнее, выжигаются провода, идущие к ним; или они отключаются каким-то иным способом).
А почему бы и нет? Сложно случайным образом получить нужное число процессоров с нужной конфигурацией, приходится ещё и вредить. А у AMD вообще ядра можно было программно включить.
Вы так и не объяснили мне, почему выгодно разрабатывать несколько разных сокетов.
Чтобы люди, покупая новый процессор, меняли и материнку, и наоборот. AMD, например, сокеты не меняет и предпочитает сохранять обратную совместимость.
Ну да, оправдано — с т.з. маркетологов. А с т.з. потребителей и общества в целом это чистое разорение, т.к. инвестиции тратятся не в совершенствование процессоров, а в ухищрения по выкачиванию денег…
Intel как частная компания имеет на это полное право. Если вас это не устраивает — голосуйте рублём, не покупайте процессоры от Intel, а пользуйтесь Raspberry Pi. Вы же правда считаете эту платформу конкурентом Intel?
VenomBlood
28.03.2017 00:39+3Отказ от общей памяти снизит потребность в кэше.
Смех да и только. Видимо вы никогда код не писали. Вы представляете последствия? Это значит что вместо того чтобы реализовать что-то в ЦП вы заставите программистов писать не только многопоточный хардкорно оптимизированный код, но и еще заниматься кучей дополнительной синхронизации из-за неразделяемой памяти.Alexeyslav
29.03.2017 06:14И получится у вас… просто несколько полностью независимых систем на одной плате. А смысл?
VenomBlood
29.03.2017 06:17+1Вот и я не понимаю, какой смысл делать несколько независимых систем на одной плате, когда для того чтобы их использовать каждый производитель софта должен будет сильно-сильно напрягаться.
Karpion
29.03.2017 22:25Раньше программисты для достижения высокой производительности писали на ассемблере. Сейчас пишут на языках высокого уровня, а оптимизирует программу компилятор; причём чем выше уровень языка, тем больше возможностей оптимизации имеет компилятор.
Точно так же надо поступить и с распараллеливанием: создавать языки высокого уровня, а раскидывать работу на много потоков будет компилятор. Ну и для начала сделать параллельными популярные библиотеки подпрограмм.
Синхронизации не особо нужны, если использовать систему обмена сообщениями. Давно разработано — вроде, в QNX является базовым элементом операционки.VenomBlood
29.03.2017 22:45+2Точно так же надо поступить и с распараллеливанием: создавать языки высокого уровня, а раскидывать работу на много потоков будет компилятор. Ну и для начала сделать параллельными популярные библиотеки подпрограмм.
Вы понимаете же, что ни один компилятор без как минимум зачатков ИИ не сделает из произвольного однопоточного алгоритма многопоточный? Компиляторам доступно очень немного информации и они обязаны принимать консервативные решения. Да и часто даже неконсервативные решения даже потенциально не смогут помочь распараллелить, ибо алгоритм не параллелится. Компилятор может распараллелить код только если он написан так, что его можно распараллелить, к подавляющему большинству кода который пишется это не относится. Компилятор автоматом сможет распареллелить только то что он может потенциально сделать сейчас, например вместо векторизации он будет генерить параллельный код. Но от этого все станет намного медленнее, зачем так делать вообще?
Синхронизации не особо нужны, если использовать систему обмена сообщениями.
А обмен сообщениями — это не синхронизация? Да и вообще, серьезно? Для того чтобы распараллелить умножение вектора на 1000 элементов — делать обмен сообщениями? Как я уже сказал — на сообщеиня уйдет больше времени чем на полезную работу.
VenomBlood
28.03.2017 00:36+3Честно — даже смешно, насколько вы далеки от темы, о которой рассуждаете.
Видите ли, развитие технология однозначно вывели нас на необходимость многопоточных вычислений.
С этим никто не спорил, не понятно откуда вы это взяли., и основное направление роста быстродействия — в увеличении числа ядер.
Не только, еще как минимум в специализированнх инструкциях, в улучшении архитектуры.
Я не предлагаю разбросать SIMD по ядрам. Я предлагаю отказаться от SIMD вообще
Ну вы полегче, я же подавлюсь опять. Какой профит выкидывать SIMD?Но наверстать это за счёт увеличения числа ядер — благо отказ от SIMD понизит потребность в «транзисторах на ядро»; а значит, количество ядер можно будет увеличить.
Серьезно? А затраты на синхронизацию вы в расчет не берете? Если все что параллелится в программе — это небольшие циклы — то векторизация с этим справится на ура, а вот раскидать это на множество ядер — там потери на синхронизацию будут больше чем выигрыш.Распад СССР привёл к деградации образования. Во всех областях.
Это не единственная страна и далеко не лидер была в области вычислительных технологий, поэтому и непонятно к чему вы ее привели, еще Демократическую Республику Конго приведите.Э-э-э…
Вы, видимо, не в курсе, но кроме ваших уютненьких популярных языков программирования есть нечто старое и не особо поддерживаемое. Но даже с современными программами — как вы всех заставите все перекомпилировать когда для многого даже исходников нету уже.
Наверно, Вы не заметили — но компиляторы постоянно переписываются.
Интересно было бы посмотреть исходный код высокоуровневого языка, для которого компилятор генерирует AVX-коды.
И к чему это вообще?
Ну, например, в ядре операционки — где нужен FPU? (Ну, разве что в видеодрайвере.)
Смешно. Во первых — FPU используется в каждом домашнем компьютере, если исключения и есть — они просто единичны и это очень вычурные случаи. Во вторых — зачем выкидывать FPU когда это принесет только проблемы?
Web-сервер, Proxy-сервер (Apache, Squid, Ngnix).
Файловый сервер Samba.
DNS-сервер? DHCP-сервер.
В ряде случаев имеет смысл проводить вычисления с фиксированной точкой.
Чтобы не надо было преобразовывать внешние команды во внутренние — надо просто чтобы компилятор изначально создавал код во внутреннем представлении.
Ага, и зачем? Идеал — это когда процессор содержит доплонительные инструкции позволяющие компилятору давать «подсказки» наравне с существующими расширениями типа AVX, шифрования, кодеков и подобного.
И сложность процессора сразу на порядок снижается
И повышается сложность всех компиляторов, и кому это нужно?
а значит, растёт надёжность
Совершенно не факт
и в плане поломок
Во первых вообще не понятно как это влияет, во вторых — когда у вас последний раз ЦП из строя выходил?
повышается скорость каждого ядра
Как раз таки понижается, потому что теперь ядро может выполнять только что-то примитивное и все что всякие AVX делают быстро оно будет теперь делать медленно.можно сделать больше ядер.
Ага, особенно учитывая что далеко не все хорошо параллелится. И даже то что параллелится — это же абсурдно, вместо того чтобы сделать быстрый ЦП — заставлять всех разработчиков софта делать хардкорную многопоточную оптимизацию алгоритмов.
mayorovp
24.03.2017 08:49Вы говорите странные и непонятные вещи. Ведь именно преобразователь традиционной системы команд в RISC-систему и является одним из наиболее сложных и тормозных элементов. И из-за этого преобразования приходится строить сложный кэш для кода, т.к. надо хранить преобразованный код. И хранить много, т.к. преобразование — процесс достаточно сложный
Это уже решенная проблема.
Karpion
24.03.2017 16:33-2Конечно, решённая. Вот только решение такое, что полностью попадает под формулу «лекарство хуже болезни»: именно из-за такого типа решений и появляются проблемы типа той, что описана в головной статье этого треда.
VenomBlood
24.03.2017 21:14Другого решения не существует, в принципе не понятно какое другое решение может быть. То что вы предлагаете (софтверная имплементация) — это курам на смех, это не решает проблему и создает кучу других проблем.
nikolayv81
29.03.2017 12:23-1Про память, сейчас уже есть проблема с физическим расстоянием от планки ddr до кристалла cpu, т.к. скорость света в нашу вселенную слишком маленькую завезли.
Karpion
29.03.2017 18:01-2Хм-м-м, я сейчас прикинул, взяв расстояние от процессора до память в десять сантиметров (учитывая размер модуля и тот факт, что сигнал по проводам идёт медленнее света). Получилось (300e3 km/s)/(0.1 m) = 3e9 s^-1
Т.е. это три гигагерца. А сейчас частота доступа к памяти перешла за один гигагерц.
Остаётся надеяться на увеличение hit rate (процент попаданий в кэш) — а это достигается увеличением кэша, что тоже малоприятно.
Правда, есть ещё вариант, за который я агитирую:
Отказаться от концепции «один многоядерный процессор и один пул памяти на все процессоры». Построить систему из множества процессоров — каждый в отдельном чипе, в каждом немного ядер, и в том же чипе (на том же кристалле или на отдельном кристалле в том же чипе) находится память.
Причём эта концепция предполагает существенную переделку программирования — надо будет учить компиляторы создавать многопоточные программы, да ещё работающие с раздельной памятью. Вероятно, надо будет создавать новые языки программирования, вынуждающие программиста создавать код так, что этот код будет легко распараллеливаться; или как минимум, библиотечные функции надо будет переписать в виде параллельных вычислений.
В существующих языках эту проблему можно будет решить примерно так:
Сейчас есть функция copystr, которая возвращает управление в программу после своего завершения. А надо будет сделать функцию parallel_copystr, которая возвращает дескриптор операции и выполняется в фоновом режиме. Когда программист хочет выяснить, в каком состоянии находится запрос — он вызывает функцию get_status (декскриптор_операции) и получает ответ типа «ещё выполняется» (м.б., с процентами выполнения) или «уже закончилась».
Далее программист вызывает wait_finish(декскриптор_операции) — эта функция ждёт завершения операции и делает декскриптор_операции бессмысленным (подобно тому, как декскриптор открытого файла становится бессмысленным после закрытия файла).
Короче говоря, традиционные методы увеличения скорости буксуют. А обсуждение новых методов тут минусуют.nikolayv81
29.03.2017 18:29+1Ваши методы пригодны для спец процессоров, даже для декодирования jpeg + цветокоррекции под монитор уже не очень подходит, увы обмен данными между потоками очень важная штука, и современные компиляторы в т.ч. умеют делать так чтобы он иногда вмешался внутри процессора.
nikolayv81
29.03.2017 18:49Да и ещё, хотя тут наверное уже приводили аргументы, распараллелить можно только небольшую часть алгоритмов, в случае же обработки больших объёмов данных спасает только огромный кэш и монструозные универсальные АЛУ.
Век risk в чистом виде, на мой взгляд, закончился на dec alpha у которых была сумасшедшая по тем временам тактовая частота, далее основное развитие пошло по увеличению количества выполняемых действий за такт (сейчас уже упёрлись в физические законы) и уже никак за счёт упрощения инструкций не вылезти. С увеличением разрядности тоже по сути достигли предела, просто некуда больше 4х каналов памяти пихать на материнку.
Про arm там не всё так хорошо с производительностью, но из-за особенностей устройств некоторые "стандартные" функции выносятся практически в отдельные устройства(блоки), для desktop-а таких возможностей меньше, т.к. процессор должен пережить несколько волн обновления ПО, и, к примеру, должен переварить новую версию алгоритма декодирования видео, а для арм достаточно встроенного полуаппаратного декодера который даже на момент покупки устройства уже не все алгоритмы(в том числе и подуровни одного h264) поддерживает.
Karpion
30.03.2017 21:54-1Обратите внимание на декларативное программирование: там компилятор достаточно легко может обеспечить параллельность вычислений.
Собственно, оптимизирующий компилятор обычных языков тоже сначала пытается выделить декларативные куски программы. А дальше уже параллелит как минимум на уровне конвейера.
Чем Вам ARM — не RISC в чистом виде? А ARM разрабатывается до сих пор.
Кодековый сопроцессор — вещь вполне предсказуемая. Правда, лучше бы вместо него сделали дополнительное ядро, с отдельным кэшем и памятью.
А что «нехорошо с производительностью» у ARM? Ну, понятно, что с ограничениями мобильных устройств по энергопотреблению — производительность приходится ужимать. Но что мешает сделать настольный вариант ARM?
Alexeyslav
30.03.2017 08:30-1Вы посчитали некую абстрактную частоту… причем судя по всему на этой частоте будет уже полное рассогласование — у процессора тактовый импульс уже прошел а до модуля памяти он только начал добираться. Т.е. нормальная синхронная работа в таких условиях попросту уже невозможна. А если учесть что для адресации ячейки в DRAM необходимо пройти 4 стадии, всё становится ещё печальнее. Поэтому память нынче пытается переходить на асинхронные последовательные интерфейсы.
Что касается параллельной обработки, то на рядовых задачах ваш параллельный процессор будет в сотню раз медленней классического.
Попробуйте ускорить за счет параллельных вычислений вычисление факториала.
Поэтому сейчас существует(и который год уже) разделение на центральный процессор и видеоускоритель — это как пример разных подходов к вычислениям. И почему-то который год ни один из этих подходов не может похоронить другой. Более того, делают ещё и специальные ASIC для математических вычислений которые уделывают по скорости счета как первые так и вторые, но полностью бесполезны в рядовых задачах.DistortNeo
30.03.2017 12:49Попробуйте ускорить за счет параллельных вычислений вычисление факториала.
Плохой пример. Его как раз можно распараллелить:
- Перемножать K (N + K) (2N K) … на каждом из N параллельных устройств.
- Итоговое перемножение длинных чисел тоже легко параллелится.
А вот хороший пример — регрессионные методы обработки изображений с использованием довольно большого словаря. С одной стороны, методы легко параллелятся — попиксельная обработка независима, но с другой отказаться от использования общей памяти (словаря) невозможно, т.к. его размер слишком большой для размещения в локальной памяти каждого из вычислительных потоков.
хранением довольного большого словаря.
mayorovp
30.03.2017 09:03Отказаться от концепции «один многоядерный процессор и один пул памяти на все процессоры». Построить систему из множества процессоров — каждый в отдельном чипе, в каждом немного ядер, и в том же чипе (на том же кристалле или на отдельном кристалле в том же чипе) находится память.
Суперкомпьютеры так и делают. Разве что память обычно все-таки находится рядом, а не на том же кристалле.
Но для обычных компьютеров или даже серверов такая архитектура попросту избыточна. Для такого числа ядер не найдется задач.
Karpion
30.03.2017 17:08-1Если Вы внимательно посмотрите на историю компьютеров, то увидите в ней некую ступенчатость.
- Этап ламповых компьютеров мы опустим, я его плохо знаю.
- Первые большие ЭВМ по своей функциональности были похожи на программируемые компьютеры. Потом они получили кэш, многопроцессорность, многозадачность, многопользовательскость и вирт.машины.
- Потом появились мини-ЭВМ. Ну, размером где-то с большой платяной шкаф, примерно четыре девятнадцатидюймовые стойки. Они тоже начали с уровня программируемых калькуляторов (ну, может, чуть повыше) и доросли до Unix.
- Затем появились настольные компьютеры — сначала восьмибитные, потом дальше больше, и доросли до кэша, многопроцессорности (в т.ч. в виде многоядерности), многозадачности, многопользовательскости и вирт.машин.
- Сейчас идёт этап носимых компьютеров (смартфонов, планшетов). Кэш и многозадачность там есть, многопользовательскости и вирт.машин пока нет.
Что касается задач — это вообще не проблема. Нужное количество задач сгенерит компилятор; а чтобы ему было проще — под это дело придумают языки программирования со встроенной парадигмой параллельных вычислений.
Да собственно, работы в этом направлении уже имеются — в виде вычислений, производимых на видеокарте.mayorovp
30.03.2017 17:18-1Ну, во-первых, в суперкомпьютерах большое число узлов все же не отменяет SIMD-инструкции. А во-вторых, ступеньки давно уже в другом направлении работают — новые технологии сначала появляются на десктопах, потом переходят на суперкомпьютеры.
dartraiden
22.03.2017 21:33+1Компьютер с новым процессором Ryzen может подвесить любая вредоносная программа. Возможно, даже через браузер.
Если у пользователя через браузер что-то самопроизвольно запускается (как раз в свежем Firefox закрыли такую уязвимость с автоматическим выполнением произвольного кода при посещении веб-страницы), то уже, честно говоря, всё равно, зависает оно, файлы шифрует или ПК как бота в ddos-ботнете использует. В этом случае всё уже плохо, независимо от процессора, и нужно скорее обновлять браузер.NaHCO3
22.03.2017 23:39+2> Если у пользователя через браузер что-то самопроизвольно запускается
Какой процент пользователей имеет активный noscript? Остальных списывать в утиль?
zerg59
23.03.2017 05:38+3*Здесь должна быть шутка про слоупоков*
Вчерашняя новость с полей:
«Гига уже пофиксила:
От человека который нашёл эту ошибку:
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.»
Daimos
23.03.2017 08:26+2Это, конечно хорошо, но боюсь Биос обновляет дай бог 5% людей.
zerg59
23.03.2017 11:04Я думаю, среди тех, кто покупает свежак в первые недели выпуска, процент заметно выше. Остальные просто ждут месяцок-два пока early adopters большинство багов выловят. Ну и цены упадут опять же.
Daimos
24.03.2017 10:56Уже произведено тысячи материнок, они лежат на складах, никто из продавцов не будет обновлять ничего, а покупатель через полгода — не факт, что тоже станет обновлять — работает же.
tronix286
23.03.2017 07:53Интересно, а AGESA наглухо закрыт всякими NDA и прочими 1024 битными AES ключами?
vasiliysenin
23.03.2017 08:52+1https://en.wikipedia.org/wiki/AGESA
AGESA source code was open-sourced in early 2011 to gain track in coreboot.
CodeRush
23.03.2017 09:07+1Раньше AGESA поставлялась в исходниках и была доступна для модификации любому желающему, но теперь AMD ударилась в PSP, начиная с Beema/Mullins для APU и Ryzen для CPU, прошивка которого в свою очередь подписана и зашифрована, и занимается он на этих процессорах не только реализацией fTPM, но и тренировкой памяти, т.е. ни отключить его, ни заменить его прошивку своей нельзя. В итоге от AGESA осталась теперь только обертка вокруг PSP и его встроенной ОС, которая с каждым новым поколением все тоньше.
Ezhyg
23.03.2017 10:54-2А ещё, АМД в очередной раз ткнула Интел мордочкой в… салат, приварив 1331 ножку на подложку :D.
Anarions
23.03.2017 12:18А можно подробней рассказать о чём речь? Звучит интересно — но сути не понимаю.
Ezhyg
23.03.2017 12:43-1Ноги же, лапы! :)
Ладно уж, поясню ;).
Интел на сокетах 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 пока не говорю, хотя там они ещё меньше, а значит мягче)dimitry78
23.03.2017 12:52-1маркетинг:
если люди жуют "там могла бы быть ваша реклама", то давайте по телеку рекламировать в роликах как нечто закидывает в рот 2 подушечки жвачки — профит! — продажи жвачки выросли на 40%… насчет ножек — себестоимость (без RN&D) кристалла для штеуд около 5$, ножки стоят 40 центов, профит!Ezhyg
23.03.2017 12:58-1Но ведь сокеты-то делает не Интел, а… Foxconn, например (хм, чой-то и правда не знаю, кто им современные сокеты делает). И явно не по себестоимости, да ещё и учитывая бОльшую сложность и «технологичность», деньги же уплывают мимо… :).
Хотя, может именно этим объясняется (помимо временно отсутствовавшей конкуренции) всё не снижающаяся цена на камни?
VenomBlood
23.03.2017 21:40Так во первых помять ножки на материнской плате все же труднее, во вторых — она зачастую стоит дешевле процессора, поэтому переместить ножки на сокет — здравая идея.
Ezhyg
23.03.2017 22:06-1Ножки не на материнской плате, а в сокете на ней. Нет, нисколько не труднее, я уже рассказал, что и как происходит тысячами (я не шучу). Поверьте на слово, ножки на самом процессоре хоть и тоже гнутся, но и выправляются сильно проще, даже криворуким чайником. И даже оторванные, паяются в разы проще… и даже… в общем, «расскажите супруге, как борщ правильно варить» :P.
Чем хороши ножки на таких сокетах (открытых), расскажите «маркетологам» Штеуд, вдруг они чего-то не знают.VenomBlood
23.03.2017 22:16Ножки не на материнской плате, а в сокете на ней.
А сокет значит не на материнской плате или как? Смысл то один и тот же.
Нет, нисколько не труднее
Таки труднее, ножки там можно погнуть по сути только в процессе установки процессора, остальные случаи достаточно вычурные. Да и в процессе установки — это надо умудриться чтобы воткнуть процессор так чтобы ножки погнуть. В любом случае это пол беды, ибо те кто так втыкает — потом воткнут молотком DVI в USB.
я уже рассказал что и как происходит тысячами случаев.
А, ну тогда конечно. Я тогда рассказываю что на процессорах ножки гнулись миллионами случаев, а на материнских платах как вы говорите — тысячами, вот и разобрались.
«расскажите супруге, как борщ правильно варить» :P.
Что за сексизм?Ezhyg
23.03.2017 22:33-1А сокет значит не на материнской плате или как?
ну что за… ведь нарочно написал:
а в сокете на ней
Нет, смысл разный! В сокете они как бы должны быть защищены, как защищены такие же контакты в других сокетах и слотах, память, видеокарты, карты расширения, да даже дополнительные гнёзда для задней и передней панели — часто находятся в более менее защищающем их корпусе.
ножки там можно погнуть по сути только в процессе установки процессора...
А ножки самого процессора можно погнуть в любое время дня и ночи… ага! Пофигу, что до установки он находится в блистере и коробке, а после, к нему точно так же нет доступа.
Да, именно так и гнут и вырывают ножки и там и там. Но, ещё раз, — ножки в сокете — крючки. Аналогично липучке Velcro (то стороне, что с крючками) цепляется за любой ворс, за ногти, за заусенцы на коже… и т.п. Вы хотите поспорить о статистике? А я не хочу. Потому что я указал только на мифическую сложность приваривания лап, на которую напирала Штеуд.
Что за сексизм?
Это вообще-то известная «пословицы и поговорки народов мира» — «Поучи жену щи варить».VenomBlood
23.03.2017 22:44Нет, смысл разный!
Это чисто придирка к словам. Давайте я тоже попридираюсь — не в сокете, а в сокете под крышечкой. Это как бы тоже в сокете, но под крышечкой. То же самое как в сокете на материнской плате — это тоже на материнской плате, но в сокете.
А ножки самого процессора можно погнуть в любое время дня и ночи… ага! Пофигу, что до установки он находится в блистере и коробке, а после, к нему точно так же нет доступа.
Только вот маленький лежащий где-то процессор намного больше подвержен поломке ножек.
цепляется за любой ворс, за ногти, за заусенцы на коже… и т.п.
Вот уж какие страсти расказываете.
Вы хотите поспорить о статистике? А я не хочу.
Ну тогда и не приводите свои «тысячи» взятые с потолка. Да и при том не понятно «тысячи» от какого числа.
Потому что я указал только на мифическую сложность приваривания лап
Так делать пины на материнской плате можно и маленькие, потому что они более защищены, а на процессоре маленькие пины — это проблема, особенно учитывая что процессор обычно дороже материнской платы.
на которую напирала Штеуд.
У вас кнопки переключения раскладки клавиатуры зацепились за ворс/ногти/заусенцы на коже и не работают?Ezhyg
23.03.2017 23:03-1У меня стойкое ощущение, что вы не читаете комментарии до комментирования или вообще общаетесь с кем-то в собственной голове, который пересказывает вам окружающую действительность.
Каждый раз, предвосхищая возможное возражение, пишу поясняющую фразу, но в итоге…постоянноодно и то же.
маленький лежащий где-то процессор намного больше подвержен поломке ножек
Нет! А знаете почему?
до установки он находится в блистере и коробке, а после, к нему точно так же нет доступа.
Как и сокет, защищёный крышкой, но только в первый раз, если мы не работаем с владельцем, отчего-то сохранившим, а не выломавшим крышку. Вот только, в третий раз:
ножки процессора — не крючки
погнутые и даже оторванные ножки — ремонтируются легче, потому что:
— находятся на не то чтобы свободном, но достаточно открытом пространстве в несколько квадратных сантиметров, сильно доступнее паяльнику, пинцету и т.п.
— сокет же, расположенный на материнской плате, при необходимости ремонта — сложнее, в том числе, потому что?
— расположен на материнской плате, в окружении других деталей и местный нагрев большой платы, с кучей меди — штука не сильно полезная, его ножки-крючки находятся среди других, таких же крючков,
взятые с потолка
Статистика ремонтов, в том числе из нескольких сц. В общем-то я и не собирался её доказывать, потому что, в третий раз:
указал только на мифическую сложность приваривания лап, на которую напирала Штеуд.
кнопки переключения раскладки клавиатуры зацепились
показательное отношение, всего-то.VenomBlood
23.03.2017 23:18У меня стойкое ощущение, что вы не читаете комментарии до комментирования или вообще общаетесь с кем-то в собственной голове, который пересказывает вам окружающую действительность.
У меня стойкое ощущение что у вас обида на Intel и вы пытаетесь выдумать статистику из воздуха чтобы хоть как-то подтвердить свое мнение.
Нет! А знаете почему?
Ну вам виднее, конечно. Везде все говорят о преимуществе LGA потому что ножки на процессоре не ломаются, а на материнской плате сломать сложнее и она стоит дешевле. Но вам виднее. Когда вы вытащите процессор из блистера — он уже подвержен поломкам если там ножки. Вы его уронили — ножка может сломаться, еще он маленький, его можно случайно задеть. Это очевидные вещи.
Как и сокет, защищёный крышкой, но только в первый раз, если мы не работаем с владельцем, отчего-то сохранившим, а не выломавшим крышку.
Что значит «в первый раз»? Если кто-то меняет процессор, то у него как бы в сокете прошлый процессор стоит. При этом если заменять процессор — к старому надо или блистер сохранять или класть в пакетик, а материнская плата даже при замене без замены процессора (и как часто это происходит?) — все равно в большей безопасности. Это если рассматривать ваши «вторые разы».
погнутые и даже оторванные ножки — ремонтируются легче
При чем тут сложность ремонта (вообще официальные СЦ ремонтируют ножки процессоров?), когда речь о том что поломок меньше.
Статистика ремонтов, в том числе из нескольких сц. В общем-то я и не собирался её доказывать, потому что, в третий раз:
Статистику в студию. И не плохо было бы еще посмотреть статистику поломок процессоров с ножками.
показательное отношение, всего-то.
Это примерно как в начальных классах школы дети коверкают фамилии тех кто им не симпатичен? Понятно.Ezhyg
23.03.2017 23:25-2Нет никакой обиды, но…
Хотите поспорить, поспорьте с этим:
АМД в очередной раз ткнула Интел мордочкой в… салат
Статистику в студию
..\|/
../.\
./...\
/.|||.\
VenomBlood
23.03.2017 23:33+2Понятно, т.е. аргументов нету — можно и шалашики рисовать?
Ezhyg
23.03.2017 23:36-1Есть! И озвучен уже 5 раз.
АМД приварила к подложке 1331 лапу. Интел «не шмагла», ещё вопросы?VenomBlood
23.03.2017 23:52Да кто сказал что «не смогла»? Что за бред? Это осознанное решение, потому что оно лучше. С чего бы Intel возвращаться к старому решению, которое они уже улучшили?
Тогда это AMD не смогла сделать контактные площадки.Ezhyg
24.03.2017 00:02-1«мальчик, ты дурак?»
Ezhyg 23 марта 2017 в 12:58 (комментарий был изменён) #
Но ведь сокеты-то делает не Интел, а… Foxconn, напримерVenomBlood
24.03.2017 00:07Вот смешно. Во первых аргументы кончились — начались переходы на личности.
А во вторых:АМД приварила к подложке 1331 лапу. Интел «не шмагла», ещё вопросы?
Т.е. у вас у самого с собой противоречие. Вы уж определитесь, или «Intel не смогла» можно говорить, а «AMD не смогла» нельзя?Ezhyg
24.03.2017 00:17-1аргументы кончились — начались переходы на личности.
всего-лишь пытаюсь взывать к зайчаткам разума
Не хотите выглядеть глупо? Не надо в восемнадцатый раз вопрошать ответы на вопросы, которые были отвечены ещё до вашего врывания в этот тред.
Тезисно.
Лапы к процессору приваривает сам производитель процессоров.
Ноги в сокете — производитель сокета.
То что одна фирма смогла припаять ноги к процессору, не значит, что она может или не может, надо ей или не надо уметь делать это же с сокетом. Патамушта ей даже сокет не нужно иметь, от слова совсем. Его производят другие фирмы (даже не одна, да) и ставить будут, каким бы странным вам это ни казалось, другие производители, материнских плат.
Отказаться от ног не сложно, у АМД есть такое, я уже приводил примеры, но вы же опять «чукча не читатель, чукча писатель».
За сим я заканчиваю беседу, ибо чуйствую, что разговариваю с глупцом, вынуждающим меня повторять по восемь раз уже сказанное.
P.S. «карма» там =>VenomBlood
24.03.2017 00:23Вот вам как раз не надо в десятый раз путаться в трех соснах, у вас какая-то слепая обида на Intel похоже. Intel делает LGA — они «не могут сделать ноги», а AMD делает ноги — это не «не могут делать LGA» — это «им не надо». Смешно же, такая махровая предвзятость.
То что одна фирма смогла припаять ноги к процессору, не значит, что она может или не может, надо ей или не надо уметь делать это же с сокетом. Патамушта ей даже сокет не нужно иметь, от слова совсем. Его производят другая фирма и ставить будут, каким бы странным вам это ни казалось, другие производители, материнских плат.
Ну вот, опять сами себе противоречите. Т.е. Intel тоже ведь ничто не мешает ноги к процессору сделать. И то что они сейчас не делают, потому что у них есть решение получше — опять же никак не значит что они не могут делать, просто им это не нужно, от слова совсем, потому что у них, опять же — есть решение лучше.
Отказаться от ног не сложно, у АМД есть такое, я уже приводил примеры, но вы же опять «чукча не читатель, чукча писатель».
Так и у Intel были процессоры с ногами раньше, нашли решение лучше и отказались от этого. Вернуть ноги не сложно, просто у Intel отработано решение получше.
Уже 10 раз вам одно и то же пишут, никак вы осознать не можете.VenomBlood
24.03.2017 00:27И да, вишенкой на торте будет то что AMD вообще Fabless, так что вашими словами — она вообще ничего «не смогла».
xforce
23.03.2017 23:49+2Банально при снятии кулера в LGA верхняя крышка держит процессор и не дает ему «прилипнуть» на термопасте к радиатору. А вот обычные процессоры с ногами довольно часто вынимаются из сокета вместе с радиатором, т.к. ногами-же за сокет и держутся. Некоторые, особо удачливые, ещё и ногу в сокете забыть при этом могут.
Ezhyg
23.03.2017 23:59-2ну давайте поговорим о случаях из практики :)
отвалился кулер оторвав припаянную крышку теплораспределителя
сняли кулер… вместе с кристалом, подложка осталась в сокете
…
в ноутубках — оторвали СО частично с шарами и пятаками
Ivan_83
24.03.2017 03:43-1Сколько экспертов собралось… даже уже из браузера собрались SIMD заюзать %)
То бинарники разных для архитектур: x86 и x86 конечно очень разные…
При этом никто не обратил внимание на то что мать у него на B350.
Все производители делают на матерях с B350 слабое питание проца, в расчёте на 1700 и аналогичные ему с TDP 65 Ватт.
И кто то упоминал что вроде как при разгоне проца баг не проявлялся…
Ну да ладно, пофиксили микрокодом.
И не плохо бы упомянуть что в ERRATA для кабилейков уже под 200 багов со статусом NO FIX.
В том числе и неопределённое поведение при выполнении AVX… не считая двух-трёх просто «неожиданно долго выполняется».
2 CodeRush
У тебя есть биос и кернел гайд на амд 17h?
Оч надо :)
SotaSill74
24.03.2017 09:47-1На мой взгляд — чистый пи-ар, побуждающий купить проц и потестить баг — «чистая капуста»!
AMD «прочухали» предыдущий «кипиш» по поводу ошибки в TLB в Фенах 9х00 и вполне себе прилично выдали 9х50,
Но! — сколько шума было поднято! — а это крути — не крути а всё же «раскрутка».
Ну и как вариант — что баг по TLB, что текущее зависание по FMA3 —
механизм влияния на покупателя —
вот он, нормуль проц!, раньше стоил 500$, вполне себе конкурент интелам за 500$ — они практически равны — амд даже обгоняет, НО!, там есть случайный баг — вы его никогда не заметите и никогда в жизни не встретите, но какой-то криво написанный тест не для виндовса — «подвешивает» систему при запуске в виндовсе — вы точно такого не увидите за всю жизнь, НО!, мы теперь написали патч, исправляющий эти ошибки, + к этому ещё снизили цену на процы на 20% —
— выбирайте: или интелы за 500, или наши, более быстрые, за 400 с пофиксенным багом
Выдали пробный шар — «зарядили» цены вровень с конкурентами — посмотрели на интенсивность и потенциал спроса — технично, лаконично, и раздуто-рекламно понизили цены — ПРОФИТ!
Merser
Молодцы, что признали проблему сразу. По последним новостям, некоторые из производителей плат уже получили доступ к обновлённой сборке AGESA на этой неделе.