Assembler vs GNU standard lib

Huvikseni yritin disassmbloida gligc-2.28:n strlen rutiinia ja sain puristettua
ulos alla olevan intel-syntaxisen ja NASM:lla käännettävän (nasm -felf64 ...) koodin siitä.
Sitten testasin tätä (nasm'lla tuotettua) koodia linkitettynä staattisesti sitä kutsuvaan
C-koodiin ja vertasin tulosta standard C strlen kutsuihin....

; Tämä ON glibc strlen vieläpä hieman optimoituna,
; eli ei stack-framea ja poistettu kaksi if lausetta.

global as_strlen
section .text

as_strlen:
mov r9, rdi
test dil, 7
je addr_c
cmp BYTE [rdi], 0
jne addr_b
jmp addr_o
addr_a: cmp BYTE [rdi], 0
je addr_g
addr_b: inc rdi
test dil, 7
jne addr_a
addr_c: mov r8, 0xfefefefefefefeff
mov rsi, 0x8080808080808080
jmp addr_f
addr_d: cmp BYTE [rdx-7], 0
je addr_i
cmp BYTE [rdx-6], 0
je addr_j
cmp BYTE [rdx-5], 0
je addr_k
cmp BYTE [rdx-4], 0
je addr_l
cmp BYTE [rdx-3], 0
je addr_m
cmp BYTE [rdx-2], 0
je addr_n
cmp BYTE [rdx-1], 0
je addr_o
addr_e: mov rdi, rdx
addr_f: lea rdx, [rdi 0x8]
mov rax, QWORD [rdx-8]
lea rcx, [rax r8]
not rax
and rax, rcx
test rax, rsi
je addr_e
cmp BYTE [rdx-8], 0
jne addr_d
addr_g: mov rax, rdi
sub rax, r9
ret
xor eax, eax
ret
addr_i: sub rdi, r9
lea rax, [rdi 1]
ret
addr_j: sub rdi, r9
lea rax, [rdi 2]
ret
addr_k: sub rdi, r9
lea rax, [rdi 3]
ret
addr_l: sub rdi, r9
lea rax, [rdi 4]
ret
addr_m: sub rdi, r9
lea rax, [rdi 5]
ret
addr_n: sub rdi, r9
lea rax, [rdi 6]
ret
addr_o: sub rdi, r9
lea rax, [rdi 7]
ret

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Ja mitä olivat tulokset?

glibc strlen voitti tämän rutiinin, eli se oli ~ 3-4% nopeampi kuin tämä
vaikka tämä koodi on melkein suora disassembly kyseisestä glibc rutiinista

Jokin pielessä?
4509
Äänestä

Muut lukivat myös

Vastaukset 4

Vanhimmat

Ei välttämättä mikään pielessä.

C-kieli on käytännössä sitä assembleria mistä ohjelmallisesti tuotetaan optimaalinen tavukoodi prosessorin ajettavaksi ja prosessorivalmistajat optimoivat sitä kääntäjää. Käsin tavukoodin nysvääminen tuskin tuottaa nopeampaa tulosta.

Käsin tavukoodin nysvääminen yleisesti ottaen ollut sellaista mitä kannattanut välttää viimeiseen asti ja ollut 20v sellainen tilanne, että kääntäjästä parempaa tulosta ei oikein saa missään.

Itseasiassa 20v sitten oli sellainen kieli kuin Haskell kypsynyt jo niin hyväksi, että sillä pystyi ohjelmointikielen tasolla varmistamaan että ei ole sivuvaikutuksia koodissa joka sitten mahdollistanut optimointeja jotka ovat ihmiselle hyvin vaiketa saada virheettömästi tehtyä. Käytännössä tekeekin semmoista temppua että voi saada helposti tuotettua nopeampaa koodia mitä C:llä, kun jo C:llä sai parempaa koodia mitä käsin tavukoodia nysväämällä.

Äänestä
  • Aloittaja

    Kyllä kyllä, mutta tuo koodi on SUORA disassembly samasta C-rutiinista

    Äänestä

  • tractor kirjoitti:

    Kyllä kyllä, mutta tuo koodi on SUORA disassembly samasta C-rutiinista

    "glibc+strlen+voitti+tämän+rutiinin,+eli+se+oli+~+3-4%+nopeampi+kuin+tämävaikka+tämä+koodi+on+melkein+suora+disassembly+kyseisestä+glibc+rutiinista"Sanoit+että+melkein+suora,+eli+ei+identtinen.

    Äänestä

Miten+on+koodisi+alignment?+Sillä+on+helposti+3-4+%+merkitys,+kun+hyppyjä+tehdään+paljon.Mutta+missä+on+repnz+scasb,+jolla+strlen+oli+aikaisemmin+toteutettu?+Sitä+tehokkaampaa+koodia+tuskin+saa+tehtyä+luuppaamalla,+vaikka+hyödyntäisi+64-bittisiä+rekistereitä+yo.+koodin+tavoin.

Äänestä

Kommentoi aloitusta


tractor kirjoitti:

Huvikseni yritin disassmbloida gligc-2.28:n strlen rutiinia ja sain puristettua
ulos alla olevan intel-syntaxisen ja NASM:lla käännettävän (nasm -felf64 ...) koodin siitä.
Sitten testasin tätä (nasm'lla tuotettua) koodia linkitettynä staattisesti sitä kutsuvaan
C-koodiin ja vertasin tulosta standard C strlen kutsuihin....

; Tämä ON glibc strlen vieläpä hieman optimoituna,
; eli ei stack-framea ja poistettu kaksi if lausetta.

global as_strlen
section .text

as_strlen:
mov r9, rdi
test dil, 7
je addr_c
cmp BYTE [rdi], 0
jne addr_b
jmp addr_o
addr_a: cmp BYTE [rdi], 0
je addr_g
addr_b: inc rdi
test dil, 7
jne addr_a
addr_c: mov r8, 0xfefefefefefefeff
mov rsi, 0x8080808080808080
jmp addr_f
addr_d: cmp BYTE [rdx-7], 0
je addr_i
cmp BYTE [rdx-6], 0
je addr_j
cmp BYTE [rdx-5], 0
je addr_k
cmp BYTE [rdx-4], 0
je addr_l
cmp BYTE [rdx-3], 0
je addr_m
cmp BYTE [rdx-2], 0
je addr_n
cmp BYTE [rdx-1], 0
je addr_o
addr_e: mov rdi, rdx
addr_f: lea rdx, [rdi 0x8]
mov rax, QWORD [rdx-8]
lea rcx, [rax r8]
not rax
and rax, rcx
test rax, rsi
je addr_e
cmp BYTE [rdx-8], 0
jne addr_d
addr_g: mov rax, rdi
sub rax, r9
ret
xor eax, eax
ret
addr_i: sub rdi, r9
lea rax, [rdi 1]
ret
addr_j: sub rdi, r9
lea rax, [rdi 2]
ret
addr_k: sub rdi, r9
lea rax, [rdi 3]
ret
addr_l: sub rdi, r9
lea rax, [rdi 4]
ret
addr_m: sub rdi, r9
lea rax, [rdi 5]
ret
addr_n: sub rdi, r9
lea rax, [rdi 6]
ret
addr_o: sub rdi, r9
lea rax, [rdi 7]
ret

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Ja mitä olivat tulokset?

glibc strlen voitti tämän rutiinin, eli se oli ~ 3-4% nopeampi kuin tämä
vaikka tämä koodi on melkein suora disassembly kyseisestä glibc rutiinista

Jokin pielessä?

Anonyymi
5000

Ilmoita asiaton sisältö

  • Sisältää materiaalia, joka on loukkaavaa, herjaavaa, rasistista, uhkailevaa tai ahdistelevaa.

  • Materiaali sisältää nimiä, yhteystietoja tai muita henkilökohtaisia tietoja. Julkisuuden henkilöistä, julkisissa viroissa toimivista ihmisistä sekä yritysten vastuuhenkilöistä saa keskustella työhön liittyen. Myös yksityiselämään liittyvistä asioista voi keskustella siltä osin, kuin niistä on julkisesti kerrottu.

  • Sisältää lapsille haitallista tai heiltä kiellettyä materiaalia. Seksuaalinen sisältö on sallittua aiheeseen tarkoitetuilla palstoilla, joiden ikäraja on 18 vuotta.

  • Lainvastaista sisältöä voi olla mm. yksityiselämää loukkaavan tiedon levitys, kiihottaminen kansanryhmää vastaan, laiton uhkaaminen, alaikäisiin liittyvä seksuaalinen sisältö/grooming, petokset, identiteettivarkaudet, kunnianloukkaukset ja tekijänoikeusrikkomukset.

  • Sisältö ei liity palstan tai keskusteluketjun aiheeseen.

  • Viesti ei ole suomea tai ruotsia (pl. International Forums), se sisältää mainontaa, se sisältää tekijänoikeuksin suojattua materiaalia, se on massapostitus tai jokin muu syy.

Jaa keskustelu