ДИПЛОМНА РАБОТА - SolidOpt

ППЛЛООВВДДИИВВССККИИ УУННИИВВЕЕРРССИИТТЕЕТТ ““ПП.. ХХИИЛЛЕЕННДДААРРССККИИ””

ФФААККУУЛЛТТЕЕТТ ““ММААТТЕЕММААТТИИККАА ИИ ИИННФФООРРММААТТИИККАА”” ККААТТЕЕДДРРАА ““ККООММППЮЮТТЪЪРРННИИ ССИИССТТЕЕММИИ””

ППЛЛООВВДДИИВВ 22001100

ДД ИИ ПП ЛЛ ОО ММ НН АА РРАА ББ ОО ТТАА

ТТЕЕММАА::

““SSOOLLIIDDOOPPTT –– ИИННССТТРРУУММЕЕННТТААРРИИУУММ ЗЗАА ААВВТТООММААТТИИЗЗИИРРААННИИ ООППТТИИММИИЗЗААЦЦИИИИ ННАА

ССООФФТТУУЕЕРРННИИ ППРРИИЛЛООЖЖЕЕННИИЯЯ.. ООППТТИИММИИЗЗААЦЦИИИИ,, ЗЗААВВИИССЕЕЩЩИИ ООТТ ППРРИИЛЛООЖЖННААТТАА ООББЛЛААССТТ””

ДДИИППЛЛООММААННТТ:: ВВААССИИЛЛ ГГЕЕООРРГГИИЕЕВВ ВВААССИИЛЛЕЕВВ

ННААУУЧЧЕЕНН РРЪЪККООВВООДДИИТТЕЕЛЛ:: ГГЛЛ.. ААСС.. ААЛЛЕЕККССААННДДЪЪРР ППЕЕННЕЕВВ

ССППЕЕЦЦИИААЛЛННООССТТ:: ССООФФТТУУЕЕРРННИИ ТТЕЕХХННООЛЛООГГИИИИ ФФААККУУЛЛТТЕЕТТЕЕНН ННООММЕЕРР:: 00990011440077001188

Съдържание ii

ССЪЪДДЪЪРРЖЖААННИИЕЕ УВОД ..................................................................................................................................................................................... 9 ВЪВЕДЕНИЕ ...................................................................................................................................................................... 11

2.1. ПРОБЛЕМИ ............................................................................................................................................................. 12 2.2. ЦЕЛИ ..................................................................................................................................................................... 15

ТЕОРЕТИЧНИ ОСНОВИ ............................................................................................................................................... 17 3.1. ОПТИМИЗАЦИЯ ..................................................................................................................................................... 17 3.2. ПРЕГЛЕД НА ВИРТУАЛНИ МАШИНИ ....................................................................................................................... 19

3.2.1 Системни виртуални машини................................................................................................................. 19 3.2.2 Процесни виртуални машини .................................................................................................................. 20

3.2.2.1. Common Language Infrastructure Virtual Execution System (CLR / Mono VM) ............................................. 23 3.2.2.1.1. Особености .............................................................................................................................................. 24

3.2.2.2. Java Virtual Machine (JVM) .............................................................................................................................. 26 3.2.2.2.1. Технологията HotSpot ............................................................................................................................. 27 3.2.2.2.2. Сигурност и валидност на клас файлове ............................................................................................... 27

3.2.2.3. Low-Level Virtual Machine (LLVM) ................................................................................................................. 28 3.2.2.4. Lua Virtual Machine ........................................................................................................................................... 29

3.2.2.4.1. Сравнение между Lua 4.0 и Lua 5.0 ....................................................................................................... 29 3.2.3 Сравнение между регистър-базирани ВМ и стек-базирани ВМ ......................................................... 29

3.3. ПРЕГЛЕД НА ТРАНСФОРМИРАЩИ И АНАЛИЗИРАЩИ СИСТЕМИ .............................................................................. 31 3.3.1 Средства за анализ на софтуера ........................................................................................................... 31

3.3.1.1. Bandera .............................................................................................................................................................. 32 3.3.1.2. Extended Static Checking (ESC)/Java ................................................................................................................ 33 3.3.1.3. FindBugs ............................................................................................................................................................ 33 3.3.1.4. JLint.................................................................................................................................................................... 34 3.3.1.5. PMD ................................................................................................................................................................... 34

3.3.2 Средства за трансформация на софтуера ........................................................................................... 35 3.3.2.1. Bartok & Singularity .......................................................................................................................................... 36 3.3.2.2. BARBER ............................................................................................................................................................ 38

3.3.3 Инструментариуми за разработка на трансформационни средства ............................................... 39 3.3.3.1. Phoenix ............................................................................................................................................................... 39 3.3.3.2. ATOM (Analysis Tools with OM) ...................................................................................................................... 40 3.3.3.3. Soot .................................................................................................................................................................... 40

3.4. ИЗВЕСТНИ ОПТИМИЗАЦИОННИ МЕТОДИ ............................................................................................................... 42 3.4.1 Автоматична паралелизация (Automatic Parallelization) ..................................................................... 42 3.4.2 Векторизация ........................................................................................................................................... 42 3.4.3 Елиминиране на проверките на границите (Bounds-Checking Elimination) ....................................... 42 3.4.4 Елиминиране на общите подизрази (Common Subexpression Elimination) .......................................... 42 3.4.5 Свиване и разпространение на константи (Constant Folding & Propagation) .................................. 43 3.4.6 Разпространение на копията (Copy Propagation) ................................................................................ 43 3.4.7 Елиминиране на “мъртъв код” (Dead Code Elimination) ..................................................................... 43 3.4.8 Глобално номериране (Global Value Numbering) .................................................................................... 44 3.4.9 Оптимизации, базирани на потребителския поток от данни и операции ........................................ 44 3.4.10 Оптимизации на обектно-ориентиран код ........................................................................................... 45

3.4.10.1. Вграждане на метод (Method Inlininig) ........................................................................................................... 45 3.4.10.2. Клониране на метод (Method Cloning) ............................................................................................................ 46 3.4.10.3. Разделяне на клас (Split Class) ......................................................................................................................... 47 3.4.10.4. Сливане на класове (Glue Classes) ................................................................................................................... 47 3.4.10.5. Премахване на делегати (Remove Delegate) ................................................................................................... 48 3.4.10.6. Премахване на шаблон “Посетител” (Remove Visitor) .................................................................................. 48

3.5. AРХИТЕКТУРНИ РЕШЕНИЯ ..................................................................................................................................... 49 3.5.1 Шаблони за дизайн................................................................................................................................... 49

3.5.1.1. Посетител .......................................................................................................................................................... 50 3.5.1.2. Композиция ....................................................................................................................................................... 51 3.5.1.3. Сек ..................................................................................................................................................................... 52

3.5.2 Архитектури, базирани на услуги (SOA)................................................................................................ 53 3.5.3 Архитектури, базирани на модели (MDA) ............................................................................................. 54

РЕАЛИЗАЦИЯ .................................................................................................................................................................. 56

Съдържание iii

4.1. СОФТУЕРЪТ КАТО МОДЕЛ ...................................................................................................................................... 56 4.1.1 Област на приложение ........................................................................................................................... 60

4.1.1.1. Общ домейн ...................................................................................................................................................... 61 4.1.1.2. Специфичен домейн ......................................................................................................................................... 62

4.2. ТРАНСФОРМАЦИИ ................................................................................................................................................. 64 4.2.1 Видове трансформации ........................................................................................................................... 64

4.2.1.1. Трансформации, променящи нивото на абстракция на модела .................................................................... 64 4.2.1.2. Трансформации, запазващи нивото на абстракция на модела ...................................................................... 65

4.2.2 Видове оптимизиращи трансформации ................................................................................................ 68 4.2.2.1. Еквивалентни оптимизации ............................................................................................................................. 69 4.2.2.2. Нееквивалентни оптимизации ......................................................................................................................... 69

4.3. ОПЕРАЦИОННА СРЕДА ........................................................................................................................................... 70 4.4. ЕВОЛЮЦИЯ НА МОДЕЛА ........................................................................................................................................ 73 4.5. ЕКСПЕРИМЕНТАЛЕН ИНСТРУМЕНТАРИУМ (SOLIDOPT) ......................................................................................... 77

4.5.1 Архитектура ............................................................................................................................................ 77 4.5.2 Услуги ........................................................................................................................................................ 79

4.5.2.1. Подсистеми ....................................................................................................................................................... 79 4.5.2.1.1. Подсистема за достъп до хетерогенни ресурси .................................................................................... 79 4.5.2.1.2. Кешираща подсистема ............................................................................................................................ 81 4.5.2.1.3. Конфигурираща подсистема................................................................................................................... 82 4.5.2.1.4. Уеб подсистема ........................................................................................................................................ 88 4.5.2.1.5. Подсистема за онлайн оптимизация ...................................................................................................... 89

4.5.2.2. Междумоделни трансформации ...................................................................................................................... 90 4.5.2.2.1. Ниво CIL .................................................................................................................................................. 90 4.5.2.2.2. Ниво CFG ................................................................................................................................................. 90 4.5.2.2.3. Ниво AST ................................................................................................................................................. 91

4.5.2.3. Оптимизационни трансформации (методи) ................................................................................................... 91 4.5.2.4. Оптимизационни методи на ниво CIL ............................................................................................................ 91

4.5.2.4.1. Премахване на nop инструкции ............................................................................................................. 91 4.5.2.4.2. Премахване на ovf инструкции .............................................................................................................. 92 4.5.2.4.3. Вграждане на метод ................................................................................................................................ 92

4.5.2.5. Оптимизационни методи на ниво CFG ........................................................................................................... 93 4.5.2.5.1. Елиминиране на “dead code” .................................................................................................................. 93

4.5.2.6. Оптимизационни методи на ниво AST ........................................................................................................... 93 4.5.2.6.1. Вграждане на метод ................................................................................................................................ 93 4.5.2.6.2. Свиване на константи ............................................................................................................................. 97

4.5.3 Използвани средства ............................................................................................................................... 99 4.5.3.1. dotNet ................................................................................................................................................................. 99 4.5.3.2. C Sharp ............................................................................................................................................................. 100 4.5.3.3. Common Intermediate Language ..................................................................................................................... 100 4.5.3.4. Mono.Cecil ....................................................................................................................................................... 101 4.5.3.5. Drupal ............................................................................................................................................................... 101 4.5.3.6. Контрол над версиите ..................................................................................................................................... 102 4.5.3.7. Система за автоматизирана компилация ....................................................................................................... 103 4.5.3.8. Документация ................................................................................................................................................. 104

БЪДЕЩО РАЗВИТИЕ .................................................................................................................................................... 105 5.1. ИНТЕГРИРАНЕ НА VMKIT ................................................................................................................................... 105

ЗАКЛЮЧЕНИЕ ............................................................................................................................................................... 106 ЛИТЕРАТУРА .................................................................................................................................................................. 108 ПРИЛОЖЕНИЯ ............................................................................................................................................................... 112

8.1. UML ДИАГРАМИ НА SOLIDOPT ............................................................................................................................112 8.1.1 UML диаграма на SolidOpt ..................................................................................................................... 112 8.1.2 UML диаграма на подсистема за достъп до хетерогенни ресурси ................................................... 113 8.1.3 UML диаграма на кешираща подсистема ............................................................................................ 114 8.1.4 UML диаграма на конфигурираща подсистема ................................................................................... 115 8.1.5 UML диаграма на разпознаване на типовете ...................................................................................... 115 8.1.6 UML диаграма на преименуване ............................................................................................................ 116 8.1.7 UML диаграма на прокси класове, използващи WSDL в подсистемата за онлайн оптимизация ... 116

8.2. МАТЕМАТИЧЕСКО OПТИМИРАНЕ ..........................................................................................................................117 8.2.1 Оптимизация без ограничения ............................................................................................................... 117

8.2.1.1. Функции на една променлива ......................................................................................................................... 117 8.2.1.2. Функции на n променливи .............................................................................................................................. 119

Съдържание iv

8.2.2 Оптимизация при налични ограничения .............................................................................................. 120 8.2.2.1. Ограничения с уравнения .............................................................................................................................. 120 8.2.2.2. Ограничения с неравенства ........................................................................................................................... 123

Списък на схемите v

ССППИИССЪЪКК ННАА ССХХЕЕММИИТТЕЕ Фигура 2-1: Схема на транслатор ....................................................................................................... 12 Фигура 2-2: Схема на оптимизиращ компилатор .............................................................................. 13 Фигура 2-3: Схема на хибриден компилатор ..................................................................................... 13 Фигура 3-1: Схема на модела на състояние на пВМ CLR ................................................................ 25 Фигура 3-2: Схема на състояние на метод ......................................................................................... 25 Фигура 3-3: Архитектурата на Bartok ................................................................................................. 37 Фигура 3-4: Клас-диаграма на “Посетител” ...................................................................................... 51 Фигура 3-5: Клас-диаграма на “Композиция” ................................................................................... 52 Фигура 3-6: Клас-диаграма на “Сек” .................................................................................................. 52 Фигура 4-1: Взаимодействия между моделите .................................................................................. 59 Фигура 4-2: Общ и специфичен домейн ............................................................................................ 60 Фигура 4-3: Връзка между домейните и нивата на абстракция ....................................................... 61 Фигура 4-4: Концептуален идеален вид на фреймуорка .................................................................. 63 Фигура 4-5: Рефакторинг/Разбъркване ............................................................................................... 65 Фигура 4-6: Пример за нееквивалентна трансформация I клас ....................................................... 67 Фигура 4-7: Пример за нееквивалентна трансформация II клас ...................................................... 68 Фигура 4-8: Абстрактна операционна среда ...................................................................................... 70 Фигура 4-9: Операционна среда.......................................................................................................... 70 Фигура 4-10: Специализация на програмата ..................................................................................... 74 Фигура 4-11: Еволюция на програмата .............................................................................................. 75 Фигура 4-12: Схема на начина на използване на подсистемите ...................................................... 78 Фигура 4-13: Схема на абстрактното взаимодействие между ядрото и услугите на SolidOpt ..... 78 Фигура 4-14: Схема предаване на управлението от ядрото към услугите ...................................... 79 Фигура 4-15: Схема на подсистема за хетерогенен достъп (ПХД) до ресурси .............................. 80 Фигура 4-16: Схема на кешираща подсистема .................................................................................. 81 Фигура 4-17: Схема на действието на кеширащата подсистема ...................................................... 82 Фигура 4-18: Схема на действието на конфигурираща подсистема ................................................ 86 Фигура 4-19: Действие на подсистемата за онлайн оптимизация ................................................... 89 Фигура 4-20: Текущо развитие на инструментариума SolidOpt ...................................................... 90 Фигура 4-21: Важни слоеве в Drupal ................................................................................................ 102 Фигура 4-22: Основни етапи на разработка в SVN хранилището ................................................. 103 Фигура 4-23: Система за автоматизирана компилация BuildBot ................................................... 104 Фигура 8-1: Графично представяне на ( )f x ................................................................................... 117 Фигура 8-2: Неактивни ограничения ................................................................................................ 124 Фигура 8-3: Функция с ограничение ................................................................................................ 126

Списък на таблиците vi

ССППИИССЪЪКК ННАА ТТААББЛЛИИЦЦИИТТЕЕ Таблица 3-1: Сравнение на процесни виртуални машини ............................................................... 22 Таблица 3-2: Анализиращи инструменти ........................................................................................... 32 Таблица 3-3: Пример за елиминиране на общите подизрази ........................................................... 42 Таблица 3-4: Пример за свиване на константи .................................................................................. 43 Таблица 3-5: Пример за разпространение на константи ................................................................... 43 Таблица 3-6: Пример за разпространение на копията ...................................................................... 43 Таблица 3-7: Пример за “мъртъв код” ................................................................................................ 44 Таблица 3-8: Пример за глобално номериране .................................................................................. 44 Таблица 3-9: Пример за вграждане на подпрограма ......................................................................... 46 Таблица 3-10: Пример за клониране на подпрограма ....................................................................... 47 Таблица 4-1: Сравнение на бързодействието на конфигурационната подсистема ........................ 88 Таблица 4-2: Пример за премахване на nop инструкции .................................................................. 92 Таблица 4-3: Пример за вграждане на програма на ниво CIL .......................................................... 93 Таблица 4-4: Пример за вграждане на програма на ниво AST (като сорс код) ............................... 96 Таблица 4-5: Пример за вграждане на програма на ниво AST (като дърво) ................................... 97 Таблица 4-6: Пример за свиване на константи .................................................................................. 98

Използвани съкращения vii

ИИЗЗППООЛЛЗЗВВААННИИ ССЪЪККРРААЩЩЕЕННИИЯЯ

АА

АПК Абстрактен Програмен Модел

ВВ

ВИМ Виртуално Изчислителна Машина

ВМ Виртуална Машина

ВП Външна памет

ДД

ДО Дефиниционна Област

ЕЕ

ЕП Език за Програмиране

ИИ

ИТ Информационни Технологии

КК

КПМ Конкретен Програмен Модел

КС Компютърна Система

ММ

МНМК Метод на Най-Малките Квадрати

ОО

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

ПП

ПО Проблемна Област

ПХД Подсистема за Хетерогенен Достъп

пВМ Процесна Виртуална Машина

AA

API Application Programming Interface

AOT Ahead Of Time

AST Abstract Syntax Tree

CC

C# C Sharp

CIL Common Intermediate Language

CFG Control Flow Graph

CLR Common Language Runtime

CMF Content Management Framework

CMS Content Management System

CTS Common Type System

EE

ECMA European Computer Manufacturers

Association

GG

GUI Graphical User Interface

HH

HIR High-level IR

II

IR Intermediate Representation

Използвани съкращения vii

JJ

JIT Just-In-Time

JVM Java Virtual Machine

LL

LIR Low-level IR

LLVM Low-Level Virtual Machine

MM

MDA Model-Driven Architecture

MIR Medium-level IR

MSIL MicroSoft Intermediate Language

OO

OMG Object Management Group

SS

SOA Service-Oriented Architecture

SOAP Simple Object Access Protocol

SSA Static Single Assignment

UU

UI User Interface

UML Unified Modeling Language

VV

VES Virtual Execution System

WW

WSDL Web Services Description Language

Благодарности viii

ББЛЛААГГООДДААРРННООССТТИИ Благодаря на ръководителя ми във ФМИ на ПУ Александър Пенев, който въпреки

разстоянието намираше и отделяше време за съвети, препоръки и идеи.

Благодаря на ръководителя ми в PH/SFT на CERN Axel Naumann за напътствията и

подкрепата, която ми оказваше през цялото време.

Увод Стр. 9 от 126

11.. УУВВООДД

Дипломната работа е от областта на дизайна и реализацията на езици за програмиране

(Programming Language Design and Implementation). Подобластта е автоматизирано

оптимизиране на софтуерни приложения.

Целта на дипломната работа е да се изгради прототип на общ инструментариум,

съдържащ средства за автоматизирано оптимизиране на софтуерни системи, без

модифициране на техния сорс код. Заедно с това да се покаже моментното развитие на

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

внимание се обръща на домейн-ориентираните оптимизации.

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

• Глава 1: “Увод”;

• Глава 2: “Въведение” въвежда в проблемната област, като описва възникването на

проблема за неоптималното компилиране на програмите. Описва също устройството

на различните видове транслатори. Формулира примерно решение на поставения

проблем, съобразявайки се с целите на дипломната работа;

• Глава 3: “Теоретични основи” описва известни средства, които в малка или по-голяма

степен могат да се приложат за постигане на целите. Описани са както подходи,

подпомагащи изграждането на добра архитектура, така и известни средства за

оптимизация. Изброени са известни оптимизационни методи. Разгледани са няколко

вида виртуални машини;

• Глава 4: “Реализация” описва постигнатото по време на процеса на разработка.

Главата условно може да се раздели на две части – формална и реализационна.

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

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

теоретичните твърдения са постижими. Също така показва, че поставените цели са

постигнати;

• Глава 5: “Заключение” анализира постиженията;

• Глава 6: “Литература” описва подробно използваната литература. Цитирани са само

Увод Стр. 10 от 126

официални източници под формата на: лекции, провеждани във ФМИ на ПУ; статии,

публикувани на общопризнати конференции; книги; спецификации и официални уеб

сайтове на разработчиците на конкретните технологии.

• Глава 7: “Приложение” показва UML диаграмите на компонентите на

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

при анализа на производителността на компютърната система.

Въведение Стр. 11 от 126

22.. ВВЪЪВВЕЕДДЕЕННИИЕЕ

Трудно е да се постигне висока производителност (оптималност) на софтуера от някаква

гледна точка (бързодействие, например), особено при разработка на големи софтуерни системи

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

различни насоки и по различно време от жизнения цикъл на системата. Почти всяка техника,

обаче, се нуждае от намеса на разработчик, за да бъдат осъществени необходимите корекции.

Факт е, че върху оптималността на софтуера влияят много фактори. Голяма част от

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

повечето го правят по време на определени етапи от цикъла на разработка.

След малко по-задълбочено изследване на слабо свързани системи и такива с добър дизайн,

лесно се достига до извода, че тези предимства пораждат сериозен недостатък. Както вече

установихме в [1] добрата архитектура води до намаляване на бързодействието на

приложенията. Реализацията на ясни и обозрими архитектури понякога предполага логическо

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

класове, повече обекти и следователно повече машинни инструкции. Това респективно оказва

влияние върху времето за изпълнение и заеманата памет от програмата както и в някои случаи –

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

Оптимизацията представлява повишаване на ефективността на целевото приложение (в

общия случай – да бъдат използвани възможно най-малко ресурси на КС). Повишаването на

ефективността се извършва основно по два начина:

• Хардуерен – замяна на хардуерните компоненти на КС с нови, по-производителни.

Хардуерното оптимизиране е лесно за реализиране, но е ограничено от природните

закони и развитието на технологиите;

• Софтуерен – създаване на по-оптимални компютърни програми или оптимизиране на

вече съществуващи.

Софтуерната оптимизация е предмет на разглеждането. Съществуват два вида софтуерни

оптимизации от гледна точка на начина на извършването им:

• “Ръчна” – този вид оптимизация е много трудоемка задача. Тя включва събиране на

информация как действа системата и продължителни тестове за ефективност и


коректност на направените промени. Голяма част от този тип оптимизации са само по

един критерии, защото е трудно човек да съобрази толкова много параметри, да

търси евентуална корелация между тях и да тества и оценява постигнатия ефект;

• Автоматизирана – този вид оптимизация включва прилагането на разнородни

оптимизационни методи от друга софтуерна система върху програмата. Методите

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

трансформираната програма (като при транслаторите, например).

2.1. ПРОБЛЕМИ ”Програмният език е нотация, чрез която хората описват изчисленията, които трябва да бъдат

изпълнени от машината. Голяма част от човешкото познание и практика зависи от програмните

езици, защото всичкият софтуер за всички компютри е написан на някакъв програмен език. Но

преди да се изпълни дадена програма, тя трябва да се транслира във форма, изпълнима от

компютър. Софтуерните системи, които извършват тази дейност се наричат транслатори.” [2]

Фигура 2-1: Схема на транслатор

При транслиране на програмата, компилаторите произвеждат изпълним код, който се записва

и не е необходимо при следващо стартиране нова компилация. Интерпретаторите са друг вид

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

операциите описани в сорс кода на транслираната програма. Компилираните програми

обикновено са много по-бързи от интерпретираните. Интерпретаторите, обаче, обикновено

дават по-добра диагностика на кода от компилаторите, защото го изпълняват ред по ред.

Трябва да се отбележи, че не винаги компилаторите произвеждат оптимален изпълним код.

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

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

код) от компилатора. При по-големи системи производството на неоптимален код се отразява

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

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

предварително зададени оптимизации. Компилатори, съдържащи такива модули се наричат

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

Например, оптимизация за бързина на изпълнение и др.


Фигура 2-2: Схема на оптимизиращ компилатор

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

Оптимизиращият модул прилага различни оптимизационни методи върху междинното

представяне. Голяма част от компилаторите имат и оптимизиращ модул по-време на и след

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

платформено-независими оптимизации, а тези по време на генерация на код – платформено-

зависими.

Генераторът на код произвежда машинния код за изпълнителя.

Недостатъците на прилаганите от компилатора оптимизации биват:

• Статичният им характер – прилагат се само веднъж по време на компилация;

• Общият им характер – не обхващат специфични за конкретната приложна област

знания;

• Вградеността им в транслатора – не могат да бъдат лесно разширявани от

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

Съществува и комбинация от компилатор и интерпретатор, която се нарича “хибриден

компилатор”. Хибридните компилатори представляват комбинация от транслиращ механизъм,

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

последствие бива интерпретирана от виртуална машина.

Фигура 2-3: Схема на хибриден компилатор


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

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

виртуалната машина.

Стъпка в увеличаването на бързодействието на хибридните компилатори са така наречените

just-in-time компилатори, които заменят интерпретиращият механизъм във виртуалната машина.

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

изходен файл, който се изпълнява много по-бързо от КС. Съвременните JIT компилатори не

компилират цялата програма, а само необходимите в момента части от нея. Прилаганите

оптимизации от JIT компилаторите имат дори от още едно сериозно ограничение – изискване за

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

значително JIT компилацията.

Поради нарастващите нужди и изисквания на клиентите се забелязва тенденцията на

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

характеристики на системата, при които тя работи най-добре спрямо нуждите на крайния

потребител. Добра стратегия за постигане на целта е автоматизираното оптимизиране на

приложенията чрез използването на общ инструментариум.

Нека приемем, че не всеки софтуерен разработчик знае точната методология на транслация

на програмата от сорс до изпълним код. В такъв случай той не би могъл да създаде оптимална

софтуерна система, още повече че това зависи и до голяма степен от архитектурата ВИМ. С

други думи, един и същ код може да се оцени с различен коефициент на оптималност за

различните архитектури ВИМ.

Дори разработчикът да знае методологията на транслиране може да се окаже, че оптималната

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

използвания транслатор.

Съществуват различни видове статични оптимизации, които намаляват проблема с

използването на повече ресурси, но това не предлага задоволително решение. Много от

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

изходния (сорс) код или на обектния код на програмата. Статичният анализ се извършва, без да

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

програмата, например сорс код или обектен код. Различните видове статичен анализ дават мета-

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

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

желаната цел, но е и сериозно ограничение, защото мета-знанията не винаги биват еднозначни и

коректни. Ако бъде приложена оптимизация, базирана на грешни заключения това не би довело


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

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

действие и приложимост на техниката. Друга слабост на този механизъм е, че поради

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

не могат да се изменят по усмотрение на разработчика. Също така е почти невъзможно да се

оптимизира с коефициенти на критериите, например 20% от максималното постижимо

бързодействие и 80% от минималния постижим разход на памет.

Рефакторингът [3] е статичен процес, който променя софтуерната система, без да изменя

поведението й, като повишава качеството на вътрешната й структура. Той също се базира на

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

