Czy wbudowany język asemblera jest wolniejszy niż natywny kod C ++?

Próbowałem porównać wydajność wbudowanego języka asemblerowego i kodu C ++, więc napisałem funkcję, która dodaje dwie tablice o wielkości 2000 na 100000 razy. Oto kod:

#define TIMES 100000
void calcuC(int *x,int *y,int length)
{
    for(int i = 0; i < TIMES; i++)
    {
        for(int j = 0; j < length; j++)
            x[j] += y[j];
    }
}


void calcuAsm(int *x,int *y,int lengthOfArray)
{
    __asm
    {
        mov edi,TIMES
        start:
        mov esi,0
        mov ecx,lengthOfArray
        label:
        mov edx,x
        push edx
        mov eax,DWORD PTR [edx + esi*4]
        mov edx,y
        mov ebx,DWORD PTR [edx + esi*4]
        add eax,ebx
        pop edx
        mov [edx + esi*4],eax
        inc esi
        loop label
        dec edi
        cmp edi,0
        jnz start
    };
}

Oto main():

int main() {
    bool errorOccured = false;
    setbuf(stdout,NULL);
    int *xC,*xAsm,*yC,*yAsm;
    xC = new int[2000];
    xAsm = new int[2000];
    yC = new int[2000];
    yAsm = new int[2000];
    for(int i = 0; i < 2000; i++)
    {
        xC[i] = 0;
        xAsm[i] = 0;
        yC[i] = i;
        yAsm[i] = i;
    }
    time_t start = clock();
    calcuC(xC,yC,2000);

    //    calcuAsm(xAsm,yAsm,2000);
    //    for(int i = 0; i < 2000; i++)
    //    {
    //        if(xC[i] != xAsm[i])
    //        {
    //            cout<<"xC["<<i<<"]="<<xC[i]<<" "<<"xAsm["<<i<<"]="<<xAsm[i]<<endl;
    //            errorOccured = true;
    //            break;
    //        }
    //    }
    //    if(errorOccured)
    //        cout<<"Error occurs!"<<endl;
    //    else
    //        cout<<"Works fine!"<<endl;

    time_t end = clock();

    //    cout<<"time = "<<(float)(end - start) / CLOCKS_PER_SEC<<"\n";

    cout<<"time = "<<end - start<<endl;
    return 0;
}

Następnie uruchamiam program pięć razy, aby uzyskać cykle procesora, które można uznać za czas. Za każdym razem wywołuję tylko jedną z wyżej wymienionych funkcji.

I oto rezultat.

Funkcja wersji montażu:

Debug   Release
---------------
732        668
733        680
659        672
667        675
684        694
Average:   677

Funkcja wersji C ++:

Debug     Release
-----------------
1068      168
 999      166
1072      231
1002      166
1114      183
Average:  182

Kod C ++ w trybie wydania jest prawie 3,7 razy szybszy niż kod asemblera. Czemu?

Wydaje mi się, że kod asemblera, który napisałem, nie jest tak skuteczny, jak kod wygenerowany przez GCC. Dla zwykłego programisty takiego jak ja trudno jest napisać kod szybciej niż jego przeciwnik generowany przez kompilator. Czy to oznacza, że ​​nie powinienem ufać wydajności języka asemblera napisanego własnymi rękami, skupić się na C ++ i zapomnieć o języku asemblera?

Tak, większość razy.

Przede wszystkim zaczynasz od błędnego założenia, że ​​język niskiego poziomu (w tym przypadku asembler) zawsze będzie generował szybszy kod niż język wysokiego poziomu (w tym przypadku C ++ i C). To nie prawda. Czy kod C jest zawsze szybszy niż kod Java? Nie, ponieważ istnieje inna zmienna: programista. Sposób pisania kodu i znajomość szczegółów architektury mają duży wpływ na wydajność (tak jak w tym przypadku).

Można zawsze produkować przykład, w którym ręcznie kod montaż jest lepszy niż kod skompilowany, ale zazwyczaj jest to fikcyjny przykład lub pojedynczy rutyna nie jest prawdziwy program 500.000 linii kodu C ++). Myślę, że kompilatory wygenerują lepszy kod asemblera 95% razy, a czasami, tylko w niektórych rzadkich przypadkach, może być konieczne napisanie kodu asemblera dla kilku, krótkich, bardzo używanych , krytycznych pod względem wydajności procedur lub gdy będziesz musiał uzyskać dostęp do funkcji swojego ulubionego języka wysokiego poziomu nie ujawnia. Czy chcesz dotknąć tej złożoności? Przeczytaj tę niesamowitą odpowiedź tutaj na SO.

