Dostęp do wartości tablicy poprzez arytmetykę wskaźnika a zapisywanie w C

" używanie arytmetyki wskaźników jest ogólnie szybsze niż zapisywanie tablic access "

To powiedziawszy, gdy iteracja elementów w tablicy, pobieranie wskaźnika do pierwszego elementu i zwiększanie go za każdym razem przez pętlę będzie zwykle nieco szybsze niż obliczanie pozycji bieżącego elementu z tablicy zmienna pętli za każdym razem. (Choć jest to niezwykłe, aby miało to znaczenie w prawdziwym życiu. Najpierw zbadaj swój algorytm, przedwczesna optymalizacja jest źródłem wszelkiego zła itp.)

To może być nieco off topic (sorry), ponieważ nie odpowiada na twoje pytanie dotyczące szybkości wykonania, ale powinieneś wziąć pod uwagę, że przedwczesna optymalizacja jest źródłem wszelkiego zła (Knuth). Moim zdaniem, szczególnie kiedy jeszcze (ponownie)uczymy się języka, napisz go tak, jak najłatwiej jest go najpierw przeczytać. Następnie, jeśli twój program działa poprawnie, rozważ optymalizację prędkości. Większość czasu kod będzie wystarczająco szybki i tak.

Mecki ma świetne wytłumaczenie. Z mojego doświadczenia wynika, że jedną z rzeczy, które często mają znaczenie przy indeksowaniu kontra wskaźnikach, jest to, co inny kod znajduje się w pętli. Przykład:

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <iostream>

using namespace std;

typedef int64_t int64;
static int64 nsTime() {
  struct timespec tp;
  clock_gettime(CLOCK_REALTIME, &tp);
  return tp.tv_sec*(int64)1000000000 + tp.tv_nsec;
}

typedef int T;
size_t const N = 1024*1024*128;
T data[N];

int main(int, char**) {
  cout << "starting\n";

  {
    int64 const a = nsTime();
    int sum = 0;
    for (size_t i=0; i<N; i++) {
      sum += data[i];
    }
    int64 const b = nsTime();
    cout << "Simple loop (indexed): " << (b-a)/1e9 << "\n";
  }

  {
    int64 const a = nsTime();
    int sum = 0;
    T *d = data;
    for (size_t i=0; i<N; i++) {
      sum += *d++;
    }
    int64 const b = nsTime();
    cout << "Simple loop (pointer): " << (b-a)/1e9 << "\n";
  }

  {
    int64 const a = nsTime();
    int sum = 0;
    for (size_t i=0; i<N; i++) {
      int a = sum+3;
      int b = 4-sum;
      int c = sum+5;
      sum += data[i] + a - b + c;
    }
    int64 const b = nsTime();
    cout << "Loop that uses more ALUs (indexed): " << (b-a)/1e9 << "\n";
  }

  {
    int64 const a = nsTime();
    int sum = 0;
    T *d = data;
    for (size_t i=0; i<N; i++) {
      int a = sum+3;
      int b = 4-sum;
      int c = sum+5;
      sum += *d++ + a - b + c;
    }
    int64 const b = nsTime();
    cout << "Loop that uses more ALUs (pointer): " << (b-a)/1e9 << "\n";
  }
}

W systemie fast Core 2 (g++ 4.1.2, x64), oto czas:

    Simple loop (indexed): 0.400842
    Simple loop (pointer): 0.380633
    Loop that uses more ALUs (indexed): 0.768398
    Loop that uses more ALUs (pointer): 0.777886

Czasem indeksowanie jest szybsze, czasem arytmetyka wskaźników. Zależy to od tego, jak procesor i kompilator są w stanie rurociągu wykonywania pętli.

Jeśli masz do czynienia z danymi typu array, powiedziałbym, że użycie indeksów dolnych sprawia, że kod jest bardziej czytelny. Na dzisiejszych maszynach (szczególnie w przypadku czegoś prostego) czytelny kod jest ważniejszy.

Teraz jeśli masz do czynienia jawnie z kawałkiem danych, które malloc () ' d i chcesz dostać wskaźnik wewnątrz tych danych, powiedzmy 20 bajtów w nagłówku pliku audio, to myślę, że arytmetyka adresów wyraźniej wyraża to, co próbujesz zrobić.

nie jestem pewien co do kompilatora optymalizacje w tym zakresie, ale nawet jeśli subskrypcja jest wolniejsza, jest wolniejsza tylko o może kilka cykli zegara co najwyżej. To prawie nic, kiedy możesz zyskać o wiele więcej dzięki jasności twojego pociągu myśli.

EDIT: zgodnie z niektórymi innymi odpowiedziami, subskrybowanie jest tylko elementem składniowym i nie ma wpływu na wydajność, jak myślałem. W takim przypadku zdecydowanie wybieraj kontekst, który próbujesz wyrazić za pomocą danych dostępowych wewnątrz wskazywanego bloku za wskaźnik.

