[Alg] code optimalisaties

[Verwijderd]

Modbreak:

Deze topic is afgesplitst van [rml][ Java] Minder code..[/rml]

$me wil ook nog even wat algemeens over complexe code zeggen.

Complexe code is op zich niet slecht. Er worden complete IDE's, libraries, code-generators etc. geschreven. Nu klink ik misschien als een oude opa, maar een simpel stukje BASIC (ja, BASIC, omdat het IMO de potentie heeft om een hele snelle en efficiente taal te zijn, omdat het in feite heel erg op assembly lijkt (verklaar me maar meteen voor gek )) geeft al de problemen met overdadige lagenstructuren weer:

Dit:

code:

FOR Counter% = 1 TO 10 
  Array(Counter%) = "Blaat"
NEXT Counter%

Is veel inefficienter dan:

code:

Counter% = 0
DO
 Counter% = Counter% + 1
 Array(Counter%) = "Blaat"
LOOP UNTIL Counter% = 10

Het volgende is nog efficienter:

code:

Counter% = 0
LoopComplete% = 0
CallCounterLoop:
GOSUB CounterLoop

CounterLoop: 
 GOSUB CounterLoopElement
 IF Counter% = 10 THEN RETURN 
 GOTO CallCounterLoop

CounterLoopElement: 
 Counter% = Counter% + 1
 Array(Counter%) = "Blaat"
RETURN

En het volgende is het efficientst:

code:

Counter% = 0
GOTO CounterLoop
:CounterLoopFinished

CounterLoop:
 Counter% = Counter%  + 1
 Array(Counter%) = "Blaat"
 IF Counter% = 10 THEN GOTO CounterLoopFinished
 GOTO CounterLoop:

Het bovenste is het makkelijkste en wordt het vaakst gebruikt. Het is echter ook significant slomer dan wanneer je de code zelf schrijft. Je kunt natuurlijk voor een aantal veelgebruikte routines templates schrijven die je snel kunt aanpassen. Dan heb je snellere code die toch makkelijk te gebruiken is.

Nu kun je wel zeggen, BASIC is oud en inefficient (wat ik overigens betwist; het ligt aan de implementatie), maar wat ik probeer te zeggen is: gebruik simpelere opdrachten, ook al wordt de code langer, hij wordt wel efficienter.

offtopic:
Om deze redenen vindt ik het jammer dat RISC het niet heeft gehaald.

[ Voor 11% gewijzigd door .oisyn op 13-04-2005 15:05 . Reden: Typo/Codefout hersteld ]

[.oisyn]

Verwijderd schreef op woensdag 13 april 2005 @ 13:36:
(ja, BASIC, omdat het IMO de potentie heeft om een hele snelle en efficiente taal te zijn, omdat het in feite heel erg op assembly lijkt (verklaar me maar meteen voor gek ))

Dan wil ik je bij deze voor gek verklaren. Het is duidelijk dat je óf basic, óf assembly niet goed kent (of allebei natuurlijk)

De voorbeelden die je geeft zijn onzin en zegt idd meer over BASIC dan over moderne compilers. De geoptimaliseerde C/C++ equivalenten van de stukjes code die je gaf zullen bijvoorbeeld nauwelijks verschillen. Daarnaast is het optimaliseren van code door je statements te herrangschikken het laatste wat je zult doen bij het optimaliseren van code, en je winst is echt minimaal en weegt totaal niet op tegen de tijd die het je kost. Je hebt het hier over luttele cycles, en met de snelheden van hedendaagse CPU's duren die cycles ontzettend kort (1/3.000.000.000e van een seconde op een 3 GHz CPU).

Maintainability is veel en veel belangrijker, en is het dus handiger om het gewoon zo op te schrijven dat het leesbaar is, bugs voorkomt en makkelijk aan te passen is.

[Zoijar]

Verwijderd schreef op woensdag 13 april 2005 @ 13:36:
Het bovenste is het makkelijkste en wordt het vaakst gebruikt. Het is echter ook significant slomer dan wanneer je de code zelf schrijft. Je kunt natuurlijk voor een aantal veelgebruikte routines templates schrijven die je snel kunt aanpassen. Dan heb je snellere code die toch makkelijk te gebruiken is.

Wat een onzin Compilers doen verschillende optimalisaties tegenwoordig. Het is zo grappig om dit soort code te zien, die helemaal handmatig is optimized, en dat de compiler van de simpele variant dan dezelfde code maakt. Vaak zie je ook bv een unrolled loop oid (met templates dan in C++) en het blijkt dat een simpele 'for (int i=0; i<3; ++i) a[i] = b[i] + c[i]' dezelfde code oplevert. Compilers snappen waarschijnlijk veel meer optimalisatie concepten dan de gemiddelde programmeur

Anyway, hier ging het topic volgens mij niet direct over.

[FendtVario]

Daarnaast zullen de meeste coders je direct verbannen als je goto statements gebruikt

[Zoijar]

FendtVario schreef op woensdag 13 april 2005 @ 13:58:
Daarnaast zullen de meeste coders je direct verbannen als je goto statements gebruikt

Ik denk dat je er met een simpele verbanning nog goed vanaf komt

[Verwijderd]

.oisyn schreef op woensdag 13 april 2005 @ 13:45:
[...]

Dan wil ik je bij deze voor gek verklaren. Het is duidelijk dat je óf basic, óf assembly niet goed kent (of allebei natuurlijk)

Ik ken beide goed, BASIC is heel elementair. In dat opzicht lijkt het op Assembly.

De voorbeelden die je geeft zijn onzin en zegt idd meer over BASIC dan over moderne compilers. De geoptimaliseerde C/C++ equivalenten van de stukjes code die je gaf zullen bijvoorbeeld nauwelijks verschillen. Daarnaast is het optimaliseren van code door je statements te herrangschikken het laatste wat je zult doen bij het optimaliseren van code, en je winst is echt minimaal en weegt totaal niet op tegen de tijd die het je kost. Je hebt het hier over luttele cycles, en met de snelheden van hedendaagse CPU's duren die cycles ontzettend kort (1/3.000.000.000e van een seconde op een 3 GHz CPU).

Dus als je 50 threads hebt die elk .5% inefficientie hebben, verknal je zo 25 procent processortijd. Ach, je processor is toch snel genoeg, wat maakt het uit. Je merkt er niets van. Geld genoeg om steeds het nieuwste systeem te kopen. En heb je dat niet, ach, pech. Moet je een oudere versie gebruiken. Lekker makkelijk, die hoef je niet meer te ondersteunen als programmeur en jij krijgt je geld toch wel. Wat maakt het uit.

Dat is dus de mentaliteit van de tegenwoordige programmeurs.

Disclaimer: Dit is geen flame of troll tegen iets of iemand, maar een illustratie van wat ik fout vindt aan het gemiddelde programmeerwerk van de laatste tijd.

Dat voorbeeld is omdat de meeste nieuwere implementaties van BASIC (dus ook nog QuickBasic etc.) overdadige layering gebruiken. Net als een library gebruiken als je het zelf ook relatief eenvoudig kunt implementeren. Een goede standaard is boven alles eenvoudig.

Bovendien, dat BASIC voorbeeld heeft niets in particular te maken met Native C of Java. De meeste programmeurs schrijven overal libraries overheen. De ene roept de andere aan, die roept nog er een aan, en dan wordt de functie uiteindelijk uitgevoerd en is die nog inefficient geschreven ook. Ik heb het al zovaak meegemaakt.

Maintainability is veel en veel belangrijker, en is het dus handiger om het gewoon zo op te schrijven dat het leesbaar is, bugs voorkomt en makkelijk aan te passen is.

Dat GOTO voorbeeld, is dat niet het toonbeeld van simpelheid? In 5 seconden geschreven, en snel en flexibel ook. Daar kunnen veel libraries en layers nog een puntje aan zuigen.

Het lijkt wel alsof niemand meer het echte programmeren kent. Dat hoeft niet Assembly of BASIC te zijn, maar de techniek uitpersen op een _eenvoudige_ manier. Dus: zoveel mogelijk functies zelf schrijven naar je wensen. Als je een cycle kunt uitsparen, doe je dat. Die zuinigheid lijkt overdreven, maar hoe meer cycles je uitspaart, hoe meer cycles je kunt gebruiken voor andere threads. En een nieuwe processor kopen is niet de oplossing voor een snelheidsprobleem met een nieuwe versie. Uiteindelijk moet je natuurlijk upgraden, maar met voorzichtigheid bij het schrijven van code kun je dat langer uitstellen. Jammer voor de computerfabrikanten, maar ik koop _geen_ nieuw systeem als ik genoeg kracht heb om mijn werkzaamheden uit te voeren op mijn huidige. Ik durf zonder blikken of blozen te stellen dat het upgraden van een systeem met minimaal 6 maanden kunt uitstellen als nieuwe versies van applicaties goed geoptimaliseerd zijn.

[Alarmnummer]

Verwijderd schreef op woensdag 13 april 2005 @ 14:10:
Dat is dus de mentaliteit van de tegenwoordige programmeurs.

Ben ik niet met je eens. Als de baas mij 50% extra geeft om mijn applicaties volledig te optimaliseren, dan zal ik dat graag doen. Alleen hebben normale developers met deadlines te maken en als de applicatie snel genoeg is, dan kan de rekening de deur uit. Het is niet dat dat het mij niet interesseerd, maar dat er domweg geen tijd (lees geld) voor is.

Verder regel ik eenvoudiger hogere hardware specs dan een beter geoptimaliseerde software. Voor een paar hondereuro heb je betere hardware en voor een paar honderd euro heb ik nog niet echt veel kunnen optimaliseren. (Ik maak voornamelijk client server software de laatste tijd, dus met clients heb ik afgezienv van een browser niets te maken).

Disclaimer: Dit is geen flame of troll tegen iets of iemand, maar een illustratie van wat ik fout vindt aan het gemiddelde programmeerwerk van de laatste tijd.

