https://x.com/davepl1968/status/2067329306918097044
https://www.youtube.com/watch?v=jH0BYAkPj78
@MrCOPYPASTE
Hi Dave, In my humble opinion this is one of your best videos.
@DavesGarage
Thanks for the kind words!
@antperez1684
@DavesGarage Is there any way to look at the code of LEGO BBT, or does the code remain closed-source and secret? Thanks.
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. И если они все еще существуют, Рич Пенненга, Джон Палфраман и Рон Джантц могут это подтвердить.
@chadvanderlinden9548
Я не знал о существовании BBT/LEGO, но ещё в 90-х мечтал о чём-то подобном. Я представлял себе систему, которая бы проходила по коду, как если бы программа работала, и находила участки кода, которые никогда не выполнялись, повторно использовала бы код, чтобы избежать дублирования, и группировала бы часто выполняемые фрагменты. Также я читал пару статей о парне, которого компании нанимали для ручной оптимизации ассемблерного кода. Из опыта он понял, что команды выполняются быстрее, если их выполнять в определённом порядке, и его знания не были широко известны. Сейчас же "Hello World" — это 550-мегабайтный файл, и это никого особо не волнует.
@2nolhta
Старая добрая оптимизация файлов компоновщика Clipper Summer 87: что что использует, а что не следует выгружать в файл подкачки во время выполнения этой задачи.
@jczeigler
Мне очень нравятся ваши видео. Когда я занимался коммерческой разработкой программного обеспечения, я часто повторял одну и ту же фразу: «Сначала нужно сделать всё правильно, а потом ускорить процесс».
@RobShinn
BBT хорошо работал только потому, что Windows была монокультурой. По крайней мере, так я себя убеждал, пока не нашел BOLT от Meta, который делает то же самое, но на Linux и даже, экспериментально, на самом ядре Linux. Удивительно.
@Paul-nu7nj
Сейчас операционная система Microslop занимает 16 ГБ, а раньше Apple удавалось запускать VisicalC всего за 4 КБ.
@WndSks
These days it would also be possible to "pre-hint" the PGO with the likely/unlikely C++ attributes on conditionals.
В наши дни также можно было бы "предварительно подсказать" PGO, используя атрибуты C++, указывающие на вероятность/вероятность, в условных операторах.
@PanzerschrekCN
Как ему удалось дизассемблировать бинарные файлы? Насколько я понимаю, это не так просто, поскольку инструкции x86 имеют переменную длину. Можно проследить граф вызовов, начиная с точки входа, но это не работает для косвенных вызовов (через указатель на функцию) или других методов, используемых компиляторами или написанных вручную на ассемблере, что приводит к нестатическому ветвлению.
@Crocodilesnaper
@shallex5744 😂👍🏼 Не отрицаю, что любая критика моего комментария необоснованна, и на самом деле я так же виновен, как и все остальные, когда дело доходит до критики Microsoft. Я, кстати, постепенно перехожу с Windows на Linux и программное обеспечение с открытым исходным кодом. Действительно, Microsoft следует критиковать, потому что они определенно уже не та инновационная компания, какой были раньше, и вместо этого превратились в кучку корпоративных карманников. Тем не менее, давайте не будем забывать, что когда-то они были компанией, которая внесла стандартизацию в бурно развивающуюся индустрию ПК, страдавшую от серьезных проблем с несовместимостью. Будем надеяться, возможно, наивно, что они услышат наши жалобы и что-нибудь с этим сделают. Мир вам!!!!
Я не пытаюсь быть слишком негативным или ворчливым, и я определенно не нападаю на вас и не пытаюсь сказать, что вы совершенно не правы, я просто говорю, что, на мой взгляд, состояние компьютерной индустрии сегодня позорное, зашло слишком далеко, подорвано и захвачено компаниями, которые ценят только прибыль любой ценой, и именно это нравится Microsoft, и они будут продолжать причинять вред миллионам людей в массовом масштабе, чтобы достичь этой цели, и они делают это уже десятилетия. Просто посмотрите документы с Хэллоуина, посмотрите видеозаписи показаний Билла Гейтса, это говорит вам все, что нужно знать о Microsoft.
@ZeekMX
BBT LEGO СТРАНИЦЫ РАСПОЛОЖЕНИЕ ПАМЯТИ инструмент отладки ветвление или неветвление, совместное существование кода в бинарном дереве, книжная полка, холодильник. Вытесняющая рабочая станция ядра NT. Карманная оперативная память NT4, совместное использование памяти. Пользовательские приложения и т. д., внедренные из-за разочарования инженера в костюмах. 200 байт, пиво, функции, горячий путь, пути ошибок, воздушный случай, else, резидентный/нерезидентный, холодный/горячий кластер, принтеры с привидениями. lol. ДЭЙВ ДЭЙВ ДЭЙВ... lol
@gsestream
isnt this kinda outdated with larger chip internal sram size. at least should be. yes profiling compiler can do that same style of runtime optimization of code paths. btw world is doing nothing. christ is doing everything. so stop claiming work duty to the world, world. also solution is to use better hardware designs from the start, ie fear of the lord is the start of wisdom. dont fear people with their law demands. thats a command from christ. when the beast is in your head, and you are yourself in the head, you dont have to do anything, even if world flesh beast tells you to do something. what memory pages. get understanding from christ beforehand as free gift. switch-case statement table jump vs if-else chain is a nice optimization thing. the most basic high level code optimization. ie kinda data structure and code path level optimization.
Разве это не устарело с увеличением размера внутренней SRAM на чипе? По крайней мере, должно быть. Да, компилятор профилирования может выполнять такую же оптимизацию кода во время выполнения. Кстати, мир ничего не делает. Христос делает всё. Так что перестаньте приписывать миру свои обязанности. Также решение состоит в использовании более совершенных аппаратных решений с самого начала, то есть страх Господень — начало мудрости. Не бойтесь людей с их требованиями закона. Это повеление Христа. Когда зверь в вашей голове, и вы сами в его голове, вам не нужно ничего делать, даже если зверь из плоти и крови велит вам что-то сделать. Что такое страницы памяти? Получите понимание от Христа заранее как бесплатный дар. Переходы между таблицами операторов switch-case и if-else — это хорошая оптимизация. Самая базовая высокоуровневая оптимизация кода. То есть, своего рода оптимизация на уровне структур данных и путей выполнения кода.
Комментариев нет:
Отправить комментарий