Assembly: Hvordan begynne i Assembly?

[Inaktivbruker_101125]

Bare legger til andre som leser dette, hvis dere har tenkt dere å lære reverse engineering og cracking av programmer, anbefaller jeg IDA (Interactive Disassembler)

 

Beste disassembler og debuggern jeg har noen gang vært borti.

[fenderebest]

For RE i Windows er IDA sammen med Windbg en genial kombinasjon.

[Gjest Slettet+9871234]

C++ Builder 2009 / 2010 tillater bruk av "assembly statements". Fra hjelp

 

<sitat>

Category

 

Keyword extensions, C++-Specific Keywords

 

Syntax

 

asm <opcode> <operands> <; or newline>_asm__asm

_asm <opcode> <operands> <; or newline>

__asm <opcode> <operands> <; or newline>

Description

 

Use the asm, _asm, or __asm keyword to place assembly language statements in the middle of your C or C++ source code. Any C++ symbols are replaced by the appropriate assembly language equivalents.

 

You can group assembly language statements by beginning the block of statements with the asm keyword, then surrounding the statements with braces ({}).

</sitat>

 

For cpu intensive spill kan dette være veldig aktuelt. Man oppnår full ytelse og fleksibilitet ved å kombinere:

• C++ og / eller assembler kode med
  
• Skripting kode skrevet i for eksempel Python eller Lua.
  

Mange spillutviklere ser ut til å foretrekke kombinasjonen C++ / Python.

 

Ytterligere informasjon: Se linken jeg viste til ovenfor som gjentas her for å unngå misforståelser: http://www.kjellbleivik.com/Books/index.htm

 

Bla ned til og klikk på lenken "Game Development".

 

Konklusjon:

 

Avansert spillutvikling er noen av de mest CPU intensive utfordringene man møter som programmering. Lære deg å kombinere kompilert kode i C++ med inline assembler instrukser for ekstra ytelse og scripting i for eksempel Python for fleksibilitet.

 

Relaterte lenker:

 

An Introduction to Assembly Language: Part I (Visual C++ og ikke C++ builder)

 

Custom built files

Endret 11. august 2010 av Slettet+9871234

[Gjest Slettet+9871234]

En oppgave her:

 

https://www.diskusjon.no/index.php?showtopic=1249989

[Drogin]

Jeg har tatt et datamaskinarkitektur kurs på UIO.

 

Vi laget en del funksjoner skrevet i assembly... med selvfølgelig registerbruk istedenfor minne, og et par "spesial-operasjoner" for x86 slik som looping-instruksjoner, rep osv.

Totalt kanskje ca 10-20 linjer assembly.

 

Alikevell var faktisk optimalisert C kode raskere, antakeligvis fordi kompilatoren vet om noen snarveier som man må være ekspert i både assembly og x86 for å klare å utnytte.

[Drogin]

Her er faktisk plansjene fra den forelesningen hvor det ble tatt opp:

Enkel C-versjon med array 5,37ms (-O3 optimalisering)

Enkel C-versjon med pekere istedenfor array 5,43ms (-O3 optimalisering)

Enkel versjon i assemblerkode 12,73ms

Assemblerkode med repnz 5,77ms

http://www.uio.no/studier/emner/matnat/ifi/INF2270/v10/undervisningsmateriale/uke-17.pdf

 

Så du skal absolutt ikke undervurdere optimaliseringsevnen til kompilatorer i C.

Spesielt ikke dersom man tar ibruk C99

Endret 6. september 2010 av Drogin

[Gjest Slettet+9871234]

Alikevell var faktisk optimalisert C kode raskere, antakeligvis fordi kompilatoren vet om noen snarveier som man må være ekspert i både assembly og x86 for å klare å utnytte.

Det tviler jeg sterkt på. Ble det forsøkt brukt "pure inline assembly" kode. Her

 

http://www.kjellbleivik.com/Books/#assembly

 

finner du mange ressurser. Allerede på "Start her" lenken finner du litteratur som gir en rekke eksempler på hvordan man optimaliserer assembly kode. Du burde skaffe deg de bøkene. Jeg skal legge inn et konkret eksempel / hint på en ny lenke:

 

