2021-04-12 12:53:38
Вчерашний разговор про "еврофейсбук" натолкнулся, как мне показалось, на непонимание, кто же в "фейсбуке" пользователи. А это вовсе не те, кто на нем переписываются ("демократический" электорат). Коллега @neformat0 указывает, что истинными пользователями "фейсбука" являются рекламодатели, но и это не совсем верно. Окончательным и единственным пользователем "фейсбука" является государственная бюрократия ("аристократия").
Я выцедил из черновиков следующую заметку, которая, возможно, поможет вам пощупать мое видение проблемы. Внимание, она имеет черты аллегории. Извините за частые отсылки к аниме-тайтлам.
Когда я был помладше, меня очень интересовали VLIW-архитектуры. VLIW это "very long instruction word", подход к наборам инструкций для суперскалярных процессоров (т.е. таких, у которых несколько конвееров), где компилятор явно указывает, на каком конвеере исполнять каждую инструкцию. Считалось, что это позволит упростить управляющую логику процессора, убрав из нее динамический планировщик, а также повысит эффективность исполнения, т.к. у компилятора гораздо больше времени на поиск хорошего плана, чем у процессора.
Сейчас о VLIW подзабыли, потому что этот подход себя не оправдал. Если напряжете память, то возможно вспомните Intel Itanium, для которого так и не смогли сделать хорошо работающий компилятор. Причем VLIW у Итаниума был даже с компромиссом: вместо длинных слов инструкции паковались в связки (bundles) по три штуки, и на самом чипе какая-то планирующая логика оставалась. Что уж говорить об архитектурах, которые замахивались на еще бОльший контроль над планами со стороны компилятора (например, такие, где в ассемблерных командах указывается не только привязка инструкций к конвеерам, но и даже коммутация портов конвеера на каждый отдельный цикл :) ).
Обещанный прирост производительности VLIW не дал вовсе не из-за сложности разработки компиляторов — она постоянно падает. Исследователи в области языков программирования создают новые языки, чтобы было удобнее создавать еще более новые языки. (В частности, одна из самых крупных программ, написанных на Haskell, это Glasgow Haskell Compiler. :) ) Само стремление полностью распланировать исполнение во время компиляции оказалось порочным. Ведь распределение ограниченных ресурсов сильно зависит от того, какое их вложение оказывается наиболее выгодным. Очень важно собирать статистику о ходе исполнения программы (traces), чтобы потом оптимизировать её самые "горячие" куски.
Но и "априорное мышление" VLIW тоже не самый главный недостаток. Изобрели бы какой-нибудь JIT-компилятор, пользующийся собранными traces. Здесь у кого-то заиграет либертарианская жилка: что же это, чтобы переставить местами две инструкции, надо собирать trace, отправлять его в Генплан^WJIT, ждать следующей пятилетки^W^Wперезапуска программы?
Корень проблемы лежит в том, что "канал связи" между микроархитектурой и компилятором, который воплощает набор инструкций, очень узок. Сверхдлинные слова, ожидаемо, оказались сверхдлинными. Они занимают много памяти относительно обычных инструкций RISC/CISC, их меньше помещается в уже и так маленький кэш инструкций. Провал VLIW по производительности во многом объясняется тем, что не получается снабжать конвееры инструкциями достаточно быстро. Никакой сверхоптимизированный план инструкций не даст выигрыша, покрывающего потери от простоя конвееров.
Для VLIW пытались разрабатывать схемы сжатия инструкций (отчасти, ей являются bundles Итаниума), но они все равно оказались недостаточно эффективными, к тому же требовали более сложной декодирующей логики. Архитекторы Intel пришли к выводу, что набор инструкций процессора не должен слишком уклоняться ни в сторону статического планирования, ни в сторону динамического.
Аристократия и демократия относятся друг к другу также как планировщики инструкций в компиляторе и в процессоре. Они тоже взаимодействуют друг с другом через некоторый заранее определенный "канал связи" в виде "набора инструкций". Один из примеров такого "набора инструкций" это и есть "фейсбук".
979 viewsedited 09:53
М
