A jelenlegi adatok alapján a helyzet:
Architektúrák népszerűsége az összes popcon jelentés (129 804 darab) alapján 2013. január 2-án
Architektúrák népszerűsége a "stable"-re szűkített popcon jelentések (73 496 darab) alapján 2013. január 2-án
Jól látszik, hogy kis különbséggel az amd64 vezet. Viszont a fordulat nem most, hanem hónapokkal korábban állt be. Valójában már szeptemberben érkezett egy bejelentés, amelyben az állt, hogy az amd64-nek 51%-a, míg az i386-nak 47%-a van. Azóta az amd64 2 százalékpontot erősödött, az i386 pedig egy százalékpontot veszített. Ha viszont megnézzük ezt a grafikont, akkor láthatjuk, hogy a helycsere valamikor tavaly nyár elején történt.
Bármelyik dátum is igaz, meglepő, hogy az i386 még mindig ilyen jól tartja magát.
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Szerintem egy ideig meg jol is fogja tartani magat. Nekem pl. 3Gb RAM -om van, ami i386 -al meg booooven eleg ( annak ellenere, hogy sok cucc nyitva szokott lenni, de ugye az XFCE nem az ehsegerol hires ), de 64 biten neha szokott swap -olni. Egyelore nem latom ertelmet 4+Gb RAM -nak.
- A hozzászóláshoz be kell jelentkezni
én meg nem tudnék már 8 giga ram alatt élni :)
- A hozzászóláshoz be kell jelentkezni
Nekem ami altalaban nyitva: Chrome ( 5-20 tab ), Firefox ( 1 - 5 tab ), Pidgin, Thunderbird, Netbeans, egy nehany terminal, egy nehany FileZilla, GIMP es megesik, hogy egy Virtualbox ( 1 Gb RAM - Windows 7 ). Ilyenkor meg nem irt semmit a swap -ra. 64 biten, ugyanezekkel nyitva, mar reg lerohadt volna.
- A hozzászóláshoz be kell jelentkezni
"64 biten, ugyanezekkel nyitva, mar reg lerohadt volna."
Miert ?
- A hozzászóláshoz be kell jelentkezni
altalaban 20-30%kal nagyobbak a 64bites binarisok es tobb memoriat is foglalnak ebbol adodoan.
Tyrael
- A hozzászóláshoz be kell jelentkezni
Én így voltam 4-el, de mióta a laptopom nem akart elindulni és kikellett venni az egyik ramot, mert csak így indult el, azóta csak 2 van 64 bites rendszeren, mert nincs időm és energiám újra rakni a Linuxot. De meglepődtem, hogy annyira nem szar, mint amire számítottam KDE-vel. :) Néha virtualboxnál swap-el, de túllehet élni.
---------------------------
Oszt jónapot!
- A hozzászóláshoz be kell jelentkezni
Valószínűleg nagy szerepe van a PAE-nek abban, hogy az i386 még ilyen jól tartja magát.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
johogy! te sem valtottal meg amd64-re, "igy is megy" felkialltassal maradtal a reginel. es voltak meg igy paran.
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
pl. én :)
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
detto... eros vas, 8GB RAM, 32bit PAE
--
Debian Sid Xfce
- A hozzászóláshoz be kell jelentkezni
Egy vélemény PAE-ről: http://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-about-pae/
- A hozzászóláshoz be kell jelentkezni
Nem kell nekem Linus ahhoz, hogy tudjam, a PAE csak egy félmegoldás. Mindazonáltal működik, így majd csak akkor váltok, ha semmi jobb dolgom nem akad.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
A PAE tenyleg jo a felhasznaloknak es a kisebb projekteken dolgozoknak. En is igy hasznalom a fejlesztoi gepemet, azonban multkor bele kellett nyulnom egy nagyobb projektbe es beleutkoztem forditaskor a max memory per process limitbe, amin ugye a PAE nem segit (hiszen az address space adott).
- A hozzászóláshoz be kell jelentkezni
"A PAE tenyleg jo a felhasznaloknak es a kisebb projekteken dolgozoknak."
Miért jó nekik?
--
zsebHUP-ot használok!
- A hozzászóláshoz be kell jelentkezni
Mert anélkül pl. nekem is használhatatlanul lassú lenne a gépem.
--
AGA@
Fork portal és az egyik logóm :)
- A hozzászóláshoz be kell jelentkezni
>Bármelyik dátum is igaz, meglepő, hogy az i386 még mindig ilyen jól tartja magát.
ezt ki mondja?
- A hozzászóláshoz be kell jelentkezni
A kimutatás.
- A hozzászóláshoz be kell jelentkezni
melyik szin/oszlop/akarmi jelzo a meglepetes fokat?
- A hozzászóláshoz be kell jelentkezni
Az elso X64 CPU-kat lassan 10 eve adtak ki, 2003 aprilisaban.
10 ev alatt nem tortent meg a rendes 32 bit-64 bit valtas szoftveres oldalon, pedig a hardvereknel ez igy van: ma mar elenyeszo mennyisegben gyartanak olyan x86 processzort, ami ne tamogatna az x64-et.
A Debianban az X64 tamogatas kozel 6 eve letezik.
Ahhoz lehetne hasonlitani a helyzetet, mintha 6 evvel a 32 bites operacios rendszerek bevezetese utan meg mindig 16 bites kodokat futtatna kozel a felhasznalok fele.
Az elso olyan Windows verzio, ami 32 bites volt, a Windows 95 volt. 2001-ben nem igazan volt 16 bites alkalmazas 50% kornyeki user base-zel.
A 32 bites architektura olyan, mint az IPv4: good enough. Majd akkor valtanak, ha mar nagyon muszaj lesz. Addig viszont szivas van: aki kifogyott az IPv4 cimekbol, az sziv, ugyanigy szivnak a Debian maintainerek, mert a 32 bitet meg mindig karban kell tartani.
- A hozzászóláshoz be kell jelentkezni
oke, de a ki szerint meglepo???
mert trey is meg 32biten van, szal nem tudom ki mondja:)
a forras emailbe nem lattam
- A hozzászóláshoz be kell jelentkezni
Az, hogy trey mit hasznal, semmit nem jelent abbol a szempontbol, hogy megleponek tartja-e a dolgot vagy nem.
O tobbszor leirta, hogy amig neki semmi nyomosabb oka nincs, nem fog valtani
http://hup.hu/cikkek/20120317/frissitettem_oneiric_ocelot-rol_precise_p…
Ettol ot meg meglepheti, hogy milyen sokan gondolkodnak igy. Pedig IT-ben mindig nagy a hype az uj dolgok irant: legujabb verzio a szoftverekbol, legujabb telefon, legujabb technologiak stb. Itt valahogy ez megis elmaradt. Pedig az x64 nem mondhato igazan uj dolognak, 10 eves technologia.
- A hozzászóláshoz be kell jelentkezni
Ha pusztán arról van szó, hogy good enough, akkor is tartsák csak karban, szerintem.
De nem csak erről van szó, a dupla méretű adatok, pl. pointerek miatt rosszabb lehet a CPU cache használat, márpedig az drámaian le tudja lassítani a dolgokat, ld. Ulrich Drepper alapozó műve a CPU és memória témában.
Mivel 4 GB alatt bőven van élet, ezért sok esetben nem indokolt a 64 bit. Csomóan szvsz azért használják, mert pl. az a default install, vagy mert fejlettebbnek hangzik.
- A hozzászóláshoz be kell jelentkezni
"pl. pointerek miatt rosszabb lehet a CPU cache használat"
A 16 altalanos celu regiszter miatt pedig kevesbe kell a stackhez fordulni egy-egy fuggvenyhivasnal.
Ez pedig dramaian tud gyorsitani.
Ugyanigy a nagyobb szamu SSE regiszter.
- A hozzászóláshoz be kell jelentkezni
Ezek biztosan gyorsítanak, de nem vagyok biztos benne, hogy ezek dominálnak egy általános applikációnál. (úgy értem, könnyen lehet, de az összhatást most nem látom kapásból, pláne mivel más részeken meg lassítani tud.)
spekula ON
Kiváncsi vagyok, pl. SSE utasításokat mennyire tesz bele a gcc egy binárisba. Eddig csak specifikus alkalmazásoknál találkoztam vele (pl. kodekek), és ott is külön fordítási vagy parancssori opció, hogy engedélyezzük az SSE használatát.
A függvény lokális változót vajon automatikusan regiszter változóvá optimalizálja a compiler ? (Ha ilyet tenne, az nem lenne multithread safe).
spekula OFF
- A hozzászóláshoz be kell jelentkezni
Ezek biztosan gyorsítanak, de nem vagyok biztos benne, hogy ezek dominálnak egy általános applikációnál. (úgy értem, könnyen lehet, de az összhatást most nem látom kapásból, pláne mivel más részeken meg lassítani tud.)
De igen, 5-10% pluszt jelent.
Kiváncsi vagyok, pl. SSE utasításokat mennyire tesz bele a gcc egy binárisba. Eddig csak specifikus alkalmazásoknál találkoztam vele (pl. kodekek), és ott is külön fordítási vagy parancssori opció, hogy engedélyezzük az SSE használatát.
osx-en peldaul szarasig.
A függvény lokális változót vajon automatikusan regiszter változóvá optimalizálja a compiler ? (Ha ilyet tenne, az nem lenne multithread safe).
Attol fugg, jobbara ha lehet igen, foleg O0 felett. Egy fuggveny lokalis valtozoinak meg tok mindegy hol van, stack-en vagy regiszterben, mert igy is, ugy is thread safe. :)
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
"Kiváncsi vagyok, pl. SSE utasításokat mennyire tesz bele a gcc egy binárisba."
Mivel 64 biten az SSE kotelezo feature (es 32 biten is megvan 1999 ota a CPU-kban), ezert ha olyan march kapcsoloval forditod, akkor bele kellene, hogy tegye.
Peldaul egy march=core2-ben fog hasznalni SSE3 utasitasokat.
Persze aki csak generic i686-ra fordit, akkor nem lesz benne. De miert Pentium Pro-ra forditott kodokat hasznalunk 2012-ben? A mai CPU-k nem csak gyors Pentium Pro CPU-k, tok gaz, hogy igy hasznaljuk oket.
- A hozzászóláshoz be kell jelentkezni
Nálam hasít a Kiwi Linux 12.04.1 LTS a 2x2 GB DDR3 1333 MHz memóriával. Mejjünk kici hajminckétbiteszek jenni. :)
- A hozzászóláshoz be kell jelentkezni
Ezek szerint van, akinek ez működik? Eddig nekem csak az tűnt fel, hogy minden gépen szoktam olyan üzeneteket látni, hogy sikertelen volt a submit, mert akármi. Azt hiszem, nincs MX rekord a popcornhoz, vagy valami.
Még sosem láttam arra utaló jelet, hogy sikerült kézbesítenie bármit.
- A hozzászóláshoz be kell jelentkezni
Ilyeneken másznak félre a kimutatások.
--
AGA@
Fork portal és az egyik logóm :)
- A hozzászóláshoz be kell jelentkezni
"Ezek szerint van, akinek ez működik?"
A jelek szerint... Több mint 120 ezer jelentés alapján készült tegnap a statisztika.
" Eddig nekem csak az tűnt fel, hogy minden gépen szoktam olyan üzeneteket látni, hogy sikertelen volt a submit, mert akármi. Azt hiszem, nincs MX rekord a popcornhoz, vagy valami."
Alapértelmezetten a popcon HTTP POST kérést küld ( http://popcon.ubuntu.com/popcon-submit.cgi ). Az SMTP csak backup és csak akkor kerül használatra, ha a HTTP metódus meghiúsul valamiért.
"Reports are sent by email only when the HTTP submission fails, which is generally caused by a temporary lack of internet connectivity."
Konfiguráció:
/etc/popularity-contest.conf
/usr/share/popularity-contest/default.conf
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
hát akkor majd megnézem. Még az is lehet, hogy az én gépeim is benne vannak a statisztikában akkor.
- A hozzászóláshoz be kell jelentkezni