Многопоточность

Приближается не очень круглая дата, 9 лет со дня выпуска новой, 52й версии браузера Firefox, использовавшей раздельную, многопроцессную архитектуру. Пользователи могли и не заметить такое изменение в организации исполняемого кода этого приложения, но всё же оно знаменательно, и вот почему. Чтобы понять, о чём идёт речь в этой статье, достаточно открыть планировщик задач и посмотреть, сколько процессов числится за одним окном Firefox. Вы увидите по одному на каждую закладку, загрузившую страницу. До 52й версии там был бы только один.

Примерно за 10-14 лет до того Intel и AMD выпустили первые потребительские процессоры с более чем одним ядром. С этого момента программное обеспечение получило возможность ускорить свою работу за счёт распараллеливания обработки данных. Произошло ли это? Увы, дальше глобальный рынок информационных технологий решил позориться и продолжает уже почти 20 лет. Причём здесь Firefox? А притом, что, благодаря распределителям нагрузки пользовательских задач в любой современной операционной системе, многопоточные приложения вроде него должны по умолчанию, безо всяких усилий со стороны их разработчиков работать параллельно при наличии более чем одного процессорного ядра. Вот только Firefox почему-то об этом или не знает, или знает, но предпочитает работать в один поток.

Проверить и убедиться в этом просто. Достаточно открыть две закладки и в одной из них зайти на какую-нибудь страницу, которая использует длительную и тяжёлую для процессора обработку на языке JavaScript. Пока она продолжается, открыть какую-либо другую страницу в другой закладке вам не удастся, потому что движок Firefox «занит, щасвирнус».

Чтобы написать Firefox, потребовался гений команды Netscape и их последователей в проекте Mozilla. Я не преувеличиваю: это действительно гений. Chrome пришёл позже, на готовенькое. Да, у Firefox, несмотря на то, что он давно уже позаимствовал движок от Chrome, есть огрехи. Некоторые страницы в нём просто не работают, и приходится запускать Chrome. Но тут ничего не поделаешь: официально некоммерческому проекту, пусть даже поддержанному «большой рекламой», всё же трудно соревноваться с глобальным монополистом Google с их триллионными бюджетами. И тем не менее, Firefox использует массу гениальных решений и алгоритмов для отображения страниц и исполнения их программ на JavaScript. Что ж эти гении не удосужились использовать многопоточную технологию, которая доступна уже 20 лет как?

Разруха не в подъезде. Она в головах. Проблема заключается в целенаправленной войне невидимых, тёмных сил, развязанной против распараллеливания вычислений. Иначе трудно объяснить панический страх перед многопоточным кодом, который испытывают многие профессиональные разработчики, получившие профильное высшее образование. Кто-то убедил их в том, что распараллеленный код злой, опасный, трудный, и его нужно избегать, а каждого, кто пытается его использовать, нужно избить или покусать, как макаки, чтобы неповадно было. А ведь достаточно, как и в других областях жизнедеятельности, победить страх и начать работать в нужном направлении.

Что рядовому пользователю до всего этого? А то, что ПО, не использующее все ядра процессора, не масштабируется. Частоты упёрлись в способность проводников передавать сигналы, транзисторов переключаться, а охлаждающих систем отводить тепло. Выжать из кристаллов ещё сколько-нибудь мегагерц становится всё сложнее, оптимизировать архитектуру исполнительных устройств тоже непросто, и пока остаётся только добавлять ядра, но если ПО их не использует, то от них толку не будет, и пользователям в какой-то момент придётся смириться с «тормозами» и просто сидеть и ждать, а время ушло, и программистов задрессировали работать в однопотоке. Ситуация кажется безвыходной, не так ли? Да, их надо было готовить к эксплуатации масштабно многоядерных систем все эти 20 лет, чтобы сейчас любой школяр мог с лёгкостью написать ПО, способное эффективно загрузить все ядра. Вместо этого даже гениальные профессионалы сторонятся такой работы, причём, если верить соцсетям, ещё и других запугивают, но это дело тёмное.

С чего бы кому-то запугивать окружающих параллельностью, спросите вы? А с того, что всё опять упирается в монополизацию рынка информационных технологий и повального помешательства облачными сервисами. Дело в физической архитектуре персональных компьютеров, на которых крутятся облака, и модели оплаты за аренду вычислительных мощностей. Вместе эти два фактора оказывают давление на потребителей вычислительных услуг в направлении прочь от многопоточности.

Парадокс? И да, и нет.

Да, потому что потребитель заинтересован в максимальной производительности и эффективности своей инфраструктуры на единицу затраченных средств.

Нет, потому что поставщик заинтересован в противоположном: чтобы ПО загружало процессор, как можно сильнее: они получают оплату, как за каждый день, так и за каждый такт. Им необходимо, чтобы им платили или повременно, или за нагрузку, а она упирается в пропускную способность процессорного кэша, который один на всех клиентов, виртуальные машины или контейнеры которых крутятся на одном сервере. Желательно, конечно, чтобы платили и за то, и за другое.

Простым, грубым человеческим языком, поставщик облачной услуги хочет, чтобы ПО каждого клиента работало на как можно меньшем количестве ядер, не замедляя весь сервер и ПО других клиентов, чтобы позволить каждому из них как можно сильнее нагрузить ядро в каждый момент времени. А как можно этого добиться, если не запугать разработчиков? Нельзя же сказать клиентам, чтобы те подписывались только на одноядерные виртуалки! Вот и рождаются мифы о вредоносности и опасности многопоточной обработки, которые распространяют, внезапно, с подачи горстки мировых монополистов в данной области деятельности.