Dlaczego to

Przede wszystkim dlatego, że kompilatory mogą przeprowadzać optymalizacje, których nawet nie jesteśmy w stanie sobie wyobrazić (zobacz tę krótką listę ), i zrobią to w ciągu kilku sekund (kiedy możemy potrzebować dni ).

Kiedy kodujesz w asemblerze, musisz wykonywać dobrze zdefiniowane funkcje z dobrze zdefiniowanym interfejsem wywołania. Mogą jednak brać pod uwagę optymalizację całego programu i optymalizację między procedurami, takie jak przydział rejestrów , stała propagacja , eliminacja wspólnego podwyrażenia , planowanie instrukcji i inne złożone, nieoczywiste optymalizacje ( na przykład model Polytope ). W architekturze RISC faceci przestali się tym martwić wiele lat temu (na przykład planowanie instrukcji jest bardzo trudne do dostrojenia ręcznie ), a nowoczesne procesory CISC mają bardzo długie potoki też.

W przypadku niektórych złożonych mikrokontrolerów nawet biblioteki systemowe są zapisywane w C zamiast w asemblerze, ponieważ ich kompilatory wytwarzają lepszy (i łatwy w utrzymaniu) kod końcowy.

Kompilatory czasami mogą automatycznie korzystać z niektórych instrukcji MMX / SIMDx , a jeśli ich nie użyjesz, po prostu nie możesz ich porównać (inne odpowiedzi bardzo dobrze sprawdzały kod asemblera). Tylko dla pętli jest to krótka lista optymalizacji pętli tego, co jest zwykle sprawdzane przez kompilator (czy myślisz, że możesz to zrobić sam, kiedy zostanie ustalony harmonogram dla programu w języku C #?) Jeśli napiszesz coś w asemblerze, ja myślę, że musisz rozważyć przynajmniej kilka prostych optymalizacji . Przykładem szkolnych tablic jest rozwinięcie cyklu (jego rozmiar jest znany w czasie kompilacji). Zrób to i ponownie uruchom test.

W dzisiejszych czasach naprawdę rzadko trzeba używać języka asemblera z innego powodu: mnogości różnych procesorów . Czy chcesz je wszystkie wspierać? Każda z nich ma określoną mikroarchitekturę i niektóre określone zestawy instrukcji . Mają różną liczbę jednostek funkcjonalnych i instrukcje dotyczące montażu powinny być ustawione tak, aby były zajęte . Jeśli piszesz w C, możesz użyć PGO, ale podczas montażu będziesz potrzebować dużej wiedzy na temat tej konkretnej architektury ( i ponownie przemyśleć i powtórzyć wszystko dla innej architektury ). W przypadku małych zadań kompilator zwykle robi to lepiej, a w przypadku złożonych zadań zwykle praca nie jest zwracana (ikompilator i tak może działać lepiej ).

Jeśli usiądziesz i spojrzysz na kod, prawdopodobnie zobaczysz, że zyskasz więcej na przeprojektowaniu algorytmu niż na tłumaczeniu na asemblerze (przeczytaj ten świetny post tutaj na SO ), istnieją optymalizacje na wysokim poziomie (i wskazówki do kompilatora), możesz skutecznie zastosować, zanim będziesz musiał skorzystać z języka asemblera. Prawdopodobnie warto wspomnieć, że często stosując wewnętrzne funkcje, uzyskasz wzrost wydajności, którego szukasz, a kompilator nadal będzie w stanie przeprowadzić większość swoich optymalizacji.

Wszystko to powiedziawszy, nawet jeśli możesz stworzyć kod montażu 5 ~ 10 razy szybszy, powinieneś zapytać swoich klientów, czy wolą zapłacić tydzień czasu lub kupić procesor szybszy o 50 $ . Ekstremalna optymalizacja częściej (a zwłaszcza w aplikacjach LOB) po prostu nie jest wymagana od większości z nas.

Twój kod zestawu jest nieoptymalny i może zostać ulepszony:

• Pchasz i pchasz rejestr ( EDX ) w swojej wewnętrznej pętli. Powinno to zostać usunięte z pętli.
• Przeładowujesz wskaźniki tablicy w każdej iteracji pętli. To powinno wyjść z pętli.
• Korzystasz z loopinstrukcji, która jest znana jako powolna na większości współczesnych procesorów (być może w wyniku użycia starożytnej książki montażowej *)
• Nie korzystasz z ręcznego rozwijania pętli.
• Nie korzystasz z dostępnych instrukcji SIMD .

Tak więc, chyba że znacznie poprawisz swoje umiejętności dotyczące asemblera, nie ma sensu pisać kodu asemblera dla wydajności.

* Oczywiście, że nie wiem, czy naprawdę otrzymałeś loopinstrukcję ze starożytnej księgi zgromadzeń. Ale prawie nigdy nie widzisz go w kodzie świata rzeczywistego, ponieważ każdy dostępny kompilator jest wystarczająco inteligentny, aby go nie emitować loop, widzisz go tylko w złych i nieaktualnych książkach IMHO.

Nawet przed zagłębieniem się w asemblerze istnieją transformacje kodu, które istnieją na wyższym poziomie.

static int const TIMES = 100000;

void calcuC(int *x, int *y, int length) {
  for (int i = 0; i < TIMES; i++) {
    for (int j = 0; j < length; j++) {
      x[j] += y[j];
    }
  }
}

można przekształcić w obrót pętli :

static int const TIMES = 100000;

void calcuC(int *x, int *y, int length) {
    for (int j = 0; j < length; ++j) {
      for (int i = 0; i < TIMES; ++i) {
        x[j] += y[j];
      }
    }
}

co jest znacznie lepsze, jeśli chodzi o lokalizację pamięci.

Można to dalej optymalizować, wykonywanie a += bX razy jest równoznaczne z robieniem, a += X * bwięc otrzymujemy:

static int const TIMES = 100000;

void calcuC(int *x, int *y, int length) {
    for (int j = 0; j < length; ++j) {
      x[j] += TIMES * y[j];
    }
}

wydaje się jednak, że mój ulubiony optymalizator (LLVM) nie wykonuje tej transformacji.

[edytuj] Odkryłem, że transformacja jest wykonywana, jeśli mamy restrictkwalifikator do xi y. Rzeczywiście bez tego ograniczenia x[j]i y[j]może być alias do tej samej lokalizacji, co powoduje, że ta transformacja jest błędna. [koniec edycji]

W każdym razie, to jest, jak sądzę, zoptymalizowaną wersję C. Już jest o wiele prostsze. W oparciu o to, oto mój crack w ASM (pozwalam Clangowi go wygenerować, jestem w tym bezużyteczny):

calcuAsm:                               # @calcuAsm
.Ltmp0:
    .cfi_startproc
# BB#0:
    testl   %edx, %edx
    jle .LBB0_2
    .align  16, 0x90
.LBB0_1:                                # %.lr.ph
                                        # =>This Inner Loop Header: Depth=1
    imull   $100000, (%rsi), %eax   # imm = 0x186A0
    addl    %eax, (%rdi)
    addq    $4, %rsi
    addq    $4, %rdi
    decl    %edx
    jne .LBB0_1
.LBB0_2:                                # %._crit_edge
    ret
.Ltmp1:
    .size   calcuAsm, .Ltmp1-calcuAsm
.Ltmp2:
    .cfi_endproc

Obawiam się, że nie rozumiem, skąd się biorą te instrukcje, jednak zawsze możesz się dobrze bawić i spróbować zobaczyć, jak się to porównuje ... ale nadal używałbym zoptymalizowanej wersji C, a nie montażu, w kodzie, dużo bardziej przenośny.

Krótka odpowiedź: tak.

Długa odpowiedź: tak, chyba że naprawdę wiesz, co robisz i masz ku temu powód.

Naprawiłem mój kod asm:

  __asm
{   
    mov ebx,TIMES
 start:
    mov ecx,lengthOfArray
    mov esi,x
    shr ecx,1
    mov edi,y
label:
    movq mm0,QWORD PTR[esi]
    paddd mm0,QWORD PTR[edi]
    add edi,8
    movq QWORD PTR[esi],mm0
    add esi,8
    dec ecx 
    jnz label
    dec ebx
    jnz start
};

Wyniki dla wersji Release:

 Function of assembly version: 81
 Function of C++ version: 161

Kod zestawu w trybie wydania jest prawie 2 razy szybszy niż C ++.

Czy to oznacza, że ​​nie powinienem ufać działaniu języka asemblera napisanego własnymi rękami

Tak, dokładnie to oznacza i dotyczy to każdego języka. Jeśli nie wiesz, jak napisać efektywny kod w języku X, nie powinieneś ufać swojej umiejętności pisania wydajnego kodu w X. A zatem, jeśli chcesz wydajnego kodu, powinieneś użyć innego języka.

Zgromadzenie jest na to szczególnie wrażliwe, ponieważ cóż, to, co widzisz, dostajesz. Pisz szczegółowe instrukcje, które procesor ma wykonać. W przypadku języków wysokiego poziomu w betweeen znajduje się kompilator, który może przekształcić kod i usunąć wiele nieefektywności. Dzięki montażowi jesteś sam.

Jedynym powodem używania obecnie języka asemblera jest użycie niektórych funkcji niedostępnych dla tego języka.

Dotyczy to:

• Programowanie jądra, które musi mieć dostęp do niektórych funkcji sprzętowych, takich jak MMU
• Programowanie o wysokiej wydajności, które wykorzystuje bardzo specyficzne instrukcje wektorowe lub multimedialne nieobsługiwane przez kompilator.

Ale obecne kompilatory są dość sprytne, mogą nawet zastąpić dwie oddzielne instrukcje, takie jak d = a / b; r = a % b;pojedyncza instrukcja, która oblicza podział i resztę za jednym razem, jeśli jest dostępna, nawet jeśli C nie ma takiego operatora.

To prawda, że ​​nowoczesny kompilator wykonuje niesamowitą pracę w zakresie optymalizacji kodu, ale nadal zachęcam do dalszego uczenia się asemblera.

Po pierwsze, wyraźnie Cię to nie przeraża , to świetny, świetny plus, dalej - jesteś na dobrej drodze, profilując się, aby zweryfikować lub odrzucić założenia dotyczące prędkości , prosisz o wkład doświadczonych ludzi , a ty mieć największe narzędzie optymalizujące znane ludzkości: mózg .

Wraz ze wzrostem doświadczenia dowiesz się, kiedy i gdzie go używać (zwykle najściślejsze, najbardziej wewnętrzne pętle w kodzie, po głębokiej optymalizacji na poziomie algorytmu).

Aby uzyskać inspirację, polecam przejrzenie artykułów Michaela Abrasha (jeśli nie otrzymałeś od niego wiadomości, jest guru optymalizacji; nawet współpracował z Johnem Carmackiem przy optymalizacji renderera oprogramowania Quake!)

„nie ma czegoś takiego jak najszybszy kod” - Michael Abrash

Zmieniłem kod asm:

 __asm
{ 
    mov ebx,TIMES
 start:
    mov ecx,lengthOfArray
    mov esi,x
    shr ecx,2
    mov edi,y
label:
    mov eax,DWORD PTR [esi]
    add eax,DWORD PTR [edi]
    add edi,4   
    dec ecx 
    mov DWORD PTR [esi],eax
    add esi,4
    test ecx,ecx
    jnz label
    dec ebx
    test ebx,ebx
    jnz start
};

Wyniki dla wersji Release:

 Function of assembly version: 41
 Function of C++ version: 161

Kod zestawu w trybie wydania jest prawie 4 razy szybszy niż C ++. IMHo, szybkość kodu asemblera zależy od Programmera

to bardzo interesujący temat!
Zmieniłem MMX przez SSE w kodzie Sashy
Oto moje wyniki:

Function of C++ version:      315
Function of assembly(simply): 312
Function of assembly  (MMX):  136
Function of assembly  (SSE):  62

Kod asemblera z SSE jest 5 razy szybszy niż C ++

Większość kompilatorów języków wysokiego poziomu jest bardzo zoptymalizowana i wie, co robi. Możesz spróbować zrzucić kod dezasemblujący i porównać go z rodzimym zestawem. Wierzę, że zobaczysz kilka fajnych sztuczek, których używa twój kompilator.

Na przykład, nawet jeśli nie jestem pewien, czy to prawda :)

