velkost booleanu?

[nou]

[MePHyst0]

je to preto aby boli struktury cache friendly(samozrejme ak sa potom s nimi tak aj nepracuje tak to nema vyznam ) a pekne adresovatelne

[Quiark]

Tuším, že 32bitový procesor je radši, když dostává pěkně 32bitové hodnoty, případně adresy zarovnané na 32 bitů. Podobně to bude asi platit i pro 64bitové procesory.
_________________
Mám strach

[rezna]

[johnnash]

Spis jde o to ze pocitaci ktery ma 32-bitovou adresovou sbernici v pripade ze data nelezi na nasobku 4 bajtu a cteme treba int tak je nutne provest dvakrat operaci cteni.

[MD]

[opice]

K prvnimu dotazu: velikost int neni nedefinovana, jak tu nekdo tvrdil, ale je to vzdy velikost adresace procesoru....
a dale velikost maleho bool je implementacne zavisla, neni definovana ve standardu, pekne pojednani o malem bool a velkem BOOL je zde:

http://www.codeguru.com/forum/showthread.php?t=332831

[Marek]

[opice]

Hmm, tak to nevim. Ale VC++ 2008 ted meni uz velikost int pro 64 bitovy kod na 64 bitu, takze u MS to tak bude. Jinak samozrejme standard o velikosti int nic nerika.

[Marek]

[tempicek]

Mno, nechtel jsem se do toho vkladat, kdyz se tu reklo tolik faktu (ktere uz jsou celkem daleko od puvodniho dotazu ), ale taky se tu reklo par polopravd a par blbosti, tak je asi na case to trochu zrekapitulovat

Podle standardu si muzete byt jisti tim, ze sizeof( char ) == 1 a ze sizeof(short int) <= sizeof(int) <= sizeof(long int). A to je z tehle kapitoly skoro vsechno Takze rozhodne nespolehat na to, ze bool je 1, 8 nebo 32 bitu. A to neplati pouze pro bool, ale pro typy obecne. Hlavne se probuh vyhnete ukladani pointeru do intu a podobnym unix-era zhuverilostem.

Obdobna vystraha plati pro velikosti struktur. struct S { char a; } totiz s nejvetsi pravdepodobnosti *nebude* mit velikost 1 byte! Jak uz bylo receno, aplikuje se na struktury zarovnani zpravidla na 4 byty, ale ani na to se nada sazet! Kdyz si to jooo extra chcete pojistit (treba nacitani struktury ze souboru), tak "#pragma pack" se da pouzit na definovani velikosti zarovnani.
Zarovnava se z mnoha duvodu, jednim z hlavnich je redukce poctu "cache-miss". Pamet (operacni i vyrovnavaci) je totiz take zarovnavana a data nejsou zpravidla ctena po bytech (konkretni velikost je dana architekturou - predevsim velikosti sbernice), ale po vetsich celcich. Tyhle celky byvaji obvykle mocniny dvou, takze je dobre na ne provadet zarovnani polozek v pameti, aby polozky nelezely na rozhrani vice bloku, nez je nezbytne nutne (pokud je blok 4 byty velky, potrebujete na 4bytovou promennou pouze jeden blok, spatnym umistenim muzete vsak zasahnout dva). S tim souvisi i nasobne cteni z pameti (jakekoli! i cache) - spatne umistena data musite nacitat vice instrukcemi. Ale souvisi to samozrejme i s velikostmi registru a jinymi vecmi, ale je tezke zavdecit se kazdemu aspektu architektury ... napriklad registru je v kazde architekture vice a zpravidla i ruznych velikosti, proto se pro ruzne velikosti data pouziji i ruzne instrukce, potazmo ruzne registry ... tim bych se tedy az tak nezabyval, pokud nekodite primo v asm na perfektne definovanou architekturu.

Nevim o tom, ze by se ve VC2008 zmenil int na 64bitu pro 64bitovy compiler; nevylucuji to, ale rozhodne by to neznamenalo absenci 32bitoveho typu - jak uz bylo receno - neni to definovano normou jazyka, takze si to zadefinuje vyrobce kompilatoru.
Rozhodne neplati, ze by byla velikost intu dana velikosti adresace. Takze opet - zadne prasarnicky s pointery!

Zarovnavat rucne - je dobry napad v pripade enumu nebo struktur, kde potrebujete presne vedet co tam kde najdete (opet priklad s nacitanim struktur ze souboru). Obecne bych pred tim opet varoval, nechte to na kompilatoru! Ti kluci vetsinou velmi dobre vedi co delaji a prelozi kod inteligentne pro danou platformu.

Setreni pameti v podobe zhustovani "flagu" do jedne promenne - ok, proc ne, ale s mirou. Pokud jsou to skutecne flagy typu "file attribut" a podobne, ma to svuj smysl. Obecne je ta pamet dnesk vazne levna a nejake skladani promennych dohromady musi mit vetsi opodstatneni nez setreni pameti (napr. rychlost prenosu). Kolik takovych promennych v programu mate? 10 000? Tzn. 40 kB i pri pouziti 32bitove promenne na jednu? Co to je? (Nerikam plytvat, plytvat, plytvat, ale setrit tam, kde to ma smysl - hlavne se vyhnout chybam).

Mno, jeste par veci jsem chtel napsat, ale leniveji mi prsty. Takze jen shrnu - jestli v techhle vecech nemate 100% jasno, vyhnete se jim obloukem a usetrite si cas pri ladeni Pro pokrocile ta varovani samozrejme neplati, tam je namiste spis varovani, aby neprecenovali sve schopnosti

[xtopi]

Já mám C++ tak rád, ale přesně tohle se mi na něm nelíbí - kolik komentářů a textu se napsalo na jeden triviální dotaz....

[niXon]

no samozrejme ze to v podstate nema vyznam, ale vezmite si, ze by ste mali kvantum (ked hovorim kvantum tak obrovske kvantum) hodnot na 1/0, a mate ich poslat cez sietove spojenie? tak tam uz nejde o vykon PC, ale o traffic... tam sa taketo "haluze" zidu ... ked si zoberiete ze z "tradicneho" (vecsinoveho) 32 bitoveho intu urobite 32 hodnot, tak mate 32x znizenie prenosu cez net... to je myslim si ze dost postacujuci dovod aby som sa takymito vecami zaoberal (a nielen ja)

[Ash]

niXon,

Šablóna triedy std::vector<> má špecializáciu std::vector<bool>, ktorá vcelku elegantne rieši problémy s poľom boolovských premenných.

[OndraSej]

niXon> to sice mas pravdu, na druhou stranu delat sitovou komunikaci primym kopirovanim z pameti je jeden z nejlepsich zpusobu jak si zajistit spoustu krasnych problemu. Takze resit, jaka je velikost booleanu v pameti, kvuli ukladani nebo sitim zas tak velky smysl nema
_________________
http://trionteam.net