Вернёмся к нашим баранам. Firefox был однопоточным всю свою историю, но тут вот какое дело. Чтобы остаться однопоточным после смены архитектуры на многопроцессную, нужно было предпринять особые усилия по синхронизации вызовов функций, использовать особые меры, потому что иначе сама операционная система предоставила бы разным процессам разные ядра, и влияния загрузки процессора одной закладкой на другие не существовало бы, а оно есть, как тот суслик. И тут тоже проявилось влияние тёмных сил, которые я наблюдаю уже давно во многих организациях, которые вроде бы должны быть заинтересованы в обратном.

Промывание мозгов выпускникам профильных университетов зашло так далеко, что фраза «потоки — это зло» стала широко распространённой мантрой, повторяемой бездумно и безапелляционно, даже при полном отсутствии знаний о том, как обстоят дела на самом деле. Её можно найти в профильных соцсетях и отследить до тех самых монополистов глобального рынка информационных технологий. Куда приведёт мир следование ей? Да в принципе, никуда. Она уже привела нас к застою. Сравните среднюю производительность по «этим вашим Интернетам» 20 лет назад и сегодня, и она не в пользу современности. Об этом я уже писал ранее в этом цикле статей: догмы и шаблоны победили, а производительность проиграла.

Можно ли что-то исправить? Если пересадить головы сотне-другой миллионов разработчиков ПО, то да, но откуда взять донорские? Серьёзно же, я не знаю, что делать, потому что подготовка специалиста занимает минимум пять, а на самом деле в два раза больше лет. Это вам не просто так сесть и прочесть учебник: нужно пройти школу реальности, набить шишки и обрести понимание того, где усилия приносят максимальный эффект, а где они не стоят потраченного времени.

Изоляция разума от окружающей среды приводит к неадекватному восприятию реальности. Изолировав разработчиков от аппаратного обеспечения при помощи облачных услуг, человечество выстрелило себе в ногу. Прежде разработчики видели, как при работе их ПО моргал светодиод доступа к диску и завывали вентиляторы. Теперь они лишь нажимают кнопку сохранения изменений в системе контроля версий и больше никогда не видят и не слышат, как отрабатывает их код. Они даже в планировщик задач взглянуть зачастую не могут, чтобы увидеть, как одно ядро загружено на 90-100%, а остальные курят бамбук. Откуда при этом взяться пониманию важности производительности?

Когда я начинал свою карьеру, запуск профилировщика после компиляции и анализ времени, затраченного наиболее используемыми и длительно выполняющимися функциями считался даже не нормой: он был просто обязателен. На сегодняшний день я с трудом могу назвать одного разработчика из тысяч бывших и нынешних сослуживцев, которым вообще известно, что такое профилировщик, и что он существует. А ведь все они считаются высококлассными специалистами и сделали головокружительные карьеры.

Написать код, который производит желаемый результат, не слишком сложно. Сделать это эффективно уже гораздо сложнее. И вот человечество платит те деньги, которые можно было бы сэкономить, и тратит время, которое можно было употребить с большей пользой, и всё это в условиях глобального экономического кризиса и режима строжайшей экономии. Что ж индустрия информационных технологий так враждебно относится к остальному человечеству? Неужели у неё есть какие-то неудовлетворённые претензии? Или, может быть, она избаловалась работой «не бей лежачего» в уютных кабинетах с отоплением и кондиционированием, за которую платят огромные по меркам других профессий деньги?

Внимательный читатель может возразить: если ты такой умный, то пойди, напиши правильный код для Firefox и покажи всем, как надо. При иных обстоятельствах я бы, может быть, так и сделал, но не после того, как Mozilla Foundation десятилетиями лгал пользователям, игнорировал их просьбы и предложения по улучшению их продуктов, урезал функциональность, выкручивал пользователям руки ради удобства «большой рекламы» и много ещё как показывал своё истинное, продажное лицо, причём без какой-либо особой нужды, ведь они давно уже используют движок Chromium от Google, то есть экономят значительный объём работ по разработке. Тем временем, я уже четверть века применяю многопоточные решения, получавшие отзывы от заказчиков в духе «оно стало в 4 раза быстрее!». Если это могу я, то уж гениям из Mozilla и подавно следовало бы, но они предпочли продолжать позориться.

В мире информационных технологий полно вещей, которые вообще никогда не должны были возникнуть или состояться. Среди них много того, на что этот мир нынче молится: Node.js, Python, Entity Framework, WordPress и другие, в том числе Firefox. Дело в том, что многое в нём было переписано с C++ на JavaScript, то есть с компилируемого языка, выполняемого напрямую на процессоре, на интерпретируемый язык, выполняемый промежуточной программой. Управлять такими архитектурами, в особенности с точки зрения производительности, гораздо сложнее. Хотите доказательств? Сравните время открытия страницы с большой таблицей в Netscape и в Firefox. Первый выиграет с огромным отрывом. Вот и остаётся спросить: у нас что, проблем мало, что мы ищем самое сложное и неэффективное из возможных решений?

Всё это говорит о том, что те, кто могли бы повлиять на положение вещей, не обладают необходимой квалификацией. Нам остро нужны специалисты, не являющиеся программистами, но владеющие предметом, чтобы они, не являясь частью проблемы, могли найти решение. Иначе мы так и будем сидеть и ждать, пока прогрузится эта чёртова страница, хотя могли бы уже выполнить работу, заработать и осчастливить очередного клиента, ожидающего своего обслуживания.

И вот опять всё вышеизложенное подтверждает, что человечество хронически не в состоянии сосредоточиться на главном и всё время отвлекается на второстепенное. Главное для него - это что бы Youtube и TikTalk бухтели, а то, что на это тратится мощность лишней электростанции - так это пустяк.