Robić:

mov eax,0

kosztuje więcej cykli niż

xor eax,eax

który robi to samo.

Kompilator zna wszystkie te sztuczki i używa ich.

Kompilator cię pokonał. Spróbuję, ale nie dam żadnych gwarancji. Będę zakładać, że „mnożenie” za czasów jest to, by to bardziej odpowiednie testy wydajności, które yi xsą 16-wyrównane, i że lengthjest niezerowe wielokrotnością 4. To chyba wszystko prawda i tak.

  mov ecx,length
  lea esi,[y+4*ecx]
  lea edi,[x+4*ecx]
  neg ecx
loop:
  movdqa xmm0,[esi+4*ecx]
  paddd xmm0,[edi+4*ecx]
  movdqa [edi+4*ecx],xmm0
  add ecx,4
  jnz loop

Jak powiedziałem, nie udzielam żadnych gwarancji. Ale będę zaskoczony, jeśli można to zrobić znacznie szybciej - wąskim gardłem jest tutaj przepustowość pamięci, nawet jeśli wszystko jest hitem L1.

Ślepo realizacji dokładny samego algorytmu, dyspozycję instrukcji, w montaż jest gwarantowany być wolniejsze niż to, co kompilator może zrobić.

Dzieje się tak, ponieważ nawet najmniejsza optymalizacja, jaką wykonuje kompilator, jest lepsza niż sztywny kod bez żadnej optymalizacji.

