Хороший приклад масиву змінної довжини C [закритий]

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

Чи можете ви навести приклад , коли використання C99 VLA надає реальну перевагу перед чимось на зразок поточних стандартних купових механізмів, що використовують C ++ RAII механізми?

Приклад, за яким я після:

1. Досягніть легко вимірюваної (на 10% можливо) переваги в порівнянні з використанням купи.
2. Не мати хорошого вирішення, яке взагалі не знадобилося б для всього масиву.
3. Фактично виграш від використання динамічного розміру замість фіксованого максимального розміру.
4. У звичайному сценарії використання навряд чи викличете переповнення стека.
5. Будьте достатньо сильні, щоб спокусити розробника, який потребує продуктивності, щоб включити вихідний файл C99 у проект C ++.

Додавання деяких пояснень у контексті: я маю на увазі VLA як мається на увазі під C99 і не включений у стандарт C ++: int array[n]де nє змінною. Я переглядаю приклад використання, коли він перетворює альтернативи, запропоновані іншими стандартами (C90, C ++ 11):

int array[MAXSIZE]; // C stack array with compile time constant size
int *array = calloc(n, sizeof int); // C heap array with manual free
int *array = new int[n]; // C++ heap array with manual delete
std::unique_ptr<int[]> array(new int[n]); // C++ heap array with RAII
std::vector<int> array(n); // STL container with preallocated size

Деякі ідеї:

• Функції, що приймають вараги, що, природно, обмежує кількість елементів до чогось розумного, але не має жодної корисної верхньої межі рівня API.
• Рекурсивні функції, де витрачається стек небажано
• Багато невеликих асигнувань і випусків, де купа грошових витрат буде поганою.
• Обробка багатовимірних масивів (на зразок матриць довільного розміру), де продуктивність є критичною, а малі функції, як очікується, будуть багато вбудовані.
• З коментаря: паралельний алгоритм, де розподіл купи має накладні синхронізації .

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

Примітка. Я спеціально після прикладу коду чи пропозиції алгоритму, який би виграв від цього, щоб я сам застосував приклад.

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

Для ДУЖЕ малих масивів це показує явну вигоду від закінчення VLA std::vector<>.

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

Для ДУЖЕ малих значень "кількості випадкових чисел" (x) у відповідних функціях vlaрішення виграє з величезним відривом. Оскільки розмір збільшується, "виграш" стає меншим, і, враховуючи достатній розмір, векторне рішення виявляється БІЛЬШЕ ефективним - не вивчав цей варіант занадто багато, як коли ми починаємо мати тисячі елементів у VLA, це не дійсно те, що вони мали на меті зробити ...

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

Запускаючи цей конкретний варіант, я отримую приблизно 10% різниці між func1(VLA) та func2(std :: vector).

count = 9884
func1 time in clocks per iteration 7048685
count = 9884
func2 time in clocks per iteration 7661067
count = 9884
func3 time in clocks per iteration 8971878

Це складено з: g++ -O3 -Wall -Wextra -std=gnu++0x -o vla vla.cpp

Ось код:

#include <iostream>
#include <vector>
#include <cstdint>
#include <cstdlib>

using namespace std;

const int SIZE = 1000000;

uint64_t g_val[SIZE];


static __inline__ unsigned long long rdtsc(void)
{
    unsigned hi, lo;
    __asm__ __volatile__ ("rdtsc" : "=a"(lo), "=d"(hi));
    return ( (unsigned long long)lo)|( ((unsigned long long)hi)<<32 );
}


int func1(int x)
{
    int v[x];

    int vmax = 0;
    int vmin = x;
    for(int i = 0; i < x; i++)
    {
        v[i] = rand() % x;
        if (v[i] > vmax) 
            vmax = v[i];
        if (v[i] < vmin) 
            vmin = v[i];
    }
    int avg = (vmax + vmin) / 2;
    int count = 0;
    for(int i = 0; i < x; i++)
    {
        if (v[i] > avg)
        {
            count++;
        }
    }
    return count;
}

int func2(int x)
{
    vector<int> v;
    v.resize(x); 

    int vmax = 0;
    int vmin = x;
    for(int i = 0; i < x; i++)
    {
        v[i] = rand() % x;
        if (v[i] > vmax) 
            vmax = v[i];
        if (v[i] < vmin) 
            vmin = v[i];
    }
    int avg = (vmax + vmin) / 2;
    int count = 0;
    for(int i = 0; i < x; i++)
    {
        if (v[i] > avg)
        {
            count++;
        }
    }
    return count;
}    

int func3(int x)
{
    vector<int> v;

    int vmax = 0;
    int vmin = x;
    for(int i = 0; i < x; i++)
    {
        v.push_back(rand() % x);
        if (v[i] > vmax) 
            vmax = v[i];
        if (v[i] < vmin) 
            vmin = v[i];
    }
    int avg = (vmax + vmin) / 2;
    int count = 0;
    for(int i = 0; i < x; i++)
    {
        if (v[i] > avg)
        {
            count++;
        }
    }
    return count;
}    

void runbench(int (*f)(int), const char *name)
{
    srand(41711211);
    uint64_t long t = rdtsc();
    int count = 0;
    for(int i = 20; i < 200; i++)
    {
        count += f(i);
    }
    t = rdtsc() - t;
    cout << "count = " << count << endl;
    cout << name << " time in clocks per iteration " << dec << t << endl;
}

struct function
{
    int (*func)(int);
    const char *name;
};


#define FUNC(f) { f, #f }

function funcs[] = 
{
    FUNC(func1),
    FUNC(func2),
    FUNC(func3),
}; 


int main()
{
    for(size_t i = 0; i < sizeof(funcs)/sizeof(funcs[0]); i++)
    {
        runbench(funcs[i].func, funcs[i].name);
    }
}

Щодо VLAs проти вектора

Чи вважали ви, що вектор може скористатися самими VLAs. Без VLAs вектор має вказати певні "масштаби" масивів, наприклад, 10, 100, 10000 для зберігання, щоб у кінцевому підсумку виділити масив 10000 елементів для вміщення 101 елемента. Якщо VLA, якщо ви зміните розмір до 200, алгоритм може припустити, що вам знадобиться лише 200 і можете виділити масив 200 елементів. Або він може виділити буфер сказати n * 1,5.

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

Цей додатковий стрибок вказівника з вектора на його внутрішній масив додається.

Відповідаючи на головне питання

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

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

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

Насправді, у більшості місць, де VLA використовуються таким чином, вони не замінюють купі виклики, а замінюють щось на кшталт:

float vals[256]; /* I hope we never get more! */

Річ у будь-якій місцевій декларації полягає в тому, що це надзвичайно швидко. Лінія float vals[n]зазвичай вимагає лише декількох інструкцій процесора (можливо, лише одну.) Вона просто додає значення в nпокажчик стека.

З іншого боку, для розподілу купи потрібна структура даних для пошуку вільної області. Час, ймовірно, на порядок довший навіть у найщасливішому випадку. (Тобто, лише акт розміщення nна стеку та виклик malloc- це, мабуть, 5-10 інструкцій.) Можливо, набагато гірше, якщо в купі є якийсь розумний обсяг даних. Мене зовсім би не здивувало, коли я бачив випадок, коли mallocв реальній програмі було 100х до 1000х повільніше.

Звичайно, тоді ви також матимете деякий вплив на ефективність із збігом free, ймовірно, за величиною схожим на mallocвиклик.

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