Waar jij een probleem mee hebt is niet de snelheid van software, maar bloat. Word voor windows 3.11 kan bij mij nog steeds meer dan ik in 10.000 jaar zal gebruiken.

Dat voorbeeld is omdat de meeste nieuwere implementaties van BASIC (dus ook nog QuickBasic etc.) overdadige layering gebruiken. Net als een library gebruiken als je het zelf ook relatief eenvoudig kunt implementeren. Een goede standaard is boven alles eenvoudig.

Wat heeft layering hier mee te maken?

Bovendien, dat BASIC voorbeeld heeft niets in particular te maken met Native C of Java. De meeste programmeurs schrijven overal libraries overheen. De ene roept de andere aan, die roept nog er een aan, en dan wordt de functie uiteindelijk uitgevoerd en is die nog inefficient geschreven ook. Ik heb het al zovaak meegemaakt.

Je kent de 90% van de tijd in 10 % van de code regel toch?

Dat GOTO voorbeeld, is dat niet het toonbeeld van simpelheid? In 5 seconden geschreven, en snel en flexibel ook. Daar kunnen veel libraries en layers nog een puntje aan zuigen.

Volgens mij kan jij er beter een punt aan zuigen want dat soort bagger hoef ik niet in mijn code te zien. Ik werk trouwens over het algemeen ook op een hoger nivo dat dit. Dus geen vieze syntactische troep in mijn code om het een klein beetje sneller te krijgen. Trouwens macro optimalisaties hebben over het algemene veel grotere performance verbeteringen tot gevolg dan micro optimalisaties. Nadeel aan jouw aanpak is dat code minder goed te onderhouden is. Ook bij wat grotere projecten gaat lelijke code tegenwerken omdat simpele dingen complex worden. Microoptimalisaties is gewoon bijna altijd a big nono (imho)...

Het lijkt wel alsof niemand meer het echte programmeren kent. Dat hoeft niet Assembly of BASIC te zijn, maar de techniek uitpersen op een _eenvoudige_ manier.

Tijden veranderen..eisen veranderen..

[ Voor 10% gewijzigd door Alarmnummer op 13-04-2005 14:27 ]

[FendtVario]

Verwijderd schreef op woensdag 13 april 2005 @ 14:10:
Jammer voor de computerfabrikanten, maar ik koop _geen_ nieuw systeem als ik genoeg kracht heb om mijn werkzaamheden uit te voeren op mijn huidige. Ik durf zonder blikken of blozen te stellen dat het upgraden van een systeem met minimaal 6 maanden kunt uitstellen als nieuwe versies van applicaties goed geoptimaliseerd zijn.

Durf je dat nog te zeggen nadat je je signature nog eens gelezen hebt. Dual XEON in aanbouw, ja dan kan ik ook nog even vooruit

[.oisyn]

Verwijderd schreef op woensdag 13 april 2005 @ 14:10:

Ik ken beide goed, BASIC is heel elementair. In dat opzicht lijkt het op Assembly.

En een appel en een peer is ook allebei fruit.

Dus als je 50 threads hebt die elk .5% inefficientie hebben, verknal je zo 25 procent processortijd.

Nee, nog steeds .5%, aangezien je CPU niet in staat is al die 50 threads tegelijk af te handelen.

Ach, je processor is toch snel genoeg, wat maakt het uit. Je merkt er niets van. Geld genoeg om steeds het nieuwste systeem te kopen. En heb je dat niet, ach, pech. Moet je een oudere versie gebruiken. Lekker makkelijk, die hoef je niet meer te ondersteunen als programmeur en jij krijgt je geld toch wel. Wat maakt het uit.

Dat is dus de mentaliteit van de tegenwoordige programmeurs.

Nee, dat is het logische gevolg van dure developers die ontwikkelen op hardware waar efficientie er simpelweg niet meer toe doet. Wij ontwikkelen 3D engines voor games, efficientie is ons motto, maar we gaan ons echt niet bezig houden met triviale zaken zoals het op een andere manier opschrijven van simpele statements. Zoals ik al zei, de winst in C++ is lang niet zo merkbaar als jij het schetst met BASIC, het is gewoon een fucking waste of time om dat soort veranderingen door te voeren. De kern van optimaliseren is het gebruik van de juiste algoritmes, niet meer en niet minder. Als je dat niet begrijpt heb je er duidelijk geen kaas van gegeten.

Het is gewoon dikke vette onzin om reguliere GUI applicaties met dat soort manieren te optimaliseren, je winst is niets terwijl het wel veel meer kost. You do the math.

Bovendien, dat BASIC voorbeeld heeft niets in particular te maken met Native C of Java. De meeste programmeurs schrijven overal libraries overheen. De ene roept de andere aan, die roept nog er een aan, en dan wordt de functie uiteindelijk uitgevoerd en is die nog inefficient geschreven ook. Ik heb het al zovaak meegemaakt.

Ik zie de relevantie niet als het gaat om optimalisaties.

Dat GOTO voorbeeld, is dat niet het toonbeeld van simpelheid? In 5 seconden geschreven, en snel en flexibel ook. Daar kunnen veel libraries en layers nog een puntje aan zuigen.

Sorry, hier ga ik niet eens op in. Als jij niet snapt waarom je beter geen goto kunt gebruiken ga ik ook niet verder met de discussie.

Dus: zoveel mogelijk functies zelf schrijven naar je wensen

Ah, ik maak hieruit op dat jij niet programmeert op professionele basis maar slechts als hobby. Zelf schrijven kost tijd, en tijd kost geld. Daarnaast schiet niemand er wat mee op als iedereen zijn eigen zelfgeschrevne functies gebruikt. Dat betekent codebloat en code die niet met elkaar kan interfacen.

Ik durf zonder blikken of blozen te stellen dat het upgraden van een systeem met minimaal 6 maanden kunt uitstellen als nieuwe versies van applicaties goed geoptimaliseerd zijn.

Ik denk nog wel langer, alleen een nieuwe CPU kopen is goedkoper (!!!) dan software verder optimaliseren. Pas als je vast zit aan een platform (denk aan een videogame op een console) en je blijkt niet genoeg snelheid te halen, dan pas ga je kijken wat je daaraan moet doen, en in eerste instantie betekent dat niet statements herrangschikken; dat doe je pas op het eind. En in de praktijk komt het er dan op neer dat je dat soort optimalisaties toch niet zult doen omdat je dan al voldoende geoptimaliseerd hebt.

[Zoijar]

Je wilt serieus zeggen dat dit:

code:

Counter% = 0
GOTO CounterLoop
:CounterLoopFinished

CounterLoop:
 Counter% = Counter%  + 1
 Array(Counter%) = "Blaat"
 IF Counter% = 10 THEN GOTO CounterLoopFinished
 GOTO CounterLoop:

makkelijker te schrijven, begrijpen, en te onderhouden(!) is dan:

code:

FOR Counter% = 1 TO 10 
  Array(Counter%) = "Blaat"
NEXT Counter%

Tsja...wat valt er dan nog toe te voegen...

[RayNbow]

Zoijar schreef op woensdag 13 april 2005 @ 14:46:
Je wilt serieus zeggen dat dit:

code:

Counter% = 0
GOTO CounterLoop
:CounterLoopFinished

CounterLoop:
 Counter% = Counter%  + 1
 Array(Counter%) = "Blaat"
 IF Counter% = 10 THEN GOTO CounterLoopFinished
 GOTO CounterLoop:

makkelijker te schrijven, begrijpen, en te onderhouden(!) is dan:

code:

FOR Counter% = 1 TO 10 
  Array(Counter%) = "Blaat"
NEXT Counter%

Tsja...wat valt er dan nog toe te voegen...

Volgens mij zijn de twee stukjes code nog geen eens equivalent... Dus door optimalisatie is er een bug opgetreden

[Verwijderd]

Alarmnummer schreef op woensdag 13 april 2005 @ 14:19:
[...]

Ben ik niet met je eens. Als de baas mij 50% extra geeft om mijn applicaties volledig te optimaliseren, dan zal ik dat graag doen. Alleen hebben normale developers met deadlines te maken en als de applicatie snel genoeg is, dan kan de rekening de deur uit. Het is niet dat dat het mij niet interesseerd, maar dat er domweg geen tijd (lees geld) voor is.

Dat bedoel ik nou. Marketing, deadlines... dat hoort niet bij programmeren. Ik scrhijf en verkoop zelf ook software en programmeertools, en ik trek mij daar niets van aan. When It's Done. Als je dan zonodig een nieuwe versie moet maken doe je dat maar met een uitbreiding van de oude. Als je applicatie een goede basis heeft kunt je met minieme inspanningen extra code toevoegen die helemaal niet complex hoeft te zijn, en die de boel ook niet slomer maakt.

Verder regel ik eenvoudiger hogere hardware specs dan een beter geoptimaliseerde software. Voor een paar hondereuro heb je betere hardware en voor een paar honderd euro heb ik nog niet echt veel kunnen optimaliseren. (Ik maak voornamelijk client server software de laatste tijd, dus met clients heb ik afgezienv van een browser niets te maken).

Typisch de verbruikscultuur: alles wat niet trendy is kan meteen de deur uit. Zo hoort het niet en daar blijf ik bij. $me gebruikt naast een wat nieuwere allerlei oude systemen en die draaien nog net zo smoothly als toen ze voor het eerst in gebruik waren genomen. Terwijl ik er vanalles opgepropt heb. Dat kan, omdat ik de code eenvoudig houd. Hetzelfde programma als op mijn PIII 800 mhz de volledige processortijd claimt, werkt net zo goed en snel op een P133. Hoe? Omdat ik zelf bepaal wat er geinstalleerd en gebruikt wordt en niet een of andere programmeur in een ver land. Mijn programma's kunnen makkelijk gebruikt worden door wat minder gevorderde mensen; tegelijkertijd kan de grootste nerd er prima mee overweg. De eerste groep gebruikt voornamelijk de standaardinstellingen; de 2e past het makkelijk helemaal naar zijn wensen aan. Een goede programma-specifieke basis is flexibel, snel, uitbreidbaar, en instelbaar. Als de user wil dat mijn programma niets installeert behalve wat hij absoluut nodig heeft, doet hij dat. Bij de meeste end-user text editors kun je niet eens de HTML-functie uitzetten omdat die te diep in de code is geweven. Bij mijn programma's is het geen probleem. Hoe? De code is wat groter, maar veel eenvoudiger.

[...]

Waar jij een probleem mee hebt is niet de snelheid van software, maar bloat. Word voor windows 3.11 kan bij mij nog steeds meer dan ik in 10.000 jaar zal gebruiken.

Idd, het gaat niet alleen om de snelheid, maar om het hele scala aan ``nuttige uitbreidingen'' die je niet eens kunt uitzetten. Dat geldt voor Word, maar ook voor WordPerfect.

[...]

Wat heeft layering hier mee te maken?

Misschien hebben we allebij een andere definitie van layering. Voor mij betekent layering dat de procedure aan de top begint, die roept een laag lager aan, en die roept weer een laag lager aan, en zo door. Elk voert een bewerking op de data uit. Vaak nergens voor nodig.

[...]

Je kent de 90% van de tijd in 10 % van de code regel toch?

Idd. Die regel breek ik heel simpel door right-to-the-point code te schrijven. Nu gaat 50% van de tijd in 50% van de code zitten. Veel handiger

[...]

Volgens mij kan jij er beter een punt aan zuigen want dat soort bagger hoef ik niet in mijn code te zien. Ik werk trouwens over het algemeen ook op een hoger nivo dat dit. Dus geen vieze syntactische troep in mijn code om het een klein beetje sneller te krijgen. Trouwens macro optimalisaties hebben over het algemene veel grotere performance verbeteringen tot gevolg dan micro optimalisaties. Nadeel aan jouw aanpak is dat code minder goed te onderhouden is. Ook bij wat grotere projecten gaat lelijke code tegenwerken omdat simpele dingen complex worden. Microoptimalisaties is gewoon bijna altijd a big nono (imho)...

Een hoger niveau is altijd, wat je ook beweert, bewerkelijker dan een lager niveau. Het klinkt radicaal, maar ik vindt de mensen die alleen de hogere niveaus kennen niet de titel ``programmeur'' waard zijn. Als je een goede reden hebt, kun je op een hoger niveau programmeren. Maar ik vindt dat je altijd eerst moet kijken hoe een computer eigenlijk werkt. En dan niet de elektronica, maar de software. Dat kun je prima zien aan oudere computers en programmeermethoden omdat ze zo transparant zijn. Dan zul je nog veel opmerkelijke dingen tegenkomen. Ga niet eerst denken hoe je je code structureerd, maar wat voor effect het zal hebben op het systeem als geheel. Een simpel DOS programmaatje voor jezelf hoef je natuurlijk niet zo erg te plannen, maar zodra je wat serieuzere ambities hebt is dat een vereiste.

[...]

Tijden veranderen..eisen veranderen..

Idd. Maar wat mij ergert is dat ze de oude tijd vergeten. Ik zeg niet: vroegah was alles beter. Ik zeg: vroeger was het simpeler en beter te begrijpen. Gebruik kennis uit het verleden om tot de nieuwe inzichten voor de toekomst te komen. Dat zie ik helaas weinig terug.

[ Voor 1% gewijzigd door Verwijderd op 13-04-2005 14:54 . Reden: Typo ]

[Alarmnummer]

Verwijderd schreef op woensdag 13 april 2005 @ 14:53:
Dat bedoel ik nou. Marketing, deadlines... dat hoort niet bij programmeren. Ik scrhijf en verkoop zelf ook software en programmeertools, en ik trek mij daar niets van aan. When It's Done.

Mag jij het een keer komen uitleggen als iets niet optijd af is...

*moppelt iets over inwendige stokslagen*

Als je dan zonodig een nieuwe versie moet maken doe je dat maar met een uitbreiding van de oude.

Soms zijn de wensen zo anders dat je sneller klaar bent om een systeem opnieuw op te zetten, dan een bestaand systeem aan te passen.

Als je applicatie een goede basis heeft kunt je met minieme inspanningen extra code toevoegen die helemaal niet complex hoeft te zijn, en die de boel ook niet slomer maakt.

Afhankelijk van de wensen. Soms kunnen wijzigingen doorgrijpen tot in het hart van het systeem. Dan kunnen dingen ineens complex en extreem sloom worden.

Een hoger niveau is altijd, wat je ook beweert, bewerkelijker dan een lager niveau. Het klinkt radicaal, maar ik vindt de mensen die alleen de hogere niveaus kennen niet de titel ``programmeur'' waard zijn.

Tja... wat moet ik hier op zeggen

Als je een goede reden hebt, kun je op een hoger niveau programmeren. Maar ik vindt dat je altijd eerst moet kijken hoe een computer eigenlijk werkt.

Onzin... ligt aan het geen dat je programmeert. Het zal mij aan mijn kont roesten hoe mijn pc aan de binnenkant werkt. Zeker als je nagaat dat Java (de taal waarik mee werk) op allerlei hardware draait.

Idd. Maar wat mij ergert is dat ze de oude tijd vergeten. Ik zeg niet: vroegah was alles beter. Ik zeg: vroeger was het simpeler en beter te begrijpen. Gebruik kennis uit het verleden om tot de nieuwe inzichten voor de toekomst te komen. Dat zie ik helaas weinig terug.

Hmm. je zou de politiek in moeten gaan..

[.oisyn]

Verwijderd schreef op woensdag 13 april 2005 @ 14:53:

Dat bedoel ik nou. Marketing, deadlines... dat hoort niet bij programmeren.

Zo ken ik er ook nog wel een paar, helaas is het harde realiteit in de meeste branches.

Ik scrhijf en verkoop zelf ook software en programmeertools, en ik trek mij daar niets van aan. When It's Done.

Fijn dat jij dat kan, wij kunnen helaas niet 10 jaar over 1 game doen omdat het dan al gigantisch achterhaald is. It's done when it's done is helaas iets wat maar weinig developers kunnen zeggen. Maar dat meteen doortrekken over de hele softwareindustrie kan simpelweg gewoon niet.

[.oisyn]

Verwijderd schreef op woensdag 13 april 2005 @ 14:53:
Idd. Die regel breek ik heel simpel door right-to-the-point code te schrijven. Nu gaat 50% van de tijd in 50% van de code zitten. Veel handiger

Dan durf ik te beweren dat jij nog nooit een algoritme hebt geschreven voor iets, maar slechts lineaire applicaties maakt. Het is namelijk geen keuze die je hebt, het is afhankelijk van wat je applicatie doet. Een simpel for-lusje waarin je een functie aanroept zorgt er al voor dat de CPU vaker in de functie zit dan in de functie waar de loop in staat. De functie waar de loop in staat optimaliseren is in dat geval onzin, de functie die aangeroepen wordt optimaliseren kan daarentegen erg nuttig zijn.

[ Voor 34% gewijzigd door .oisyn op 13-04-2005 15:09 ]

[Verwijderd]

Alarmnummer schreef op woensdag 13 april 2005 @ 15:02:
[...]

Mag jij het een keer komen uitleggen als iets niet optijd af is...

*moppelt iets over inwendige stokslagen*

Aan mijzelf? Of aan mijn klanten waar ik een prima tijdelijke oplossing aanbied waarmee ze weer even verder kunnen zonder iets noemenswaardig te hoeven veranderen?

[...]

Soms zijn de wensen zo anders dat je sneller klaar bent om een systeem opnieuw op te zetten, dan een bestaand systeem aan te passen.

Mijn programma's hebben een basis die zo universeel en toch snel en specifiek is dat ik er zo lang mee kan werken als nodig is. Allemaal afkomstig van dezelfde eigen moederspecificatie en toch aangepast aan de situatie.

[...]

Afhankelijk van de wensen. Soms kunnen wijzigingen doorgrijpen tot in het hart van het systeem. Dan kunnen dingen ineens complex en extreem sloom worden.

Tja, dan moet je het hart niet te gecompliceerd maken

[...]

Tja... wat moet ik hier op zeggen

Dat zou ik ook niet weten

[...]

Onzin... ligt aan het geen dat je programmeert. Het zal mij aan mijn kont roesten hoe mijn pc aan de binnenkant werkt. Zeker als je nagaat dat Java (de taal waarik mee werk) op allerlei hardware draait.

Java is een computer op zich. Daarmee is het veel simpeler om een eigen specifieke implementatie te gebruiken. Toch gaat mijn voorkeur uit naar programma's zonder emulatie, simulatie, of virtualisatielagen. Mijn basis is niet platformafhankelijk, en mijn programma's zijn dat dus meestal ook niet. En toch schrijf ik ze met success voor de botte echte machine

[...]

Hmm. je zou de politiek in moeten gaan..

Zit ik al in Bedankt voor het compliment!

[whoami]

* whoami heeft de draad ff snel met stijgende verbazing doorgelezen.

Maar ik stel me toch wel de vraag wat een mens nu (tegenwoordig) in godsnaam zou bezielen om op zo een laag niveau aan optimalisaties te gaan doen.

Om even op het statement 'iemand die op een hoger niveau naar software kijkt is de term programmeur niet waard' te komen:
Ik denk dat, als je dat zegt, je in een droomwereld leeft, of je nog nooit professioneel aan software gewerkt hebt.
Het hogere niveau, het design van hoe de software in elkaar steekt is super-belangrijk. Niet alleen om een correcte werking te kunnen garanderen, maar ook omdat het in grote mate bepaald hoe performant die software is. Op dit niveau kan je al de meeste performantie gaan winnen (of verliezen).

De rest wat ik denk, is al gezegd.

[Alarmnummer]

