sciencetalk

Hey,

Is er hier iemand die goed in assembler kan programmeren ?

Ik zou willen leren optimaliseren van code.

Dank.

why? (Leer liever compilers te verbeteren...)

1. Don't.

2. Don't... yet.

3. Profile Before Optimizing

(Rules Of Optimization)

Premature optimization is the root of all evil

Eigenlijk heb je wel gelijk hoor.

Waar kun je dat leren, betere compilers schrijven ?

Ik zou willen leren optimaliseren van code.

Naast hetgeen al gezegd is: "Optimaliseer alleen daar waar dat blijkt nodig te zijn." en "de beste optimalisatie is een beter algoritme."

Mijn ervaring is dat als een programma onderdeel traag is (en dat ontdek je alleen als je het gaat onderzoeken) dit vrijwel altijd komt door een onhandig gekozen algoritme.

Tevens kon je vroeger nog wel eens een beetje snelheidswinst halen door in asm te programmeren, tegenwoordig valt dat behoorlijk tegen. De huidige cpu's hebben multiple cores, pipelining, branch-prediction.. er zijn maar heel weinig mensen die het beter kunnen doen dan een compiler.

Gentle, yet insistent executive summary: If you don't know how compilers work, then you don't know how computers work. If you're not 100% sure whether you know how compilers work, then you don't know how they work.

READ: rich programmer food

Ik heb niet alles gelezen van die blog, maar ik kan het maar beter vergeten denk ik.

Er is een Compiler Construction Wiki book.

Maar je moet eerst wel een beetje kennis hebben van automata theory en aanverwante onderwerpen.

Persoonlijk zou ik zeggen dat je het beter kunt beginnen met SICP

En voor cutting edge ontwikkelingen kun je wellicht kijken naar LLVM.

Heb je wel eens gezien wat voor asm een c++ compiler als die van VS2005 produceert? Daar is met de hand nauwelijks tegenop te optimizen hoor...

Vroeger heb ik menig routine versneld door inline assembler te gebruiken, maar tegenwoordig nooit meer. Behalve dat er ondanks ontzettend veel moeite waarschijnlijk nauwelijks iets te winnen valt, kleven er allerlei nadelen aan: asm code is veel lastiger te onderhouden, onbegrijpelijk voor anderen, een ramp om te debuggen, zo platform afhankelijk als maar kan, en één foutje en je code blijkt juist tientallen procenten trager dan wat die compiler ervan maakt.

Bedenk trouwens ook dat in de meeste programma's 99% van de CPU tijd wordt gespendeerd in 1% van de code.

Je kunt soms veel/wat snelheid winst behalen door niet gebruik te maken van interne modulen...

zelf schrijven van de module scheelt soms stukken omdat modulen soms gemaakt zijn voor te veel doeleinden.

Ook het geheugenbeheer van de interne modue is soms regelrecht pet.

Bijvoorbeeld:

het inlezen van een file gaat in delphi met blockread gewoon al 2 keer sneller.

Ik schrijf zelf een compiler en de compiler is meer bezig met het uitvoeren van niet compiler gerichte handelingen dan aan het compileren zelf.

Daarom heeft het geen zin om de compiler zelf in een andere taal dan C++ of pascal te schrijven.

Ik schrijf veel met tprocedure arrays zodat de compiler meteen weet wat voor routine hij moet uitvoeren voor de handeling.

Door mijn speciale commando-techniek waarbij A_B hetzelfde commando is als B_A heb ik een speciale techniek moeten ontwikkelen omdit snel af te handelen.

Ik probeer op veel vlakken efficient te schrijven maar heb ook wel eens routinen die niet efficient zijn.

Bij commandos die niet vaak voorkomen is dat geen enkel punt.

voorbeeld: Het opzoeken van AMSTERDAM ion een database moet zo zijn dat amsterdam voorrang bekomt tegen

Vierhuizen.

Een punt van aandacht is het feit hoe men data inleest voor de compiler..

Als de kop van de harddisk moet gaan bewegen is dat een slechte zaak.

Het is daarom zinvol om een file geheel in te lezen en deze dan pas te verwerken alsj men andere data van files nodig heeft.

De harddiskkop hoeft dan niet telkens heen en weer....

De processor werkt met 2 000 000 000 stapjes per seconde, de kop van de harddisk is 100 stapjes per seconde of zoiets.

Ik heb mijn compiler op kleine files geschreven en hij leest grofweg 500 files per seconde uit.

Het produkt omvat nu rond de 10.000 regels en de software omvat rond 253000 bytes.

En dat is geen klein programma....

Ik zeg maar van: de muis naar de compilertoets bewegen kost meer tijd dan het compileren.......

boek: Basics of Compiler Design free download.