Oczywiście możliwe jest pokonanie kompilatora, zwłaszcza jeśli jest to niewielka, zlokalizowana część kodu, musiałem to zrobić sam, aby uzyskać ok. 4x przyspieszenia, ale w tym przypadku musimy mocno polegać na dobrej znajomości sprzętu i licznych pozornie intuicyjnych sztuczkach.

Jako kompilator zamieniłbym pętlę o stałym rozmiarze na wiele zadań wykonawczych.

int a = 10;
for (int i = 0; i < 3; i += 1) {
    a = a + i;
}

będzie produkować

int a = 10;
a = a + 0;
a = a + 1;
a = a + 2;

i ostatecznie będzie wiedział, że „a = a + 0;” jest bezużyteczny, więc usunie tę linię. Mam nadzieję, że coś w twojej głowie chce teraz dołączyć pewne opcje optymalizacji jako komentarz. Wszystkie te bardzo skuteczne optymalizacje przyspieszą skompilowany język.

Dokładnie to znaczy. Pozostaw mikrooptymalizacje kompilatorowi.

Podoba mi się ten przykład, ponieważ pokazuje ważną lekcję na temat kodu niskiego poziomu. Tak, można napisać, że montaż jest tak szybki jak kod C. Jest to tautologicznie prawdziwe, ale niekoniecznie nic nie znaczy . Najwyraźniej ktoś może, w przeciwnym razie asembler nie poznałby odpowiednich optymalizacji.