"Exercise: Improve the loop by inline assembly code."

 

så kan du selv avgjøre. Studer det eksemplet nøye. Den boken inneholder mye om inline assembly kode.

 

 

Så du skal absolutt ikke undervurdere optimaliseringsevnen til kompilatorer i C.

Hva er så det magiske ved C99?

 

Jeg kan gi deg et eksempel på en fraktal skrevet i C som gikk 100 ganger raskere i assembly.

 

Micro Cornucopia #43 Sept-Oct 1988 page 22 "Fast fractals".

Endret 7. september 2010 av Slettet+9871234

[tommen]

Jeg har tatt et datamaskinarkitektur kurs på UIO.

 

Vi laget en del funksjoner skrevet i assembly... med selvfølgelig registerbruk istedenfor minne, og et par "spesial-operasjoner" for x86 slik som looping-instruksjoner, rep osv.

Totalt kanskje ca 10-20 linjer assembly.

 

Alikevell var faktisk optimalisert C kode raskere, antakeligvis fordi kompilatoren vet om noen snarveier som man må være ekspert i både assembly og x86 for å klare å utnytte.

 

No offence men jeg tror ikke lærerstabben ved UIO er spesielt gode til å progge i assembler. Da hadde de ikke jobbet der i utgangspunktet.

 

Poenget er at det er fullt mulig å lage dårlig assembler kode.

 

 

 

