[LKits]

Tere

Kui on soov kokku hoida ressurssi, siis kas on vahet kas kood on

[Andykas]

Pole päris 100% kindel aga kompilaatori jaoks pole vahet, ta peaks optimeerima nii-ehk-naa sellist koodi. Kui nüüd mõne disassembleriga seda koodi vaadata siis peaks näha olema, et seal on ikkagi kõik jumpid eraldi välja toodud, seega lõpptulemus on ikkagi see, et on mitu rida erinevaid konditsioone ja jumpe, lihtsalt programmeerijal on kiirem/lihtsam/mugavam defineerida neid ühte if-i.

[LKits]

Selge. Seda arvasingi. Igaks juhuks vaatan disassembleriga üle, et kas ikka on nii.

Küsisin, sest tean, et interpreteerimismeetodiga ("tõlgendamismeetod" ehk scripting) töötab just niimoodi, et eraldi tingimused on parem/kiirem variant.

[t]

Konkreetselt selles küsimuses on asi keele standardis fikseeritud.
Kui on jõudluse kysimus, siis üldjuhul on ainuõige korraldada katse (benchmark) ja teha mõõtmisi, mitte püüda oletuste pealt arutleda. Samas pädeva katsetuse tegemine ei ole triviaalne.


Avaldise arvutamisest:

When using the logical operators, C++ only evaluates what is necessary from left to right to come up with the combined relational result, ignoring the rest. Therefore, in this last example ((5==5)||(3>6)), C++ would evaluate first whether 5==5 is true, and if so, it would never check whether 3>6 is true or not.

http://www.cplusplus.com/doc/tutorial/operators/

[LKits]

Väga hästi. Eks pean debuggima, mis tingimus kõigepealt peaks tulema. Mingi loenduriga peaks see igaljuhul võimalik olema.

Suured tänud kiirete vastuste eest.

[mikk36]

&& puhul käiakse nkn kõik if'i elemendid läbi kuna sa ise nõuad seda, || puhul vaid niipalju kui vaja. See peaks igas kompileerijas/keeles kehtima optimeerimimse eesmärgil.

[LKits]

&& puhul ei pea ju kõiki elemente läbi kontrollima, sest kui juba üks tingimus ei kehti, siis pole ju vaja ka edasi liikuda.
|| puhul samuti - kui juba üks tingimus kehtib, siis pole vaja järgmisi kontrollida.

[Ohohh]

Seda, kas tehted tehakse kõik ära või ainult niipalju kui vaja, on väga lihtne kontrollida. Selleks ei pea midagi asmis debugima hakkama
if (foo() && bar()) {
}
Kui foo tagastab false, siis vaatad, kas läheb bar'i sisse või mitte.

[LKits]

Nja... loogiline... peaks ise selliste asjade peale tulema

Igal juhul. Kõigile suured tänud abistamise eest. Eks katsetan nüüd edasi iseseisvalt

[mikk36]

lkits, pidasin silmas kõikide läbi kontrollimise all seda et senikaua kuni if'i läbimine võimalik on. Mitteläbiva tingimuse korral peatatakse edasine kontrollimine tõesti.

[Ho Ho]

Huvi pärast küsin mida see kood sul teeb et niivõrd oluline on tingimuslausete optimeerimine?

Kui nende puhul tahad maksimaalset jõudlust siis oleks kõige mõistlikum teha feedback'il põhinevat optimeerimist. Tean, et nii GCC kui ICC seda toetavad kuid hetkel paraku ei meenu mis parameetritega ning mis selle asja õige nimi oli Igatahes ideeliselt nägi asi välja sedasi, et kompileerid oma programmi ära teatud võtmetega, lased sellel joosta näidisandmete peal ning tekitada koodi täitmise kohta logifailid mille kompilaatorile ette söödad teistkordseks kompileerimiseks. Sellise info järgi saab kompilaator näiteks otsustada millises järjekorras võiksid olla nood if lause tingimused et kõige vähem branch mispredictioneid tekiks lisaks ka posule muudele võimalikele optimeerimistele.

Aga loomulikult enne kui nii low-level asja juurde minna tasuks väga sügavalt järgi mõelda kas optimeerimisel üldse mingi mõte on ning kas asjale lähenetakse õigest suunast. Mina isiklikult pole senise poole elu jooksul progemisel veel kordagi kohanud kus peaks hakkama tingimuslauseid ümber kirjutama kiiruse taga ajamiseks ning ma ei saa väita nagu poleks mul vaja olnud üpriski performance-critical kraami kirjutada.

[LKits]

No juhul, kui ühe tingimusega loetakse miljoneid mälu aadresse läbi, siis on vast ikka vaja neid filtreerida...

[Ho Ho]

[LKits]

Kindlasti annab, aga sain teada, mis soovisin Las ülejäänu olla nii nagu on.

[Ho Ho]

[Fukiku]

[Ohohh]

Te proovite mõelda olukorda keerulisemaks, kui see tegelikult on.

Kui ma õigesti aru saan, siis lkits'il on lihtsalt kaks kontrollitavat tingimust, kus üks on ressursinõudlik ja teine väga kiire. Tema küsimus seisnes selles, et kui ta paneb need ühte if'i järjest, et kas ta saab kindel olla, et keerulisemat ei hakta kontrollma, kui lihtsam annab juba negatiivse.

if (a>b && mingiKeerulineAsi()) {
}

Kus "mingiKeerulineAsi" võib olla näiteks päring andmebaasi poole, mida ei ole vaja hakata tegema, kui a<=b.