Podobnie obowiązuje ta sama zasada, gdy wchodzisz w górę hierarchii abstrakcji języka. Tak, można napisać parser w C, który jest tak szybko, jak szybki i brzydka skrypt Perl, a wiele osób. Ale to nie znaczy, że ponieważ użyłeś C, twój kod będzie szybki. W wielu przypadkach języki wyższego poziomu wykonują optymalizacje, których być może nawet nie wziąłeś pod uwagę.

W wielu przypadkach optymalny sposób wykonania jakiegoś zadania może zależeć od kontekstu, w którym zadanie jest wykonywane. Jeśli procedura jest napisana w języku asemblera, generalnie nie będzie możliwe zmienianie sekwencji instrukcji w zależności od kontekstu. Jako prosty przykład rozważ następującą prostą metodę:

inline void set_port_high(void)
{
  (*((volatile unsigned char*)0x40001204) = 0xFF);
}

Kompilator dla 32-bitowego kodu ARM, biorąc pod uwagę powyższe, prawdopodobnie renderowałby go jako:

ldr  r0,=0x40001204
mov  r1,#0
strb r1,[r0]
[a fourth word somewhere holding the constant 0x40001204]

a może

ldr  r0,=0x40001000  ; Some assemblers like to round pointer loads to multiples of 4096
mov  r1,#0
strb r1,[r0+0x204]
[a fourth word somewhere holding the constant 0x40001000]

Można to nieco zoptymalizować w ręcznie składanym kodzie, ponieważ:

ldr  r0,=0x400011FF
strb r0,[r0+5]
[a third word somewhere holding the constant 0x400011FF]

lub

mvn  r0,#0xC0       ; Load with 0x3FFFFFFF
add  r0,r0,#0x1200  ; Add 0x1200, yielding 0x400011FF
strb r0,[r0+5]

Oba ręcznie zmontowane podejścia wymagałyby 12 bajtów przestrzeni kodu zamiast 16; ten ostatni zastąpiłby „obciążenie” „dodaniem”, co w przypadku ARM7-TDMI wykona dwa cykle szybciej. Gdyby kod miał być wykonywany w kontekście, w którym r0 nie wiedział / nie przejmował się, wersje językowe asemblera byłyby nieco lepsze niż wersja skompilowana. Z drugiej strony załóżmy, że kompilator wiedział, że jakiś rejestr [np. R5] będzie przechowywał wartość mieszczącą się w granicach 2047 bajtów od pożądanego adresu 0x40001204 [np. 0x40001000], a ponadto wiedział, że idzie inny rejestr [np. R7] do przechowywania wartości, której niskie bity to 0xFF. W takim przypadku kompilator może zoptymalizować wersję C kodu, aby po prostu:

