Um bom exemplo de matriz de comprimento variável C [fechado]

Como essa pergunta ficou um pouco congelada na SO, decidi excluí-la e tentar aqui. Se você acha que ele também não se encaixa aqui, pelo menos deixe um comentário na sugestão de como encontrar um exemplo que eu estou procurando ...

Você pode dar um exemplo , onde o uso de V99s C99 oferece uma vantagem real sobre algo como os atuais mecanismos C ++ RAII Ceap-heap atuais?

O exemplo que estou procurando deve:

1. Obtenha uma vantagem de desempenho facilmente mensurável (talvez 10%) sobre o uso de heap.
2. Não tem uma boa solução alternativa, que não precisaria de toda a matriz.
3. Beneficie realmente do tamanho dinâmico, em vez do tamanho máximo fixo.
4. É improvável que cause excesso de pilha no cenário de uso normal.
5. Seja forte o suficiente para tentar um desenvolvedor que precisa do desempenho para incluir um arquivo de origem C99 em um projeto C ++.

Adicionando alguns esclarecimentos sobre o contexto: refiro-me ao VLA como significou C99 e não incluído no padrão C ++: int array[n]where né uma variável. E estou atrás de um exemplo de caso de uso em que ele supera as alternativas oferecidas por outros padrões (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

Algumas ideias:

• Funções que utilizam varargs, que limitam naturalmente a contagem de itens a algo razoável, ainda não possuem nenhum limite superior útil no nível da API.
• Funções recursivas, onde pilha desperdiçada é indesejável
• Muitas pequenas alocações e liberações, onde a sobrecarga da pilha seria ruim.
• Manipulação de matrizes multidimensionais (como matrizes de tamanho arbitrário), onde o desempenho é crítico, e espera-se que pequenas funções sejam incorporadas muito.
• Do comentário: algoritmo simultâneo, em que a alocação de heap tem sobrecarga de sincronização .

A Wikipedia tem um exemplo que não atende aos meus critérios , porque a diferença prática de usar heap parece irrelevante, pelo menos sem contexto. Também não é ideal, porque sem mais contexto, parece que a contagem de itens pode muito bem causar estouro de pilha.

Nota: Estou especificamente após um código de exemplo, ou sugestão de um algoritmo que se beneficiaria disso, para eu implementar o exemplo eu mesmo.

Acabei de hackear um pequeno programa que gera um conjunto de números aleatórios reiniciando na mesma semente a cada vez, para garantir que seja "justo" e "comparável". À medida que avança, ele descobre o mínimo e o máximo desses valores. E quando gera o conjunto de números, conta quantos estão acima da média de mine max.

Para matrizes MUITO pequenas, mostra um benefício claro com o término do VLA std::vector<>.

Não é um problema real, mas podemos facilmente imaginar algo em que estaríamos lendo os valores de um arquivo pequeno, em vez de usar números aleatórios, e fazendo outros cálculos de contagem / min / max mais significativos com o mesmo tipo de código .

Para valores MUITO pequenos do "número de números aleatórios" (x) nas funções relevantes, a vlasolução vence por uma margem enorme. À medida que o tamanho aumenta, a "vitória" diminui e, com tamanho suficiente, a solução vetorial parece ser MAIS eficiente - não estudou muito essa variante, como quando começamos a ter milhares de elementos em um VLA, não é realmente o que eles deveriam fazer ...

E tenho certeza de que alguém me dirá que há alguma maneira de escrever todo esse código com vários modelos e fazê-lo sem executar mais do que o RDTSC e os coutbits em tempo de execução ... Mas não acho que seja realmente o ponto.

Ao executar esta variante específica, recebo uma diferença de cerca de 10% entre o func1(VLA) e 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

Isso é compilado com: g++ -O3 -Wall -Wextra -std=gnu++0x -o vla vla.cpp

Aqui está o código:

#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);
    }
}

Em relação a VLAs versus um vetor

Você considerou que um vetor pode tirar proveito dos próprios VLAs. Sem os VLAs, o vetor precisa especificar certas "escalas" de matrizes, por exemplo, 10, 100, 10000 para armazenamento, para que você aloque uma matriz de 10000 itens para armazenar 101 itens. Com os VLAs, se você redimensionar para 200, o algoritmo pode assumir que você precisará apenas de 200 e pode alocar uma matriz de 200 itens. Ou pode alocar um buffer de dizer n * 1,5.

De qualquer forma, eu argumentaria que, se você souber quantos itens precisará em tempo de execução, um VLA terá melhor desempenho (como demonstrado pelo benchmark de Mats). O que ele demonstrou foi uma iteração simples de duas passagens. Pense em simulações de monte carlo, onde amostras aleatórias são coletadas repetidamente, ou manipulação de imagem (como filtros do Photoshop), onde os cálculos são feitos em cada elemento várias vezes e, possivelmente, cada cálculo em cada elemento envolve a observação de vizinhos.

Esse ponteiro extra salta do vetor para sua matriz interna.

Respondendo à pergunta principal

Mas quando você fala sobre o uso de uma estrutura alocada dinamicamente como um LinkedList, não há comparação. Uma matriz fornece acesso direto usando aritmética de ponteiro para seus elementos. Usando uma lista vinculada, você precisa percorrer os nós para chegar a um elemento específico. Portanto, o VLA ganha as mãos nesse cenário.

De acordo com esta resposta , ele é dependente da arquitetura, mas em alguns casos o acesso à memória na pilha será mais rápido devido à disponibilidade da pilha no cache. Com um grande número de elementos, isso pode ser negado (potencialmente a causa dos retornos decrescentes que Mats viu em seus benchmarks). No entanto, vale a pena notar que os tamanhos de cache estão crescendo significativamente e você potencialmente verá mais esse número crescer de acordo.

O motivo para usar um VLA é principalmente o desempenho. É um erro desconsiderar o exemplo do wiki como tendo apenas uma diferença "irrelevante". Eu posso ver facilmente casos em que exatamente esse código poderia ter uma grande diferença, por exemplo, se essa função fosse chamada em um loop apertado, onde read_valhavia uma função de E / S que retornava muito rapidamente em algum tipo de sistema em que a velocidade era crítica.

De fato, na maioria dos lugares onde os VLAs são usados ​​dessa maneira, eles não substituem as chamadas de heap, mas substituem algo como:

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

A questão de qualquer declaração local é que ela é extremamente rápida. A linha float vals[n]geralmente requer apenas algumas instruções do processador (talvez apenas uma). Simplesmente adiciona o valor nao ponteiro da pilha.

Por outro lado, uma alocação de heap requer caminhar uma estrutura de dados para encontrar uma área livre. O tempo é provavelmente uma ordem de magnitude mais longa, mesmo nos casos mais afortunados. (Ou seja, apenas o ato de colocar nna pilha e chamar mallocé provavelmente de 5 a 10 instruções.) Provavelmente muito pior se houver uma quantidade razoável de dados no heap. Não me surpreenderia ver um caso de malloc100x a 1000x mais lento em um programa real.

Obviamente, você também terá algum impacto no desempenho com a correspondência free, provavelmente semelhante em magnitude à mallocchamada.

Além disso, há o problema da fragmentação da memória. Muitas pequenas alocações tendem a fragmentar a pilha. Amontoados fragmentados desperdiçam memória e aumentam o tempo necessário para alocar memória.