Емпіричне порівняння семи мов програмування

1. Діаграми і статистичні методи
2. результати
3. Час виконання програми
4. Вимоги до пам'яті
5. Довжина програм і число коментарів
6. надійність програм
7. Час роботи і продуктивність праці
8. структура програми
9. найважливіші висновки
10. Достовірність порівняння
11. Кваліфікація програмістів
12. Точність вимірювання часу роботи
13. Різниця завдань і умов роботи
14. Висновки
15. повернутися
16. Завдання: перетворення телефонних номерів

Програмісти і вчені, як правило, упереджені, коли мова заходить про переваги і недоліки різних мов програмування. Порівнявши кілька мов, автор спробував отримати об'єктивну інформацію про Сі, Сі ++, Java, Perl, Python, Rexx і Tcl.

Для зіставлення була використана одна програма, яка пред'являє однаковий набір вимог до всіх мов. Такий прийом звужує область порівняння, але робить її однорідною. Крім того, для кожної мови було проаналізовано кілька окремих реалізацій програми, підготовлених різними програмістами. Груповий підхід має дві переваги. По-перше, згладжуються відмінності між окремими програмістами, які можуть позбавити достовірності будь-які порівняння, засновані на єдиному «зразку» для кожної мови. По-друге, з'являється можливість порівняти мінливість характеристик програм, складених на різних мовах.

В ході порівняльного дослідження зіставлялися різні аспекти кожної мови, в тому числі довжина програми, зусилля, витрачені на програмування, час виконання, займане простір пам'яті і надійність. Мови порівнювалися індивідуально і по групах. Мови сценаріїв, такі як Perl, Python, Rexx і Tcl частіше інтерпретуються, ніж компілюються (по крайней мере, на етапі розробки програм), і зазвичай не вимагають визначення змінних.

Більш традиційні мови програмування - Сі, Сі ++ і Java - частіше компілюються, ніж інтерпретуються і вимагають опису типів змінних. Оскільки багато хто вважає мову Java дуже неефективним, я іноді відносив Сі і СІ ++ до однієї групи, а Java до іншої.

Діаграми і статистичні методи

В якості основного інструменту оцінки в статті використовується блокова діаграма, показана на рис. 1. Кожна лінія представляє одне підмножина даних, ім'я якого зазначено зліва. Кожним малим гуртком позначено одне значення даних. Інша частина діаграми допомагає візуально порівняти два або кілька підмножин даних. В затіненому блоці укладена середня половина значень, між верхніми межами першої чверті (25%) і третьої чверті (75%). «Вуса» ліворуч і праворуч від блоку показують нижні і верхні 10%, відповідно. Жирна крапка усередині блоку - верхня межа другої чверті (50%). Символ «M» і розірвана лінія навколо нього показує середнє арифметичне, плюс / мінус среднеквадратическую помилку.

Рис. 1. Час роботи програми з набором даних z1000
Виконання трьох програм було завершено безрезультатно після закінчення приблизно 21 хвилини. Розкид відносин «поганих і хороших величин» становить від 1,5 для Tcl до 27 для Сі ++. Зверніть увагу на логарифмический масштаб осі. Пояснення до даного малюнку відносяться також до Рис. 2-7. Більш докладний опис дано в розділі «Діаграми і статистичні методи»

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

Найважливіший висновок можна зробити безпосередньо з діаграми. Однак для повторного огляду були виконані статистичні тести. Для порівняння середніх значень використовується односторонній U-критерій Манна-Уїтні (також званий критерієм суми рангів Уилкоксона). Результат кожного тесту - p, величина, що характеризує ймовірність того, що спостережувана різниця між двома вибірками лише випадкова, і що в дійсності відмінності між двома групами величин відсутні або мають протилежний знак. Зазвичай саме p-значення не наводиться, а в тексті статті вказується «... більше, ніж ...», якщо 0 0,10, то «істотних відмінностей немає».

У ряді випадків вказані довірчі інтервали для відмінностей в середніх значеннях або для відмінностей в логарифмах середніх значень - т. Е., Відносин середніх величин. Обрані відкриті рівні довірливості, з нескінченної верхньою межею. Довірчі інтервали обчислені методом розкрутки (bootstrap), докладно описаними в багатьох джерелах (див., Наприклад, [ 1 ]).

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

