Az általad használt asztali/laptop gépeken hány bites az operációs rendszer?

Szoftver

Mindegyiken 64 bites
62% (446 szavazat)
A többségén 64 bites
26% (185 szavazat)
A többségén 32 bites
6% (46 szavazat)
Mindegyiken 32 bites
5% (34 szavazat)
Egyéb, alább leírom
2% (12 szavazat)
Összes szavazat: 723

( carlcolt | 2014. 11. 13., cs – 20:15 )

Emlekeztek arra amikor lehozta minden ujsag hogy a Windows 8-bol lesz majd 128 bites verzio? ;)

( iron v | 2014. 11. 13., cs – 20:25 )

Tegye fel a kezét, aki manapság még használ !32 ill. !64bites gépet aktívan.

Windows 8 tabletekben ált 2gb ram van, emiatt csak 32 bit az, ami ajánlott az alacsonyabb oprendszer memória-használat érdekében. Btw 64 bites driverek a gyártó (lenovo) honlapján nem is érhető el. Vsz tudnék hangkártya drivert vadászni, mert a többi fellelhető, de minek a 64 bit?

( DirtY_iCE | 2014. 11. 13., cs – 20:37 )

virtualis gepbe elofordul meg neha 32bites, de amugy sehol. linuxon mar nagyon reg ota csak 64bitet hasznalok, windowson.. na ott meg kb win7 ota (probaltam az xp x64 edition-t is.. de hat, az meg nem allt a helyzet magaslatan)

I hate myself, because I'm not open-source.

( sigellef | 2014. 11. 13., cs – 20:58 )

... lehet, hogy az olcsóbb hardver miatt, de a 64 bites oprendszer határozottan lomhább egy adott gépen. Windows 7-tel volt módomban kipróbálni, 2 magos Intel, 2G RAM mellett. Kb. ugyanaz a helyzet, mint 20 éve a Windows 3.1-nél 486 DX2-n: 286-os módban sokkalta gyorsabb volt, mint 386-os módban.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

( mauzi v | 2014. 11. 13., cs – 21:02 )

Windows fronton az XP -> 7 váltással együtt kampányszerűen megjátszottuk a 64 bitet. Hamár fáj, legalább egyszer fájjon. (A Windows 7-hez úgyis minden driverből és egyéb csecsebecséből teljesen újat kellett telepíteni.)

Linux esetében a Debian 6 -> 7 váltásnál történt ugyanez, szerverek esetében két lépésben:
- első lépésben frissítettük a 32 bites rendszert Debian 6 -> 7-re, hogy a 64 bites átállás esetén ne kelljen még a verzió-eltérésekből származó problémákkal is küzdeni. (konfigfájlok megfelelősége, adatbázisok fájlszinten átmásolhatóak legyenek, stb.)
- második lépésben felépítettünk egy új rendszert az eredetivel megegyező, de 64 bites szoftverekkel, és amikor elkészült, egyszerűen átcsatoltuk oda a felhasználói adatokat tartalmazó fájlrendszereket (már ahol eleve nem NFS-ről jött) majd lekapcsoltuk a régi szervert.

Így születtek újjá olyan szerverek, amelyek még az APT megjelenése előtt lettek telepítve, 2.0 (hamm) óta csak frissítve lettek. A szervereink többsége ugyanis anno. hamm-ra lett (újra)telepítve, mert akkor így volt az egyszerűbb a váltás libc5-ről libc6-ra (glibc2)

( kovi | 2014. 11. 13., cs – 21:09 )

2db 16, 1db 32 és 3-4 64 bites. a gyűjteményi darabokat nem számoltam.

--
Vortex Rikers NC114-85EKLS

( fabian-bros | 2014. 11. 13., cs – 22:24 )

Signed 64bites operacios rendszert hasznalok.
Stack negativ, heap pozitiv

--------------------------------------
Unix isn't dead. It just smells funny.

( Zahy v | 2014. 11. 13., cs – 22:28 )

3 db 64-bites gép és 1 db 32-bites gép, 2+2 felállásban. Ja, és ezek közül a legerősebb az amelyiknek nem kéne, de 32-bites OS-t futtat :-)

( locsemege v | 2014. 11. 14., p – 01:11 )

