Je hebt deels gelijk. Maar momenteel gebruik ik ook nog best een flink aantal OpenCV functies die ik er op termijn uit wil mikken. Voorbeeld hiervan is dat ik met Opencv gelijk een eenvoudige grafische output heb. Andere dingen die ik nu nog gebruik zijn alle gemakken die bij OpenCV zitten zoals resize functie, transpose, floodfill...quote:Op maandag 9 december 2013 10:56 schreef Ai_KaRaMBa het volgende:
Ik mis een betje waarom je uberhaubt met OpenCV matrices aan het werken bent. Je lijkt de matrix te 'misbruiken' als canvas van 320x240 pixels, en daarmee ben je opzoek naar optimalisaties omdat het blijkbaar niet snel genoeg is? Wat doet OpenCV preceis voor je in deze casus?
Ik zou zeggen dat als je een 'echte' canvas alloceerd (aaneengesloten blok geheugen, wat een twee-dimensionale array van (signed) integers representeerd), dat dat veel sneller en overzichtelijker werkt?
[ code verwijderd ]
Maar als die eerste statement leeg is haalt de compiler m weg?quote:Op maandag 9 december 2013 11:00 schreef Gehenna het volgende:
[..]
oh wacht daar heb je gelijk in idd (Ik ben net wakker ), hij gaat bij die 2e natuurlijk de alle statements door als waarde==0. Dan zou idd die eerste wellicht de betere keuze zijn..
Nee ik las verkeerquote:Op maandag 9 december 2013 11:02 schreef Holy_Goat het volgende:
[..]
Maar als die eerste statement leeg is haalt de compiler m weg?
1 2 3 4 | If (A) //Doe niets if(B) DoeIets() |
1 2 3 4 | if (A) //Doe niets else if (B) DoeIets() |
Dat lijkt inderdaad niet te werken. Per rij een pointer fetchen wel. Maar kan aan mij liggenquote:Op maandag 9 december 2013 11:04 schreef Ai_KaRaMBa het volgende:
Ik ken OpenCV verder niet, maar als je daarin integer matrices kan definieren, en je kan idd direct de elementen adresseren (zonder de [] overload bij iedere access aan te hoeven roepen), is dat natuurlijk effectief hetzelfde.
Echter, wat je een aantal posts geleden aangaf, is dat 1 keer een pointer fetchen en de ++en in een loop niet lijkt te werken...
Dat maakt volgens mij niets (of nauwelijks iets) uit. Branch prediction in de CPU zorgt ervoor dat je daar niet op deze manier overna hoeft te denken. (de CPU weet welke jumps er vaak en minder vaak worden genomen, en zal verder 'vooruit werken' in het pad waarin hij denkt te gaan springen.quote:Op maandag 9 december 2013 11:02 schreef Holy_Goat het volgende:
[..]
Maar als die eerste statement leeg is haalt de compiler m weg?
Dat ook nog eens iddquote:Op maandag 9 december 2013 11:06 schreef Ai_KaRaMBa het volgende:
[..]
Dat maakt volgens mij niets (of nauwelijks iets) uit. Branch prediction in de CPU zorgt ervoor dat je daar niet op deze manier overna hoeft te denken. (de CPU weet welke jumps er vaak en minder vaak worden genomen, en zal verder 'vooruit werken' in het pad waarin hij denkt te gaan springen.
1 2 3 4 | if (loopafhankelijkewaarde>iets) { somestatement=true; } |
1 2 3 4 | if (somestatement==false && loopafhankelijkewaarde>iets) { somestatement=true; } |
Tegenwoordig is dat echt niet meer te zeggen. Dit soort minimale veranderingen hebben waarschijnlijk sowieso geen invloed op je runtijd, maar met de optimalisaties die de compiler doet en de optimalisaties die de CPU er nog bovenop doet, is er werkelijk geen zinnig woord over te zeggen.quote:Op dinsdag 10 december 2013 16:01 schreef Holy_Goat het volgende:
Klopt dan de volgende gedachte dat dit 'optimaler' is?
1 2 | If(loopwaarde == iets) Somestatement = true; |
Ik ga dat met zo een profiler eens een keer proberen. Nooit geweten.quote:Op dinsdag 10 december 2013 16:14 schreef Ai_KaRaMBa het volgende:
Wat gs42 zegt. En bekijk ook eens de assembler output van je compiler: dat geeft ook een hoop inzicht in wat er gebeurt en wat bepaalde wijzigingen voor impact hebben.
Om terug te komen op je vraag, doe het zo:
[ code verwijderd ]
Als ik moest gokken, denk ik dat dit het snelste is:quote:Op dinsdag 10 december 2013 16:14 schreef Ai_KaRaMBa het volgende:
Om terug te komen op je vraag, doe het zo:
1 | somestatement |= loopafhankelijkewaarde > iets; |
Profilen moet ik nog even induiken. Lees het een beetje door en ziet er toch ingewikkeld uitquote:Op dinsdag 10 december 2013 16:48 schreef GS42 het volgende:
[..]
Als ik moest gokken, denk ik dat dit het snelste is:
[ code verwijderd ]
Aangenomen dat somestatement een bool is. Zo kan je een branch eruit halen en vervangen door een bitwise operator. Maar zoals ik al zei: geen idee of het werkelijk sneller is. Het zou me ook niets verbazen als een if sneller blijkt te zijn, bijv. door branch prediction. Altijd profilen voordat je iets "optimaliseert".
In ieder geval maak je hiermee je code een stuk minder duidelijk.
De basics zijn best eenvoudig. Je krijgt vrij snel inzicht waarmee je programma het meest mee bezig isquote:Op dinsdag 10 december 2013 16:58 schreef Holy_Goat het volgende:
[..]
Profilen moet ik nog even induiken. Lees het een beetje door en ziet er toch ingewikkeld uit
Netbeans in ubuntuquote:Op dinsdag 10 december 2013 17:03 schreef Gehenna het volgende:
[..]
De basics zijn best eenvoudig. Je krijgt vrij snel inzicht waarmee je programma het meest mee bezig is
Gebruik je een IDE? Wellicht dat deze ook wel wat profiling functies in huis heeft
Nee, het verschil zat in de '==' ipv de '>'. Dat was onder de aanname dat loopvariabbele in stapjes van 1 oploopt (wat vaak zo is). Als je loop dat niet doet, is het waarschijnlijk zo'n complexe loop dat het herschrijven van de conditie toch geen significante optimalisatie is...quote:Op dinsdag 10 dec 2013 16:33 schreef Holy_Goat het volgende:
[..]
Ik ga dat met zo een profiler eens een keer proberen. Nooit geweten.
Wat betreft de 'doe het zo' : dat is toch hetzelfde gewoon als met { } ?
Ubuntu blijkt alleen intern te profilen voor Java.quote:Op dinsdag 10 december 2013 17:03 schreef Gehenna het volgende:
[..]
De basics zijn best eenvoudig. Je krijgt vrij snel inzicht waarmee je programma het meest mee bezig is
Gebruik je een IDE? Wellicht dat deze ook wel wat profiling functies in huis heeft
1 2 | double& angle = Par.Xtion.SensorAngle; double angle = Par.Xtion.SensorAngle; |
In principe maak je er dan een const reference van. Zo geef je aan dat je de waarde niet aan gaat passen en hoef je niet het hele object te kopieren. Bij fundamentele types heeft het maken van een referentie niet zoveel zin, en dus zou ik hier een const double gebruiken:quote:Op dinsdag 10 december 2013 20:36 schreef Holy_Goat het volgende:
Is het over het algemeen beter om optie 2 te gebruiken als je niet van plan bent Par.Xtion.sensorangle aan te passen?
1 | double const angle = Par.Xtion.SensorAngle; |
Oei, kun je me iets meer hier over uitleggen?quote:Op dinsdag 10 december 2013 21:15 schreef GS42 het volgende:
[..]
In principe maak je er dan een const reference van. Zo geef je aan dat je de waarde niet aan gaat passen en hoef je niet het hele object te kopieren. Bij fundamentele types heeft het maken van een referentie niet zoveel zin, en dus zou ik hier een const double gebruiken:
[ code verwijderd ]
De meerwaarde van een referentie is dat je een object zonder te kopieren door kunt geven. Dit doe je (hopelijk) bij functies door `std::string const &` als parameter te hebben in plaats van gewoon een `std::string`. Dit gaat ten koste van een (onzichtbare) indirectie.quote:Op dinsdag 10 december 2013 21:18 schreef Holy_Goat het volgende:
[..]
Oei, kun je me iets meer hier over uitleggen?
Ik volg even de link niet tussen const reference en bv const double.
Dus als ik angle niet aan ga passen in de code, en sensorangle al helemaal niet,
is het dan niet (eigenlijk) hetzelfde om const reference of const double te doen?
+1 voor const na de type, daar hou ik van.quote:Op dinsdag 10 december 2013 21:15 schreef GS42 het volgende:
[..]
In principe maak je er dan een const reference van. Zo geef je aan dat je de waarde niet aan gaat passen en hoef je niet het hele object te kopieren. Bij fundamentele types heeft het maken van een referentie niet zoveel zin, en dus zou ik hier een const double gebruiken:
[ code verwijderd ]
De compiler kan die belofte gebruiken om de boel wat te optimaliseren.quote:Op woensdag 11 december 2013 05:48 schreef Holy_Goat het volgende:
Fungeert die const alleen als waarborg dat je ook echt nergens probeert de waarde aan te passen of is er nog een ander doel mee gemoeid?
Nja, als je gewoon fatsoenlijk je header files bouwt vind ik ze wel beter dan die packet troep in javaquote:Op vrijdag 6 december 2013 21:38 schreef robin007bond het volgende:
Op de een of andere manier gaat OOP mij moeilijker af in C++ dan in Java. De header-files vind ik zo'n zooitje.
Als ik een C+=2 zou maken zouden die header files er definitief uit mogen.
Dat kan in gewoon C++ ook prima. Als je het eens probeert in een iets groter project zie je ook meteen waarom ze beter wel gebruikt wordenquote:Op vrijdag 6 december 2013 21:38 schreef robin007bond het volgende:
Op de een of andere manier gaat OOP mij moeilijker af in C++ dan in Java. De header-files vind ik zo'n zooitje.
Als ik een C+=2 zou maken zouden die header files er definitief uit mogen.
Ik weet dat het kan, maar dan wordt het snel een rotzooitje.quote:Op woensdag 11 december 2013 22:03 schreef trancethrust het volgende:
[..]
Dat kan in gewoon C++ ook prima. Als je het eens probeert in een iets groter project zie je ook meteen waarom ze beter wel gebruikt worden
|
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |