https://x.com/davepl1968/status/2067329306918097044
https://www.youtube.com/watch?v=jH0BYAkPj78
https://softantenna.com/blog/microsoft-lego-binary-optimization/
История о том, как Microsoft ускорила работу Windows с помощью оптимизации в стиле конструктора Lego.
Часто говорят, что «старое программное обеспечение было легче», но это объяснялось кропотливой работой разработчиков.
В 1990-х годах Microsoft также тщательно оптимизировала свои исполняемые файлы для запуска Windows и Office в средах с объемом оперативной памяти всего 12 МБ.
В основе всего этого лежал инструмент под названием BBT (Basic Block Tool) , который внутри компании называли «конструктором Microsoft Lego».
По словам бывшего инженера Microsoft Дэйва Пламмера, в то время приложения становились всё более громоздкими, но при запуске требовалась лишь небольшая часть кода. Однако эти необходимые 300 КБ кода были разбросаны по 10-мегабайтному исполняемому файлу, что требовало доступа к большому количеству страниц памяти во время загрузки и приводило к значительным задержкам при обращении к диску.
Для решения этой проблемы компания BBT выполнила процесс «дефрагментации» бинарного файла, который включал анализ пути выполнения и группировку связанного кода, что позволило создать более быстрый бинарный файл, сохранив при этом ту же функциональность.
Философия оптимизации, которая остается актуальной и сегодня.
По словам Дэйва Пламмера, существовавшая в то время среда оказала прямое влияние на пользовательский опыт, благодаря таким улучшениям, как сокращение количества страниц, запрашиваемых при запуске, группировка часто используемого кода для предотвращения его замены и повышение отзывчивости при многозадачности.
Философия оптимизации остается актуальной и сегодня, несмотря на значительное улучшение производительности оборудования. Пламмер утверждает: «Масштаб проблемы просто изменился, но суть осталась прежней».
Несмотря на то, что бинарные файлы стали огромными, фреймворки — более сложными, а сервисы — более децентрализованными, принципы «объединения часто используемого кода» и «поддержания небольших общих путей выполнения» остаются актуальными, и эта философия продолжается в современных инструментах, таких как BOLT и HP Dynamo.
https://dl.acm.org/doi/pdf/10.1145/349299.349303
http://www.hpl.hp.com/cambridge/projects/Dynamo
https://web.archive.org/web/20030212171520/http://www.hpl.hp.com/cambridge/projects/Dynamo/
Discuss
https://web.archive.org/web/20030210080835/http://arstechnica.infopop.net/OpenTopic/page?a=cfrm
Youtube comment
Andy Glew from Intel had made a comp.arch Usenet post
the Pentium's new performance counter overflow external pin back into the NMI
The next generation of Pentium directly supported performance counter interrupts
@jimevans5780
В 1995 году я проходил летнюю стажировку в небольшой группе, которая занималась разработкой LEGO. Какое замечательное возвращение в прошлое! Энди Глев из Intel опубликовал в Usenet сообщение на comp.arch, в котором предлагал подключить внешний контакт переполнения нового счетчика производительности Pentium обратно к NMI и получить своего рода аппаратную статистическую выборку событий производительности. Моя задача заключалась в том, чтобы потратить 2 минуты с паяльником и 2 месяца на написание драйвера устройства, чтобы попытаться интегрировать эту идею в базовое профилирование блоков LEGO. Всё это устарело уже через месяц, когда следующее поколение Pentium напрямую поддержало прерывания счетчика производительности. Помню, как еженедельные групповые мероприятия чередовались между стрельбой из оружия и катанием на водных лыжах на озере Саммамиш. Это было действительно весёлое лето.
@JohnSwenson-m2r
Мой отец работал на Univac 1, который имел 1000 слов ОЗУ (ртуть в металлических трубках) и магнитный барабан. Все важные данные нужно было хранить в ОЗУ, поскольку работа с барабаном сильно замедляла процесс. Поэтому у них был так называемый «SOAP-блок», который выполнял аналогичную оптимизацию, стараясь максимально сосредоточить выполнение кода в ртути. Он также работал после ассемблера и компоновщика, так что это звучит как довольно похожая схема, существовавшая десятилетиями ранее.
@adamludwick9931
Самое забавное для меня то, что я ежедневно взаимодействовал с BBT на протяжении почти десяти лет... и мне никогда не приходило в голову, что это секретный инструмент.
@mcbeenb
Дэйв, возможно, вы сможете помочь мне разобраться в том, что оставалось для меня загадкой последние 30 лет. В конце разработки NT4, примерно в 1995-96 годах, я работал в компании, занимающейся разработкой программного обеспечения для баз данных. Работая с одной из поздних бета-версий NT4 (когда программное обеспечение Microsoft еще поставлялось в огромных папках с компакт-дисками по подписке), я обнаружил, что могу значительно повысить скорость работы диска, включив виртуальную память и установив размер файла подкачки равным нулю. Скорость доступа к диску приблизилась к уровню оперативной памяти, но с очевидно улучшенной отказоустойчивостью. Это было настолько быстро, что локальные операции с базами данных приблизились к скорости наших серверов баз данных с большим количеством кэширования и корпоративных SCSI-накопителей. Однако это продлилось недолго, так как с выходом NT4 эта «ошибка» была устранена. Какое-то время мы могли достигать скорости серверного уровня на обычном настольном оборудовании. У вас есть какая-нибудь информация об этой странной аномалии? Мы предположили, что это как-то связано с дисковым кэшированием и виртуальной памятью. Возможно, установка файла подкачки в пустое состояние оставляла выделенное место в дисковом кэше, куда наша база данных могла бы попадать вместо файла подкачки. Мы не потеряли никаких данных и так и не смогли найти способ воспроизвести этот эффект.
@jimboy3100
Предполагаю, что сам диск никогда не становился таким быстрым. Вероятно, вы наблюдали, как менеджер кэша и менеджер памяти NT случайно позволяли активному рабочему набору базы данных почти полностью находиться в оперативной памяти. Установка файла подкачки на ноль не отключала виртуальную память, но в той бета-версии это могло изменить поведение фиксации/подкачки настолько, что система перестала выгружать полезные страницы и вместо этого сохранила гораздо больше страниц файлового кэша/базы данных в оперативной памяти. Таким образом, в бенчмарке отображалась бы «скорость диска», но реальный путь ввода-вывода в основном обходился после первого чтения.
Это также объясняет, почему это исчезло в финальной версии NT4. Microsoft, вероятно, исправила обрезку кэша, учет фиксации или поведение отложенной записи до RTM, потому что такое поведение было бы опасно при нехватке памяти. На машине с подходящей рабочей нагрузкой и достаточным объемом оперативной памяти это казалось бы потрясающим, но это не было надежным улучшением хранилища; по сути, это был случайный режим кэширования в оперативной памяти для вашей рабочей нагрузки базы данных. Таким образом, ваша теория, вероятно, очень близка к истине: виртуальная память и дисковое кэширование взаимодействовали лишь на бета-уровне, но база данных не попадала в файл подкачки — она оставалась активной в кэше файловой системы.
@alexandrestrube
Я защитил докторскую диссертацию по базовым блокам и оптимизации производительности. Это меня очень задело.
@dsudikoff
Dave, you are restoring my estimation of Microsoft engineers. As a DEC real-time OS developer I thought you were a bunch of morons. On My midnight visit to Washington MS campus on Sunday midnight, I observed many frustrated engineers having to do tedious WNT4 reboots. Now I know you guys weren't so clueless. Whew!
Дэйв, ты восстанавливаешь мое представление об инженерах Microsoft. Как разработчик операционных систем реального времени в DEC, я считал вас кучкой идиотов. Во время моего ночного визита в кампус в Вашингтоне, штат Миссисипи, в воскресенье, я наблюдал, как многие расстроенные инженеры были вынуждены утомительно перезагружать WNT4. Теперь я знаю, что вы, ребята, были не такими уж и бестолковыми. Фух!
@jimwinchester339
Я также работал над аналогом BBT для защищенного режима в AT&T, Мидлтаун, Нью-Джерси. Он включал в себя полный трекер содержимого регистров 80x86 (внутри каждого базового блока), который отслеживал, является ли каждый бит каждого регистра 0, 1 или неизвестным. Это позволяло заменять определенные инструкции, обычно те, которые включают непосредственные операнды, регистровыми операндами, когда было известно, что эти регистры содержат 0 или (~0). Наиболее примечательно, что он отслеживал содержимое сегментных/селекторных регистров, фактические значения которых становились неизвестными только после полной (статической) компоновки программы. Это позволяло оптимизировать очень дорогостоящую перезагрузку сегментных селекторов в защищенном режиме, иногда заменяя их переопределением сегмента на другой сегментный регистр, содержащий то же значение. По крайней мере, можно было оптимизировать трудоемкий процесс перемещения значения селектора в промежуточный общий регистр, а затем в целевой сегментный регистр, просто с помощью команды PUSH <imm8/16>, а затем записи в сегментный регистр, сэкономив 1 или 2 байта. Программа называлась, как ни странно, OPTIM. И если они все еще существуют, Рич Пенненга, Джон Палфраман и Рон Джантц могут это подтвердить.
Комментариев нет:
Отправить комментарий