Men skal du f.eks. kalkulereen funksjon som ikke støttes av OP-settet til CPU (f.eks Floating Point multiplikasjon på en 386 sx(Før dumme flames så bruker jeg dette som et eksempel men det fins tilsvarende mer kompliserte matematiske problem som ikke støttes av CPU i dag som må løses manuelt).

 

Åssen ser koden ut via en kompilator?

 

sansynligvis benyttes en loop eller en bit-shift rutine som tar enten så mange looper som trengs for å kalulere det eller 16-32-xx looper (avhengig av størrelsen på multiplikatorne). Dette er treigt.

 

I assembler vill en t.eks ha brukt log/exp multiplisering med tabell hvis hurtighet hadde vært essensielt (trenger kun 2 index tabeller samt en pluss for å finne resultatet).

[Drogin]

Jeg har heller ikke sagt at lærerstaben på UiO er eksperter på assembler/X86.

 

Og det var heller ikke poenget.

Poenget var at skal du få til raskere assembly kode enn en C-kompiler med optimization får til,

skal man være veldig god med assembler.

Eller møte noen veldig sære problemer som kompilatoren ikke greier å optimize.

[Gjest Slettet+9871234]

Personlig mener jeg det er liten vits i å lære seg assembly om du ikke:

1. Har ambisjoner om å forstå datamaskinen langt bedre enn en høynivåprogrammerer.
   
2. Kunne slå en hvilken som helst høynivåkompilator ved å kjenne maskinen og dens assembler instruksjoner inngående.
   
3. Lage ditt eget Assembler baserte språk.
   
4. Være i stand til å forstå disassemblert kode. Nærliggende Eksempel: kunne forstå avanserte virus.
   

 

Jeg har i dag lastet opp et makro bibliotek og en video rutine:

 

INFO.ASM

MYLIB.MAC

 

http://www.kjellbleivik.com/Books/ASM/Start/index.html

 

Selv om det er 8088 kode og gamle adaptere, skulle det være my å lære der.

[LonelyMan]

Bare tull at c++ kompilatorer gjør en bedre jobb. Det tar meg bare noen sekunder å gjøre en bedre jobb selv.

 

Et lite eksempel på en oppstartskode jeg har laget som er iallefall 10 ganger raskere enn oppstartskode generert i c++. Det er endel spagetti kode her men det er fordi den er optimalisert.

 

push ebx
push esi
push edi
xor esi, esi
Invoke CreateFont, 13, esi, esi, esi, FW_THIN, esi, esi, esi, esi, esi, esi, PROOF_QUALITY, esi, OFFSET FontName
mov hFont, eax
mov ecx, 3
mov edx, 150
mov esi, GRP_START_X
mov edi, GRP_START_Y
push ecx
mov ebx, OFFSET GrpList
ALIGN 16
p0: mov ecx, 2
push edi
p1: xor eax, eax
push ecx
push edx
INVOKE CreateWindowEx, eax, OFFSET Ctrl_Btn, [ebx], GRP_STY_1, esi, edi, GRP_WIDTH, GRP_HEIGHT, hWnd, edx, hInstance, eax
pop edx
add edi, GRP_Y_INC
pop ecx
add ebx, 4
inc edx
loop p1
pop edi
pop ecx
add esi, GRP_X_INC
dec ecx
test ecx, ecx
jz @F
push ecx
jmp p0
@@:
INVOKE CreateWindowEx, ecx, OFFSET Ctrl_Btn, [ebx], GRP_STY_1, esi, edi, GRP_WIDTH_L, GRP_HEIGHT_L, hWnd, edx, hInstance, ecx
mov edx, 1
mov ecx, 3
mov esi, BUT_START_X
mov edi, BUT_START_Y
mov ebx, OFFSET CtrlList
mov CreateFree, edx
push ecx
ALIGN 16
l0: mov ecx, 1
mov eax, 5
push ecx
l1: push eax
push edx
xor ecx, ecx
INVOKE CreateWindowEx, ecx, OFFSET Ctrl_Btn, [ebx], [ebx+4], esi, edi, BUT_WIDTH, BUT_HEIGHT, hWnd, edx, hInstance, ecx
pop edx
pop eax
add edi, BUT_HEIGHT + CON_SP_VER
add ebx, 8
inc edx
dec eax
jnz l1
push edx
xor eax, eax
INVOKE CreateWindowEx, EDT_EX_STY, OFFSET Ctrl_Edt, OFFSET EDT_ZERO, [ebx+4], esi, edi, BUT_WIDTH, BUT_HEIGHT, hWnd, edx, hInstance, eax
pop edx
xor eax, eax
inc edx
push edx
INVOKE CreateWindowEx, eax, OFFSET Ctrl_UpDwn, eax, UPDN_STY, eax, eax, eax, eax, hWnd, edx, hInstance, eax
mov eax, CreateFree
pop edx
add edi, BUT_HEIGHT + CON_SP_VER
add ebx, 8
inc edx
test eax, eax
jz @F
xor eax, eax
push edx
mov CreateFree, eax
INVOKE CreateWindowEx, eax, OFFSET Ctrl_Btn, OFFSET CTRL_FREE, BTN_STY_3, esi, edi, BUT_WIDTH, BUT_HEIGHT, hWnd, edx, hInstance, eax
pop edx
mov SlotBtnHwnd, eax
inc edx
@@:
pop ecx
xor eax, eax
cmp ecx, 1
jne @F
push eax
add edi, GROUP_SP_VER
mov eax, 5
jmp l1
@@:
pop ecx
dec ecx
test ecx, ecx
jz @F
add esi, BUT_WIDTH + GROUP_SP_HOR
mov edi, BUT_START_Y
push ecx
jmp l0
@@:
mov ecx, 2
mov edi, BUT_SW_START_Y
push ecx
add esi, BUT_WIDTH + SWITCH_X_GAP
ALIGN 16
m0: mov ecx, 2
m1: push ecx
push esi
push edx
xor eax, eax
INVOKE CreateWindowEx, EDT_EX_STY, OFFSET Ctrl_Edt, [ebx], [ebx+4], esi, edi, BUT_WIDTH, BUT_HEIGHT, hWnd, edx, hInstance, eax
pop edx
xor eax, eax
inc edx
push edx
INVOKE CreateWindowEx, eax, OFFSET Ctrl_UpDwn, eax, UPDN_STY, eax, eax, eax, eax, hWnd, edx, hInstance, eax
pop edx
add esi, BUT_WIDTH + EDT_BTN_XGAP
inc edx
xor eax, eax
push edx
INVOKE CreateWindowEx, eax, OFFSET Ctrl_Btn, [ebx+8], [ebx+12], esi, edi, BUT_WIDTH, BUT_HEIGHT, hWnd, edx, hInstance, eax
pop edx
pop esi
pop ecx
add ebx, 16
inc edx
dec ecx
jz @F
add edi, BUT_HEIGHT + SW_S_Y_GAP
jmp m1
@@:
pop ecx
add edi, BUT_HEIGHT + SW_GR_Y_GAP
dec ecx
jz @F
push ecx
jmp m0
@@:
ALIGN 16
sub edi, SW_GR_Y_GAP - SW_S_Y_GAP
push esi
push edx
xor eax, eax
INVOKE CreateWindowEx, EDT_EX_STY, OFFSET Ctrl_Edt, [ebx], [ebx+4], esi, edi, BUT_WIDTH, BUT_HEIGHT, hWnd, edx, hInstance, eax
pop edx
xor eax, eax
inc edx
push edx
INVOKE CreateWindowEx, eax, OFFSET Ctrl_UpDwn, eax, UPDN_STY, eax, eax, eax, eax, hWnd, edx, hInstance, eax
pop edx
add esi, BUT_WIDTH + EDT_BTN_XGAP
inc edx
xor eax, eax
push edx
INVOKE CreateWindowEx, eax, OFFSET Ctrl_Btn, [ebx+8], [ebx+12], esi, edi, BUT_WIDTH, BUT_HEIGHT, hWnd, edx, hInstance, eax
pop edx
pop esi
add ebx, 16
inc edx
add edi, BUT_HEIGHT + SW_GR_Y_GAP
add esi, KEY_CENTER
sub edi, 6
xor eax, eax
push edx
INVOKE CreateWindowEx, eax, OFFSET Ctrl_Btn, [ebx], [ebx+4], esi, edi, BUT_WIDTH, BUT_HEIGHT, hWnd, edx, hInstance, eax
add edi, BUT_HEIGHT + SW_S_Y_GAP - 5
pop edx
xor eax, eax
add esi, X_INLINE
inc edx
push edx
INVOKE CreateWindowEx, eax, OFFSET Ctrl_Btn, [ebx+8], [ebx+12], esi, edi, BUT_WIDTH, BUT_HEIGHT, hWnd, edx, hInstance, eax
pop edx
add ebx, 16
mov edi, BOTTOM_LINE_Y + QBTN_Y_GAP
mov esi, ABOUT_START_X
inc edx
xor eax, eax
push edx
INVOKE CreateWindowEx, eax, OFFSET Ctrl_Btn, [ebx], [ebx+4], esi, edi, QBTN_WIDTH, BUT_HEIGHT, hWnd, edx, hInstance, eax
pop edx
add esi, QBTN_WIDTH + QBTN_X_GAP
xor eax, eax
inc edx
INVOKE CreateWindowEx, eax, OFFSET Ctrl_Btn, [ebx+8], [ebx+12], esi, edi, QBTN_WIDTH, BUT_HEIGHT, hWnd, edx, hInstance, eax
mov edx, 250
mov esi, SEP_LINE_X
mov edi, SEP_LINE_Y1
xor ebx, ebx
push edx
INVOKE CreateWindowEx, ebx, OFFSET Ctrl_Stat, ebx, STAT_STY_1, esi, edi, SEP_LINE_WIDTH, SEP_LINE_HEIGHT_1, hWnd, edx, hInstance, ebx
pop edx
mov edi, SEP_LINE_Y2
inc edx
push edx
INVOKE CreateWindowEx, ebx, OFFSET Ctrl_Stat, ebx, STAT_STY_1, esi, edi, SEP_LINE_WIDTH, SEP_LINE_HEIGHT_2, hWnd, edx, hInstance, ebx
pop edx
mov edi, SEP_LINE_Y3
inc edx
push edx
INVOKE CreateWindowEx, ebx, OFFSET Ctrl_Stat, ebx, STAT_STY_1, esi, edi, SEP_LINE_WIDTH, SEP_LINE_HEIGHT_3, hWnd, edx, hInstance, ebx
pop edx
mov esi, 10
mov edi, BOTTOM_LINE_Y - 10
inc edx
INVOKE CreateWindowEx, ebx, OFFSET Ctrl_Stat, ebx, BTM_LINE_STY, esi, edi, WIN_WIDTH - 25, ebx, hWnd, edx, hInstance, ebx
INVOKE EnumChildWindows, hWnd, OFFSET EnumChildProc, hFont
INVOKE GetWindowLong, hWnd, GWL_EXSTYLE
or eax, WS_EX_DLGMODALFRAME or DS_CENTER
INVOKE SetWindowLong, hWnd, GWL_EXSTYLE, eax
INVOKE SetWindowPos, hWnd, 0, WIN_POS_X, WIN_POS_Y, WIN_WIDTH, WIN_HEIGHT, SWP_NOSIZE or SWP_NOZORDER or SWP_FRAMECHANGED
pop edi
pop esi
pop ebx

[Antoweif]

Ingen språk slår Assembly når det kommer til ytelse, men tid er penger så derfor blir språk som C++ brukt, fordi C++ er utrolig effektivt sammenlignet med Assembly koding.

Det er en del fordeler med å kunne Assembly selv ved C++ koding så ikke undervurder språket

 

Noter deg: Om du får til raskere program/kode (hva enn man vil sikte til) i C++ så betyr det bare at du ikke er dyktig nok i Assembly :nei2:

Endret 6. september 2012 av Antoweif

[LonelyMan]

Ja, assembler krever som regel mer tid. Sant det. Men på en annen side så føles det egentlig ikke sånn, det kan ha noe med at man føler seg hjemme med det og er i komfort sonen.

 

Her er et eksempel på et directsound program jeg har laget, directsound biblioteket er på ca 1300 linjer med assembler kode og jeg skrev det på et par dager. Men nå kan jeg gjenbruke det så ofte jeg vil selvfølgelig. Programmet som benytter biblioteket er også skrevet i assembler, men det skrev jeg på bare noen minutter, for biblioteket er så brukervennlig. Vedlagt fil. En enkel demonstrasjon på avspilling av directsound lyder i ren assembler.

DirectSound.rar

Endret 6. september 2012 av LonelyMan

[Drogin]

Jeg sier ikke at det ikke er mulig å gjøre det raskere med assembly, men å gjøre det raskere enn en god kompilator, er ofte så innviklet at det ikke er worth it.

 

Og LonelyMan, jeg husker jeg leste en tråd tidligere her på forumet hvor du skulle prøve å implementere en algoritme og sammenlikne med en skrevet i C, og du ble eid av GCC's optimaliserer.

 

Da prøvde du deg med å endre algoritme, mens C-programmet var på den gamle algoritmen.

*Knis*

Endret 7. september 2012 av Drogin

[LonelyMan]

C++ programmet som du refererer til var 8 ganger tregere enn mitt. Vedkommede tok min assemblerkode og skrev den om til 64 bit assemblerkode, så det var asm vs asm, ikke c++ vs asm. Så det du egentlig gjør er å gi meg skryt for dette. Han tok min asm kode og brukte samme koden som jeg har skrevet, ikke bare algoritmen, men han tok hele koden min og gjenbrukte den på en helt annen og bedre arkitektur, så jeg takker for skrytet ditt. he-he.

 

Nei du har ikke lest tråden skikkelig. Vedkommede som laget c++ tok min assembler kode etter jeg endret algoritme og brukte samme algoritme, han implementerte samme algoritme som jeg laget i assembler på linux og med 64 bit kode og 64 bit registre, og den kjørte nesten nøyaktig like fort som min x86 kode. Han brukte 64 bit registre i tillegg, jeg skalerte sammenlikningen, og uten tvil var min kode raskest. Du har bare ikke lest tråden skikkelig, men jeg tror ikke du forstår tråden nok til å snakke om det selv om du leser den.

 

Han kjørte på en helt annen plattform, med min egen assembler kode og min egen algoritme, på en helt annen arkitektur som er bedre enn den jeg brukte, men på tross av dette så kjørte min kode raskest.

 

Om du ønsker å sammenlikne c++ kode med min asm kode og vi bruker samme arkitektur begge to, så er du mer en velkommen til det, og jeg inviterer deg også til å bruke koden som du refererer til fra den gamle tråden, du får mer enn gjerne lov å bruke den, men bruk den på samme arkitektur. Du er mer enn velkommen til å forsøke å lage raskere kode. Jeg tror ikke du vil klare det, og han som tok min asm kode og skrev den om til sin egen arkitektur klarte det heller ikke. Jeg la frem testresultater med hans type maskinvare på x86 og viste han klart og tydelig hvor feil målingen ble, i stor skala. Det er ikke tull

Endret 7. september 2012 av LonelyMan

[LonelyMan]

Kompilatorer er blitt gode det er sant, men bare husk at de er skrevet av assembler eksperter, ikke c++ eksperter. Det er folk som meg selv som lager de. Så neste gang du skryter opp en kompilator, så ikke glem å tenk på assembler eliten (de få som er igjen av de)

Endret 7. september 2012 av LonelyMan

[Gjest Slettet+9871234]

Ja, assembler krever som regel mer tid. Sant det. Men på en annen side så føles det egentlig ikke sånn, det kan ha noe med at man føler seg hjemme med det og er i komfort sonen.

Her er et eksempel på et directsound program jeg har laget, directsound biblioteket er på ca 1300 linjer med assembler kode og jeg skrev det på et par dager. Men nå kan jeg gjenbruke det så ofte jeg vil selvfølgelig. Programmet som benytter biblioteket er også skrevet i assembler, men det skrev jeg på bare noen minutter, for biblioteket er så brukervennlig. Vedlagt fil. En enkel demonstrasjon på avspilling av directsound lyder i ren assembler.

 

LonelyMan

 

Glimrende at noen driver med dette i Norge. Som teoretisk mattematikk grenser til filosofi, grenser programmering i assembly til kunst. Den menneskelige hjerne har en stor fordel fremfor en CPU, den ser mønstre langt bedre. Dette kan utnyttesi i assembly. Kunstnere blir sjelden godtatt av sin samtid.

 

Han kjørte på en helt annen plattform, med min egen assembler kode og min egen algoritme, på en helt annen arkitektur som er bedre enn den jeg brukte, men på tross av dette så kjørte min kode raskest.

 

Det er da helt fundamentalt at man bruker samme platform. Assembly koden er jo fundamentalt avhengig av den underliggende arkitekturen og assembleren. En virkelig dyktig assembler programmer vil kunne slå de fleste C++ programmererere i effektiv (rask) kode uansett om vedkommende bruker en dårligere plattform. Det er en påstand jeg overlater til de som leser denne tråden og motbevise.

 

Om du ønsker å sammenlikne c++ kode med min asm kode og vi bruker samme arkitektur begge to, så er du mer en velkommen til det, og jeg inviterer deg også til å bruke koden som du refererer til fra den gamle tråden, du får mer enn gjerne lov å bruke den, men bruk den på samme arkitektur. Du er mer enn velkommen til å forsøke å lage raskere kode. Jeg tror ikke du vil klare det, og han som tok min asm kode og skrev den om til sin egen arkitektur klarte det heller ikke. Jeg la frem testresultater med hans type maskinvare på x86 og viste han klart og tydelig hvor feil målingen ble, i stor skala. Det er ikke tull

 

Glimrende forslag. Ser med spenning frem til resultatet.

1. Hvor lenge har du drevet med Assembly?
   
2. Har du lest Peter Nortons assembly bøker?
   

Endret 7. september 2012 av Slettet+9871234

[Drogin]

C++ programmet som du refererer til var 8 ganger tregere enn mitt. Vedkommede tok min assemblerkode og skrev den om til 64 bit assemblerkode, så det var asm vs asm, ikke c++ vs asm. Så det du egentlig gjør er å gi meg skryt for dette. Han tok min asm kode og brukte samme koden som jeg har skrevet, ikke bare algoritmen, men han tok hele koden min og gjenbrukte den på en helt annen og bedre arkitektur, så jeg takker for skrytet ditt. he-he.

 

Nei du har ikke lest tråden skikkelig. Vedkommede som laget c++ tok min assembler kode etter jeg endret algoritme og brukte samme algoritme, han implementerte samme algoritme som jeg laget i assembler på linux og med 64 bit kode og 64 bit registre, og den kjørte nesten nøyaktig like fort som min x86 kode. Han brukte 64 bit registre i tillegg, jeg skalerte sammenlikningen, og uten tvil var min kode raskest. Du har bare ikke lest tråden skikkelig, men jeg tror ikke du forstår tråden nok til å snakke om det selv om du leser den.

 

Han kjørte på en helt annen plattform, med min egen assembler kode og min egen algoritme, på en helt annen arkitektur som er bedre enn den jeg brukte, men på tross av dette så kjørte min kode raskest.

 

Om du ønsker å sammenlikne c++ kode med min asm kode og vi bruker samme arkitektur begge to, så er du mer en velkommen til det, og jeg inviterer deg også til å bruke koden som du refererer til fra den gamle tråden, du får mer enn gjerne lov å bruke den, men bruk den på samme arkitektur. Du er mer enn velkommen til å forsøke å lage raskere kode. Jeg tror ikke du vil klare det, og han som tok min asm kode og skrev den om til sin egen arkitektur klarte det heller ikke. Jeg la frem testresultater med hans type maskinvare på x86 og viste han klart og tydelig hvor feil målingen ble, i stor skala. Det er ikke tull

Tja, kan jo være artig å teste. Vi holder oss til generic x86-64 / AMD64, for Linux. Ikke noe bruk av skjermkort, SIMD elns.

Hadde vært kult om jeg bare kunne linka den med i GCC for å kalle på funksjonen din.

 

Lag en funksjon som tar inn 2 arrays av samme lengde, med type double, og en int size og returnerer float.

 

float testFunction(double *array1, double *array2, int size);

 

Algoritme:

1. Løp gjennom første og andre array parallelt

--1.1 Del hvert element i array1 med 3

--1.2 Gang hvert element i array2 med 16

--1.3 Summer elementene fra begge arrays

2. Returner summen / legg resultatet fra #1.3) på stacken

Endret 7. september 2012 av Drogin

[Gjest Slettet+9871234]

Er ikke det spesielt egnet til optimalisering siden løkkene er ganske predikerbare?

 

Kanskje ikke det beste eksemplet?

 

RISC (Reduced Instruction Set Computer) prosessoren er ganske kjent.

 

Mindre kjent er antagelig

 

VLISC (Very Large Instruction Set Computer) prosessoren er mindre kjent.

 

Poenget med den siste er at etter et par gjennomganger av en løkke, gjetter prosessoren på neste steg. En god kompilator gjør vel noe lignende.

 

På sett og vis som en Skip List om jeg ikke er helt på ville veier .

Endret 7. september 2012 av Slettet+9871234

[Drogin]

Er ikke det spesielt egnet til optimalisering siden løkkene er ganske predikerbare?

 

Kanskje ikke det beste eksemplet?

 

RISC (Reduced Instruction Set Computer) prosessoren er ganske kjent.

 

Mindre kjent er antagelig

 

VLISC (Very Large Instruction Set Computer) prosessoren er mindre kjent.

 

Poenget med den siste er at etter et par gjennomganger av en løkke, gjetter prosessoren på neste steg. En god kompilator gjør vel noe lignende.

 

På sett og vis som en Skip List om jeg ikke er helt på ville veier .

Det er en funksjon med variabel size, så den er ikke predikerbar.

Tror opgpaven egner seg ganske bra. Om noen har fordeler av den, så er det assembly-programmereren, da oppgaven er såppas liten og spesifik...da er det lett å gjøre optimaliseringer.

Å holde et slikt nivå på et stort program tilsvarende flere tusen linjer i C/C++ blir raskt verre. Mye verre.

Men vi kan prøve et enkel oppkonstruert oppgave som den ovenfor.