[ALG] Nieuwe taal leren: C++/ASM *

[Battle Bunny]

Hoi All,

Ik weet dat dit een zeer lame topic is, maar ik moet op het moment wel ... Ik zit erg te twijfelen en heb nog niet echt goede argumenten gehoord waardoor ik kies voor één van de twee. Een flamewar wil ik ook niet ontlokken, ik ben gewoon op zoek naar de + en - punten van beide taaltjes.

Sinds VB3 uit is, werk ik al met Visual Basic (en sinds een tijd ook met ASP). Dit is allemaal leuk en aardig, maar met het project waar ik nu mee bezig ben blijkt dat VB toch echt ronduit bagger traag is met wiskundige toestandjes (ASM app is 5.8x sneller dan een compiled VB progje -- zelf getest), en dat is nou nét wat is zoveel nodig heb. Hierdoor ga ik dus een andere taal leren samen met een vriend van me, maar ik ben er nog niet uit welke. We werken beide al heel lang met pc's, snappen ook hoe hardware werkt enzo, en schijnen ook nog eens erg slim te zijn

Please help !

[whoami]

Ik zou voor C++ gaan, en ASM links laten liggen. Met Assembly ben je heel dicht op hardware niveau bezig en ga je je dus ook meer werk moeten steken in de I/O terwijl dat in C++ toch al veel makkelijker is. Assembly is ook heel cryptisch en zeer lastig onderhoudbaar enzo.
Doordat je op hardware-niveau bezig bent, is het ook zeer moeilijk te porten naar een ander systeem.

Een programma in C++ is veel duidelijker, kun je object georienteerd enzo aanpakken en je kunt makkelijker fouten opsporen (die fouten zul je toch al minder snel maken dan als je met Assembly bezig bent). Assembly is wel sneller, maar als je goed bezig bent in C++ zal dat zoveel niet schelen.

Het is natuurlijk ook te zien welke progsels je wilt gaan brouwen, maar ik zou zeker voor C++ gaan. De vraag assembly of C++ zou zelfs niet eens in me opkomen. Zeg nu zelf, wat is duidelijker:

code:

mov     ax,  bx

of

code:

int a = 23;

[D2k]

hoe kan je een 2GL (tnx mbravenboer) met een 3GL taal gaan vergelijken?
das echt een gevalletje appels met peren

[Alarmnummer]

Als je c++ of ASM wilt gebruiken moet je gewoon je applicatie in C++ schrijven en alleen tijd kritische routines eventueel in ASM (je als je wilt inline asm doen).

[mbravenboer]

Alarmnummer: Als je c++ of ASM wilt gebruiken moet je gewoon je applicatie in C++ schrijven en alleen tijd kritische routines eventueel in ASM (je als je wilt inline asm doen).

Mee eens, dus: leer ze allebei .

ASM is heel grappig, maar je kunt voor grotere hoeveelheden code niet opboxen tegen de huidige compilers van abstractere talen zoals C++.

Lokaal kan je nog wel aardig wat frunniken met optimalisaties, over je hele code genomen is dat echter heel lastig en ook onzinnig: optimaliseren moet je altijd voor kritische secties doen.

Globaal optimaliseren heeft geen nut en zorgt waarschijnlijk voor slechtere optimalisering in de echt kritische situaties.

[Alarmnummer]

en de beste optimalisaties zijn meestal macro optimalisaties en geen micro.