Należy pamiętać, że szybkość wykonania jest trudna do przewidzenia, nawet jeśli patrzymy na kod maszynowy z procesorami supersalarowymi i tym podobnymi z

• out of order exection
• pipelining
• przewidywanie gałęzi
• hyperthreading
• ...

To nie tylko instrukcje liczenia maszyn i nie tylko liczenie zegarków. Wydaje się łatwiej po prostu zmierzyć w przypadkach, gdy naprawdę konieczne. Nawet jeśli nie jest niemożliwe obliczenie prawidłowego cyklu licz na dany program (musieliśmy to zrobić na studiach), ale to nie jest zabawne i trudno się dobrze dostać. Uwaga: prawidłowy pomiar jest również trudny w środowiskach wielowątkowych / wielowątkowych.

char p1[ ] = "12345";
char* p2 = "12345";

char *ch = p1[ 3 ]; /* 4 */
ch = *(p2 + 3); /* 4 */

Standard C nie mówi, który jest szybszy. Na obserwowalne zachowanie jest takie samo i to do kompilatora zaimplementować go w dowolny sposób chce. Często nawet nie czyta pamięci.

Ogólnie rzecz biorąc, nie można powiedzieć, który jest "szybszy", chyba że podasz kompilator, wersję, architekturę i opcje kompilacji. Nawet wtedy Optymalizacja będzie zależeć od otaczającego kontekstu.

Więc ogólną radą jest użycie tego, co daje jaśniejszy i prostszy kod. Używanie tablic [i] daje niektórym narzędziom możliwość znalezienia warunków indeksu-out-of-bound, więc jeśli używasz tablic, lepiej je traktować jako takie.

Jeśli jest krytyczna-zajrzyj do assemblera, który generuje kompilator. Ale pamiętaj, że może się to zmienić, gdy zmienisz kod, który go otacza.

Nie, używanie arytmetyki wskaźnika nie jest szybsze i prawdopodobnie wolniejsze, ponieważ kompilator optymalizujący może używać instrukcji takich jak LEA (Load Effective Address) na procesorach Intela lub podobnych na innych procesorach do arytmetyki wskaźnika, która jest szybsza niż add lub add/mul. Ma tę zaletę, że robi kilka rzeczy na raz i nie wpływa na flagi, a także zajmuje jeden cykl do obliczenia. BTW, poniżej jest z podręcznika GCC. Tak więc -Os nie optymalizuje przede wszystkim prędkości.

I również całkowicie zgadzam się z Marko. Najpierw spróbuj napisać czysty, czytelny i wielokrotnego użytku kod, a następnie pomyśl o optymalizacji i użyj narzędzi do profilowania, aby znaleźć wąskie gardło. Przez większość czasu problem z wydajnością jest związany z I/O lub jakimś złym algorytmem lub jakimś błędem, który musisz wytropić. Knuth to człowiek; -)

Przyszło mi do głowy, że co zrobisz z tablicą struktury. Jeśli chcesz zrobić arytmetykę wskaźnika, to zdecydowanie powinieneś to zrobić dla każdego członka struktura. Czy to brzmi jak przesada? Tak, oczywiście to przesada, a także otwiera szerokie drzwi do niejasnych błędów.

-Os optymalizacja pod kątem rozmiaru. Os włącza wszystkie optymalizacje O2, które zazwyczaj nie zwiększają rozmiaru kodu. Wykonuje również dalsze optymalizacje mające na celu zmniejszenie rozmiaru kodu.

To nieprawda. Jest dokładnie tak szybki jak w przypadku operatorów indeksów dolnych. W Objective-C można używać tablic, jak w C i w stylu obiektowym, gdzie styl obiektowy jest o wiele wolniejszy, ponieważ wykonuje pewne operacje w każdym wywołaniu ze względu na dynamiczny charakter wywołania.

Jest mało prawdopodobne, że będzie jakaś różnica w prędkości.

Używanie operatora tablicy [] jest prawdopodobnie preferowane, ponieważ w C++ można używać tej samej składni z innymi kontenerami (np. vector).

Pracowałem nad optymalizacją C++/assembly dla kilku tytułów AAA przez 10 lat i mogę powiedzieć, że na poszczególnych platformach/kompilatorze pracowałem nad arytmetyka wskaźników zrobiła całkiem wymierną różnicę.

Jako przykład dla spojrzenia na sytuację, byłem w stanie zrobić naprawdę ciasną pętlę w naszym generatorze cząstek o 40% szybciej, zastępując cały dostęp do tablicy arytmetyką wskaźników do całkowitego niedowierzania moim współpracownikom. Słyszałem o tym od jednego z moich nauczyciele jako dobry trick z powrotem w dzień, ale założyłem, że nie będzie sposobu, aby to zrobić różnicę z kompilatorów / CPU mamy dzisiaj. Myliłem się;)

Należy podkreślić, że wiele procesorów konsoli ARM nie posiada wszystkich uroczych cech nowoczesnychCISC procesorów i kompilatora było czasami trochę chwiejnych.