Forráskód nem hordozható?

[uzsolt]

É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]

É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 🙂

[pointux]

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. :)))

[pointux]

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. :)))

[gendelider]

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.

[gendelider]

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.

[uzsolt]

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]

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.

[gabaman]

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.

[gabaman]

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.

[Szerző]

Bejegyzés