Science and Informatics University of Žilina, Slovakia. · Тренинг Под...

Министерство образования и науки Украины Национальный аэрокосмический университет

им. Н.Е. Жуковского «ХАИ»

В.В. Скляр, О.Н. Одарущенко, Е.Н. Бульба, Р.А. Горбенко,

А.Ю. Кривцов, А.О. Ивасюк, В.С. Харченко

Энергоэффективность алгоритмов и программ.

Анализ и оптимизация с использованием

GreenCo Controller

Тренинг

Под редакцией В.С. Харченко, В.В. Скляра, О.Н. Одарущенко

Energy Efficiency of Algorithms and Programs.

Analysis and Optimization using GreenCo Controller

Training

Проект

530270-TEMPUS-1-2012-1-UK-TEMPUS-JPCR

Green Computing & Communication

2016

УДК 004.9+681.5ББК 164.9ю31-5 С78

Викладено матеріали тренінг-курсу LLL1 “Methods and Tools for Green Algorithms and Software”, який розроблено в рамках проекту TEMPUS «Green Computing & Communication» (530270-TEMPUS-1-2012-1-UK-TEMPUS-JPCR).

Курс базується на методичних та інструментальних засобах, призначених для оволодіння практичними навичками розроблення енергоефективного програмного забезпечення, вимірю-вання та оптимізації енергоспоживання для алгоритмів і програм, які реалізуються у вбудованих системах на мікроконтролерах. Надано опис лабораторних робіт і тренінгів, які виконуються з використанням програмно-апаратного комплексу GreenCo Controller.

Для інженерів, які займаються розробленням та впровадженням енергоефективних мікро-процесорних систем, а також магістрів і аспірантів університетів, які навчаються за напрямами комп’ютерних наук, комп’ютерної та програмної інженерії, при вивченні методів і засобів зеле-ної ІТ-інженерії.

Рецензенты: Мохор Владимир Владимирович, директор Института проблем моделирования в энергетике им. Г.Е. Пухова Национальной Академии наук Украины, доктор технических наук, профессор;

Levashenko Vitaly, Dr, Professor, Faculty of Management Science and Informatics University of Žilina, Slovakia.

В.В. Скляр, О.Н. Одарущенко, Е.Н. Бульба, Р.А. Горбенко, А.Ю. Кривцов, А.О. Ивасюк, В.С. Харченко

Энергоэффективность алгоритмов и программ. Анализ и оптимиза-ция с использованием GreenCo Controller. Тренинг. / Под ред. Харченко В.С., В.В. Скляра, О.Н. Одарущенко. – Харьков: Национальный аэрокосмический университет имени Н.Е. Жуковского «ХАИ». – 2016. – 95 с.

ISBN 978-617-7361-09-0.

Изложены материалы тренинг-курса LLL1 “Methods and Tools for Green Algorithms and Software”, разработанного в рамках проекта TEMPUS “Green Computing & Communication” (530270-TEMPUS-1-2012-1-UK-TEMPUS-JPCR).

Курс базируется на методических и инструментальных средствах для овладения практическими навыками разработки энергоэффективного программного обеспечения, измерения и оптимизации энергопотребления для алгоритмов и программ, которые реализуются во встроенных системах с использованием микроконтроллеров. В пособии приведено описание лабораторных работ и тренингов, которые выполняются с использованием программно-аппаратного комплекса GreenCo Controller.

Для инженеров, занимающихся разработкой энергоэффективных микропроцессорных систем, магистров и аспирантов университетов, которые учатся по направлениям компьютерных наук, компьютерной и программной инженерии, при изучении методов и средств зеленой ИТ-инженерии. Библ. – 56 наименований, рисунков – 23, таблиц – 7.

Утверждено на заседании Ученого совета Национального аэрокосмического университета имени Н.Е. Жуковского «ХАИ» (протокол № 1 от 2.09.2015).

УДК 004.9+681.5ББК 164.9ю31-5

© В.В. Скляр, О.Н. Одарущенко, Е.Н. Бульба, Р.А. Горбенко, А.Ю. Кривцов, А.О. Ивасюк, В.С. Харченко

ISBN 978-617-7361-09-0© Национальный аэрокосмический университет

имени Н.Е. Жуковского «ХАИ», 2016

Список сокращений

3

СПИСОК СОКРАЩЕНИЙ

МК - микроконтроллер

МП - микропроцессор

ЭПО - энергосберегающее программное обеспечение

ДПФ - дискретное преобразование Фурье

БПФ - быстрое преобразование Фурье

ЦПУ - центральное процессорное устройство

ПО – программное обеспечение

ОС – операционная система

MCU - Micro Controller Unit

HW - Hardware

ISP - In-System Programming

COM - Communication Port - serial port

RAM - Random Access Memory

MCU - Microcontroller Unit (микроконтроллер)

GUI - Graphical User Interface (графический пользовательский

интерфейс).

Введение

4

ВВЕДЕНИЕ

Мотивация. Важной составляющей зеленой ИТ-инженерии

являются технологии создания энергоэффективного программного

обеспечения (ПО), т.е. ПО, при котором минимизируется

энергопотребление встроенных систем, где оно используется.

Действенность методов и средств повышения энергоэффективности

алгоритмов и программ, снижения энергопотребления для

встроенных систем, являются технологии, обеспечивающие решение

трех взаимосвязанных задач:

- измерение и анализ энергопотребления встроенными

решениями в зависимости от вариантов реализуемых алгоритмов и

программных средств;

- разработка программного обеспечения с учетом требований к

энергохарактеристикам систем, протрассированных для ПО;

- оптимизация энергохарактеристик ПО для существующих и

модернизируемых систем.

При этом важно овладеть средствами, способными измерять той

части энергопотребления, которое зависит от прикладного ПО, а

затем убедиться в его возможном уменьшении после

энергооптимизации и, естественно, научиться выполнить ее.

Цель и структура тренинг-курса. В пособии изложены

материалы тренинг-курса LLL1 "Methods and Tools for Green

Algorithms and Software", разработанного для магистрантов,

аспирантов и инженеров в рамках проекта TEMPUS «Green

Computing & Communication» (530270-TEMPUS-1-2012-1-UK-

TEMPUS-JPCR).

В основу практикума положено изучение техник

экспериментального измерения характеристик, разработки и

оптимизации так называемых "зеленых " алгоритмов и программ,

целью которых является создание энергоэффективного ПО. Тренинг-

курс содержит три модуля, которым соответствуют разделы данного

пособия, включающего набор лабораторных работ-практикумов.

В первый раздел включены лабораторные работы, посвященные

изучению программно-аппаратных компонент учебно-лабораторного

исследовательского комплекса "GreenCo Controller" и методов

проведения исследований параметров энергопотребления алгоритмов

и программ с его помощью.

Второй раздел посвящен исследованию характеристик

алгоритмов различной сложности и анализу энергопотребления

Введение

5

программ, которые разработаны на языках программирования

различного уровня на основе этих алгоритмов.

Третий раздел объединяет лабораторные работы, посвященные

анализу влияния уровней оптимизации при компиляции на

энергопотребление программ и исследованию техник оптимизации.

Авторский коллектив. Пособие подготовлено техническим

директором Научно-производственного предприятия (НПП) "Радий",

профессором кафедры компьютерных систем и сетей Национального

аэрокосмического университета им. Н.Е. Жуковского "ХАИ" д.т.н.,

профессором Скляром В.В. (раздел 1), заведующим этой кафедры

д.т.н., профессором Харченко В.С. (введение, раздел 3), ведущим

научным сотрудником НПП "Радий" к.т.н., доцентом Одарущенко

О.Н. (введение и раздел 1), заместителем технического директора

НПП "Радий" к.т.н. Ивасюком А.О. (раздел 1), старшим инженером-

программистом НПП "Радий" Бульбой Е.Н. (раздел 1), инженером-

программистом НПП "Радий" Горбенко Р.А. (раздел 1), ассистентом

кафедры компьютерных систем и сетей ХАИ Кривцовым А.Ю.

(разделы 2 и 3). Разработка программы курса выполнено всеми

авторами. Общее редактирование проведено В. С. Харченко, В.В.

Скляром и О.Н. Одарущенко.

Учебно-лабораторный исследовательский комплекс "GreenCo

Controller" и его действующий образец спроектирован и изготовлен

Ивасюком А.О., Бульбой Е.Н., Горбенко Р.А., Барвинко А.П.

Благодарности. Авторы выражают благодарность рецензентам,

коллегам по проекту, сотрудникам кафедр за ценную информацию,

методическую помощь и конструктивные предложения, которые

высказывались в процессе обсуждения требований к "GreenCo

Controller", программы курса, материалов пособия.

1. Методика проведения измерений с использованием GreenCo Controller

6

1. МЕТОДИКА ПРОВЕДЕНИЯ ИЗМЕРЕНИЙ С

ИСПОЛЬЗОВАНИЕМ GREENCO CONTROLLER

1.1 Тренинг-лабораторная работа №1. Изучение

лабораторного комплекса GreenCo Controller

Цель и задачи лабораторной работы

Целью лабораторной работы является изучение архитектуры,

режимов работы и особенностей использования GreenCo

Controller, применяемого программного обеспечения.

Учебные задачи:

- изучение HW-архитектуры GreenCo Controller;

- изучение применяемого программного обеспечения и

пользовательского интерфейса;

- приобретение первичных навыков работы с лабораторным

комплексом.

Подготовка к лабораторной работе

При подготовке к лабораторной работе необходимо:

уяснить цели и задачи работы;

изучить теоретический материал, приведенный в данном

руководстве, а также в работах [1.1 – 1.3].

Теоретический материал. Современные производители

микроконтроллеров (МК) и микропроцессоров (МП) с каждым

днем стремятся не только повысить производительность своих

чипов, но и снизить их общее энергопотребление. Связано это,

прежде всего с переходом на встраиваемые мультимедийные

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

литиевый аккумулятор или несколько батарей типа ААА.

Неотъемлемыми атрибутами нашего времени стали

мобильные телефоны (смартфоны), планшеты, ноутбуки и прочие

устройства, которые удобно носить и использовать в повседневной

жизни. И конечно же, очень хотелось, чтобы эти устройства имели

как можно больший период работы между регулярными

подзарядками. Как известно, даже самый экономичный смартфон

при максимально эффективном использовании с трудом

выдерживает один рабочий день. Для увеличения рабочего

времени производители идут на всякого рода ухищрения. Самый


7

простой способ продлить жизнь любимому устройству

заключается в увеличении емкости аккумуляторных батарей.

Дальше в ход идут средства по уменьшению

энергопотребления периферией, а именно специальные

малопотребляющие дисплеи, низковольтные микросхемы в

модулях связи и навигации, ну и конечно низковольтные

процессоры. Следующий этап, это специальные режимы работы

процессорных устройств, которые позволяют переводить

устройство в режим ожидания, сна или глубокого сна, с

возможностью быстрого пробуждения, но при этом

энергопотребление снижается с сотен мА до десятков мкА.

Лишь последним в этой цепочке борьбы за энергопотребление

выступает энергосберегающее программное обеспечение (ЭПО).

Существует множество программ, которые помогают сэкономить

ресурсы и без того прожорливого вычислительного ядра любого

микропроцессорного устройства. Такие программы приобрели

популярность со времен ноутбуков и теперь активно используются

мобильными устройствами. К сожалению, всё что они делают, так

это распределяют ресурсы вычислительного устройства так, чтобы

программы с разным уровнем приоритета получали доступ к

ресурсам микропроцессора на определенный период времени,

после чего отправлялись в так званый кэш. Таким образом,

процессорное устройство выполняет в данный момент только

нужные пользователю задачи, все остальные же находятся в

режиме ожидания, при этом, не занимая вычислительные ресурсы

микропроцессора.

Вернемся к микроконтроллерам. Рассмотрим микроконтрол-

леры компании MicroChip. Данная компания выпустила новое

семейство микроконтроллеров PIC24F16KA способных потреблять

ток не больше 9 нА в режиме сна. До этого лидерство держала

компания Texas Instruments с потреблением 100 нА для

разработанных микроконтроллеров MSP430F2x. Что означает 9 нА

в режиме сна? Компания MicroChip подсчитала, что такой

микроконтроллер, питаясь от стандартной батареи CR2032, может

проработать до 30 лет. Другими словами, данный

микроконтроллер может провести в режиме ожидания отклика от

управляемого устройства до 30 лет (рис. 1).


8

Рис. 1. Время работы МК при использовании приложением 1% и

0,1% ресурса батареи

Другой стороной энергопотребления, точнее другой

характеристикой, с которой она связана, является

производительность. Чем ниже напряжение питания МК, тем

меньше операций в секунду он выполняет. Другими словами, МК

не могут работать на высоких частотах при низком потреблении

энергии. И снова возникает проблема, ведь добившись понижения

питания, мы теряем производительность, что ставит под сомнение

саму цель энергосбережения. Компании Microchip удалось

сохранить производительность при пониженном питании (рис 2).

Рассмотренной тенденции следуют другие производители

электронных устройств разной степени интеграции.

Следовательно, возникает ряд вопросов.

1. Может ли процессорное устройство эффективно выполнять

поставленные задачи при разных режимах потребления

(зависимость напряжения от тактовой частоты)?

2. Насколько изменяется потребляемый ток при разных

режимах работы МК (зависимость тока от времени выполнения

алгоритма)?


9

3. Какое количество потребляемой МК энергии рассеивается в

виде тепла (зависимость температуры, как от частоты, так и от

напряжения)?

4. Как зависит потребление энергии МК от реализованной

одной и той же задачи, но разными способами?

5. Существует ли такой “зеленый” алгоритм, который сможет,

одинаково эффективно выполнятся и при пониженном

напряжении и при пониженной частоте?

6. Можно ли любой алгоритм превратить в “зеленый”?

7. Влияет ли архитектура МК CISC, RISC, ARM на

потребление электроэнергии кристаллом?

8. Насколько может меняться энергопотребление в случае

реализации одного алгоритма различными программными

версиями?

Рис. 2. Зависимость тактовой частоты от питания МК

Для ответов на эти вопросы и была предложена концепция

разработки MCU-based GreenCo Controller и цикла лабораторных

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

на часть из заданных вопросов.


10

HW - архитектура GreenCo Controller

В соответствии с описанной выше концепцией была

разработана плата (GreenCo Board) как дополнение к

существующим отладочным платам. В качестве устройства

контроля энергопотребления микропроцессора была выбрана

отладочная плата Arduino UNO R3.

На рис. 3 Ошибка! Источник ссылки не

найден.представлена структурная схема разработанного

устройства. В таблице 1 приведен перечень основных узлов (units)

контроллера и их назначение.

Таблица 1. Основные узлы GreenCo Controller

№ п/п Название узла (unit) Назначение узла (unit)

1. Tested MCU Микроконтроллер dsPIC30F3011-30I/PT/

Microchip ‒ является базовым узлом,

предназначен для исследования характеристик

его энергопотребления для различных

алгоритмов и программ

2. Arduino Controller Отладочная плата Arduino UNO R3,

предназначена для организации интерфейсных

связей между MCU-based GreenCo Controller и

интерфейсом пользователя ПК

3. Clock Unit 32 MHz Узел предназначен для формирования тактовой

частоты работы микроконтроллера в диапазоне

1-32 MHz

4. Current Measurement

Unit

Узел предназначен для контроля (измерения)

потребляемого тока

5. Temperature Sensor Узел предназначен для измерения температуры

микропроцессора в различных режимах работы

6. Adjustable Power

Supply

Регулируемый внутренний источник питания

7. External Power

Supply Unit