постигне добра логическа свързаност на кода източник, което впоследствие би довело до

генерацията на по-оптимален машинен код за ВИМ, но много често се постига обратен ефект.

Посочените видове решения не са достатъчно изчерпателни и не решават напълно проблема

със създаването на неоптимални софтуерни приложения. Решенията имат редица ограничения

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

2.2. ЦЕЛИ Разумно решение на поставените проблеми е разработката на инструментариум (фреймуорк),

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

оптималност на програмите, разнообразни видове оптимизационни методи, подсистема за

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

Основните предимства на инструментариума са:

• Отделеност от транслатора – така се постига по-добра независимост и гъвкавост,

защото оптимизационните методи могат да се разширяват от потребителя, както и да

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

били валидни в общия случай;

• Намиране на по-добри метазнания – с течение на времето, данните, събирани от

анализатора стават все по-точни (директно следствие от закона за големите числа);

• По-добри евристични функции – директно следствие от горното;

• Конфигурируемост – всичко ще може да бъде конфигурирано от потребителя,

съгласно неговите конкретни нужди;

• Използване на многомоделни представяния на различно ниво на абстракция за

улеснение на оптимизационните методи.

Инструментариумът предполага няколко потребителски роли:


• Роля “Разработчик” – разработчикът използва фреймуорка по време на разработка, за

да постигне оптималност на програмата (със знанието за наличието на фреймуорка,

действието му и програмния модел);

• Роля “Интегратор” – интеграторът използва инструменти, разработени на базата на

фреймуорка, за да оптимизира вече реализираната програма (интеграторът не “знае”

програмния модел и концепцията на програмата);

• Роля “Краен потребител” – крайният потребител използва инструменти, базирани на

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

оптимизации. Може да се използва статистика за потребителя, събирана по време на

изпълнението за допълнителна персонализация на приложението.

Характеристики, които са приоритет при разработката:

• Общоприложимост – основополагащите концепции и принципи трябва да са

приложими върху широк набор от приложни области;

• Отвореност – способността на инструментариума да бъде разширяван в едно или

повече направления;

• Разширимост – способността да бъде добавяна нова функционалност чрез модули;

• Гъвкавост – лесното адаптиране към различни приложни области;

• Слаба свързаност и модулност – слабата свързаност повишава възможността даден

клас да бъде използван самостоятелно и позволява дадената система да бъде

изследвана, променяна и разширявана. Модулността е реализационният аспект на

слабата свързаност.

Целта на дипломната работа е да се изгради прототип на общ инструментариум,

съдържащ средства за автоматизирано оптимизиране на софтуерни системи, без

модифициране на техния сорс код. Заедно с това да се покаже моментното развитие на

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

внимание се обръща на домейн-ориентираните оптимизации.

Теоретични основи→Оптимизация Стр. 17 от 126

33.. ТТЕЕООРРЕЕТТИИЧЧННИИ ООССННООВВИИ

3.1. ОПТИМИЗАЦИЯ Оптимизационните проблеми възникват естествено в много различни дисциплини.

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

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

която е колкото може по-евтина. Агрономът, ръководещ дадена плантация трябва да планира

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

нужди на клиентите с минимални средства. В примерите се забелязват три основни цели:

1. Има крайна цел. За архитекта крайната цел е да минимизира разходите за построяване

на сградата. За агронома крайната цел е да максимизира добива;

2. В допълнение към крайната цел обикновено има изисквания или ограничения, които

трябва да бъдат изпълнени. Архитектът трябва да изпълни стандартите за безопасност,

а агрономът трябва да задоволи нуждите на клиентите като се съобрази с наличната

работна сила и ограничените материали;

3. Косвено във всички ситуации е идеята, че има възможност за избор и ако е направен

успешно ще бъде изпълнена крайната цел и изискванията едновременно. Изборите се

наричат оптимизация или избор на (design) променливи [4].

Става ясно, че неформалната формулировка на оптимизацията включва избиране на една или

повече оптимизационни променливи; избиране на целева функция; определянето на

множеството от ограничения.