В таблиці 1 показано число програм для кожної мови і платформи виконання. Для оцінки Java використовувалися комплекти розробників JDK 1.2.2 Hotspot Reference version або JDK 1.2.1 Solaris Production version with JIT, в залежності від того, яка платформа забезпечувала більшу швидкодію конкретної програми. Всі програми виконувалися на робочій станції Sun Ultra II / 300 МГц з оперативною пам'яттю ємністю 256 Мбайт, оснащеної операційною системою SunOS 5.7. Результати для мов Сі і Rexx отримані на підставі всього п'яти і чотирьох програм, відповідно, і тому можуть вважатися лише грубим наближенням до дійсності; для всіх інших мов результати були отримані після аналізу 10 і більше програм - прийнятно широке представництво для досить точної оцінки.

у виразках «Задача: перетворення телефонних номерів» і «Достовірність порівняння» описані організація і достовірність дослідження. Читачі можуть знайти більш докладний опис дослідження в Web [ 2 ].

результати

Для оцінки програм використовувалися три різних вхідних файлу: z1000, що містить 1000 непустих випадкових телефонних номерів; m1000, що містить 1000 довільних випадкових телефонних номерів, деякі з яких могли бути порожніми; і z0, що не містить телефонних номерів і службовець виключно для вимірювання часу завантаження словника.

Час виконання програми

Я почав аналіз з вимірювання повного часу виконання, а потім досліджував окремо етапи ініціалізації і пошуку.

Повний набір даних z1000. Як показано на рис. 1, час виконання всіх програм за винятком Сі ++, Java і Rexx, становить менше 1 хв. Порівнюючи дані, можна зробити кілька значущих висновків.

• Середній час виконання програм Tcl незначно більше, ніж Java і навіть Сі ++.
• Середній час виконання як для Python, так і для Perl менше, ніж Rexx і Tcl.
• Середній показник Сі ++ може ввести в оману. Через досить великий розкид між сусідніми великими і меншими величинами, середнє значення нестабільно. Критерій Уилкоксона, який враховує весь набір даних, підтверджує, що середній час для Сі ++, як правило, менше середнього часу для Java (p = 0,18).
• Середній час виконання для Сі менше, ніж для Java, Rexx і Tcl, і як правило, менше ніж для Perl і Python.
• Час виконання для Tcl і Perl - за винятком двох дуже повільних програм - як правило, більш стабільно, ніж час виконання програм на інших мовах.

Не слід надавати особливо великого значення діаграм для Сі і Rexx, побудованим за все по декількох точках. Час виконання програм на Rexx може бути знижено приблизно в чотири рази, якщо перекомпіліровать інтерпретатор Regina для використання хеш-таблиць більшого розміру; вимоги до пам'яті при цьому зростають незначно. Якщо об'єднати мови всього в три групи (одна - Сі і СІ ++, друга - Java, третя - мови сценаріїв), то програми на Сі та Сі ++ працюють швидше, ніж Java (p = 0,074), і як правило, швидше сценаріїв (p = 0,15).

Між середнім часом виконання програм на Java і сценаріїв немає суттєвої різниці. З ймовірністю 80% сценарій буде виконуватися в 1,29 рази довше - а програма на Java щонайменше в 1,22 рази довше - чим програма на Сі або Сі ++. Ставлення «поганих і хороших величин» значно менше для сценаріїв (4,1), ніж для Java (18) і навіть для Сі і Сі ++ (35).

Тільки етап ініціалізації, набір даних z0. Потім я виміряв час, необхідний для зчитування, попередньої обробки та збереження словника. Відповідні часи наведені на рис. 2. Результати явно свідчать, що Сі і Сі ++ виконують цю фазу швидше, ніж інші протестовані мови. І знову, найшвидшими мовами сценаріїв виявилися Perl і Python. Як з'ясувалося (з ймовірністю 80%) при порівнянні укрупнених груп, програма на Java буде виконуватися по крайней мере в 1,3 рази довше, ніж програми на Сі та Сі ++, а для виконання сценарію буде потрібно принаймні в 5,5 раз більше часу. Сценарій буде виконуватися по крайней мере в 3,2 рази довше програми на Java.

