Витрати на пошуки порівняно з розрахунками

Мені цікаво налаштувати обчислення, щоб перевірити, чи задоволений критерій відстані: тобто відстань між вектором та вектором пилу має бути менше деякого значення . Мої дані розподілені відповідно до ортогональної сітки координат. Оскільки мій обріз менший за відстань між кінцевими точками координат найближчого сусіда, я хотів би додати змінну "октант", щоб перевірити, чи правильно налаштовані речі: ${\bf x}_i$ ${\bf x}_j$ $r_{\rm max}$

if octant[j] in allowed_list continue

як "коротке замикання" на

if dist(x[i], x[j]) < r_max

Моє запитання: наскільки ефективними обчислювальними є булеві пошуки та порівняння відносно операцій з плаваючою комою? Чи варто це робити в сучасних архітектурах?

efficiency

— aeismail
джерело

Чи бажаєте ви розв'язати свій код і протестувати його? Мені здається, що стандартна відповідь на більшість із них "Краще це кодувати (в один спосіб) чи (іншим способом)?" типів питань є "Спробуйте і порівняйте його".

— Джефф Оксберрі

Всього мої 2 копійки. Як писав Джефф, такий тип порад - це те, що я завжди отримував, коли я задавав подібні запитання щодо stackoverflow щодо коду C ++: спершу кодуйте все, впорядкуйте код так, щоб я залишався модульним і повторно використовувався, і тільки після цього приступайте до рефакторингу. Існує правило 80-20: програмне забезпечення витрачає 80% часу на 20% коду. Зачекайте, поки структура не працює, а потім змінити, перевірити, змінити, перевірити ..

— tmaric

@GeoffOxberry: Моє запитання не настільки специфічне: я просто хочу знати, чи є перевага апаратного забезпечення або компілятора для здійснення булевої перевірки порівняно з операцією з плаваючою комою.

— aeismail

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

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

Моє правило полягає в тому, що якщо ви можете ефективно обчислити деяку кількість (хороше використання FPU) менше ніж 50 флопів за значення подвійної точності, краще перерахувати, ніж зберігати. Тенденція, яка є стійкою протягом десятиліть, полягає в можливості плаваючої крапки вдосконалюватися швидше, ніж продуктивність пам'яті, і, швидше за все, не поступається через фізичні обмеження та енергетичні потреби швидкої пам'яті. Значення 50 має правильну величину для всіх популярних обчислювальних платформ (Intel / AMD, Blue Gene та GPU).

Приблизні оцінки витрат на ядро

[вказівки для 2011/2012 машин на базі Intel та AMD]

нс: час виконати одну операцію з плаваючою точкою з подвійною точністю як частину векторизованого коду без залежностей даних та переплетеного множення / додавання $0.05$
$0.2$
$0.4$
$0.4$ $0.8$
$2$
$3$ $5$
$3$ $5$
$5$
$4$ $8$
$12$
$12$
$30$ $50$
$100$
$10^3$ $1$ $\mu$
$10^4$ $10$ $\mu$
$10^6$
$2\cdot 10^6$ MPI_Allreduce
$10^7$
$5\cdot 10^8$
$1.8\cdot 10^{12}$

Подальше читання

— Джед Браун
джерело

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

— Елділа