В математиката, терминът оптимизация или математическо оптимиране (mathematical

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

максималната стойност на реална функция, като систематично се избират реални или цели

стойности от зададено множество.

Оптимизационна задача може да се представи по следния начин:

Дадено: функция :f A R→ от някакво подмножество A на реалните числа

Търси се: елемент 0x в A, такъв, че 0( ) ( )f x f x≤ за всички стойности на x в A

("минимизация") или 0( ) ( )f x f x≥ за всички стойности на x в A ("максимизация").

Теоретични основи→Оптимизация Стр. 18 от 126

Обикновено A е някакво подмножество на Евклидовото пространство nR , което често е

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

трябва да удовлетворят. Областта A на f се нарича пространство на търсене (search space),

докато елементите на A се наричат кандидат решения или възможни решения (feasible solutions).

Функцията f се нарича целева функция. Възможно решение, което минимизира (или

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

За основите на математическото оптимиране виж “Математическо oптимиране” в

“Приложения”.

Под оптимизация на компютърна програма ще разбираме подобряване на

характеристики (една или повече), които са количествено измерими с предварително

дефинирани математически функции.

Измерването на характеристики на компютърните програми с функции (метрики) позволява

прилагането на описания по-горе математически апарат.

Теоретични основи→Преглед на виртуални машини Стр. 19 от 126

3.2. ПРЕГЛЕД НА ВИРТУАЛНИ МАШИНИ Терминът виртуална машина е първоначално дефиниран от Popek и Goldberg като

“ефективно, изолирано копие на реална машина”[5]. Настоящото използване на термина

виртуална машина (ВМ) включва дори ВМ, които нямат директно съответствие с реален

хардуер. Важно е да се отбележи, че софтуерът, изпълняван във ВМ е ограничен от ресурсите и

абстрактните представяния, предоставени от конкретната ВМ. С други думи софтуерът е

изолиран в неговия виртуален свят.

Известни са две различни интерпретации на термина ВМ, чиито значения са близки, но не

еднакви[6].

3.2.1 СИСТЕМНИ ВИРТУАЛНИ МАШИНИ Системните ВМ (понякога наричани хардуерни ВМ) позволяват разпределяне на хардуерните

ресурси на КС между различните ВМ, всяка от които би могла да използва различна ОС.

Системните ВМ емулират реална хардуерна система. Целта на системната ВМ е да наподобява

възможно най-много дадена реално съществуваща.

Софтуерният слой, предоставящ виртуализацията се нарича хипервайзор (hypervisor).

Хипервайзорът може да бъде инсталиран директно върху хардуера (тип 1) или да бъде

инсталиран върху ОС (тип 2).

Основните предимства на този тип ВМ са:

• Множество ОС могат съвместно да съществуват на една физическа машина в силна

изолация помежду си;

• ВМ може да предоставя различна архитектура (Instruction Set Architecture). Това

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

на реалната машина.

• Счита се, че чрез използване на системни ВМ в замяна на реални КС се намалява

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

[7].

Съществуват редица технологии, подпомагащи виртуализацията на КС. Те се класифицират

по степента си на виртуализация: пълна виртуализация, частична виртуализация,

паравиртуализация, хардуерно поддържана виртуализация[8][9][10][11].

Основен недостатък остава производителността. Целта на различните видове виртуализация

е да редуцират разликите в производителността на ВМ и аналогичната й реална машина

[9][10][11].


3.2.2 ПРОЦЕСНИ ВИРТУАЛНИ МАШИНИ Процесните виртуални машини (пВМ) (понякога наричани програмни ВМ) се изпълняват

като обикновени приложения в ОС и виртуализират само изпълнението на един процес.

Процесната ВМ се създава, когато виртуализираният процес се стартира и преустановява

действието си, когато виртуализираният процес приключи изпълнението си. Много често за

тази цел, пВМ използват концепцията за междинно представяне на приложенията, наречено by-

tecode или bitcode. Междинното представяне позволява на пВМ е да предостави платформено-

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

ОС. На теория приложенията би трябвало да се изпълняват по един и същ начин на различните

платформи.

Една от класификациите на пВМ се основава на броя операнди в инструциите:

• 0 операнда – стек-базирани машини;

• 1 операнд – акумулатор-базирани машини;

• 2 или 3 операнда – регистър-базирани машини

Следователно може да се каже, стек-базираните пВМ имат най-висока плътност на кода.

Съвременните пВМ биват регистър-базирани или стек-базирани. Стек-базираните имат стек

с аргументи, който стек не трябва да бъде бъркан със стек-фрейма. При изпълнение на операция

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

резултатът се записва отново в стека. При регистър-базираните пВМ вместо стек се използват

регистри за съхранение на данните.

Спорен е въпросът коя архитектура е по-ефективна. Регистър-базираните пВМ могат да

намалят значително броя на необходимите инструкции (не се нуждаят от инструкции за

манипулиране на стека), но извличането на аргументите се счита за по-неефективен (регистрите

трябва да бъдат определени, което води до повече код). При стек-базираните пВМ наборът

инструкции е по-голям, но извличането на аргументите е много по-ефективно (знае се размерът

на отместването от указателя, сочещ върха на стека)[12].

Известни са няколко стратегии за изпълнение на код в пВМ:

• Интерпретация – най-широко използвана, интерпретацията на кода означава, че той

се компилира до машинен код ред по ред (или сегмент по сегмент) по време на

изпълнението на виртуализираното приложение. Използването на интерпретацията

се счита, че е по-бавно, но използва значително по-малко памет;

• Компилация по време на изпълнение (JIT compilation) – повишава

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

код[14]. Това води до повишаване на ефективността, но често забавя стартирането и


използва повече памет. При компилацията по време на изпълнение е важно да се

отбележи, че не компилира цялото междинно представяне на пВМ, а само частите,

които удовлетворяват евристиката в компилатора[15]. Например; при стартиране на

приложението могат да бъдат компилирани методите, които ще се използват най-рано

или тези, които ще се използват най-често и т.н;

• Преждевременна компилация (Ahead of time compilation) – междинното представяне

на пВМ се компилира до машинен код от КС, която ще изпълнява приложението[16].

Компилацията се извършва на целевата машина, което позволява да се включат

всички възможни оптимизации, приложими в конкретния случай. Аналогично на JIT

компилацията при AOT компилацията се следва евристика за каква част от

междинното представяне да бъде компилирана[17].

Поради тези причини съществуват различни реализации на пВМ, които са показани на

Таблица 3-1

Този тип ВМ е особено важен за настоящата дипломна работа.

Теор

етич

ни о

снов

и→П

регл

ед н

а ви

ртуа

лни

маш

ини

С

тр.

22

от 1

26

пВМ

М

одел

У

прав

лени

е на

пам

етта

С

игур

ност

на

код

а И

нтер

прет

атор

JI

T

Пре

двар

ител

на

ком

пила

ция

Общ

и би

блио

теки

О

бщ о

бект

ен

мод

ел н

а ез

ика

Дин

амич

но

типи

зира

не

CL

R

стек

ав

том

атич

но

или

ръчн

о � ��

� ��

� ��

� ��

� ��

� ��

� ��

Mon

o ст

ек

авто

мат

ично

или

ръчн

о � ��

� ��

� ��

� ��

� ��

� ��

� ��

LLV

M

реги

стър

ръ

чно

� ��

� ��

� ��

� ��

� ��

� ��

� ��

JVM

ст

ек

авто

мат

ично

� ��

� ��

� ��

� ��

� ��

� ��

� ��

Lua

5.0

реги

стър

ав

том

атич

но

или

ръчн

о ?

� ��

� ��

� ��

? � ��

?

Lua

4.0

стек

ав

том

атич

но

или

ръчн

о ?

� ��

� ��

� ��

? � ��

?

Табл

ица

3-1:

Сра

внен

ие н

а пр

оцес

ни в

ирт

уалн

и м

ашин

и


Управление на паметта – в тези пВМ адресирането на паметта става на по-високо ниво на

абстракция в сравнение с реалните физически КС. Някой от пВМ като JVM изискват

предоставяне на проследими указатели (аритметика с указатели не е позволена). Други пВМ по-

близки до реалните КС като LLVM позволяват директно използване и манипулиране с

указатели. Трети като CLR/Mono позволяват контролирано адресиране (safe automatic memory

management) и небезопасно адресиране (unsafe memory management).

Сигурност на кода – основно се отнася до възможността на пВМ да изпълнява кода като

ограничава обхвата му. Например, пВМ може да позволи на кода достъп само до определено

множество инструкции или данни. На практика се използват същите алгоритми, чрез които се

контролира управлението на паметта.

Интерпретатор – пВМ позволява на приложенията, съставени от виртуални инструкции да

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

JIT – отнася се до компилация на виртуалните инструкции в най-късния възможен момент.

Това е обикновено преди стартиране или по време на изпълнение на приложението.

Предварителна компилация – отнася се до това дали приложението съдържа фрагменти,

компилирани до машинен код. Предимството е, че подпомага стартирането особено когато JIT

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

Общи библиотеки – представляват средства за преизползване на общ код по време на

изпълнение от много приложения.

3.2.2.1. Common Language Infrastructure Virtual Execution System (CLR / Mono VM)

Преди обзора трябва да се отбележи разликата между CLI VES, CLR и Mono VM. CLI VES

представлява спецификация на ECMA [60] за обща среда за изпълнение (пВМ), а CLR и Mono

са съответните реализации на респективно Microsoft и Novell.

Common Language Infrastructure (CLI) [60] предлага спецификация за изпълним код и за

средата, която го изпълнява. Изпълнимият код е представен във пВМ като модули. Модул е

отделен файл, съдържащ изпълним код. В основата на CLI е обединената система типове–

Common Type System (CTS), която е обща за компилатори, инструменти и за самата CLI. CTS е

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

управлява типове. CTS формира фреймуорк, който реализира съвместимостта между различни

ЕП, типовата безопасност и високоскоростното изпълнение на код.

CLI се състои от:

• Common Type System (CTS) – осигурява богата система от типове, която поддържа


голяма част от типовете и операторите, намиращи се в други ЕП. CTS е проектиран

да поддържа пълната реализация на широк набор от ЕП;

• Метаданни – CLI използва метаданни, за да опише и достъпи типовете, дефинирани

от CTS. Тези метаданни са съхранени по начин, независим от всеки ЕП. Така

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

както между инструментите (компилатори и дебъгери), които манипулират

програмите, така и между тези инструменти и пВМ;

• Common Language Specification (CLS) – може да се нарече споразумение между

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

множество от конвенции за използване;

• Виртуално изчислителната машина или пВМ(VES) – реализира и прилага строго

модела CTS. пВМ е отговорна за зареждането и изпълнението на програми, написани

за CLI. Тя осигурява услугите и данните необходими, за да се изпълни управлявания

код. Метаданните се използват, за да се свържат отделно генерираните модули по

време на изпълнение (late binding).

Заедно, тези аспекти на CLI, формират обединена основа за проектиране, разработване,

внедряване и изпълняване на разпределени компоненти и приложения. Подходящото

подмножество на CTS е на разположение на всеки език за програмиране, който поддържа CLI.

3.2.2.1.1. Особености

Една от основните цели на CLI е да “скрие” детайлите на стек фрейма от генератора на код.

Това позволява на CLI (а не на генератора на код в CLI) да избере най-ефективната конвенция за

предаване на параметри и най-доброто разположение на стека. За да се постигне тази

абстракция, стек фрейма на извикванията е интегриран в CLI. Това е и причината състоянията

на пВМ да бъдат основно:

• Глобално състояние;

• Състояние на метод.

CLI може да управлява: много контролни нишки (thread of control) (не е задължително да са

същите, които са предоставени от ОС); много управляеми хийп сегменти (heaps) и споделено

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

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

текущото състояние при срещане на инструкция за извикване на метод.

Фигура 3-1 илюстрира модела на пВМ, който включва контролни нишки, състояния на

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


Фигура 3-1: Схема на модела на състояние на пВМ CLR

Състоянието на метод показано отделно на Фигура 3-2 като абстракция на стек фрейма.

Аргументите и локалните променливи са част от състоянието на метода, но могат да съдържат

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

сегменти. Аргументите и локалните променливи са “видими” само за нишката изпълнител,

докато инстанциите, статичните полета и елементите на масиви могат да бъдат “видими” за

повече нишки. Модификацията на елементи, видими от повече от една нишка се счита за

страничен ефект.

Фигура 3-2: Схема на състояние на метод


Състоянието на метод описва средата, в която всеки метод се изпълнява (ако се използва

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

от стек фрейма на извикванията). Състоянието на метод се състои от:

• Програмен брояч (Instruction Pointer – IP) – винаги сочи към следващата инструкция,

която ще бъде изпълнена;

• Стек (evaluation stack) – празен при началото на метод. Неговото съдържание е

изцяло локално за метода, който се изпълнява в момента. При извикване на метод

стека се запазва. Например, ако дадения метод извика друг метод и когато втория

метод върне резултат, съдържанието на стека е такова каквото е било преди

извикването му плюс евентуално резултатът от извикания метод;

• Масив с локалните променливи (започващ с индекс 0) – стойностите на локалните

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

Локалните променливи могат да съдържат произволен тип данни;

• Масив с аргументите (започващ с индекс 0) – стойностите на параметрите на

текущия метод;

• MethodInfo обект – съдържа информация за метода като сигнатура, типовете на

локалните променливи и данните за обработката на изключенията;

• Local Memory Pool – съдържа инструкции за динамично заделяне на обекти;

• Return State – използва се за възстановяване на състоянието на метода при изход от

текущия метод. Обикновено съдържа състоянието на извикващия метод (отговаря на

динамична връзка (dynamic link) при традиционните компилатори);

• Security descriptor – не е директно достъпен от управляемия код, но се използва от

подсистемата за сигурност на CLI, за да записва предефинирани директиви за

сигурност (assert, permit-only и deny).

3.2.2.2. Java Virtual Machine (JVM)

Java Virtual Machine е стек-базирана пВМ[18]. За изпълнение на приложения JVM предоставя

хибрид между JIT компилация и интерпретация. Основната цел на JVM е да предостави

платформена независимост на междинното си представяне (Write once run anywhere).

Градивна единица в междинното представяне на JVM е клас форматът (class file format). Не

трябва да се счита, че съответствието между клас форматът и класовете в ЕП Java е едно към

едно. Междинното представяне на JVM не е пряко обвързано с ЕП Java, но е свързано с

обектно-ориентираната парадигма[18].


3.2.2.2.1. Технологията HotSpot

Реализациите на JVM, поддържащи технологията HotSpot[19] имат предимството да

използват хибриден подход при изпълнението на приложенията. Хибридният подход

представлява JIT компилация, където е необходимо, а където не е – интерпретация.

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

известен при JIT компилацията. Известно е, че интерпретацията е за предпочитане пред JIT

компилацията, когато дадените сегменти от приложението се изпълняват не много често. Също

така се съхранява и пространство, защото не е необходимо да се записва нещо на ОП или ВП.

Ако JVM HotSpot идентифицира сегмент от междинното представяне, който се използва

често, то той се JIT компилира.

3.2.2.2.2. Сигурност и валидност на клас файлове

ЕП Java се използва в интернет в аплети и сървъри за приложения[20]. Java аплетът

позволява на потребителя да стартира инстанция на JVM в уеб браузър и да получи динамично

съдържание. Междинно представяне, обаче, от неизвестен източник в глобалната мрежа

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

JVM прави проверки в междинното представяне преди да го изпълни. Основни проверки са:

• Проверки на структурата на междинното представяне;

• Проверки, независещи от потока данни;

• Проверки на последователността от данни;

• Проверки на символи.

Първоначално междинното представяне-кандидат се проверява за структурна цялостност.

JVM проверява за магическите битове (magic bits) в началото на файла (0xCAFEBABE) и дали

версията на междинното представяне е съвместима с конкретната реализация на JVM. Файлът

също се проверява дали е правилно терминиран, като се анализира дали има допълнителни

байтове след края и др.

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

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

области на видимост (Например дали някой клас, дефиниран като final не е наследен).

Следваща стъпка е анализът на потока от данни, при който се определя дали използването на

символите е след техните декларации.

Накрая се проверяват дали всички референции са валидни.

Описаният по-горе процес на валидация е превантивна мярка срещу чужд (евентуално

злонамерен) код и същевременно демонстрира ограничение върху кода, наложено от пВМ с цел


повишаване на сигурността.

3.2.2.3. Low-Level Virtual Machine (LLVM)

Low level virtual machine (LLVM) е едновременно регистър-базирана пВМ и фреймуорк за

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

разработка на ЕП от средно и високо ниво. Една от задачите пред пВМ LLVM е да предостави

инфраструктура, позволяваща анализ и оптимизация на произволни приложения.

Основна разлика между LLVM и разгледаните пВМ е, че тя е от по-ниско ниво на

абстракция. Това означава, че LLVM е съвместима с останалите, а не е тяхна алтернатива.

Аналогично на останалите пВМ, междинното представяне в LLVM е независимо от сорс кода

и се характеризира с:

• Използването на набор от инструкции от ниско ниво, които са малко по-абстрактни

от тези на асемблерните езици;

• Използването на модел на паметта, който е малко по-абстрактен от този на

физическата КС и ЦП;

• Не се налагат изисквания за средата на изпълнение (runtime);

• Не се налагат изисквания за семантиката на приложенията.

Голяма част от разликите на LLVM с другите пВМ произхождат от различното им ниво на

абстракция:

• LLVM няма нотация за конструкции от високо ниво като: класове, наследяване или

управление на изключенията дори когато ЕПВН ги позволяват;

• LLVM не определя околната среда за изпълнение (runtime) и конкретен обектен

модел;

• LLVM не гарантира сигурност на типовете и паметта;

• LLVM не обезпечава взаимооперативността между ЕП повече от асемблерните езици

и ЦП;

• LLVM предоставя стандартни API функции и генератор за код, които са подпомагат

разработката на различни компилатори;

• LLVM предоставя оптимизиращ фреймуорк, който поддържа широк набор от

платформи;

• LLVM предоставя средства за профайлинг.

Качествата на пВМ като LLVM са безспорни. Интегрирането на подобна пВМ в

многомоделната схема на SolidOpt е истинско предизвикателство, но евентуалните бъдещи

предимства и резултати биха оправдали усилията.


3.2.2.4. Lua Virtual Machine

Първата версия на пВМ Lua е пусната през 1993. В момента намира широко приложение при

игрите. Основната цел на Lua е да предостави скриптов език, който да:

• Бъде прост – търси се възможно най-простият език и съответно възможно най-

простият код на C, с който да се реализира езикът. Това означава прост синтаксис, с

малък брой езикови конструкции;

• Бъде ефективен – търси се възможно най-бърза компилация и изпълнение на

приложенията, използващи Lua. Това изисква бърз, еднопасов, “интелигентен”

компилатор и бърза пВМ;

• Бъде преносим – изисква се Lua да работи на колкото се може повече платформи;

• Позволява вграждане – ЕП Lua е допълнителен език и неговата цел е да предоставя

възможност за изпълняване на скриптове в приложенията;

• Бъде лесен за вграждане – изисква се “стегнат” C код, малко ядро и разширенията да

бъдат добавяни като библиотеки.

3.2.2.4.1. Сравнение между Lua 4.0 и Lua 5.0

Едно от интересните дизайнерски решения е преминаването от стек-базирана към регистър-

базирана архитектура в по-новата версия на пВМ. Разработчиците на Lua детайлно се

аргументират в [21]. Ще разгледаме две от основните причини:

• При стек-базираната пВМ, някои от операциите изискват стойностите в стека да

бъдат премествани и разменяни, което не само размива идеята за стек-базираност, но

и води до генериране на излишни инструкции. (Например при генерация за т.нар clo-

sures);

• По-големият размер на инструкцията в регистър-базираната пВМ се компенсира от

по-бързото й извличане.

Крайният резултат от изследването и проведените тестове е, че регистър-базираната Lua 5.0 е

по-ефективна средно със 70% от стек-базираната Lua 4.0[21].

3.2.3 СРАВНЕНИЕ МЕЖДУ РЕГИСТЪР-БАЗИРАНИ ВМ И СТЕК-БАЗИРАНИ ВМ пВМ позволяват на приложенията да бъдат разпространявани в платформено-независим

формат, който може да бъде компилиран или интерпретиран лесно. Най-използваните пВМ в

момента са JVM и CLR, които са със стек-базирана архитектура за разлика от доминиращите

регистър-базирани архитектури при ЦП. Съвсем естествено възниква въпросът коя е по-добра

регистровата или стековата архитектура на пВМ, предвид регистър-базираната архитектура на

ЦП.


В публикацията си от 2008 Shi et al[13] трансформират стек-базираната JVM в регистър-

базирана и правят различни тестове. Изследванията са направени, използвайки стратегия на

интерпретация на стековото и регистровото междинно представяне. Трябва да се отчетат и

следните факти при анализа на получените резултати:

• Компилацията до стек-базирано междинно представяне е по-лесна от компилацията

до регистър-базирано. Една от причините е, че при стек-базираното междинно

представяне липсва механизъм за разпределяне на регистрите (register allocator).

Може да се каже, че стек-базираните пВМ са по-податливи на JIT компилация,

защото липсва предположение за броя регистри. Недостатъкът на това е, че ако броят

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

компилация;

• Размерът на стек-базираното представяне е по-малък от размера на регистър-

базираното, защото липсва явни операции с регистри.

Резултатите показват, че регистър-базираните пВМ имат 46% по-малко изпълнени

инструкции, но кодът е 26% повече от съответстващия на стек-базирана пВМ[13].

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

горепосочените резултати могат силно да варират. По-задълбочени изследвания в това не са част

от настоящата дипломна работа.

От направения кратък обзор става ясно, че не може да бъде избрана само една определена

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

представителя от всяка основна архитектура пВМ както и връзка между тях.

Теоретични основи→Преглед на трансформиращи и анализиращи системи Стр. 31 от 126

3.3. ПРЕГЛЕД НА ТРАНСФОРМИРАЩИ И АНАЛИЗИРАЩИ СИСТЕМИ Обзорът на средства за анализ и трансформация на софтуерните системи би разширил

общият поглед върху проблемната област. Въпреки че основната цел на дипломната работа е

изграждането на общ инструментариум за създаване на средства за оптимизиращи

трансформации, е добре да се обърне внимание на по-широк набор от подобни системи.

Прегледът на анализиращи и трансформиращи средства дава обща представа за това какво

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

3.3.1 СРЕДСТВА ЗА АНАЛИЗ НА СОФТУЕРА Средствата за автоматизиран програмен анализ са изключително важни за разбиране на

поведението на програмите. Софтуерните разработчици се нуждаят от такива инструменти, за

да анализират разработките си и да определят критичните им секции. Хардуерните

разработчици се нуждаят от тях, за да оценят как ще действа софтуера на новите архитектури.

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

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

вход за профилно-ориентирани (profile-driven) оптимизации.

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

напасване на шаблони, изследване на потока данни (data flow analysis), проверка на модели и

доказване на теореми. Чрез тях се откриват слабости в анализирания софтуерен продукт.

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

как да бъдат отстранени. Основни недостатъци са:

• Много от откритите слабости са с различни нива на важност, сигурност и лекота на

отстраняване, които не биват систематизирани;

• Наличие на т. нар. фалшиви грешки;

• Системите за анализ на софтуера най-често намират приложение по време на фаза

разработка на софтуера;

• Има нужда от намеса на разработчик.

Ще бъдат разгледани системи, предназначени основно за Java:


Име Входен език Технология Bandera Сорс код Проверка на модели

ESC/Java Сорс код1 Доказване на теореми FindBugs Bytecode, Сорс код Синтактичен анализ, поток данни

JLint Bytecode Синтактичен анализ, поток данни PMD Сорс код Синтактичен анализ

1 ESC/Java използва основно сорс код, но може да има нужда от допълнителни спецификации за поддръжка на

типовете.

Таблица 3-2: Анализиращи инструменти

За подробна информация за степента на припокриване на разглежданите инструменти виж

[9].

3.3.1.1. Bandera

Технологията, използвана в Bandera е проверка на модели. Общата идея на технологията е да

се намерят евентуални мъртви хватки (deadlocks) и подобни критични състояния, които

причиняват сривове. Проверява се дали даден модел на системата отговаря на предварително

определена спецификация. За да бъде решен проблемът алгоритмично, е необходимо моделът да

бъде представен чрез прецизен математически апарат (краен автомат, насочен граф и т.н.).

Спецификацията бива описвана чрез темпорална логика.

Приложението на тази технология е както над хардуерни, така и над софтуерни системи.

Създаването на модели за хардуерни системи е много по-лесно, поради естеството им. При

моделите за софтуерните системи има проблеми по изграждането на коректни модели.

Един такъв проблем е семантичната празнина между идеите на разработчиците, програмните

езици и инструментите за анализ. Голяма част от разработчиците използват езици за

програмиране с общо предназначение като C, C++, C#, Java, Delphi, докато инструментите за

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

(Process calculus), автомати и др.).

Друг проблем е комбинаторният взрив на състоянията. Броят на състоянията нараства

експоненциално при увеличаване на компонентите.

Bandera има следните преимущества:

• Преизползва съществуващи технологии;

• Предлага автоматизирана поддръжка на абстракции – прави сложни трансформации,

за да повиши нивото на абстракция на модела;

• Предлага специализирани модели за специфични цели – автоматично генерира

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


• Дизайнът на системата позволява лесното й разширяване;

• Интегрира се с тестващите и дебъгиращите инструменти.

Един начин за използване на Bandera от разработчиците е анотиране на сорс кода, описвайки

какво трябва да бъде проверено. (Анотирането на определени секции за проверка намалява

проблема с комбинаторния взрив на състоянията.). Ако не се предостави описание, системата

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

Bandera предоставя опционални фази на рязане (program slicing) и абстракция, последвани от

проверка на модела.

3.3.1.2. Extended Static Checking (ESC)/Java

Технологията, използвана в ESC/Java [23] е автоматизирано доказване на теореми.

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

(аксиоми и хипотези). Езикът, съдържащ хипотезите и аксиомите (познати като формули) често

е логически. Използва се логика от първи ред, но е възможно и използването на некласическа

логика (например Deontic logic) или логика от по-висок ред. Основната цел на езика е да намали

до минимум двусмислията.

Доказателствата на теоремите описват “как” и “защо” е направено поредното заключение, по

начин, който бива разбран и приет от всички, дори и компютърни програми. Доказателствата

могат да бъдат не само убедителни, а и да съдържат решението на проблема. Например, при

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

за подреждането му.

ESC/Java предоставя удобен език за анотации, чрез който могат да се описват формално

дизайнерските решения. След това се изследват анотираните правила и се извеждат заключения

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

Проверките са статични, т.е. не е необходимо програмата да се изпълнява. ESC/Java открива

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

типовете (type checking systems). Чрез модула за доказване на теореми се намират грешки,

възникващи по време на изпълнение като обръщения към null-обекти, нарушения на границите

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

паралелни програми.

3.3.1.3. FindBugs

Технологията, използвана във FindBugs [24] е синтактичен анализ и анализ на потока от

данни. Синтактичният анализ се основава на синтактична проверка на сорс кода дали съдържа

познати съмнителни практики. Например, FindBugs проверява дали извикванията на wait (),


използвани при паралелните програми на Java, са винаги в цикъл, каквото е правилното им

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

Анализът на потока от данни се основава на обхождане на структурите на bytecode и

извличането на информация от тях. За обхождане на структурите често се използва шаблонът за

дизайн “Посетител” [25]. FindBugs изследва клас или JAR-файлове, търсейки потенциални

проблеми чрез напасване на шаблони. Има гъвкава система за разширение, позволяваща

добавяне на нови анализатори.

3.3.1.4. JLint

Подобно на FindBugs, JLint [27] анализира Java bytecode чрез синтактични проверки и анализ

на потока от данни. JLint създава граф на мъртвата хватка (lock graph) и следи за мъртви хватки,

като изследва графа дали е цикличен. Системата прави синтактична и семантична проверка (ve-

rification). Семантичната проверка се осъществява чрез извличане на информация от Java клас

файлове и използва debug информацията, за да асоциира генерираните предупреждения със

сорс кода.

Тъй като Java в голяма част наследява синтаксиса на C/C++, JLint може да проверява и

всички езици от синтактичното семейство (syntax family) на C като C, C++ и Objective C. За

разлика от FindBugs системата е трудно-разширима.

3.3.1.5. PMD

PMD [28], също като FindBugs и JLint извършва синтактични проверки на програмния сорс

код, но няма компонент за анализ на потока от данни. Като допълнение на откриването на

неправилен код е търсенето на нарушени стилистични конвенции, които могат да бъдат

подозрителни при определени обстоятелства. Например, съществуването на try блок и празен

catch блок подсказва за възможно неправилна обработка на грешките.

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

възможност за избор на тези, които да бъдат използвани. PMD е сравнително лесно-разширим.

За създаване на нов детектор е необходимо той да бъде реализиран на Java или да се използва

XPath.

Съществуват и системи, анализиращи качеството и стила на писане на сорс код. Те

проверяват основно за:

• Синтактично правилни имена на идентификатори – проверяват дали съществува

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

• Спазване на конвенции за именуване на идентификатори – приложими са, когато


идентификаторите са повече от една дума;

• Спазване на конвенции на отстъпи (indents) – редът, отговарящ на определения

програмен блок да започва с по-голям отстъп;

• Спазване на конвенции за интервали;

Такава система е StyleCop [29]. Тя включва много от споменатите по-горе техники, но излиза

извън разглеждането, защото в по-голямата си част е текстово ориентирана анализираща

система. Качеството на създадения сорс код е важен аспект от програмирането, но неговото

разглеждане е извън поставените цели на прегледа.

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

механизъм за правилната интерпретация на получените данни. За да се направи даден вид

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

извършва с този инструмент. Различните средства предоставят хетерогенна информация, която

затруднява създаването на оптимизиращи методи, базирани на няколко вида и/или класа

анализиращи инструменти. С други думи, по-важно е правилното интерпретиране на

получената информация, отколкото самата информация. Защото може да се окаже, че

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

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

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

3.3.2 СРЕДСТВА ЗА ТРАНСФОРМАЦИЯ НА СОФТУЕРА За пълнота на класификацията е необходимо средствата за трансформация на софтуера да се

разделят на следните подкатегории от гледна точка на сложността на извършвания анализ:

• Средства, използващи първичен анализ – обикновено обхождат структурите на

програмите и прилагат трансформации, базирани на шаблонно напасване. Съдържат

фиксиран брой трансформации, които биват прилагани при определени

обстоятелства. Тези средства са лесни за реализация, поддръжка и разширение, но

прилагат само сравнително прости трансформации върху софтуера и са ниско

ефективни;

• Средства, използващи комплексен анализ – правят сложни заключения на базата на

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

бъде приложена. Реализацията им не е лесна задача, за сметка на по-високата им

ефективност. Много от тези средства са свързани към конкретна приложна област.


3.3.2.1. Bartok & Singularity

Ще бъде разгледана една изцяло нова идея на организация на компилираните програми в

операционните системи. Тя осигурява нормалната работа на описания оптимизиращ компилатор

Bartok. За прилагането на оптимизациите се използва първичен анализ.

Singularity [30] е операционна система, работеща с управляем (managed) код. Тя е създадена

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

минимализъм; яснота в дизайна и разширяемостта на модерните езици и инструменти.

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

приспособена за бъдещи изследвания и иновации в системната надеждност. Някои от

иновативните архитектурни решения са:

• Типово безопасен (type safe), абстрактен набор от инструкции – базиран на типово-

безопасният MSIL предоставя идеален системен двоичен интерфейс. Така се

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

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

• Обобщен механизъм за разширение на приложения и ОС – улеснява дизайна и

реализацията на ОС и приложенията. Поддържайки един механизъм за разширение

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

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

надеждността и сигурността;

• Силна софтуерна изолираност на процесите – преодоляват се два основни проблема в

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

приложения и нежеланите атаки от недобронамерен код. Силната изолираност на

процесите повишава надеждността на системата и полага основи за бъдещи

изследвания;

• Общата инфраструктура на метаданните, описваща кода и данните – помага за

премахването на ненадеждни приложения възможно най-рано от жизнения цикъл на

системата. Метаданните позволяват типовата безопасност и гъвкавостта на

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

разширение и пълната връзка за дълбока изолация на процесите.

Именно в ОС като Singularity има необходимост и от следващо поколение компилатор, който

да прави кода надежден. Такъв компилатор е Bartok [32].

Bartok е компилатор, който използва управляеми (от ВИМ) езици за програмиране като C#.

Състои се от около 200,000 реда код предимно написани на C#.

Bartok може да компилира всеки двоичен модул индивидуално или може да компилира


цялата програма като същевременно прилага и между-процедурни оптимизации. Режима за

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

библиотеките, които не са верифицирани.

Фигура 3-3: Архитектурата на Bartok

Компилаторът транслира програмите, написани на CIL, който е междинно представяне за C#

и други езици в изпълним машинен (native x86) код. Използват се три междинни представяния:

High-level IR (HIR), Medium-level IR (MIR) и Low-level IR (LIR). Прилагат се около 40

оптимизации на трите нива, базирани предимно на първичен анализ.

HIR е подобен на CIL като се изключи, че не използва стеково-базирани изчисления.

Системата от типове е подобна на CIL (или C#) и съдържа примитивни типове, класове,

интерфейси, масиви и т.н. Всички обектно-ориентирани операции в HIR са примитиви,

например извикване на виртуален метод, преобразуване на тип (type cast), достъп до масиви и

други.

Тези примитиви се понижават по време на транслацията от HIR до MIR. Например,

извикването на виртуален метод се транслира до код за извличане (fetching) на виртуалната

таблица от обект, извеждане на метод извън виртуалната таблица и извикване на метода върху

обекта. Първичният MIR има същата система от типове като HIR, която не е достатъчно

изразителна, за да представи резултата от понижаването. Например, не съществува тип в HIR,

който може да представи виртуалната таблица на клас, съдържащ виртуален метод.


MIR се понижава до LIR. Тогава се прилагат няколко трансформации върху LIR: class layout,

избор на инструкция, разпределение на регистрите, stack frame layout. В LIR няма типове.

Най-ниското ниво на LIR (което по същество е assembly) се записва в обектни файлове със

стандартен формат. Стандартен линкер свързва обектните файлове и създава изпълними

файлове на машинен език.

Едно от ограниченията на оптимизациите в Bartok е техният фиксиран брой. А тясната им

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

използват само по време на разработка на програмата. Друг недостатък е тясното обвързване на

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

приложимостта.

3.3.2.2. BARBER

Barber използва техниката на т. нар. двоичен рефакторинг (binary refactoring) [31]. Двоичният

рефакторинг подобрява реализацията на програмите, без да се модифицира сорс кодът.

Трансформациите, основани на двоичен рефакторинг запазват семантиката и повишават

ефективността на приложенията. По-подходящо е, двоичният рефакторинг да се разглежда като

техника, която увеличава “поддържаемостта”, без да се жертва производителността, отколкото

да се разглежда като техника за повишаване на производителността. Причината за

съществуването му не е, че програмите се нуждаят от по-добра оптимизация, а поради това, че

разработчиците са принудени да трансформират кода с цел постигане на по-висока

производителност. Още повече че тези трансформации “замърсяват” сорс кода и понижават

възможността за поддържането му. Например, разделянето на класове не поради дизайнерски

причини, а от съображения за производителност. Двоичният рефакторинг е много близко като

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

BARBER представлява двоичен рефакторинг редактор за Java. Поддържа следните важни

оптимизационни трансформации:

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

функционалността на първичния клас (вероятно единствено при определени

обстоятелства). Изменя клиентите на първичния клас да използват частичните

класове;

• Слепване на класове – слива два класа, чиито обекти се използват винаги заедно;

• Вграждане на метод – замества извикване на метод с адаптираното тяло на

извиквания метод;

• Девиртуализиране на метод – замества индиректно (виртуално) извикване на метод


със статично извикване;

• Премахване на делегати;

• Премахване на шаблон “Посетител”.

Проектът е в начален етап на разработка и се базира на анотации, но те могат да бъдат лесно

заменени от система, извършваща комплексен анализ. От получената информация при анализа

може да бъдат предприети различни оптимизационни трансформации.

3.3.3 ИНСТРУМЕНТАРИУМИ ЗА РАЗРАБОТКА НА ТРАНСФОРМАЦИОННИ СРЕДСТВА

Инструментариумите за разработка на трансформационни средства улесняват създаването на

такива средства, като свеждат реализацията на средството до минимум. Описаните в секцията

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

основните подходи за реализация. Прегледът и анализът на тези подходи дава ясна представа за

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

експерименталния фреймуорк.

3.3.3.1. Phoenix

Phoenix [33] е кодовото име на фреймуорк за софтуерна оптимизация и анализ, основа на

бъдещите компилатори на Microsoft. Той е разширяема система, която може да се приспособи за

четене и писане на двоични и MSIL модули (assemblies). Phoenix представя входните файлове в

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

се използват т. нар. Phoenix API.

Phoenix е разработен, за да удовлетвори нуждите на два класа потребители: разработчици,

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

разработват програмни инструменти и езици за програмиране.

За разработчиците, Phoenix предлага множество блокове, които позволяват да се комбинират

методи и обекти при създаване на инструмент с определена цел. Генераторът на код поддържа

типово-безопасни езици като C# и други като C++ и Visual Basic. Анализът и оптимизациите

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

Разработчиците получават солидна инфраструктура, разработена за модулно преизползване

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

Ядрото на фреймуорка е отделено от машинните модели така, че целият продукт може да

бъде преконфигуриран. Основа на системата е междинното представяне на много нива.

Много от идеите са фундаментални, но са строго ориентирани към изграждането на

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


3.3.3.2. ATOM (Analysis Tools with OM)

ATOM [34] е фреймуорк за разработване на широк набор от инструменти за програмен

анализ. Той предоставя общата инфраструктура на всички инструменти, използвани за

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

процедурите за анализ. Например, за разработката на инструмент за броене на блоковете като

Pixie е необходимо само страница код.

Използвайки технологията link-time на OM, ATOM организира изпълнимия файл като

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

информацията се предава директно от приложението към процедурите за анализ само чрез

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

диска.

ATOM е реализиран за микропроцесор Alpha AXP под OSF/1. Той е ефикасен и се използва за

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

запис на паметта, симулации на инструкции и данни в кеша, конвейерна симулация (pipeline si-

mulation), оценка и предсказване на преходи, разпределение на инструкции (instruction schedul-

ing) и др.

Има няколко системи предоставящи подобна на ATOM функционалност за различните

платформи. EEL [35] за архитектурата SPARC, Etch [36] и Vulcan [37] за архитектурите x86 и

BIT [38] за Java bytecode.

Vulcan, например, разширява основните идеи на ATOM. Той може да извършва статични и

динамични модификации на кода в хетерогенни и разпределени системи.

3.3.3.3. Soot

Soot [39] е инструментариум за оптимизиране на Java bytecode. Реализиран е на Java и

поддържа три междинни представяния на Java bytecode:

• Baf – въпреки, че основната цел на инструментариума е да се избегне манипулацията

със стековото представяне на bytecode, понякога е необходимо да се анализира или

оптимизира в тази си форма. Baf се използва за по-лесно управляване на bytecode.

Едно от основните предимства на Baf е неговата типизираност за разлика от bytecode

(където има и нетипизирани инструкции като dup, например). Използва се за цели

като: генериране на Jimple представяне, защото е необходимо да се направи

абстрактна интерпретация на стека; преди генериране на нов bytecode, защото е

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

зареждания/съхранения (load/store);


• Jimple – представлява три-адресно представяне на bytecode. Добър е за прилагане на

анализ и трансформации като развиване на цикли или по-сложни като разкриване на

виртуални методи (използвани при обектно-ориентираните езици за програмиране).

Стекът е елиминиран и заменен от допълнителни локални променливи;

• Shimple – вариант на Jimple включващ поддръжка на Static Single Assignment (SSA);

• Grimp – представлява неструктурирано представяне на Java bytecode, което позволява

да бъдат конструирани дървета, съставени от изрази (expression trees).

Извършват се трансформации и върху трите представяния, като всяко представяне позволява

да бъде извършвана (лесно) различна трансформация. Съществува и надстройка на Soot, която е

атрибутно-ориентирана [40].

Атрибутите са елементи, които позволяват да бъде добавена декларативна информация за

програмите. Те са необходими, защото много от предоставяните услуги са трудно-реализируеми

със стандартен код. Използват се за “анотиране” на допълнителни свойства или характеристики.

Тези допълнения се наричат метаданни. Това е концепция, позволяваща на разработчиците да

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

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

инструменти. В случай, че инструментите разпознаят даден атрибут те извършват определени

операции върху обекта, съдържащ атрибута, в противен случай го прескачат. Това означава, че

чрез анотиране могат да се “подскажат” ключовите места, подходящи за трансформация.

Основен недостатък на атрибутите е увеличаването на размера на обектите. Едно решение на

проблема е използването на трансформация, която ги премахва. Тъй като атрибутите в

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

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

Описаните системи са съвременни, но не предлагат унифициран механизъм за анализиране,

профайлинг и оптимизиране на широк набор от произволни приложения. Създаването на такъв

механизъм би улеснило задачата за намиране на оптималните стойности и параметри на работа

на дадена софтуерна система.

Прегледът на качествено различни системи описва част от идеите на разработвания

инструментариум. Анализът на силните и слабите страни на всяка от системите очертава

концепциите, заложени в SolidOpt.

Теоретични основи→Известни оптимизационни методи Стр. 42 от 126

3.4. ИЗВЕСТНИ ОПТИМИЗАЦИОННИ МЕТОДИ Голяма част от известните оптимизационни методи са разработени за оптимизационните

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

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

инструментариум. Затова ще бъдат разгледани различни оптимизации, които биха могли да се

реализират в разработвания проект.

3.4.1 АВТОМАТИЧНА ПАРАЛЕЛИЗАЦИЯ (AUTOMATIC PARALLELIZATION) Техниката представлява преобразуване на последователен код в многонишков и/или

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

3.4.2 ВЕКТОРИЗАЦИЯ Техниката представлява трансформация на скаларна програма във векторизирана.

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

векторна програма се прилагат върху двойка векторни (група от подобни стойности) операнди.

3.4.3 ЕЛИМИНИРАНЕ НА ПРОВЕРКИТЕ НА ГРАНИЦИТЕ (BOUNDS-CHECKING ELIMINATION)

Оптимизацията е използваема при ЕП, които включват проверка на границите. Техниката

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

индексиращи операции не е необходимо да се проверяват по време на изпълнение. Например,

при обхождане елементите на масива, условието на цикъла гарантира валидността на индекса.

Затова използването на индекса в цикъла е безопасно и позволява премахване на проверките.

3.4.4 ЕЛИМИНИРАНЕ НА ОБЩИТЕ ПОДИЗРАЗИ (COMMON SUBEXPRESSION ELIMINATION)

Оптимизационната техника търси идентични изрази (такива връщащи един и същ резултат) и

анализира дали си заслужава да ги замени с временна променлива, съдържаща изчислената

стойност. Например, може да си струва A да се замени с B:

Преди елиминиране (A) След елиминиране (B)

a = b * c + g; d = b * c * d;

tmp = b * c; a = tmp + g; d = tmp * d;

Таблица 3-3: Пример за елиминиране на общите подизрази


3.4.5 СВИВАНЕ И РАЗПРОСТРАНЕНИЕ НА КОНСТАНТИ (CONSTANT FOLDING & PROPAGATION)

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

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

чиито стойности не се модифицират или такива, които са явно указани като константи.

Следният израз се изчислява по време на компилация:

Преди свиване След свиване

i = 100 * 200 * 300; i = 6000000;

Таблица 3-4: Пример за свиване на константи

Разпространението на константи е процес на замяна на стойности на константи в изрази по

време на компилация. Например, следния фрагмент A ще се замени от B:

Преди разпространение (A) След разпространение (B)

int f = 10; int g = 3 – f / 5; return g * (19 / f + 1);

int f = 10; int g = 3 – 10 / 5; return g * (19 / 10 + 1);

Таблица 3-5: Пример за разпространение на константи

3.4.6 РАЗПРОСТРАНЕНИЕ НА КОПИЯТА (COPY PROPAGATION) Разпространението на копията е процес, при който се заменят дясната част на директните

присвоявания с техните стойности. Директно присвояване е от вида y=x, където x се присвоява

на y. Например, от A се получава B:

Преди разпространение (A) След разпространение (B)

y = x; z = 3 + y;

y = x; z = 3 + x;

Таблица 3-6: Пример за разпространение на копията

Разпространението на копията е полезна “почистваща” оптимизация, често използвана след

други оптимизации. Някои оптимизации изискват разпространението на копията да бъде

пусната след тяхното действие, за да се постигне по-висока ефективност.

3.4.7 ЕЛИМИНИРАНЕ НА “МЪРТЪВ КОД” (DEAD CODE ELIMINATION) Техниката елиминира кода, който няма ефект върху програмата. Премахването му намалява

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


бързодействието й. Мъртвият код включва код, който никога не може да бъде изпълнен и такъв,

който въздейства само на “мъртви променливи”:

Преди елиминиране След елиминиране

int deadcode() { int a = 24; int b = 25; /* Присвояване към мъртва променлива */ int c; c = a << 2; return c; b = 24; /* Неизпълним код */ }

int deadcode() { int a = 24; int c; c = a << 2; return c; }

Таблица 3-7: Пример за “мъртъв код”

3.4.8 ГЛОБАЛНО НОМЕРИРАНЕ (GLOBAL VALUE NUMBERING) Глобално номериране е оптимизация, базирана на представянето SSA. Понякога помага за

премахването на излишния код, който не бива премахнат от елиминирането на общите

подизрази. Техниката присвоява число на променливи и изрази. На тези променливи и изрази,

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

Добре реализирана, оптимизационната техника би присвоила едно и също число на x и w и

едно и също число на y и на z, т.е 1, 1, 2, 2x w y z→ → → → . Използвайки тази информация,

фрагментът A може да се трансформира до B:

Преди (A) След (B)

w = 3; x = 3; y = x + 4; z = w + 4;

w = 3; x = w; y = w + 4; z = y;

Таблица 3-8: Пример за глобално номериране

При това положение е възможно “разпространението на копия” да премахне присвояванията

на x и на z.

3.4.9 ОПТИМИЗАЦИИ, БАЗИРАНИ НА ПОТРЕБИТЕЛСКИЯ ПОТОК ОТ ДАННИ И ОПЕРАЦИИ

Потребителският поток от операции (user control flow) представлява последователността от

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

Потребителският поток от данни (user data flow) е последователността от данни, които

потребителят използва при взаимодействието си със системата.


Понякога потребителският поток от операции и/или данни определя кога една оптимизация

върху целевата система е приложима и ефективна.

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

информация за честотата им на изпълнение. Съобразявайки тази информация може да се

направи по-точно заключение къде оптимизациите биха били по-ефективни. Струва си да се

оптимизират подпрограмите, които се изпълняват многократно. Честотата на изпълнение, обаче,

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

конкретния потребител.

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

оптимизациите.

3.4.10 ОПТИМИЗАЦИИ НА ОБЕКТНО-ОРИЕНТИРАН КОД Разгледаните оптимизационни техники дотук бяха сравнително елементарни. Ще разгледаме

следните “сложни” оптимизации, свързани главно с обектно-ориентираното програмиране. Те

се нуждаят от по-задълбочен анализ кога и къде да бъдат приложени, защото зависят от това как

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

3.4.10.1. Вграждане на метод (Method Inlininig)

Вграждането на метод е частен случай на вграждането на подпрограма, но има определени

специфики свързани с обектно-ориентираното програмиране (например, видимост на полета,

неявно предаване на this указател и др.). Тези специфики ще се дискутират в реализационната

част.

Вграждането на подпрограми [48] [49] се състои от заместване на извикването на

подпрограма с модифицирано копие на тялото й. Извикване означава изречение (statement) или

израз (expression), който когато се изпълни, извиква именувана подпрограма.

Вграждането на подпрограми елиминира допълнителното време за запазване на състоянието

и операциите по предаване на параметри. По-важното е, че позволява да бъдат приложени

оптимизации върху извикващата подпрограма и тялото на извикваната, заедно. Това позволява

прилагане на оптимизации като елиминиране на общите подизрази (3.4.4), без загуба на

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

При контекстен анализ на извикване на подпрограма е достъпна много по-прецизна

информация за потока от данни (data flow). Информацията за параметри и глобални променливи

може да бъде разпространена (3.4.6) в тялото на подпрограмата. Вграждането на подпрограми е

особено приложимо при високо-модулните системи, защото изпълнението на тялото на

подпрограмата е по-вероятно да бъде по-бързо от самото й извикване. Например:


Преди вграждане След вграждане

double Area(int a, int b) { p = (a + b + c)/2; return sqrt(p* (p-a)* (p-b)* (p-c)); } void Main() { ... s = Area(a, b, c); ... }

double Area(int a, int b) { p = (a + b + c)/2; return sqrt(p* (p-a)* (p-b)* (p-c)); } void Main() { ... p = (a + b + c)/2; s = sqrt(p*(p-a)* (p-b)* (p-5)); ... }

Таблица 3-9: Пример за вграждане на подпрограма

Вграждането на подпрограми винаги намалява цялостното време за изпълнение, но може да

доведе до увеличаване на размера на двоичните файлове на програмите. Понякога при

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

препълване на стека.

Компилаторите прилагат вграждането на подпрограми по два начина:

• Автоматично – компилаторът решава коя подпрограма да бъде вградена;

• Чрез явно указване от разработчика – програмистът посочва кои подпрограми да

бъдат вградени.

Двата способа са неефективни.

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

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

постигне задоволителен резултат.

При явното указване компилаторът “се опитва” да вгради подпрограмата и ако срещне

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

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

3.4.10.2. Клониране на метод (Method Cloning)

Съществуват определени ситуации, при които един или повече изрази (expressions)

представляват входни параметри на метод (или в по-общия случай на подпрограма) при

неговото извикване.

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

подпрограмата от извикващата я не се използват по време на изпълнение. Когато такъв израз е

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

извикване. При тези обстоятелства изчисляването на израза е ненужно.

Чрез клониране на извикванията се генерира реализация, която има същото външно


поведение като оригинала, но различна сигнатура. В сигнатурата липсва изразът, който не се

прoменя, а в тялото е заменен с неговата стойност. В израза, съдържащ извикването, старата

сигнатура се заменя с ново-генерираната. Например:

Преди клониране След клониране

double Area(int a, int b, int c) { p = (a + b + c)/2; return sqrt(p* (p-a)* (p-b)* (p-c)); } void Main() { ... s1 = Area(a, b, 5); ... s2 = Area(a, b, 5); ... s3 = Area(a, b, a + b); }

double Area(int a, int b, int c) { p = (a + b + c)/2; return sqrt(p* (p-a)* (p-b)* (p-c)); } double AreaClone(int a, int b) { p = (a + b + 5)/2; return sqrt(p*(p-a)* (p-b)* (p-5)); } void Main() { ... s1 = AreaClone(a, b); ... s2 = AreaClone(a, b); ... s3 = Area (a, b, a + b); }

Таблица 3-10: Пример за клониране на подпрограма

Клонирането променя структурата на графа на извикванията (call graph) по начин, който

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

В много случаи и често след допълнителни оптимизации, клонирането на подпрограми

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

предаваните параметри. [50]

3.4.10.3. Разделяне на клас (Split Class)

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

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

частичните класове вместо общия.

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

съхрани или изпрати независимо. Това прави съхранението/изпращането по-ефективно.

Друго приложение на разделянето на класове е повишаване на ефективността на кеш

паметта. Например, определени полета от обекта се използват много по-често от други. При

разделяне на подобекти е възможно много по-голяма част от често използваните полета да

попаднат в кеш паметта и системата да стане по-производителна.

3.4.10.4. Сливане на класове (Glue Classes)

Сливат се два класа, чиито обекти се използват винаги заедно. При прилагането на тази


оптимизация се премахва индирекцията при достъп и се постига по-ефективно разпределение

на данните.

Оптимизацията е приложима при използване на шаблона за дизайн “Мост”. “Шаблонът за

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

променят независимо” [25]. Причината за приложимостта е това, че много често абстракцията

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

3.4.10.5. Премахване на делегати (Remove Delegate)

Модифицира така клиентския код, че вместо извикване на делегат извиква целевият обект

директно.

Оптимизацията е приложима, когато делегатът има много клиенти и те “знаят” статично кой

делегат ще бъде извикан.

3.4.10.6. Премахване на шаблон “Посетител” (Remove Visitor)

Елиминират се излишествата (overhead), резултат на използването на шаблона за дизайн

“Посетител”.

Оптимизацията е приложима, когато типовете на обработваните обекти и посетителите се

“знаят” статично.

Теоретични основи→Aрхитектурни решения Стр. 49 от 126

3.5. AРХИТЕКТУРНИ РЕШЕНИЯ

3.5.1 ШАБЛОНИ ЗА ДИЗАЙН “Проектирането на обектно-ориентиран софтуер е трудно, а проектирането на обектно-

ориентиран софтуер за многократна употреба е още по-трудно.” [25].

Тъй като основната цел на дипломната работа е проектирането на фреймуорк за многократна

употреба ще бъде необходимо да се използват общоприети, добри практики в проектирането на

обектно-ориентиран софтуер. Една такава практика е използването на шаблони за дизайн,

поради няколко причини:

• Преизползваемост;

• Слаба свързаност;

• Общоизвестност/общоприетост – даден проблем се решава с определен шаблон за

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

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

специфични особености в реализацията му.

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

това описва същината на решението на този проблем. Решението се описва така, че да може да

се използва много пъти “без някога да се повтори начинът на изпълнение” [25].

С други думи, шаблонът за дизайн представлява абстрактно описание на даден дизайнерски

проблем и как едно общовалидно подреждане на елементите (като класове и обекти) го решава.

Основните характеристики на един шаблон са:

• Име – средство, което може да се използва за кратко описание на дизайнерски

проблем, неговите решения и следствия;

• Проблем – описва кога даден шаблон може да се приложи. Пояснява проблема и

контекста му;

• Решение – описва елементите, които изграждат дизайна, техните взаимоотношения,

отговорности и връзки. Решението не описва определен конкретен дизайн или

приложение, защото шаблонът е нещо като модел, който може да се приложи при

много различни ситуации;

• Следствия – описва предимствата и недостатъците, следващи от прилагането на

шаблона.

Тъй като някой от описаните в [25] шаблони за дизайн се използват многократно ще бъдат

разгледани по-обстойно.


3.5.1.1. Посетител

Представя операции, които се извършват върху елементите на обектна структура. Посетител

дава възможност да се дефинира нова операция, без да се променят класовете на елементите,

върху които работи тя.

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

синтактично дърво. Той ще трябва да извършва операции върху дървото за анализ на статичната

им семантика (например дали всички променливи са дефинирани). Също така трябва да

генерира и код. Това означава, че може да дефинира операции за проверка на типа,

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

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

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

характеристики, пренареждане на операторите им и т.н.

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

присвояване, различно от възлите, които представляват променливи или аритметични изрази.

От това следва, че ще има един клас за инструкции за присвояване, друг за достъп до

променливи, трети за аритметични изрази и т.н. Би било объркващо, ако всички тези операции

са едновременно на едно и също място. Освен това добавянето на нова операция обикновено

изисква прекомпилиране на всички тези класове.

Тези две неща могат да се постигнат, като се пакетират свързаните операции от всеки клас в

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

дърво при обхождането му. Когато даден елемент “приеме” посетителя, той изпраща заявка до

него, която кодира класа на елемента. Освен това елементът се включва като аргумент. След

това посетителят ще изпълни операцията за този елемент, която преди се е намирала в класа на

елемента.


Фигура 3-4: Клас-диаграма на “Посетител”

За да са напълно функционални, посетителите имат нужда от абстрактен клас NodeVisitor за

всички посетители на абстрактното дърво. NodeVisitor трябва да декларира операция за всеки

различен клас възел.

Шаблонът “Посетител” капсулира операциите за всяка фаза на компилиране в обекта Visitor,

асоцииран с тази фаза.

Нова операция се създава чрез прибавяне на нов подклас в йерархията на класа на

посетителя.

3.5.1.2.Композиция

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

Шаблонът Композиция дава възможност на клиентите да третират еднакво отделни обекти и

композиции от обекти.

Графичните приложения от рода на редакторите за рисуване и системи за проектиране (CAD)

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

компоненти. Потребителят може да групира компоненти, за да формира по-големи компоненти,

които, от своя страна, могат да бъдат групирани, за да формират още по-големи компоненти.

Една примерна имплементация би могла да дефинира графични примитиви като Text и Line,

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

При този подход обаче има един проблем: кодът, използващ тези класове, трябва да третират

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

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


приложението по-сложно. Шаблонът Композиция описва как да се използва рекурсивна

композиция, така че клиентите да не трябва да правят такова разделение.

Фигура 3-5: Клас-диаграма на “Композиция”

Сърцето на шаблона Композиция е един абстрактен клас, представящ едновременно

примитивите и техните контейнери. При графичните системи този клас е Graphic (графика).

Graphic декларира операции като Draw, които са специфични за графичните обекти. Той

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

и управление на наследниците.

Подкласовете Line (линия), Rectangle (правоъгълник) и Text (текст) дефинират примитивни

графични обекти. Тези класове имплементират операцията Draw, която чертае (рисува)

съответно линии, правоъгълници и текст. Тъй като примитивните графики нямат вложени в себе

си графики, никой от тези подкласове не имплементира операции, свързани с наследници.

В класа Picture (картина) е дефинирана съвкупността от Graphic обекти. Picture реализира

операцията Draw, така че да извиква методите Draw на своите наследници, а също така

реализира и съответните операции, свързани с наследниците. Тъй като интерфейсът на Picture е

производен на интерфейса на Graphic, Picture обектите могат да композират рекурсивно други

Picture обекти.

3.5.1.3. Сек

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

за достъп до него.

Фигура 3-6: Клас-диаграма на “Сек”


За някои класове е важно да имат точно по една инстанция. Въпреки че една система може да

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

Глобалната променлива прави обекта достъпен, но това не предпазва от инстанцииране на

множество обекти.

По-добро решение е да се направи самият клас отговорен за следенето на единствената си

инстанция. Класът може да гарантира, че не може да се създаде друга инстанция (чрез

прихващане на заявки за създаване на нови обекти) и може да предоставя начин за достъп до

инстанцията.

3.5.2 АРХИТЕКТУРИ, БАЗИРАНИ НА УСЛУГИ (SOA) SOA осигурява набор от принципи за концепциите на управлението, използвани по време на

фазата на разработка и интеграция. Подобна архитектура би пакетирала функционалността като

взаимодействащи си услуги (services). Те представляват софтуерни модули, осигуряващи

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

техните клиентски системи са качествено различни. Реализацията на SOA се опитва да въведе

нова техника за софтуерна интеграция на модули. Тя не дефинира API функции, а интерфейси в

термините на протоколи и функционалност.

SOA е базирана на съвкупност от услуги. Услугите са неасоциирани помежду си, слабо

свързани, функционални единици, без вградени извиквания помежду си. Всяка услуга

реализира едно действие, като онлайн регистрация, онлайн поръчка на книга или билет. Вместо

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

протоколи. Протоколите описват как услугите предават или интерпретират данни, използвайки

метаданни.

Разработчикът свързва обектите от SOA, като използва дирижиране (orchestration). В процеса

на дирижиране се асоциира функционалността (услугите) в нейерархични подредби (за разлика

от йерархията между класовете).

Използването на техниката изисква метаинформацията да описва не само характеристиките

на услугите, но и данните, чрез които услугите се управляват. Едни от езиците за описание на

данните и протоколите са WSDL (Web Services Description Language) и SOAP (Simple Object

Access Protocol).

Целта на SOA е да позволи на потребителите да “слепват” заедно сравнително големи части

от функционалност, за да сформират специални приложения, които са създадени почти изцяло

от съществуващи услуги. Колкото по-големи са частите, толкова по-лесно се реализира

необходимият набор от функционалност. При прекалено големи функционални части може да се


затрудни преизползването им. Всеки интерфейс (част) води със себе си излишество (overhead),

което налага съобразяване с производителността, при избор на услуги.

За да се използва ефективно SOA, трябва да е изпълнено следното:

• Взаимооперативността (interoperability) между различните системи и ЕП представя

основата за интегриране на услугите на разнородни платформи. За обмяна на данни

трябва да се използва комуникационен протокол. Пример за такъв протокол е

обмяната на съобщения. Съобщенията намаляват сложността на системата, като

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

създаването на комуникационен протокол;

• Създаване на федерации от ресурси. Федерациите обединяват ресурси и приложения,

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

Услугите е добре да включват в дизайна си:

• Капсулация;

• Слаба свързаност;

• Договореност (contract) – услугите трябва да се придържат към предварително-

дефинирано споразумение за комуникация;

• Абстракция;

• Преизползваемост;

• Композитност – колекции от услуги могат да бъдат координирани и събрани от една,

композитна услуга;

• Откриваемост – услугите трябва да са описани така, че да бъдат лесни за откриване и

достъпване от механизма за откриване.

SOA е архитектурна и дизайнерска насока, създадена за подобряване на

взаимооперативността (обмяна на информация, преизползване, композитност) и повишаване на

нивото на федерациите.

Разработваният инструментариум използва архитектура, близка до SOA, която с

реализацията на повече услуги, ще се доближава все повече до крайната цел – напълно

съобразена с изискванията на SOA архитектура.

3.5.3 АРХИТЕКТУРИ, БАЗИРАНИ НА МОДЕЛИ (MDA) Според OMG, MDA дефинира подход за спецификациите на системите в сферата на

информационните технологии. Тя разделя софтуерната спецификация на функционална

спецификация, спецификация на реализацията на тази функционалност и на спецификация на


технологичната платформа. За да улесни това, MDA дефинира архитектура от модели, които

осигуряват набор от насоки за структуриране на спецификациите. Моделите и базираното на

модели програмиране са сърцето на MDA.

В термините на MDA, модел е представянето на част от функционалността, структурата

и/или поведението на системата. Моделът предоставя абстракция върху физическата система,

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

само върху значимите. Всички форми на инженерство се основават на модели, за да бъдат

разбрани сложни системи от реалния свят. Моделите могат да се разработват преди

реализацията на системата, да се получават от съществуваща система или да се получават по

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

Подходът MDA и неговите стандарти позволяват моделът, определящ системната

функционалност да бъде реализиран върху различни платформи.

Казва се, че една спецификация е формална, ако е базирана на език за програмиране с добре

дефиниран синтаксис и семантика. Синтаксисът може да бъде текстов или графичен.

Семантиката може да бъде дефинирана в термините на наблюдения върху описвания свят (ПО)

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

дефинирано значение. В MDA спецификация, която не е дефинирана по този формален начин не

е модел.

Трябва да се обърне внимание, че при подобно дефиниране, сорс кодът е модел, който има

отличителната характеристика, че може да бъде изпълняван от ВИМ.

Терминът абстракция се използва в MDA в смисъл на потискане на детайлите, които са без

значение за поставената цел.

Полезно е моделите да се характеризират в термините на критерия абстрактност, който ще

определя какво да бъде включено в модела. Модел, който се базира на специфичен критерий на

абстрактност, често се нарича модел от гледище на дефинирания критерии.

Модел от по-високо ниво на абстракция се нарича моделът, при който голяма част от

детайлите са пренебрегнати в сравнение с модела от по-ниско ниво на абстракция. За повече

информация виж [47].

Идеята за използване на модели с различни нива на абстракция е приложима и в

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

пропуснат ненужните детайли от оптимизираната система, като се фокусират само

необходимите за конкретната цел.

Реализация→Софтуерът като модел Стр. 56 от 126

44.. РРЕЕААЛЛИИЗЗААЦЦИИЯЯ

Представените в “Теоретични основи” подходи и целите на дипломната работа подсказват

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

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

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

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

постигнали целите, включвайки дадена технология.

Анализите са под формата на предимства, недостатъци и препоръки, което означава, че са

зададени неявно. Неявното представяне не изисква аргументи. При общ преглед върху

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

излишна информация. Това предимство, обаче, в реализационната част е недостатък, защото

неявните описания на приложимостта на определени на технологии не са достатъчни. Поради

тази причина е наложително използваните подходи да бъдат явно описани и аргументирани.

4.1. СОФТУЕРЪТ КАТО МОДЕЛ Както отбелязахме в 2.1 програмният език е нотация, чрез която хората описват

изчисленията, които трябва да бъдат изпълнени от машина. Целият софтуер за всички компютри

е написан на някакъв програмен език. Следователно софтуерът може да се разглежда като

предписание, решаващо конкретна задача от реалния свят. А всяко предписание или алгоритъм,

описващ част от реалния свят е модел. Може да се направи заключението, че софтуерната

програма е модел на изпълнение за намиране на решение на даден проблем. Моделират се

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

решение.

Програмните езици непрекъснато се променят, като се стремят да се доближат максимално до

естествения език. Създават се различни семантично-еквивалентни конструкции (понякога и

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

основната цел на тези изменения е да се улесни максимално разработчика на софтуер.

С течение на времето и моделът на програмата би трябвало да става все по-абстрактен и все

по-близък до естествения език, т.е. да се превръща в модел, по-ясен за разработчика. Това води


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

ВИМ (абстрактен изпълнител). Този процес (познат като транслация) води до загуба на

информация за модела от високо ниво и в частност до създаване на неоптимален код за

изпълнение. Неоптималната транслация е следствие на три основни причини:

• Липса или недостатъчно добре реализирани оптимизиращи модули в транслатора;

• Не се използват пълните възможности на ВИМ;

• Не се използват знания за приложната област на модела;

• Не се използва пълната информация налична в модела от високо ниво.

Един от начините, чрез който могат да бъдат избегнати посочените недостатъци е изнасянето

на част от оптимизационните алгоритми извън транслаторите. По този начин се постига по-

добра независимост и гъвкавост, защото оптимизационните методи могат да се разширяват

лесно от потребителя, както и да се предприемат различни агресивни стратегии за модификация

на кода. Някои от които не биха били валидни в общия случай, защото са специфични за

приложната област или конкретното приложение.

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

оптимално работещи системи (приложения). Изходният код остава непроменен, като за

оптималността на модела се грижи специализирана софтуерна подсистема. Едно от важните

предимства на подхода е, че могат да бъдат прилагани концептуално различни софтуерни

трансформации в зависимост от зададените цели. Освен това, от основния алгоритъм могат да

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

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

допълнителни техники за оптимизиране на изпълнението му.

Наличието на специализирана софтуерна подсистема позволява разделение между модела,

генериран от разработчика и модела (за изпълнение), генериран от транслатора. Следователно

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

Основно изискване остава моделите да бъдат семантично еквивалентни.

При транслация до изпълним модел се използват множество представяния (модели).

Преминаването от един модел в друг не е новост при разработката на софтуер. Много от

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

Поради това много от трансформациите от един модел в друг са неясни и често необратими.

Използването на множество модели с ясни и обозрими механизми за трансформация би

позволило много по-фино транслиране и оптимизиране на компютърните програми. Тази идея е

основополагаща за разработвания от нас инструментариум SolidOpt.

Създаването на една такава многомоделна архитектура, каквато е показана на Фигура 4-1.


обобщава трансформирането на софтуерния модел от високо ниво до модел, изпълним от ВИМ.

В зависимост от целите, етапите (междинните модели) през които преминава трансформацията

може да са произволен брой.

Трансформационен оптимизационен метод (наричан за краткост оптимизационен метод или

оптимизация) в термините на инструментариума SolidOpt е модул, който преобразува

софтуерната програма така, че тя да удовлетворява някакви условия. Най-често тези условия

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

метрика за бързодействие, метрика за енергопотребление и т.н. Оптимизационни методи

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

• По-ефективното действие на метода – съществуват ситуации, при които дадена

оптимизация може да се приложи на няколко нива на абстракция. Обаче на всяко

едно ниво подобрението на програмата може да бъде различно. Затова е добре да се

избере моделът, над който резултатите са най-добри;

• По-лесното реализиране на метода за модела – например, намирането на мъртъв код

става много по-безпрепятствено в абстрактното синтактично дърво (abstract syntax

tree) (задачата се свежда до свързаност на графи) отколкото на сорс код ниво, а на

ниво CFG (Control Flow Graph) е елементарно.

Също така има методи, за които е необходим строго определен модел. Например, машинно

зависимите оптимизации обикновено се извършват на много ниско ниво на абстракция (ниво

модел за изпълнение). Реализирането на метод, заменящ умножение по степен на 2-ката с ляв

шифт [41] илюстрира този вид машинно-зависими оптимизации.

Една от целите на SolidOpt е да предложи достатъчно модели за извършване на

оптимизационни трансформации.

Валидна е следната схема, на която се основава действието на инструментариума:


10T −

0T

11T −

1T

11nT −−

1nT −

nM

1nMT −

nMT

1M

1MT

1

1MT −

0M

0

1MT −

0MT

Фигура 4-1: Взаимодействия между моделите

На Фигура 4-1 са използвани следните означения:

• iM – ниво на абстракция на модела, където [0; ]i n∈ . 0M е целевият модел, т.е. 0M е

изпълнимата програма;

• 1,i iM MT T − – трансформация на модела, където [0; ]i n∈ . Запазва нивото на абстракция

на модела;

• 1,i iT T − – междумоделна трансформация, където [0; 1]i n∈ − . Променя нивото на

абстракция.

Схемата описва отношението между моделите и начините за понижаване и повишаване

нивото на абстракция. Също така показва и механизма за трансформиране на модела. Трябва да

се обърне внимание на факта, че могат да съществуват множество модели от едно и също ниво

на абстракция. Тях ще наричаме модели с еквивалентно ниво на абстракция. Например, нека

предположим, че моделът 0M е предназначен за CISC изпълнител. Ясно е, че може да

съществува модел 0 'M , който да е предназначен за RISC изпълнител. Казваме, че 0M и 0 'M са

с еквивалентно ниво на абстракция.

Използването на така определената методология би улеснило съставянето на

оптимизационни методи, работещи на различни нива. Това предоставя гъвкавост при

разработката на сложни оптимизации като например сливане на класове, реструктуриране на БД

и др. За да се постигнат по-добри резултати, може да се налага някои оптимизации да работят на

няколко нива на абстракция на модела.

Използването на многомоделна архитектура понижава производителността на системата.

Също така се повишава и цялостната сложност на инструментариума. Но трябва да се

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


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

По-ниската производителност на оптимизациите се компенсира при постигането на по-

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

конкретното приложение.

4.1.1 ОБЛАСТ НА ПРИЛОЖЕНИЕ Наред с различните нива на абстракция на моделите е важно да се обърне внимание и на

областта на приложение.

Област на приложение или домейн, в термините на SolidOpt, ще наричаме множеството от

модели, при които дадената трансформация има смисъл. Разграничават се два основни типа

домейни от гледна точка на общоприложимостта на трансформациите:

• Общ домейн;

• Специфичен домейн.

Спец. 1

Спец. 2

Общ домейн

Спец. 3

Фигура 4-2: Общ и специфичен домейн

Типичен пример за оптимизации от специфичен домейн са:

• Премахване на ovf инструкции (виж 4.5.2.4.2) – представлява нееквивалентна

трансформация от I клас. Необходимото условие за прилагане на трансформацията е

алгоритъмът да не прави препълване;

• Елиминиране на проверките за границите в масиви – представлява нееквивалентна

трансформация I клас. Необходимото условие е проверките да бъдат в цикъл по

елементите на масива.

Идеята за домейн-специфични оптимизации налага логическа свързаност между моделите и

приложните им области. Това от своя страна води до многомерно представяне на Фигура 4-1.

Показани са само 2 от измеренията, които принципно се съдържат в схемата.

Интересен специфичен домейн е оптимизацията на софтуерни приложения и в частност

самооптимизацията на софтуерни системи. Възможно е SolidOpt да се самооптмизира като


преподрежда модулите си, изважда общите им части или прилага оптимизации върху

оптимизиращите модули.

Друг интересен специфичен домейн е домейнът потребителски интерфейс (UI), който може

да бъде редактиран и оптимизиран изцяло визуално. Това дава съвсем нови насоки на

изследвания и разработка на бъдещи системи.

Фигура 4-3: Връзка между домейните и нивата на абстракция

Важен домейн за SolidOpt е специфичният домейн “етап от жизнен цикъл на приложението”.

При него приложимостта на трансформацията се определя от времето (етапа), по което е

приложена. Например, прилагането на трансформация вземаща под предвид поведението на

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

“Разработка”.

4.1.1.1. Общ домейн

Общият домейн представлява надмножество на всички специфични домейни, ако се

UI

Компютърна графика

Математ.

�� CIL CFG, …, SSA AST …

UML

GUI Бази данни

Изрази

Шейдъри

Интерпретатори &

Компилатори

WEB

Оптимизация на софтуерни приложения


разглежда от гледна точка на областите на приложение. Ако се разглежда от гледна точка на

трансформациите, той налага най-много ограничения, защото дадената трансформация трябва

да е валидна за всички специфични области.

В общия домейн ще бъдат поставяни предимно известни оптимизационни методи, които

запазват семантиката на изпълнение и поведение.

4.1.1.2. Специфичен домейн

Теоретично, специфичните домейни могат да бъдат безброй много, защото всяко непразно

множество, което е подмножество на общия домейн може да се нарече специфичен домейн. На

практика обаче, интересните специфични домейни не са много.

Множеството на специфичните домейни е особено интересно за научни изследвания като

основни насоки са:

• Приложението на семантично нееквивалентни трансформации;

• Автоматизираното изследване на области на приложимост на трансформациите;

• Създаване на програми, чрез предварително дефинирани блокове;

• Създаване на многомоделни ЕП.

Предимството при използване на области на приложение е, че могат да бъдат прилагани

специфични трансформации, които не са валидни в общия случай (общия домейн).

Недостатък е, че многомоделната архитектура (Фигура 4-1) се усложнява неимоверно и в

идеалния си вид се превръща в мултиграфа с примки:


Фигура 4-4: Концептуален идеален вид на фреймуорка

При него всеки връх е един модел, а всяко ребро е междумоделна трансформация. Като всяко

ребро на графа може да съдържа списък от тежести, оценяващи различна характеристика на

трансформацията. Например реброто свързващо даден връх A с даден връх B може да има

списък с тежести оценяващи бързината на трансформация; количеството на загубената

информация; количеството на добавената излишна информация и т.н.

Ясно е, че на практика това е почти невъзможно, защото при добавяне на ново представяне

ще са нужни (n-1)! междумоделни трансформации, където n е броя на всички модели.

Реализация→Трансформации Стр. 64 от 126

4.2. ТРАНСФОРМАЦИИ

4.2.1 ВИДОВЕ ТРАНСФОРМАЦИИ Фигура 4-1 описва създаването на софтуер от две гледни точки – а именно от гледище на

разработчика и от гледище на ВИМ. Поставени са две основни цели – лекота при програмиране

и трансформиране на програмата до изпълним код. За да се постигнат тези цели е необходимо

да се премине през много нива на абстракция на моделите. Именно затова трансформациите ще

бъдат класифицирани от гледище на нивото на абстракция на модела. Ще бъде дискутирана и

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

4.2.1.1. Трансформации, променящи нивото на абстракция на модела

Правата посока (понижаване на абстракцията) е позната като компилация. Отбелязваме я с

, [0; 1]iT i n∈ − . Повишаването на абстракцията (обратна посока) е известна като декомпилация.

Отбелязваме я с 1, [0; 1]iT i n− ∈ − . Много ключова част от дискусията е съществуването и

допустимостта на тези трансформации.

Не винаги когато говорим за трансформация на моделите в други модели съществуват

коректни трансформационни функции. Понякога е допустимо функцията да не отразява точно

трансформацията от един модел в друг, а да предлага задоволяваща апроксимация. Такъв

пример е компилацията. Генерацията на неоптимален код от транслаторите е отчасти следствие

на тази “задоволяваща апроксимация”. Апроксимацията е задоволяваща, но единствено от

гледна точка на получаването на семантично-еквивалентни модели. Обратно, същата тази

“задоволяваща апроксимация” може да се окаже незадоволяваща от гледна точка на

оптималната работа на компилираната система. За целите на SolidOpt моделите в йерархията се

подбират така, че да съществуват достатъчно добри трансформационни функции. С други думи

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

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

то тя трябва да бъде минимална.

При понижаване на нивото на абстракция на модела обикновено се губи информация, защото

по-абстрактният модел не винаги е еднозначен. Нееднозначността не е проблем за хората,

поради естествения интелект, докато тя представлява проблем при КС. Затова при понижаване

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

на част от данните.

Обратно, при повишаване на нивото на абстракция на модела се налага да се използва по-

сложен анализ, чрез който да бъдат запълнена целенасочено-пропуснатата информация. Това


често е сложен, продължителен и лабилен към грешки процес.

4.2.1.2. Трансформации, запазващи нивото на абстракция на модела

Нека разгледаме трансформациите , [0; ]iMT i n∈ и 1, [0; ]

iMT i n− ∈ . По същество те представляват

преобразуване на модела в модел с еквивалентно ниво на абстракция (най-често в същия вид

модел). 1iMT − има за цел да върне преобразуването, направено от

iMT . Трябва да се отбележи, че

условия за съществуване на 1iMT − не са необходими. С други думи, ако съществува такава

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

Важни за концептуалното действие на инструментариума са функциите iMT . Те се използват,

за да преобразуват модела в друг по-добър от дадена гледна точка. Идеята може да се опише и с

логика от първи ред. Можем да дефинираме предикат, който показва дали новият модел е по-

добър от дадена гледна точка. Нека да дефинираме предикат ( , ) ( ) ( )P m m m mµ µ′ ′= < , където

( )xµ е функция определяща размера на модела на програмата , [0.. ]ix M i n∈ ∈ . Всяка

трансформация, водеща до удовлетворяване на P е подобряване на модела от гледна точка на

постигане на по-малък размер на програмния код.

Нека, например, разгледаме следната схема:

1kT −

kT

11kT −+

1kT +

kM

kMT

1kMT −

Фигура 4-5: Рефакторинг/Разбъркване

Схемата представлява k-та ( [0; ]k n∈ ) част от Фигура 4-1. Без ограничаване на общността, ще

предположим, че kM е сорс кода на програмата. Чрез многомоделната схема може да се

дефинира и терминът рефакторинг. Нека се дефинира предикат P , който отговаря на

определението за рефакторинг и се приложи трансформацията kMT . Ако след прилагането на

трансформацията предикатът е удовлетворен ще казваме, че сме направили рефакторинг на


кода. В общия случай ще казваме, че сме направили рефакторинг на модела kM .

Ако съществува 1kMT − бихме могли лесно да върнем модела в изходна позиция без

допълнително излишество (overhead), т.е. приложената трансформация е обратима.

Съвсем естествено в тази схема попада и друга добре известна техника за трансформация на

кода – разбъркване (obfuscation) [42]. При нея отново имаме промяна на кода на едно и също

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

(reverse engineering).

Тъй като трансформационните функции iMT са основополагащи за SolidOpt те трябва да

бъдат детайлно дискутирани.

Нека си представим, че моделът kM решава определен набор от проблеми (наричан

проблемна област (ПО)). Очертават се няколко типа трансформации от гледна точка на ПО и

новополучения модел:

• Новият модел решава всички проблеми от старата ПО;

• Новият модел решава част от проблемите на старата ПО;

• Новият модел не решава проблемите от старата ПО, но той е допустим;

• Новият модел не решава проблемите от старата ПО и не е допустим.

За да се формализира описанието е необходимо да се дефинира функция, която описва ПО,

решима с конкретен модел. Ще бележим функцията с ПОF . Нека iMT е трансформацията,

трансформираща модела iM в модела 'iM

Ще наричаме трансформацията iMT еквивалентна, тогава и само тогава когато:

( ) ( ')ПО i ПО iF M F M= (1)

Ще наричаме трансформацията iMT нееквивалентна трансформация, тогава и само тогава,

когато:

�( ) ( ) ( ) �( ): 'ПО i ПО i ПО i ПО iF M F M F M F M∃ ⊂ ≠ (2)

Ще наричаме трансформацията iMT нееквивалентна трансформация I клас, тогава и само

тогава, когато:

( ) ( )

1) ;

2) ' : .i

i

M

ПО i ПО i M

T е нееквивалентна трансформация

F М F М T е еквивалентна трансформация∃ ⊂ (3)

Ще наричаме трансформацията iMT нееквивалентна трансформация II клас, тогава и само

тогава, когато:


( ) ( ) ( )( )

1) ;

2) ;

