company_banner

System-level optimization и её вклад в решение проблем энергопотребления


    О том, как проблемы энергопотребления решаются на этапе проектирования микропроцессоров, рассказывалось в серии постов «Жизнь в эпоху «тёмного» кремния». Были освещены четыре основных подхода, однако существует ещё один подход, речь о котором пойдет в этот раз. Это оптимизация на системном уровне.

    Первый же вопрос, который закономерно возникает — почему system-level? Ответ на него крайне прост – значение имеет конечный продукт, а не «винтики» из которых он состоит. Необходим системный взгляд на связку программный стек + аппаратная платформа + полупроводниковые компоненты, для того, чтобы оценить характеристики конечного продукта и управлять ими.

    Это верно и в случае с энергопотреблением: комплексный подход открывает новые возможности для оптимизации и позволяет решать иначе неразрешимые задачи. В этом посте я приведу несколько примеров, чтобы показать, что это действительно так.

    big.LITTLE


    Данная идея заключается в том, чтобы объединить в рамках одной системы два процессора. Один — для решения высокопроизводительных задач, а другой – для меньшего расхода энергии там, где не требуется большая производительность. Соответственно, если переносить вычисления с одного процессора на другой при изменении нагрузки, можно добиться экономии энергии.
    Разработчики из ARM объединили таким образом процессоры Cortex-A7 и Cortex-A15. Эти процессоры практически идентичны с точки зрения архитектуры системы команд, модели памяти и программной модели. Соответственно все инструкции будут выполняться единообразно, хотя и с разной производительностью.
    Различия становятся заметны на уровне микроахитектуры. Cortex-A7 это in-order процессор, с длинной конвейера 8-10 ступеней. А Cortex-A15 это out-of order процессор, конвейер которого насчитывает от 15 до 24 ступеней (в зависимости от инструкции).

    big.LITTLE система

    Энергопотребление такой системы изображено на следующем графике. Как видно, в области низкопроизводительных вычислений использование A7 дает примерно двухкратный выигрыш в энергопотреблении по сравнению с A15.

    Производительность big.LITTLE системы

    А при чем тут system-level? Дело в том, что действуя на каком-то одном уровне ничего подобного создать бы не вышло. Необходимо уделить внимание сразу трем уровням:
    — Используемые процессоры должны обеспечивать соответствующий выбор между производительностью и энергоэффективностью, а также идентичность программной модели.
    — Аппаратная платформа должна обеспечивать должное взаимодействие этих двух процессоров
    — Системное программное обеспечение должно обеспечивать миграцию вычислений с одного процессора на другой, решая все сопутствующие задачи. Кроме того, A7 и A15 хоть и практически идентичны с точки зрения программной модели, но не на 100%. Эти отличия необходимо скрывать от верхних уровней операционной системы и выполняемых программ.

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

    Android Power Management Stack


    Сабж представлен на следующем рисунке. В самом низу находятся реализованные в железе аппаратные средства управления энергопотреблением и firmware, выполняемое PCU (Package Control Unit). Далее следует программная часть, относящаяся к ядру Linux и окружению Android и, собственно, пользовательские приложения. Чего удалось бы достичь с точки зрения экономии энергии, если бы каждый разработчик не смотрел за пределы своего уровня стека? Например, если бы Intel уделял внимание только той части управления энергопотреблением, которая относится к кремнию и firmware, игнорируя остальное? Процессор точно не вышел бы из строя от перегрева :), но чего-то большего я бы не стал гарантировать. Даже если на аппаратном уровне менеджмент реализован безупречно, но программная часть довольно посредственная, то о хороших показателях можно забыть. Именно поэтому тратится масса усилий на совершенствование всего стека как единого целого.


    System-level power delivery


    Здесь наше внимание привлекает тот факт, что система обеспечения питания в мобильных платформах (например, смартфоны) сама по себе потребляет немало энергии (20-40%). Более того, энергопотребление процессора не является доминирующим в системе. В таких условиях оптимизация энергопотребления должна выполняться на системном уровне. Например, выбор оптимальной частоты для процессора необходимо проводить с оглядкой на энергопотребление остальных компонентов системы.



    Рассмотрим такой пример. Предположим, текущая нагрузка процессора существенно ниже максимальной. В такой ситуации есть два варианта поведения. Первый – быстро (на большой частоте и с большей потребляемой процессором мощностью) выполнить вычисления и перейти на длительное время в спящий режим. Второй – медленно (затрачивая процессором меньше энергии в единицу времени) выполнять расчеты и перейти в спящий режим на гораздо меньшее время. Какой вариант выбрать? Это совсем не просто, и для этого нужно знать сколько потребляют остальные компоненты системы в различных режимах.


    Themperature estimation and management


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


    В заключение хочу сказать, что оптимизация на системном уровне стала по-настоящему необходимой вещью. Её польза очевидна и ряд задач иначе решены быть не могут. А т.к. в вопросах энергопотребления на нее обратили внимание сравнительно недавно, то есть основания полагать, что в этом направлении еще будет множество интересных достижений.
    Intel
    222.54
    Company
    Share post

    Comments 21

      +2
      MSIC != «система обеспечения питания»
      Питание лишь одна из задач MSIC, причём только одна из многих (~10 компонентов может включать в себя MSIC). К примеру, MSIC может отвечать за сенсорику, в том числе и за тач-интерфейсы, или за аудио (там как раз ADC/DAC нужны). Так же иногда содержит драйвер дисплея, который является промежуточным этапом между граф. чипом и контроллером дисплея.
      Так что цифры в 20-30% имхо не столь шокирующие.
        0
        Спасибо за уточнение к моему не слишком удачному переводу.
        А как бы вы назвали по-русски «system-level power delivery»?
          –1
          MSIC = Mixed Signal IC. Хотя одна из главных задач IMHO как раз power managenent (управление источником питания, нагрузкой, и зарядкой акку).
            0
            Спасибо, но расшифровку аббревиатуры я прекрасно знаю.
            Меня больше интересует русскоязычный термин, обозначающий то же самое.
            +1
            Ну здесь сложная ситуация с терминологией. Краткая история примерно выглядит так:
            1. Все SoC'и изначально содержали PMIC, причём так и называли их в даташитах.
            2. Пришёл Intel, и в Moorestown сделал, имхо, не совсем рациональную вещь — разделил SoC на 3 части. Langwell, Lincroft и Briertown. Но то ли у них места не хватило в первых 2х чипах, то ли какие-то другие причины были, но в Briertown втиснули помимо PMIC'a еще логику DAC/ADC и вполне резонно назвали это MSIC.
            3. Так как роль PMIC'a выполнял в Атоме MSIC, некоторые стали совмещать эти 2 термина. В том числе и на слайде, судя по всему, ибо AFAIR TI никогда не использовала термин MSIC относительно SoC'ов, В своих OMAP'ах PMIC'и содержат только бизнес-логику связанную с питанием, аудио вынесено в отдельный чип, gpio/тач интегрированы в SoC. Apple юзает свой чип, Samsung — Maxim'овские.
            4. Выходит Medfield (Мегафоновский Mint основан на этой платформе). Троица чипов от Intel заменена одним. Но подвязанный на внешний PMIC. Причём это именно PMIC, а не MSIC, так как выполняет ровно три функции — voltage supply / clocking / voltage control. Внешний — это значит не от Intel. Самое забавное что местами его сами Intel называют по-прежнему MSIC, хотя там только Power Managment.
            5. Clover Trail полностью отказался от аббревиатуры MSIC, в даташитах используется PMIC. Несмотря на то, что с Medfield'ом у них куча общего, в частности интегрированный «PCH», который и взаимодействует с PMIC.

            Как-то так.
            В общем, один странный шаг интел привёл к очередной номенклатурно-терминологической путанице (думаю никто не будет отрицать что с процессорами они откровенно чудят, и без пол-литра не разобраться в названиях и версиях процов для пользователей, хотя в Xeon'ах всё четко).
              0
              Насчет обозначений процессоров — полностью согласен :) Недавно, в магазине приложений Android даже появилась программа для дешифрации маркировок…

              И всё-таки, вы прокомментировали англоязычную сторону терминологии. А какой русскоязычный перевод, на ваш взгляд, наиболее удачен? Просто интересно.
                0
                На слайде я думаю просто запутались между PMIC и MSIC, причём не ясно в какую сторону, то ли на MSIC возложили только Power Managment, только PMIC назвали MSIC'ом, что менее вероятно.
                Отсюда и пошли странные данные.
                А русский перевод имхо вполне корректный.
              0
              Может «управление питанием на системном уровне»?
            +4
            Самое привлекательное в статье — Дерпи))
              +2
              Тут я, увы, матчастью не владею. Подозреваю, что это один из пони?:)
              Еще подозреваю, что большинство недовольных недовольны именно по причине ненависти к ним.))
              Для меня же это просто еще одна картинка.
                +1
                Это пони-пегас, которая справа :)
                  +1
                  Думаю, большинство недовольных недовольны присутствием неканоничных, «злых» пони.
                0
                КДПВ была выбрана рандомно?
                  +1
                  Нет, хоть, похоже, и неудачно.
                  –2
                  снова пост с понями и снова он в плюсе
                    +1
                    система обеспечения питания в мобильных платформах (например, смартфоны) сама по себе потребляет немало энергии (20-40%)

                    Как интересно. Хотелось бы пояснений. Что входит в эту систему и на что расходуется эта энергия?
                      0
                      И тишина…
                        0
                        Извините, пропустил комментарий.

                        Речь идет о MSIC или PMIC (дискуссия о терминологии была выше). Опуская детали — это микросхема, стоящая на пути между батареей и CPU.
                        Наиболее энергозатратная функция — поддержание стабильного уровня напряжения на выходе, что необходимо для работы CPU.
                        По мере разряда батареи уровень напряжения на ней падает, а для работы CPU на определенной частоте нужна вполне конкретная величина.
                          0
                          Спасибо. Но мне все равно не понятно, на что именно расходуется столько энергии. Рассеивается? Неужели современные стабилизаторы настолько неэффективны? И еще не понятно почему (согласно приведенной диаграмме) эти накладные расходы как-то нелинейно зависят от общего потребления.
                            0
                            Данные об эффективности не мои, я просто разместил объяву заглянул в datasheet, и у меня нет причин не доверять данным TI.
                            И еще не понятно почему (согласно приведенной диаграмме) эти накладные расходы как-то нелинейно зависят от общего потребления.

                            А что вас тут удивляет? Чем больше потребляемый ток, тем сложнее поддерживать стабильный уровень выходного напряжения. Ну а работа с малой нагрузкой — вообще отдельный разговор.
                      0
                      deleted

                      Only users with full accounts can post comments. Log in, please.