Telepített gépeken 64 bites oprendszereket használok, viszont 32 bites live image-et generáltam annak érdekében, hogy a live linuxomat őskövület gépeken is legyen esélyem elindítani. Az a virtuális gép is 32 bites, amelyben a live-ot előállítom. Nyilván azért, mert így kényelmes.

A többségén 64 bites opcióra szavaztam.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( uid_4263 v | 2014. 11. 14., p – 07:17 )

Nem tudom az Úr hányadik évében telepítettem utoljára 32 bites gépet. A legutolsó 32 bites hardverem egy AMD Athlon XP-s gép volt. Talán pont 10 éve.

--
arch,debian,windows,android

dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C

( BlinTux v | 2014. 11. 14., p – 08:44 )

Van egy 32 és van egy 64 bites, akkor most mit kell bejelölni? :S
Imádom ezeket a HUP-os szavazásokat... :D

( batyu v | 2014. 11. 14., p – 13:48 )

Ha a kérdés arra irányult, hogy a 64 bites gépeimen 64 bitest futtatok-e, akkor igen, csak azt. Egyébként meg amilyen a vas, pl. a régi kedves motion computing tabletem 32 bites, ergo nincs választás.

( Csab | 2014. 11. 14., p – 17:28 )

64-eseket használok, de szerintem kizárólag annyi értelme lenne a 64 bitnek, hogy programok használhassanak 4G-nál több memóriát.

A Firefoxot leszámítva általában egy alkalmazásnak sincs szüksége 4G memóriára, pláne ha a gépben sincs több. Azért használok 64 bites OS-t, mert 64 bites gépeim vannak, de túl sok extrát nem várok tőle.

A 8->16->32 ugrások látványosak voltak, de mondjuk 128 bites ugrás már szerintem teljesen felesleges lenne.

A hasonlítás azért nem korrekt, mert a sebességnövekedés jelentős, csak az összehasonlítás rossz. Amikor 32 bites kód futtatásáról beszélsz, azt is 64 bites CPU hajtja végre, s ugyanolyan szélesen éri el a memóriát (talán 128 bitesen), ugyanannyit fetch-el egy ciklussal, akár 32 bites, akár 64 bites kódot futtat. Szóval valódi 32 bites CPU-val hasonlítva már nem néhány százalék a különbség.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nézd, Commodore 64-en a videochip a program és a színmemóriát párhuzamosan érte el. Ettől még a gép 8 bites volt és nem 12.

Sőt, bizonyos architektúrákon pl. 64 bitnél jóval nagyobb blokkot látni, ráadásul a caching is megbuherál mindent.
Szerintem egy gép attól még nem lesz 256 bites, hogy a memóriával a processzort 256 + x vezeték köti össze. Maximum gyorsít rajta.

Nehéz fix receptet adni, hogy egy 64 bites gép mitől 64 bites, de ha látod, hogy hogyan viselkedik, tudod hány bites.

Sok a marketing bullsheet a 32/64 bit körül és kevesebb az, aki kételkedőként alapvető vizsgálatokba fogott. Például:

$ uname -m
x86_64

$ cat teszt.c 

#include <stdio.h>

int main() {
    printf("%lu\n", sizeof(int));
    return 0;
}

$ ./teszt
4

Azaz 32 bites az int. Az értekezés további része felesleges.

Tedd hozzá, hogy gcc alatt.

A sizeof(long) 8-at ad vissza 64 biten, míg 4-et 32 biten. A Microsoft fordítója mindig 4 byte-ot használ long-ra, függetlenül attól, hogy hány bites a gép.

Szerintem a fordítót nem érdemes ebbe belekeverni. Annyiban van igazad, hogy az átlag programozó jó közelítéssel 0%-ban használja ki a szélesebb int előnyeit, kivéve a pointereket, melyek valóban 8 byte-osak. És el is jutottunk oda, hogy kizárólag a >4G memória címzése miatt fontos a 64 bit.

Pont ez a lényeg, a pointer. Egyben láthatod ugyanabból a processzból is a > 4 GB RAM-ot. Bár kevés processz igényel egyben ennyit.

Ellenben ha a processzek darabjainak elég 2 GB alatti RAM, akkor a kernel a memória belapozgatással megoldja a dolgot 32 bit + PAE segítségével.

Régebben pályán levők emlékeztek még a DOS 16 bites szegmentált címzésére? Ott is belapozgatta a 64 kB-os szegmenseket. Ráadásul 16 byte-os lépésekben tudtad kijelölni.