3) ' : ' , ,

, .

i

i

M

M

ПО i ПО i ПО i

T е нееквивалентна трансформация

T не е нееквивалентна трансформация I клас

F М Q F М F М където

Q е предикат определящ допустимостта спрямо съответната цел

∃(4)

Ще наричаме трансформацията iMT абстрактна нееквивалентна трансформация, тогава и

само тогава, когато:

( ) ( ) ( )( ), . .

' : ' , ,

, .

iM

ПО i ПО i ПО i

T не е нито една от горепосочените т е

F М Q F М F М където

Q е предикат определящ допустимостта спрямо съответната цел

∃ (5)

Този вид нееквивалентност се прилага при доказателства, използващи опровергаване на

отрицанието.

За да се онагледи какво представлява нееквивалентната трансформация I клас ще разгледаме

следния пример. Нека имаме функция ( )( ) , ;f x x∈ −∞ +∞ и функция ( )( ) , 1;1g x x∈ − . Знаем че

( )( ) ( ) , 1;1f x g x x= ∈ − . Очевидно е, че при замяна на f(x) с g(x) ще съществува множество от

стойности, за което може ( ) ( )f x g x≠ и то е ( ] [ ); 1 1;x∈ −∞ − ∪ +∞ . С други думи, знаем (от

естеството на ПО), че трансформацията е нееквивалентна, но съществува подмножество, в

което тя е еквивалентна. Ако използваните аргументи на функцията ( )g x са в интервала, в

който тя е еквивалентна на ( )f x , то тя е допустима и се нарича нееквивалентна трансформация

I клас.

Фигура 4-6: Пример за нееквивалентна трансформация I клас

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

уравнение. Той е по-бавно сходящ към решението, отколкото методът на Нютон, но при метода

на Нютон се изискват повече знания за изследваната функция [46].

( )g x

1 -1 x

y

x

y

1 -1

( )f x


Следният пример за нееквивалентна трансформация II клас е валиден:

Нека имаме функция f (x) и функция g(x).

-1 -0.8 -0.6 -0.4 -0.2 0 0.2 0.4 0.6 0.8 1

1

0.8

0.6

0.4

0.2

0

f

g

Фигура 4-7: Пример за нееквивалентна трансформация II клас

Видно е, че няма подобласт, в която трансформацията би била еквивалентна. Въпреки това

трансформацията може да бъде осъществена, ако съществува предикат, който позволява

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

се със зададената цел.

Всички трансформации със загуба на информация са нееквивалентни от II клас:

• Компресиране на файлове – при този процес е допустима загубата на информация,

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

• Трансформиране на изображения – при този процес е допустимо загубата на

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

нейната загуба, поради факта, че човешкото око не възприема всички цветове от

спектъра на светлината;

• Дигитализиране на сигнали (в частност звук) – допустима е загубата на информация,

поради “несъвършенствата” на човешките възприятия (например на човешкия слух).

4.2.2 ВИДОВЕ ОПТИМИЗИРАЩИ ТРАНСФОРМАЦИИ Класификацията на оптимизационните трансформации (наричани оптимизации) е

аналогична на тази на трансформациите, тъй като оптимизациите са техен частен случай, при

който има определен критерий (един или повече), който трябва да бъде

минимизиран/максимизиран.


4.2.2.1. Еквивалентни оптимизации

При еквивалентните оптимизации същността на модела на системата се запазва. Заменят се

неоптималните части с по-оптимални в сравнение с даден критерий/критерии. Например,

дискутираният по-горе ляв шифт.

4.2.2.2. Нееквивалентни оптимизации

Нееквивалентните трансформации използват специфични знания за конкретната ПО или

конкретното приложение, които правят неприложимите оптимизации, приложими в областта.

• Оптимизации I клас – представляват нееквивалентни трансформации I клас (3) и е

приложимо “свиване” на дефиниционната област (ДО) до нова чрез използване на

допълнителни знания. Например, ако съществуват излишни за ПО проверки, то те

могат да бъдат отстранени. Така се получава различен модел на програмата, който

работи по същия начин за конкретната ПО;

• Оптимизации II клас – представляват нееквивалентни трансформации II клас (4) и не

могат да бъдат причислени към I клас, но съществува критерий, който указва, че са

приложими за конкретната област или приложение. Например, броят и точността на

операциите може да бъде обратно-пропорционална на дистанцията на

визуализирания обект от наблюдателя. Това знание би могло да бъде реализирано

като нееквивалентна оптимизация от II клас върху общия модел (алгоритъм) на

визуализация. Това е възможно, защото съществува предикат, който позволява

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

Реализация→Операционна среда Стр. 70 от 126

4.3. ОПЕРАЦИОННА СРЕДА Софтуерните приложения не са напълно независими. Обикновено зависят от много външни

фактори, например операционната система. В операционните системи работата на софтуера се

отделя като процес.

Компютърните програми трябва да се разглеждат като комбинация от процес, изпълняващ се

в работно време (runtime) и обкръжаваща среда. Това осигурява много по-точна информация за

поведението им.

Нека прегледаме следната концептуална схема:

Фигура 4-8: Абстрактна операционна среда

Вижда се, че процесите са поставени в околната среда и зависят от нейното естество.

Абстрактната схема помага за получаване на обща информация относно следващата схема:

n

Фигура 4-9: Операционна среда

Операционната среда е съставена от три основни елемента:

• Софтуерът, който обменя данни с приложението – Комуникацията между два отделни

процеса се осъществява единствено чрез обмен на данни. Той бива два вида –


директен и индиректен. Директният обмен се осъществява чрез изпращане на

съобщение (заявка) и получаване на резултат. Индиректният подход е при

комуникация с трети процес чрез посредник. Видът на данните и комуникацията

определят голяма част от поведението на процеса;

• Хардуерът – характеристиките на хардуерните компоненти определят много от

функционалните възможности на процеса. Например, процес уеб сървър не е

напълно функционален, ако няма хардуерна интернет карта (LAN карта). Хардуерът

определя цялостната производителност на процеса. Специално място трябва да се

отдаде на ВИМ (и в частност микропроцесорът), защото той определя какъв да бъде

модела от най-ниско ниво на абстракция ( 0M ), т.е. той указва значително влияние

върху многомоделната архитектура;

• Потребителят – процес, който обменя данни с приложението (може да е човек, но не

е задължително). Потребителят определя т. нар. потребителски поток от операции

(control flow) и поток от данни (data flow) на приложението. Потребителският поток

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

изпълняват от потребителя върху процеса. Потребителският поток от данни е

последователността от обменени данни.

Комуникацията на потребителя и хардуера със софтуерния процес се осъществява

индиректно – чрез респективно хардуер и операционна система.

Всички тези данни, зависещи от заобикалящата ги среда определят поведението на

софтуерните системи по време на изпълнение. Факт е, че в повечето случаи поведението по

време на изпълнение се различава от предвиденото поведение при разработка. Двете поведения

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

следствие от различните среди.

Ето защо е необходимо данните да бъдат анализирани и да се предприема стратегия за

приспособяване на модела към тях.

Например, нека имаме следната конструкция на ниво сорс код:

if (x == 1) {y = 5} else if (x == 2) {y = 12} ... else if (x == 30) {y = 4}

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

получава x е 30. Можем да приложим трансформация на модела и да получим:


if (x == 30) {y = 4} else if (x == 2) {y = 12} ... else if (x == 1) {y = 5}

По този начин програмата ще прави (най-често) 29 сравнения по-малко, което ще повиши

производителността й, като същевременно ще запази семантиката й. Трансформацията променя

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

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

архитектурните промени в хардуера. Например, създаването на производителна компютърна

програма при липсата на кеш памет в изпълнителя (Intel 8086) предполага определена

трансформация на модела. При добавянето на кеш в новата архитектура на ВИМ (Intel Pentium)

тази трансформация може да не доведе до оптимална работа.

Реализация→Еволюция на модела Стр. 73 от 126

4.4. ЕВОЛЮЦИЯ НА МОДЕЛА Събирането на данни за поведението и идеята за подобряване на системата много наподобява

на еволюционен процес. За да отговаря на дефиницията за софтуерна еволюционна система,

системата трябва да добавя или изменя функционалност. Разработваната от нас система за

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

оптималността на модела. Еволюцията на оптималността на модела обикновено е в определена

насока. Например, подобряване на дадена метрика (като размер на програмата, заемана памет,

бързодействие, енергоразход). Засега основната цел е подобряване на тези метрики без

изменяне на функционалността, т.е. без добавяне на нова функционалност.

Метриката представлява оценъчна функция за качеството на трансформация на модела. С

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

ще бъде предмет на бъдещи разглеждания е комбинацията между няколко метрики, т.е

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

отделните трансформации. 20% подобряване на бързодействието, 30% за подобряване размера и

50% подобряване на енергоразхода.

След като дискутирахме необходимостта от данни за средата трябва да отбележим как ще ги

използваме. С други думи, по-важно е правилното интерпретиране на получената информация,

отколкото самата информация. Защото може да се окаже, че неправилно интерпретирана

достоверна информация за действието на софтуерната система може да доведе до много по-

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

дали информацията е некоректна). Ще разделим методите за анализ, които ще се използват от

гледна точка на тяхната сложност. Тези методи дават насоки чрез какъв механизъм ще бъдат

интерпретирани данните:

• Прости математически модели и евристични методи – може да бъде търсена връзка

между данните както и формула, която най-точно да ги описва (Например, чрез

МНМК или други числени методи). Това дава сравнително прост и същевременно

силен механизъм за управление на данните. Намирането на такава функция често не

е лесна задача. При промяна на спецификата на данните е необходимо процеса по

моделиране и търсене на функцията да се извърши отначало. Използването на

математически модели и евристики строго зависи от проблемната област. Например,

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

производителност или енергопотребление – не чак толкова. За подробности виж [43].

Много важен е човешкият фактор в процеса.


• Статистични – използването на по-сложни математически модели за анализ на

данните не е новост. Съществуват доста инструментариуми и библиотеки, които

правят достатъчно добър анализ на данните. За подробности виж [44]. Чрез метода

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

състави по-добри евристики;

• Експертни системи – използването им дава много голяма гъвкавост при заключения,

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

оптимизиращите модули на базата на знания на експерти. Могат да обработват

автоматизирано големи обеми данни. Могат да се използват в комбинация със

статистичните методи за осъществяване на фин контрол над оптимизирането на

компютърните програми;

• Интелигентни системи – следващата крачка е използването на напълно

автоматизирани системи, контролиращи целия процес на оптимизация. Прилагането

на агенти, подпомагащи разработчиците в процеса на рефакторинг от рода на [45] с

цел оптимизация на изходния код, както и на ниво изпълним код, е добър подход за

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

и недостатъци, които няма да бъдат обсъждани на този етап.

Нашите изследвания са насочени основно към статистическите методи и експертните

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

Казаното дотук може да се обобщи чрез архитектурния шаблон:

Фигура 4-10: Специализация на програмата

След като имаме програмния модел и информацията за поведението му по време на

изпълнение еволюцията на оптималността му може да започне. На базата на получената


информация от взаимодействието със заобикалящата среда и вътрешното поведение на

системата се предприема стратегия за оптимизиране на модела. От дадения програмен модел

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

информация. Трябва да се отбележи, че това е важно когато системата има много потребители.

По този начин може да се получи оптимизирано копие за всеки конкретен потребител.

Нека разгледаме по-задълбочено връзката абстрактен програмен модел (АПМ) –

трансформация – конкретен програмен модел (КПМ).

Дан

ни

за

по

вед

ени

ето

Фигура 4-11: Еволюция на програмата

Чрез еволюционния шаблон се описва безкраен цикъл на оптимизация. От първоначалния

модел чрез трансформации получаваме конкретен, който се изпълнява от ВИМ. При

изпълнението му се събират данни за поведението за следващия цикъл на еволюция. При

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

• Старият модел (КПМi-1) – това намалява времето на адаптация за постигане на

оптимална работа;

• Абстрактният модел (АПМ) – това осигурява по-сигурното адаптиране на модела

спрямо данните. Още повече, че понякога еволюция от един конкретен модел в друг е

невъзможно;

• Събраните данни за обкръжението – осигуряват използването на точните

оптимизации, базирани на поведението на КПМ в средата.

Трябва да се обърне внимание, че всеки период за еволюция строго зависи от спецификата на

системата. Също така зависи и от времето, необходимо за събиране на достатъчно информация

за взаимодействието със заобикалящата среда. Не е задължително всички еволюционни периоди

да са през еднакъв интервал от време.

Една от важните характеристики на системите от гледна точка на изложените факти е


адаптивността на модела. Адаптивността на модела е способността на софтуерната система да

бъде подложена на еволюция на оптималността й. Строго специализираните приложения са по-

трудно адаптивни, поради многото специфични знания, заложени по време на разработка.

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

връзката й с времето. Нека предположим, че адаптивността на софтуера е доказана.

Нерационално е да мислим, че това би било полезно ако времето за адаптация е 100 години,

например. Затова важно свойство на адаптивността е нейната приемливост.

Адаптивността и нейните свойства са фактори, които указват решаващо влияние върху

качеството на работа на разработвания инструментариум SolidOpt. Затова ще бъде подложена на

бъдещ обстоен анализ.

Реализация→Експериментален инструментариум (SolidOpt) Стр. 77 от 126

4.5. ЕКСПЕРИМЕНТАЛЕН ИНСТРУМЕНТАРИУМ (SOLIDOPT) За пълното постигане на поставените цели е нужно да се изгради експериментален

инструментариум (SolidOpt) с долуописаната архитектура и средства.

4.5.1 АРХИТЕКТУРА Главната задача на архитектурата на инструментариума е да позволи лесното му

разширяване. Избрана е близка до SOA архитектура, която дава достатъчно добра гъвкавост и

лекота на разширение. SolidOpt се състои от подсистеми, формиращи ядро и услуги.

Ядрото реализира минималната необходима функционалност за нормалната работа на

приложение, разработено посредством SolidOpt.

Разгледахме разновидни софтуерни системи с различна сложност. Забеляза се, че почти

всички се нуждаят от:

• Достъп до ресурси – представлява обменът на данни на приложението. Входните,

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

необходимата гъвкавост. Местата на съхранение на ресурсите са качествено

различни, но имат една важна обща характеристика – време за достъп. Всяко място за

съхранение има различно време за достъп. Ресурсите са представени по начин,

зависещ от типа и спецификата им. Например, базите данни имат различно

представяне от html документите;

• Конфигурация – представлява процес, при който се задават стойности на

променливите в програмата от външни източници. Съвременните приложения

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

Параметрите от заобикалящата среда задават информация за текущите настройки и

състояние на КС и указват на програмата как да се интегрира в средата. Крайният

потребител задава специфични за него настройки, които трябва да бъдат валидни и

при следващи стартирания. Съвременният софтуер разчита на различни

конфигурационни средства, за да повишат ефективността си;

• Ускоряване на бавните изчисления (кеширане) – представлява механизъм, чрез който

се избягват излишните повторни изчисления. Излишни изчисления са тези, които

след изпълнението си не показват различен резултат от предишното пресмятане.

Излишните изчисления забавят програмата, затова добре-проектираният софтуер има

кеширащи механизми, намаляващи ненужните операции с данните.

Горните три подточки обобщават минималните изисквания за софтуерна система. С други

думи една добра софтуерна система притежава най-малко механизми за достъп до ресурси;


конфигуриране и кеширане. Тези механизми не е задължително да са в явен вид, т.е. да са ясно

обособени.

Непрекъснатите стрелки на Фигура 4-12 показват как би трябвало да се използват

подсистемите. Прекъснатите стрелки показват още един начин да се използват трите

подсистеми, но той е неоптимален.

За достъп до ресурси е по-добре да се използва кеширащата система, защото тя може да

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

Конфигурацията трябва също да използва кеширащата система за достъп до конфигурационни

файлове, за да може времето за достъп, където е възможно, да бъде оптимизирано.

Конфигур. подсистема

Кешираща подсистема

Подсистема за ДХР

Услуги Услугa 1

Услугa 2

...

Услуга N

Фигура 4-12: Схема на начина на използване на подсистемите

Ядрото на SolidOpt реализира този минимализъм явно – чрез подсистеми. Идеята е ядрото да

бъде универсално, т.е. да може да се използва в произволно приложение. Освен ядрото (Фигура

4-13) SolidOpt се състои от разнообразни услуги.

Фигура 4-13: Схема на абстрактното взаимодействие между ядрото и услугите на SolidOpt

Услугите специализират инструментариума в инструментариум за автоматизирани

оптимизации. Те позволяват на фреймуорка да бъде разширяван скаларно. Броят и характерът

им показва приложимостта на SolidOpt.

Контролът над управлението се предава на услугите в определен от ядрото ред. След

завършване на действието на услугата, тя връща управлението на ядрото и се стартира друга


услуга. Услугите могат да предават управлението йерархично на други услуги, но при условие

че извиканият го връща обратно на извикващия:

Фигура 4-14: Схема предаване на управлението от ядрото към услугите

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

управление.

4.5.2 УСЛУГИ

4.5.2.1. Подсистеми

4.5.2.1.1. Подсистема за достъп до хетерогенни ресурси

С развитието на компютърната техника и информационните технологии много често се

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

взаимодействащо с различни източници е важно да осъществява бърз и ефективен достъп до

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

данни, на отдалечени компютри и др.

Съхранението на ресурси по различен начин дава множество предимства като повишаване на

сигурността, бърз достъп, ефективна обработка и др. Например, ако на приложението е

необходима конфигурация, която не трябва да бъде променяна от клиента е по-добре, от гледна

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

система.

Хетерогенните ресурси представляват разнородни представяния на данни, което прави

обработката им по-трудна, за разлика от обработката на еднородно представяне. Ако

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

отделно, тогава би имало следните недостатъци:

• Ненужно усложняване на логиката на системата;

• Трудно добавяне на нов вид обработка на ресурс;

• Сложна трансформация от един вид ресурс към друг, при необходимост.


Описаните недостатъци биха увеличили размера на програмата и нейното време за

изпълнение. Добър подход е използването на еднородно (междинно) представяне, което би

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

ресурси, но същевременно да ги използва.

Фигура 4-15: Схема на подсистема за хетерогенен достъп (ПХД) до ресурси

Схемата описва подсистемата за достъп до хетерогенни ресурси, която се състои от:

• Клиентско приложение – компютърната програма, използваща хетерогенни ресурси;

• Доставчик на ресурси – средството, чрез което клиентско приложение осъществява

достъп до междинното представяне;

• Междинно представяне – общо, унифицирано представяне на ресурсите;

• Група за импорт – съдържа механизми за достъп и конвертиране на конкретен ресурс

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

• Група за експорт – съдържа механизми за достъп и конвертиране на междинното

представяне в конкретен ресурс.

Добавянето на нов тип импорт/експорт се осъществява лесно и без да нарушава останалата

логическа свързаност на системата. Лесноосъществимото добавяне на нови типове

импорт/експорт улеснява поддръжката и бъдещото разширение на системата.

Има възможност за преминаване от едно представяне в друго. Например, конфигурационните

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

отдалечен компютър.

Интересен въпрос е съхраняването на ресурса на части. Например, част от ресурса да бъде

съхранена във файл, друга в база данни, трета в уеб и т. н. По този начин се решава проблемът,


когато всяка част от ресурса използва различно свойство на мястото си за съхранение. Ако част

от ресурса съдържа в себе си поверителна информация, то тя ще бъде съхранена на отдалечен

сървър, ако друга част се нуждае от прочитане многократно (т. е. бърз достъп) ще се съхрани в

база данни и т. н. Механизмът би дал отлична гъвкавост на ресурсите, но реализацията му е

трудна, особено в частта за обединяване на частите.

Чрез обособяването на подсистема за достъп до хетерогенни ресурси се изнася логиката за

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

повишаване на слабата свързаност.

Реализацията на системата ще бъде включена като услуга в общия инструментариум SolidOpt

с наименованието Stream Provider.

4.5.2.1.2. Кешираща подсистема

След като стана дума за разнородните ресурси и различните им места за съхранение, трябва

да се обсъди времето за достъп до тях.

Обикновено, различните места на съхранение на ресурси имат нееднакво време за достъп.

Достъпът до някои хранилища е по-бавен, но те притежават редица други предимства като

сигурност. Например, достъп до ресурс, съхранен на файловата система на компютъра е много

по-бърз, отколкото достъп до ресурс в интернет. Обаче, ресурсът на файловата система е по-

несигурен, защото може да бъде модифициран по-безпрепятствено.

За да се избегнат недостатъците, породени от времето за достъп е необходимо да се изгради

компенсиращ механизъм.

Разработването на кешираща подсистема не е новост. Кеширащите системи съхраняват

актуално копие от използваните ресурси на бързо-достъпни места (оперативна памет, файлова

система и др.).

Основна цел е разработване на преизползваема кешираща подсистема, която да бъде

включена към инфраструктурата на SolidOpt.

Хранилище на кешираните

ресурси

Init

Touch

IsValid


Get

Update

Delete

Фигура 4-16: Схема на кешираща подсистема

Направена е стандартна реализация, като при обикновените кеширащи системи, но също така


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

използване.

Една кешираща система съдържа следните основни операции:

• Инициализиране на нов елемент (Init) – създава се място за кеширане на елемент в

хранилището;

• Изтриване на съществуващ елемент (Delete) – изтрива заделеното място за елемента

в хранилището;

• Достъп до кеширан елемент (Touch) – проверява дали елементът е валиден, ако да,

модифицира времето на последното му използване;

• Проверка за валидност на елемент (IsValid) – проверява дали елементът, съхранен в

хранилището е още валиден;

• Извличане на ресурса от оригиналното му място за съхранение (Get).

Клиентското приложение използва кеширащата подсистема като “пълномощно” [25] за

осъществяване на отложен достъп до ресурсите. Фигура 4-17 онагледява взаимодействието

между клиентското приложение и кеширащата подсистема.


Клиентско приложение

Ресурси

Фигура 4-17: Схема на действието на кеширащата подсистема

ПХД улеснява реализацията на клиентското приложение, а кеширащата подсистема я

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

обръща за достъп до ресурси (ако е необходимо) към ПХД.

4.5.2.1.3. Конфигурираща подсистема

Съвременните приложения все по-често обръщат сериозно внимание на средствата за

настройка от страна на системните администратори и от крайните потребители. Затова

обикновено една от базовите подсистеми на ядрото на всяка система е тази за конфигуриране на

приложението.

Конфигурирането е процес на настройка на определени параметри на елементите на


системата (функции/методи, обекти, класове, модули, библиотеки, подсистеми, динамично

зареждани модули и др.) [59].

Разнообразните формати предполагат и различен начин да ползването на конфигурацията,

както и различна степен на гъвкавост, бързодействие и защита на параметрите от

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

• „INI“ и “conf” текстови файлове [51];

• Windows Registry йерархична база от данни [52];

• XML файлове [53], [54], [55], [56];

• YAML файлове [57], [58];

• Binary файлове със специфичен за програмата формат;

• Сорс код с константи (параметри) [58] и др.

Източници на конфигурационни данни могат да бъдат не само файлове, но и БД, променливи

в обкръжението, параметрите от командния ред на програмата и др. Затова ще ги наричаме с

общото име конфигурационни източници.

Логиката на конфигуриране може да бъде:

• Константи – твърдо зададени константи в кода на програмата. Този подход има

множество недостатъци. Изисква прекомпилиране на модула и/или програмата след

всяка промяна на параметрите (константите). Понякога е удобен за ползване в

скриптови езици. Едно от предимствата му е скоростта на достъп;

• Конфигурационен файл – параметрите се четат от файл от всеки елемент на

системата, който имат параметри за настройване. Сравнително добър подход, но

може да се дублира логика по обработка на файла на много места, по-трудно се

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

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

Предимство е, че конфигурационните данни са обособени на едно място и са лесни

за промяна;

• Наложено конфигуриране – системата зарежда параметрите и настройва променливи

или полета в обектите, които трябва да бъдат конфигурирани. Недостатък на този

подход е, че се настройва всичко независимо дали параметърът ще се ползва след

това или не. Друг недостатък е, че на обектите могат да се настройват само

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

конфигурационната подсистема, а не във всеки елемент;

• Конфигуратор – обект в системата зарежда параметрите при необходимост и отговаря

на запитванията на обекти или функции, които имат параметри за настройване. Може


да реализира логиката на обединяване на повече източници (файлове), приоритет на

конфигурациите, сигурност, кеширане, зареждане при необходимост и др.

Конфигураторът може да връща отделни стойности (низове, числа и др.) или

конфигурационни обекти (съдържащи само полета с конфигурационните данни),

структури, масиви и др.

Организацията на параметрите може да бъде:

• Линейна – обикновено са организирани като списък от атрибут-стойност. Тази

организация може да се разглежда като частен случай на следващата, но с едно ниво

на йерархията;

• Групирана (йерархична на две нива) – имената на атрибутите са групирани съобразно

някакви критерии;

• Йерархична – имената на атрибутите имат йерархия и са групирани съобразно

някакви критерии;

• Граф – обикновено йерархия с вътрешни и/или външни хипервръзки, т.е. в даден

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

Организацията на конфигурационните източници (еднотипни или разнотипни) може да бъде:

• Един или повече източници на едно ниво – обикновено съдържат настройките за

всички потребители. Тази организация се използва често при по-прости приложения;

• Един или повече източници на две нива – обикновено съдържат настройки за цялата

система и за всеки потребител самостоятелно. Това е много често срещан случай;

• Източници, организирани на няколко (много) нива – например за потребителя, за

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

конкретните към по-общите. Така липсващите параметри в едната се „наследяват“ от

по-общата конфигурация и т. н.

Права за промяна на стойностите на параметрите (зависи основно от защитата на

конфигурационните източници – файлове, БД и др.):

• Без ограничения;

• Директно от крайния потребител;

• Само от администратора на системата;

• От разработчика;

• Комбинация от по-горните и други.

Нека разгледаме логиката на конфигуриране на софтуерни системи от възникването на

нуждата от конфигурация до сега.

В началото, при разработката на софтуер се е забелязало, че има едни и същи изрази, които се


използват на множество места в програмата (3.14, например). Това довежда до необходимостта

изразите да се изнесат като константи, за да се променят по-лесно.

След като броят на константите нараства и стойностите на някой от тях зависят от

конкретния потребител и/или КС се налага да бъдат изнесени в конфигурационни файлове.

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

да се изисква прекомпилация на програмата. Това предимство, обаче, довежда до сериозен

недостатък – четенето и записването на константи в конфигурационния файл е много по-бавно.

Също така конфигурационните параметри от файловете се използват чрез променливи в

програмата, което освен, че е по-бавно, не позволява да бъдат приложени оптимизации като

свиване и разпространение на константи и други.

Следващата стъпка е изнасяне на конфигурационните файлове на отдалечени машини, за да

се постигне по-високо ниво на сигурност, ако е необходимо. Това улеснява администрирането на

настройките на множество КС, докато ефективността на четене/запис намалява още повече.

Развитието на конфигурационните файлове е подобно. Всеки следващ формат е с усложнена

логика (поддържат валидатори, преименуващи механизми (mapping), йерархични отношения и

др.). С други думи конфигурационните файлове се стремят да вложат допълнителна логика

върху данните, което на практика е ЕП.

Изводът е, че параметрите в конфигурационните файлове са неразделна част от софтуерната

система, но поради различни съображения са изнесени извън нея.

Ако се използват съвременни технологии като dotNet и Mono.Cecil на Mono е възможно да се

запазят предимствата от описаните подходи и да се елиминират голяма част от недостатъците

им.

Основна цел на конфигурационната подсистема на SolidOpt е да генерира програмен модул,

който да бъде включен към програмата. По този начин ще се запази отделеността на

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


Фигура 4-18: Схема на действието на конфигурираща подсистема

На Фигура 4-18 е описан начинът, по който конфигурационната подсистема създава модул

(assembly) към програмата. Използва се междинно представяне, за да е възможно йерархичното

групиране на конфигурационните параметри.

Предимствата от използване на модул (assembly), съдържащ конфигурация са:

• Модулът е силно типизиран – избягват се стандартните претипизации, а също така не

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

некоректна операция е събиране на низ (който е записан с цифри, но семантиката на

използването му е – низ) с число;

• Модулът се взема предвид от компилатора – компилаторът анализира модула заедно с

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

разпространяване на константи и други;

• Модулът се “вижда” от помощника при писане на сорс код – при активиране на

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

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

Една от най-важните части на конфигуриращата подсистема е нейният механизъм за обратна

съвместимост. Механизмът дава възможност за лесно добавяне на нов формат, от който да бъдат

получени данните за генерирания модул. Също така преобразуването от поддържан

конфигурационен формат към друг става елементарно.

Повечето конфигурационни файлове са в текстов формат и не може да се разпознае веднага

конкретният тип на параметъра. Типът е нужен на междинното представяне, за да може да

генерира правилно конфигурационния модул. Затова има допълнителна логика, която


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

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

Конфигурационната подсистема има логика по преименуване на параметри. Преименуването

(mapping) е процес, при който се променят част или целите имена на параметрите.

Преименуването е няколко вида:

• Потребителско преименуване – приложимо е, когато разработчикът прецени, че

новите имена биха били по-полезни, по-разбираеми или по-интуитивни;

• Валидационно преименуване – приложимо е, когато форматът, към който

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

поддържа част от символите, използвани в имената на параметрите или тези символи

са специални. Например, в INI специални символи са “ [“, “] “,”=“. Ако има

параметри, които трябва да се съхранят в INI и съдържат в имената си тези символи,

то те трябва да се преименуват, защото ще се получи невалиден конфигурационен

файлов формат.

• Оптимизационно преименуване – приложимо е при използване на ненужно дълги

имена. Ненужно дългите имена използват повече място в ОП и е добре да бъдат

редуцирани с цел по-ефективно изпълнение на програмата.

Спецификата на разпознаването на типове и преименуването изисква елементите (класовете)

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

При разпознаване на типовете е важно да не се разпознае по-общ тип. Например, ако се

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

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

информация, нарушаваща системната логика.

Строгата последователност при преименуването е необходима за специфични вериги на

преименуване. Например, може да има преименуващ клас, който очаква върху имената

предварително да е приложено валидационно преименуване.

За да се реши адекватно проблемът, се разработи композитен клас (шаблон за дизайн

“Композиция” [25]), който може да включва повече от един елементи, които ще бъдат изпълнени

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

обработва от системата по същия начин, по който се обработват останалите некомпозитни

елементи.

Направени са няколко вида тестове върху конфигурационната подсистема. Направени са

сравнения с разнообразни съществуващи решения за различни ЕП и технологии. Тестовете

включват четене на един или повече параметри определен брой пъти и засичане на времето,


необходимо за операцията. Резултатите могат да бъдат видени в Таблица 4-1. Тестовете са

проведени на КС “Intel Core 2 Duo T5750 @ 2GHz, 2x2GB RAM”.

ЕП Тип тест Технология Брой параметри

Тип парметър Итерации Време

(ms) Време

(ms)Итерации

C# INI – SolidOpt .NET 2.0 1 Integer 107 63 0,0000063 C# INI – Native Call .NET 2.0 1 Integer 105 15319 0,1531900 C# XML – .NET .NET 2.0 1 Integer 107 10686 0,0010686

JAVA INI – ini4j JAVA SE 6 1 Integer 107 3482 0,0003482

Delphi INI – VCL VCL 1 Integer 105 14571 0,1457100

C# INI – SolidOpt .NET 2.0 1 String 105 15 0,0001500 C# INI – Native Call .NET 2.0 1 String 105 16536 0,1653600 C# XML – .NET .NET 2.0 1 String 105 156 0,0015600 JAVA INI – ini4j JAVA SE 6 1 String 105 46 0,0004600 Delphi INI – VCL VCL 1 String 105 14508 0,1450800 C# INI – SolidOpt .NET 2.0 2 Integer, String 105 31 0,0001550 C# INI – Native Call .NET 2.0 2 Integer, String 105 31575 0,1578750 C# XML – .NET .NET 2.0 2 Integer, String 105 312 0,0015600 JAVA INI – ini4j JAVA SE 6 2 Integer, String 105 118 0,0005900 Delphi INI – VCL VCL 2 Integer, String 105 48235 0,2411750 C# INI – SolidOpt .NET 2.0 20 String 105 16 0,0000080 C# INI – Native Call .NET 2.0 20 String 103 3120 0,1560000 C# XML – .NET .NET 2.0 20 String 105 30920 0,0154600 JAVA INI – ini4j JAVA SE 6 20 String 105 582 0,0002910 Delphi INI – VCL VCL 20 String 103 2933 0,1466500 C# INI – SolidOpt .NET 2.0 100 Integer, String 105 31 0,0000031 C# INI – Native Call .NET 2.0 100 Integer, String 103 16286 0,1628600 C# XML – .NET .NET 2.0 100 Integer, String 105 12745 0,0012745 JAVA INI – ini4j JAVA SE 6 100 Integer, String 105 2684 0,0002684 Delphi INI – VCL VCL 100 Integer, String 103 14851 0,1485100

Таблица 4-1: Сравнение на бързодействието на конфигурационната подсистема

4.5.2.1.4. Уеб подсистема

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

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

представителен сайт. Целта на уеб подсистемата е да представи основните идеи на SolidOpt.

Освен представителна част уеб подсистемата има секции като:

• Документация – различна по вид и целева група документация, улесняваща

потребителите;

• Хора, допринесли за развитието на системата – при интерес от потребителите те

могат да се свържат с участниците в проекта;

• Проекти, свързани със системата – при интерес от потребителите те могат да се

включат в разработката.


Уеб подсистемата е достъпна на адрес http://sandbox.solidopt.org/.

4.5.2.1.5. Подсистема за онлайн оптимизация

Инструментариумът има реализирана уеб услуга посредством езика WSDL. Предимствата на

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

Стандартизирането на уеб услугата с език като WSDL улеснява изграждането на онлайн

приложения от хора, които не са пряко свързани с разработката му. Пример за това е изградената

подсистема за онлайн оптимизация[26] от Васил Гъров, който не е пряко свързан с разработката

на други части от SolidOpt.

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

интерфейс, позволяващ на потребителите да използват SolidOpt в реално време. Фигура 4-19

показва действието на подсистемата.

Фигура 4-19: Действие на подсистемата за онлайн оптимизация

Подсистемата действа на няколко стъпки:

• След отваряне на страницата потребителя вижда наличните оптимизационни методи;

• Потребителя зарежда необходимите му оптимизационни методи;

• Потребителя конфигурира избраните оптимизационни методи;

• Потребителя посочва желан изпълним файл за оптмизация;

• Подсистемата изпраща изпълнимия файл и конфигурацията на оптимизационните

методи на сървърите, където е SolidOpt;

• SolidOpt извършва оптимизацията и връща новополучения файл на подсистемата,

която го изпраща на потребителя.

Подсистемата за онлайн оптимизация е достъпна на адрес http://solidopt.org/online/.


4.5.2.2. Междумоделни трансформации

Този вид трансформации е изключително важен за поддържане на целостта на

инструментариума. Трансформациите представляват iT (компилация) и 1iT − (декомпилация) от

Фигура 4-1 в секция 4.1.

Инструментариумът засега предлага две нива на абстракция, наречени CIL и AST:

0MT2MT

1MT

Фигура 4-20: Текущо развитие на инструментариума SolidOpt

4.5.2.2.1. Ниво CIL

Нивото на абстракция описва инструкциите на ВИМ като дву-свързан списък. Всяка

инструкция съдържа указател към следващата (ако има такава) и към предишната (ако има

такава). Нивото CIL е реализирано от Mono и се нарича Mono.Cecil. Много подходящо е за

прилагане на сравнително лесни оптимизации като премахване на ненужни инструкции, замяна

на инструкции с по-ефективни и т. н. Друго предимство е, че Mono.Cecil може да генерира

почти автоматично нова програма (assembly), т.е. изпълнима от ВИМ програма.

Нивото на абстракция CIL е добра основа за повишаване на абстракцията на програмния

модел.

4.5.2.2.2. Ниво CFG

Нивото на абстракция Control Flow Graph представя програмата като свързани блокове,

съдържащи CIL инструкции. Всеки блок съдържа множество от инструкции, които се

изпълняват последователно, т.е нямат преходи. Преходите са реализирани като връзки между

блоковете.

В момента всеки блок има връзки към следващите го от гледна точка на изпълнението на

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

реализирана.


4.5.2.2.3. Ниво AST

Нивото на абстракция AST представя програмата като абстрактно синтактично дърво.

Обхожда се CIL нивото, симулира се системният стек и се генерира дърво. За да се реализира

задоволително функцията 10T − се използва проект с кодово име Cecil.Decompiler, който е в много

ранна фаза на разработка. Наложиха се немалко промени в проекта. Трябва да се обърне

внимание, че основната цел на проекта Cecil.Decompiler е генерация на сорс код и следователно

нивото на абстракция AST не е достатъчно добре “пригодено” за лесно реализиране на сложни

оптимизации.

Създадена е връзката 0T , за да е възможно превръщането на абстрактното синтактично дърво

в обратно в CIL.

4.5.2.3. Оптимизационни трансформации (методи)

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

функциите iMT от Фигура 4-1 в секция 4.1. Методите преобразуват модела, над който работят в

модел от същото ниво на абстракция, но по-добър спрямо дадена характеристика.

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

изпълнява по-ефективно, т.е. заема по-малко памет и работи по-бързо.

Оптимизационните трансформации са същността на разработвания проект и от техните

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

внимателно проектирана и реализирана.

Реализирането на оптимизационна услуга в SolidOpt не е сложно. Необходимо е:

• да се избере ниво на действие на оптимизацията;

• да се реализира интерфейс с един метод, който трансформира модела в нов.

4.5.2.4. Оптимизационни методи на ниво CIL

4.5.2.4.1. Премахване на nop инструкции

В асемблер инструкцията nop не извършва никаква операция. Обикновено се използва за:

• слагане на точка на прекъсване;

• заменяне с друга инструкция (обикновено при преходи напред);

• изравняване на отмествания.

В редки случаи при изравняване на отместванията nop подобрява производителността.

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

методи, чиято реализация включва заместването на дадена инструкция с nop.

В CIL, nop се генерира с цел да се подобри дебъгирането на програмата. След завършване на


разработката е добре, ако не са отстранени всички nop инструкции, да се отстранят.

Оптимизацията “Премахване на nop инструкции” действа на ниво на абстракция CIL. В Soli-

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

• Да се демонстрира необходимият минимум за създаване на оптимизационен метод;

• Да може да се съпоставят оптимизациите, приложени на различни нива на

абстракция.

Пример за действието на оптимизацията е:

Преди премахване След премахване

Таблица 4-2: Пример за премахване на nop инструкции

След като се премахнат всички nop инструкции, размерът на програмата намалява. Има

компилатори, които дори в режим “генерация на програма за разпространение” генерират

инструкции, които не правят нищо. В такъв случай една подобна оптимизация спомага за

изчистване на кода.

4.5.2.4.2. Премахване на ovf инструкции

Аналогично на 4.5.2.4.1 ArithmeticOverflowRemover заменя инструкциите, съдържащи

проверка за препълване с такива, при които няма. Това подобрява производителността, но

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

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

би била валидна само, ако алгоритъмът е реализиран така че да не създава препълвания.

4.5.2.4.3. Вграждане на метод

В обектно-ориентираното програмиране, методът (член функцията) е специален вид

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

Най-общо, при вграждането на метод, тялото на извиквания метод се замества в извикващия

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


запази семантиката и последователността на изпълнение. Предимствата и недостатъците на

оптимизационната техника върху производителността на КС са дискутирани в 3.4.10.1.

Предимствата на реализацията на ниво CIL е нейната простота и ефективност. За сравнение

виж 4.5.2.6.1.


Таблица 4-3: Пример за вграждане на програма на ниво CIL

4.5.2.5. Оптимизационни методи на ниво CFG

4.5.2.5.1. Елиминиране на “dead code”

CFG представя приложенията като граф от свързани по между си блокове. Елиминирането на

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

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

може да бъде отстранен.

4.5.2.6. Оптимизационни методи на ниво AST

4.5.2.6.1. Вграждане на метод

Предимствата на реализацията на метода на ниво AST са, че алгоритъмът ще се сведе до

търсене в дърво и замяна на извикването с модифицираното поддърво на извиквания метод.

За изясняване на всички случаи, които трябва да се предвидят в алгоритъма за вграждане на

метод е необходимо поне неформално да се дефинира декларирането на метод. Значимите части

за алгоритъма в декларацията на метод са:

• Връщана стойност;

• Входни параметри;

• Входно-изходни параметри;


• Изходни параметри.

За формализиране на извикване и декларация на метод може да се направи справка, както

следва: CIL – [60]; ЕП, свеждащ се до CIL, например C# – [61].

Вижда се, че трябва да се анализират няколко варианта, оказващи влияние върху вграждането

на метод. Вариантите, подредени възходящо по сложност, са:

1. Методът да има входни параметри (например, void MethodExample(int a, int b, …));

2. Методът да връща и резултат (например, int MethodExample(int a, int b, …));

3. Методът да има и входно-изходни параметри (например, int MethodExample(int a, ref int

b, …));

4. Методът да има и изходни параметри (например, int MethodExample(int a, ref int b, out

int c,…));

5. Методът да има и сложни изрази със странични ефекти като параметри (например, int

MethodExample(int a, ref int b , out c, ++�, …) , където “a” е глобална променлива);

6. Методът да има и други методи като параметри, които имат странични ефекти (int

MethodExample(int a, ref int b , out c, ++�, f(x), …), където “a” е глобална променлива, а

f(x) е извикване на функция, която има странични ефекти).

Казва се, че подпрограма (метод в частност) има страничен ефект като допълнение към

връщаните стойности, ако модифицира някакво състояние или има наблюдаемо взаимодействие

с външния (за подпрограмата) свят. Например, подпрограма може да променя глобална или

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

ефекти.

Направената по-горе декомпозиция на подпроблеми помага да се дадат кратки и ясни

решения на подпроблемите. Накрая решенията на подпроблемите се обединяват и дават

решение на целия проблем.

Нека да разгледаме случая, когато методът има входни параметри.

За да се вгради този метод, е необходимо да се сложи етикет в края на тялото на метода за

вграждане. След това всеки израз за възврат (“return”) да се замени с безусловен преход (“goto”)

в края на тялото на извикания метод (където вече е сложен етикет). Накрая, позоваването на

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

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

Нека разгледаме случая, когато методът връща и резултат.

За да се вгради методът коректно, е необходимо освен горната стъпка да се декларира

променлива, в която ще се съхранява резултатът от метода. След това трябва да се добави

присвояване към резултатната променлива преди всеки безусловен преход (“goto”) към края на


тялото. Ако извикваният метод е използван в израз за присвояване (double s = f(x);), тогава

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

Нека разгледаме случая, когато методът има и входно-изходни параметри.

Входно-изходните параметри се отличават от входните параметри по това, че се предават по

указател, т.е. тяхната стойност може да бъде променена от метода. Този вид параметри трябва да

се заменят от локалните променливи, които са актуални параметри в извикването. Единственото

условие за да се извърши замяната коректно е локалните променливи, с които ще се заменя да

имат вече стойност.

Нека разгледаме случая, когато има и изходни параметри.

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

предварителна инициализация на локалните променливи, с които ще се заменя. Добавя се

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

вграждания метод.

Нека разгледаме последните два случая. Те на практика представляват един и същ случай,

защото извикването на метод (f(x) в примера) е също израз.

При наличие на странични ефекти е необходимо да се запази редът на изпълнение на

изразите. Затова най-лесно е, изразите да бъдат изнесени. Изнасянето на израз става чрез

деклариране на локална променлива и присвояването му към нея. След това изразите в

извикването се заменят със съответните им локални променливи. Така извикването на метод с

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

Трябва да се обърне внимание на следните варианти за вграждане на метод в различни

конструкции, написани на псевдо-код:

Условен преход преди изнасяне Условен преход след изнасяне

if (<израз_с_изв_на_метод>) { ... }

<променлива> = <изв_на_метод>; if (<модиф_израз>) { ... }

Условен преход преди изнасяне Условен преход след изнасяне

switch (<израз_с_изв_на_метод>) { ... }

<променлива> = <изв_на_метод>; switch (<модиф_израз>) { ... }


Цикъл с предусловие преди изнасяне Цикъл с предусловие след изнасяне

while (<израз_с_изв_на_метод>) { ... }

e1: <променлива> = <изв_на_метод>; if (<модиф_израз>) { ... goto e1: }

Цикъл със следусловие преди изнасяне Цикъл със следусловие след изнасяне

do { ... } while (<израз_с_изв_на_метод>);

do { ... <променлива> = <изв_на_метод>; } while (<модиф_израз>);

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

Демонстрирана е и действащата услуга. Предложени са два варианта – единият е сорс код,

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

са извършени описаните трансформации.


Таблица 4-4: Пример за вграждане на програма на ниво AST (като сорс код)



Таблица 4-5: Пример за вграждане на програма на ниво AST (като дърво)

4.5.2.6.2. Свиване на константи

Друга оптимизационна услуга е свиването на константи (3.4.5). Услугата ще бъде разработена

върху ниво на абстракция AST. Оптимизацията е сравнително проста като реализация и

действие, но ефективна. Тя действа върху конструкции от вида:

• <унарен_оператор><израз> или <израз><унарен_оператор>, наречен унарен израз

(Unary Expression);

• <израз1><бинарен_оператор><израз2>, наречен бинарен израз (Binary Expression).

Целта е да се провери дали <израз> или съответно <израз1> и <израз2> са известни литерали

(Literal Expression). Литералите са обикновено прости типове като int, float, double и други. След

като се установи, че унарният/бинарният оператор действа върху литерали да се извърши

опростяване като се приложи съответната операция върху операндите и да се запише направо

резултатът.

<унарен_оператор> е оператор действащ върху един операнд. Унарни операции, които ще

бъдат опростявани са:

• Унарен минус;

• Побитово отрицание (Bitwise Not);


• Логическо отрицание (Logical Not).

<бинарен_оператор> е оператор действащ върху два операнда. Бинарни операции, които ще

бъдат опростявани са:

• Събиране;

• Изваждане;

• Умножение;

• Деление;

• Целочислено деление;

• Побитово “и”;

• Побитово “или”;

• Побитово изключващо “или”;

• Изместване наляво (Left Shift);

• Изместване надясно (Right Shift);

• По-голямо (>);

• По-голямо или равно (>=);

• По-малко (<);

• По-малко или равно (<=);

• Равно (==);

• Различно (!=);

• Логическо “и”;

• Логическо “или”.

Следния пример демонстрира действието на услугата:

Преди свиване След свиване

Таблица 4-6: Пример за свиване на константи


Заместването директно на резултатите на мястото на унарните/бинарните изрази намалява

броя на изчисленията, индиректните извиквания и понякога премахва излишните box-

ing/unboxing на типовете, които са стойности.

Услугата може да се използва след прилагане на услугата за вграждане на метод (както е в

примера), защото трансформациите оставят много литерални изрази неразвити. Така

комбинацията от двата метода – вграждане и свиване на константи дава по-добри резултати при

оптимизиране.

4.5.3 ИЗПОЛЗВАНИ СРЕДСТВА Използваните средства са подбрани по такъв начин, че да улеснят максимално реализацията

на основните идеи и цели в дипломната работа.

4.5.3.1. dotNet

Фреймуоркът dotNet [62] е важен компонент от Windows, който позволява създаването и

изпълнението на приложения и XML уеб услуги от следващо поколение. dotNET е проектиран

да изпълни следните цели:

• Да осигури хомогенна обектно-ориентирана среда за програмиране, където

обектният код е запазен и изпълняван локално; изпълняван локално и разпространен

по интернет; или изпълняван отдалечено;

• Да осигури среда, която намалява времето за внедряване на кода;

• Да осигури среда за изпълнение, която спомага за безопасно изпълнение на код,

включително такъв, създаден от непознат или полусигурен трети източник.

• Да осигури среда за изпълнение, която премахва проблемите, свързани с

производителността на интерпретираните езици за програмиране;

• Да използва уменията на разработчика за изграждането на различни типове

приложения;

• Да има обратна съвместимост с всеки друг код.

Фреймуоркът dotNET има два основни компонента: CLR (Common Language Runtime) и FCL

(.NET Framework Class Library).

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

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

управление на нишки, отдалечено изпълнение (remoting). В същото време строго спазва типова

безопасност и други видове технологии, свързани с кода, правейки го по-безопасен и по-гъвкав.

С други думи, управлението на кода е основна задача на CLR. Код, който използва CLR е познат

като управляван (managed).


FCL, другият главен компонент на .NET, е изчерпателна, обектно-ориентирана колекция от

преизползваеми типове. Те могат да се използват, за да се създадат приложения, които варират

от конзолни до такива, които са базирани на последните иновации, осигурени от ASP.NET.

Важна характеристика е, че кодът може да се прекомпилира и под Mono, който е съвместим с

unix-базирани операционни системи.

4.5.3.2. C Sharp