Verwijderd schreef op woensdag 13 april 2005 @ 15:12:
Mijn programma's hebben een basis die zo universeel en toch snel en specifiek is dat ik er zo lang mee kan werken als nodig is. Allemaal afkomstig van dezelfde eigen moederspecificatie en toch aangepast aan de situatie.

Tja.. wat moet ik hier nu van zeggen. Ik zou wel eens willen weten wat voor complexe zaken jij maakt. Ik heb al heel wat complexe shit gemaakt en al zo vaak volledig structurele wijzigingen meegemaakt.

Tja, dan moet je het hart niet te gecompliceerd maken

Daar ontkom je soms niet aan.

Zit ik al in Bedankt voor het compliment!

Het was geen compliment.

[P_de_B]

Verwijderd schreef op woensdag 13 april 2005 @ 14:53:
[...]


Dat bedoel ik nou. Marketing, deadlines... dat hoort niet bij programmeren..

Ik zal de rest van de micro optimalisatie routines laten voor wat het is, maar hier moet ik toch even op reageren

Uit je profiel blijkt het niet, maar ik ga ervan uit dat je nog naar school gaat, of in ieder geval nog geen professionele ervaring hebt in het schrijven van software. Hoewel niet elke programmeur bovengenoemde zaken leuk zal vinden ze horen natuurlijk wel bij de dagelijkse praktijk. Je kunt niet tegen een klant zeggen dat hun opdracht 'ooit' klaar zal zijn, en dat je niet kunt vertellen hoeveel het gaat kosten.

Je hebt als je niet voor je hobby, maar voor je brood programmeert juist heel erg te maken met deadlines. Zowel als bedrijf richting klant, als programmeur richting je baas. Als je een week na een deadline klaar bent, maar je programma gebruikt .5% minder CPU tijd maak je echt niemand blij.

Je moet dit niet als een persoonlijke aanval zien, maar het is heel duidelijk dat je nog nooit een echt commercieel project gedaan hebt

[whoami]

Verwijderd schreef op woensdag 13 april 2005 @ 15:12:
[...]
Zit ik al in Bedankt voor het compliment!

Als ik jouw reply lees, dan denk ik dan: schoenmaker, blijf bij je leest, en blijf dus in de politiek, maar blijf ver weg van software ontwikkeling.

Misschien klink ik nu wel cru, maar ik denk dat je hier een beetje zit te zwanzen over jouw 'eigen applicaties' en jouw 'moeder-implementatie', of hoe je het ook noemt.

[mulder]

Denk dat de discusie hier is tussen iemand die (spijt me zeer) tooltjes schrijft als uit de hand gelopen hobby, en mensen die in/voor het bedrijfsleven met meerdere mensen applicaties bouwen.

Appels en peren, en in eigen straatje lullen...

[ Voor 12% gewijzigd door mulder op 13-04-2005 15:23 ]

[Zoijar]

Ik snap eerlijk gezegd niet waar de discussie nou precies over gaat?

Code bloat bestaat, ja. Maar dat is niet, en heeft grotendeels niet de oorzaken, die door 'de zeurkous' genoemd worden. Bloat zou juist toenemen vanwege het programmeren met dit soort optimalisaties en machine specifieke dingen. Simpelweg omdat niemand het meer begrijpt, en niemand meer een andere keus heeft dan het als blackbox her te gebruiken. Wat is nu het punt? Want optimalisaties zoals eerder aangedragen zijn gewoon niet verstandig en compleet overbodig. Daar lijkt me geen discussie over mogelijk; er zitten hier genoeg professionals, en die zijn het volgens mij allemaal met elkaar eens. Ik snap ook niet waarom profesionele programmeurs zich altijd maar moeten verdedigen tegenover amateurs, die vaak ergens iets gelezen of gehoord hebben... Maar misschien is dat in elke branche wel zo...

[mbravenboer]

De discussie is natuurlijk te belachelijk voor woorden, dus probeer ik nog even wat anders te bereiken: Ik vind dat mensen die claimen een ervaren software engineer zijn, ook het lef moeten hebben om in hun profile te zetten wat ze voor werk doen, liefst inclusief een link naar een website. Het valt toch eenvoudig te vinden, dus je staat nogal voor joker als je hier met grote claims binnenkomt maar uiteindelijk een jongen van <18 jaar blijkt te zijn met wat leuke hobby projecten. Daar is niets mis mee, maar doe dan ook niet alsof je meer ervaring hebt!

[Verwijderd]

.oisyn schreef op woensdag 13 april 2005 @ 14:28:
[...]


En een appel en een peer is ook allebei fruit.

Een sinaasappel en een grapefruit lijken heel erg op elkaar.

[...]


Nee, nog steeds .5%, aangezien je CPU niet in staat is al die 50 threads tegelijk af te handelen.

Nee, bij fatsoenlijk programmeren kan een thread processortijd inleveren. Die kun je voor een andere thread gebruiken. Helaas zie ik veel te veel een simpele NOOP om ongebruikte tijd te besteden

[...]


Nee, dat is het logische gevolg van dure developers die ontwikkelen op hardware waar efficientie er simpelweg niet meer toe doet. Wij ontwikkelen 3D engines voor games, efficientie is ons motto, maar we gaan ons echt niet bezig houden met triviale zaken zoals het op een andere manier opschrijven van simpele statements. Zoals ik al zei, de winst in C++ is lang niet zo merkbaar als jij het schetst met BASIC, het is gewoon een fucking waste of time om dat soort veranderingen door te voeren. De kern van optimaliseren is het gebruik van de juiste algoritmes, niet meer en niet minder. Als je dat niet begrijpt heb je er duidelijk geen kaas van gegeten.

Tuurlijk is het een waste of time, een keer een nieuwe methode van proggen aanleren en die altijd gebruiken. Als je een goede basis, ik noem het een standaard voor je eigen programmeerwerk ontwikkeld en die leert gebruiken, schrijf je al je code ineens stukken efficienter. Maar ja, de efficientie doet het er toch niet toe. Dan kun je mooi de consument laten upgraden naar de nieuwste hardware en daar van uit gaan. Lekker makkelijke manier om met resources om te gaan.

Het is gewoon dikke vette onzin om reguliere GUI applicaties met dat soort manieren te optimaliseren, je winst is niets terwijl het wel veel meer kost. You do the math.

Tja, de gemiddelde consument is koopziek. $me is niet zuinig, maar geef het geld uit aan waar je het
echt voor nodig hebt, en niet aan het nieuwste ditje en datje als het oude het nog prima doet.

[...]


Ik zie de relevantie niet als het gaat om optimalisaties.

Hoe meer libraries/lagen, hoe slomer. Dat is simpel rekenen

[...]


Sorry, hier ga ik niet eens op in. Als jij niet snapt waarom je beter geen goto kunt gebruiken ga ik ook niet verder met de discussie.

Jammer. Want gewoon een paar globale variabelen van parameters voorzien die de GOTO-procedure daarna uitleest, en je kunt alles doorgeven wat je wilt. Het is wat complexer, maar sneller en tegelijkertijd net zo overzichtelijk als je het goed implementeerd.

[...]

Ah, ik maak hieruit op dat jij niet programmeert op professionele basis maar slechts als hobby. Zelf schrijven kost tijd, en tijd kost geld. Daarnaast schiet niemand er wat mee op als iedereen zijn eigen zelfgeschrevne functies gebruikt. Dat betekent codebloat en code die niet met elkaar kan interfacen.

Al verkoop ik met succes programma's, ik ben geen grote speler in de softwaremarkt. Het is en blijft een hobby maar ik blijf erbij dat als de functies aan standaarden voldoen het prima moet gaan. Het is ook een proces van selecteren, als je wel goed geoptimaliseerde functies tot je beschikking hebt, gebruikt je die gewoon. Maar die moet je dan integreren in je code en niet als lib ofzow eraan hangen. Behalve als het een kernel-functie is. Dan moet je de kernel gebruiken.

[...]


Ik denk nog wel langer, alleen een nieuwe CPU kopen is goedkoper (!!!) dan software verder optimaliseren. Pas als je vast zit aan een platform (denk aan een videogame op een console) en je blijkt niet genoeg snelheid te halen, dan pas ga je kijken wat je daaraan moet doen, en in eerste instantie betekent dat niet statements herrangschikken; dat doe je pas op het eind. En in de praktijk komt het er dan op neer dat je dat soort optimalisaties toch niet zult doen omdat je dan al voldoende geoptimaliseerd hebt.

$me zorgt dat hij nooit vast aan een platform. Dezelfde applicaties draaien zonder enige aanpassing onder DOS (!), Win en Linux. Allemaal met een grafische GUI die prima voldoet. Helaas moet ik ook wel eens geloven aan de Window Manager-manie, dus dan probeer ik altijd gewoon het toegewezen (gedeelte van het) scherm als een afbeelding te schrijven. Da's makkerlijker en sneller, en het ziet er net zo herkenbaar uit als de gewone X of Win windows. Niet precies hetzelfde, maar het concept is wel hetzelfde en het valt net zo te bedienen.

[TheBorg]

TheBorg gaat jouw code even benchmarken.

[Verwijderd]

Zoijar schreef op woensdag 13 april 2005 @ 14:46:
Je wilt serieus zeggen dat dit:

code:

Counter% = 0
GOTO CounterLoop
:CounterLoopFinished

CounterLoop:
 Counter% = Counter%  + 1
 Array(Counter%) = "Blaat"
 IF Counter% = 10 THEN GOTO CounterLoopFinished
 GOTO CounterLoop:

makkelijker te schrijven, begrijpen, en te onderhouden(!) is dan:

code:

FOR Counter% = 1 TO 10 
  Array(Counter%) = "Blaat"
NEXT Counter%

Tsja...wat valt er dan nog toe te voegen...

Ja, ik wil dat serieus zeggen. De bovenste code is veel duidelijker, omdat het in kleinere stappen gebeurt. Wil je een aangepaste FOR-functie maken, dan voeg je op de juiste punt(en) een paar regels code in, en klaar. Als je alleen FOR kent, begrijp je ook niet wat FOR eigenlijk doet.

