20% продуктивного штрафу за хороший дизайн програмного забезпечення

17

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

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

Спочатку це виглядало досить похмуро; код, яким я колись пишався, працював на 60% повільніше, ніж версія без будь-якого елегантного дизайну програмного забезпечення. Але мені вдалося зробити кілька оптимізацій низького рівня - вбудовану функцію та невелику зміну циклу - без зміни API зовсім. З тими змінами, це лише на 20% повільніше, ніж конкуренція.

Що приводить мене до мого питання: Скільки втрати продуктивності я повинен прийняти, якщо це означає, що у мене є хороша об'єктна модель?

linear-algebra sparse-matrix oop

— Даніель Шаперо
джерело

Яку операцію з розрідженою матрицею ви вимірювали?

— Білл Барт

Множимо матричний вектор. Матриці в діапазоні розмірів від

. Я зробив їх графіком Лаплакій для випадкових графіків Ердоса-Рені з середнім ступенем

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

n = 1024, . . ., 16384

$n = 1024,...,16384$

d = \log_{2} n

$d = \log_2n$

— Даніель Шаперо

3

Яку мову програмування ви використовуєте? Зазвичай щось на зразок C ++ дозволить вам уникнути елегантних (іш) дизайнів за низькою (або неіснуючої) вартості. В інших мовах без метапрограмування (Java, Fortran тощо) 20% вартість здається розумною.

— Л.Клевін

Чи можете ви показати нам свій код? Якою мовою ви користувалися? Що таке компілятор та прапорці компіляції? Ви точно знайшли, звідки береться хіт виступу? Як ви переконалися, що знайшли правильну причину? Який профілер ви використовували та як ним користувалися? Ви впевнені, що симпатична об'єктна модель не реалізована неефективно? 20% - це досить мало, що вам потрібно зібрати багато даних і провести детальний аналіз, перш ніж сказати, що це, безумовно, пов'язано з дизайном, а не, скажімо, неповноцінною реалізацією чи деякими іншими проблемами кодування.

— Кирило

Коротка сторона: все, схоже, публічно хвалить хороший дизайн за чисті експлуатаційні характеристики (звичайно, з дуже поважних причин). Але тоді, чому так багато реального світового коду насправді, насправді нездійсненного? Чи всі члени кодексу відчувають свою провину і, таким чином, публічно мовчать?

— AlexE

9

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

Ось кілька типових прикладів цих обмежень, які можуть бути застосовані до дизайну вашої розрідженої матричної бібліотеки:

Завершено за один місяць
Працює правильно на своєму ноутбуці та декількох робочих станціях
Працює ефективно

Вчені поступово приділяють більше уваги деяким іншим загальним вимогам з інженерії програмного забезпечення:

Документація (керівництво користувача, підручник, коментування коду)
Ремонтопридатність (контроль версій, тестування, модульний дизайн)
Багаторазовість (модульна конструкція, "гнучкість")

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

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

Але що робити, якщо у вас недостатньо часу на розробку? Що достатньо добре? Ну, це залежить, і ніхто не зможе дати вам гарну відповідь на це питання без більшого контексту.

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

— Арон Ахмадія
джерело

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

— Даніель Шаперо

ATLAS, FFTW, Spiral, OSKI, Ignition, stencil_codegen, щоб назвати кілька. Це публічно не рекламується, але я не здивуюсь, якщо кілька важливих ядер у MKL та ESSL генеруються таким чином. Цілком цікавим подальшим питанням може бути написання коду для збереження ядра. У мене є досвід у цьому, але я б не вважав себе авторитетом.

— Арон Ахмадія

12

Це питання, на що ви витрачаєте свій час. Для більшості з нас ми витрачаємо 3/4 часу на програмування і 1/4 часу на очікування результатів. (Ваші номери можуть відрізнятися, але я думаю, що це число не повністю без достоїнств.) Отже, якщо у вас є дизайн, який дозволив програмувати вдвічі швидше (3/4 одиниці часу замість 1,5 одиниць часу), то ви Ви можете нанести 300-відсоткову ефективність (від 1/4 до 1-ої одиниці часу), і Ви все одно випереджаєте в плані реального часу, витраченого на вирішення проблеми.

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

Мені 20% здаються досить гарними компромісами, якщо ти в кінцевому підсумку буде більш продуктивним.

— Вольфганг Бангерт
джерело

Хороша відповідь, я також додав би важливості, коли важлива робота. Даний науковий код не робить лише матричне множення; якщо 20% вашого часу виконання перебуває в матричному множенні, 20-відсоткове враження від продуктивності є загальною різницею лише на 4%, і я б із задоволенням взяв це в обмін на більш просту у використанні бібліотеку.

— Аврелій

1

А краща письмова бібліотека означає менше помилок, щоб ви талійовували менше часу, чекаючи неправильних результатів.

— Давидм

4

IMHO штраф до 50% (з будь-якої причини) не так вже й погано.

Насправді я бачив різницю у продуктивності на 0-30% саме на основі типу компілятора. Це для рідкісної програми MatMult PETSc на матрицях, що випливає з дискреційності FE низького порядку.

— stali
джерело

1

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

— MirekE
джерело

Я не думаю, що це відповідає на питання.

— nicoguaro

0

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

— jolvi
джерело