strb r7,[r5+0x204]

Znacznie krótszy i szybszy niż nawet ręcznie zoptymalizowany kod zestawu. Ponadto załóżmy, że set_port_high wystąpił w kontekście:

int temp = function1();
set_port_high();
function2(temp); // Assume temp is not used after this

W ogóle nie jest to niemożliwe przy kodowaniu systemu wbudowanego. Jeśli set_port_highjest zapisany w kodzie asemblera, kompilator musiałby przenieść r0 (który przechowuje wartość zwracaną function1) gdzie indziej przed wywołaniem kodu asemblera, a następnie przenieść tę wartość z powrotem do r0 (ponieważ function2spodziewa się swojego pierwszego parametru w r0), więc „zoptymalizowany” kod zestawu wymagałby pięciu instrukcji. Nawet jeśli kompilator nie wiedział o żadnym rejestrze zawierającym adres lub wartość do przechowywania, jego czteroinstrukcyjna wersja (którą mógłby przystosować do korzystania z dowolnych dostępnych rejestrów - niekoniecznie r0 i r1) pobiłaby „zoptymalizowany” zestaw wersja językowa. Gdyby kompilator miał niezbędny adres i dane w r5 i r7, jak opisano wcześniej, function1nie zmieniłby tych rejestrów, a zatem mógłby zastąpićset_port_highz pojedynczą strbinstrukcją - cztery instrukcje mniejsze i szybsze niż kod asemblera „zoptymalizowany ręcznie”.

Zauważ, że ręcznie zoptymalizowany kod asemblera często przewyższa kompilator w przypadkach, gdy programiści znają dokładny przebieg programu, ale kompilatory świecą w przypadkach, gdy kawałek kodu jest napisany przed poznaniem jego kontekstu lub gdy jeden fragment kodu źródłowego może być wywoływany z wielu kontekstów [jeśli set_port_highjest używany w pięćdziesięciu różnych miejscach kodu, kompilator może niezależnie dla każdego z nich zdecydować, jak najlepiej go rozwinąć].

Zasadniczo sugerowałbym, że język asemblera jest w stanie zapewnić największą poprawę wydajności w tych przypadkach, w których do każdego fragmentu kodu można podejść z bardzo ograniczonej liczby kontekstów, i może być szkodliwy dla wydajności w miejscach, w których fragment do kodu można podchodzić z wielu różnych kontekstów. Co ciekawe (i dogodnie) przypadki, w których montaż jest najbardziej korzystny dla wydajności, to często przypadki, w których kod jest najbardziej prosty i łatwy do odczytania. Miejsca, w których kod języka asemblerowego zamieniłby się w lepki bałagan, to często te, w których pisanie w asemblerze zapewniałoby najmniejszą korzyść w zakresie wydajności.