Maar als je een vb`er bent zul je het al moeilijk genoeg krijgen met c/c++. Dus maak je borst maar nat

[Onno]

Op zaterdag 02 februari 2002 12:58 schreef whoami het volgende:
Assembly is ook heel cryptisch

Zo'n opmerking valt in dezelfde categorie als 'regexen zijn onlogisch'. Gebrek aan inzicht van jouw kant maakt iets niet meteen cryptisch of ondoorzichtig. Cryptisch is assembly zeker *niet*, maar het is natuurlijk wel zo dat je vaak veel meer moet doen om hetzelfde te bereiken als in een hogere programmeertaal.

Zeg nu zelf, wat is duidelijker:

code:

mov     ax,  bx

of

code:

int a = 23;

Je doet hier twee compleet verschillende dingen, hoe kun je dat nou met elkaar vergelijken?

[Alarmnummer]

Ok, hij doet er wel verschillende dingen, maar alleen die hards schrijven hun applicatie nog in asm. Een combinatie tussen beiden is de meest voor de hand liggende oplossing.

[edit] is bijna alles over asm vergeten

[Onno]

Op zaterdag 02 februari 2002 13:16 schreef Alarmnummer het volgende:
Een combinatie tussen beiden is de meest voor de hand liggende oplossing.

Natuurlijk. Maar niet omdat assembly onduidelijk of cryptisch zou zijn. Gemak is iets anders dan duidelijkheid.

[whoami]

Op zaterdag 02 februari 2002 13:14 schreef Onno het volgende:

Zo'n opmerking valt in dezelfde categorie als 'regexen zijn onlogisch'. Gebrek aan inzicht van jouw kant maakt iets niet meteen cryptisch of ondoorzichtig. Cryptisch is assembly zeker *niet*, maar het is natuurlijk wel zo dat je vaak veel meer moet doen om hetzelfde te bereiken als in een hogere programmeertaal.

cryptisch heeft niet direct iets te maken met gebrek aan inzicht. Een taal kan cryptisch zijn al versta je die taal.
Ik kan geen Assembly, maar C++ is toch cryptischer dan Basic bv.

Je doet hier twee compleet verschillende dingen, hoe kun je dat nou met elkaar vergelijken?

Ik gaf hier gewoon een voorbeeld van een statement in alletwee de talen, of die nu iets verschillends doen of niets doet niet echt terzake. Het zijn naar ik meen alletwee assignments.

[Alarmnummer]

Op zaterdag 02 februari 2002 13:20 schreef Onno het volgende:

[..]

Natuurlijk. Maar niet omdat assembly onduidelijk of cryptisch zou zijn. Gemak is iets anders dan duidelijkheid.

Ik zou niet graag een bubblesort in ams willen nakijken op fouten Maar ik heb ook al heeeel lang niets meer gedaan in asm.

En ik gebruikte het ook alleen op plekken waar het nodig was. Een putpixel, pageflip of iets dergelijks. En dan kan je wel een behoorlijke performance winst halen

En wat was 64kb toen nog veel geheugen wat moet je met 1 mb geheugen? Dat krijg je ja nooit vol!!

[Battle Bunny]

Zoals ik al verwachtte: de meningen zijn verdeeld. Zoals het er nu uitziet, lijkt de menigte toch te gaan voor C++, dus ik denk dat ik dat ook maar zal doen. Kon je in C++ (MS compiler) trouwens ook ASM code opnemen? Net zoals in Pascal, dus. Dat zou erg handig zijn voor de ECHTE kritische delen.

Thanks voor alle antwoorden !

[Alarmnummer]

Op zaterdag 02 februari 2002 13:34 schreef Battle_Bunny het volgende:
Zoals ik al verwachtte: de meningen zijn verdeeld. Zoals het er nu uitziet, lijkt de menigte toch te gaan voor C++, dus ik denk dat ik dat ook maar zal doen. Kon je in C++ (MS compiler) trouwens ook ASM code opnemen? Net zoals in Pascal, dus. Dat zou erg handig zijn voor de ECHTE kritische delen.

Thanks voor alle antwoorden !

Als het goed is wel ja

in tc (turbo c) kon het zo (geloof ik)

code:

void bla(){
   asm{
    mov ax,10
    add ax,10
    ... etc
   }
}

pfff... tis veel te lang geleden Ik prog alleen nog java

Het is juist leuk dat je talen met elkaar kan combineren, ze hebben namelijk stuk voor stuk sterke en zwakke punten en je kunt dan zelf de beste taal voor je job (deeltaak evt) uitzoeken.

[RickN]

FF twee opmerkingen:

Als je je ASM appje maar 5,8x sneller krijgt dan een VB (notabene!!!!) appje, dan is je ASM nog véééééééééél te traag (afhankelijk van de toepassing natuurlijk)

Houd bij optimalisaties altijd Amdahls Law in de gaten. Dit is een wet die vooral in de hardware scene gebruikt wordt, maar hij heeft natuurlijk evengoed betrekking op software. Amdahl's Law zegt dat de speedup die je krijgt van een optimalisatie altijd begrensd zal zijn door de fractie die van de optimalisatie gebruik kan maken. Deze begrensing is zeer extreem en tegenintuïtief. Stel dat je een bepaald stuk code 20x (!!!) zo snel kunt krijgen en je algorime bevindt zich 90% (!!!) van de tijd in die code dan is de effectieve speedup die de hele applicatie daarmee ondervind slechts 6,9x (!!!). Laat dit ff tot je doordringen, 6,9x lijkt wel veel maar kijk ff wat je daarvoor moet doen. Je moet 90% van je code (of iig de code die 90% van de tijd geexecuteerd wordt) 20x zo snel maken!!!.

ASM is leuk, maar vaak "more troubles that it's worth"

[Onno]

Op zaterdag 02 februari 2002 13:21 schreef whoami het volgende:
cryptisch heeft niet direct iets te maken met gebrek aan inzicht. Een taal kan cryptisch zijn al versta je die taal.
Ik kan geen Assembly, maar C++ is toch cryptischer dan Basic bv.

En ook cryptischer dan assembly.

x86 assembly bestaat enkel uit hele simpele instructies, met 0 t/m 3 parameters. Geen ingewikkelde language constructs, geen lange onleesbare regels, alleen maar simpele instructies. Daarom schrijf ik het cryptisch noemen van assembly toe aan gebrek aan inzicht.

Ik gaf hier gewoon een voorbeeld van een statement in alletwee de talen, of die nu iets verschillends doen of niets doet niet echt terzake. Het zijn naar ik meen alletwee assignments.

Ja, en a = (b==(c>d)?e:f) is ook een assignment. Als je die vergelijkt met mov ax, bx, zeg je dan nog steeds dat C duidelijker is? Zomaar twee assignments noemen heeft geen enkele waarde als ze niet hetzelfde doen. (overigens was jouw C voorbeeld geen assignment maar een declaratie)

[Battle Bunny]

FF twee opmerkingen:

Als je je ASM appje maar 5,8x sneller krijgt dan een VB (notabene!!!!) appje, dan is je ASM nog véééééééééél te traag (afhankelijk van de toepassing natuurlijk)

Hummmz... Het was eigenlijk geen echte app, maar een test case. Het enige wat 'ie deed was van 1 tot 4294967295 tellen

code:

ASM:
    9 784 ms
VB :
    Uncompiled, Do...Loop
        460 456 ms :)
    Uncompiled, For ... Next loop
        97 944 ms
    Compiled, For ... Next loop
        56 507 ms

Houd bij optimalisaties altijd Amdahls Law in de gaten. Dit is een wet die vooral in de hardware scene gebruikt wordt, maar hij heeft natuurlijk evengoed betrekking op software. Amdahl's Law zegt dat de speedup die je krijgt van een optimalisatie altijd begrensd zal zijn door de fractie die van de optimalisatie gebruik kan maken. Deze begrensing is zeer extreem en tegenintuïtief. Stel dat je een bepaald stuk code 20x (!!!) zo snel kunt krijgen en je algorime bevindt zich 90% (!!!) van de tijd in die code dan is de effectieve speedup die de hele applicatie daarmee ondervind slechts 6,9x (!!!). Laat dit ff tot je doordringen, 6,9x lijkt wel veel maar kijk ff wat je daarvoor moet doen. Je moet 90% van je code (of iig de code die 90% van de tijd geexecuteerd wordt) 20x zo snel maken!!!.

ASM is leuk, maar vaak "more troubles that it's worth"

Jesus ... Dit stukje ga ik nog een paar keer lezen
Ik reken altijd simpelweg vanaf het begin van wat dan ook totdat de hele code klaar is, niet per stukje ofzo...

[farlane]

Eigenlijk lijkt me je keuze duidelijk ...

Je gaat C++ leren en daarbij laat je VB voor wat het is (Behalve voor een simpele GUI applicatie met een db eraan ofzo..) Voordeel is dat je ook veel C oppikt onderweg.

Loop je op een keer tegen een performance bottleneck aan dan herzie je je ontwerp.

Kom je er echt niet onderuit dan ga je in asm freubelen.( Op dit punt beland je pas als je je eigen OS aan het schrijven bent oid, wat nog erg lang gaat duren als je tot nu toe alleen VB hebt gebruikt. )

[RickN]

Nog ff over Amdahl's Law. Dit grafiekje geeft goed aan wat Amdahl's Law nou eigenlijk betekent.

Speedup_opt is versnelling van het geoptimaliseerde stuk code.

Fractie_opt is de fractie van de tijd dat geoptimaliseerde code wordt geexecuteerd.

Speedup_eff is de effectieve speedup die je krijgt bij de gegeven Speedup_opt en Fractie_opt.



Bemoedigend hè....

[mbravenboer]

Ik vind dit grafiekje een beetje misleidend.

Dit grafiekje duwt je namelijk nogal richting de conclusie dat het geen nut heeft om een stuk code te optimaliseren tenzij deze een extreem groot deel uitmaakt van de executie-tijd. Dat zegt echter niet dat je nu maar globaal moet gaan optimaliseren. Ik wil namelijk meer grafiek zien: wat gebeurt er bij een grotere speedup(opt)?

Je moet juist details optimaliseren. Er zijn ook beweringen die bijvoorbeeld stellen dat een programma meer dan 90% van de tijd in minder dan 10% van de code doorbrengt. Dat is juist weer zeer bemoedigend. Als je deze 10% van de code extreem kunt optimaliseren (en dan heb ik het dus niet over 20%) kan je juist zeer grote effecten bereiken op je speedup(eff). Het heeft geen nut om de andere 90% van de code met bijvoorbeeld 5% te gaan optimaliseren. Dat kan je duidelijk zien in de grafiek hierboven. In dit stuk is dus ook de tijd die je als ontwikkelaar hebt om te optimaliseren meegenomen.

Dit hele aspect van grote effecten op kleine delen die vaak worden uitgevoerd zie je niet terug in deze grafiek.

Dus: bekijk waar je code de meeste tijd doorbrengt en investeer zwaar in het optimaliseren van dit kleine percentage. Hierdoor kan je een hoge speedup(opt) bereiken, waardoor speedup(eff) ook groot wordt (met dank aan de al hoge fractie(opt).

Bemoedigend he? .

[mbravenboer]

Nog even analyserend uit de grafiek: Je ziet op het gegeven moment het vlak vrij stijl omhoog lopen. Je moet als je aan het optimaliseren bent altijd zorgen dat je in dat gebied bezig bent en niet in het vlakke stuk: dat is niet effectief. Zoals je ziet gaat het effect op het laatst zelfs extreem stijl omhoog.

Wanneer zit je dus in het stijle stuk?
1. Als de applicatie een groot gedeelte in het stuk code doorbrengt
2. Als de optmalisatie in dat stuk erg goed is.

Deze afweging moet je dus maken als je aan het optimaliseren bent . Hoe maak je die afweging? Zoek uitgaande van een bepaalde tijd die je hebt om te optimaliseren stuk code waarbij je genoeg effect kunt bereiken en waar dat effect ook globaal effectief is. .

Het heeft dus geen zin om uit performance overwegingen je volledige applicatie in ASM te schrijven. Dit zal meer ontwikkelingstijd vragen en dus heb je minder tijd om de echt belangrijke onderdelen te optimaliseren.

[Battle Bunny]

Eigenlijk lijkt me je keuze duidelijk ...

Je gaat C++ leren en daarbij laat je VB voor wat het is (Behalve voor een simpele GUI applicatie met een db eraan ofzo..) Voordeel is dat je ook veel C oppikt onderweg.

Loop je op een keer tegen een performance bottleneck aan dan herzie je je ontwerp.

Kom je er echt niet onderuit dan ga je in asm freubelen.( Op dit punt beland je pas als je je eigen OS aan het schrijven bent oid, wat nog erg lang gaat duren als je tot nu toe alleen VB hebt gebruikt. )

Dit lijkt me inderdaad het beste voor nu. Vergis je alleen niet over het feit dat ik alleen maar VB kan, want dat betekent natuurlijk niet dat ik geen performance problemen heb (zelfs in C++)... Het gaat hier namelijk om het begin van een 3D engine, die alles in software gaat doen. Dit hebben we voor de test in VB gedaan, omdat ik dit al kon, en het wel makkelijk is om te debuggen enzo. Dat ik op dit moment 60fps heb in een "scene" maar 260 lijnen, tja ...

[EDIT]: Het bovenstaande zorgt er meteen voor, dat ik het liefst NU dingen zo snel mogenlijk maak, en ook dat ik de kleinste optimalisaties toepas. (Niet dat het veel helpt in VB )

[RickN]

Op zaterdag 02 februari 2002 15:34 schreef mbravenboer het volgende:
Ik vind dit grafiekje een beetje misleidend.

Je hebt m'n grafiekje niet helemaal goed begrepen, of misschien ben ik niet helemaal duidelijk geweest met wat ik hier nu afbeeld, maar hoe dan ook, deze grafiek is niet misleidend, wel erg schokkend. Voor ik verder ga wil ik even zeggen dat deze grafiek niet het resultaat is van experimenten ofzo, maar gewoon wiskundig te berekenen valt. Bij de gegeven optimalisaties en fracties KUN JE ABSOLUUT NIET EEN HOGERE VERSNELLING KRIJGEN DAN DEZE GRAFIEK AANGEEFT.

Dit grafiekje duwt je namelijk nogal richting de conclusie dat het geen nut heeft om een stuk code te optimaliseren tenzij deze een extreem groot deel uitmaakt van de executie-tijd.

Idd, daar kun je onmogelijk omheen. En hoe schokkend het ook is, het is een zeer bekend resultaat.

Dat zegt echter niet dat je nu maar globaal moet gaan optimaliseren. Ik wil namelijk meer grafiek zien: wat gebeurt er bij een grotere speedup(opt)?

Ik denk dat je hele reactie een beetje gekleurd is door de volgende onduidelijkheid. De Speedup_opt in de grafiek is absoluut, niet relatief. De speedup loopt dus van 1x tot 20x of, zoals jij het wilt, van 100% tot 2000%!!!

Je moet juist details optimaliseren. Er zijn ook beweringen die bijvoorbeeld stellen dat een programma meer dan 90% van de tijd in minder dan 10% van de code doorbrengt. Dat is juist weer zeer bemoedigend.

Helemaal mee eens en dat spreekt de grafiek ook niet tegen. Die bewering die je noemt (locality of execution genoemd) is samen met een dergelijke bewering (locality of reference genoemd) het enige wat ons red, zonder dit zou b.v. caching in moderne cpu's ook veel minder zinvol zijn. Maar in mijn hele post heb ik ook telkens gepraat over de fractie van executie tijd, nooit over de fractie van code.

Als je deze 10% van de code extreem kunt optimaliseren (en dan heb ik het dus niet over 20%) kan je juist zeer grote effecten bereiken op je speedup(eff).

Dit was dus blijkbaar niet helemaal duidelijk, de grafiek loopt dus van 100% tot 2000%

Het heeft geen nut om de andere 90% van de code met bijvoorbeeld 5% te gaan optimaliseren. Dat kan je duidelijk zien in de grafiek hierboven.

Sterker nog, het heeft zelfs geen zin om dat andere deel van de code 2000% (of whatever) te optimaliseren.

In dit stuk is dus ook de tijd die je als ontwikkelaar hebt om te optimaliseren meegenomen.

Dit hele aspect van grote effecten op kleine delen die vaak worden uitgevoerd zie je niet terug in deze grafiek.

Dat zie je JUIST terug in deze grafiek.

Dus: bekijk waar je code de meeste tijd doorbrengt en investeer zwaar in het optimaliseren van dit kleine percentage. Hierdoor kan je een hoge speedup(opt) bereiken, waardoor speedup(eff) ook groot wordt (met dank aan de al hoge fractie(opt).

Ik zou willen zeggen: Als hier je een hoge speedup(opt) kunt bereiken, dan wordt speedup(eff) ook hoog (met dank aan de hoge fractie(opt).

Bemoedigend he? .

We zijn nog niet verdoemd nee....

P.S. De post die je hierna maakte, daar ben ik het volledig mee eens.

[Battle Bunny]

Aangezien hier heel veel info wordt rondgegooid, weet iemand ook hoesnel C is vergeleken VB? En dan heb ik het niet over een simpel GUI'tje, maar echt over zware wiskundige toestanden (zoals wat ik nu gebruik, veel COS, TAN, SIN, etc)

[mbravenboer]

RickN: Je hebt m'n grafiekje niet helemaal goed begrepen

Ah, ik was inderdaad uitgegaan van percentage , maar dat maakt voor de kern van de zaak niet zoveel uit.

deze grafiek is niet misleidend, wel erg schokkend.

Dat vind ik echt wel meevallen. Hij is wel misleidend, en hij is niet schokkend .

Reken je even mee?

Stel dat je een stuk code hebt. Van een execute van 100 sec brengt deze code 90 sec door in deel x, 10 sec in deel y.

Als we dit deel x nu eens 2x zo snel maken?

De tijd in deel x wordt nu gereduceerd tot 45 sec. Deel y duurt nog steeds 10 sec => totale execute is 55 sec ipv 100 sec!

Dat klinkt dus positief, waarom ziet dit er in de grafiek hierboven nu zo slecht uit?

Het is in de grafiek niet slecht ! Een visuele interpretatie van deze grafiek is echter misleidend. Het lijkt namelijk wel slecht...

Ok, hoe komt dit dan?

Heel simpel: als je een deel 10x optimalseert wordt de totale code natuurlijk in geen enkel geval meer dan 10x geoptimalseerd! De grafiek suggereerd (ten minste bij mij) echter dan 20x het subliem haalbare is! Als je een deel van de code 2x optimaliseert geldt natuurlijk hetzelfde .

Je moet dus bij een visuele interpretatie van de grafiek niet kijken naar de liggen van het vlak ten opzichte van de bovenkant van het blok, maar ten opzichte van de rechte lijn tegen de recher-achterkant van de grafiek.

Een visuele interpretatie werkt daarom erg misleidend. Geringe optimalisaties (2x bijv) op die een groot deel van de tijd worden uitgevoerd, lijken in de grafiek bij een verkeerde interpretatie helemaal niet effectief. Dat zijn ze
echter wel!

Dit hele effect wordt nog enorm versterkt door de kleuring in de grafiek. De kleuring suggereert dat paars een andere situatie is dan lichtblauw (beter bijvoorbeeld). Maar ook dat is dus niet zo .

Bij de gegeven optimalisaties en fracties KUN JE ABSOLUUT NIET EEN HOGERE VERSNELLING KRIJGEN DAN DEZE GRAFIEK AANGEEFT.

Dat hoef je niet in caps te zetten hoor. IK begrijp ook wel dat dit gewoon formules zijn. Het gaat mij ook niet zozeer om de incorrectheid van deze grafiek.

[mbravenboer]

Wat je trouwens wel uit de grafek op kunt maken: optimalisaties hebben alleen nut als die ook op delen van de code plaats vinden die relatief veel tijd in beslag nemen.

Dat is de boodschap van de grafiek. Doordat er echter een hele range van optimalisaties wordt behandeld en er misleidend met kleuren wordt gespeeld lijkt het net alsof optimalisaties alleen nut hebben als ze meer dan 10x optimaliseren en meer dan 90 procent in de code doorbrengen.

[RickN]

Mja, ik zie wat je bedoelt.

Dit blijft natuurlijk een kwestie van grafiek kunnen lezen.

edit:
Ik realiseer me nu dat dit een beetje fout over kan komen, zo is het niet bedoelt

Als je waarden bij Speedup_opt=20 gaat vergelijken met waarden bij Speedup_opt=2 ben je natuurlijk appels met peren aan het vergelijken. Als je even de tijd neemt voor de grafiek en weet waar ie vandaan komt dan zou dat toch wel duidelijk moeten zijn, maar ik geef toe dat op het eerste gezicht vooral die speedup 20 eruit springt en dat je daar een beetje mee gaat vergelijken. En idd die kleuring helpt in dat opzicht helemaal niet, maar dat deed Mathematica automagisch. Ik heb zelf vooral te maken gehad met 2D grafieken, met een vaste waarden voor Speedup_opt en die zijn erg overtuigend (iig voor waar ik mee bezig was). Ik dacht: joh, laat ik nou een 3D grafiekje maken met die Speedup_opt ook nog variabel, dat zal er wel cool uitzien . Ik had ff niet door dat voor mensen die dit voor het eerst zien het effect hierdoor iets moeilijker te vinden was.

Ik blijf er trouwens wel bij dat dit een schokkend resultaat is, in de zin van tegen intuïtief.

B.T.W. wat de grafiek WEL duidelijk maakt, is dat het effect van Amdahl's Law groter wordt naarmate Speedup_opt groter wordt. Als je zo naar de grafiek kijkt is ie niet misleidend. Voor mij niet tenminste, maar deze hele discussie zal wel komen doordat dit voor mij erg vanzelfsprekend is. Voor de zekerheid nog maar 2 grafiekjes:

Speedup_opt=2:


Speedup_opt=20:


Zoals je ziet (toch?) is de grafiek bij 2 veel meer wat je intuïtief zou verwachten dan bij 20. Als je veel tijd gaat steken in een SUPER optimalisatie moet je er wel zeker van zijn dat die optimalisatie ook veel gebruikt gaat worden, anders heeft ie minder effect dan je misschien denkt. Kleinere optimalisaties hebben wel het effect wat je er ongeveer van zou verwachten.

[mbravenboer]

RickN: Dit blijft natuurlijk een kwestie van grafiek kunnen lezen.

Mwah niet zozeer, in de statistiek komt het zeer vaak voor dat gegevens zo worden weergegeven dat ze een verkeerd beeld scheppen. De gegevens kloppen dan wel, maar zijn op een of andere manier zo gerangschikt dat je snel in de maling wordt genomen.

In dit geval vond ik dat dus zo: de grafiek ziet er bij een vluchtige blik inderdaad schokkend uit. Als je goed gaat kijken valt dat echter best wel mee.

Als je waarden bij Speedup_opt=20 gaat vergelijken met waarden bij Speedup_opt=2 ben je natuurlijk appels met peren aan het vergelijken.

Klopt, maar grafieken zijn over het algemeen om via een visualisatie een goed beeld te geven van een situatie. Deze grafiek deed dat helemaal niet: het vlak is eigenlijk zinloos.

maar dat deed Mathematica automagisch.

Leuk programma, behalve in dit geval dan .

Ik blijf er trouwens wel bij dat dit een schokkend resultaat is, in de zin van tegen intuïtief.

Mwah, ik vind het wel logisch eigenlijk: als je met de fiets de straat uit fietst en daarna afstapt om een half uur te gaan lopen heeft dat fietsen niet zoveel nut .

is dat het effect van Amdahl's Law groter wordt naarmate Speedup_opt groter wordt.

Dat komt volgens mij omdat je kijkt naar de tijd die het programma in de geoptimaliseerde code doorbrengt. Kijk maar eens naar de grafiek als je kijkt naar de tijd die voor de optimalisatie werdt doorgebracht in die code.

Bij een grote optimalisatie wordt de fractie nogal verkleind, waardoor je rare effecten krijgt in je grafiek...: het trekt helemaal naar rechts.

Voor de zekerheid nog maar 2 grafiekjes

Die zijn duidelijk . Je bekijkt het effect hier bij een vaste optimalisatie en dat is dus duidelijk .

[RickN]

Op zaterdag 02 februari 2002 18:02 schreef mbravenboer het volgende:

[..]
Mwah, ik vind het wel logisch eigenlijk: als je met de fiets de straat uit fietst en daarna afstapt om een half uur te gaan lopen heeft dat fietsen niet zoveel nut .
[..]

Jaha, maar als je driekwart van de weg 20x zo hard gaat fietsen dan je loopt, en dan de rest gaat lopen, zou je toch verwachten dat je er meer dan maar 3,5x zo snel aankomt.
En als je ziet hoe hard sommige mensen van stoplicht naar stoplicht rijden...

Klopt, maar grafieken zijn over het algemeen om via een visualisatie een goed beeld te geven van een situatie. Deze grafiek deed dat helemaal niet: het vlak is eigenlijk zinloos.

Ik vind het vlak niet zinloos, het geeft aan dat de globale effectiviteit van een optimalisatie sublineair schaalt met de kwaliteit van die optimalisatie, tenzij je vrijwel continue van de optimalisatie gebruik maakt.

Wat kun je daarmee? Nou dit:

: Baas?
: Ja?
: Ik heb die ene routine 2 keer zo snel gekregen...
: Oh...
: En als je me nog 2 dagen geeft kan ik em nog wel 2 keer zo snel krijgen...
: mmm...doet ons programma nog iets anders dan die routine?
: euh...ja...
: laat dan maar zitten.

[mbravenboer]

Ach tja, dat zijn meningen, das prima

Kijk hier nog eens naar?

mbravenboer: Dat komt volgens mij omdat je kijkt naar de tijd die het programma in de geoptimaliseerde code doorbrengt. Kijk maar eens naar de grafiek als je kijkt naar de tijd die voor de optimalisatie werdt doorgebracht in die code.

Bij een grote optimalisatie wordt de fractie nogal verkleind, waardoor je rare effecten krijgt in je grafiek...: het trekt helemaal naar rechts.

Het grotere effect bij grotere optimalisaties moet je namelijk ook kunnen relativeren denk ik.

Al met al komt het hier op neer:
het ligt er maar net aan hoe je het bekijkt .

[mbravenboer]

RickN:
: mmm...doet ons programma nog iets anders dan die routine?
: euh...ja...
: laat dan maar zitten.

Domme baas . Hij had moeten vragen hoeveel tijd op dit moment door gebracht in die routine .

Dit bewijst maar weer dat managers slecht zijn .

[RickN]

Op zaterdag 02 februari 2002 18:34 schreef mbravenboer het volgende:
[..]
Het grotere effect bij grotere optimalisaties moet je namelijk ook kunnen relativeren denk ik.

MMM, dat stukje kon ik niet helemaal volgen, kun je iets duidelijker zijn. Maar volgens mij is dat grotere effect toch vrij inherent aan Amdahl's Law hoor. Kijk maar eens naar deze grafiek. (Dit is eigenlijk gewoon die 3d grafiek, maar dan een projectie op het Speedup_eff-Fractie_opt vlak)



Dit zijn de grafieken voor Speedup_opt=2,7,12,17 en 22 in 1 grafiek. Hoe groter Speedup_opt hoe verder je naar rechts moet in de grafiek om b.v. de helft van je "investering" terug te zien...

Zo moet je bij Speedup_opt=22 ruim 95% optimaliseren om daar de helft van terug te zien in Speedup_eff, terwijl dit bij Speedup_opt=7 "maar" 82% is. Dat bedoelde ik met dat het effect groter wordt, bedoelde jij iets anders?

Al met al komt het hier op neer:
het ligt er maar net aan hoe je het bekijkt .

Deal.

[mbravenboer]

Duidelijk grafiekje en stukje .

RickN: Dat bedoelde ik met dat het effect groter wordt, bedoelde jij iets anders?

Dat het effect dramatischer wordt staat natuurlijk vast, daar is geen twijfel over mogelijk .

Het is mijn alleen niet duidelijk of fract(opt) de tijd voor of na de optimalisatie is. Als het de tijd in de geoptimaliseerde sectie na de optimalisatie is, wordt het beeld iets triester dan wanneer het de tijd voor de optimalisatie is.

De fractie die de tijd dan doorbrengt in de geoptimaliseerde code is dan immers een stukje groter (logisch, want is een andere waarde) terwijl de speedup hetzelfde blijft (logisch, want is dezelfde optimalisering)....

[RickN]

Op zaterdag 02 februari 2002 20:11 schreef mbravenboer het volgende:
[..]
Het is mijn alleen niet duidelijk of fract(opt) de tijd voor of na de optimalisatie is. Als het de tijd in de geoptimaliseerde sectie na de optimalisatie is, wordt het beeld iets triester dan wanneer het de tijd voor de optimalisatie is.
[..]

Gelukkig is het de tijd vóór de optimalisatie. Daarom is Amdahl's Law ook een handig hulpmiddel bij het bepalen van welke optimalisaties je gaat proberen te doen. Met profilers kun je redelijk bepalen waar de tijd in een typische situatie in gaat zitten. En het effect van een locale optimalisatie kun je redelijk goed afschatten. Het globale effect kun je dan mooi uitrekenen.

Ik bedenk nu dat ik Amdahl's Law zélf nog niet eens gepost heb. Dus, bij deze dan, voor de geïntereseerden:



Use it wisely

[mbravenboer]

RickN: Gelukkig is het de tijd vóór de optimalisatie.

Ah ok .

Ik kende die Law trouwens niet in deze vorm, anders had ik het wel zelf geweten natuurlijk (kende uiteraard wel de gedachte erachter).

[Battle Bunny]

[afbeelding]

Kun je deze formule even vertalen naar gewoon Nederlands? (Of Engels )