- This topic has 80 hozzászólás, 9 résztvevő, and was last updated 16 years, 7 months telt el by
.
-
Bejegyzés
-
És az hardverfüggő, hogy nálam sose adott nan-t, míg a másik két gépen mindig adott? /Mármint ha olyan 10 futtatásból 10 „mindig”-nek számít, nálam pedig ennek jónéhányszorosa/
Persze diff-eket nem néztem, bíztam magamban 🙂És az hardverfüggő, hogy nálam sose adott nan-t, míg a másik két gépen mindig adott? /Mármint ha olyan 10 futtatásból 10 „mindig”-nek számít, nálam pedig ennek jónéhányszorosa/
Persze diff-eket nem néztem, bíztam magamban 🙂uzsolt wrote:És az hardverfüggő, hogy nálam sose adott nan-t, míg a másik két gépen mindig adott? /Mármint ha olyan 10 futtatásból 10 „mindig”-nek számít, nálam pedig ennek jónéhányszorosa/
Persze diff-eket nem néztem, bíztam magamban 🙂Nem mindegy, hogy milyen cpu, nem mindegy, hogy 32/64 bites os, nem mindegy, hogy milyen fordító, sőt még a verzió is számíthat (mivel akár teljesen máshogy is fordíthatja)… a paraméterekről nem is beszélve.
(Persze függ attól, hogy a kód hogy van megírva. Még akkor is lehet eltérés, ha hibátlanul van megírva. Pl. a típusok hossza cpu, os és fordító függő. Még az egész számok bit hossza is változhat.)
Írjad assemblerben 386-ra… az a legbiztosabb. :)))uzsolt wrote:És az hardverfüggő, hogy nálam sose adott nan-t, míg a másik két gépen mindig adott? /Mármint ha olyan 10 futtatásból 10 „mindig”-nek számít, nálam pedig ennek jónéhányszorosa/
Persze diff-eket nem néztem, bíztam magamban 🙂Nem mindegy, hogy milyen cpu, nem mindegy, hogy 32/64 bites os, nem mindegy, hogy milyen fordító, sőt még a verzió is számíthat (mivel akár teljesen máshogy is fordíthatja)… a paraméterekről nem is beszélve.
(Persze függ attól, hogy a kód hogy van megírva. Még akkor is lehet eltérés, ha hibátlanul van megírva. Pl. a típusok hossza cpu, os és fordító függő. Még az egész számok bit hossza is változhat.)
Írjad assemblerben 386-ra… az a legbiztosabb. :)))Jóreggelteket!
Volt olyan régebben, amikor egy-egy prociról felröppent, hogy „rosszul számol”. SZerintem tanulságos lenne – és egy-két „vájtszemű” fórumtárs ki is szúrna valamit benne talán – ha betennéd a /proc/cpuinfo -t a gépekről, jelezve, hogy melyikeken ment, és melyikeken nem ment a programod.
Jóreggelteket!
Volt olyan régebben, amikor egy-egy prociról felröppent, hogy „rosszul számol”. SZerintem tanulságos lenne – és egy-két „vájtszemű” fórumtárs ki is szúrna valamit benne talán – ha betennéd a /proc/cpuinfo -t a gépekről, jelezve, hogy melyikeken ment, és melyikeken nem ment a programod.
vizsla wrote:Pl. a típusok hossza cpu, os és fordító függő. Még az egész számok bit hossza is változhat.Erre figyeltem, mindenhol sizeof van.
gendelider wrote:Volt olyan régebben, amikor egy-egy prociról felröppent, hogy „rosszul számol”. SZerintem tanulságos lenne – és egy-két „vájtszemű” fórumtárs ki is szúrna valamit benne talán – ha betennéd a /proc/cpuinfo -t a gépekről, jelezve, hogy melyikeken ment, és melyikeken nem ment a programod.Szerintem nem ez volt a dolog, mivel több adatsorral is megcsináltam, és mindig nan-t kaptam. Az egyik gép egy Dell laptop, a másik pedig egy HP laptop volt, amin nem működött. Amin működött, egy Cel2Ghz-es desktop, ill. egy Cel300MHz-es laptop.
vizsla wrote:Pl. a típusok hossza cpu, os és fordító függő. Még az egész számok bit hossza is változhat.Erre figyeltem, mindenhol sizeof van.
gendelider wrote:Volt olyan régebben, amikor egy-egy prociról felröppent, hogy „rosszul számol”. SZerintem tanulságos lenne – és egy-két „vájtszemű” fórumtárs ki is szúrna valamit benne talán – ha betennéd a /proc/cpuinfo -t a gépekről, jelezve, hogy melyikeken ment, és melyikeken nem ment a programod.Szerintem nem ez volt a dolog, mivel több adatsorral is megcsináltam, és mindig nan-t kaptam. Az egyik gép egy Dell laptop, a másik pedig egy HP laptop volt, amin nem működött. Amin működött, egy Cel2Ghz-es desktop, ill. egy Cel300MHz-es laptop.
uzsolt wrote:vizsla wrote:Pl. a típusok hossza cpu, os és fordító függő. Még az egész számok bit hossza is változhat.Erre figyeltem, mindenhol sizeof van.
Nem erről van szó. A fordítónál beállítható például az egész (szó) címre igazítás is, ami azt jelenti, hogy a memória foglalás mindig néggyel osztható címre történjen 32 biten, nyolccal osztható címre 64 biten. Ezért egy
Code:for (int i=0;i<1024;i++)
array[i] = malloc (1);valójában nem 1KB mint ahogy sokan hiszik, hanem 8KB vagy 16KB (32/64 bit) foglalását eredményezi. Természetesen -Os esetén 5KB vagy 9KB lesz a lefoglalt méret a mutatótömb nélkül.
Mivel a gcc (statikus foglalás), glibc (dinamikus foglalás) és az OS hármas osztja ki a memória címeket, ezért életszerű az, hogy nálad nem volt NaN, másik gépeken igen mindenféle ellentmondás nélkül. Az is szerepet játszhat, hogy milyen szoftverek futottak előtte, az rk statikus tömb minek a helyét kapta meg.
Az hogy valahol futott máshol meg nem, ne zavarjon meg, a memória hibák általában ilyenek, lappanganak és alattomosak, csak az a biztos hogy mindig kiszámíthatatlan a hatásuk.
Ha valakinek még mindig nem lenne világos, most már szó sincs hardveres vagy lebegőpontos hibáról, az ilyesmi minden „Hello world!” kódnál bonyolultabb forráskóddal előfordul.
uzsolt wrote:vizsla wrote:Pl. a típusok hossza cpu, os és fordító függő. Még az egész számok bit hossza is változhat.Erre figyeltem, mindenhol sizeof van.
Nem erről van szó. A fordítónál beállítható például az egész (szó) címre igazítás is, ami azt jelenti, hogy a memória foglalás mindig néggyel osztható címre történjen 32 biten, nyolccal osztható címre 64 biten. Ezért egy
Code:for (int i=0;i<1024;i++)
array[i] = malloc (1);valójában nem 1KB mint ahogy sokan hiszik, hanem 8KB vagy 16KB (32/64 bit) foglalását eredményezi. Természetesen -Os esetén 5KB vagy 9KB lesz a lefoglalt méret a mutatótömb nélkül.
Mivel a gcc (statikus foglalás), glibc (dinamikus foglalás) és az OS hármas osztja ki a memória címeket, ezért életszerű az, hogy nálad nem volt NaN, másik gépeken igen mindenféle ellentmondás nélkül. Az is szerepet játszhat, hogy milyen szoftverek futottak előtte, az rk statikus tömb minek a helyét kapta meg.
Az hogy valahol futott máshol meg nem, ne zavarjon meg, a memória hibák általában ilyenek, lappanganak és alattomosak, csak az a biztos hogy mindig kiszámíthatatlan a hatásuk.
Ha valakinek még mindig nem lenne világos, most már szó sincs hardveres vagy lebegőpontos hibáról, az ilyesmi minden „Hello world!” kódnál bonyolultabb forráskóddal előfordul.
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz