The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Разработчики DragonFly BSD выявили ошибку в процессорах AMD"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Подсказка: Второй уровень иерархии тем в форуме реализован через вкладку "Показ ключевых тем".
. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD" –4 +/
Сообщение от Ваня (??), 07-Мрт-12, 11:16 
Массовый вброс глупостей и сплетен.

Несовместимости между х8086 и последующими не было, но были умники, которые напр. использовали скорость выполнения операции вместо таймера; рост скорости процессора в 20 раз повлиял на правильность работы их программы.

История с линией а20 ещё более прозаична: когда ОП выросла до 1 Мб нужно было решение которое с одной стороны не изменило работу старых, а с другой позволило работать с памятью выше 1 Мб новым. Решение было найдено - новые программы должны были устанавливать флаг что они новые. Вместо того чтобы создавать новый контроллер решили использовать один из существующих, а именно контроллер клавиатуры где из 32 существующих флагов использовались менее половины, был использован флаг №20. Спустя 10 лет стало очевидно что решение мягко говоря неудачное: контроллер клавиатуры один из самых медленных, а "старых" программ не осталось. В результате был реализован аппаратный хак по перехвату обращения к флагу а20 с передачей этого обращения в куда более быстрый южный (?) мост; вдобавок вместо 3 циклов с обращением к контроллеру клавиатуры появилась возможность установки за 1 команду; вдобавок во многих BIOS'ах а20 включена по умолчанию.

В 80386 была реализована недокументированная команда POPALL, которую некоторые раздолбаи стали массово использовать, несмотря на все вопли Intel'а что этой команды в следующих процессорах уже не будет.

В 80486 ряд было замедление при определённой последовательности команд связанная с не до конца корректной обработкой сброса кэша. Ряд программ, оптимизированных под 80386 на 80486 работали медленнее. На 80586 к слову появились U и V "трубы", которые позволяли при определённой оптимизации получить удвоение скорости выполнения кода, а на Pentium II таких труб стало уже 3, на Pentium !!! уже 5, и оптимизации под 80586 приводили к замедлению на последующих процессорах; но к этому времени идиотов, пишущих на ассемблере и использующих низкоуровневые оптимизации осталось уже совсем немного...

Работа с кэшами и спариванием, которой посвящён последний абзац глупостей, изобилует особенностями. Напр.:
- процессор пытается предсказывать переходы, делая это по принципу какой чаще случался - туда и идём; так напр. если обычно выполнялась положительная ветвь, то в случае появления отрицательной ветви выполнение может замедлиться
- процессор осуществляет выборку кэша линиями (у кэша 3 уровня, в каждом свои линии) по N байт (запрос на чтение 1 байта приведёт к чтению 256 байт в кэш 1-ого уровня, 128 байт в чтение из кэша 1-ого в кэш 2-ого, и 64 байт в кэш 3-его из 2-ого). При случайном (или неоптимально организованном) доступе к памяти падение скорости может быть 30-кратным.
- особенности работы с кэшем требуют выравнивания кода и данных. Обращение к невыровненным данным в ряде команд процессора физически невозможно (будет сгенерирован сбой "Недопустимая команда"). Выравнивания различны, от 4 байт до 4 кб, разные для различных команд.
- процессор может выполнить две команды, работающие с разными объектами одновременно, это называется "спаривание" (напр. команды А=А+10 и Б=Б-5 спарятся; а команды А=А+10 и Б=Б+А нет, т.к. во втором случае для выполнения второй команды нужно выполнить первую). Но дальше начинаются особенности: некоторые команды не спариваются вообще никогда (XCHG), другие спариваются не везде (сейчас 5, вроде, "труб", из них лишь одна умеет выполнять все команды; закон 80:20), третьи обнуляют кэш предсказаний, и т.д. Вдобавок ко всему ассемблеровский хак с переходом в середину предыдущей команды вызывает полный сброс всех кэшей и хрен пойми что ещё, зато позволяет заморочить код как для железки, так и для человека. Пример заморочек: "or al,1" спаривается, а "bts al,0" (делает то же самое) нет. Но обращение к части регистра до/после обращения к целому регистру (напр. "mov eax,1000000h" перед "or al,1") вызывает паузу в 10 тиков, и т.д.

Но т.к. код уже давно генерят компиляторы все эти заморочки - это проблемы их [компиляторов] создателей. Хотя идиоты никуда не делись и очередная попытка очередного идиота соптимизировать работающий код приводит к замедлению работы или даже его неработоспособности.

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Разработчики DragonFly BSD выявили ошибку в процессорах AMD, opennews, 06-Мрт-12, 13:49  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру