Az amd64 a Debian legnépszerűbb architektúrája (a popcon szerint)

 ( trey | 2013. január 2., szerda - 14:09 )

A tegnapelőtt kiadott Debian Misc Developer News 31. számában Paul Wise bejelentette, hogy a Debian Popularity Contest (röviden "popcon") adatai szerint a Debian legnépszerűbb architektúrája immár az amd64. A bejelentés helyes, csak negyed/fél évet csúszott attól függően, hogy honnan nézzük.

A jelenlegi adatok alapján a helyzet:

Debian popcon - összes jelentés @ 20130102
Architektúrák népszerűsége az összes popcon jelentés (129 804 darab) alapján 2013. január 2-án

Debian popcon - stable @ 20130102
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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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.

én meg nem tudnék már 8 giga ram alatt élni :)

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.

"64 biten, ugyanezekkel nyitva, mar reg lerohadt volna."

Miert ?

altalaban 20-30%kal nagyobbak a 64bites binarisok es tobb memoriat is foglalnak ebbol adodoan.

Tyrael

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

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

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!

pl. én :)

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

detto... eros vas, 8GB RAM, 32bit PAE
--
Debian Sid Xfce

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 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 PAE tenyleg jo a felhasznaloknak es a kisebb projekteken dolgozoknak."
Miért jó nekik?
--
zsebHUP-ot használok!

Mert anélkül pl. nekem is használhatatlanul lassú lenne a gépem.
--
AGA@
Fork portal és az egyik logóm :)

>Bármelyik dátum is igaz, meglepő, hogy az i386 még mindig ilyen jól tartja magát.

ezt ki mondja?

--
http://blog.sartek.net | https://twitter.com/sartek

A kimutatás.

melyik szin/oszlop/akarmi jelzo a meglepetes fokat?

--
http://blog.sartek.net | https://twitter.com/sartek

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.

oke, de a ki szerint meglepo???
mert trey is meg 32biten van, szal nem tudom ki mondja:)
a forras emailbe nem lattam

--
http://blog.sartek.net | https://twitter.com/sartek

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_pangolin-re?comments_per_page=9999#comment-1436176

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.

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.

"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.

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

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

"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.

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

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.

Ilyeneken másznak félre a kimutatások.
--
AGA@
Fork portal és az egyik logóm :)

"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

hát akkor majd megnézem. Még az is lehet, hogy az én gépeim is benne vannak a statisztikában akkor.