[Drobna uwaga: jest kilka miejsc, w których można użyć kodu asemblera, aby wywołać hiperoptymalizowany lepki bałagan; na przykład jeden kawałek kodu, który zrobiłem dla ARM, potrzebował pobrać słowo z pamięci RAM i wykonać jedną z około dwunastu procedur na podstawie sześciu górnych bitów wartości (wiele wartości odwzorowanych na tę samą procedurę). Myślę, że zoptymalizowałem ten kod do czegoś takiego:

ldrh  r0,[r1],#2! ; Fetch with post-increment
ldrb  r1,[r8,r0 asr #10]
sub   pc,r8,r1,asl #2

Rejestr r8 zawsze zawierał adres głównej tablicy wysyłkowej (w pętli, w której kod spędza 98% swojego czasu, nic nigdy nie wykorzystywało go do żadnych innych celów); wszystkie 64 wpisy odnosiły się do adresów w 256 bajtach poprzedzających. Ponieważ pętla pierwotna miała w większości przypadków sztywny limit czasu wykonania wynoszący około 60 cykli, pobieranie i wysyłanie w dziewięciu cyklach było bardzo istotne dla osiągnięcia tego celu. Użycie tabeli 256 32-bitowych adresów byłoby o jeden cykl szybsze, ale pochłonęłoby 1 KB bardzo cennej pamięci RAM [flash dodałby więcej niż jeden stan oczekiwania]. Użycie 64 32-bitowych adresów wymagałoby dodania instrukcji maskowania niektórych bitów z pobranego słowa i nadal pochłonąłoby 192 bajty więcej niż tabela, której faktycznie użyłem. Korzystanie z tabeli 8-bitowych przesunięć dało bardzo kompaktowy i szybki kod, ale nie jest to coś, czego oczekiwałbym od kompilatora; Nie spodziewałbym się również, że kompilator poświęci rejestrowi „pełny czas” na przechowywanie adresu tabeli.

Powyższy kod został zaprojektowany do działania jako samodzielny system; może okresowo wywoływać kod C, ale tylko w pewnych momentach, gdy sprzęt, z którym się komunikuje, może być bezpiecznie wprowadzony w stan „bezczynności” na dwa mniej więcej co milisekundowe interwały co 16 ms.

W ostatnim czasie wszystkie optymalizacje prędkości, które przeprowadziłem, zastępowały wolny kod uszkodzonego mózgu tylko rozsądnym kodem. Ale ponieważ szybkość była naprawdę krytyczna i włożyłem duży wysiłek w szybkie zrobienie czegoś, w rezultacie zawsze był to proces iteracyjny, w którym każda iteracja dawała więcej wglądu w problem, znajdując sposoby rozwiązania problemu za pomocą mniejszej liczby operacji. Ostateczna prędkość zawsze zależała od tego, ile wglądu w problem. Jeśli na jakimkolwiek etapie użyłem kodu asemblera lub kodu C, który został nadmiernie zoptymalizowany, ucierpiałby proces znalezienia lepszego rozwiązania, a wynik końcowy byłby wolniejszy.

C ++ jest szybszy, chyba że używasz języka asemblera z głębszą znajomością we właściwy sposób.

Kiedy koduję w ASM, reorganizuję instrukcje ręcznie, aby procesor mógł wykonywać więcej z nich równolegle, o ile jest to logicznie możliwe. Ledwo używam pamięci RAM, gdy koduję w ASM, na przykład: w ASM może być ponad 20000 linii kodu i nigdy nie użyłem push / pop.

Możesz potencjalnie przeskoczyć w środku kodu operacji, aby samodzielnie zmodyfikować kod i zachowanie bez możliwej kary za samododyfikację kodu. Dostęp do rejestrów zajmuje 1 tik (czasem zajmuje .25 tików) procesora. Dostęp do pamięci RAM może zająć setki.

W mojej ostatniej przygodzie ASM nigdy nie użyłem pamięci RAM do przechowywania zmiennej (dla tysięcy linii ASM). ASM może być potencjalnie niewyobrażalnie szybszy niż C ++. Ale zależy to od wielu zmiennych czynników, takich jak:

1. I was writing my apps to run on the bare metal.
2. I was writing my own boot loader that was starting my programs in ASM so there was no OS management in the middle.

Uczę się teraz C # i C ++, ponieważ zdałem sobie sprawę, że produktywność ma znaczenie !! W wolnym czasie możesz spróbować robić najszybsze możliwe programy, używając czystego ASM. Ale aby coś stworzyć, użyj jakiegoś wysokiego poziomu języka.

Na przykład ostatni program, który kodowałem, używał JS i GLSL i nigdy nie zauważyłem żadnego problemu z wydajnością, nawet mówiąc o JS, który jest powolny. Wynika to z faktu, że sama koncepcja programowania GPU dla 3D sprawia, że ​​szybkość języka, który wysyła polecenia do GPU, jest prawie nieistotna.

Szybkość samego asemblera na gołym metalu jest niezaprzeczalna. Czy może być jeszcze wolniej w C ++? - Być może dlatego, że piszesz kod asemblera za pomocą kompilatora, który nie używa asemblera na początek.

Moją osobistą radą jest, aby nigdy nie pisać kodu asemblera, jeśli możesz go uniknąć, mimo że uwielbiam asembler.

Wszystkie odpowiedzi tutaj wydają się wykluczać jeden aspekt: ​​czasami nie piszemy kodu, aby osiągnąć konkretny cel, ale dla samej zabawy . Zainwestowanie czasu w to może być nieopłacalne, ale prawdopodobnie nie ma większej satysfakcji niż pokonanie najszybszego fragmentu kodu zoptymalizowanego pod kątem kompilatora za pomocą ręcznie walcowanej alternatywy asm.

Kompilator c ++, po optymalizacji na poziomie organizacyjnym, wytworzyłby kod, który wykorzystywałby wbudowane funkcje docelowej jednostki centralnej. HLL nigdy nie prześcignie ani nie prześcignie asemblera z kilku powodów; 1.) HLL zostanie skompilowany i wyprowadzony z kodem Accessora, sprawdzeniem granic i ewentualnie wbudowanym wyrzucaniem elementów bezużytecznych (wcześniej adresując zakres w manieryzmie OOP), wszystkie wymagające cykli (przerzutów i klap). HLL wykonuje obecnie doskonałą robotę (w tym nowsze C ++ i inne, takie jak GO), ale jeśli przewyższają one asembler (a mianowicie twój kod), musisz skonsultować dokumentację procesora - porównania z niechlujnym kodem są z pewnością niejednoznaczne, a skompilowane języki, takie jak asembler, wszystkie rozwiązują aż do kodu operacyjnego HLL streszcza szczegóły i nie eliminuje ich, w przeciwnym razie aplikacja nie uruchomi się, nawet jeśli zostanie rozpoznana przez system operacyjny hosta.

Większość kodu asemblera (przede wszystkim obiektów) jest wyprowadzana jako „bezgłowa” w celu włączenia do innych formatów wykonywalnych, wymagając znacznie mniej przetwarzania, dlatego będzie znacznie szybszy, ale o wiele bardziej niezabezpieczony; jeśli asembler generuje plik wykonywalny (NAsm, YAsm; itp.), to będzie on nadal działał szybciej, aż do pełnego dopasowania kodu HLL pod względem funkcjonalności, wówczas wyniki mogą być dokładnie zważone.

Wywołanie obiektu kodu opartego na asemblerze z HLL w dowolnym formacie z natury spowoduje dodatkowy narzut przetwarzania, a także wywołania przestrzeni pamięci przy użyciu globalnie przydzielonej pamięci dla zmiennych / stałych typów danych (dotyczy to zarówno LLL, jak i HLL). Pamiętaj, że ostatecznym wyjściem jest użycie procesora jako interfejsu API i abi względem sprzętu (opcode), a oba asemblery i „kompilatory HLL” są zasadniczo / zasadniczo identyczne, a jedynym prawdziwym wyjątkiem jest czytelność (gramatyka).

Witaj, światowa aplikacja konsolowa w asemblerze używającym FAsm ma 1,5 KB (aw Windowsie jest jeszcze mniejsza w FreeBSD i Linux) i przewyższa wszystko, co GCC może wyrzucić w najlepszym dniu; Powodem jest niejawne wypełnienie zerami, sprawdzanie poprawności dostępu i sprawdzanie granic, aby wymienić tylko kilka. Prawdziwym celem są czyste biblioteki HLL i optymalizowany kompilator, który celuje w procesor w „hardkorowy” sposób i większość robi to obecnie (w końcu). GCC nie jest lepsze niż YAsm - chodzi o praktyki kodowania i zrozumienie dewelopera, o których mowa, a „optymalizacja” następuje po eksploracji nowicjuszy oraz przejściowym szkoleniu i doświadczeniu.

Kompilatory muszą łączyć i składać dane wyjściowe w tym samym kodzie operacyjnym co asembler, ponieważ te kody to wszystko, co CPU będzie wyjątkiem (CISC lub RISC [PIC też]). YAsm zoptymalizował i wyczyścił wiele na wczesnym NAsm, ostatecznie przyspieszając wszystkie dane wyjściowe z tego asemblera, ale nawet wtedy YAsm, podobnie jak NAsm, tworzy pliki wykonywalne z zewnętrznymi zależnościami atakującymi biblioteki systemu operacyjnego w imieniu programisty, więc przebieg może się różnić. Na zakończenie C ++ jest w punkcie, który jest niesamowity i znacznie bezpieczniejszy niż asembler dla ponad 80 procent, szczególnie w sektorze komercyjnym ...

Montaż może być szybszy, jeśli kompilator generuje dużo kodu obsługi OO .

Edytować:

Do downvoters: OP napisał: „czy powinienem ... skupić się na C ++ i zapomnieć o asemblerze?” i podtrzymuję moją odpowiedź. Zawsze musisz mieć oko na kod generowany przez OO, szczególnie podczas korzystania z metod. Nie zapominanie o języku asemblera oznacza, że ​​będziesz okresowo sprawdzać zestaw, który generuje Twój kod OO, co moim zdaniem jest niezbędne do pisania dobrze działającego oprogramowania.

W rzeczywistości dotyczy to całego kompilowalnego kodu, nie tylko OO.