Вже сьогодні ринок персональних комп’ютерів практично перейшов на багатоядерні та мультипроцесорні системи, в зв’язку з цим від сучасного програмного забезпечення вимагається повне  використання сучасних можливостей апаратури. При цьому послідовні програми необхідно переробляти у їх паралельний еквівалент для підвищення ефективності – рефакторінг. Сам рефакторінг програмного забезпечення потребує економічних затрат та чисельних робот. При цьому фактично нічого нового не виникає, перероблене забезпечення не буде мати нові функціональні можливості. Крім того, програмне забезпечення за теперішніх темпах розвитку робиться набагато швидше, ніж проходить успішне  тестування, а навіть після успішного тестування ніхто не застрахований від помилок. Компанії, що виробляють програмне забезпечення, дістають колосальних збитків та навіть гублять своїх покупців у разі, якщо помилка не виправлена вчасно. Найбільш гостро ця проблема визначається у ігровій індустрії. За обставин жорстокої конкуренції більшість ігор робиться прискорено, є багато випадків, коли вже у продажу гра не працює. Досвідчені розробники використовують перевірені часом рішення, а не пишуть свої власні реалізації. Люди більш довіряють стабільному та надійному програмному забезпеченню, яке в свою чергу теж пройшло тернистий шлях доробок та виправлень помилок. На сьогоднішній день вади рефакторінгу перевищують користь від нього, тому ним практично ніхто не займається. В цілому даний підхід є логічним, бо навіщо переробляти програму, яка і так працює? Треба зазначити, що багато старих програм, незважаючи на вік використаних технологій, є відмінними зразками, не рідко виконані краще, ніж сучасні аналоги. З цього можна зробити висновок, що при рефакторингі таких програм їх дуже важко покращити, не зробив жодної помилки. Людина робить помилки, це нормально, тому що на помилках людина навчається. Традиційно вважається, що машина не робить помилок, або робить їх набагато менше, хоча самі машини роблять люди. В цьому плані рефакторінг можна віднести до тих речей, де дуже дорого виходять помилки, тож їх не повинно бути. На даному етапі розвитку людства, ми ще не маємо машин, що здібні якісно виконувати процес мислення. Рефакторінг загалом  потребує від людини  інтелектуальної роботи, але часто він потребує лише зміни деяких операцій на більш ефективні еквіваленти. Яскравим прикладом такого рефакторінгу є переробка суми масивів з використанням MMX або SSE. Отримані в результаті такої переробки програми є повними еквівалентами, за виключенням того, що виконуються у багато разів швидше.

На сьогоднішній день вирішення цієї проблеми вже частково автоматизовано, в основному завдяки глибокому аналізу на етапі компіляції програми. Для цього використовуються спеціальні оптимізуючи компілятори, найчастіше розраховані на конкретну платформу. Особливо яскраво це виражається у компіляторах від фірми Intel, після використання яких простежується підвищення ефективності при виконанні програм на процесорах тієї ж фірми. Рішення такого типу ідеально підходять для тих випадків, коли компіляція програм робиться лише один раз, приймаючи кінцевий вид у вигляді програмного коду для конкретної платформи.

Простіше рішення мають програми для віртуальних машин, де в основному переробка стосується лише віртуальної машини, а не самих програм. При цьому нові віртуальні машини досягають підвищення ефективності завдяки паралельному виконанню внутрішніх робот, таких як сбір сміття, пошук у таблиці символів тощо. Такі віртуальні машини фактично не роблять програму паралельною, а підвищення ефективності виникає  завдяки  зменшення внутрішніх затримок. Основною перевагою цього рішення є те, що підвищення ефективності є зразу під час виконання, не потребуючи для цього завчасної обробки тексту програми. Крім того, це дозволяє оптимізувати динамічно сформовану під час виконання програму. Для динамічно сформованої програми не підходять існуючі методи з оптимізації тексту, бо текст програми не є визначеним.