Узел предназначен для питания целевого

устройства в широком диапазоне напряжений.


11

Ри

с. 3

. С

тру

кту

рн

ая с

хем

а G

reen

Co C

ontr

oll

er


12

Разработанный и изготовленный GreenCo Board изображен на

рис.4а, отладочная плата Arduino UNO R3 представлена на рис. 4б,

а) б)

в)

Рис. 4. Архитектура GreenCo Controller: а) GreenCo Board, б)

отладочная плата Arduino UNO, в) GreenCo Controller в сборе.

Применяемые программно-аппаратные инструменты

Набор инструментов разработки включает в себя следующие

основные программно-аппаратные элементы:

1. Персональный компьютер (ПК) с установленной Java virtual

machine (JWM)

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-

downloads-2133151.html

http://www.oracle.com/technetwork/java/javase/downloads/jre8-

downloads-2133155.html

2. Интегрированная среда разработки Arduino Integrated

Development Environment (IDE).

http://www.arduino.cc/en/Main/Software

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html

http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html

http://www.arduino.cc/en/Main/Software


13

3. Интегрированная среда программирования MPLAB

Integrated Programming Environment (IPE). Для более расширенных

возможностей работы с микроконтроллером необходима

интегрированная среда разработки MPLAB X IDE.

Скачать данную среду можно с сайта официального

разработчика http://www.microchip.com/mplab/mplab-x-ide.

4. Интерфейсная программа GreenCo Controller GUI.

Скриншот программы представлен на рис.18.

5. Отладочная плата Arduino Uno R3 (под управлением

микроконтроллера ATmega328) рис.4б.

6. Плата расширения GreenCo Board (GreenCo Board рис.4а).

7. Внутрисхемный программатор-отладчик PICkit 3.

Рекомендация. Перед началом работы с целевым устройством

целесообразно установить на ПК программное обеспечение из

приведенного выше перечня.

Программное обеспечение

Дадим краткую характеристику программного обеспечения

необходимого для работы.

Интегрированная среда разработки Arduino IDE

Интегрированная среда разработки Arduino IDE создана для

платформы Arduino и ориентированная на непрофессиональных

пользователей. В Arduino IDE имеется текстовый редактор,

менеджер проектов, препроцессор, компилятор и инструменты для

загрузки программ в устройства, которые совместимы с

платформой. Полностью открытая архитектура системы позволяет

свободно копировать или дополнять линейку продукции Arduino.

Для плат Arduino не требуется отдельный программатор, так

как загрузка программы происходит через встроенный загрузчик.

Также имеется возможность не использовать загрузчик, а

запрограммировать плату через выводы ICSP (внутрисхемное

программирование) сторонним программатором. Загрузчик платы

и сама плата Arduino UNO работает по интерфейсу USB через

виртуальный COM порт и не требует дополнительной настройки,

так как настройка происходит автоматически при установке

Arduino IDE. В процессе загрузки программы от Arduino IDE к

Arduino UNO участвует множество компонентов. Если хотя бы

один из них работает некорректно ‒ процесс программирования

http://www.microchip.com/mplab/mplab-x-ide


14

будет прерван. В частности, процесс загрузки программы зависит

от: драйверов Arduino UNO, выбора модели устройства и порта в

среде разработки Arduino IDE, физического подключения к плате,

прошивке микроконтроллера загрузчика, настроек главного

микроконтроллера платы Arduino (установка фьюз-битов и т.д.).

Если указанный ниже процесс загрузки завершится ошибкой,

воспользуйтесь рекомендациями для устранения возникших

ошибок с ресурса http://arduino.ua/ru/guide/Troubleshooting#toc1.

Для использования платы впервые необходимо загрузить в

Arduino UNO скомпилированную заранее программу обработки и

передачи данных в графический интерфейс GreenCo Controller

GUI. Для этого необходимо:

1. Подключить Arduino UNO к USB, запустить оболочку

Arduino IDE.

2. Убедится, что в меню Tools > Board выбрана ваша модель

Arduino UNO (рис. 5).

Рис. 5. Выбор платы Arduino UNO

3. Проверить, что в меню Tools > Serial Port выбран

правильный СОМ порт (рис. 6).

http://arduino.ua/ru/guide/Troubleshooting#toc1


15

Рис. 6. Выбор порта для подключения Arduino UNO

4. Через меню File > Open выбрать для загрузки файл

GreenCoArduinoUNO.ino (расположен в директории

\GreenController\Software\Arduino\GreenCoArduinoUNO\) (рис. 7).


16

Рис. 7. Выбор файла GreenCoArduinoUNO.ino для первой загрузки

5. Скомпилировать и загрузить проект выполнив команду

Upload c панели Arduino IDE или через меню Sketch > Upload. При

успешном завершении загрузки и отсутствии ошибок, в поле

компилятора отобразится сообщение Done Uploading с

информацией по загрузке (например, Sketch uses 9,418 bytes (29%)

of program storage space. Maximum is 32,256 bytes. Global variables

use 303 bytes (14%) of dynamic memory, leaving 1,745 bytes for local

variables. Maximum is 2,048 bytes.) (рис. 8).


17

Рис. 8. Успешное завершение загрузки файла в Arduino UNO

6. При успешном завершении загрузки оболочку Arduino

IDE можно закрыть. Плату Arduino UNO оставить подключенную

к USB порту ПК.

Интегрированная среда программирования MPLAB IPE

Интегрированная среда программирования MPLAB IPE это

программное приложение с простым интерфейсом для быстрого

доступа к основным функциям программирования

микроконтроллеров. Возможность программирования в IPE

практически всех микроконтроллеров обеспечена использованием

общей с IDE базой данных устройств отладчика MDB (Microchip

Debugger), аппаратных интерфейсов и соответствующих

драйверов.

Чтобы установить IPE, необходимо отметить

соответствующий пункт в диалоговом окне при установке ПО

MPLAB Х (рис. 9). При этом устанавливать IDE для

использования IPE не обязательно, но рекомендовано для

расширения возможностей PICkit 3 и выполнения внутрисхемной

отладки.


18

Рис. 9. Диалоговое окно установки ПО MPLAB Х

После установки, доступ к приложению IPE возможен из

меню системы или по ярлыку на рабочем столе. При этом, для

обеспечения правильной работы, приложение необходимо

запускать с правами администратора операционной системы.

Работа IPE возможна в двух режимах:

1. Production Mode режим, в котором выполняются операции

программирования. По умолчанию приложение запускается в

данном режиме, а его возможности задаются через меню в режиме

Advanced mode.

2. Advanced Mode расширенный режим, в котором возможен

просмотр и изменение установок для операций программирования.

Для активизации режима необходимо запустить приложение IPE и

перейти в меню Settings, где выбрать пункт Advanced Mode. В

появившемся диалоговом окне Advanced Settings в поле Password

ввести пароль, а затем нажать на кнопку Log on. Пароль

чувствителен к регистру и по умолчанию установлена фраза

microchip. В диалоговом окне предусмотрена возможность смены

пароля кнопкой Change Password, а также запоминание введенной


19

парольной фразы для следующих запусков приложения отметив

поле Remember Password (рис. 10).

Рис. 10. Диалоговое окно авторизации для активизации

расширенного режима

После запуска IPE для программирования устройства

необходимо выполнить следующие шаги:

1. Из выпадающего меню Family выбрать соответствующее

семейство устройств, а в меню Device само устройство. Или

сразу использовать выпадающее меню Device для прямого выбора

устройства. Выберем семейство 16-bit DSCs (dsPIC30), а затем

устройство dsPIC30F3011.

2. Нажимаем кнопку Apply, чтобы настроить IPE для

текущего устройства (рис. 11).


20

Рис. 11. Выбор целевого устройства

3. Подключить используемый внутрисхемный программатор-

отладчик PICkit 3 к ПК (описание приведено ниже). К разъему для

подключения программируемого устройства подключите

устройство (см. рис.19,20). Питание для целевого устройства

может быть внешним, или при выборе поступать с программатора.

4. В выпадающем меню Tool отобразится подключенный

инструмент разработки. Если к ПК подключено более одного

инструмента разработки, выберите тот, который будет

использоваться.

5. Нажмите кнопку Connect (рядом с названием инструмента

разработки), чтобы установить связь между IPE и инструментом

разработки (рис. 12). При этом отображается дополнительное окно

с предупреждением о правильном выборе питания для целевого

устройства (рис. 13). Нажмите ОК если установки питания

корректны.


21

Рис. 12. Выбор инструмента разработки и его подключение к IPE

Рис. 13. Окно предупреждения о выборе питания для целевого

устройства

6. Когда инструмент разработки подключен, любые

сообщения или ошибки, связанные с этим инструментом будет

отображаться в окне Output. Показать или скрыть дополнительную

информацию можно нажав на кнопку More или Less

соответственно (рис. 14). Обратитесь к онлайн-помощи для

получения дополнительных инструкций и информации о

возможно возникших проблемах при подключении к целевой

плате.


22

7. После успешного подключения инструмента разработки,

возможно дальнейшее программирование целевого устройства.

Для этого необходимо разъем для подключения

программируемого устройства 3 программатора PICkit 3 (см.

рис. 16) соединить согласно маркеру c разъемом для подключения

программируемого устройства GreenCo Board. При успешном

подключении и отсутствии ошибок, отобразится сообщение,

например, Target device dsPIC30F3011 found. Device ID Revision =

1002 (рис. 14).

Рис. 14. IPE и подключенный инструмент разработчика PICkit 3

В расширенном режиме Advanced Mode доступны

дополнительные настройки, при этом в окне приложения IPE

отображается дополнительное меню (рис. 15).

Меню Operate основное окно, где выполняются операции

программирования целевого устройства.


23

Меню Power активно только при подключенном инструменте

разработчика. Для подачи питания на целевое устройство от

инструмента разработчика, необходимо в опции Voltage Settings

для раскрывающегося меню VDD установить требуемое значение

напряжения и отметить поле Power Target Circuit from Tool для

ICSP Options. Установленное напряжение VDD не должно

превышать максимально допустимое значения для целевого

устройства. Для микроконтроллера dsPIC30F3011 это значение

равно 5 В. Из-за поддержки большого количества

микроконтроллеров, часть из которых не допускают подачи

напряжения питания более 3,3 В, уровень напряжения и подачу

питания необходимо устанавливать при каждом запуске

приложения IPE.

Рис. 15. Диалоговое окно IPE в режиме Advanced Mode


24

Внутрисхемный программатор-отладчик PICkit™ 3

PICkit 3 это внутрисхемный программатор-отладчик,

поддерживающий внутрисхемную отладку и программирование

микроконтроллеров и цифровых сигнальных контроллеров

компании Microchip Technology Inc.

PICkit 3 позволяет:

выполнять отладку приложений на ПК в режиме реального

времени;

выполнять отладку с аппаратными точками останова

программы;

контролировать состояние внутренних регистров,

устанавливать точки останова на основе внутренних событий

целевого устройства;

программирование целевого устройства.

Внешний вид PICkit3, а также назначение элементов

изображено на рис. 16.

PICkit 3 подключается к ПК через интерфейс USB 2.0 и не

требует дополнительного источника питания. Подача питания для

отлаживаемого устройства от PICkit 3 возможна с установкой

напряжения питания в диапазоне от 2,5 до 5,5 В с шагом 0,125 В.

Если же питание от USB порта ПК не может обеспечить

требуемый ток потребления (не менее 100 мА), используйте

внешний источник питания для отлаживаемого устройства

(микроконтроллера).

Маркер первого контакта разъема программатора необходим

для правильного выравнивания соединителя при подключении

отлаживаемого устройства.


25

Рис. 16. Внутрисхемный программатор-отладчик PICkit 3.

Обозначения на рисунке следующие: 1 ‒ разъем для подключения

USB кабеля; 2 ‒ маркер первого контакта разъема программатора;

3 ‒ разъем для подключения программируемого устройства; 4 ‒

индикаторы состояния; 5 ‒ функциональная кнопка.

Разъем для подключения программируемого устройства имеет

6 выводов. Назначение выводов указано на рис. 17. Функции

выводов программирующего разъема отличаются при

программировании различных микросхем памяти EEPROM. Для

получения подробной информации по подключению конкретной

микросхемы необходимо обратиться к файлу справки PICkit 3 или

самого программируемого устройства.


26

Рис. 17. Разъем для подключения программируемого устройства.

Назначение выводов следующее: 1 ‒ MCLR / VPP – напряжение

программирования, сигнал сброса; 2 ‒ VDD – напряжение питания

целевого устройства; 3 ‒ VSS – общий вывод; 4 ‒ PGD (ICSPDAT) –

сигнал данных; 5 ‒ PGC (ICSPCLK) – сигнал тактирования; 6 ‒

PGM (LVP) – зарезервирован для низковольтного программирования

Индикаторы состояния отображают статус устройства и несут

следующею информацию:

1. Power (зеленый) подача питания на PICkit 3 через USB

порт ПК.

2. Active (синий) отображает подключение PICkit 3 через

USB порт к ПК с установленным соединением.

3. Status:

Busy (желтый) показывает, что PICkit 3 занят и выполняет

определенную функцию (программирование, проверка и т.п.);

Error (красный) произошла ошибка.

Функциональная кнопка используется для работы в режиме

«Programmer-To-Go». Режим «Programmer-To-Go» позволяет,

записав в память PICkit 3 отлаженную программу прошивки

микроконтроллера (до 512 кбайт), программировать целевое

устройство нажатием одной кнопки, без использования ПК. При

этом необходимо подать питание по USB mini B для PICkit 3 от

автономного источника питания.


27

Описание графического интерфейса пользователя

GreenCo Controller

На рис. 18 представлен интерфейс пользователя для

проведения измерений параметров энергопотребления и

документирования результатов. Он включает шкалы для вывода

измеренных значений тока и напряжения, окна для демонстрации

измеренных и вычисленных средних значений напряжения, тока,

потребляемой мощности, средней температуры нагрева

микроконтроллера, а также измеренного времени работы

исследуемого объекта (прошитой программы). Частью

функционала GUI, есть автоматическая запись результатов

измерений в файлы с расширением *.xlsx. Запись ведется в

проектную папку logs.

Рис. 18. Графический интерфейс

пользователя GreenCo Controller GUI


28

Таким образом, выше были описаны функции, настройка

программно-аппаратных компонент лабораторного комплекса.

Схема их взаимодействия приведена на рис. 19.

ICSP USB

AD

C, I/O

USB

Integrated Development Environment

( MPLAB X)

In-Circuit Debugger/Programmer

(PICkit 3 )

к

персональному компьютеру

Рис. 19. Схема взаимодействия программно-аппаратных

компонент лабораторного комплекса

Рис. 20. Соединение программатора и целевого устройства


29

Рис. 21. Лабораторный комплекс в сборе в режиме проведения

измерений

Программа исследований

1. Установить на ПК требуемое программное обеспечение,

выполнить сборку и настройку учебно-лабораторного комплекса в

соответствии с описанием приведенным выше.

2. Выполнить прошивку алгоритма из библиотеки

Для загрузки файла прошивки в MPLAB IPE необходимо в

поле Source указать путь и сам файл прошивки, например,

dsPIC30F3011_FFT_.2sBL64_TFC_fr_7.37MHz (FRC)_2000d.hex из

директории \Green Controller\labs\. После успешной загрузки

файла, его необходимо загрузить в микроконтроллер используя

кнопку Program или нажав сочетание клавиш Alt + F5. В

результате успешной загрузки будет выдано подтверждающее

сообщение с указанием времени завершения операции 2016-03-

11T16:05:00+0200- Programming complete и увеличен счетчик