BTW, de eerste versie van de GOSUB code was niet goed, heb ik allang aangepast

[whoami]

Verwijderd schreef op woensdag 13 april 2005 @ 15:45:
[...]


Een sinaasappel en een grapefruit lijken heel erg op elkaar.

Deze discussie gaat hier op niets uitdraaien.

Nee, bij fatsoenlijk programmeren kan een thread processortijd inleveren. Die kun je voor een andere thread gebruiken. Helaas zie ik veel te veel een simpele NOOP om ongebruikte tijd te besteden

Wat oisyn wou zeggen is dat threads niet tegelijkertijd lopen.

Hoe meer libraries/lagen, hoe slomer. Dat is simpel rekenen

Hoe meer gebruik van reeds bestaande code, hoe sneller je kan ontwikkelen, hoe beter onderhoudbaar jouw code zal zijn.
Telkens het wiel opnieuw uitvinden is pas een waste of resources.

Jammer. Want gewoon een paar globale variabelen van parameters voorzien die de GOTO-procedure daarna uitleest, en je kunt alles doorgeven wat je wilt. Het is wat complexer, maar sneller en tegelijkertijd net zo overzichtelijk als je het goed implementeerd.

Lekker als je na een paar maanden eens wat moet aanpassen in die code.....
Of nee, jouw code is natuurlijk onfeilbaar, en je moet nooit iets aanpassen.

$me zorgt dat hij nooit vast aan een platform. Dezelfde applicaties draaien zonder enige aanpassing onder DOS (!), Win en Linux.

Hmm, dan wil ik wel eens weten hoe jij dat doet.
Hoe krijg je multi-threading voor elkaar ?
En file - access ?

[Verwijderd]

whoami schreef op woensdag 13 april 2005 @ 15:17:
* whoami heeft de draad ff snel met stijgende verbazing doorgelezen.

Maar ik stel me toch wel de vraag wat een mens nu (tegenwoordig) in godsnaam zou bezielen om op zo een laag niveau aan optimalisaties te gaan doen.

Tja, je hebt van die nerds die het liefst hun eigen computer bouwen uit discrete onderdelen

Om even op het statement 'iemand die op een hoger niveau naar software kijkt is de term programmeur niet waard' te komen:
Ik denk dat, als je dat zegt, je in een droomwereld leeft, of je nog nooit professioneel aan software gewerkt hebt.
Het hogere niveau, het design van hoe de software in elkaar steekt is super-belangrijk. Niet alleen om een correcte werking te kunnen garanderen, maar ook omdat het in grote mate bepaald hoe performant die software is. Op dit niveau kan je al de meeste performantie gaan winnen (of verliezen).

De rest wat ik denk, is al gezegd.

Het hogere niveau en het design van de software is idd. belangrijk. Maar voordat je daar aan begint, en ook tijdens de rest van het ontwikkelproces, moet je eerst begrijpen wat op het lagere niveau gebeurt. Ik duidde op mensen die b.v. een compleet progje in Visual Basic maken, maak niet begrijpen hoe Windows werkt, en al helemaal niet het concept van instructies, threads, etc.

[Onno]

Verwijderd schreef op woensdag 13 april 2005 @ 13:36:
Dit:

code:

FOR Counter% = 1 TO 10 
  Array(Counter%) = "Blaat"
NEXT Counter%

Al je voorbeeldjes gaan uit van 1 en 10. Laten we daar a en b van maken en zien wat er fout gaat.

code:

Counter% = a - 1
DO
 Counter% = Counter% + 1
 Array(Counter%) = "Blaat"
LOOP UNTIL Counter% = b

Dit doet niet hetzelfde als de oorspronkelijke FOR. Bekijk het geval a = 14 en b = 0. Een FOR zal niets doen, terwijl dit een eindeloze lus wordt. Daarnaast is deze code niet mogelijk als a de minimumwaarde van je integer type is. En tenslotte is het niets efficienter. De juiste herschrijving van FOR is hier

code:

Counter = a;
WHILE Counter <= b
  Array(Counter) = "Blaat"
  Counter = Counter + 1
WEND

Het volgende is nog efficienter:

code:

Counter% = a - 1
LoopComplete% = 0
CallCounterLoop:
GOSUB CounterLoop

CounterLoop: 
 GOSUB CounterLoopElement
 IF Counter% = b THEN RETURN 
 GOTO CallCounterLoop

CounterLoopElement: 
 Counter% = Counter% + 1
 Array(Counter%) = "Blaat"
RETURN

Dit is verre van efficient. Doordat je telkens GOSUBt wordt er telkens een hoop op de stack gepusht en er daarna weer van gepopt. Daarnaast moet je GOTO CallCounterLoop eigenlijk GOTO CounterLoop zijn (op deze manier vul je je stack waarschijnlijk alleen maar totdat je een overflow krijgt), en is "CallCounterLoop:" helemaal overbodig. Zelfde voor LoopComplete trouwens.

En het volgende is het efficientst:

code:

Counter% = a - 1
GOTO CounterLoop
:CounterLoopFinished

CounterLoop:
 Counter% = Counter%  + 1
 Array(Counter%) = "Blaat"
 IF Counter% = b THEN GOTO CounterLoopFinished
 GOTO CounterLoop:

Net als in het vorige voorbeeld gaat dit helemaal fout doordat de loop weer vrolijk opnieuw begint na "CounterLoopFinished:". (die : moet erachter ipv ervoor)
Verder is dit exact hetzelfde als je eerste optimalisatie.

En in het geval dat a en b bekend zijn, zoals in je oorspronkelijke voorbeeld, is het zeker niet het efficientste, dat is dit namelijk:

code:

Array(1) = "Blaat"
Array(2) = "Blaat"
Array(3) = "Blaat"
Array(4) = "Blaat"
Array(5) = "Blaat"
Array(6) = "Blaat"
Array(7) = "Blaat"
Array(8) = "Blaat"
Array(9) = "Blaat"
Array(10) = "Blaat"

Ga je uit van een variabele a en b, dan geldt nog steeds hetzelfde als wat ook bij je eerste optimalisatie fout ging.

Ik denk dat je nu wel voldoende duidelijk gemaakt hebt dat dit soort optimalisaties alleen maar tot onduidelijke, onjuiste en niet herbruikbare code leiden.

[RobIII]

Verwijderd schreef op woensdag 13 april 2005 @ 15:45:
Nee, bij fatsoenlijk programmeren kan een thread processortijd inleveren. Die kun je voor een andere thread gebruiken. Helaas zie ik veel te veel een simpele NOOP om ongebruikte tijd te besteden

Dude, écht... heb je enig idee waar je het over hebt? Een processor kan maar 1 ding tegelijk hoor, al start je 1000 threads...

Een NOOP wordt niet "zomaar" gebruikt door een compiler. Als een NOOP al wordt gebruikt is dat meestal vanwege optimalisatie van pipelines etc om er voor te zorgen dat je ALU niet vooruit gaat zitten rekenen met data die nog niet beschikbaar is. Een NOOP kost maar 1 cycle en om daar nou op te gaan zitten bezuinigen... Wou je daar nog even 1 instructie tussen frotten voordat je alsnog verder gaat met waar je mee bezig was dan?

Bekijk het eens zo: Hoeveel tijd heb je zitten in je optimalisaties? Dagen? Uren? Weken? Maanden? En hoeveel wint de eindgebruiker er mee? 0.03 sec minder wachten bij het sorteren van een klantlijstje van 1 miljoen klanten? Wat toch nooit voorkomt omdat het gemiddelde bedrijf zelden meer dan, zeg, 10.000 klanten heeft? Wat haalt het nou uit? Kom eens met wat meetbaars? Kom eens met wat zichtbare resultaten of met wat voorbeelden waar je zo trots op bent... Ik ben benieuwd.

Serieus, ik bedoel dit niet als flame, maar je lijkt niet te willen begrijpen waar het hier nou om gaat.

[ Voor 9% gewijzigd door RobIII op 13-04-2005 16:01 ]

[Verwijderd]

Alarmnummer schreef op woensdag 13 april 2005 @ 15:18:
[...]

Tja.. wat moet ik hier nu van zeggen. Ik zou wel eens willen weten wat voor complexe zaken jij maakt. Ik heb al heel wat complexe shit gemaakt en al zo vaak volledig structurele wijzigingen meegemaakt.

Bestandssystemen, databases, etc. Nee, het is niet makkelijk, Maar je krijgt er veel voor terug

[...]


Daar ontkom je soms niet aan.

Ik tot nu toe wel. Maar als ik een flinke kernel moet schrijven dan piep ik wel anders Maar ja, ik programmeer ook alleen op een kernel, niet door een kernel. Maar ik zorg wel dat ik weet hoe een kernel werkt.

[...]

Het was geen compliment.

Toch zie ik het zo

[mulder]

Als je alleen FOR kent, begrijp je ook niet wat FOR eigenlijk doet.

Ja en als ik hier druk gaat daar het licht uit? Serieus, je hebt idd een voorspoedige loopbaan in de politiek in het vooruitzicht

[ Voor 24% gewijzigd door mulder op 13-04-2005 16:02 ]

[RobIII]

Verwijderd schreef op woensdag 13 april 2005 @ 16:00:
[...]


Bestandssystemen, databases, etc. Nee, het is niet makkelijk, Maar je krijgt er veel voor terug


[...]


Ik tot nu toe wel. Maar als ik een flinke kernel moet schrijven dan piep ik wel anders Maar ja, ik programmeer ook alleen op een kernel, niet door een kernel. Maar ik zorg wel dat ik weet hoe een kernel werkt.


[...]


Toch zie ik het zo

Volgens mij zit 'ie gewoon te kijken hoe 'ie ons allemaal zoveel mogelijk kan stangen
Kom dan eens met iets tastbaars voor ons, en toon ons je grote licht?