C Sharp (C#) произлиза от С и С++, като използва голяма част от изреченията (statements),

изразите (expressions) и операторите им. Езикът за програмиране е прост, но в същото време,

проектиран за създаването на сложни проекти. Той предлага значителни подобрения и

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

(versioning), събития, събирач на боклук (Garbage Collector). С# поддържа и небезопасен режим,

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

под контрола на събирача на боклук.

Езикът поддържа всички необходими механизми за постигане на целите на дипломната

работа.

4.5.3.3. Common Intermediate Language

Когато компютърът компилира до управляем код, той го транслира до междинен език (CIL),

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

Междинният език включва инструкции за:

• Четене;

• Съхранение;

• Инициализиране;

• Извикване на методи;

• Аритметични и логически операции;

• Контрол на последователността на изпълнение;

• Директен достъп до паметта;

• Обработка на изключения;

• Други операции.

Преди кодът да бъде изпълнен, MSIL (реализацията на CIL от Microsoft) трябва да бъде

компилиран до машинно зависим език, което обикновено се постига чрез JIT компилатор.

Поради факта, че CLR предоставя един или повече JIT компилатори за всяка поддържана

компютърна архитектура, един и същ MSIL код може да бъде компилиран от JIT компилатора и

изпълнен на всяка поддържана компютърна архитектура.


Когато компилаторът транслира до междинен код, то на сигнатурата на всеки тип се създават

и метаданни. Метаданните описват използваните типове, включително и дефинициите на всеки

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

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

преносим, изпълним файл. Файловият формат на изпълнимия файл, в който се записва

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

разпознае изпълними от CLR файлове. Метаданните във файла, заедно с междинния език,

позволяват на кода да се самоопише, което означава, че няма нужда от библиотеки от типове

или от езици за дефиниране на интерфейси (Interface Definition Language). CLR намира и

извлича метаданните от файла, когато са му необходими по време на изпълнение. [63]

4.5.3.4. Mono.Cecil

Mono.Cecil е библиотека на Mono, която се използва в SolidOpt. Тя представлява реализация

на спецификацията на ECMA за CLI [60].

4.5.3.5. Drupal

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

съдържанието (content management system). Системата трябва:

• Да има достатъчно свободно-разпространяващи се модули, за да улеснява

създаването на съдържание;

• Да предоставя добра система за шаблони (template system);

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

модули.

Ефективния уеб дизайн е този, който успява да балансира между гъвкавост и простота. Ако

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

прекалено сложна ще бъде трудна за разбиране от потребителите.

Уеб системата Drupal цели балансирането на тези противоречащи си идеи. Именно затова

Drupal може да се разглежда като система за управление на съдържанието (CMF) и фреймуорк

за системи за управление на съдържанието (CMF). Главната разлика идва от предаването на

информацията между слоевете на Drupal и разбирането за основата на уеб съдържанието:


Фигура 4-21: Важни слоеве в Drupal

Градивната единица в Drupal е възел, защото уеб съдържанието се представя като свързан

граф:

1. Базовата система е колекция от възли, представящи уеб съдържанието;

2. Слоя представя модулите, които са функционални разширения. Модулите могат да

бъдат част от ядрото или да са разработени и предоставени от други потребители;

3. Слоя представя блоковете и менютата в Drupal. Блоковете много често представляват

форматиран изход от даден модул, който може да бъде разположен на произволна

позиция в уеб приложението;

4. Слоя представя потребителски роли, т.е кой потребител какво част от уеб сайта може

да вижда и управлява;

5. Слоя представя външния вид на уеб сайта.

4.5.3.6. Контрол над версиите

За реализиране на поставените цели е необходимо да се предостави механизъм за контрол

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

SolidOpt.

За контрол над версиите е избрана една от най-широко разпространените технологии за

момента Apache Subversion (SVN). Тя предоставя всички необходими за разработката средства

за поддържане на хронологията на разработка, разрешаване на конфликти и др.

Основната единица в SVN се нарича ревижън (revision) и означава промените качени на

сървъра от един разработчик с една транзакция. На Фигура 4-22 са показани трите основни


етапа на разработка в хранилището: главна разработка (trunk); клонове (branches) и стабилни

версии (tags):

Фигура 4-22: Основни етапи на разработка в SVN хранилището

4.5.3.7. Система за автоматизирана компилация

При SOA системи, каквато трябва да бъде SolidOpt, процесът на синхронизация при

разработка е много труден. При всяко обновяване на модул или на инструментариума е

възможно част от другата функционалност да е несъвместима с новите промени. Това доста

често е трудно да се идентифицира, поради неедновременната разработка на различната

функционалност. Необходима е система, която тества за синхронизация всеки проект и

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

Една такава система е BuildBot. BuildBot е система, която автоматизира цикъла

компилиране/тестване с цел валидиране на промените в сорс кода. Системата автоматично

компилира и тества дървото на хранилището при всяка направена промяна. Така проблемите

компилацията на сорс кода се намират дори преди другите разработчици да са изпитали

неудобство от невъзможността да компилират. Разработчика допуснал грешката се

идентифицира и уведомява без да има нужда от човешка намеса.

BuildBot предоставя възможността да се правят компилации на различни платформи.Така

разработчиците, които нямат възможност да тестват собствения си код върху различни

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

платформи.

Фигура 4-23 показва действието на системата за компилация BuildBot:


Фигура 4-23: Система за автоматизирана компилация BuildBot

4.5.3.8. Документация

Необходима е система за онлайн документация за разработчиците, която да бъде

синхронизирана с текущата разработка. Подробната синхронизирана документация на SolidOpt

би улеснила процеса на проектиране и разработка.

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

сорс кода. Doxygen поддържа голям брой езици за програмиране и може да генерира

документация в различни формати (html, pdf, chm и др.). HTML форматът е особено приложим,

защото може да бъде качен на уеб сървър.

Също така doxygen може да извлича структурата на кода, който не е документиран, което

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

създава различни диаграми и графи, базирани на съществуващия сорс код.

Бъдещо развитие→Интегриране на VMKit Стр. 105 от 126

55.. ББЪЪДДЕЕЩЩОО РРААЗЗВВИИТТИИЕЕ

5.1. ИНТЕГРИРАНЕ НА VMKIT Управляемите среди за изпълнение (managed runtime environments) като JVM и CLR стават

норма, определяща начинa на изпълнение. Техните недостатъци са известни.

Тъй като те са важна част от многомоделното представяне в SolidOpt (виж Фигура 4-1) е

необходимо да се предоставят средства улесняващи създаването на произволни пВМ с

управляеми среди за изпълнение.

Интегрирането на пВМ в SolidOpt е стъпка напред в тази насока, но то само по себе си не е

достатъчно. Реализирането на пВМ като CLR или JVM само чрез използване на

инфраструктурата на LLVM е много трудоемка и предразположена към грешки задача.

VMKit [64] от своя страна улеснява изграждането на управляеми среди за изпълнение като

предоставя необходимите стандартни средства за реализирането им. Изследванията, направени

от Nicolas Geoffray показват, че CLR и JVM имат около 96% общо по-между си[64]. Това са

именно управлението на паметта, управлението на нишки, събиране на боклук (garbage collec-

tion), JIT и др.

На базата на това изследване VMKit представя управляемите среди за изпълнение като слой

от общи части и слой от специфични части.

Авторите[64] показват, че използвайки VMKit (използващ инфраструктурата на LLVM) за

реализация на пВМ като JVM (и/или CLR) са необходими не повече от 20 000 реда код, който

представлява 4% от целия код. Останалите 96% се предоставят от слоя, реализиращ общите

части.

Бъдещата интеграция на VMKit със SolidOpt ще доведе до възможността лесно и бързо да се

реализират нови пВМ (в термините на SolidOpt модели).

Заключение Стр. 106 от 126

66.. ЗЗААККЛЛЮЮЧЧЕЕННИИЕЕ

Целите на дипломната работа са постигнати успешно. Описаната архитектура е достатъчно

гъвкава и разширима. Реализиран е прототип на инструментариума – SolidOpt, който принципно

доказва изложените идеи.

Подробно е описана идеята за домейн базирано приложение на трансформациите.

Представени са достатъчно примери, илюстриращи идеята за домейн специфични оптимизации.

Една от целите при разработката беше архитектурата на SolidOpt да бъде възможно най-

близка до принципите на SOA. Целта беше задоволително постигната. В следствие на това

функционалността на инструментариума може да бъде развивана почти скаларно. С други думи,

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

В момента се работи върху услуги като:

• Разпространение на константи;

• Опростяване на изрази;

• Добавяне на различни представяния;

• Интегриране пВМ с регистър-базирана архитектура като LLVM

Част от резултатите са публикувани на международната конференция на IEEE в Равда (юни

2009). Статията е на тема “SolidOpt – Innovative Multiple Model Software Optimization

Framework”.

Емпирично доказателство на работоспособността на идеите в секция “Реализация” може да

се намери на http://sandbox.solidopt.org/ . Проектът е с отворен код и се разпространява с LGPL

лиценз. Предимство на посоченият уеб адрес е, че може да се проследи и историята на

разработка.

Бъдеща цел е допълването на многомоделната схема с още модели, улесняващи реализацията

на оптимизационни модули. Моделите трябва да повишават нивото на абстракция постепенно.

Добре е да се направи и модел, съдържащ граф на извикванията (call graph) на методи. Модел,

представящ програмата в триадресен вид (матричен код) също ще допринесе за по-качествено

оптимизиране на приложенията.

Друга насока, която е в бъдещото развитие на фреймуорка е т. нар retargeting.

Добре е да бъдат реализирани, ако не всички, то поне част от оптимизациите, които се

http://vvassilev.chickenkiller.com:808/SolidOpt%20.????????

Заключение Стр. 107 от 126

прилагат в компилаторите. Този вид оптимизации са с доказана еквивалентност, приложимост и

ефективност.

Областта е обширна и не всичко е добре изследвано. Затова изследвания могат да се направят

в много насоки.

Важна насока за изследване са нееквивалентните трансформации и формалното доказване на

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

данните, получени от потребителския поток данни и/или операции и предприемането на най-

подходящата стратегия за подобряване на целевото софтуерно приложение.

Литература Стр. 108 от 126

77.. ЛЛИИТТЕЕРРААТТУУРРАА

[1] Dimov D., Penev A., Vassilev V. – “Applying Model-View-Controller in Geometric Modelling

Methodology”, In Proceedings of International Conference Varna 2008, Varna, 2008

[2] Aho A., Lam M., Sethi R., Ullman J., “Compilers: Principles, Techniques, and Tools (2nd Edition)”,

Addison-Wesley Longman Publishing Co. Inc., Boston, MA, 2006

[3] Fowler M., Beck K., Brant J., Opdyke W., Roberts, D., “Refactoring: Improving the Design of Existing

Code”, Addison-Wesley Longman Publishing Co. Inc, Boston, MA, 1999

[4] Bhatti M., “Practical Optimization Methods: With Mathematica Applications”, pages 1-20, 1998

[5] Popek G.J., Goldberg R.P.: “Formal requirements for virtualizable third generation

architectures”, Communications of the ACM, vol 17(7), pages 412–421, ACM Press, 1974

[6] Smith J.E.; Nair R.,“The Architecture of Virtual Machines”,. Computer (IEEE Computer Society),

vol 38 (5), pages: 32–38, May 2005.

[7] Virtualization: The big picture, http://www.gantthead.com/content/articles/240290.cfm, (visited

August 2010)

[8] Understanding Full Virtualization, Paravirtualization, and Hardware Assist,

http://www.vmware.com/files/pdf/VMware_paravirtualization.pdf, (visited August 2010)

[9] Fisher-Ogden J., “Hardware Support for Efficient Virtualization”,

http://cseweb.ucsd.edu/~jfisherogden/hardwareVirt.pdf

[10] Performance Evaluation of Intel EPT Hardware Assist,

http://www.vmware.com/pdf/Perf_ESX_Intel-EPT-eval.pdf

[11] Performance Evaluation of AMD RVI Hardware Assist,

http://www.vmware.com/pdf/RVI_performance.pdf

[12] Shi Y., Gregg D., Beatty A., Ertl M. A., “Virtual machine showdown: stack versus registers”, In

VEE 2005, pages 153–163, 2005.

[13] Shi Y., Gregg D., Beatty A., Ertl M. A., “Virtual machine showdown: stack versus registers”,

ACM Transactions on Architecture and Code Optimization (TACO), vol 4 issue 4, article: 2, 2008.

[14] Suganuma T., Ogasawara T., Takeuchi M., Yasue T., Kawahito M., Ishizaki K., Komatsu H., Nakatani T.,

“Overview of the IBM Java just-in-time compiler”, IBM Systems Journal, vol 39 issue 1, pages: 175–193, 2000

[15] Schilling J. L., “The simplest heuristics may be the best in Java JIT compilers”, ACM Sig-

plan Notices, vol 32 issue 2, pages: 36–46, 2003

[16] Mikheev V.,Lipsky N., Gurchenkov D., Pavlov P., Sukharev V., Markov A, Kuksenko S., Fedoseev S.,

Leskov D., Yeryomin A., “Overview of excelsior JET, a high performance alternative to java virtual

http://www.gantthead.com/content/articles/240290.cfm

http://www.vmware.com/files/pdf/VMware_paravirtualization.pdf

http://cseweb.ucsd.edu/~jfisherogden/hardwareVirt.pdf

http://www.vmware.com/pdf/Perf_ESX_Intel-EPT-eval.pdf

http://www.vmware.com/pdf/RVI_performance.pdf


machines”, Workshop on Software and Performance in proceedings of the 3rd international workshop on Software and

performance, pages: 104–113, Rome, Italy, 2002

[17] AOT, http://www.mono-project.com/AOT, visited August 2010

[18] Lindholm T., Yellin F., “Java Virtual Machine Specification, 2nd edition”, Addison-Wesley

Longman Publishing Co., Inc. Boston, MA, USA, 1999.

[19] Sun Microsystems, The Java Hotspot virtual machine, Tech rep. Sun Microsystems, 2001

[20] Apache Tomcat, http://tomcat.apache.org/, visited August 2010

[21] Ierusalimschy R., Figueiredo L. H., Celes W., “The Implementation of Lua 5.0”,

http://www.lua.org/doc/sblp2005.pdf, 2005, visited August 2010

[22] Rutar N., Almazan C., Foster J., “A Comparison of Bug Finding Tools for Java”, In Proceedings of the

15th IEEE International Symposium on Software Reliability Engineering, France, November 2004

[23] Flanagan C., Leino K., Lillibridge M., Nelson G., Saxe J., Stata R., “Extended static checking for Java”,

In Proceedings of the ACM SIGPLAN ’02 Conference on Programming Language Design and Implementation, pages 234–

245. Association for Computing Machinery, ACM Press, June 2002

[24] Hovemeyer D., Pugh. W., “Finding Bugs Is Easy”,

http://www.cs.umd.edu/˜pugh/java/bugs/docs/findbugsPaper.pdf, 2003, (visited in March 2009)

[25] Gamma E., Helm R., Johnson R, Vlissides J, „Design patterns: elements of reusable object-oriented

software”, Addison-Wesley Longman Publishing Co. Inc., 1995, Boston, MA, (in Bulgarian)

[26] Гъров В, “Flex базиран онлайн достъп до Web услуга за оптимизация на софтуерни

приложения”, дипломна работа, бакалавър по информатика, ФМИ, ПУ, 2010

[27] “Jlint”, http://artho.com/jlint, (visited in March 2009)

[28] “PMD/Java”, http://pmd.sourceforge.net, (visited in March 2009)

[29] “StyleCop”, http://code.msdn.microsoft.com/sourceanalysis, (visited in March 2009)

[30] “Singularity”, http://research.microsoft.com/os/singularity/, (visited in January 2009)

[31] Tilevich E., Smaragdakis Y., “Binary refactoring: Improving code behind the scenes”, In Proceedings of

International Conference on Software Engineering (ICSE), pages 264–273, May 2005

[32] Chen J., Hawblitzel C., Perry F., Emmi M., Condit J., Coetzee D., Pratikakis P., “Type-preserving

compilation for large-scale optimizing object-oriented compilers”, In Proceedings of the SIGPLAN 08 Conference on

Programming Language Design and Implementation, pages 183–192, Tucson, AZ, June 2008

[33] “Phoenix”, http://research.microsoft.com/Phoenix/, (visited in January 2009)

[34] Srivastava A., Eustace A., “ATOM: A System for Building Customized Program Analysis Tools”, In

Proceedings of the SIGPLAN '94 Conference on Programming Language Design and Implementation, pages 196–205,

Orlando, FL, June 1994

[35] Larus J. R., Schnarr E., “EEL: Machine-Independent Executable Editing”, In Proceedings of the

SIGPLAN '95 Conference on Programming Language Design and Implementation, pages 196–205, June 1995

[36] Romer T., Voelker G., Lee D., Wolman A., Wong W., Levy H., Chen B., Bershad B., “Instrumentation and

Optimization of Win32/Intel Executables Using Etch”, USENIX Windows NT Workshop, Aug. 1997

[37] Srivastava A., Edwards A., Vo H., “Vulcan: Binary Transformation in a Distributed Environment”, Micro-

soft Research Technical Report, MSR-TR-2001-50

[38] Lee H., Zorn B., “BIT: A Tool for instrumenting Java bytecodes”, USENIX Symposium on Internet Tech-

http://www.mono-project.com/AOT

http://tomcat.apache.org/

http://www.lua.org/doc/sblp2005.pdf

http://code.msdn.microsoft.com/sourceanalysis

http://research.microsoft.com/Phoenix/


nologies and Systems, Monterey, CA, 1997

[39] Vallee-Rai R., Co P., Gagnon E., Hendren L., Lam P., Sun-daresan V., “Soot – a Java Bytecode

Optimization Framework”, In Proceedings of CASCON '99, pages 125-135, 1999

[40] Pominville P., Qian F., Vallée-Rai R., Hendren L., Verbrugge C., “A framework for optimizing Java using

attributes”, In Proceedings of the 10th International Conference on Compiler Construction (CC ’01), pages 334–354, April

2001

[41] Bradley D., “Assembly language programming for the IBM Personal Computer” (in Bulgarian), pages 82-

85, 1984

[42] Low D., “Protecting Java Code via Code Obfuscation”, ACM Crossroads 4, No. 3, pages 21-23, 1998

[43] Varde A., Ma S., Maniruzzaman M., Brown D., Rundensteiner E., Sissonjr R., “Comparing mathematical

and heuristic approaches for scientific data analysis”, ACM Artificial Intelligence for Engineering Design, Analysis and

Manufacturing, Vol. 22, Issue 1, Jan 2008

[44] Law A., “Statistical analysis of simulation output-data: The practical state of the art”, In Proceedings of

the Winter Simulation Conference, pages 67–72, 2004

[45] Glushkova T., Stoyanova A., “Interaction and adaptation to the specificity of the subject domains in the

system for e-Learning and distance training DeLC”, In Proceedings of the Informatics in science knowledge Conference,

Varna, June 2008

[46] Гочева С., “Лекции по Компютърни числени методи”, 2009, Пловдивски университет,

http://77.77.167.148/evlm/DBbg/database/courses/2%20lekcia-k4m-2009.pdf (посетен Септември 2009)

[47] Brown A., “An Introduction to Model Driven Architecture”, 2004, IBM

http://www.ibm.com/developerworks/rational/library/3100.html (visited September 2009)

[48] Carini P., “Call-Site Specific Selective Automatic Inlining”, US Patent, Patent Number: 5740443, 14 Apr

1998

[49] Bates et al, “System for Partial In-line Expansion of Procedure Calls During Program Compilation”, US

Patent, Patent Number: 5701489, 23 Dec 1997

[50] Bates et al, “Expression Reduction During Compilation Through Routine Cloning”, US Patent, Patent

Number: 6895580, 17 May 2005

[51] “INI File”, http://www.cloanto.com/specs/ini.html

[52] Honeycutt J., “Microsoft Windows Registry Guide, Second Edition”, Redmond, Microsoft Press, (2005),

page 608, ISBN 0735622183

[53] Lhotka R., “Application Configuration Files Explained”, http://msdn.microsoft.com/library/en-

us/dnadvnet/html/vbnet04222003.asp, (2003)

[54] Microsoft Corporation, “ASP.NET Configuration Overview”, http://msdn2.microsoft.com/en-

gb/library/ms178683.aspx, (2006)

[55] “NINI .NET Configuration Library”, http://nini.sourceforge.net/

[56] “Carbon Component Framework”, http://carbon.sourceforge.net/

[57] Ben-Kiki O., Evans C., Ingerson B., “YAML Ain't Markup Language (YAML) Version 1.1”

http://www.yaml.org/spec/, (2004)

[58] “Symfony Project”, http://www.symfony-project.com/

[59] Penev A., Dimov D., Kralchev D., “Acceleration of structured and heterogeneous configuration of the

applications”, In Proceedings 36th conference – Union of Bulgarian Mathematicians, Sofia, pages 327–331, 2007

http://77.77.167.148/evlm/DBbg/database/courses/2%20lekcia-k4m-2009.pdf

http://www.ibm.com/developerworks/rational/library/3100.html

http://www.cloanto.com/specs/ini.html

http://nini.sourceforge.net/

http://carbon.sourceforge.net/

http://www.symfony-project.com/


[60] ECMA International, “Standard ECMA-335, Common Language Infrastructure (CLI)”, http://www.ecma-

international.org/publications/files/ECMA-ST/Ecma-335.pdf (visited Sep. 2009)

[61] ECMA International, “Standard ECMA-334, C# Language Specification”, http://www.ecma-

international.org/publications/files/ECMA-ST/Ecma-334.pdf (visited Sep. 2009)

[62] “.NET Framework Conceptual Overview”, http://msdn.microsoft.com/en-us/library/zw4w595w.aspx, (vi-

sited Sep 2009)

[63] “Compiling to MSIL”, http://msdn.microsoft.com/en-us/library/c5tkafs1%28VS.71%29.aspx, (visited Sep

2009)

[64] Geoffray N., Thomas G., Lawall J., Muller G., Folliot B., “VMKit: a substrate for managed

runtime environments”, In Proceedings of the 6th ACM SIGPLAN/SIGOPS international conference on Virtual execu-

tion environments, pages: 51 – 62, 2010

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-335.pdf

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-335.pdf

http://msdn.microsoft.com/en-us/library/zw4w595w.aspx

http://msdn.microsoft.com/en-us/library/c5tkafs1%28VS.71%29.aspx

Приложения→UML диаграми на SolidOpt Стр. 112 от 126

88.. ППРРИИЛЛООЖЖЕЕННИИЯЯ

8.1. UML ДИАГРАМИ НА SOLIDOPT

8.1.1 UML ДИАГРАМА НА SOLIDOPT

<<namespace>>

StreamProvider

(from Root::SolidOpt::SolidOpt::Core::Providers)

<<namespace>>

Configurator

(from Root::SolidOpt::SolidOpt::Core)

<<namespace>>

Configurator


<<namespace>>

Providers


<<namespace>>

Cache

(from Root::SolidOpt::SolidOpt)

<<namespace>>

Mappers

<<namespace>>

Targets

<<namespace>>

Sources

<<namespace>>

Mappers

<<namespace>>

TypeResolvers

pkg Configurator


8.1.2 UML ДИАГРАМА НА ПОДСИСТЕМА ЗА ДОСТЪП ДО ХЕТЕРОГЕННИ РЕСУРСИ

URIManager

importers:List<T1->IGetURI>=new List<IGetURI>()

exporters:List<T1->ISetURI>=new List<ISetURI>()

<<GetAccessor, SetAccessor, property>> Importers():List<T1->IGetURI>

<<GetAccessor, SetAccessor, property>> Exporters():List<T1->ISetURI>

<<constructor>> URIManager()

SetResource(in stream:Stream, in resource:Uri):void

GetResource(in resource:Uri):Stream

<<interface>>

ISetURI

CanExport(in resource:Uri):bool

Export(in stream:Stream, in resource:Uri):void

<<interface>>

IGetURI

CanImport(in resource:Uri):bool

Import(in resource:Uri):Stream

<<namespace>>

Exporters

<<namespace>>

Importers

List<T1->IGetURI>

List<T1->ISetURI>

-importers-exporters

pkg StreamProvider


8.1.3 UML ДИАГРАМА НА КЕШИРАЩА ПОДСИСТЕМА

TKey,TValue

<<attributes>>

CacheManager

storage:Dictionary<T1->TKey,T2->CacheItem>

initDelegate:InitDelegate

touchDelegate:TouchDelegate

validateDelegate:ValidateDelegate

calculateDelegate:CalculateDelegate

updateDelegate:UpdateDelegate

deleteDelegate:DeleteDelegate

<<constructor>> CacheManager(in delegates:Delegate...[*])

<<virtual>> DefaultInitDelegate(in key:TKey, in value:TValue):CacheItem

<<virtual>> DefaultTouchDelegate(in key:TKey, in item:CacheItem):CacheItem

<<virtual>> DefaultValidateDelegate(in key:TKey, in item:CacheItem):bool

<<virtual>> DefaultCalculateDelegate(in key:TKey):CacheItem

<<virtual>> DefaultUpdateDelegate(in key:TKey, in item:CacheItem):void

<<virtual>> DefaultDeleteDelegate(in key:TKey, in item:CacheItem):void

Add(in key:TKey, in value:TValue):void

ContainsKey(in key:TKey):bool

Remove(in key:TKey):bool

Compact():void

Save():void

Load():void

<<virtual>> InitItem(in key:TKey, in value:TValue):CacheItem

<<virtual>> TouchItem(in key:TKey, in item:CacheItem):CacheItem

<<virtual>> ValidateItem(in key:TKey, in item:CacheItem):bool

<<virtual>> CalculateItem(in key:TKey):CacheItem

<<virtual>> UpdateItem(in key:TKey, in oldItem:CacheItem):void

<<virtual>> DeleteItem(in key:TKey, in item:CacheItem):void

<<override>> ToString():string

<<GetAccessor, SetAccessor, indexer>> this(in key:TKey):TValue

<<GetAccessor, SetAccessor, property>> State():object

<<delegate>> InitDelegate

<<delegate>> TouchDelegate

<<delegate>> ValidateDelegate

<<delegate>> DeleteDelegate

<<delegate>> CalculateDelegate

<<delegate>> UpdateDelegate

<<attributes>> CacheItem

<<attributes>> MemoryCacheItem

<<attributes>>

sections = Serializable

CacheItem (Class)

<<attributes>> sections = Serializable

MemoryCacheItem (Class)

<<attributes>> sections = Serializable

<<attributes>>

MemoryCacheItem

(from CacheManager)

value:TValue

<<constructor>> MemoryCacheItem()

<<constructor>> MemoryCacheItem(in value:TValue)

<<override>> ToString():string

<<GetAccessor, SetAccessor, override, property>> Value():TValue

<<attributes>>

sections = Serializable

<<attributes>>

CacheItem

(from CacheManager)

<<GetAccessor, SetAccessor, property>> Value():TValue

<<attributes>>

sections = Serializable<<delegate>>

TouchDelegate

(from CacheManager)

