Скільки слід оптимізувати наукове програмне забезпечення?

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

Скільки потрібно часу і сил, щоб розробники програмного забезпечення вклали гроші в оптимізацію програми? Які ключові критерії використовуються?

У переважній більшості випадків вдосконалення алгоритмів мають більшу різницю, ніж поліпшення оптимізації. Алгоритми також більш портативні, ніж оптимізації низького рівня. Моя порада - дотримуватися загальних найкращих практик щодо компонування пам’яті для повторного використання кешу, уникати надмірних копій чи зв’язку, обробляти файлову систему розумним способом, а ядра з плаваючою комою мають достатню деталізацію для векторизації. Іноді цього достатньо, щоб досягти прийнятно високої частки "піку" (для цієї операції).

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

Мабуть, найскладнішим завданням є проектування важливих (у тому сенсі, що багато коду залежатиме від цих варіантів) інтерфейсів та структур даних, щоб потім можна було оптимізувати, не потребуючи змін API. На відміну від конкретних оптимізацій та загальних рекомендацій, я не знаю, як цього навчити, окрім досвіду. Робота з чутливим до продуктивності програмним забезпеченням з відкритим кодом допомагає. Як і у випадку будь-якого рішення API, важливо зрозуміти проблемний простір.

Як би ви визначили "оптимізувати"? Існує цілий спектр від розробки кращих алгоритмів чи обчислювальних моделей до використання налаштованого вручну асемблера.

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

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

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

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

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

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

Вам доведеться зробити аналіз (витрат) витрачання стільки людських місяців (а вони завжди міфічні :-)) на досягнення швидкості виконання. Вам доведеться розібратися, скільки разів буде використано цю частину програмного забезпечення та скільки людей, щоб ви могли оцінити виграш.

Як правило, правило - це відоме правило 80/20. У якийсь момент він просто не додає більше витрачати більше часу на здобуття кількох відсотків (або менше) часу роботи. Але вам доведеться проаналізувати.

І я щиро погоджуюся з вищезазначеними плакатами: переконайтеся, що ваш API добре продуманий, тому він не потребує багатьох змін і переконайтесь, що код є переносним та ремонтопридатним (подумайте про необхідність повторного аналізу алгоритму, який ви написали, і nitty-gritty оптимізовано десять років тому). І переконайтеся, що ви використовуєте добру практику програмування та стандартні бібліотеки. Швидше за все, хтось уже задумався про найефективніший алгоритм для вашої програми.

Цитувати Дональда Кнута: "передчасна оптимізація - корінь усього зла". Тож профіліруйте свій код, але не надто скоро.

Деякі додаткові поради:

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