Overigens getuigd je posthistorie nou niet van die kennis die je hier beweert te beheersen. NOFI hoor.

[ Voor 13% gewijzigd door RobIII op 13-04-2005 16:04 ]

[whoami]

Verwijderd schreef op woensdag 13 april 2005 @ 16:00:
[...]

Ik tot nu toe wel. Maar als ik een flinke kernel moet schrijven dan piep ik wel anders Maar ja, ik programmeer ook alleen op een kernel, niet door een kernel. Maar ik zorg wel dat ik weet hoe een kernel werkt.

En al jouw software werkt, zonder aanpassingen, naadloos op DOS, Linux, Windows ?
Ga ff ergens anders de mensen hun tijd verdoen ofzo....

[.oisyn]

Verwijderd schreef op woensdag 13 april 2005 @ 15:45:
Nee, bij fatsoenlijk programmeren kan een thread processortijd inleveren. Die kun je voor een andere thread gebruiken. Helaas zie ik veel te veel een simpele NOOP om ongebruikte tijd te besteden

Onzin, tenzij je busy wait loops gebruikt maar dan ben je sowieso al dom bezig. Een CPU kan maar 1 ding tegelijk (dual cores en hyperthreading even buiten beschouwing gelaten). Een thread vroegtijdig stoppen helpt niet om de boel sneller te laten lopen; de instructies die de thread op dat moment niet uitvoert zal ie alsnog uit moeten voeren op een later ogenblik.

Tuurlijk is het een waste of time, een keer een nieuwe methode van proggen aanleren en die altijd gebruiken. Als je een goede basis, ik noem het een standaard voor je eigen programmeerwerk ontwikkeld en die leert gebruiken, schrijf je al je code ineens stukken efficienter.

De meeste developers werken niet alleen, daarnaast bestaat er over het algemeen al een snelle standaard.

Tja, de gemiddelde consument is koopziek. $me is niet zuinig, maar geef het geld uit aan waar je het echt voor nodig hebt, en niet aan het nieuwste ditje en datje als het oude het nog prima doet.

Je luistert niet naar wat ik zeg. Op een gegeven moment zal een app niet meer draaien op een bepaalde CPU omdat je functionaliteit hebt toegevoegd. Je app optimaliseren zal in veel gevallen voor je klanten duurder zijn dan een nieuwe CPU kopen. Snellere CPU's zijn er namelijk zat, developmenttijd is daarentegen erg kostbaar.

Hoe meer libraries/lagen, hoe slomer. Dat is simpel rekenen

Het verschil is over het algemeen minimaal, en daarentegen wordt je code wel flexibeler. Dat laatste weegt over het algemeen zwaarder.

Jammer. Want gewoon een paar globale variabelen van parameters voorzien die de GOTO-procedure daarna uitleest, en je kunt alles doorgeven wat je wilt. Het is wat complexer, maar sneller en tegelijkertijd net zo overzichtelijk als je het goed implementeerd.

Het is meer errorprone, het is niet intuitief voor degenen die het niet geschreven hebben, en daarnaast is het lastiger te maintenancen. Sorry, maar uit alles blijkt dat je gewoon geen kaas hebt gegeten van professionele softwaredevelopment als je dit soort dingen beweert. Het is niet voor niets zo dat de rest van de wereld tegen goto ageert, en dat is heus niet omdat ze elkaar allemaal nalullen of dat efficientie totaal niet boeit.

Al verkoop ik met succes programma's, ik ben geen grote speler in de softwaremarkt. Het is en blijft een hobby maar ik blijf erbij dat als de functies aan standaarden voldoen het prima moet gaan. Het is ook een proces van selecteren, als je wel goed geoptimaliseerde functies tot je beschikking hebt, gebruikt je die gewoon. Maar die moet je dan integreren in je code en niet als lib ofzow eraan hangen. Behalve als het een kernel-functie is. Dan moet je de kernel gebruiken.

Het is onzin om een eigen stringreverse functie te maken omdat ie sneller zou zijn dan de stringreverse functie die je tot je beschikking hebt als je 'm in de hele looptijd van je programma maar 1 keer aanroept. Maar voor jou geldt dat natuurlijk niet, aangezien al je code net zo vaak wordt aangeroepen .

$me zorgt dat hij nooit vast aan een platform. Dezelfde applicaties draaien zonder enige aanpassing onder DOS (!), Win en Linux. Allemaal met een grafische GUI die prima voldoet. Helaas moet ik ook wel eens geloven aan de Window Manager-manie, dus dan probeer ik altijd gewoon het toegewezen (gedeelte van het) scherm als een afbeelding te schrijven. Da's makkerlijker en sneller, en het ziet er net zo herkenbaar uit als de gewone X of Win windows. Niet precies hetzelfde, maar het concept is wel hetzelfde en het valt net zo te bedienen.

Wat is het punt dat je hiermee nou eigenlijk wilt maken

[Verwijderd]

.oisyn schreef op woensdag 13 april 2005 @ 15:03:
[...]


Zo ken ik er ook nog wel een paar, helaas is het harde realiteit in de meeste branches.

Idd. $me schikt net zoals ieder ander naar de werkelijkheid als het niet anders kan. Als ik jou baan zou hebben zou ik dat ook doen, al was ik het er niet mee eens. Mijn eerste post waar deze discussie vandaan kwam ging alleen maar over hoe het zou moeten, niet hoe het in de praktijk gaat.

[...]


Fijn dat jij dat kan, wij kunnen helaas niet 10 jaar over 1 game doen omdat het dan al gigantisch achterhaald is. It's done when it's done is helaas iets wat maar weinig developers kunnen zeggen. Maar dat meteen doortrekken over de hele softwareindustrie kan simpelweg gewoon niet.

[/quote]

Gebruik van je totale programmeerkracht 80% voor de nieuwe applicatie en 20% om gebruikers van een oude versie tevreden te houden. Maar ja, maar met games gaat dat idd niet. $me speelt ook vaak games. Al ben ik bereid te wachten, over het algemeen is het een hippe en snelle cultuur. Helaas denkt niet iedereen goed na (en daar bedoel ik de gamers mee, niet de programmeurs) over het nut van het meest realistische mogelijk. Het duurt toch nog wel een poosje voordat het er uitziet als het echte leven. Het gaat ondanks alles toch maar stapsgewijs. Dat is net als je een DVD-speler koopt al je toch pas tevreden bent met blu ray.

[curry684]

RobIII schreef op woensdag 13 april 2005 @ 16:02:
[...]

Volgens mij zit 'ie gewoon te kijken hoe 'ie ons allemaal zoveel mogelijk kan stangen
Kom dan eens met iets tastbaars voor ons, en toon ons je grote licht?

Overigens getuigd je posthistorie nou niet van die kennis die je hier beweert te beheersen. NOFI hoor.

Hmm idd ik heb 'm 2 maanden geleden nog uitgelegd dat filebased IPC echt niet efficient is in het merendeel van de gevallen

[whoami]

BTF
* whoami zoekt curry's plaatje.

[ Voor 83% gewijzigd door whoami op 13-04-2005 16:13 ]

[FendtVario]

Verwijderd schreef op woensdag 13 april 2005 @ 15:45:
$me zorgt dat hij nooit vast aan een platform. Dezelfde applicaties draaien zonder enige aanpassing onder DOS (!), Win en Linux. Allemaal met een grafische GUI die prima voldoet. Helaas moet ik ook wel eens geloven aan de Window Manager-manie, dus dan probeer ik altijd gewoon het toegewezen (gedeelte van het) scherm als een afbeelding te schrijven. Da's makkerlijker en sneller, en het ziet er net zo herkenbaar uit als de gewone X of Win windows. Niet precies hetzelfde, maar het concept is wel hetzelfde en het valt net zo te bedienen.

Dus je schrijft niet alleen loops met GOTO's maar ook nog eens je eigen GUI"s over DOS en Windows(!!) heen.

[RayNbow]

Verwijderd schreef op woensdag 13 april 2005 @ 15:51:
[...]


Ja, ik wil dat serieus zeggen. De bovenste code is veel duidelijker, omdat het in kleinere stappen gebeurt. Wil je een aangepaste FOR-functie maken, dan voeg je op de juiste punt(en) een paar regels code in, en klaar. Als je alleen FOR kent, begrijp je ook niet wat FOR eigenlijk doet.

En als je echt wilt optimaliseren, dan zorg je voor dat je array begint met index 0 en dan vul je 'm beginnende bij index 9. Zo iets dus (code niet getest):

GAS:

.bss
array:  .skip 40                  # 4 bytes per element

.data

.text
blaat:  .asciz "blaat"


main:   movl $36, %eax            # i = 9 (9*4 = 36)
        
loop:   movl $blaat, array(%eax)  # array[counter] = blaat
        subl $4, %eax             # i-- (1 element = 4 bytes)
        jns loop                  # loop als i >= 0

end:    pushl $0                  # push exit code
        call exit                 # C library exit functie

Op deze manier scheelt het een cmp instructie. Wow, wat een optimalisatie .

[RobIII]

FendtVario schreef op woensdag 13 april 2005 @ 16:13:
[...]


Dus je schrijft niet alleen loops met GOTO's maar ook nog eens je eigen GUI"s over DOS en Windows(!!) heen.

Dat heeft ook zo z'n voordelen
XP look in DOS

Maar seriously, is er iemand in de zaal die dit nog serieus neemt? Als je toch je eigen "window manager" functies implementeert door "plaatjes" te schrijven naar het (video)geheugen...dan vraag ik je toch...

[Verwijderd]

.oisyn schreef op woensdag 13 april 2005 @ 15:06:
[...]

Dan durf ik te beweren dat jij nog nooit een algoritme hebt geschreven voor iets, maar slechts lineaire applicaties maakt. Het is namelijk geen keuze die je hebt, het is afhankelijk van wat je applicatie doet. Een simpel for-lusje waarin je een functie aanroept zorgt er al voor dat de CPU vaker in de functie zit dan in de functie waar de loop in staat. De functie waar de loop in staat optimaliseren is in dat geval onzin, de functie die aangeroepen wordt optimaliseren kan daarentegen erg nuttig zijn.