Однією з подібних систем є Лісп системи. Лісп є функціональною мовою, в котрій текст та данні програми представлені однаково. Крім того, сам механізм віртуальної машини простий в реалізації. Мова Лісп є другою за рахунком мовою високого рівня, та в першу чергу була винайдена для обробки списків (List processing). Ця особливість даної мови орієнтувала її на натуральну мову, роблячи її зручною для вирішення задач штучного інтелекту. Рекурсія та лямбда-вирази зробили мову зручною для математичних досліджень, а також для утворення баз даних. Мова логічного програмування – Пролог, дуже просто реалізується на Лісп. Ідея рекурсивного паралелізму у цій мові така ж стара, як і сама мова. Діло в тому,що виконання Лісп програм базується на рекурсії.

    Предметом дослідження є модель транслятору мови Лісп, що має можливість паралельного виконання програм з підвищенням їх ефективності.

Використання паралельних обчислень у мові Лісп не є новим, багато реалізацій трансляторів мови Лісп дозволяють створювати нові процеси для виконання задач. Першими рішеннями були додатково введені функції операційної системи для роботи з процесами та іншими системними об’єктами. Стандарт Common Lisp задав механізм виклику системних функцій, однак у різних операційних системах ці функції були різними. Іншим рішенням для паралельного виконання програм було введення додаткових конструкцій мови для визначення паралельного виконання. Ці розширення мали назву «прозорі», бо якщо їх видалити з тексту коректної програми, результати роботи не зміняться. Одна з таких конструкцій – “future” була занесена до стандарту язика для створення відкладених обчислень.

Kyoto Common Lisp (університет Кіото) - 1985,AOS/VS для ECLIPSE MV, Unix 4.2 bsd для Sun Workstation (на базі Motorola 6800). Для визначення паралельного виконання використовуються функції ОС. Ця реалізація Ліспу була найбільш повною та потужною. Усі наступні реалізації Common Lisp базувалися на її частинах, а деякі функції навіть перейшли у стандарт мови. Реалізація мала додатковий інтерфейс для мови Сі. Основні функції для роботи з ОС були перенесені з Сі в Лісп, не змінивши навіть аргументи.

MultiLisp 1985. Перше використання конструкції “future” . Ця додаткова конструкція додавала простий, ефективний та елегантний спосіб для паралельного виконання програм. Цей спосіб полягав у тому, що тіло даної конструкції обчислювалося паралельно, а на місце результату виконання ставав заступник. Коли головна програма доходила до місця, де був потрібен результат, вона чекала на нього, у разі якщо паралельний процес ще не обчислив його. Перевагами цього було те, що крім цієї конструкції нічого не потрібно було писати для синхронізації, крім того з заступником можна було робити будь-які операції, що не потребували знання результату, наприклад конструювати список або брати наступний після нього елемент. Конструкція “future” у 1991 році увійшло до стандарту Лісп.

Qlisp (Lucid Inc) – 1989 (мультипроцесорна система з роздільною пам’яттю). Паралелізм визначався спеціальними конструкціями мови, віртуальна машина динамічно регулювала кількість паралельних задач у відносності до кількості зайнятих процесорів, вводила додаткові конструкцій для синхронізації з боку користувача.

MultiLisp (університет Монреалю) – 1993, реалізація “future” через MPI. У даній роботі був проведений аналіз існуючих методів керування задачами, що називаються «Нетерпляча задача» та «Лінива задача». Завдяки їх реалізації «Лінивої задачі» з’явилася можливість підвищення ефективності на MPI більше, ніж на мультипроцесорах, що використовують одну пам'ять. Основним недоліком до їх реалізації була висока вартість синхронізації при розподіленні задач між процесорами.

TS/SCHEME (NEC) - 1994,STING, Silicon Graphics MIPS R4000 (розподілена система для об’єктно-орієнтованого Ліспу). Паралелізм визначався також спеціальними конструкціями мови.