Рис. 2. Час, витрачений програмою тільки на завантаження і попередню обробку словника (набір даних z0). Зверніть увагу на логарифмический масштаб осі. Співвідношення «поганих і хороших величин» в межах від 1,3 для Tcl до 7,5 для Python

Тільки етап пошуку. І нарешті, я вирахував час час етапу завантаження (набір даних z0) з повного часу виконання (набір даних z1000), щоб отримати час тільки пошукового етапу програми. На рис. 3 показані відповідні часи, з яких можна зробити наступні висновки.

• Дуже швидкі програми складені на всіх мовах, за винятком Rexx і Tcl, а дуже повільні програми зустрічаються на всіх мовах.
• Середній час виконання програм на Tcl більше, ніж час програм на мовах Python, Perl і Сі, але менше, ніж на Rexx.
• Середній час виконання програм на Python менше, ніж часи для Rexx і Tcl, і як правило, менше, ніж час виконання Java (p = 0,13).
• Середній час виконання програм на Perl менше середніх показників для Rexx, Tcl і Java.
• Середній час Сі ++ істотно відрізняється від результатів іншої мови.

Рис. 3. Час, витрачений програмою тільки на пошук, обчислене як різниця між часом роботи з набором даних z1000 і набором даних z0. Зверніть увагу на логарифмический масштаб осі. Співвідношення «поганих і хороших величин» в межах від 2,9 для Perl до 50 для Сі ++

Порівняння укрупнених груп свідчить про відсутність серйозних відмінностей між будь-якими групами. Однак можна з ймовірністю 80% стверджувати, що розкид часу виконання сценаріїв принаймні в 2,1 рази менше, ніж у Java, і принаймні в 3,4 рази менше, ніж у Сі і Сі ++.

Вимоги до пам'яті

На рис. 4 показаний загальний розмір процесу в кінці обробки вхідного файлу z1000. З нього можна зробити кілька висновків.

• Очевидно, що найбільш ефективно пам'ять використовується в програмах груп Сі і Сі ++, а найменш ефективно - в програмах групи Java.
• За винятком Tcl, лише деякі сценарії споживають більше пам'яті, ніж найгірша половина програм на Сі і Сі ++.
• Для сценаріїв Tcl потрібно більше пам'яті, ніж для інших сценаріїв.
• Відносний розкид вимог до пам'яті програм на Python і Perl, як правило менше, ніж програм на Сі і особливо Сі ++.
• Деякі сценарії займають великі області пам'яті.
• При порівнянні укрупнених груп можна стверджувати з імовірністю 80%, що в середньому програми на Java займають принаймні на 32 Мбайт більше пам'яті (297%), ніж програми на Сі та Сі ++, і принаймні на 20 Мбайт більше (98 %), ніж сценарії. Сценарії займають принаймні на 9 Мбайт більше пам'яті (85%), ніж програми на Сі та Сі ++.

Рис. 4. Обсяг пам'яті, необхідний програмі, в тому числі для розміщення інтерпретатора або виконуючою системи, власне програми і всіх статичних і динамічних структур даних. Співвідношення «поганих і хороших величин» в межах від 1,2 для Python до 4,9 для Сі ++

З цих даних можна зробити висновок, що вимоги Java до пам'яті зазвичай удвічі вище вимог сценаріїв, а сценарії не обов'язково менш ефективно використовують пам'ять, ніж програми, складені на Сі і Сі ++, хоча і не можуть перевершити економну програму на Сі або Сі ++ .

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

Довжина програм і число коментарів

На рис. 5 показано число рядків вихідного файлу кожної програми, в яких міститься будь-яка семантична інформація програми: оператори, визначення або принаймні роздільники, такі як закриває фігурна дужка. Несценарние файли зазвичай удвічі або втричі довше сценаріїв. Навіть найдовші сценарії коротше середніх несценарних вихідних текстів. Разом з тим, щільність коментарів в сценаріях значно вище (p = 0,020): в несценарних програмах в середньому міститься на 22% більше рядків з коментарями, ніж рядків з операторами; для сценаріїв цей показник становить 34%.

Рис. 5. Довжина програми: число рядків вихідного тексту без коментарів. Співвідношення «поганих і хороших величин» в межах від 1,3 для Сі до 2,1 для Java і 3,7 для Rexx

надійність програм