Een complete IF-boom is idd het verdiependste wat ik aan code schrijf, al vragen mijn programma's vaak wel om verschilllende soorten input. Maar als je een eigen standaard hebt waar je in geoefend bent kun je het balanceren. Je kent je eigen code, je weet wat het beste geoptimaliseerd kan worden, je kent de zwakke plekken, omdat je het zelf geschreven hebt. Als je simpel IF/GOTO gebruikt is het balanceren heel makkelijk. Dat gaat moeilijker als je complete subroutines hebt. Daarom schrijf ik ze meestal zelf.

[.oisyn]

Verwijderd schreef op woensdag 13 april 2005 @ 16:16:
Een complete IF-boom is idd het verdiependste wat ik aan code schrijf

Wat alweer aangeeft hoe onervaren je eigenlijk bent

[curry684]

Verwijderd schreef op woensdag 13 april 2005 @ 16:00:
[...]

Bestandssystemen, databases, etc. Nee, het is niet makkelijk, Maar je krijgt er veel voor terug

Dus je schrijft file systems en databases en:

Verwijderd schreef op woensdag 13 april 2005 @ 16:16:
[...]

Een complete IF-boom is idd het verdiependste wat ik aan code schrijf, al vragen mijn programma's vaak wel om verschilllende soorten input.

Laat me niet lachen

[Gé Brander]

Verwijderd schreef op woensdag 13 april 2005 @ 15:56:
[...]
Het hogere niveau en het design van de software is idd. belangrijk. Maar voordat je daar aan begint, en ook tijdens de rest van het ontwikkelproces, moet je eerst begrijpen wat op het lagere niveau gebeurt. Ik duidde op mensen die b.v. een compleet progje in Visual Basic maken, maak niet begrijpen hoe Windows werkt, en al helemaal niet het concept van instructies, threads, etc.

Hoge mate van verbazing in dit topic bij mij... Kan iemand mij volgen? Nee, ik het topic ook niet!

Topicstarter wil volgens mij niet begrijpen dat de klant betaald per uur, of fixed price/fixed date.
Als de klant betaald per uur wordt hij door topicstarter genaaid door optimalisaties die veelal niet nodig zijn of veelal goedkoper door hardware uitbreiding kan worden opgelost.
In geval van fixed price/fixed date, naait de topicstarter vooral zichzelf omdat hij in die extra tijd die hij nu bij die ene klant besteed, een tweede klant tevreden had kunnen stellen.....

Call me stupid...

<sub>Het is prima om principes te hebben, maar je kan ook overdrijven...

Gewoon een extra vraagje... Doe je ook aan documenteren? Wacht ik denk dat ik het antwoord al weet... (Laat maar, misschien een beetje te lullig...)</sub>

[ Voor 7% gewijzigd door Gé Brander op 13-04-2005 16:20 ]

[RobIII]

Verwijderd schreef op woensdag 13 april 2005 @ 16:16:
[...]
Dat gaat moeilijker als je complete subroutines hebt. Daarom schrijf ik ze meestal zelf.

<zucht>
Je snapt het idee achter subroutines niet helemaal denk ik... Het (globale) idee is dat je op meerdere plaatsen zo'n subroutine kunt aanroepen, en als er dan iets mis mee blijkt te zijn kun je dat simpel oplossen door die subroutine 1x aan te passen. En je schrijft je code geen 12x opnieuw als je 12x dezelfde functionaliteit wil gebruiken.

En geloof me, de meeste subroutines die een taal omvat (zoals een strReverse) zijn meestal al aardig geoptimaliseerd en zelden nog sneller te maken (met hier en daar een uitzondering uiteraard).

[ Voor 17% gewijzigd door RobIII op 13-04-2005 16:22 ]

[whoami]

Verwijderd schreef op woensdag 13 april 2005 @ 16:16:
[...]


Een complete IF-boom is idd het verdiependste wat ik aan code schrijf, al vragen mijn programma's vaak wel om verschilllende soorten input. Maar als je een eigen standaard hebt waar je in geoefend bent kun je het balanceren. Je kent je eigen code, je weet wat het beste geoptimaliseerd kan worden, je kent de zwakke plekken, omdat je het zelf geschreven hebt. Als je simpel IF/GOTO gebruikt is het balanceren heel makkelijk. Dat gaat moeilijker als je complete subroutines hebt. Daarom schrijf ik ze meestal zelf.

Become one with the car code.

Dit wordt hier wel een grappig topic dat zo in de hall of fame ofzo kan, maar ik ben allang gestopt met jou serieus te nemen hoor.

[ Voor 10% gewijzigd door whoami op 13-04-2005 16:22 ]

[Verwijderd]

P_de_B schreef op woensdag 13 april 2005 @ 15:18:
[...]

Ik zal de rest van de micro optimalisatie routines laten voor wat het is, maar hier moet ik toch even op reageren

Uit je profiel blijkt het niet, maar ik ga ervan uit dat je nog naar school gaat, of in ieder geval nog geen professionele ervaring hebt in het schrijven van software. Hoewel niet elke programmeur bovengenoemde zaken leuk zal vinden ze horen natuurlijk wel bij de dagelijkse praktijk. Je kunt niet tegen een klant zeggen dat hun opdracht 'ooit' klaar zal zijn, en dat je niet kunt vertellen hoeveel het gaat kosten.

Tuurlijk. Dat is de praktijk. Nogmaals, ik begon de thread met een uitleg waarom programma's niet meer zo efficient zijn als vroeger. Ik heb vanaf het begin aan begrepen dat je die principes niet altijd kunt toepassen. Dat geldt voor elk principe.

Je hebt als je niet voor je hobby, maar voor je brood programmeert juist heel erg te maken met deadlines. Zowel als bedrijf richting klant, als programmeur richting je baas. Als je een week na een deadline klaar bent, maar je programma gebruikt .5% minder CPU tijd maak je echt niemand blij.

Je moet dit niet als een persoonlijke aanval zien, maar het is heel duidelijk dat je nog nooit een echt commercieel project gedaan hebt

Helemaal mee eens. Ik heb nog nooit een echt groot commercieel project gehad, maar ik weet wel hoe het gaat in het bedrijfsleven: timetables, deadlines, version control systems, bug reports die gedistribueerd worden, geschiedenis, kosten... Dan is het niet altijd mogelijk je aan je eigen principes te houden.

[whoami]

Verwijderd schreef op woensdag 13 april 2005 @ 16:22:
[...]


Tuurlijk. Dat is de praktijk. Nogmaals, ik begon de thread met een uitleg waarom programma's niet meer zo efficient zijn als vroeger. Ik heb vanaf het begin aan begrepen dat je die principes niet altijd kunt toepassen. Dat geldt voor elk principe.

Hoezo ?
Doen ze niet meer wat ze moeten doen ?
Doen ze wat ze moeten doen niet meer in een acceptabele tijd ?

Ik denk dat jouw programma's misschien wel efficient zijn (in jouw ogen dan, en voor zover je er hebt), maar dat jij helemaal niet efficient bent.

[ Voor 15% gewijzigd door whoami op 13-04-2005 16:24 ]

[.oisyn]

Verwijderd schreef op woensdag 13 april 2005 @ 16:22:
maar ik weet wel hoe het gaat in het bedrijfsleven: timetables, deadlines, version control systems, bug reports die gedistribueerd worden, geschiedenis, kosten... Dan is het niet altijd mogelijk je aan je eigen principes te houden.

En jij vindt dat allemaal slechte dingen? Je hebt nog een hoop te leren

[Verwijderd]

whoami schreef op woensdag 13 april 2005 @ 15:19:
[...]


Als ik jouw reply lees, dan denk ik dan: schoenmaker, blijf bij je leest, en blijf dus in de politiek, maar blijf ver weg van software ontwikkeling.

Ho! Ik heb vanaf mijn 3e constant achter de computer gezeten, en ik zit pas 2 jaar in de politiek. Ik weet hoe software ontwikkeling verloopt. Programmeren is niet alleen een hobby. Het is een levensbehoefte
Politiek is een bijzaak. Mijn leven draait om computers.

Misschien klink ik nu wel cru, maar ik denk dat je hier een beetje zit te zwanzen over jouw 'eigen applicaties' en jouw 'moeder-implementatie', of hoe je het ook noemt.

Moeder-specificatie Ik zit niet te zwanzen. Ik vertel wat ik geprogammeerd heb. Mijn basis is ook niet perfect. Alleen voor mijn applicaties is het dat wel. En het leunt heel erg op het principe: simpel houden, en zelf implementeren. Al ontkom ik er vaak niet aan om andermans implementatie te gebruiken. Om een tipje van de sluier op te lichten: het is plugin-based Maar het is niet dat de plugin aangeroepen wordt zodra het nodig is, de complete controle over het programma gaat van plugin naar plugin. Dat kun je in veel gevallen beter niet doen Het is heel bewerkelijk, maar het loont voor mezelf. Eenvoud is niet gelijk aan Eenvoudig!

[cybermans]

Ik vraag me dan toch echt af waarom je niet direct assembler gaat zitten coden. Kan je me gelijk helpen aan die basic compiler voor linux?

maar ff serieus. Waarom zou je duur gaan doen? Hardware upgraden (is dat uberhaupt nodig?) is gewoon voordeliger. Tja ik werk hier in een omgeving waar het geld niet in grote stromen uit de kraam komt maar tegenwoordig hebben we hier wel pc's die allemaal snel genoeg zijn voor wat ze moeten doen. En tja voor sommige dingen zijn ze te licht en dan worden ze vervangen. Wel hier de aantekening bij dat deze machines al ruim afgeschreven zijn. Ik optimaliseer ook wel indien het nodig is maar ben het eigenlijk nog niet zo vaak tegen gekomen dat ik me hier een expert op noem.