успешных загрузок Pass Count: 2 (рис. 22).


30

Рис. 22. Загрузка hex файла

Контрольные вопросы

1. Назовите основные програмно-аппаратные компоненты

учебно-лабораторного комплекса.

2. Опишите порядок сборки и настройки учебно-

лабораторного комплекса.

3. Опишите порядок прошивки программы в

микроконтроллер.


31

1.2 Тренинг-лабораторная работа №2. Измерение

энергопотребления для алгоритма быстрого преобразования

Фурье

Цель и задачи лабораторной работы

Целью лабораторной работы является изучение

энергопотребления алгоритма быстрого преобразования Фурье на

различных частотах работы GreenCo Board.


анализ количественных результатов исследования и

зависимости показателей энергопотребления реализованных

алгоритмов от установленных параметров работы

микроконтроллера;

проведение выбора наилучшей программной реализации

алгоритма при существующих ограничениях.

Подготовка к лабораторной работе

При подготовке к лабораторной работе необходимо:

ознакомится с целями и задачами исследования;

изучить теоретический материал, приведенный в описании.

Теоретический материал

Преобразование Фурье наиболее распространенная операция

при обработке сигналов. При применении вычислений в цифровой

форме, дискретное преобразование Фурье (ДПФ), используется

для описания, представления и анализа дискретных сигналов.

Однако, прямое выполнение ДПФ требует большого объема

вычислений, что обусловило разработку более скоростных

алгоритмов. Они основываются на сокращении требуемого числа

операций и получили название быстрого преобразования Фурье

(БПФ). К самым простым и наиболее используемым алгоритмам

БПФ можно отнести алгоритм, разработанный в вычислительном

центре IBM Джоном Кули под руководством Джона Тьюки.

Рассмотрим ДПФ и продемонстрируем суть БПФ. ДПФ

трансформирует последовательность комплексных (либо

вещественных) чисел xn в последовательность комплексных чисел


32

Xn. Прямое (1) и обратное (2) преобразования Фурье определяются

как

и