При роботі з вхідним файлом z1000 три програми - одна на мові Сі, одна на Сі ++ і одна на Perl - не видали коректних результатів, оскільки не могли завантажити великий словник або через закінчення часу, відведеного на завершення етапу завантаження. Дві програми на Java мали майже нульову надійність і відмовили з інших причин; а одна програма на Rexx видала багато результатів, використовуючи некоректний, тільки форматують сценарій - її надійність склала 45%.

Відкинувши ці явно помилкові програми - тим самим, були виключені 13% програм на Сі і Сі ++, 8% програм на Java і 5% сценаріїв - і порівнявши інші по мовних груп, ми виявили, що програми на Сі та Сі ++ менш надійні, ніж Java і сценарії. Однак ці відмінності були викликані лише кількома програмами з дефектами і тому не можуть бути підставою для загальних висновків.

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

Потім я порівнював поведінку при роботі з вхідним файлом m1000, в якому можуть міститися телефонні номери без цифр, лише з тире і похилими рисами. Такі телефонні номери повинні перетворюватися в порожні записи, але програмісти схильні забувати про такі вимоги, читаючи завдання. Тому на файлі m1000 перевіряється добротність програми. Більшість програм успішно впоралися з цією ситуацією, але половина програм Java та чотири сценарії - один Tcl і три на мові Python - зависли на першому порожньому телефонному номері, після того, як було видано 10% результатів. Зазвичай збій відбувався через неправильне індексу рядка або масиву. Серед інших програм, 15 - одна складена на Сі, п'ять Сі ++, чотири Java, дві Perl, дві Python і одна Rexx - не змогли обробити порожні телефонні номери, але в іншому працювали коректно; їх надійність склала 98,4%.

В цілому, надійність сценаріїв, мабуть, не нижче надійності несценарних програм.

Час роботи і продуктивність праці

На рис. 6 показано загальний час, витрачений на проектування, складання та тестування програми, повідомлене авторами сценаріїв і виміряний для програмістів несценарних програм.

Рис. 6. Повний час, витрачений на реалізацію програми
Програмісти сценарної групи вимірювали і повідомляли час роботи: час мов «несценарной» групи вимірювалося експериментатором. Співвідношення «поганих і хороших величин» в межах від 1,5 для Сі до 3,2 для Perl. Три величини для Java - робочий час 40, 49 і 63 годину - виходять за межі діаграми і тому не показані.

Ми виявили, що час складання сценаріїв із загальною медианой 3,1 години більш ніж удвічі менше, ніж несценарних програм із загальною медианой 10,0 годин, хоча ймовірно, відмінність перебільшено через неповну достовірності експерименту.

На щастя, можна одночасно перевіріті два фактора, а самє, коректність Повідомлень про годину, вітраченій на складання програм, и Рівність кваліфікації програмістів в сценарної и несценарной групах. Обидвоє ЦІ фактори, если смороду Дійсно Грають роль, повінні Сприяти может скоротіті срок служби сценарної групи: я припускають, что суб'єктивні ПОВІДОМЛЕННЯ містітімуть Зменшення, а не перебільшене годину роботи програми, а в разі з'явиться відмінностей ми очікувалі віявіті більш кваліфікованіх програмістів в сценарної групи, оскількі в 1997 и 1998 роках, коли проводилося дослідження, програмісті Java були Менш досвідченімі, чем фахівці з других мов. В основу даної перевірки покладено старе практичне правило, згідно з яким число рядків вихідного тексту, що видаються програмістом в годину, не залежить від мови програмування. У декількох широко застосовуваних методах оцінки трудовитрат - в тому числі Cocomo [3] Баррі Боема і таблицях мов програмування для оцінки функціональних точок [ 4 ] Кейперса Джонса - явно передбачається, що погодинне число рядків вихідного тексту не залежить від мови програмування. на Рис. 7 показані оцінки робочого часу, складені на основі цього правила. Судячи з достовірно відомому діапазону продуктивності при роботі з Java, все величини, за винятком трьох кращих результатів для Tcl і кращих часів для Perl, виглядають правдоподібно.

Рис. 7. Число рядків вихідного тексту, написаних за повний робочий час. Співвідношення «поганих і хороших величин» в межах від 1,4 для Сі до 3,1 для Tcl