delegate(in key:TKey, in item:CacheItem):CacheItem

<<delegate>>

InitDelegate

(from CacheManager)

delegate(in key:TKey, in value:TValue):CacheItem

<<delegate>>

ValidateDelegate

(from CacheManager)

delegate(in key:TKey, in item:CacheItem):bool

<<delegate>>

DeleteDelegate

(from CacheManager)

delegate(in key:TKey, in item:CacheItem):void

<<delegate>>

UpdateDelegate

(from CacheManager)

delegate(in key:TKey, in item:CacheItem):void

<<delegate>>

CalculateDelegate

(from CacheManager)

delegate(in key:TKey):CacheItem

-calculateDelegate

-deleteDelegate

-updateDelegate

-validateDelegate

-touchDelegate

-storage

-initDelegate

pkg Cache


8.1.4 UML ДИАГРАМА НА КОНФИГУРИРАЩА ПОДСИСТЕМА

TParamName

ConfigurationManager

instance:ConfigurationManager<TParamName->TParamName>=new ConfigurationManager<TParamName>()

targets:List<T1->IConfigTarget<TParamName->TParamName>>=new List<IConfigTarget<TParamName>>()

sources:List<T1->IConfigSource<TParamName->TParamName>>=new List<IConfigSource<TParamName>>()

ir:Dictionary<T1->TParamName,T2->object>=new Dictionary<TParamName, object>()

cacheManager:CacheManager<TKey->TParamName,TValue->object>

streamProvider:URIManager

mapManager:MapManager<TParamName->TParamName>

typeManager:TypeManager<TParamName->TParamName>

<<GetAccessor, property>> Instance():ConfigurationManager<TParamName->TParamName>

<<GetAccessor, SetAccessor, property>> Targets():List<T1->IConfigTarget<TParamName->TParamName>>

<<GetAccessor, SetAccessor, property>> Sources():List<T1->IConfigSource<TParamName->TParamName>>

<<GetAccessor, SetAccessor, property>> IR():Dictionary<T1->TParamName,T2->object>

<<GetAccessor, SetAccessor, property>> CacheManager():CacheManager<TKey->TParamName,TValue->object>

<<GetAccessor, SetAccessor, property>> StreamProvider():URIManager

<<GetAccessor, SetAccessor, property>> MapManager():MapManager<TParamName->TParamName>

<<GetAccessor, SetAccessor, property>> TypeManager():TypeManager<TParamName->TParamName>

<<constructor>> ConfigurationManager()

SaveConfiguration(in resourse:Uri, in fileFormat:string):void

SaveConfiguration(in configRepresenation:Dictionary<T1->TParamName,T2->object>, in resourse:Uri, in fileFormat:string):void

LoadConfiguration(in resUri:Uri):Dictionary<T1->TParamName,T2->object>

GetParam<TParam>(in name:TParamName):TParam

GetParam(in name:TParamName):object

GetParams<TBaseParam>(in names:TParamName...[*]):Dictionary<T1->TParamName,T2->TBaseParam>

GetParams(in names:TParamName...[*]):Dictionary<T1->TParamName,T2->object>

<<interface>>

IConfigSource<TParamName->TParamName>

<<interface>>

IConfigTarget<TParamName->TParamName>

ConfigurationManager<TParamName->TParamName>

CacheManager<TKey->TParamName,TValue->object>

TypeManager<TParamName->TParamName>

MapManager<TParamName->TParamName>

<<namespace>>

Sources

<<namespace>>

Targets

<<namespace>>

TypeResolvers

<<namespace>>

Mappers

-sources

-cacheManager

-targets

-mapManager

-instance

-typeManager

pkg Configurator

8.1.5 UML ДИАГРАМА НА РАЗПОЗНАВАНЕ НА ТИПОВЕТЕ

ChainResolver

resolverChain:List<T1->ITypeResolver>=new List<ITypeResolver>()

<<GetAccessor, SetAccessor, property>> ResolverChain():List<T1->ITypeResolver>

<<constructor>> ChainResolver()

<<override>> InsertAfter(in after:ITypeResolver, in resolver:ITypeResolver):Resolver

<<override>> InsertAtPosition(in position:int, in resolver:ITypeResolver):Resolver

<<override>> InsertFirst(in resolver:ITypeResolver):Resolver

<<override>> Add(in resolver:ITypeResolver):Resolver

<<override>> RemoveResolver(in resolver:ITypeResolver):void

<<override>> TryResolve(in paramValue:object):object

Resolver

<<virtual>> TryResolve(in paramValue:object):object

<<virtual>> Add(in resolver:ITypeResolver):Resolver

<<virtual>> InsertFirst(in resolver:ITypeResolver):Resolver

<<virtual>> InsertAfter(in after:ITypeResolver, in resolver:ITypeResolver):Resolver

<<virtual>> InsertAtPosition(in position:int, in resolver:ITypeResolver):Resolver

<<virtual>> RemoveResolver(in resolver:ITypeResolver):void

FloatResolver

<<constructor>> FloatResolver()


IntResolver

<<constructor>> IntResolver()


StringResolver

<<constructor>> StringResolver()


<<interface>>

ITypeResolver

(from Root::SolidOpt::SolidOpt::Core::Configurator)

TryResolve(in paramValue:object):object

pkg TypeResolvers


8.1.6 UML ДИАГРАМА НА ПРЕИМЕНУВАНЕ

TParamName

MapManager

mapperList:List<T1->Mapper<TParamName->TParamName>>=new List<Mapper<TParamName>>()

mmCIR:Dictionary<T1->TParamName,T2->object>

<<GetAccessor, SetAccessor, property>> MmCIR():Dictionary<T1->TParamName,T2->object>

<<constructor>> MapManager()

Map(in mmCIR:Dictionary<T1->TParamName,T2->object>):Dictionary<T1->TParamName,T2->object>

UnMap(in mmCIR:Dictionary<T1->TParamName,T2->object>):Dictionary<T1->TParamName,T2->object>

Add(in mapper:Mapper<TParamName->TParamName>):MapManager<TParamName->TParamName>

AddFirst(in mapper:Mapper<TParamName->TParamName>):MapManager<TParamName->TParamName>

AddLast(in mapper:Mapper<TParamName->TParamName>):MapManager<TParamName->TParamName>

Remove(in mapper:Mapper<TParamName->TParamName>):void

TParamName

INIMaper

tCIR:Dictionary<T1->TParamName,T2->object>=new Dictionary<TParamName, object>()

<<constructor>> INIMaper()

<<override>> Map(in mmCIR:Dictionary<T1->TParamName,T2->object>):Dictionary<T1->TParamName,T2->object>

MapCIR(in mmCIR:Dictionary<T1->TParamName,T2->object>, in key:string):Dictionary<T1->TParamName,T2->object>

<<override>> UnMap(in mmCIR:Dictionary<T1->TParamName,T2->object>):Dictionary<T1->TParamName,T2->object>

UnMapParam(out dict:Dictionary<T1->TParamName,T2->object>, in item:KeyValuePair<T1->TParamName,T2->object>):void

TParamName

CustomMapperGroup

mapperList:List<T1->Mapper<TParamName->TParamName>>=new List<Mapper<TParamName>>()

<<constructor>> CustomMapperGroup()



<<override>> AddMapper(in mapper:Mapper<TParamName->TParamName>):Mapper<TParamName->TParamName>

<<override>> RemoveMapper(in mapper:Mapper<TParamName->TParamName>):void

TParamName

Mapper



<<virtual>> AddMapper(in mapper:Mapper<TParamName->TParamName>):Mapper<TParamName->TParamName>

<<virtual>> RemoveMapper(in mapper:Mapper<TParamName->TParamName>):void

TParamName

IdentityMapper

<<constructor>> IdentityMapper()



TParamName

<<interface>>

IConfigMapper



<<interface>>

IConfigMapper<TParamName->TParamName>

<<interface>>

IConfigMapper<TParamName->TParamName> Mapper<TParamName->TParamName>

Mapper<TParamName->TParamName>



-mapperList

-mapperList

pkg Mappers

8.1.7 UML ДИАГРАМА НА ПРОКСИ КЛАСОВЕ, ИЗПОЛЗВАЩИ WSDL В ПОДСИСТЕМАТА ЗА ОНЛАЙН ОПТИМИЗАЦИЯ

Приложения→Математическо oптимиране Стр. 117 от 126

8.2. МАТЕМАТИЧЕСКО OПТИМИРАНЕ

ИИЗЗППООЛЛЗЗВВААННИИ ООЗЗННААЧЧЕЕННИИЯЯ

nR — n-мерно евклидово пространство TA — матрицата, транспонирана на матрицата A

:f X Y→ — функция, дефинирана в множеството X със стойности в множеството Y

'( )f x — производна (градиент) на функцията f в точката x

( )f

xs∂∂

— производна на функцията f в точката x по посока s

( )n

n

fx

s∂∂

— n-та производна на f в точката x по посока s.

8.2.1 ОПТИМИЗАЦИЯ БЕЗ ОГРАНИЧЕНИЯ

8.2.1.1. Функции на една променлива

Функцията ( )f x има локален минимум в точката 0x , ако съществува някаква положителна

величина δ , такава че, ако 0x x δ− < , то 0( ) ( )f x f x≥ , т.е. ако съществува околност на точката

0x , такава че за всяка стойност на x в тази околност ( )f x е по-голяма от 0( )f x . Функцията

( )f x има глобален минимум в точката *x , ако за всяко x е изпълнено неравенството

( ) ( *)f x f x≥ .

Фигура 8-1: Графично представяне на ( )f x

На Фигура 8-1 е дадено графичното представяне на функцията ( )f x , която има локален

минимум в точката 0x и глобален минимум в точката *x . Класическият подход към задачата за

( )f x

cx

*x

mx

0x


намиране на стойности за 0x и *x се състои в търсене на уравнение, което са длъжни да

удовлетворяват. От представената на Фигура 8-1 функция и нейната непрекъсната производна е

очевидно, че в точката 0x и *x производната '( )f x (градиента на функцията) е равна на нула.

Следователно 0x и *x са решения на уравнението:

'( ) 0f x = (6)

Точката mx , в която се достига локален максимум и точката cx , която е точка на инфлексия,

също така удовлетворяват това уравнение. Следователно, уравнението (6) се явява необходимо,

но недостатъчно условие за минимум.

Забелязва се обаче, че в точките 0x и *x производната '( )f x си мени знака от отрицателен

на положителен. В точката mx знакът се променя от положителен на отрицателен, докато в

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

функция, а тъй като степента на нарастване на '( )f x се измерва във втората производна, може

да се очаква, че 0''( ) 0, ''( *) 0f x f x> > , тогава ''( ) 0mf x < .

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

Получените по-горе резултати могат да намерят надеждно обяснение, ако се разложи на

функцията ( )f x в Тейлоров ред в околност на точката 0x (или *x , или mx ), защото трябва

непрекъснатостта на функцията и нейната производна:

2

0 0 0 0( ) ( ) '( ) ''( ) ...2!h

f x h f x hf x f x+ − = + + (7)

Ако в точката 0x се достига минимум, то лявата част (7) е неотрицателна за достатъчно малко

h ( h δ< ). Следователно, първата производна 0'( )f x трябва да бъде равна на нула и така се

получава достатъчното условие (виж (6)). Ако тя е положителна, тогава при достатъчно малка

отрицателна стойност на h ще направи дясната част отрицателна, а ако тя е отрицателна, тогава

достатъчно малка положителна стойност на h ще направи дясната част отрицателна.

Така както в следващия израз (7) винаги 2 0h > , то ако:

0''( ) 0f x > (8)

В точката 0x се достига минимум. Ако '( ) 0mf x = и ''( ) 0mf x < , то по аналогични

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

между локалния и глобалния минимум е достатъчно да се сравнят стойностите на функциите

0( )f x и ( *)f x .


8.2.1.2. Функции на n променливи

Нека разгледаме функцията на n променливи 1 2( , ,..., ) ( )nf x x x f= x

Точката в n-мерното евлидово пространство с координати 1 2, ,..., nx x x се означава с вектора-

стълб x . Градиентът на функцията, т.е. векторът с компоненти 1 2/ , / ,..., / nf x f x f x∂ ∂ ∂ ∂ ∂ ∂ се

означава с ( )f∇ x или понякога с ( )g x . Матрицата на Хесе (Hessian matrix) на хесиановите

функции ( )f x се означава с ( )G x и представлява симетрична матрица n n× с елементи от вида:

2

iji j

fG

x x∂

=∂ ∂

, т.е.

2 2 2

21 1 2 1

2 2 2

22 1 2 2

2 2 2

21 2 2

( )

n

n

n n

f f fx x x x x

f f fG x x x x x x

f f fx x x x x

∂ ∂ ∂ ∂ ∂ ∂ ∂ ∂ ∂ ∂ ∂

= ∂ ∂ ∂ ∂ ∂ ∂ ∂ ∂ ∂ ∂ ∂ ∂ ∂

L

L

M M O M

L

Функцията ( )f x има локален минимум в точката 0x , ако съществува околност на точката 0x ,

такава че ( )f x да е по-голяма от ( )f 0x във всяка точка на тази околност, т.е. съществува

положителна величина δ , такава че, ако δ− <0x x е изпълнено неравенството ( ) ( )f f≥ 0x x .

В случая с глобален минимум в точката *x за всяко х е изпълнено неравенството

( ) ( *)f f≥x x .

При тези определения и очевидното предположение относно диференцируемостта е

възможно да се обобщи уравнение (7), като се получи:

( ) ( )2

1 2 1 21 1 1

1( ) ( ) , ,..., , ,..., ...

2!

1( ) ( ) ...

2

n n n

i n i j ni i ji i j

T T

f ff f h x x x h h x x x

x x x

f

= = =

∂ ∂+ − = + +

∂ ∂ ∂

= ∇ + +

∑ ∑∑0 0

0 0

x h x

h x h G x h

(9)

Тогава, ако 0x е точка на минимум на ( )f x , то всяка първа частна производна

/ ( 1,..., )if x i n∂ ∂ = става равна на нула в точката 0x . В противен случай, за съответният избор на

ih е възможно да се получи, че разликата ( ) ( )f f+ −0 0x h x е отрицателна.

Следователно, необходимото условие за минимум в точката 0x се задава чрез уравнението:

( ) 0f∇ =0x , т.е. (10)

0( )0 ( 1,..., )

i

f xi n

x∂

= =∂

(11)

Тогава разликата ( ) ( )f f+ −0 0x h x се определя от едночлена


1

( )2

T0h G x h (12)

Ако матрицата ( )0G x е положително определена (всички глaвни минори да имат

положителни детерминанти), то този едночлен е положителен за всяко h . Следователно

необходимо и достатъчно условие за минимум е:

( ) 0, ( )f∇ =0 0x G x - положително определена (13)

Необходимо и достатъчно условие за максимум е:

( ) 0, ( )f∇ =m mx G x - отрицателно определена (14)

8.2.2 ОПТИМИЗАЦИЯ ПРИ НАЛИЧНИ ОГРАНИЧЕНИЯ

8.2.2.1. Ограничения с уравнения

Нека разгледаме минимизация на функцията на две променливи:

( , )z f x y= , където на x и y е наложено ограничение, зададено с уравнението:

( , ) 0g x y = (15)

Уравнението ( , ) 0g x y = може да се реши, както спрямо y като функция на x, т.е. ( )y h x= . На

практика може да се окаже трудно или дори невъзможно да се намери явния вид на функцията

( )h x .

( )dy d g g

h xdx dx x y

∂ ∂= = −

∂ ∂ (16)

Тогава функцията

[ ]( , ) , ( )z f x y f x h x= = (17)

може да се запише като функция на една независима променлива, в случая x. Необходимо

условие за минимум на функцията z е съотношението

0dz f f dydx x y dx

∂ ∂= + =∂ ∂

, т.е.

. 0

ff gy

gx xy

∂ − ∂ ∂∂ + =∂∂ ∂

∂

(18)

Съотношенията (15) и (16) могат да бъдат решени с цел получаване на стойности на *, *x y в

точката на минимума.

Този резултат може да бъде представен в различни форми. Ако положим


( , ) ( , )f g

x y x yy y

λ −∂ ∂=∂ ∂

(19)

при *, *x x y y= = , то в точката на минимума са изпълнени съотношенията

( , ) 0,

( , ) ( , ) 0,

( , ) ( , ) 0,

g x y

f gx y x y

x xf g

x y x yy y

λ

λ

=

∂ ∂+ =

∂ ∂∂ ∂

+ =∂ ∂

последното следва непосредствено от (19).

За получените три необходими условия е възможно да се използва функцията на Лагранж

( , , ) ( , ) ( , )F x y f x y g x yλ λ= + (20)

която представлява сумата на целевата функция и произведението на множителя на Лагранж

с функционалното ограничение. Тогава необходимите условия за минимум на функцията

( , )f x y при налични ограничения могат да бъдат записани в следния вид:

( , , ) ( , ) ( , ) 0,

( , , ) ( , ) ( , ) 0,

( , , ) ( , ) 0,

F f gx y x y x y

x x xF f g

x y x y x yy y yF

x y g x y

λ λ

λ λ

λλ

∂ ∂ ∂= + = ∂ ∂ ∂

∂ ∂ ∂ = + = ∂ ∂ ∂

∂= =

∂

(21)

Ето система с три неизвестни и три уравнения, решенията на която се явяват стойности на

*, *x y и *λ в точката на минимум.

Необходимите условия за минимум (21) могат да бъдат обобщени за функции с n променливи

при налични m ограничения, зададени с равенства.

Нека разгледаме задачата за минимизиране на функцията

1 2( ) ( , ,..., )nz f f x x x= =x ,

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

1 2( ) 0, ( ) 0,..., ( ) 0.mg g g= = =x x x (22)

Ограниченията могат да се използват, за да се изразят m променливи (без ограничение на

общността могат да се означат 1 2, ,... nx x x ) чрез останалите ( n m− ) променливи, които могат да

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

( ) ( ) 0f f+ − ≥x h x за всяко h, се удовлетворява условието ( ) ( ) 0i ig g+ = =x h x при 1,...i m= .

Тогава с точност до първи порядък jh ще имаме


1

0n

jj j

fh

x=

∂=

∂∑ ,

където

1

0n

ij

j j

gh

x=

∂=

∂∑ при 1,...i m=

Даденото условие може да се запише

1 1

0n m

ij i

j ij j

gfh

x xλ

= =

∂∂+ = ∂ ∂

∑ ∑ , (23)

където 1 2, ,..., mλ λ λ са множители на Лагранж.

Понеже, 1 2, ,...,m m nh h h+ + са независими нараствания, то коефициентите пред тях трябва да

бъдат равни на нула, т.е.

1

0m

ii

ij j

gfx x

λ=

∂∂+ =

∂ ∂∑ , при 1,...,j m n= +

Нарастванията 1 2, ,..., mh h h не са независими и е възможно да ги положим да са равни на нула

като изберем множителите на Лагранж в уравнение (23)

Така избираме множителите 1 2, ,..., mλ λ λ , такива че

1

0m

ii

ij i

gfx x

λ=

∂∂+ =

∂ ∂∑ , при 1, 2,...,j m=

Тогава окончателно ще имаме

1

0m

ii

ij i

gfx x

λ=

∂∂+ =

∂ ∂∑ , при 1, 2,...,j n= (24)

Следователно, ако определим функцията на Лагранж във вида

1

( , ) ( ) ( )m

i ii

F f gλ=

= +∑x x xλλλλ , (25)

тогава необходимите условия за минимум на функцията ( )f x при налични ограничения

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

1

0m

i

ij j j

gF fx x x

λ=

∂∂ ∂= + =

∂ ∂ ∂∑ , при 1, 2,...,j n= (26)

( ) 0ii

Fg

λ∂

= =∂

x , при 1,...,i m= (27)

Трябва да отбележим, че за допустимите стойности на x (тези, които удовлетворяват

ограниченията) е изпълнено отношението


1

( , ) ( ) ( ) ( )m

i ii

F f g fλ=

= + =∑x x x xλλλλ

В точката на минимума при налични ограничения на стойността на *x е възможно да се

запише, че ( * ) ( *) 0f f+ − ≥x h x , където h удовлетворява уравнението ( * ) 0ig + =x h за всяко i.

Така

2

1 1 1

1( * ) ( *) ... 0

2

n n n

j i jj i jj i j

F FF F h h h

x x x= = =

∂ ∂+ − = + + ≥

∂ ∂ ∂∑ ∑∑x h x ,

където производните са изчислени в точка *x при *λ λ= .

С вземане предивид уравнението (26) получаваме за всяко h, удовлетворяващо

ограниченията, че

2

1 1

10

2

n n

i ji j i j

Fh h

x x= =

∂≥

∂ ∂∑∑

Достатъчни условия за минимум при налични ограничения са уравненията (26) и (27), също

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

2

1 1

12

n n

i ji j i j

Fh h

x x= =

∂∂ ∂∑∑ (28)

за стойностите на h, удовлетворяващи ограниченията.

Забележка. Не винаги е просто да се приведе квадратичната форма във вид, удобен за

използване.

8.2.2.2. Ограничения с неравенства

В този раздел методът на множителите на Лагранж ще бъде доразвит за ограничения,

зададени с неравенства. Нека разгледаме общата задача на математическото програмиране:

Минимизирайте функцията ( )f x при наличните m ограничения ( ) ( 1, 2,..., )i ig b i m≤ −x .

Тези ограничения не ограничават общността на разглеждане. (Ограничението ( ) cϕ ≥x може

да бъде записано във вида ( ) cϕ− ≤ −x ).

До сега няма метод, гарантиращ съществуването на решение на всяка произволна задача.

Ограниченията, зададени с неравенства могат да бъдат преобразувани в ограничения,

зададени с равенства, като се добави към тях неотрицателна променлива 2iu ( 2

iu е винаги

положителна): 2( )i i ig u b+ =x

или 2( ) 0i i ig u b+ − =x


Така задачата се свежда до минимизация на функцията ( )f x при налични m ограничения,

зададен с равенства 2( ) 0i i ig u b+ − =x . Чрез изложения в предишния раздел метод се образува

функцията на Лагранж

2

1

( , , ) ( ) ( )m

i i i ii

F f g u bλ=

= + + − ∑x u x xλλλλ (29)

Необходимите условия, които трябва да са изпълнени за стационарната точка са:

1

0m

ii

ij i j

gF fx x x

λ=

∂∂ ∂= = +

∂ ∂ ∂∑ , при 1, 2,...,j n= , (30)

20 ( )i i ii

Fg u b

λ∂

= = + −∂

x , при 1, 2,...,i m= , (31)

0 2 i ii

Fu

uλ∂

= =∂

, при 1, 2,...,i m= (32)

Умножавайки последното уравнение с 2

iu, получаваме 2 0i iuλ = , т.е.

[ ]( ) 0i i ib gλ − =x , при 1, 2,...,i m= (33)

Уравненията (30), (31) и (33) са необходими условия за минимум в точката *x . Уравнението

(31) е повторен запис на ограничението ( ) 0ig ≤x . Уравнението (33) означава, че или 0iλ = или

( *) 0i ib g− =x . Ако 0iλ ≠ , тогава ( )i ig b=x и ограничението е активно и представлява

ограничение, зададено с равенство. От друга страна, ако ограничението е зададено със строгото

неравенство ( *)i ig b<x , тогава съответния множител на Лагранж 0iλ = . Ако ( *)i ig b<x , то

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

възможно да се пренебрегне, а съответните множители 0iλ = . На Фигура 8-2, активното

ограничение е това, върху което лежи optx , а другите две на практика са неактивни.

Фигура 8-2: Неактивни ограничения

Разбира се, предварително не е известно кои ограничения могат да бъдат пренебрегнати.

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


минимума при налични ограничения, а именно 0iλ ≥ .

Нека предположим, че уравненията (30), (31) и (33) са изпълнени в точка ( *; *; *)x uλλλλ . Ако

фактическият минимум на функцията при налични ограничения e ( *)z f= x , тогава z може да се

разглежда като функция на ib и изменяйки ib може да се изменят ограниченията и по този

начин изменяме само функцията z. Ще докажем, че

*ii

zb

λ∂= −

∂

1

nj

ji j i

xz fb x b=

∂∂ ∂=

∂ ∂ ∂∑ , (34)

където частната производна се изчислява в точката *x .

Понеже 2( )k k kg u b+ =x , тогава

0,

1,

njk k

j ii j i

x при i kg gпри i kb x b=

∂ ≠∂ ∂= = =∂ ∂ ∂ ∑

Тогава

* *

1 1 1

m n mjk k

k i kk j ki i i j j i

xg gz z fb b b x x b

λ λ λ= = =

∂∂ ∂∂ ∂ ∂+ = + = + ∂ ∂ ∂ ∂ ∂ ∂ ∑ ∑ ∑

Но тази формула съгласно (30) е равна на нула. Така получаваме

*ii

zb

λ∂= −

∂

С нарастването на ib областта с ограничения се разширява, така че не може да се предвиди

при увеличаване на стойността на z – минимума на функцията ( )f x дали ще попадне в областта

на ограниченията, а е възможно и само да намалява. Така 0i

zb∂

≤∂

, т.е.

* 0iλ ≥ (35)

Необходими условия за минимум на функцията ( )f x при налични ограничения

( ) ( 1, 2,... )i ig b i m≤ =x имат такъв вид, че е възможно да се намерят такива x и λλλλ , за които е

изпълнено

[ ]

1

0 1,... ,

( ) 1, 2,..., ,

( ) 0 1, 2,..., ,

0 1,...,

mi

iij j

i i

i i i

i

gfпри j n

x x

g b при i m

g b при i m

при i m

λ

λ

λ

=

∂∂ + = = ∂ ∂

≤ = − = = ≥ =

∑

x

x

(36)


Знакът на iλ е противоположен, ако се разглежда максимум.

Тези условия са известни като условия на Кун-Такер.

На Фигура 8-3 е дадена примерна функция от вида 2 21 1 2 2( )f ax bx x cx= + +x , на която са

наложени ограниченията 1 2 1 20; 0;x x x x b≥ ≥ + ≥ (защрихованата част). За да се спази точно

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

1 2 1 20; 0;x x x x b− ≤ − ≤ − − ≤ − . Следователно функцията на Лагранж има следния вид:

( ) ( ) ( )2 2 2 2 21 1 2 2 1 1 1 2 2 2 3 3 1 2F ax bx x cx u x u x u x x bλ λ λ= + + + − + − + − − + . Намирането на

координатите на минимума и стойността е тривиално, като се използват условията на Кун-

Такер.

Фигура 8-3: Функция с ограничение

Използвани са материали от:

• B. Bunday, “Basic Optimization Methods”, Edward Arnold, London, UK, 1984 (in

Russian)

• Кендеров П., Христов Г., Дончев А., “Математическо оптимиране”, София,

Университетско издателство, 1989

Documents

ДИПЛОМНА РАБОТА - SolidOpt