Továbbá EMM386 is egy trükk volt: a szegmentált címzés által kicímezhető 1 MB-os terület egyik részébe belapozta ha jól emlékszem 256 kB-onként az 1 MB feletti memóriaterületet.

Az int méretéről: bár a régi definíció azt írta, hogy az int mérete az architektúra bitszámával egyezik. Érdekes módon a 32 bitet általános esetben nem vitték feljebb GCC esetén.

Ennek több gyakorlati oka van. Egyik legfontosabb oka, hogy a különböző méretű INT-ek esetén félő sok szoftvernél a fájlba írt illetve a TCP/IP-n átadott adatstruktúrák inkompatibilitása. Másrészt lassabb a 64 bites összeadás a 32 bithez képest, vagy sokkal költségesebb a carry gyors felterjesztése miatt az összeadó.

Csak erre reagálok:

"Az int méretéről: bár a régi definíció azt írta, hogy az int mérete az architektúra bitszámával egyezik."

Ezt hol írák? Én az eredeti Kernighan & Ritchie -féle könyvben nem emlékszem ilyesmire, kizárólag arra, hogy short kisebbegyenlő int kisebbegyenlő long. Pont.

Igaz. Nem definíció szerint kőbevésve, csak "tipikusan" és nem a bitszámával, hanem a "gépre jellemző" módon.

Kernighan & Ritchie: int egész szám, amely tipikusan a befogadó gépre jellemző egész szám ábrázolási méretet tükrözi. (2.2. Adattípusok és méretek; forrásnyelven: int an integer, typically reflecting the natural size of integers on the host machine)

Én még baromi jól emlékszem, amikor volt a készletben egy DEC Alpha is, és arra kellett open source progikat lefordítani... hogy hány akadt fenn a sizeof(int)=8-on, azt inkább nem ecsetelném... nagy szopásfaktor volt, na. Nem véletlen, hogy az ILP64-et senki más nem erőltette.

Nekem itt olyat ír, hogy

"First released in Issue 6. Included for alignment with the ISO/IEC 9899:1999 standard."

Szerk: Ráadásul az MS-nek nincs C fordítója, az MSVC C++ fordítót tartalmaz, ahol csak a C++11-ben lett a szabvány része.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mert C-ben manapsag biztos lehet az ember, hogy mire fordul (egyebkent a lényegi reszt irtam). Sot. Biztos lehet abban, hogy a lefordított kod hogyan,fog vegrehajtodni az adott mikroarchitekturan... (P1 ota maximum saccolhat az ember).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Sajnos emlékszünk a szegmentálásra, far/huge/near pointerekre és az összes többi bullshit-re.

Egy rohadt tömböt nem tudtál deklarálni 64k felett, hanem mindenféle huge baromságokkal kellett szórakoztatnod magadat, ellenkező esetben a pointer a 64k feletti részeknél körbefordult.

Becsületére váljon az AMD-nek, hogy 32-bitről 64-bitre emelte a címbusz méretét, ahelyett, hogy ezeket a frappáns trükkös megoldásokat újra felfedezte volna.

Commodore 64 után, amikor a 64k már nem volt elég, a processzorokon növelni kellett volna a címbusz méretét 16 bitről 32-re (esetleg 24-re), ahelyett, hogy a szegmentálás című fusi baromságaikat elkezdték volna.

Azóta már szerencsére felnőtt egy generáció, aki képes volt folyamatában tekinteni a dolgokat és a hasonló trükkös megoldások egyenesen a kukába kerültek. Amikor a 32 bites architektúrát megcsinálták, az egyetemen még valószínűtlennek tartották, hogy valaha e fölé kell menni, mert akkortájt egy komplett szoba is kevés lett volna ekkora tár elkészítéséhez.

Legalább annyira volt akkor valószínűtlen, mint ma a 64 bit túllépése.

Ha jól gondolom, arról beszélsz, hogy az operandusokból azonnal képezzük az átvitelt, vagy aszinkron, de soros módon, ahogyan az alsó bitről terjed felfelé. Azt, hogy ez előbbi került megvalósításra, azzal a vélelmezéssel állítható, hogy feltételezzük, 1 T ciklus alatt sorosan nem tud végighaladni a CY. Ami persze jó eséllyel igaz. A másik feltételezés, hogy regiszterek közti művelet közvetlen, nem használnak pipeline-t.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE