"Kioptimalizálja" a C++ a változómat. Mit okozhatja?

Fórumok

(bocsi de valamiért nincs hosszú i betüm)
Egy klaszterező (meg az alakját is .... ) detektáló algoritmost irok.

Ha "c++ -O0 teszt.cpp" vel forditok akkro a kimenet

A/Az 1802. megtalalt kaszter 2 darab reszecskebol all.
A/Az 1803. megtalalt kaszter 1 darab reszecskebol all.
A/Az 1804. megtalalt kaszter 1 darab reszecskebol all.
A/Az 1805. megtalalt kaszter 1 darab reszecskebol all.
A/Az 1806. megtalalt kaszter 3 darab reszecskebol all.
A/Az 1807. megtalalt kaszter 1 darab reszecskebol all.
A/Az 1808. megtalalt kaszter 1 darab reszecskebol all.
A/Az 1809. megtalalt kaszter 2 darab reszecskebol all.
A/Az 1810. megtalalt kaszter 2 darab reszecskebol all.
A/Az 1811. megtalalt kaszter 1 darab reszecskebol all.
különbözö méretek:776 klaszterek_száma:1811

Ha pedig "c++ -O1 teszt.cpp" vagy bagyobb O2 O3 akkor ez.
A/Az 1795. megtalalt kaszter 1 darab reszecskebol all.
A/Az 1796. megtalalt kaszter 1 darab reszecskebol all.
A/Az 1797. megtalalt kaszter 2 darab reszecskebol all.
A/Az 1798. megtalalt kaszter 2 darab reszecskebol all.
A/Az 1799. megtalalt kaszter 1 darab reszecskebol all.
különbözö méretek:0 klaszterek_száma:1799

Minden paraméter tök ugyanaz.

Jó lenne optimalizálni, mert elég jelentős sebességkölönbséget kapok.
Ezt mi okozhatja?

Hozzászólások

bugos a programod, majdnem biztos, hogy egy valtozot nem inicializalsz

debug modban altalaban inicializalja a valtozokat automatikusan, valami fix mintaval, pl. 0xab, release -ben meg memoria szemet van ott.

Ez inkább vélemény, mint tény, vagy méginkább pillanatnyi állapot.

Az O3 működéséből adódóan nagyobb kódot generál.
Ez néha gyorsabb, de gyakran nem,

Minden más bug. Amit vélhetően szoktak javítgatni. Maximum nem ezek a bugok az elsők. De sehol nincs leírva, hogy az O3 dedikáltan bugos...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

a gcc ilyen szintu optimalizacio mellett bugos
Igen, en is sokszor hittem ezt. Aztan kiderult, hogy megiscsak en vagyok a hulye...:]

-W -Wall nem eleg?
Neha ez kicsit bosszanto is, pl kell melle' a -Wno-long-long. Igaz, a longlong mindig olyan kontextusban kerult elo nekem, ami vegul kulturtipussal archfuggetlenul ki lehetett valtani (size_t, off_t, ...), de ha tenyleg elesben kell direkt longlong, akkor ez szopo.

Ami meg hasznos hordozhatosag szempontbol az a -pedantic es/vagy -ansi.

Rakj fel egy valgrind-et és nézd meg azzal (csak ne felejtsd el előtte debugosra fordítani):


c++ -Wall -ggdb3 -o teszt teszt.cpp
valgrind --leak-check=full --show-reachable=yes --trace-children=yes --log-file=/tmp/teszt.log ./teszt ize hoze 42

Ezután a '/tmp/teszt.log.$PID'-ben keress ilyesmit:


==7972== Conditional jump or move depends on uninitialised value(s)
==7972==    at 0x4068044: vfprintf (in /lib/tls/libc-2.3.6.so)
==7972==    by 0x4070402: printf (in /lib/tls/libc-2.3.6.so)
==7972==    by 0x80483A6: main (teszt.c:10)

A hívási verem jelzi, hogy honnan jön inicializálatlan érték.

A topichoz nincs elsőkörben köze, de ez a topic segített megoldani a problémámat, ezért leírom,
hátha valaki más is belefut!

Szituáció (egyszerűsitve):

a.c


float szamol()
{
  ...
  return 1.26;
}

b.c


  float b = szamol();
  printf("%f\n, b);

eredmény: 42.0

kb két napja keresem, hogy miért nem jó a számolási eredmény!

megoldás: _mindenképp_ meg kell adni b.c -ben az a.c beli függvény
deklarációját (#include "a.h", vagy extern float szamol()), különben
nem tudja visszaadni a helyes értéket ...

már csak azt nem értem, hogy miért pont 42? :)))