Занимательная многоядерность

⇡#Ложка дегтя

На первый взгляд, даже измученному сессией студенту-филологу может показаться, что писать программки для метеорологов, на 100% использующие возможности современных многоядерных процессоров, проще простого. Огорчу вас. Это, мягко говоря, не так.

Во-первых, само по себе многопоточное программирование довольно сложная и коварная штука, и у многих программистов есть проблемы с возможностью представить себе в голове, как программа будет работать на самом деле. Вследствие этого, многопоточные приложения обычно подвержены появлению в них очень тонких и неочевидных ошибок, которые трудно воспроизвести и обнаружить (любознательные бегут в поисковик с запросами deadlock и race condition).

Момент второй — переход от линейного решения задачи к многопоточному его варианту, который был бы при этом еще и эффективнее линейного, чаще всего есть весьма и весьма нетривиальная задача. Код такого решения почти всегда объемнее и сложнее линейного кода, а значит его дольше писать, сложнее отлаживать и дороже сопровождать. Более того, в мире существует огромное число задач, которые крайне неохотно поддаются распараллеливанию (даю подсказку, это такие, где каждый последующий шаг вычисления жестко завязан на результат работы предыдущего).

В общем, умение писать хорошо масштабирующие по количеству ядер программы — это целое искусство.

Лучшие умы человечества бьются над тем, чтобы упростить написание подобного рода программ. К примеру, есть целый класс языков программирования (так называемые функциональные языки), код на которых автоматически можно выполнять на любом количестве ядер. Одна проблема — языки эти довольно специфичны, они не очень хорошо подходят для решения целого ряда задач, и их доля на рынке колеблется в районе жалких пары процентов. Замечу, что, в противоположность экзотическим функциональным языкам программирования, существует целый ряд современных и популярных языков, которые вообще не поддерживают эффективную многопоточную модель. Например, к таким относится Python и Ruby.

Наверное, непросто будет устоять, когда такие красивые орудия маркетологов начнут убеждать нас в необходимости многоядерного смартфона?

А теперь хотелось бы вернуться к тому, с чего я начал этот материал — к теме двухъядерных мобильных устройств. Почему производители начали растить свои процессоры вширь, а не в высоту, я подробно описал в первой части, теперь надо объяснить — почему по этой же проторенной дорожке вынуждены пойти производители мобильных решений. Как мы знаем, потолок частоты, которого достигли сегодня в мобильных одноядерных системах с ядром ARM, чуть больше 1 ГГц. Вроде бы не так много, по меркам 3+ ГГц, за которые мы шагнули на десктопах. Однако в мобильном мире есть два важных нюанса, предопределивших переход на многоядерность именно на этом рубеже.

Первое — вопрос охлаждения. Мало того, что вы не можете использовать кулеры внутри корпуса современного смартфона, толщина которого составляет каких-то 10 мм, вы даже более-менее солидный радиатор вряд ли уместите.

Начинка двухъядерного смартфона LG нуждается в весьма внушительном по мобильным меркам радиаторе

Второе — энергопотребление. Тут постоянно ищется баланс между мощностью процессора и потребляемой мощностью. Повышать частоты на текущем витке технологических возможностей означает, что ваш любимый «гуглофон» будет умирать не через 6 часов активного использования, а через каких-то жалких два.

В общем, от прогресса никуда не убежишь — добрый дедушка Мур исправно дает каждые два года новую порцию транзисторов, и производители мобильных решений решили использовать ее для реализации второго ядра общего назначения (помимо всего прочего, немалая часть этих тразисторов в современных SoC идет на GPU, который, как мы помним, масштабируется куда как веселее).

Фантазируя по поводу смысла появления многоядерности в мобильных устройствах, маркетологи иногда придумывают совсем уж странные задачи, вроде транслирования HD-картинки с планшетного ПК на телевизор…

Что же нам дает появление второго ядра в смартфонах?

Честно говоря, не так уж и много. Точно так же, как и на десктопе, где обычно востребованы жалкие пара процентов от потенциальной мощности вашего четырехъядерного монстра, в мобильном мире есть очень узкий класс задач, где действительно нужны такие вычислительные ресурсы. Кроме хардкорных игр, честно говоря, даже мало что приходит на ум. Потому что даже задача кодирования/декодирования видео в высоком разрешении очень часто решается специализированным декодером, а не усилиями центрального процессора. А если вспомнить главную программу любого современного смартфона — браузер, то и тут есть много узких и неудобных мест, которые не дадут многоядерности сказать свое веское слово. К примеру, используемые сегодня JavaScript-движки многопоточность не поддерживают.

Второе ядро может пригодиться в смартфоне, если его владелец увлекается так называемой «дополненной реальностью».

Есть люди, которые полагают, что появление второго ядра скажется на плавности работы и общей отзывчивости системы. Тут тоже есть свои нюансы. К примеру, общеизвестно, что Android OS страдает регулярно возникающими лагами в работе. Многие специалисты полагают, что вызваны они явлением под названием «сборка мусора» (это когда работа приложений приостанавливается для того, чтобы специальный механизм привел в порядок их динамическую память). Можно рассуждать так — раз у нас два ядра, то одно ядро будет заниматься сборкой мусора, а второе в это время будет себе работать дальше! Никаких лагов! На практике, написать хороший алгоритм сборки мусора так, чтобы во время его активности приложение продолжало работать дальше без потери производительности, — не такая уж тривиальная задача (аналогия — трудно переставлять в комнате мебель и одновременно делать в ней уборку). Некий concurrent garbage collector появился в Android 2.3, но пока трудно сказать — насколько он хорош в деле. Есть сильное ощущение, что на двух ядрах в смартфонах лежит толстый-толстый слой маркетинга, как в свое время на 64-битности процессоров Athlon 64. Когда таковая стала действительно востребованной, процессоры уже успели безнадежно устареть…

Нашумевший двухъядерный Motorola Atrix 4G основную часть времени работает смартфоном, но если владелец раскошелится на недешевую док-станцию, может превратиться в смартбук. Правда, пока трудно судить — насколько востребованным окажется такое решение

⇡#Сухой остаток

Если кто не понял, то статья эта была о том, как трудно живется программистам после того, как их подставили нехорошие производители процессоров. Кроме шуток. Мы вступили в эпоху, когда разработчики игр для современных (читай — многоядерных) консолей выступают с большими докладами, суть которых сводится к тому, как, не слишком уродуя код, решить проблемы «modern hardware restrictions». Может быть, я наивен и старомоден, но мне всегда казалось, что прогресс должен снимать с разработчиков ограничения, а не наоборот (подробнее можно почитать, к примеру, здесь). К сожалению, рост процессоров в ширину, который до прихода на десктопы хорошо себя зарекомендовал в области серверных решений (потому что там постоянно нужно обслуживать несколько клиентов), на мирных компьютерах и в мобильной области в некотором смысле знаменует собой эпоху застоя и проблем, связанных с выбрасыванием старых подходов к решению задач, переучиванию квалифицированных специалистов и переписыванию большого количества существующего кода.

Закон Мура все еще работает, но ощущаем ли мы это?

P.S. Мы попросили прокомментировать этот материал представителя Intel Дмитрия Оганезова, менеджера сообщества Intel Software Network (http://software.intel.com/ru-ru/).

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

Вот уже лет пять, как частота процессоров замерла в районе 3 гигагерц (о, ужас!). Почему так вышло? Мы все еще не оставили надежду на то, что статью действительно прочитали несколько гуманитариев, а попытка объяснить сей феномен «на пальцах» может отпугнуть и их… Тем не менее, это поможет нам посмотреть на всю картину в целом.

Итак, рост частоты интегральных микросхем ограничен не только и не столько потребляемой мощностью — эту проблему производители научились решать применением более «тонких» технологических процессов. К сожалению, есть еще одна загвоздка: современный процессор представляет собой крайне сложное устройство, некоторые модели содержат больше миллиарда транзисторов. Физические процессы, которые происходят при работе такого количества транзисторов на высоких частотах, неизбежно приводят к некоторым помехам (наводкам) внутри схемы, а как следствие — проблемам со стабильностью в целом. Очевидно, что простого и эффективного решения этих проблем на данный момент не существует.

Что же делать? К счастью, на помощь приходит как раз пресловутая возможность совершенствовать техпроцесс. Это значит, что при той же тактовой частоте и потребляемой мощности можно делать процессоры с большим количеством транзисторов. Возникает резонный вопрос — как лучше использовать эти «лишние» транзисторы? Хорошая новость заключается в том, что значительное количество «бесплатных» транзисторов попадают в те блоки процессора, которые не связаны напрямую с «многоядерностью», как например блоки SSE/AVX, а также в кеш-память различных уровней. Это дает возможность повышать производительность процессора на десятки процентов от модели к модели при том же количестве основных вычислительных ядер.

Таким образом, те программисты, которые пока не осилили принципы параллельного программирования, могут быть спокойны: запаса «последовательной» производительности хватит еще надолго. Кроме того, как подсказывает практика, целый класс алгоритмов так и будет существовать только в том или ином последовательном виде.

Тем же, кому действительно нужен существенный рывок в скорости, стоит отбросить смутные сомнения и приступать к распараллеливанию. Да, это не так просто. Но давайте вспомним, как оконные пользовательские интерфейсы и функциональная сложность программ прикончили структурное программирование и послужили началом великой эпохи ООП… К тому же, при всей своей сложности, параллельная парадигма, пожалуй, на данный момент является… наиболее простой из всех существующих парадигм.

Вполне возможно, что мы стоим на пороге новой великой эпохи, а уж будет ли она эпохой параллельного программирования, или эпохой неоднородных вычислений, или еще какой-то там новой эпохой — покажет время. И само по себе наличие выбора никак не позволяет мне назвать нашу эпоху «эпохой застоя».