BandaLisp (університет Сінгапуру) – 1994,SunOS 5.3 SunSparc Server 1000 (мультипроцесорна система з загальною пам’яттю). Паралелізм визначався спеціальними конструкціями мови та компіляція програми. Не дивлячись на те, що дана система була розрахована лише на послідовний діалект Ліспу Scheme, проводилася оптимізуюча компіляція частин програми у машинний код. Результатами цих переробок були дуже високі  показники ефективності програм, часто достигаючі показників при рішенні задачи на паралельному Сі. Ціллю даного проекту було спростування поширеної думки про те, що Лісп програми програють їх Сі еквівалентам. Незважаючи на успішний результат, таке негативне ставлення до Ліспу ще досі поширено.

Починаючи з 1995 року цікавість до Ліспу впала, цим мотивується відсутність літератури за даний період. В період з 2000 по 2007 роки нових підходів не формувалось, з’явилося декілька реалізацій Ліспу з відкритим кодом на різні платформи, при цьому використані методи лишилися тими самими. Більшість реалізацій розраховано на спеціальні мультипроцесорні системи.

Основними перевагами даних реалізацій є їх висока ефективність, велика база бібліотек та підтримка об’єктно-орієнтованих технологій.

Усі реалізації потребують використання додаткових конструкцій мови, яки повинні вказуватися у тексті програми. Ця особливість робить реалізації не дійсними для паралельного виконання програм без переробки тексту програмістом.

На практиці більшість чистих Лісп програм можуть бути легко виконані паралельно автоматично,базуючись на рекурсивних функціях без побічних ефектів. Але для підтримання послідовного стилю написання програм мова Лісп була розширена спеціальними конструкціями. Більшість таких конструкцій мають побічні ефекти, таким чином їх не можна не враховувати. Не зважаючи на велику кількість скобок, синтаксис мови є максимально простим, що дозволяє писати програми з нестандартною структурою, наприклад динамічно формуючі програму, як було відмічено вище. У цьому сенсі Лісп дозволяє навіть такий безлад, як інше визначення стандартних функцій функціями користувача, безпосереднє управління зв’язками атомів. Таким чином Лісп розрахований на повну анархію програми, таких конструкцій не дозволяє утворювати жодна мова з перевіркою типів. Не можна сказати, що ця особливість мови є особливо корисною, бо такі програми важко аналізуються. У цьому плані думки розходяться. Деякі вважають, що строге написання програми краще, а у Лісп краще заборонити такі речі. Інші вважають, що такі конструкції підвищують можливості мови, також дають змогу писати унікальні програми. У даній роботі автор переконаний, що кожна людина має право використовувати ці можливості на свій смак.

Крім того, не треба недооцінювати можливості по паралельному виконанню внутрішніх процесів транслятору. У даній роботі мається намір паралельно збирати сміття та організувати конвеєр для обробки текстів.

Ціллю даної роботи є створення паралельного транслятору мови Лісп, що не потребує додаткових конструкцій мови для визначення паралельних обчислень. Для цього у віртуальну Лісп машину планується вставити аналізатор виконання програми з можливістю протоколювання окремих процесів. Крім цього у віртуальну машину буде вбудований механізм для запису програми у стані виконання, а також загрузки стану та продовження виконання з місця зупинки. Для контролю правильності виконання програми передбачається механізм самодіагностики з можливістю виправлення. Перевірку повного тексту програми на предмет паралельних обчислень у Лісп робити не оптимально, бо в цьому разі потрібно буде прораховувати взаємно неможливі шляхи виконання, при цьому лише один шлях буде використаний. Крім того, вільність мови дуже ускладнює механізм виявлення залежностей. Передбаченим методом вирішення цієї проблеми є контроль по ходу виконання. Таким чином, передбачену реалізацію транслятору мови Лісп можна вважати не тільки паралельною віртуальною машиною, але я як інструмент для аналізу послідовних програм на предмет паралельного виконання. Легкість переносу на інші платформи буде забезпечуватися завдяки використанню MPI, бо на сьогоднішній день він вже реалізований майже на всіх платформах.

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

На даний момент робота знаходиться у стадії розробки, буде завершена у грудні 2007 року.