Жодне з медіанний відмінностей не має явної статистичної значущості, хоча відмінності Java від Сі, Perl, Python і Tcl (0,07

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

структура програми

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

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

Більш витончений підхід полягає у використанні 10-арного дерева, кожен вузол якого представляє певну цифру, а вузли на висоті n представляють n-ний символ слова. Слово зберігається в вузлі, якщо шлях від кореня до даного вузла представляє числовий шифр слова. Це рішення - найефективніший, але для побудови і проходження дерева потрібно порівняно велика кількість операторів. В Java численність результуючих об'єктів призводить до великої витрати пам'яті через необхідність виділяти надзвичайно великі області для зберігання кожного об'єкта в поточних реалізаціях середовища виконання Java-програм.

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

Хоча хеш-таблиці реалізовані в бібліотеках класів як для Java, так і для Сі ++, жоден з програмістів, які працюють з несценарнимі мовами не скористався ними, вважаючи за краще будувати дерево вручну. І навпаки, автори сценаріїв з готовністю застосовують вбудовані в їх мови хеш-таблиці.

найважливіші висновки

Порівняльний аналіз 80 реалізацій програми кодування телефонних номерів на семи різних мовах приніс такі найважливіші результати.

• Проектування і складання програм на мовах Perl, Python, Rexx і Tcl займає не більше половини часу, необхідного для програмування на Сі, Сі ++ і Java - а довжина вихідного тексту вдвічі менше.
• Явних відмінностей в надійності між програмами різних мовних груп не виявлено.
• Типовий сценарій займає приблизно вдвічі більше пам'яті, ніж програма на Сі або Сі ++. Програми на Java займають втричі і вчетверо більше пам'яті, ніж програми на Сі та Сі ++.
• Програми на Сі і Сі ++ виконують ініціалізацію програми перетворення телефонних номерів, яка полягає в зчитуванні словникового файлу розміром в 1 Мбайт і побудові 70-кілобайтні внутрішньої структури даних, в три або чотири рази швидше, ніж програми на Java і приблизно в п'ять або десять раз швидше, ніж сценарії.
• На основному етапі програми перетворення телефонних номерів ведеться пошук у внутрішній структурі даних, і програми на Сі та Сі ++ працювали всього приблизно вдвічі швидше Java. Сценарії, як правило, працюють швидше програм на Java.
• Серед сценарних мов Perl і Python виконували обидва етапи швидше, ніж Tcl.
• Розкид будь-яких досліджених параметрів програм, що виник внаслідок відмінностей між програмістами, що працюють на одній мові - відбитий відносинами «поганих і хороших величин» - в середньому такий же або більше розкид характеристик, викликаного відмінностями мов.

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

Незважаючи на ці недоліки, пряме зіставлення різних мов програмування може принести корисну інформацію. Наприклад, можна зробити висновок, що витрати Java при роботі з пам'яттю і раніше величезні в порівнянні з Сі і Сі ++, проте час виконання програм стало цілком прийнятним. Мови сценаріїв перетворилися в розумну альтернативу Сі і Сі ++, навіть для задач, пов'язаних з великими обчисленнями і обробкою великих масивів даних. Їх відносне час виконання і вимоги до пам'яті часто прийнятні, а програмувати на них набагато швидше, по крайней мере, при складанні невеликих програм.

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

Лутц Прехельт ( [email protected] ) - керівник служби контролю якості компанії abaXX Technology (Штуттгарт, Німеччина).

література

1. E. Bradley and R. Tibishirani, «An Introduction to the Bootstrap,» Monographs on Statistics and Applied Probability 57, Chapman and Hall, New York, 1993
2. L. Prechelt, An Empirical Comparison of C, C ++, Java, Perl, Python, Rexx and Tcl for Search / String-Processing Program, Tech Report 2000-5, Fakultat fur Informattik , Universitat Karlsruhe, Germany, Mar. 2000.
3. BW Boehm, Software Engineering Economics, Prentice Hall, Englewood Cliffs, NJ, 1981
4. C. Jones, Software Productivity Research , Programming Languages Table, Version 7, 1996..

An Empirical Comparison of Seven Programming Languages, Lutz Prechelt, IEEE Computer, October 2000, pp. 23-29. Copyright IEEE CS, Reprinted with permission. All rights reserved.