[whoami]

Verwijderd schreef op woensdag 13 april 2005 @ 16:28:


]Ik weet hoe software ontwikkeling verloopt.

Blijkbaar niet.

[TheBorg]

10.000x de code uitvoeren in QuickBASIC 4.5 met de array 1000x vullen i.p.v. 10x:

code 1: 3.6796875 sec.
code 2: 4.44921875 sec.
code 4: 4.55859375 sec.

Code 3 kon ik helaas niks van maken.

[Alarmnummer]

Hmmm.. volgens mij kan dit topic beter gestaakt worden. Iedereen probeerd de TS een beetje voor gek te zetten en als 1 iemand dat doet kan ik er wel om lachen. Maar als de hele kluit erop duikt dan ga ik me ergeren.

Dus.. slotje?

[Verwijderd]

curry684 schreef op woensdag 13 april 2005 @ 16:10:
[...]

Hmm idd ik heb 'm 2 maanden geleden nog uitgelegd dat filebased IPC echt niet efficient is in het merendeel van de gevallen

Dat wist ik al, maar met jullie kritiek heb ik mijn procedure kunnen aanscherpen. Het is niet voor alles geschikt, maar voor veel, maar lang niet alle, progjes van mij is het bruikbaar. Maar dat komt doordat ik het liefst DOS gebruik

Over mijn posthistory: ik weet meestal wel waarover ik praat. Alleen het is voor mij vaak wel zinnig en voor anderen niet. Maar dat komt doordat ik een n3rd ben en het altijd moeilijk doen. Ik ben altijd blij met kritiek, al ga ik daar tegenin, ik scherp mijn procedure altijd wel aan. Lees maar eens een hele thread en zie hoe het plan beter gestalte krijgt. Al klinkt het voor de meeste mensen nog steeds onzinnig. Maar ja, dat ben ik

[Verwijderd]

FendtVario schreef op woensdag 13 april 2005 @ 16:13:
[...]


Dus je schrijft niet alleen loops met GOTO's maar ook nog eens je eigen GUI"s over DOS en Windows(!!) heen.

Ja. Dat is veel leuker en leerzamer.

[FendtVario]

Verwijderd schreef op woensdag 13 april 2005 @ 16:28:
Ho! Ik heb vanaf mijn 3e constant achter de computer gezeten, en ik zit pas 2 jaar in de politiek. Ik weet hoe software ontwikkeling verloopt. Programmeren is niet alleen een hobby. Het is een levensbehoefte
Politiek is een bijzaak. Mijn leven draait om computers.

Ik heb niet mijn hele leven achter de pc gezeten ik wil ook graag toegeven dat ik nog heel (heel heel) veel dingen kan leren. Maar je verhaal komt gewoon niet serieus over. Als we het anno 2005 gaan hebben over het optimaliseren van een Basic loop dan vind ik het leuk voor je dat je basic kent maar get real. Hetzelfde geldt voor je IniDB, leuk bedacht maar eerst zijn het ini bestandjes en aan het einde van het topic is het opeens een bestandssysteem op basis van ini's

Misschien kun je als politicus ook eens het nut van software patenten uitleggen. (Doe eigenlijk maar niet, anders moeten we dit topic ook afsplitsen).

[AtleX]

* AtleX gaat ook even een bijdrage proberen te leveren

@Zeurkous: Je gaat erg prat op je platformonafhankelijke programma's die schijnbaar ook nog eens sneller zijn dan de meeste andere programma's. De enigste manier om een beetje cross-platform te programmeren is om met een interpreter (juiste term?) of iets als de Java VM aan de gang te gaan. Helaas zijn die dingen ontzettend traag tov native compiled spul. Doe maar eens een kleine vergelijking tussen PHP en C/Delphi/iets met de volgende code (die eenvoudig is om te zetten naar de verschillende talen:

PHP:

<?php
 

/*
The nfib function.
*/

function nfib( $n )
{
//      print("n = " . $n . "<br/>\n");
 
        $val = 0;

        if($n < 2)
        {
                $val = 1;
        }
        else
        {
                $val = nfib($n - 1) + nfib($n - 2) + 1;
        }

//      print("val = " . $val . "<br/>\n");
 
        return $val;
}


print("Fibonacci: " . nfib(32));

?>

En jou "efficiente" stukje code:

code:

Counter% = 0
GOTO CounterLoop
:CounterLoopFinished

CounterLoop:
 Counter% = Counter%  + 1
 Array(Counter%) = "Blaat"
 Array(Counter%) = "Blaat"
 Array(Counter%) = "Blaat"
 Array(Counter%) = "Blaat"
 Array(Counter%) = "Blaat"
 Array(Counter%) = "Blaat"
 Array(Counter%) = "Blaat"
 Array(Counter%) = "Blaat"
 Array(Counter%) = "Blaat"
 Array(Counter%) = "Blaat"
 Array(Counter%) = "Blaat"
 Array(Counter%) = "Blaat"
 Array(Counter%) = "Blaat"
 Array(Counter%) = "Blaat"
 Array(Counter%) = "Blaat"
 IF Counter% = 10 THEN GOTO CounterLoopFinished
 GOTO CounterLoop:

Natuurlijk is dit even een raar voorbeeld, maar met langere stukken code ben je je overzicht totaal kwijt, en iemand anders kan je code pas na veel uitpluiswerk wijzigen. Zelfs ik leerde op mijn MBO opleiding dat een GOTO zo ongeveer het schoolvoorbeeld van spaghetticode is.

Code optimalisaties zijn leuk, maar alleen als ze echt nodig zijn en betaalbaar zijn. Schiet ik er wat mee op als mijn code 0.00001 seconde sneller is dan voor de optimalisatie? Ik heb een boze klant omdat hij een zak geld neerlegt voor iets waar hij niets aan heeft. Natuurlijk is het belangrijk om efficient te programmeren, maar leesbaarheid en bruikbaarheid van je code is ook erg belangrijk. Ook moet je natuurlijk binnen je deadline blijven en binnen de begroting, zoals al meerdere malen is genoemd, veel optimalisaties zijn te duur in gewerkte uren en geld.

Verwijderd schreef op woensdag 13 april 2005 @ 16:35:
[...]


Ja. Dat is veel leuker en leerzamer.

Sorry, maar is de ingebouwde interface van Windows niet veel sneller dan zelf een beetje een ding in een elkaar te gaan klussen? Zo'n ding maken levert je meer werk op dan dat het oplevert.

[ Voor 30% gewijzigd door AtleX op 13-04-2005 16:40 ]

[Michali]

Zoals ik het geleerd heb door veel boeken te lezen is om het gewoon eerst op een zo duidelijke, simpele methode uit te voeren. Als je dat doet is het later vrij simpel om optimalisaties uit te voeren, en dan op plaatsen waar echt een performance bottleneck zit. En dat heb ik zelf ook al meerdere malen ondervonden. Natuurlijk moet je wel enkele beslissingen nemen kwa performance, maar je moet er niet te snel mee beginnen. Gewoon goed profilen en stukjes code testen en op basis daarvan dan verbeteringen aanbrengen. Dat uitvoeren totdat je de gevraagde performance eisen hebt gehaald en dan is het klaar.

[.oisyn]

Maar goed, alles is nu wel zo'n beetje gezegd. De Zeurkous, het lijkt me verstandig dat je nog wat ervaring opdoet of anders gewoon niet doen alsof je wat te vertellen hebt want uit deze draad is wel weer gebleken dat dat niet het geval is .

Ja. Dat is veel leuker en leerzamer.

No argument there, vanuit de hobbysfeer zou ik dat ook zeker blijven doen aangezien je daar alleen maar van leert. Maar hou wel in je achterhoofd dat dit niet geldt voor professionele software development waar je te maken hebt met grote teams en ingewikkeldere stukken software, en waar geld een hele belangrijke speler is. Premature optimalisations are the root of all evil, en nog meer van dat soort uitspraken. Statements herrangschikken is bijna nooit een goed idee, tenzij je code er leesbaarder of onderhoudbaarder van wordt; performancewinst is minimaal en het kost alleen maar tijd. Tijd die je beter kunt steken in het onderzoek naar verschillende algoritmes, want die bepalen, itt lowlevel optimizations, wél of een applicatie staat of valt.

[NMe]

Verwijderd schreef op woensdag 13 april 2005 @ 16:35:
Ja. Dat is veel leuker en leerzamer.

Zelf dingen knutselen en weten hoe iets in mekaar zit is inderdaad heel leerzaam. Je zal zeker de eerste niet zijn die om iets te leren dit soort concepten zelf wil uitwerken. Maar als je als serieus/professioneel programmeur zegt dat een for minder efficiënt is dan werken met goto en labels (wat niet eens zo hoeft te zijn omdat een compiler zoiets netjes weet te optimaliseren), dan waag ik het te betwijfelen dat je ooit een goed programmeur wordt.

Nu computers steeds sneller en sneller worden is performance op dit niveau sowieso steeds minder relevant. Zelfs als het zo zou zijn dat jouw constructie sneller zou werken dan datgene wat 99% van alle programmeurs als best practice ziet, dan nog is het onwenselijk omdat de code veel minder leesbaar en minder duidelijk is. In een tijd waarin computers met de dag sneller worden en vooral snelheid in het developmentproces belangrijk is, is juist de duidelijkheid van je code belangrijk. Performancewinst van een paar nanoseconden gaat niet boven een versnelling van het productieproces van enkele weken/maanden.

edit:
Wat .oisyn ook al zegt dus.

[NMe]

De Zeurkous heeft me gemaild en wilde graag nog even wat toevoegen ter afsluiting van dit topic:

Ik weet dat ik een vreemde manier van programmeren heb, en mijn originele post was gewoon om een simpel voorbeeld te geven van wat ik vindt dat er mis is. Het was niet mijn bedoeling een complete discussie te starten, alleen kwam het er zo van. Sorry als ik mensen met mijn vreeme ideen opgeschrikt heb