(

(1)

(

(2)

где , .

Приведенные выше формулы имеют сложность Θ(N2), однако

существует способ снижения сложность ДПФ. Так, алгоритм БПФ

сокращает число операций по сравнению с алгоритмами ДПФ до

Θ(N·log(N)). При очень больших массивах отсчетов входного

сигнала выигрыш в скорости обработки может достигать

нескольких тысяч.

Основная идея БПФ заключается в разделении вектора

(дискретизированного сигнала) на части (первая содержит

слагаемые с четными индексами, вторая с нечетными) согласно

формуле (3) и последующем слиянием результатов их обработки.

Для реализации алгоритма применяются только векторы длины N,

являющиеся степенями 2.

((3)

По равенству (3) вычисляют k-й коэффициент ДПФ вектора

длинны N через два преобразования длины N/2, одно из которых

применяется к четному вектору x2n, а другое, к нечетному x2n+1.

Далее рассмотрим два случая.

При 0 ≤ k < N/2 положим k = j запишем (3) в виде


33

(

(4)

При N/2 ≤ k < N полагаем k = j + N/2. Подставляя в (3),

получим

((5)

Упростим (5) учитывая свойства корня из единицы

до

(

(6)

Полученные формулы дают возможность вычислять

преобразование длины N путем комбинации двух преобразований

длины N/2, при этом левая часть вектора вычисляется по формуле

(4), а правая – по формуле (5), j = 0, 1, ..., N/2-1. Таким образом,

операция объединения двух ДПФ в одно занимает Θ(N) времени.

Общая схема алгоритма состоит в повторяющемся сведении

ДПФ вектора длины N к векторам длины N/2 и объединении

результатов, и имеет сложность (Θ(N·log(N)).

АЛГОРИТМ БПФ (x, N) {

1. Если длина вектора равна 1, вернуть x.

2. Разбить вектор на четную часть и

нечетную .


34

3. Рекурсивно вызвать БПФ на каждой из частей

и .

4. Объединение результатов по формулам (5) и (6).

a. (инициализация) Присвоить N значение главного

комплексного корня N-й степени из единицы

.

b. (инициализация) Присвоить N = 1.

c. Одновременно в цикле для шагов от i = 0 до i < N/2,

вычислить и ,

каждый шаг i переходя к следующей степени корня

.

5. Вернуть вектор X.}


1. Выполнить настройку учебно-лабораторного комплекса.

2. Выполнить прошивку алгоритма из библиотеки.

Для загрузки файла прошивки в бреде MPLAB IPE в поле

Source указать путь и сам файл

прошивки,dsPIC30F3011_FFT_.2sBL64_TFC_fr_512kHz

(FRC)_2000d.hex из директории \Green Controller\labs\.

3. Используя графический интерфейс пользователя GreenCo

Controller GUI провести измерение энергетических параметров

работы микроконтроллера на рабочей частоте 512 kHz (тока -I,

напряжения-U, потребляемой мощности-P, средней температуры

нагрева микроконтроллера). Снять показания времени работы

алгоритма. Убедиться, что файл с результатами измерений создан.

4. Выполнить задания п.2 и п.3, используя прошивки

алгоритма БПФ на частотах работы микроконтроллера 7.37MHz и

32MHz. Используйте фалы прошивок:

-dsPIC30F3011_FFT_.2sBL64_TFC_fr_7.37MHz

(FRC)_2000d.hex;


35

-dsPIC30F3011_FFT_.2sBL64_TFC_fr_32MHz

(FRC)_2000d.hex.

5. Используя данные файлов с результатами измерений

построить графические зависимости: F(U), F(I), F(P), I(t), U(t).

6. Сформулировать выводы о характере изменения значений

электрических параметров работы микроконтроллера при

изменении значений рабочей частоты.

7. Сравнить измеренные значения времени работы алгоритма

и температуры микроконтроллера в зависимости от значения

рабочей частоты. Сформулировать выводы.

6. Оформить отчет о лабораторной работе

Контрольные вопросы

1. В чем заключается преимущество быстрого преобразования

Фурье?

2. Опишите функциональную зависимость потребляемой

мощности от значения рабочей частоты микроконтроллера.

3. Как изменяется время работы алгоритма на различных

рабочих частотах?

2. Исследование энергоэффективности алгоритмов и программ

с использованием GreenCo Controller

36

2. ИССЛЕДОВАНИЕ ЭНЕРГОЭФФЕКТИВНОСТИ

АЛГОРИТМОВ И ПРОГРАММ С ИСПОЛЬЗОВАНИЕМ

GREENCO CONTROLLER

2.1 Тренинг-лабораторная работа №3. Исследование

энергопотребления при реализации алгоритмов различной

сложности

Цель и задачи лабораторной работы.

Целью лабораторной работы является выработка навыков

получения и анализа энергопотребления алгоритмов различной

сложности с использованием GreenCo Controller.


- изучение факторов, влияющих на энергопотребление

алгоритма;

- изучение способов численной оценки этих факторов на

основании метрик энергопотребления.

Практические задачи:

- получение навыков анализа алгоритмов для применения

метрик энергоэффективности;

- интерпретация и практическое применение метрик

энергоэффективности для выбора из нескольких вариантов

оптимального по сложности алгоритма.

Подготовка к лабораторной работе:

При подготовке к практическому занятию необходимо:

- уяснить цели и задачи занятия;

- изучить теоретический материал, приведенный в данном

руководстве, а также в приведенных литературных источниках;

- подготовить различные программные коды, реализующие

алгоритмы различной сложности. Эти коды в процессе

выполнения работы будут сравниваться по степени оптимальности

энергопотребления.



37


Большое количество метрик для внутренних параметров

программных продуктов, такие, как размер программы, сложность,

функциональность, структурированность, модульность, были в

свое время разработаны и активно применялись и применяются к

программным продуктам [3.5]. Потребление энергии программой

зависит от ее динамического поведения, и от аппаратной

платформы, на которой программа выполняется, поэтому

необходимо расширить существующую программную модель

граф-схемы для однозначного определения параметров времени

исполнения ПО. Поскольку основные источники потребления

энергии в компьютерных системах это процессорные операции и

операции доступа к оперативной памяти, нужно разработать меры

для динамических характеристик этих операций.

Исследования в направлении создания энергоэффективного

ПО были начаты с разработки энергетических моделей уровня

набора инструкций, которые оценивали потребление

электроэнергии процессором [3.6, 3.7]. Эти модели могут быть

применены к исследуемой программе как после ее выполнения,

чтобы получить трассировку выполненных инструкций, или

применив методы статического анализа на уровне исходного кода

для оценки количества выполняемых инструкций [3.8].

Основываясь на измерениях, которые показывали, что

межинструкционные (переход от одной инструкции к другой)

затраты энергии отличаются для разных пар инструкций [3.6],

были предложены несколько методик для оптимизации расхода

энергии, которые использовали алгоритмы диспетчеризации

(определение последовательности выполнения инструкций, или

программ) для минимизации расходов энергии [3.7]. Для оценки

комплексного воздействия программной и аппаратной

оптимизации на энергоэффективность были использованы модели

уровня инструкций с высокой точностью циклов (работа

процессора моделировалась вплоть до каждого его цикла работы)

[3.4, 3.9]. Другая литература, касающаяся проектирования

энергоэффективного ПО, описывает методологии связанные с

потреблением энергии оперативной памятью. В них предлагается

преобразование программного кода таким образом, чтобы



38

организовать работу с меньшими участками памяти и с меньшими

энергозатратами за каждую операцию доступа к памяти [3.10]. Тем

не менее, несмотря на все предыдущие работы, потребление

энергии конкретной программой всегда оценивалось, используя

специфическую целевую архитектуру. При этом не были сделаны

попытки определить энергетические метрики, которые могли бы

использоваться для сравнения дизайна ПО, независимо от

нижележащего аппаратного обеспечения. Более того, вопросы

проектирования энергоэффективного ПО не рассматривались в

привязке к потреблению энергии в результате совместной работы

процессора и оперативной памяти. Так же не было исследований

влияния различных вариантов программного кода на потребление

энергии. Следует отметить, что существующие методы

используют трассировку инструкций исследуемых программ, и

промежуток времени, требуемый для данного процесса для

больших приложений, становится непомерно длинным. Перенос

расчетов для оптимального соотношения потребляемой энергии и

производительности на более высокие уровни абстракции

становится неизбежным, особенно когда большие объемы работ по

проектированию ПО должны быть выполнены за короткий

промежуток времени [3.2, 3.4].

Цель данной работы заключается в определении зависимости

энергопотребления алгоритма от его сложности. Учитывая цель, в

работе необходимо рассмотреть меры энергоэффективности,

которые можно использовать для оценки потребления энергии

программой, а также определить сложность алгоритмов.

Зависимость необходимо протестировать на различных

реализациях алгоритмов, которые будут экспериментально

оценены по производительности и потреблению энергии,

используя GreenCO Controller с применением предложенных

параметров. Потребление энергии микроконтроллером происходит

из-за функционирования его электрических схем во время

выполнения программных инструкций. Декодирование и

выполнение инструкций производится за счет коммутирующих

действий в узлах цифровой схемы микроконтроллера, которые

представляют собой зарядку и разрядку емкостей этих узлов, что

приводит к динамическому рассеиванию энергии [3.1]. Для



39

измерения данной составляющей расхода энергии существуют

модели потребления энергии уровня инструкций. Эти модели

основаны на предположении [3.6], что можно, измеряя

электрический ток процессора во время выполнения им

определенного набора инструкций, получить большую часть

информации, требуемую для оценки потребления энергии

программой, выполняемой на этом микроконтроллере.

Существует две основных составляющих модели потребления

энергии уровня инструкций. Базовые расходы энергии

представляют собой расходы, которые связаны с базовой

обработкой, необходимой для выполнения инструкции. Расход

оценивается как среднее значение тока, потраченное на

выполнение одного цикла микроконтроллера обработки

нескольких экземпляров одной и той же инструкции.

Накладные расходы энергии получаются из-за

коммутирующих действий в схеме микроконтроллера и из-за

косвенных дополнительных расходов энергии, вытекающих из

выполнения смежных инструкций (пересчет индексов циклов и

вычисление адресов памяти). Для измерения среднего значения

тока в данном случае используются последовательности

специализированных инструкций. Таким образом, общее

потребление электроэнергии программой, выполняемой на

процессоре, может быть получено как сумма всех базовых и

накладных расходов энергии за время выполнения программы.

Расходы энергии на память связаны с операциями доступа к

инструкциям, или к данным. Расход энергии за операцию доступа

зависит от объема памяти. Следовательно, для больших модулей

памяти, находящихся вне микроконтроллера, энергопотребление

значительно выше, чем для памяти небольшого размера,

встроенной в микроконтроллер. Эта составляющая потребления

энергии так же зависит от самого выполняемого ПО.

Энергопотребление памяти, используемой для хранения

инструкций, зависит от размера программного кода, который

определяет объем используемой памяти, и количества

выполняемых инструкций, которые определяют количество

операций выборки из памяти. Энергопотребление памяти,

используемой для хранения данных, зависит от объема



40

обрабатываемых приложением данных, и от того, насколько

интенсивно приложение работает с данными, то есть насколько

часто оно получает доступ к данным. Согласно типичной модели

потребления энергии энергия расходуется на операции доступа к

памяти, и ее расход прямо пропорционален количеству операций

доступа, размеру и количеству портов ввода-вывода памяти,

напряжения питания, и технологии производства. Согласно

вышесказанному, количество выполняемых инструкций имеет

двукратное воздействие на энергопотребление – посредством

выполнения инструкций с помощью процессора, и извлечения

инструкций из памяти. С другой стороны, вклад операций доступа

к памяти в энергопотребление рассматривается однократно, как

сам по себе. Создание энергетических мер основывается на том,

что поток команд каждой программы можно представить с

помощью ориентированного графа, который называется

потоковым графом программы [3.5]. Базовые S-графы, которые

используются для определения семейства допустимых S-

структурированных графов, к которым принадлежит потоковый

граф любой произвольной программы, показаны на рис. 23.

Рис. 23. Базовые S-графы

Таким образом, мы видим, что энергопотребление будет

меняться в зависимости от выбранного алгоритма.



41

Алгоритм – это точное предписание, однозначно

определяющее вычислительный процесс, ведущий от варьируемых

начальных данных к искомому результату.

При разработке алгоритмов очень важно иметь возможность

оценить ресурсы, необходимые для проведения вычислений,

результатом оценки является функция сложности (трудоемкости).

Оцениваемым ресурсом чаще всего является процессорное время

(вычислительная сложность), память (сложность алгоритма по

памяти) или энергопотребление. Оценка позволяет предсказать

время выполнения, затраченную энергию и сравнивать

эффективность алгоритмов.

Вычислительная сложность ‒ понятие в информатике и

теории алгоритмов, обозначающее функцию зависимости объёма

работы, которая выполняется некоторым алгоритмом, от размера

входных данных. Раздел, изучающий вычислительную сложность,

называется теорией сложности вычислений. Объём работы обычно

измеряется абстрактными понятиями времени и пространства,

называемыми вычислительными ресурсами. Время определяется

количеством элементарных шагов, необходимых для решения

задачи, тогда как пространство определяется объёмом памяти или

места на носителе данных.

Теория сложности вычислений возникла из потребности

сравнивать быстродействие алгоритмов, чётко описывать их

поведение (время исполнения и объём необходимой памяти) в

зависимости от размера входа.

Количество элементарных операций, затраченных алгоритмом

для решения конкретного экземпляра задачи, зависит не только от

размера входных данных, но и от самих данных. Например,

количество операций алгоритма сортировки вставками

значительно меньше в случае, если входные данные уже

отсортированы. Чтобы избежать подобных трудностей, рассмат-

ривают понятие временной сложности алгоритма в худшем случае.

Временная сложность алгоритма (в худшем случае) ‒ это

функция от размера входных данных, равная максимальному

количеству элементарных операций, проделываемых алгоритмом

для решения экземпляра задачи указанного размера.



42

Аналогично понятию временной сложности в худшем случае

определяется понятие временная сложность алгоритма в

наилучшем случае. Также рассматривают понятие среднее время

работы алгоритма, то есть математическое ожидание времени

работы алгоритма. Иногда говорят просто: «Временная сложность

алгоритма» или «Время работы алгоритма», имея в виду

временную сложность алгоритма в худшем, наилучшем или

среднем случае (в зависимости от контекста).

По аналогии с временной сложностью, определяют

пространственную сложность алгоритма, только здесь говорят не о

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

памяти.

Каждое вычислительное устройство имеет свои особенности,

которые могут влиять на длительность вычисления. Обычно при

разработке алгоритма не берутся во внимание такие детали, как

размер кэша процессора или тип многозадачности, реализуемый

операционной системой. Анализ алгоритмов проводят на модели

абстрактного вычислителя, называемого машиной с произвольным

доступом к памяти (RAM).

Модель состоит из памяти и процессора, которые работают

следующим образом:

- память состоит из ячеек, каждая из которых имеет адрес и

может хранить один элемент данных;

- каждое обращение к памяти занимает одну единицу

времени, независимо от номера адресуемой ячейки;

- количество памяти достаточно для выполнения любого

алгоритма;

- процессор выполняет любую элементарную операцию

(основные логические и арифметические операции, чтение из

памяти, запись в память, вызов подпрограммы и т.п.) за один

временной шаг;

- циклы и функции не считаются элементарными операциями.

Несмотря на то, что такая модель далека от реального

компьютера, она замечательно подходит для анализа алгоритмов.

После того, как алгоритм будет реализован для конкретной ЭВМ,



43

вы можете заняться профилированием и низкоуровневой

оптимизацией, но это будет уже оптимизация кода, а не алгоритма.

Одним из способов оценки трудоемкости (Tn) является

подсчет количества выполняемых операций. Рассмотрим в

качестве примера алгоритм поиска минимального элемента

массива.

начало; поиск минимального элемента массива array из N

элементов

min := array[1]

для i от 2 до N выполнять:

если array[i] < min

min := array[i]

конец; вернуть min

При выполнении этого алгоритма будет выполнена:

1. N – 1 операция присваивания счетчику цикла i нового

значения;

2. N – 1 операция сравнения счетчика со значением N;

3. N – 1 операция сравнения элемента массива со значением

min;

4. от 1 до N операций присваивания значения переменной min.

Точное количество операций будет зависеть от

обрабатываемых данных, поэтому имеет смысл говорить о

наилучшем, наихудшем и среднем случаях. При этом худшему

случаю всегда уделяется особое внимание, в том числе потому, что

“плохие” данные могут быть намеренно поданы на вход

злоумышленником.

Понятие среднего случая используется для оценки поведения

алгоритма с расчетом на то, что наборы данных равновероятны.

Однако, такая оценка достаточно сложна:

1. Исходные данные разбиваются на группы так, что

трудоемкость алгоритма (ti) для любого набора данных одной

группы одинакова;

2. Исходя из доли наборов данных группы в общем числе

наборов, рассчитывается вероятность для каждой группы (pi);



44

3. Оценка среднего случая вычисляется по формуле:

m

iii

tp1

.

Подсчет количества операций позволяет сравнить

эффективность алгоритмов. Однако аналогичный результат можно

получить более простым путем. Анализ проводят с расчетом на

достаточно большой объем обрабатываемых данных (n→∞),

поэтому ключевое значение имеет скорость роста функции

сложности, а не точное количество операций.

При анализе скорости роста игнорируются постоянные

члены и множители в выражении, т.е. функции

fx=10x2+20 и gx=x2

эквивалентны с точки зрения скорости роста. Незначащие

члены лишь добавляют “волнистости”, которая затрудняет анализ.

В оценке алгоритмов используются специальные

асимптотические обозначения, задающие следующие классы

функций:

O(g) – функции, растущие медленнее чем g;

Ω(g) – функции, растущие быстрее чем g;

Θ(g) – функции, растущие с той же скоростью, что и g.

Запись fn=O(gn) означает принадлежность функции f классу

O(g), т.е. функция f ограничена сверху функцией g для достаточно

больших значений аргумента. n0>0, c>0:n>n0, fncgn.

Ограниченность функции g снизу функцией f записывается

следующим образом: gn=Ω(fn). Нотации Ω и O взаимозаменяемы:

fn=O(gn)⇔gn=Ω(fn).

Если функции f и g имеют одинаковую скорость роста

(fn=Θ(gn)), то существуют положительные константы c1 и c2 такие,

что n0>0:n>n0, fnc1gn, fnc1gn. При этом fn=Θ(gn)⇔gn=Θ(fn).

Оценка сложности – способ не только сравнения алгоритмов,

но и прогнозирования времени их работы. Никакие тесты

производительности не дадут такой информации, т.к. зависят от

особенностей конкретного компьютера и обрабатывают

конкретные данные (не обязательно худший случай).

Анализ алгоритмов позволяет определить минимально

возможную трудоемкость, например:



45

- алгоритм поиска элемента в неупорядоченном массиве не

может иметь верхнюю оценку сложности лучше, чем O(n). Это

связано с тем, что невозможно определить отсутствие элемента в

массиве (худший случай) не просмотрев все его элементы;

- возможно формально доказать, что не возможен алгоритм

сортировки произвольного массива, работающий лучше, чем

О(nlogn) [3.5].

Ниже представлены примеры различных алгоритмов с

указанием их сложности.

Хорошо Приемлемо Плохо

Таблица 2. Алгоритмы поиска:

Таблица 3. Сортировка



46

Таблица 4. Структуры данных

Таблица 5. Представление графов

Таблица 6. Нотация асимптотического роста

1. (О ‒ большое) ‒ верхняя граница, в то время как (Омега ‒

большое) ‒ нижняя граница. Тета требует как (О ‒ большое), так и



47

(Омега ‒ большое), поэтому она является точной оценкой (она

должна быть ограничена как сверху, так и снизу). К примеру,

алгоритм требующий Ω (n logn) требует не менее n logn времени,

но верхняя граница не известна. Алгоритм требующий Θ (n logn)

предпочтительнее потому, что он требует не менее n logn (Ω (n

logn)) и не более чем n logn (O(n logn)).

2. f(x)=Θ(g(n)) означает, что f растет так же как и g когда n

стремится к бесконечности. Другими словами, скорость роста f(x)

асимптотически пропорциональна скорости роста g(n).

3. f(x)=O(g(n)). Здесь темпы роста не быстрее, чем g (n). O

большое является наиболее полезной, поскольку представляет

наихудший случай.


В ходе выполнения лабораторной работы необходимо:

1. Выбрать 4 алгоритма различной сложности из перечня,

приведенного в таблицах 2-5. Для каждого из них реализовать

программный код. Описание алгоритмов приведено в [3.10-3.12].

2. Произвести оценку сложности каждого алгоритма методом

подсчета количества выполняемых операций и асимптотически.

3. Произвести оценку энергопотребления программного кода

реализации каждого алгоритма.

4. Составить таблицу, в которую необходимо внести все

полученные показатели для каждого алгоритма.

5. Представить данные в виде диаграмм.

6. Провести сравнительный анализ результатов и получить

зависимость энергопотребления алгоритма от его сложности.

7. Сделать выводы по работе.

Требования к содержанию аналитического отчета

Отчет должен содержать:

Титульный лист;

Цель и программу проведения исследований;



48

Тексты программных кодов выбранных алгоритмов;

Результаты оценки, сведенные в таблицу;

Результаты оценки, представленные графически;

Выводы по работе.

Контрольные вопросы и задания

1. Назовите две основные составляющие модели потребления

энергии уровня инструкций.

2. Что такое потоковый граф программы?

3. Что такое алгоритм?

4. Что такое оцениваемый ресурс алгоритма?

5. Что такое вычислительная сложность алгоритма?

6. Что такое временная сложность алгоритма?

7. Что такое пространственная сложность алгоритма?

8. Как проводят анализ алгоритмов?

9. Что такое метод оценки трудоемкости алгоритма путем

подсчета выполняемых операций?

10. Что такое асимптотические обозначения?

11. Что такое рост функции сложности?

12. Какие вы знаете алгоритмы поиска?

13. Какие вы знаете алгоритмы сортировки?

14. Какие вы знаете структуры данных?

15. Как зависит энергопотребление алгоритма от его

сложности?



49

2.2 Тренинг-лабораторная работа №4. Анализ

энергопотребления при реализации программ на различных

языках программирования


Целью лабораторной работы является выработка навыков

получения и анализа энергопотребления алгоритмов,

реализованных с помощью языков программирования различного

уровня с использованием GreenCo Controller.



алгоритма;

- изучение способов численной оценки этих факторов на

основании метрик энергопотребления.


- получение навыков анализа алгоритмов для применения

метрик энергоэффективности;

- интерпретация и практическое применение метрик

энергоэффективности для выбора из нескольких вариантов

оптимальной по уровню языка программирования реализации.





руководстве, а также в работах;

- подготовить различные программные коды, реализующие

алгоритмы различной сложности на языках программирования

различного уровня. Эти коды в процессе выполнения работы будут

сравниваться по степени оптимальности энергопотребления.


В настоящее время для микроконтроллеров существует

множество языков программирования: от классического



50

BASCOM-AVRBasic[4.1] до Assembler и C. Наиболее

распространёнными являются язык ассемблера и язык C. В этих

языках реализованы практически все возможности

программирования встраиваемых систем на данном типе

микроконтроллеров[4.2]. Рассмотрим общие особенности

программирования на этих языках для существующих

микропроцессорных систем, а также частности программирования

в аппаратной среде микроконтроллеров, как встраиваемых микро-

ЭВМ. В настоящее время в различных публикациях по вопросам

программирования микропроцессорных систем и, в частности,

систем на микроконтроллерах, утверждается приоритет языка

программирования C и приводится ряд преимуществ этого языка

программирования по отношению к языку ассемблера.

Цель данной работы – произвести сравнительный анализ

данных языков программирования, являющихся основными при

программировании микропроцессорных систем. Как известно, все

существующие языки программирования можно разделить на две

основные категории: языки программирования низкого уровня;

языки программирования высокого уровня. К первой группе

относят семейство языков ассемблера, например, Turbo Assembler,

Macro Assembler. Эти средства разработки позволяют получить

наиболее короткий и быстродействующий код. Ко второй группе

относятся упомянутые выше BASCOM-AVRBasic и язык

программирования C. Известно, что язык C, в некотором роде,

занимает промежуточное положение, объединяя возможности

языков высокого уровня с функциональностью языков

ассемблера[4.3], однако, это не совсем так. Основные функции

языков ассемблера имеют основанием низкоуровневый доступ к

компьютеру, определяющий полноценную возможность

управления процессором, что, с одной стороны, позволяет

достигать максимальной скорости реакции программы на действия

пользователя[4.4], а с другой стороны позволяет достичь

определённых преимуществ в размере конечного исполняемого

кода программ[4.2].

У опытных программистов на языках высокого уровня, к

которым всё-таки относится и язык программирования C, часто

возникают возражения по описанным выше вопросам, основанные



51

на том, что некоторые операторы языка C или даже Turbo Pascal

напрямую преобразуются в машинные коды. Также допустимо

утверждать, что такие языки программирования как FORTH

обеспечивают непосредственный низкоуровневый доступ. Но

несмотря на то, что C или иные языки программирования

обеспечивают выполнение некоторых низкоуровневых операций,

эти языки всё равно не могут сравниться с языком ассемблера в

возможностях доступа к процессору [4.4].

Высокоуровневые языки, несмотря на наличие возможности

выполнения низкоуровневых операций, требуют комбинирования

своих функций с функциями языка ассемблера, путём встраивания

ассемблерного кода в код программ, написанных на этих

языках[4.4]. Как уже было отмечено выше, ассемблер – это

низкоуровневый язык программирования, что позволяет достичь

значительного уровня оптимизации уже при непосредственном

написании кода программы. При этом оптимизация достигается

уже при программировании и её уровень контролируется

непосредственно. Фактически, программируя, мы одновременно

оптимизируем программу. При использовании автоматических

компиляторов необходима синтетическая оптимизация. В

настоящее время при программировании на языке C используются

так называемые оптимизирующие компиляторы или оптимизаторы

кода, например, компилятор фирмы Microsoft, упомянутый в

статье [4.5].В таких системах оптимизация программного кода

происходит при компиляции программы, то есть при

преобразовании исходного текста программы в машинный код.

В настоящее время не существует единого мнения по

вопросам доверия оптимизации, выполненной автоматически.

Обоснованием позиции, опирающейся на не совершенство

синтетической оптимизации, может служить тестовый обзор [4.6].

Известно, что оптимизирующие компиляторы разных

производителей имеют значительные различия при работе с

различными комбинациями программного кода и по-разному

переводят его в мнемонику конкретного микроконтроллера. Из

вышесказанного можно заключить, что автоматическая

оптимизация на данном этапе своего развития нуждается в

изменениях и доработках и к её использованию не следует



52

прибегать повсеместно, что делает её малозначительным

преимуществом языков программирования высокого уровня.

В большинстве публикаций, посвящённых языку ассемблера

[4.4], указывается на непереносимость и аппаратную зависимость

программ, написанных на нём, по сравнению с языками высокого

уровня, такими как C. Однако, программы на языке C также могут

быть аппаратно зависимыми и вследствие чего непереносимыми,

особенно, при работе с графическими контроллерами. Некоторые

функции неработоспособны при программировании под

графические контроллеры различных производителей. Таким

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

для прямого взаимодействия с драйверами видеокарт [4.8]. Кроме

того, программы автоматической оптимизации кодов, созданные

для языка C, о которых написано выше, сами являются аппаратно

зависимыми и непереносимыми, например, считающийся одним из

лучших компиляторов Intel C Compiler производит некорректную

оптимизацию программ для процессоров других производителей

[4.9]. Известно утверждение, что программирование на языке

ассемблера затруднено слабой читаемостью программ, что в свою

очередь приводит к большему числу ошибок при

программировании на этом языке, нежели на языке

программирования C [4.2].

В данном случае читаемость программ, как и количество в

них ошибок, занесённых при программировании, зависит в

большей степени от опыта, внимательности и стараний

программиста, а также от того факта, насколько хорошо известен

разработчику тот или иной язык программирования[4.4]. Кроме

того, за якобы лучшей читаемостью программ, написанных на

языке программирования C, скрывается множество

недокументированных возможностей, как отрицательно, так и

положительно влияющих на правильную работу конечного

программного продукта. Язык программирования C – громоздкий

язык. Таким образом, хотя разработка программ на языке C, при

поверхностном взгляде, быстрее программирования на языке

ассемблера, однако программирование на нём требует знания

нюансов, без которых написание корректно работающих программ

невозможно [4.10].



53

Язык ассемблера, в свою очередь, представляет собой набор

простых правил, изучив которые, можно уверенно

программировать на нём, а знание и изучение архитектуры

целевой микропроцессорной системы упрощает процесс

программирования и последующего чтения программ [4.7].

Сегодня большинство программистов убеждены, что одним из

основных преимуществ языка C по отношению к языку ассемблера

является наличие библиотечных программ, например,

подпрограмм вычисления сложных выражений, вида (x* 2 + 8)

[4.4]. Несмотря на удобство программирования с их

использованием, следует признать, что отсутствие встроенных

библиотечных программ, скорее преимущество языка ассемблера,

нежели его недостаток, так как при использовании таких программ

в языках высокого уровня теряется возможность полного

управления ресурсами компьютера и, следовательно, возможность

написания максимально эффективных, быстрых и компактных

программ, кроме того существует большое количество

ассемблерных библиотек, позволяющих выполнять операции,

характерные для языков высокого уровня[4.4], например,

стандартные библиотеки адресации для микроконтроллеров,

позволяют обращаться к регистрам и портам микроконтроллера

аналогично программам на C, в противном случае пришлось бы

вручную изучать адреса регистров и вносить их в управляющие

конструкции [4.11].

В условиях программирования малых микропроцессорных

систем и однокристальных микро-ЭВМ, к которым относятся

микроконтроллеры, а такие технические особенности этих

микроконтроллеров, как развитая регистровая память,

включающая тридцать два регистра общего назначения,

исключают необходимость использования сложных

высокоуровневых языков программирования, хотя и допускают её

[4.11]. Как можно заключить из вышеописанного, преимущества

языка программирования C достаточно спорны. В настоящее

время он обладает одним принципиальным преимуществом, а

именно знакомство с ним большинства программистов, которые

программировали на нём изначально для персональных

компьютеров с процессорами архитектуры x86. Таким образом,



54

если большинство программистов по каким-то причинам не

пожелали использовать или изучить язык ассемблера, язык

программирования C подходит для использования в случаях, когда

группа программистов работает над программным кодом для

одной задачи. Для написания же эффективных,

быстродействующих и компактных программ язык ассемблера

предпочтительнее языка C.

Язык ассемблера – необычный компьютерный язык.

Преимуществами языка ассемблера является, низкоуровневый

доступ к процессору, достижение максимальной скорости за счёт

возможности полностью управлять процессом вычисления,

компактность и скорость программ [4.4]. Программам на языке

ассемблера присуща точность исполнения заложенного алгоритма

в отсутствии описанных выше нюансов, основанных на

своеобразном «языковом барьере» между высокоуровневым

языком программирования и реальным вычислительным

процессом, так как программы на языках высокого уровня

преобразуются в машинные коды опосредованно посредствам

промежуточного языка, ассемблерные мнемонические операторы

имеют прямое соответствие «код-машинная операция» [4.3, 4.4,

4.13, 4.14]. Как уже отмечалось выше, язык ассемблера

чрезвычайно эффективен в условиях систем на

микроконтроллерах, также большинство программ для

микроконтроллерных систем сохранили условности характерные

для традиционных технологий программирования, при которых

имеется ограничение на используемые вычислительные ресурсы и

от программ требуется прежде всего эффективность и

компактность [4.15]. При таких условиях, в большинстве случаев,

возможностей языка ассемблера достаточно, а возможности языка

C избыточны.

Для анализа кода программы возможно применение

следующих характеристик [4.4]:

- количество строк кода (англ.: Lines of Code (LOC));

- метрические характеристики Холстеда;

- индекс разработки (англ.: Maintainability Index (MI));

- циклическая сложность (англ.: Cyclomatic Complexity

(CC));



55

- расширенная циклическая сложность (англ.: Extended

Cyclomatic Complexity (ECC)).

Для сравнительного анализа реализаций алгоритма были

выбраны метрические характеристики Холстеда, так как они

наиболее полно описывают полученный код. Необходимо

вычисление следующих характеристик [4.3]: длина программы;

объем программы; уровень программы; уровень языка

программирования; ожидаемое время реализации алгоритма;

интеллектуальное содержание алгоритма; количество переданных

ошибок; работа.

Данные метрики основаны на следующих показателях:

- n1 ‒ число уникальных операторов программы, включая

символы-разделители, имена процедур и знаки операций (словарь

операторов);

- n2 ‒ число уникальных операндов программы (словарь

операндов);

- N1 ‒ общее число операторов в программе;

- N2 ‒ общее число операндов в программе;

- n1' ‒ теоретическое число уникальных операторов;

- n2' ‒ теоретическое число уникальных операндов.

Учитывая введенные обозначения, можно определить:

- n=n1+n2 ‒ словарь программы;

- N=N1+N2 ‒ длина программы;

- n'=n1'+n2' ‒ теоретический словарь программы;

- N'= n1*log2(n1) + n2*log2(n2) ‒ теоретическая длина

программы (для стилистически корректных программ отклонение

N от N' не превышает 10%);

- V=N*log2n ‒ объем программы;

- V'=N'*log2n' ‒ теоретический объем программы, где n* ‒

теоретический словарь программы;

- L=V'/V ‒ уровень качества программирования, для

идеальной программы L=1;

- L'= (2 n2)/ (n1*N2) ‒ уровень качества программирования,

основанный лишь на параметрах реальной программы без учета

теоретических параметров;



56

- EC=V/(L')2 ‒ сложность понимания программы;

- D=1/ L' ‒ трудоемкость кодирования программы;

- y' = V/ D2 ‒ уровень языка выражения;

- I=V/D ‒ информационное содержание программы, данная

характеристика позволяет определить умственные затраты на

создание программы;

- E=N' * log2(n/L) ‒ оценка необходимых интеллектуальных

усилий при разработке программы, характеризующая число

требуемых элементарных решений при написании программы.

При применении метрик Холстеда частично компенсируются

недостатки, связанные с возможностью записи одной и той же

функциональности разным количеством строк и операторов.

При использовании представленных формул в разработанной

программе должны отсутствовать следующие, т.н.

«несовершенства» [4.4]:

– дополняющие друг друга операции (последовательное

применение двух дополняющих друг друга операторов к одному и

тому же операнду);

– неоднозначные операнды (имя операнда используется для

обозначения разных объектов);

– синонимичные операнды (указание двух различных имен

для одного и того же объекта);

– общие подвыражения (подвыражения, которые

встречаются несколько раз);

– ненужное присваивание;

– использование выражений, не представленные в виде

произведений множителей (то есть произведение представляется в

виде суммы, при этом выполняются ненужные операции).


В ходе выполнения практической работы необходимо:

1. Для алгоритмов из лабораторной работы №3 работы

дополнительно реализовать программный код на языке низкого

уровня.

2. Произвести оценку с помощью метрик Холстеда для

каждого программного кода реализации алгоритма.



57

3. Произвести оценку энергопотребления программного кода

реализации каждого алгоритма.


полученные показатели для каждого алгоритма.


6. Провести сравнительный анализ результатов и получить

зависимость энергопотребления алгоритма от уровня языка его

реализации.






Тексты программных кодов выбранных алгоритмов;





1. Что такое язык программирования?

2. Что такое язык программирования низкого уровня?

3. Что такое язык программирования высокого уровня?

4. Что такое словарь программы?

5. Что такое длина программы?

6. Что такое теоретический словарь программы?

7. Что такое теоретическая длина программы?

8. Что такое объем программы?

9. Что такое теоретический объем программы?

10. Что такое уровень качества программирования?

11. Что такое сложность понимания программы?

12. Что такое уровень языка выражения?

Что такое информационное содержание программы?

3. Анализ эффективности энергооптимизации


58

3. АНАЛИЗ ЭФФЕКТИВНОСТИ ЭНЕРГООПТИМИЗАЦИИ С

ИСПОЛЬЗОВАНИЕМ GREENCO CONTROLLER

3.1 Тренинг-лабораторная работа №5. Анализ влияния

уровней оптимизации при компиляции программ на

энергопотребление


Целью практического занятия является выработка навыков

получения и анализа влияния уровней оптмизации при

компиляции на энергопотребление программ с использованием

GreenCoController.



программы;

- изучение влияния компилятора и уровня его оптимизации на

энергопотребление.


- получение навыков оценки влияния программного

обеспечения на энергопотребление;

- практическое применение способов выбора уровня

оптимизации компилятора при реализации алгоритмов для

снижения влияния программного обеспечения на

энергопотребление.





руководстве, а также в работах [5.1-5.15];

- подготовить программные коды из практической работы №

4. Эти коды в процессе выполнения работы будут сравниваться по

степени оптимальности энергопотребления при различных

уровнях оптимизации.



59


Для оптимизации энергопотребления в основном

применяются аппаратные решения. Программные подходы для

решения данного вопроса являются относительно новыми.

Программное обеспечение имеет значительное влияние на общее

потребление энергии, главным образом определяя активность ядра

процессора, памяти и других компонентов[5.1 – 5.5].

Основные подходы к повышению энергоэффективности,

рассмотренные в источниках [5.6 – 5.11] базируются на

преобразовании исходного кода с сохранением его

функциональных возможностей, т.е. на его оптимизации. Такую

оптимизацию можно разделить на два типа – ручную и

автоматическую. Ручная оптимизация осуществляется, как

правило, в конце этапа кодирования и выполняется разработчиком

[5.6, 6.7]. Автоматическая оптимизация осуществляется на этапе

компилирования и выполняется компилятором [5.8].

Ручная оптимизация имеет ряд недостатков. Во-первых, для

ее реализации необходим существенно больший временной

ресурс, чем на выполнение автоматической. А чаще всего именно

его так не хватает разработчикам. Во-вторых, для ручной

оптимизации необходим человеческий ресурс, что сопровождается

дополнительными затратами на разработку ПО. В-третьих, при

проведении оптимизации исходного кода существенно понижается

его читабельность. Учитывая, что над одним проектом может

работать несколько десятков программистов, подобные ухудшения

недопустимы. Кроме того, читабельность кода влияет и на

качество оптимизации при компиляции. В-четвертых, при

современных размерах исходных кодов программист просто

физически не в состоянии удерживать в голове большое

количество необходимых для оптимизации параметров. Часто для

повышения эффективности работы используются различные

автоматизированные средства, типа профайлеров, но даже они не в

состоянии критически повлиять на состояние вопроса. Автоматическая оптимизация с помощью компилятора

лишена всех этих недостатков. Всѐ большие надежды возлагаются

на оптимизирующие компиляторы, особенно это связано с



60

распространением и постоянным обновлением многоядерных

архитектур микропроцессоров. Компьютерные технологии

проникли во все аспекты нашей жизни, производительность

устройств очень важна, и может быть существенно улучшена с

помощью оптимизации заложенных программ. Однако если

ручную оптимизацию мы можем проводить по множеству

различных критериев, то набор критериев в оптимизирующих

компиляторах, как правило, ограничен.

В компиляторах используются следующие критерии

оптимизации [5.11]:

количество используемых ресурсов ЦПУ;

количество исполняемых операций;

количество вызовов памяти;

время исполнения программы на целевом устройстве,

измеряемое в тактах или секундах;

память, используемая при исполнении программы для

типичных входных данных. Иногда учитывается отдельно каждый

тип памяти: регистровая, кэш, оперативная, внешняя.

размер исполняемого бинарного кода программы;

цена производства целевого устройства. Это совокупная

функция, определяемая по таким характеристикам устройства, как

частота работы, количество функциональных блоков, размер

регистровых файлов и кэшей;

потребляемая энергия.

Таким образом, можно определить следующие общие

направления оптимизации – сокращение времени работы

программы, повышение производительности и уменьшение

энергопотребления.

Оптимизирующее преобразование в компиляторе исполняется

в три этапа:



61

1. определить часть программы, которую надо

оптимизировать, и определить соответствующее оптимизирующее

преобразование;

2. проверить, что преобразование не изменяет результат

исполнения данного участка кода или изменяет его в рамках,

утверждённых пользователем;

3. провести преобразование.

Пункт 1 является предметом длительных исследований, так

как его исполнение зависит от множества факторов (в т.ч.

архитектура процессора). Пункт 2 гласит о том, что результат

работы программы не должен изменяться. Наиболее слабое

определение гласит что Преобразование допустимо, если

оригинальная и преобразованная программы дают один и тот же

вывод для разных исполнений при одинаковых входных данных.

Два запуска программы являются идентичными, если они

произведены при одинаковых входных данных и если каждая пара

соответствующих операторов с недетерминированным

исполнением при обоих запусках даёт одинаковый результат.

Обычно недетерминированные исполнение является

результатом вызова внешних функций, например, процедур

операционной системы.

Преобразование программы корректно, если для всех

семантически правильных исполнений программы, оригинальная и

преобразованная версии программы дают идентичный результат

для идентичных запусков.

Фактически, при программировании мы делаем множество

допущений, которые могут в конкретном случае и не выполняться:

например, индексация массива может не выходить за пределы его

размерностей. Корректность в этом контексте является не

свойством самой программы, а свойством её конкретного запуска

– поскольку при одних входных данных программа может вести

себя корректно, при других некорректно. Те же самые



62

соображения относятся и к обработке исключений. Вообще

недостоверно, что преобразованная программа будет давать

абсолютно такой же результат, как и исходная – возможно это не

требуется.

Таким образом, на практике используется ещё более слабое

утверждение, что преобразование программы корректно, если для

всех семантически корректных запусков исходной программы,

оригинальная и преобразованная версии производят

эквивалентные операции при идентичных запусках. Все

перестановки коммутативных операций подразумеваются

эквивалентными.

Естественно, если в случае выполнения компилятором пункта

(3) появляется погрешность в вычислениях, выходящая за

определённые рамки, необходимо вернуться к пункту (2) – трудно

заранее предугадать, как будет оптимизировано исполнение

коммутативных операторов.

Базовым понятием, используемым во всех оптимизирующих

преобразованиях уровня базового блока и выше, является понятие

зависимости по данным.

В общем случае встречаются три типа зависимости по

данным: истинная или потоковая, антизависимость, и зависимость

по выходу (выходная). Для каждого типа зависимости определены

исток (источник зависимости) и сток зависимости (зависящий

оператор). Графом зависимости по данным является

ориентированный граф, вершинами которого являются операторы

программы, две вершины Si и Sj соединены дугой, если существует

зависимость одного из трёх перечисленных типов с истоком в Si и

стоком в Sj. Каждая дуга имеет метку, определяющую тип

зависимости и глубину зависимости (для оператора в теле гнезда

цикла) – номер цикла, порождающего данную зависимость.

Пусть Si обозначает i-й оператор в программе или ББ, если

считать в лексикографическом порядке. Все имеющиеся в



63

программе операторы разделяются на два типа: скалярные и

индексированные. Индексированные операторы – те, которые

встречаются в теле какого-нибудь цикла или их исполнение

управляется с помощью индексной переменной (векторные

операторы). Остальные операторы являются скалярными.

Степенью оператора является число разных циклов, его

окружающих, или число измерений его операндов. Оператор

степени k имеет вид Si(I1,I2,…,Ik), где Ij, LjIjUj, – индексная

переменная j-го цикла, Lj и Uj – нижняя и верхняя границы

изменения индексной переменной. Индексированный оператор

Si(I1,I2,…,Ik) имеет

k

j jN1

, где Nj = Uj – Lj + 1, разных

экземпляров (исполнения) по одному для каждого значения Ij,

j=1,…,k. Первый и последний экземпляры оператора степени k

имеют вид Si(L1,L2,…,Lk) и Si(U1,U2,…,Uk).

Порядок исполнения между двумя операторами Si и Sj

определяется следующим образом: скалярный оператор Si

исполняется раньше скалярного Sj (обозначается Si Sj), если

оператор Si лексически предшествует Sj (i<j). Для

индексированных операторов степени k имеет место:

если Si и Sj не имеют общих индексов, то Si Sj, если ij;

если у них одни и те же индексы, то (обозначая как Si(i1,…,ik)

конкретный экземпляр оператора Si при I1=i1,…,Ik=ik: Si(i1,…,ik)

Sj(j1,…,jk) если ij и существует такое m (0mk), что il=jl для

l=1,…,m и im+1<jm+1. Если же i<j, всё остаётся аналогично, но с

условием m<k;

если Si и Sj имеют m<k общих индексов и il=jl (l=1,…,m), то Si

Sj только тогда, когда ij.

Определим также множества IN(S) и OUT(S) входных и

выходных переменных оператора Si соответственно. Определим

через OUT(Si(i1,…,ik)) множество экземпляров переменных

(необязательно разных), определяющихся экземпляром Si(i1,…,ik)



64

оператора Si. Аналогично, определим через IN(Si(i1,…,ik))

множество экземпляров переменных, которые используются тем

же экземпляром оператора. Считаем, что оператор Si простой

(содержит не более одного присваивания) если||OUT(Si)||1.

Два оператора Si(I1,I2,…,Ik) и Sj(J1,J2,…,Jk) будут в потоковой

зависимости Si Sj, только если существуют значения индексов

(i1,i2,…,ik) и (j1,j2,…,jk) такие, что справедливы два условия:

1) Si(i1,i2,…,ik)Sj(j1,j2,…,jk);

2) OUT(Si(i1,i2,…,ik))∩IN(Sj(j1,j2,…,jk))≠.

Антизависимость от Si к Sj (обозначается SiaSj) определяется

аналогично потоковой, но условие (2) имеет вид

IN(Si(i1,i2,…,ik))∩OUT(Sj(j1,j2,…,jk))≠.

Выходная зависимость от Si к Sj (обозначается SiSj)

определяется аналогично потоковой, с условием (2):

OUT(Si(i1,i2,…,ik))∩OUT(Sj(j1,j2,…,jk))≠.

Граф зависимостей по управлению формируется следующим

образом. Каждая вершина, которая может определять

последующее исполнение операторов проверкой логического

условия (вершина-распознаватель), имеет не более двух дуг к

подчинённым вершинам (т.е. куда передаётся поток управления).

Этим дугам сопоставлены атрибуты T («истина») и F («ложь») –

фактически – куда переходить по результатам проверки условия.

Вершина v постдоминируется вершиной w (w≠v) в графе

программы (или вершина w – обязательный наследник v), если

каждый путь из v в t содержит в себе w (начальная вершина пути

исключается – вершина не постдоминирует сама себя).

Вершина y зависит по управлению от x, если:

1) существует путь P из x в y, в котором любая вершина x (за

исключением x и y) постдоминируется вершиной y;

2) вершина x не постдоминируется вершиной y.



65

Граф зависимостей по данным и граф зависимостей по

управлению вместе составляют граф программных зависимостей

(или управляющий граф программы).

Оптимизация параметров компилятора строится, в частности,

на технологии итеративной оптимизации, позволяющей

исследовать пространство оптимизирующих преобразований,

количество которых весьма велико, а архитектуры процессоров

весьма сложны для моделирования. Итеративная оптимизация

позволяет улучшить производительность скомпилированного

приложения, например задача перемножения двух матриц может

быть ускорена в несколько раз.

Для автоматической подстройки компиляторов применяется,

например, машинное обучение, реализованное с помощью ряда

подходов. Построение дерева решений эффективно для

подстройки алгоритмов развертывания циклов на разных

архитектурах, однако для решения более широкой задачи,

включающей большее число алгоритмов, может потребоваться

слишком много ресурсов.

Машинное обучение – хорошее подспорье при поиске

оптимальных параметров компилятора, однако для достижения

заметных результатов требуется сбор большого числа различных

данных, приведение их к единому представлению и

статистическая обработка. Для того чтобы обучение дало

действительно оптимальную для общего случая эвристическую

функцию, необходим тщательно подобранный набор обучающих

приложений, покрывающий большой спектр разнообразных

случаев.

Сегодня имеется множество алгоритмов отбора опций

компиляторов. Число оптимизирующих преобразований в

современном компиляторе велико. Явное задание всех

необходимых оптимизирующих преобразований было бы

громоздким. Поэтому вводится понятие уровня оптимизации как

множества используемых оптимизирующих преобразований. Как

правило, компиляторы имеют несколько уровней оптимизации.

Опции, которые начинаются с O, - это указания компилятору

включать различные оптимизации.



66

- O0 (O ноль) - это самые простые и примитивные

оптимизации.

- O1 - более сильные оптимизации.

- O2 - оптимизировать все, что можно, но только проверенные

и надежные оптимизации.

- O3 - жесткая и насильная оптимизация, применяются

экспериментальные методы.

Каждый последующий уровень включает предыдущие. Что

происходит на каждом уровне, сильно зависит от версии

компилятора и нужно смотреть в документацию.

Обычно принято, что когда компилируют для отладки,

используют максимум -O1. Для кода на сервера - -O2. -O3

применяют те, кому нужны дополнительные проценты в

производительности и они готовы пожертвовать тем, что

приложение может быть нестабильным.


В ходе выполнения практической работы необходимо:

1. Использовать программные коды из практической работы

№ 4.

2. Использовать для компиляции разные уровни оптимизации.

3. Оценить энергопотребление полученного программного

обеспечения


полученные показатели для каждой связки «язык

программирования – компилятор – уровень оптимизации».

4. Представить данные этой таблицы в виде диаграмм.

5. Провести сравнительный анализ результатов.






Алгоритм, согласно варианту задания;



67

Тексты полученных реализаций для различных языков

программирования;





1. Что такое компиляция?

2. Что такое оптимизация программного кода?

3. Что такое ручная оптимизация?

4. Опишите основные элементы автоматической

оптимизации.

5. Назовите недостатки ручной оптимизации.

6. Перечислите критерии оптимизации компиляторов.

7. Перечислите этапы оптимизирующего преобразования в

компиляторе.

8. Когда преобразование программы корректно?

9. Что такое зависимость по данным?

10. Назовите типы зависимости по данным.

11. Сформулируйте методику оптимизации параметров

компилятора.

12. Что такое итеративная оптимизация параметров

компилятора?

13. Опишите применение генетического

программирования в выборе параметров компиляторов.

14. Опишите применение машинного обучения при поиске

оптимальных параметров компилятора.

15. Что такое уровень оптимизации в компиляторе?

16. Опишите основные уровни оптимизации в

компиляторе.



68


методов оптимизации энергопотребления программ


Целью практического занятия является выработка навыков

оптимизации программного кода по критерию энергопотребления

на основе статического анализа с использованием

GreenCoController.



программы;

- изучение способов снижения энергопотребления

программного обеспечения.


- получение навыков оценки влияния программного

обеспечения на энергопотребление;

- практическое применение способов оптимизации

программного кода по критерию энергопотребления.

Подготовка к практическому занятию:




руководстве, а также в работах [6.1 -6.11] ;

- подготовить программные коды из практической работы №

5. Эти коды в процессе выполнения работы будут сравниваться по

степени оптимальности энергопотребления при различных

уровнях автоматической оптимизации и ручной.


В данной работе мы сосредоточим свое внимание на

оптимизации программного кода, так как, во-первых, ее методики

являются универсальными для большинства программного

обеспечения, а во-вторых, их легко можно использовать и для кода

уже созданных программ.

Среди практических задач программной инженерии особое

место занимает задача оптимизации программного обеспечения



69

[6.1 - 6.4]. При этом под оптимизацией понимается модификация

программного обеспечения для улучшения его эффективности.

Следует отметить, что термин «оптимизация программного

обеспечения» (или «оптимизация программного кода») не

предполагает строгого решения задачи оптимизации (то есть

нахождение экстремума) в ее математической постановке [6.5,

6.6]. Оптимизированное программное обеспечение обычно только

соответствует заданным ограничениям, при этом, как правило,

невозможно доказать, что полученные характеристики

соответствуют глобальному экстремуму. Такая ситуация

объясняется двумя следующими причинами.

Во-первых, функционирование программного обеспечения

зависит от входных данных, то есть оптимальное

функционирование при одних входных данных не означает

оптимального функционирования при всех возможных наборах

входных данных.

Во-вторых, в большинстве случаев невозможно задать

значение «веса» для компонентов программного кода, поскольку

все они должны быть выполнены. В современной литературе по

программной инженерии отсутствует какая-либо математическая

формализация постановки задачи оптимизации программного

обеспечения по критерию энергопотребления. Следует также

отметить, что публикации, посвященные теоретическим аспектам

оптимизации ПО, достаточно редки, и, как правило, сводятся к

приемам работы с инструментальными средствами оптимизации.

Процесс оптимизации программного обеспечения может быть

представлен как набор итераций, включающих проверку того,

соответствуют ли после модификации параметры

энергопотребления заданным и необходимо ли дальнейшее

изменение структуры кода для достижения этого.

Формально – это задача оптимизации, а в контексте данного

исследования – задача минимизации энергопотребления. Таким

образом, критерием оптимизации является некоторая функция:

min),...,,( 21 nxxxE , (6.1)

где E – энергопотребление; x – все параметры (метрики), которые



70

прямым или косвенным образом могут влиять на

энергопотребление системы.

Выбор всей совокупности метрик, влияющих на

энергопотребление программы, является индивидуальным для

каждого типа программного обеспечения. Как правило,

современное программное обеспечение – это очень сложная

система с огромным числом связей и зависимостей. И дело не

только в сложности самого программного продукта. Любая

программа имеет свою среду выполнения, работает в

операционной системе, взаимодействует с другими сервисами и

другим программным обеспечением, причем все эти элементы

также являются отдельными сложными системами с не меньшим

числом внутренних связей и зависимостей. Если же добавить еще

и взаимные зависимости метрик, то получим астрономическое

число всевозможных комбинаций параметров [6.7]. Однако, есть

такие метрики, которые независимо будут присутствовать в

каждой программе, например, потребление энергии центральным

процессором, оперативной памятью и прочее.

К оптимизации программного кода предъявляются

следующие требования [6.3]:

оптимизация должна быть максимально машинно-

независимой и переносимой на другие платформы (операционные

системы) без дополнительных затрат и существенных потерь

эффективности. Мы должны оставаться исключительно в рамках

целевого языка, причем, желательно использовать, только

стандартные его средства и любой ценой избегать специфических

расширений, имеющихся, только в одной конкретной версии

компилятора;

оптимизация не должна увеличивать трудоемкость

разработки (в том числе и тестирование) программного

обеспечения более чем на 10 – 15%, а в идеале, все критические

алгоритмы желательно реализовать в виде отдельной библиотеки,

использование которой не увеличивает трудоемкости разработки

вообще;



71

оптимизированный алгоритм должен давать выигрыш в

энергопотреблении не менее чем на 10 – 15% по сравнению с

неоптимизированным;

оптимизация должна допускать внесение изменений

отдельных участков кода без последствий для других, уже

оптимизированных участков. Достаточно много техник

оптимизации способствуют деградации программы, поскольку

даже незначительная модификация оптимизированного кода

может уничтожить результат оптимизации.

Для проведения оптимизации нужны специальные методики и

инструменты. Одним из таких является статический анализ кода.

Статический анализ кода – это анализ, который выполняется

(в отличие от динамического анализа) без реального выполнения

исследуемых программ. В большинстве случаев статический

анализ проводится над какой-либо версией программного кода.

В зависимости от используемого инструмента глубина

анализа может варьироваться от определения поведения

отдельных операторов к анализу, включающему весь имеющийся

программный код. Способы использования полученной в ходе

анализа информации также различные – от выявления мест,

возможно содержащих ошибки, до формальных методов,

позволяющих математически доказать какие-либо свойства

программы (например, соответствие поведения программы ее

спецификации).

Получение метрик и статический анализ часто сочетаются,

особенно при создании встраиваемых систем (software quality

objectives) [6.8].

В последнее время статический анализ все больше

используется в верификации свойств программного обеспечения,

используемого в компьютерных системах высокой надежности,

особенно критического назначения. Он также применяется для

поиска кода, который содержит уязвимости [6.9].

Рассмотрим преимущества статического анализа кода.

Статические анализаторы дают полное покрытие кода, то есть

проверяют даже те фрагменты кода, которые получают управление



72

крайне редко. Такие участки кода, как правило, не удается

протестировать другими методами. Это позволяет находить

дефекты в обработчиках редких ситуаций, в обработчиках ошибок

или в системе логирования. Статический анализ не зависит от

используемого компилятора и среды, в которой будет выполняться

скомпилированная программа. Это позволяет находить скрытые

ошибки, которые могут проявить себя только через несколько лет

[6.10].

Но надо учитывать и недостатки статического анализа кода.

Этот анализ, как правило, слаб в диагностике нерационального

использования памяти и ошибок при параллельной обработке.

Чтобы обнаруживать подобные ошибки, фактически необходимо

виртуально выполнить часть программы. Программы статического

анализа предупреждают о подозрительных местах кода. Это

означает, что на самом деле код может быть абсолютно корректен,

а система статического анализа будет выдавать предупреждающие

сообщения. Это явление называется ложно-положительными

срабатываниями. Необходимость просматривать ложные

срабатывания отнимает время и ослабляет внимание к тем

участкам кода, где на самом деле находятся ошибки [6.10]. Кроме

того, иногда существуют проблемы с анализом циклов, рекурсий и

вызовов глубокой вложенности. Однако новые подходы

(например, рассмотренные в работе [6.11]) помогают решать эти

проблемы.

Обычно для проверки энергопотребления программ

используют только динамический анализ программного

обеспечения. Однако это не является рациональным.

Преимущества статического анализа перед динамическим:

статический анализ проверяет весь код. Он может проверить

даже те ветви, которые крайне редко получают управление. При

динамическом анализе выполнить определенные ветви программы

иногда бывает очень трудно (сложно подготовить данные, сложно

сымитировать аварийную ситуацию и так далее);

динамический анализ часто подходит при тестировании

ресурсоемких программ. Если программа использует гигабайты

данных, то использование динамического анализатора может



73

привести к недопустимому снижению скорости работы.

Статический анализ не зависит от этапа выполнения, поскольку

анализирует программный код. При этом скорость его анализа

легко и просто масштабируется;

можно проверить код в тот момент, когда запуск

определенных тестов еще невозможен. Это значит, что мы

устраняем некоторые ошибки максимально рано, а значит

максимально дешево;

статический анализатор может обнаружить ситуации,

абсолютно безопасны с точки зрения динамического анализа.

Следует заметить, что в большинстве современных

источников понятие оптимизации энергопотребления созвучно с

оптимизацией по времени. Т.е. они базируются на утверждении,

что чем быстрее работает приложение, тем меньше оно потребляет

энергии.

Таким образом, перед нами стоят следующие задачи:

определить является ли наиболее эффективный код по

времени настолько же эффективным по энергопотреблению;

определить влияние текущих методов оптимизации на

энергопотребление как системы в целом, так и на отдельные ее

элементы;

определить методы оптимизации, сокращающие

энергопотребление;

структурировать найденные методы оптимизации;

Зависимость энергопотребления от времени работы

приложения всегда справедлива для методов, основанных на

сокращении количества исполняемых инструкций, но далеко не

всегда – для методов, увеличивающих уровень существующего

параллелизма в программе, что часто влечет за собой повышение

пиковой и средней мощности процессора. Следовательно, в

некоторых случаях, ускоряя приложение, мы повышаем этим его

энергопотребление. При этом часто можно найти разумный

компромисс, несколько увеличив время работы приложения, но



74

снизив его энергопотребление (для не критичных по времени

систем).

Ниже представлены методы оптимизации, снижающие

энергопотребление [6.8 – 6.11]:

использование регистровых операндов;

кластеризация инструкций;

переупорядочивания инструкций и обращений к памяти;

оптимизация циклов;

пропуск кэша;

удаление рекурсий;

использование базы энергопотребления;

динамическое управление питанием;

использование спящего режима ресурсов;

аппаратная независимость;

удаленное отображение задач.

Для полного проведения анализа использования методов их

можно разбить на группы:

сокращение количества выполняемых инструкций;

использование базы энергопотребления инструкций при

генерации кода;

добавление функций управления режимами аппаратных

компонентов;

использование внешних вычислительных мощностей.

Ниже в таблице представлен пример ряда оптимизаций:



75

Таблица 7. Примеры оптимизаций

№ группы оптимизации

№ метода Метод оптимизации

1 Константы

1 Свертка констант

2 Объединение констант

3 Константная подстановка в условиях

4 Константная подстановка в функциях

2 Код и переменные

1 Удаление мертвого кода

2 Удаление неиспользуемых функций

3 Удаление неиспользуемых переменных

4 Удаление неиспользуемых выражений

5 Удаление лишних обращений к памяти

6 Удаление копий переменных

7 Размножение переменных

8 Распределение переменных по

регистрам

9 Регистровые ре-ассоциации

3 Выражения

1 Упрощение выражений

2 Упрощение алгоритма

3 Использование подвыражений

4 Ветвления

1 Выравнивание переходов

2 Частичное вычисление условий

3 Удаление избыточных проверок

4 Удаление проверок нулевых указателей

5 Совмещение проверок

6 Сокращение длины маршрута

7 Уменьшение количества ветвлений

8 Сокращение количества сравнений

9 Избавление от ветвлений

10 Оптимизация switch

11 Балансировка логического древа

12 Создание таблицы переходов



76

№ группы оптимизации

№ метода Метод оптимизации

5 Циклы

1 Выравнивание циклов

2 Разворот циклов

3 Шелушение циклов

4 Фальцевание циклов

5 Векторизация

6 Автопараллелизм

7 Программная конвейеризация

8 Предвычисление индуктивных циклов

9 Разбивка длинных цепочек

зависимостей

10 Устранение хвостовой рекурсии

11 Объединение циклов

12 Разматывание циклов

13 Расщепление циклов

14 Нормализация циклов

15 Масштабирование циклов

16 Замена циклов с предусловием на

циклы с постусловием

17 Стремление циклов к нулю

18 Отказ от branch-count-reg

19 Вынос инвариантных ветвлений

20 Ротация ветвлений

21 Упорядочение обращений к памяти



77


В ходе выполнения лабораторной работы необходимо:

1. Выбрать из перечня оптимизаций необходимые методы и

провести оптимизацию программного кода из практического

задания №5. Описание методов оптимизации приведено в [6.12-

6.14]

2. Измерить энергопотребление оптимизированного вручную

программного кода.


полученные показатели для оптимизированного вручную и

автоматически программного кода.


5. Провести сравнительный анализ результатов.






Тексты составленных исследуемых программ;

Тексты оптимизированных программ;





1. В чем заключается алгоритмическая оптимизация

программного обеспечения?

2. Что входит в оптимизацию программного кода?

3. Каковы задачи оптимизации программного обеспечения?



78

4. Перечислите требования к оптимизации программного

кода.

5. Что такое статический анализ кода?

6. Назовите достоинства статического анализа кода.

7. Назовите недостатки статического анализа кода.

8. Что такое динамический анализ кода?

9. Назовите достоинства динамического анализа кода.

10. Назовите недостатки динамического анализа кода.

11. Опишите методы оптимизации программного кода.

12. Как производится оценка энергопотребления

программного обеспечения?

13. Опишите инструментарий оценки энергопотребления

программного обеспечения.

Литература

79

ЛИТЕРАТУРА

Литература к работе №1

1.1. Brian W. E. Arduino Programming Notebook [Electronic

Resource] / W. Evans Brian // Creative Commons. – 2007. – Access

mode: http://playground.arduino.cc/uploads/Main/arduino_notebook_v1-

1.pdf.

1.2. Getting Started with dsPIC30F Digital Signal Controllers

User’s Guide [Electronic Resource] // Microchip Technology

Incorporated. – 2005. – Access mode:

http://ww1.microchip.com/downloads/en/DeviceDoc/70151a.pdf.

1.3. Аверченко А.П. Оценка выигрыша вычислительных

затрат преобразования Хартли перед преобразованием Фурье

[Электронный ресурс] / А.П. Аверченко, Б.Д. Женатов // Омский

научный вестник. – 2015. – Режим доступа:

http://cyberleninka.ru/article/n/otsenka-vyigrysha-vychislitelnyh-zatrat-

preobrazovaniya-hartli-pered-preobrazovaniem-furie.


2.1. Дискретное преобразование Фурье, Хартли [Electronic

Resours] // Режим доступа: http://algolist.manual.ru/maths/fft.php.


3.1. Chandrakasan A., Brodersen R. Low Power Digital CMOS

Design. Boston, Kluwer Academic Publishers, 1995.

3.2. Fornaciari W., Gubian P., Sciuto D., Silvano C. Power

estimation of embedded systems: A hardware/software codesign

approach. IEEE Trans. on VLSI Systems, 1998, vol. 6, no. 2, pp. 266-

275.

3.3. Brooks D., Tiwari V., Martonosi M. Wattch: A framework

for architectural-level power analysis and optimizations. Proc.

International Symposium on Computer Architecture. Vancouver, BC,

Canada, 2000, pp. 83-94.

http://playground.arduino.cc/uploads/Main/arduino_notebook_v1-1.pdf

http://playground.arduino.cc/uploads/Main/arduino_notebook_v1-1.pdf

http://ww1.microchip.com/downloads/en/DeviceDoc/70151a.pdf

http://cyberleninka.ru/article/n/otsenka-vyigrysha-vychislitelnyh-zatrat-preobrazovaniya-hartli-pered-preobrazovaniem-furie

http://cyberleninka.ru/article/n/otsenka-vyigrysha-vychislitelnyh-zatrat-preobrazovaniya-hartli-pered-preobrazovaniem-furie

http://algolist.manual.ru/maths/fft.php


80

3.4. Catthoor F., Wuytack S., De Greef E., Balasa F.,

Nachtergaele L., Vandecappelle A. Custom Memory Management

Methodology: Exploration of Memory Organization for Embedded

Multimedia System Design. Boston, Kluwer Academic Publishers,

1998.

3.5. Furber S. ARM System-on-Chip Architecture. Harlow,

Addison-Wesley, 2000.

3.6. Kandemir M., Vijaykrishnan N., Irwin M.J., Ye, W.

Influence of compiler optimizations on system power. Proc. Design

Automation Conference. LosAngeles, CA, 2000, pp. 304-307.

3.7. Sinevriotis G., Stouraitis Th. SOFLOPO: low power

software development for embedded applications. ESPRIT ESD-LPD

Project 25403, Public Final Report, 2001.

3.8. Васильев В. С. Алгоритм. Свойства

алгоритма [Электронный ресурс] – режим доступа: http://pro-

prof.com/archives/578. Дата обращения: 06.01.2014.

3.9. Васильев В. С. Блок-схемы алгоритмов сортировки

пузырьком, выбором и вставками [Электронный ресурс] – режим

доступа: http://pro-prof.com/archives/1462. Дата обращения:

06.01.2014.

3.10. Дж. Макконелл. Анализ алгоритмов. Активный

обучающий подход. ‒ 3-е дополненное издание. М: Техносфера,

2009. -416с.

3.11. Миллер, Р. Последовательные и параллельные

алгоритмы: Общий подход / Р. Миллер, Л. Боксер; пер. с англ. ‒ М.

: БИНОМ. Лаборатория знаний, 2006. ‒ 406 с.

3.12. Скиена С. Алгоритмы. Руководство по разработке. 2-е

изд.: Пер. с англ. ‒ СПб.: БХВ-Петербург. 2011. ‒ 720 с.: ил.


81


4.1. Программирование микроконтроллеров AVR //

Электронный журнал «Мой робот» [Электронный ресурс] – режим

доступа: http://myrobot.ru/stepbystep/mc_programming.php

4.2. Глушаков, С.В., Программирование на C++ [Текст] /

C.В. Глушаков, Т.В. Дуравкина – М.:АСТ, 2008 – 685 с.

4.3. Сван, Том, Освоение Turbo Assembler: Пер. с англ.

[Текст] / Том Сван – К.;М.;СПб.: Диалектика, 1996 – 544 с.

4.4. Оптимизация компилятора // Электронный журнал

«Техника оптимизации» [Электронный ресурс] – режим доступа:

http://howoptimize.ru/optimization.html

4.5. Missed Optimization // Электронный журнал

«EasyElectronics.ru» [Электронный ресурс] – режим доступа:

http://we.easyelectronics.ru/AVR/missed-optimization.html

4.6. Ассемблер или C? // Электронный журнал «Controller

systems» [Электронный ресурс] – режим доступа:

http://controllersystems.com/books/praktika_programmirovaniya_atmel

_avr/assembler-ili-s.html

4.7. Фленов, Михаил, Искусство программирования игр на

C++ [Текст] // Михаил Фленов – СПб.:БХВ-Петербург, 2006 – 256

с.

4.8. Придётся ли Intel убрать из компилятора функцию,

намеренно выдающую плохой код для процессоров AMD? //

Электронный журнал «Железные войны» [Электронный ресурс] –

режим доступа: http://www.holyware.ru/viewtopic.php?f=52&t=2296

4.9. Касперски Крис, Сишные трюки // Крис Касперски –

журнал «Хакер», август 2008 (116) 2008, с.104

4.10. Авдюхин, Алексей, Высокий уровень

программирования // Алексей Авдюхин – журнал «Хакер», июль

07 (127) 2009, с.104

4.11. Павловская, Т.А., C/C++ Программирование на языке

высокого уровня [Текст] / Т.А.Павловская – СПб.: Питер, 2004 –

461с.


82

Литература работе №5

5.1. Rasmussen N. Electrical efficiency modeling for data centers

/ N. Rasmussen // American Power Conversion, white paper # 113. –

2006. – 18 p.

5.2. Tiwari V. Instruction level power analysis and optimization

of software / V. Tiwari, S. Malik, A. Wolfe, M.T.C. Lee// J. VLSI

Signal Processing, 1996. – Vol. 13. – no. 2. – p. 1-18

5.3. Eder K. Whole Systems Energy Transparency / K. Eder, S.

Kerrison, J. Gallagher, P. Lopez-Garcia. // NanoEnergy - Letters No. 6.

– August 2013.

5.4. Edwards C. Lack of Software Support marks the Low Power

Scorecard at DAC / C. Edwards. // ElectronicsWeekly. – No. 2472. –

15-21 June 2011.

5.5. Kerstin Eder Energy Aware Computing: Why SW engineers

are key to energy efficient computing / Kerstin Eder // Towards

Energy-Aware Software Development. – Dec. 11th. – 2014

5.6. Murugesan S. and Gangadharan G.R., Harnessing Green IT:

Principles and Practices, / S. Murugesan and G.R. Gangadharan. –

Wiley. – 2012. – 432 p.

5.7. Kharchenko V.S Green IT-Engineering. In 2 Volumes /

Kharchenko V.S . – National Aerospace Univercity KhAI. – Kharkiv,

Ukraine. – 2014. – 594 p.

5.8. Fakhar F. Software level green computing for large scale

systems/ F. Fakhar, B. Javed, R. Rasool, O. Malik, K. Zulfiqar// – vol.

1, №4. – Journal of cloud computing: Advanced, Systems and

Applications. – 2012. – 17 p.

5.9. Yakushkin S.I., Software and hardware optimization in the

generation of computing devices / S.I. Yakushkin// – S-PbGU. – 2005.

– pp 281-293.

5.10. Roy K. Software Design for Low Power. Chapter in Low

power design in deep submicron electronics/ K. Roy and M.C.

Johnson// – Kluwer Nato Advanced Science Institutes Series. – Vol.

337. – Kluwer Academic Publishers. – Norwell, MA. – USA,1997.– pp

433-460.


83

5.11. Kandemir M. Compiler optimization for low power

systems / M. Kandemir, N. Vijaykrishnan, M.J. Irwin// – Kluwer

Academic Publisher Norwell. – 2002. – pp. 191-210.

5.12. Kremer U. Low Power/Energy Compiler Optimizations/ U.

Kremer// – Low-Power Electronics Design. – CRC Press. – 2005. – 10

p.

5.13. Mahmut Kandemir Compiler optimizations for low power

systems /Mahmut Kandemir, N. Vijaykrishnan, Mary Jane Irwin, In

Robert Graybill and Rami Melhem editors// Power aware computing. –

Kluwer Academic Publishers, Norwell, MA, USA. – 2002. – p. 191–

210

5.14. Chung-Hsing Hsu The design, implementation, and

evaluation of a compiler algorithm for cpu energy reduction/ Chung-

Hsing Hsu, U. Kremer // SIGPLAN Not. – 38(5):38–48. – May 2003

5.15. Бруснецов Л. Автоматическая оптимизация при

компиляции/ Бруснецов Л. // «Открытые системы» . – № 02, 2011,

[Электронный ресурс] / – Режим доступа: -

http://www.osp.ru/os/2011/02/13007711/


6.1. Fornaciari W., Gubian P., Sciuto D., and Silvano C. (1998),

Power estimation of embedded systems: A hardware/software code sign

approach, IEEE Trans. on VLSI Systems, Vol. 6/2, pp. 266 – 275.

6.2. Kryvtsov A.Y., Hontovyi S.V. Approach to improve energy

efficiency of information systems, // Радіоелектронні і комп’ютерні

системи. – 2014. – № 1 (65). – С. 73 – 77.

6.3. Касперски К. Техника оптимизации программ.

Эффективное использование памяти / К. Касперски. – БХВ-

Петербург, – 2003. – 464 с

6.4. Магда Ю. С. Использование ассемблера для

оптимизации программ на С++ / Ю. / С. Магда. – БХВ-Петербург,

2004. – 492 с.

6.5. Левитин А.В. Алгоритмы: введение в разработку и

анализ / А. В. Левитин. – М.: Вильямс, 2006. –576 с.

6.6. Кормен Т. Алгоритмы: построение ианализ / Т. Кормен,

Ч. Лейзерсон, Р. Ривест, К. Штайн.– М. : Вильямс, 2006. – 1296 с.


84

6.7. Кривцов А. Ю. Аналіз зелених метрик та інструментів

для оцінки енергофективності програмного забезпечення / А. Ю.

Кривцов, С. В. Гонтовий // Радіоелектронні і комп’ютерні системи.

– 2014. – № 5 (69). – С. 76 – 80.

6.8. Briand P., Brochet M., Cambois T., Coutenceau E., Guetta

O., Mainberte D., Mondot F., Munier P., Noury L., Spozio P., and

Retailleau F.,(2010), Software Quality Objectives for Source Code.,

Proceedings Embedded Real Time Software and Systems Conference,

ERTS2,Toulouse, France

6.9. Livshits B. Improving Software Security with Precise Static

and Runtime Analysis / B.Livshits // section 7.3 “Static Techniques for

Security,” - Stanford University, 2006. – 229 p.

6.10. Макконнелл С. Совершенный код. Мастер-класс: пер. с

англ. / С. Макконнелл. – М. : Издательско-торговый дом “Русская

редакция”; СПб. Питер, 2005. – 896 с.

6.11. Юрченко А. В. Проектирование и анализ программного

обеспечения с низким энергопотреблением с помощью

программных метрик энергоэффективности / А. В. Юрченко//

Наука и образование. – 2013. – № 1. – С. 215 – 234.

6.12. Касперски К. Техника оптимизации под Linux. Часть 1

[Электронный ресурс] / К.Касперски // Системный администратор. –

2005. – Режим доступа: http://samag.ru/archive/article/428.



2005. – Режим доступа: http://samag.ru/archive/article/429.



2005. – Режим доступа: http://samag.ru/archive/article/465

http://samag.ru/archive/article/428



Анотація та зміст

85

АНОТАЦІЯ ТА ЗМІСТ

УДК004.9+681.5

В.В. Скляр, О.М. Одарущенко, Е.М. Бульба, Р.А. Горбенко,

А.Ю. Кривцов, О.О. Івасюк, В.С. Харченко Енергоефективність

алгоритмів та програм. Аналіз та оптимізація з

використанням GreenCo Controller. Тренінг. / За ред.

Харченка В.С., Скляра В.В., Одарущенка О.М. – Харків:

Національний аерокосмічний університет імені М.Є. Жуковського

«ХАІ». – 2016. – 95 с.

Викладено матеріали тренінг-курсу LLL1 "Methods and Tools

for Green Algorithms and Software", який розроблено в рамках

проекту TEMPUS «Green Computing & Communication» (530270-

TEMPUS-1-2012-1-UK-TEMPUS-JPCR).

Курс базується на методичних та інструментальних засобах,

призначених для оволодіння практичними навичками розроблення

енергоефективного програмного забезпечення, вимірювання та

оптимізації енергоспоживання для алгоритмів і програм, які

реалізуються у вбудованих системах на мікроконтролерах. Надано

опис лабораторних робіт і тренінгів, які виконуються з

використанням програмно-апаратного комплексу GreenCo

Controller.

Для інженерів, які займаються розробленням та

впровадженням енергоефективних мікропроцесорних систем, а

також магістрів і аспірантів університетів, які навчаються за

напрямами комп'ютерних наук, комп'ютерної та програмної

інженерії, при вивченні методів і засобів зеленої ІТ-інженерії.

Бібл. – 56 найменувань, рисунків – 23, таблиць – 7.

ISBN 978-617-7361-09-0.

Анотація та зміст

86

ЗМІСТ

ПЕРЕЛІК СКОРОЧЕНЬ ....................................................................... 3

ВСТУП ................................................................................................... 4

1. МЕТОДИКА ПРОВЕДЕННЯ ВИМІРЮВАНЬ З

ВИКОРИСТАННЯМ GREENCO CONTROLLER ............................ 5

1.1 Тренінг-лабораторна робота №1. Вивчення лабораторного

комплексу GreenCo Controller ............................................................. 5

1.2 Тренінг-лабораторна №2. Дослідження енергоспоживання для

алгоритму швидкого перетворення Фур'є ........................................ 30

2. ДОСЛІДЖЕННЯ ЕНЕРГОЕФЕКТИВНОСТІ АЛГОРИТМІВ І

ПРОГРАМ З ВИКОРИСТАННЯМ GREENCO CONTROLLER .... 35

2.1 Тренінг-лабораторна робота №3. Дослідження

енергоспоживання при реалізації алгоритмів різної складності .... 35

2.2 Тренінг-лабораторна робота №4. Аналіз енергоспоживання при

реалізації програм на різних мовах програмування ........................ 52

3. АНАЛІЗ ЕФЕКТИВНОСТІ ЕНЕРГООПТІМІЗАЦІІ З

ВИКОРИСТАННЯМ GREENCO CONTROLLER ........................... 57

3.1 Тренінг-лабораторна робота №5. Аналіз впливу рівнів

оптимізації при компіляції програм на енергоспоживання ............ 57

3.2 Тренінг-лабораторна робота №6. Дослідження методів

оптимізації енергоспоживання програм ........................................... 67

ЛІТЕРАТУРА ...................................................................................... 83

АННОТАЦІЯ ТА ЗМІСТ ................................................................... 84

ДОДАТОК А. НАВЧАЛЬНА ПРОГРАМА ...................................... 88

Abstract and content

87

ABSTRACT AND CONTENT

UDC004.9+681.5

Sklyar V., Odarushchenko O., Bulba Y., Gorbenko R., Krivtsov

A., Ivasiuk O., Kharchenko V. Energy Efficiency of Algorithms and

Programs. Analysis and Optimisation Using GreenCo Controller.

Training. / Ed. Kharchenko V., Sklyar V., Odarushchenko O. –

Kharkiv: National Aerospace University KhAI. – 2016. – 95p.

ISBN 978-617-7361-09-0

Practical materials of training course LLL1 "Energy Efficiency

of Algorithms and Programs" for under graduates, post graduate

students and engineers in frameworks of the project TEMPUS «Green

Computing & Communication» (530270-TEMPUS-1-2012-1-UK-

TEMPUS-JPCR) are described.

The training course is based on methodical and instrumental

tools to study techniques and to get skills of developing energy-

efficient algorithms and software, measuring energy related metrics,

power consumption optimization using different methods and means

for embedded systems. The trainings and labs to study green software

development and optimization using a special kit GreenCo Controller

are described.

The book is supposed to be used by engineers developing energy

efficient software and embedded systems, and MSc and PhD students

of universities that study computer science, computer and program

engineering when studying methods and tools of green IT. It could be

very useful for lecturers and professors who conduct classes on

corresponding courses.

Ref. – 56 items, figures – 23, tables – 7.

Abstract and content

88

CONTENT

ABBREVIATION .................................................................................. 3

INTRODUCTION .................................................................................. 4

1. METHODS OF POWER CONSUMPTION MEASUREMENT FOR

SOFTWARE AND EMBEDDED SYSTEMS USING GREENCO

CONTROLLER ...................................................................................... 5

1.1. Training-lab № 1. The study of laboratory complex GreenCo

Controller ................................................................................................ 5

1.2 Training-lab № 2. Energy research of fast Fourier transform

algorithm ............................................................................................... 30

2. RESEARCH OF ALGORITHMS AND SOFTWARE ENERGY

EFFICIENCY USING GREENCO CONTROLLER ........................... 35

2.1. Training-lab № 3. Power consumption research on realization of

different difficulty algorithms .............................................................. 35

2.2. Training-lab № 4. Analysis of energy consumption of software

developed using programming languages of different levels ............... 52

3. ANALYSIS OF ENERGY OPTIMIZATION TECHNIQUES FOR

SOFTWARE USING GREENCO CONTROLLER ............................ 57

3.1 Training-lab № 5. Power consumption-oriented impact analysis of

the optimization level for compiling programs .................................... 57

3.2 Training-lab № 6. Research of techniques for energy optimization

of software ............................................................................................ 67

REFERENCES ..................................................................................... 83

APPENDIX. DESCRIPTION OF THE MODULE ............................. 88

Приложение. Учебная программа

89

ПРИЛОЖЕНИЕ. УЧЕБНАЯ ПРОГРАММА

DESCRIPTION OF THE MODULE

TITLE OF THE MODULE Code

Energy Efficiency of Algorithms and Programs

Teacher(s) Department

Coordinating: Dr. Odarushchenko Oleg

Others: DrS, Prof. Sklyar Vladimir, DrS, Prof.

Kharchenko Vyacheslav, Bulba Yevhen, Gorbenko

Roman, Krivtsov Andrii, Dr Ivasiuk Oleksandr

Comper Systems

and Networks

Department of

KhAI, RPC Radiy

Study cycle Level of the module Type of the module

Under graduates,

Post graduate A

Full-time tuition

Form of delivery Duration Language(s)

Full-time tuition One semester Russian

Prerequisites

Prerequisites: Boolean algebra; statistics; discrete

mathematics; software developments;

computer systems and system

analysis

Co-requisites (if necessary):

Credits of the

course

Total student

workload

Contact hours Individual work

hours

2.5 75 38 37


90

Aim of the module (course unit):

competences foreseen by the study programme

Learning of software development methods with lower power consumption

Learning outcomes of module

(course unit)

Teaching/learning

methods

Assessment

methods

At the end of course, the

successful student will be able:

1. To perform measurements by

use of GreenCo Controller. To

assess energy metrics of

algorithms (similar Fast Fourier

Transform algorithms).

Interactive lectures,

Learning in

laboratories,

Just-in-Time Teaching

Module

Evaluation

Questionnaire

2. To research energy efficiency

of algorithms and programs


Learning in

laboratories,


Module

Evaluation

Questionnaire

3. To perform an impact analysis

of the optimization level for

compiling programs on energy

consumption.

4. To research and apply the

techniques of energy optimization

of programs


Learning in

laboratories,


Module

Evaluation

Questionnaire


91

Themes

Contact work hours

Time and tasks for

individual work

Lec

ture

s

Co

nsu

ltat

ion

s

Sem

inar

s

Pra

ctia

cl w

ork

Lab

ora

tory

wo

rk

Pla

cem

ents

To

tal

con

tact

wo

rk

Ind

ivid

ual

wo

rk

Tasks

1. The study of laboratory

complex GreenCo

Controller

2 2 4 4

2. Energy research Fast

Fourier Transform

algorithm

2 2 2 6 5

3. Energy research of

algorithms of different

complexity

2 4 6 5

4. Analysis of energy

consumption programs

developed using

programming languages

of different levels

2 2 4 8 8

5. Impact analysis of the

optimization level when

compiling programs on

energy consumption

2 2 2 6 6

6. Research of t

techniques to optimize

energy programs

2 2 4 8 9

Total: 12 8 18 38 37


92

Assessment strategy

Weight

in %

Deadl-

ines Assessment criteria

Lecture

activity,

including

fulfilling

special

self-tasks

10 7,14 85% – 100% Outstanding work,

showing a full grasp of all the questions

answered.

70% – 84% Perfect or near perfect

answers to a high proportion of the

questions answered. There should be a

thorough understanding and

appreciation of the material.

60% – 69% A very good knowledge of

much of the important material,

possibly excellent in places, but with a

limited account of some significant

topics.

50% – 59% There should be a good

grasp of several important topics, but

with only a limited understanding or

ability in places. There may be

significant omissions.

45% – 49% Students will show some

relevant knowledge of some of the

issues involved, but with a good grasp

of only a minority of the material. Some

topics may be answered well, but others

will be either omitted or incorrect.

40% – 44% There should be some work

of some merit. There may be a few

topics answered partly or there may be

scattered or perfunctory knowledge

across a larger range.

20% – 39% There should be substantial

deficiencies, or no answers, across large

parts of the topics set, but with a little

relevant and correct material in places.

0% – 19% Very little or nothing that is

correct and relevant.


93

Learning in

laboratories

30 7,14 85% – 100% An outstanding piece of

work, superbly organised and presented,

excellent achievement of the objectives,

evidence of original thought.

70% – 84% Students will show a

thorough understanding and

appreciation of the material, producing

work without significant error or

omission. Objectives achieved well.

Excellent organisation and presentation.

60% – 69% Students will show a clear

understanding of the issues involved

and the work should be well written and

well organised. Good work towards the

objectives.

The exercise should show evidence that

the student has thought about the topic

and has not simply reproduced standard

solutions or arguments.

50% – 59% The work should show

evidence that the student has a

reasonable understanding of the basic

material. There may be some signs of

weakness, but overall the grasp of the

topic should be sound. The presentation

and organisation should be reasonably

clear, and the objectives should at least

be

partially achieved.

45% – 49% Students will show some

appreciation of the issues involved. The

exercise will indicate a basic

understanding of the topic, but will not

have gone beyond this, and there may

well be signs of confusion about more

complex material. There should be fair

work towards the laboratory work

objectives.


94

40% – 44% There should be some work

towards the laboratory work objectives,

but significant issues are likely to be

neglected, and there will be little or no

appreciation of the complexity of the

problem.

20% – 39% The work may contain

some correct and relevant material, but

most issues are neglected or are covered

incorrectly. There should be some signs

of appreciation of the laboratory work

requirements.

0% – 19% Very little or nothing that is

correct and relevant and no real

appreciation of the laboratory work

requirements.

Module

Evaluation

Quest

60 8,16 The score corresponds to the percentage

of correct answers to the test questions

Содержание

95

СОДЕРЖАНИЕ

СПИСОК СОКРАЩЕНИЙ .................................................................. 3

ВВЕДЕНИЕ ........................................................................................... 4

1. МЕТОДИКА ПРОВЕДЕНИЯ ИЗМЕРЕНИЙ С

ИСПОЛЬЗОВАНИЕМ GREENCO CONTROLLER .......................... 6

1.1 Тренинг-лабораторная работа №1. Изучение лабораторного

комплекса GreenCo Controller ............................................................. 6

1.2 Тренинг-лабораторная №2. Измерение энергопотребления для

алгоритма быстрого преобразования Фурье .................................... 31

2. ИССЛЕДОВАНИЕ ЭНЕРГОЭФФЕКТИВНОСТИ

АЛГОРИТМОВ И ПРОГРАММ С ИСПОЛЬЗОВАНИЕМ

GREENCO CONTROLLER ................................................................ 36


энергопотребления при реализации алгоритмов различной

сложности ............................................................................................ 36

2.2 Тренинг-лабораторная работа №4. Анализ энергопотребления

при реализации программ на различных языках программирования

.............................................................................................................. 49

3. АНАЛИЗ ЭФФЕКТИВНОСТИ ЭНЕРГООПТИМИЗАЦИИ С

ИСПОЛЬЗОВАНИЕМ GREENCO CONTROLLER ........................ 58

3.1 Тренинг-лабораторная работа №5. Анализ влияния уровней

оптимизации при компиляции программ на энергопотребление .. 58

3.2 Тренинг-лабораторная работа №6. Исследование методов

оптимизации энергопотребления программ .................................... 68

ЛИТЕРАТУРА .................................................................................... 79

АНОТАЦІЯ ТА ЗМІСТ ...................................................................... 85

ABSTRACT AND CONTENT ............................................................ 87

ПРИЛОЖЕНИЕ. УЧЕБНАЯ ПРОГРАММА ................................... 89

Скляр Володимир ВолодимировичОдарущенко Олег МиколайовичБульба Євген МиколайовичГорбенко Роман АнатолійовичКривцов Андрій ЮрійовичІвасюк Олександр Олегович

Харченко Вячеслав Сергійович

Енергоефективність алгоритмів та програм.Аналіз та оптимізація з використанням

GreenCo Controller

Тренінг.(російською мовою)

Редактори: Харченко В.С., Скляр В.В., Одарущенко О.М.

Комп’ютерна верстка Харченко Л.Д.

Зв. план, 2014Підписаний до друку 11.01.2016

Формат 60х84 1/16. Папір офс. №2. Офс. друк.Умов. друк. арк. 5,58. Уч.-вид. л. 6,00.

Наклад 200 прим. Замовлення 1. Ціна вільна

Національний аерокосмічний університет ім. М. Є. Жуковського«Харківський авіаційний інститут»

61070, Харків-70, вул. Чкалова, 17 http://www.khai.edu

Видавець: ФОП Голембовська О.О.03049, Київ, Повітрофлотський пр-кт, б. 3, к. 32.

Свідоцтво про внесення суб’єкта видавничої справи в державний реєстр видавців, виготовлювачів і розповсюджувачів видавничої продукції

ДК №5120 від 08.06.2016

Віддруковано ТОВ «Юстон ЛТД»01034, м. Київ, вул. О. Гончара, 36-а

Тел. +38 044 360-2266, www.yuston.com.ua

Science and Informatics University of Žilina, Slovakia. · Тренинг Под...

Documents

Transcript of Science and Informatics University of Žilina, Slovakia. · Тренинг Под...