"Amit minden programozónak tudnia kellene a memóriáról"

Programozás

A Red Hat alkalmazásában álló Ulrich Drepper elérhetővé tette egy darab PDF képében azt a cikksorozatot, amely az LWN-en nemrég még csak a előfizetők számára volt olvasható. A cikksorozat és a dokumentum címe: "Amit minden programozónak tudnia kellene a memóriáról". A dokumentum 114 oldalas, 900 KB méretű. Letölthető innen.

( mrev | 2007. 11. 24., szo – 11:11 )

Ezek azok a dolgok, amikről egy programozónak nem kell tudnia. Ha a cím igaz volna, akkor nem volnának, és nem is lehetnének programok. Nyilván nem programozó a pofa.

--
CCC3

Nem teljesen értek egyet veled. A programozók egy részének szüksége van rá. Azoknak, akiknek teljesítményorientált dolgokat kell készítenie. És itt most nem az übergiga 100 GL eszközökkel dolgozókra gondolok elsősorban, hanem azokra, akik alájuk rakják a rendszert.

szerk.: Ez az a felfogás, amiért olyan az M$ világ amilyen.

Az a baj, hogy nem tudod eldugni. Sokan, regota probaljak, de nem megy. Itt-ott felbukkan, keresztbetesz, es akkor az average hatulogombolos RAD programozo nem tud vele mit kezdeni. Pedig minimalis dolgokra kene figyelni fejleszteskor, hogy egyaltalan el se kelljen dugni...

Szoval en ahelyett h. eldugnam, oktatnam. Vegulis a programozoknak illene tudni, legalabb nagy vonalakban, hogy a programjuk mit okoz, melyen a rendszerben, amivel dolgoznak. Ezert fizetik oket, fizetnek minket.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Látom, hogy az okosok között felháborodást váltottam ki. Árnyalom azért a képet. Rendben van, érdekes a dolgozat. Talán kernel programozóknak nem is káros.

Csakhogy a társadalom működése többezer éve a munkamegosztáson alapul: nem foglalkozik mindenki mindennel.

Bizonyos dolgokról bizonyos helyzetekben káros tudni. Pl. ha programozó vagy, és ismered a memóriák működését (cikk), és sikerül írnod egy olyan programot, ami csak ilyen vagy olyan memóriával működik, akkor az egy rossz program.

A programtervezők nagy erőfeszítéseket tesznek azért, hogy a programok különböző részei el legyenek egymástól (és a hardvertől) szigetelve, lehetőleg minél kevesebbet kelljen tudniuk a környezetükről. Ez egy fontos és hasznos alapelv. A cikk címe ennek ellentmod, tehát hülyeség.

Az MS mentalitásnak ehhez semmi köze.

--
CCC3

Hát én már csak így hasogatok.

Természetesen, az első postom előtt átnéztem a dokumentumot, hátha van benne valami, amit programozóként hasznosíthatok. Lehet, hogy van: Érdekelne pl. hogy többszálú programban egy szál hogyan értesül egy másik CPU-n futó másik szálban történő változásokról. Fenntartom viszont, hogy ezekről a dolgokról nem kell minden programozónak tudnia.

Amúgy mérnöknek vagy fizikusnak nézem a pofát. Szinte biztos, hogy nem programozó. Targoncája is lehet:)

--
CCC3

"Pl. ha programozó vagy, és ismered a memóriák működését (cikk), és sikerül írnod egy olyan programot, ami csak ilyen vagy olyan memóriával működik, akkor az egy rossz program."

Akkor irjuk át a video dekódereket PHP-be, mert hogy az "portabilis". Mert ugye rosszak, mert rendszerint optimalizálva vannak egy hardverhez.

Igenis, vannak dolgok, amiket nem árt betartani még ha magas szintű nyelvben programozik is az ember. Pl. egy struct-ban a nagyon használt változókat közel tenni egymáshoz és lehetőleg az elejére.

Látom nem olvastad el a cikket. (Még én se :) )

pl. (DDR)SD burst mode,..,.. szinte minden eszközön használt, pár constans érték (méretek) ami más lehet. Ha figyelembe veszed a memória ilyen tulajdonságait, egy rendszeren egy másik rendszeren is optimálisabb lesz mintha nem vetted volna figyelembe, az másik kérdés, hogy optimumot ott nem éri el, de jobb lesz mint nélküle.

set_mempolicy() nélkül vagy jól alkalmazva egy NUMA rendszeren teljesítményben óriási változás állhat be. (Talán tudok olyan kódot generálni ahol kb. 4x sparc T2 -n)

Cikkben szereplő dolgok nem platform függőek, más gépen max. nem lesz gyorsabb, de nem kell újra írni.

"A programtervezők nagy erőfeszítéseket tesznek azért, hogy a programok különböző részei el legyenek egymástól (és a hardvertől) szigetelve, lehetőleg minél kevesebbet kelljen tudniuk a környezetükről. Ez egy fontos és hasznos alapelv. A cikk címe ennek ellentmod, tehát hülyeség."
Ez a magatartás természetem ellen val. OO -ellen irányuló baszogatásaim ez ellen szolnak, holott pl. C++ is gyakran figyelembe lehet venni ilyen tényezőket még OO elemekkel együtt is.

Ahamm. Pl. azt sem kell tudnia, hogy

"...the binary must have permission to change the access permissions for the memory page to include writing and then back to executing."

Ami súlyos biztonsági problémát jelenthet.

http://people.redhat.com/drepper/textrelocs.html

ugy latom masok mar leosztottak elottem.
Igy rovidre fogom:
Ha ezeket a dolgokat legalabb feluletesen nem ismered, akkor te fogod irni azokat a progrmaokat, amik tipikusan 2 het alatt futnak le 2 ora helyett.

Mivel valsz e kijelentesed ota remelhetoleg elolvastad, nem tepem tobbet a szam.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Csatlakozom.
Igaz koca és hobbi programozó vagyok, de nem tudok ilyen hozzáállást elfogadni.
Egy példát mindjárt közzé is tennék, igaz nem memórikezelés, de jól szemlélteti a hardverek nem ismerésének problematikáját.
Történt a 90-es évek elején, mikor még a scientific american-nak jelent meg magyar fordítása.
Fent említett folyóiratban volt egy rovat, amelyben érdekes matematikai szösszeneteket tárgyaltak ki viszonylag gyakorlatias szempontok szerint.
Egyik ilyen a Ljapunov térrel foglalkozott, és volt benne egy rövid útmutató, hogyan írhatunk Ljapunov-féle képeket előállító programot.
Nosza én nekiálltam, és megírtam saját kis programomat, nem emlékszem már, hogy 386-osom volt coprocival, vagy a 486DX-em, de meglehetősen lassan futott le a progi (640x480-as kép 1-1,5 nap alatt).
Az algoritmusban 1 db logaritmusszámítás van, amit illik képpontonként legalább 1000x lefuttatni. Ez Turbo pascalban x2-őt jelentett + egy osztást, mivel, ha jól emlékszem csak 10-es alapú log volt benne, nekem meg természetes, vagy 2-es alapú kellett.
Akkortájban vettem meg - ha jól emlékszem a címére - 386-os processzorok belső felépítése című kiadványt. Ebben elmélyedve látom, hogy az fpu tud 2-es, meg természetes alapú logaritmust. Ekkor megvilágosodtam, és rájöttem, hogy pont 3 logaritmusszámítással, és 3 osztással többet csinálok ciklusonként, mint kellene. Természetesen a futási idő nagy részét a log számítás tette ki.
Ezek alapján egy prog. nyelvet sem tudok elképzelni, ahol ne lenne haszna annak, hogy ismeri az ember a hardvert, az alacsony szintű funkció megvalósításának módját, vagy egyéb nem egyértelmüen hasznosnak tűnő dolgokat.

( ProTech | 2007. 11. 24., szo – 15:03 )

Nagyjabol atlapoztam, de most nincs idom egy 100 oldalas doksit elolvasni. Es hirtelen nem lattam semmi olyan dolgot amire szuksegem lehetne. Az latszik, hogy nagyon jo cimet valasztott, mar miota errol megy a flame :) Egyszer azert lehet elolvasom, ha tobb idom lesz ra.

Szerintem at lehetne nevezni a cikket arra, hogy "Amit minden Asm/C/C++/Pascal programozonak tudnia kellene a memoriarol."

Nem hiszem, hogy egy java/C#/perl/python/php programozo tul sok hasznos informacioval okosabb lenne.

Bocs, nem volt szándékomban flamet kavarni.

Megjegyzem azért, hogy ezeket a dolgokat általában a C/C++/Pascal programozóknak sem kell tudnia. Akinek mégis tudnia kell, az megnézi az ilyen cikkekben, mint ez. Nem is mondtam semmi rosszat a dolgozat tartalmáról. Az asm-ról annyit, hogy 1000 közül 1 programozónál sem indokolt, hogy assemblyt használjon.

Nem akarom cikizni a srácot, szimpatikus fiú, csak a cím melléfogás. Kicsit nagyképű. Inkább ez kéne: Mi az, amit eddig megtanultam a memóriáról? Nem gondolt rá, hogy a programozók sokfélék. PHP kóderek ritkán töprengenek kondenzátorok feszültségátviteli karakterisztikáin. Ezért gondoltam mérnök-fizikusnak a srácot. Programozók inkább API-kban gondolkodnak.

--
CCC3

ezeket a dolgokat általában a C/C++/Pascal programozóknak sem kell tudnia
Azert ez igy tulzas. csak egy pelda, amit igy fel perc atolvasas utan rogton kiszurtam, pl hogy hogy me'sz vegig egy matrixon: sorfolytonosan vagy oszlopfolytonosan. a ketto" kozott lehet hatekonysagban egy 2-4x-es szorzo. Raadasul en pont ekkora meretu" matrixokkal dolgozom mostanaban (2k x 2k, 4k x 4k) ;). Es akkor felmerulhet a kerdes, hogy hogy optimalizalhatsz jol, ha a sor/oszlopfolytonos ciklusok kozott nem donthetsz szabadon, az implementalando algoritmus tulajdonsagai miatt. Es ha az embernek egy ilyen tipusu futasra mondjuk nem 1 hetet kell varnia, hanem mondjuk 2-3 napot, akkor megeri kicsit gondolkodni.

Satobbi.

A.

em hiszem, hogy egy java/C#/perl/python/php programozo tul sok hasznos informacioval okosabb lenne.

Az a baj, hogy a nyelvek kozott nagy az atjaras. Es tapasztalat, hogy aki sokaig nem tanulja meg az ilyesmi kezeleset, annak kesobb is megmaradnak a rossz berogzodesek, ha esetleg mas nyelvben kell programoznia (marpedig ez egy bizonyos szint felett eleg surun elofordul).

Mas kerdes, hogy a Perl, Piton es PHP-szeru izeket en joindulattal is csak scriptelesnek hivnam, nem programozasnak... Kb. mint a HTML programozas c. okossag. Attol is feltor bennem a vinnyogva rohoges. De ez mar egy eleg messzire vezeto vita lenne, es elismerem, hogy szelsosegesek a nezeteim. :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Rohadtul nem errol beszeltem, de nem baj. :) Egyebkent en Plus/4 es C64 BASIC-cal kezdtem, es csak kesobb x86-on tanultam meg eloszor assemblyben, szoval errol ennyit. :) (Aztan kesobb irtam par nagyon egyszeru szosszenetet 65xx-re is asmban, de azokat nem rakom ki az ablakba inkabb... :P )

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Szerintem minden programozasi nyelvnek megvan a maga helye. Nalam kb igy nez ki a dolog: egyszerubb dolgok: bash, kicsit bonyolultabb scipt: perl, valami webes cucc: php, esetleg perl ha nagyon egyszeru. Bonyolultabb program: java. Ha GTK+ GUI kell: C#.

Szerintem sokkal egetobb dolog a mai programozoknal, hogy nem nagyon tudnak tobb szalu programokat irni. A memoriakezelest eleg jol elrejtik mar a nyelvek a programozo elol. Java-ban, vagy C#-ban nem nagyon volt problema ilyenekbol. Az igazsaghoz hozzatartozik, hogy egy memleak-et lattam mar C# alatt, de ez kuriozum :D Viszont multithreading miatt mar rengeteget szoptunk. Tudod amikor 3 nap debug utan felcserelsz ket sort es utanna mukodik az egesz. Most, hogy elegge elterjedtek a dual es lassan quad core processzorok ez egyre egetobb dolog lesz. Megprobalok nezni egy HD felbontasu filmet mplayer-el, az Ati kartya miatt nincs hardware-es gyorsitas, ezert szaggat a film, ha megnezem a prociterhelest 50%-on van ami azt jelenti, hogy a ket procibol az egyik idle, a masik meg kikopi a belet...

"Mas kerdes, hogy a Perl, Piton es PHP-szeru izeket en joindulattal is csak scriptelesnek hivnam, nem programozasnak..."

Majd ha átnézted mondjuk a pychess Python-ban megírt sakkmotorjának rotated bitboard-os táblareprezentációját, vágási algoritmusait és kiértékelőfüggvényét, akkor kiváncsi leszek, hogy ezt fenntartod-e még.

"Mas kerdes, hogy a Perl, Piton es PHP-szeru izeket en joindulattal is csak scriptelesnek hivnam, nem programozasnak."

A PHP az fair, mert az csak egy ocska tulnott templating engine.

Viszont a Perl es Python programnyelvek, persze lehet bennuk scriptelni is.

Egyszeruen Perlben az igenyek egy resze script formaban fejezodik ki, de ez kozel sem jelenti azt hogy nem hasznaljak komoly helyeken. Most igy eszembe jut hirtelen a BioPerl, vagy mondjuk egy Amazon.com-os rendszer amit mar nem igazan hivnek scriptelgetesnek. De talan ha megemlitem hogy SpamAssassin, az szerintem mar kierdemelne a program nevet.

Csak szintaktikai szempontbol: a Lisp 7 meghatarozo motivumabol a Perl tud 6-ot. A C egyet.

comet
Perl Programozo

"Nem hiszem, hogy egy java/C#/perl/python/php programozo tul sok hasznos informacioval okosabb lenne."

Ezt hadd kerjem ki a valamirevalo Perl programozok neveben...

Aki meg nem hasznalt pack/unpack/vec fuggvenyeket, vagy nem optimizalt rendesen az termeszetesen nem tudja hogy miert lenne ilyesmire szukseg.

( xilu | 2007. 11. 24., szo – 16:00 )

bocsi de ezt a PDF.t csak én nem tudom megnyitni?

( tr3w v | 2007. 11. 24., szo – 16:32 )

Emberek... Olvassátok már el a cikke(ke)t...

Lehet, hogy itt mindenki csak olyan programokat ír, aminek mindegy, hogy 1 vagy 100 másodperc alatt fut le, de szerintem a programok többségénél nem mindegy.

Nagy különbség van aközött hogy valaki programozik, és aközött, hogy valaki programozó.
A programozónak igenis tudnia kell ezekről a dolgokról, még ha esetleg nem is ennyire részletesen. Egyszerűen megkerülhetetlen.

Pl. még egy Java programozónak sem mindegy, hogy egy tömböt merre jár be, feltéve, hogy nem akar lassú kódot írni.

Egyébként pont emiatt a "ezt nekem nem kell tudnom majd a fordítóprogram elintézi" hozzáállás miatt van annyi szörnyen lassú program. És pont emiatt szídja annyi ember a Java-t, pedig sok esetben csak a programozó a béna...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Egyetértek. Nem véletlenül az a címe, ami, tényleg kéne tudni ezeket minden proramozónak.

Sajnos tényleg sok félidióta programozó egyszerűen nem hajlandó tudomásul venni, hogy a programja egy hardveren fut, bármennyire is virtualizáltan.

Java programozóknak üzenem, hogy a sebesség-problémáik nagy része megoldható lenne, ha lenne fogalmuk a cikkben írtakról.

Érdemes elolvasni pl. amiket a cache működéséről ír a faszi. Nagyon könnyű ugyanis olyan többszálú progit írni, ami gyakorlatilag egyáltalán nem skálázódik, akárhány procin is futtatod. És ez a javásokra is vonatkozik, bálmannyire is ott van a GC, ami "mindenről" gondoskodik.

Nagyon fontos témák vannak még a cikkben, amiket ha programozóként nem ismersz, te is szépen elsüllyedsz majd a buta középszerű biorobot programozók közé, akikre csak konkrét metódusok lekódolását merik bízni speckó alapján.

( meditor | 2007. 11. 24., szo – 17:05 )

A cikkben lévő információk sok esetben hasznosíthatók. Viszont
a "minden programozónak" kitétel túlzás. Persze lehet, hogy csak
a "programozó" szót értjük félre sokan.

Ajánlom MINDEN programozónak: Nemes Mihály: sebesség a
számítástechnikában. Ajánlom továbbá: nézze meg milyen
assembly kód fordul a programjából.

> Sol omnibus lucet.

igen. anno, amig javaba fejlesztettunk 3d enginet (jah, eleg orulten hangzik, en is azt mondtam, de erre volt igeny) irtam is egy java disassemblert, hogy lassam hogy forditja le a kodot a compiler, es tudjak optimalizalni rajta... nem art amugy megnezni, utana jobban erti az ember hogy pl. mi tortenik a hatterben pointer atadassal es mi masolassal, ami azert eleg jelentosen befolyasolja egy java program sebesseget. (gyk: javaban is van pointer, csak object-nek hivjak :) ha object-kent adsz at valami parametert, az pointer szerint lesz kezelve es nem a tartalma masolodik)

A'rpi

ps: ftp://thot.banki.hu/esp-team/linux/JDisAsm-1.0.tar.gz

A byte kod egy dolog de az megsem gepi kod. A class-okbol eleg jol viszafejtheto maga a java forras. Szinte csak a konstansokat helyettesiti be, illetve a lokalis valtozok nevei eltunnek. Vannak mas apro elteresek is, de ez eleg mesze van az assembly-tol. Ez ertheto is mivel ugyanaz a kod fut sparc-on mint x86-on.

A java memoriakezelese eleg fura. Egyszer probaltam memoriafelhasznalast csokkenteni java progiban, hat nem egyszeru. Foleg a String-ekkel trukkoznek sokat.

Előre is elnézést kérek mindenkitől. "Programozó" - ez vmi szakembert jelent, és elvárható, hogy ismerje a szakmáját.
A háziorvos nem oprál, de tudnia kell, hol van a máj, vese.
A programozónak meg ismernie kell a hardware-t, amin a programja futni fog. Nem hinném, hogy egy-két-három nyelv ismerete és a fejlesztőeszköz felületének ismerete jó programozóvá tesz valakit. Írhat persze jó programot, ha egy területre specializálódott, de azért ez mégsem minden.
Sajnos tényleg elfajult a helyzet, a program mérete, sebessége lassan senkit nem érdekel. Kis túlzással meg azt mondhatnám, az a cél, hogy a programozó jobb kezének mutatóujja se legyen túlterhelve. Ez részben annak (is) következménye, hogy a számítógép=pc, a szórakoztatóipar része, és nem olyan funkciókra használják, mint amire eredetileg ki lett találva. Közben azért nem szabad elfelejteni, hogy a "programozó" szakma eredeti jelentése mi volt.

Sajnos ez nagyon igaz... utobbi idoben az a nezet divik, hogy gyorsabban fejlodik a gepek teljesitmenye mint amennyi ido alatt optimalizalni lehetne ra az adott kodot.
(amiben amugy lehet valami, az mplayer codeceket anno evekig optimalizaltuk, es ugyan amikor elkezdtuk meg csak a nagyon eros gepeken futott, de mire leoptimalizaltunk mindent, mar az optimalizalatlan kod is boven elment az akkori atlag pc-ken)

Ezert is irjak amugy a windozt es a legtobb jatekot is az epp elerheto legbikabb gepre, hogy amire elkeszul es letesztelik, az mar ugyis az atlag pc lesz.

A'rpi

Ha ezzel arra akarsz celozni, hogy a meret aranyos a program optimalizalatlansagaval, akkor tanulj meg programozni.
Persze lehet meretre is optimalizani (en is irtam nem egy 256byte es 4k introt anno), de az mplayer sebessegre van optimalva, nem meretre.
(lasd meg: ugyanaz a kod gcc -O3 es -Os opciokkal forditva)

Hogy az mplayer miert akkora, na az egy jo kerdes. Meg sose gondoltam bele, de nehany tipp:
- ha --runtime-cpudetect -el van forditva, akkor pl. az osszes asm cucc benne van minden cpu-ra kulon optimalizalva
- a libavcodec alapbol minden optimot tartalmaz, es runtime valaszt, fuggetlenul a --runtime-cpudetect kapcsolotol
- rakas konstans adat tabla van a kulonbozo codecekhez
- sok hasznos es haszontalan feature
- millio statikus lib beleforditva
- gondolom a neu-team beleforditotta a sajat fotoit :)
- el van rejtve benne egy 3d-s passziansz es egy repuloszimulator. ha excel filet jatszol le vele, kiprobalhatod :)))

ettol fuggetlenul a default tenyleg nem kicsi, bar lehet par 100k-sat is forditani belole, nekem sikerult, amikor arra volt szukseg, persze erosen reduced feature settel...

A'rpi

ps: az openoffice miert akkora? vagy az x11? a kde-t ne is emlitsuk.

Bocs, ha tamadasnak vetted , nem annak szantam. (Tul nagy kod meret meg artalmas lehet (cache miss -ek), de ez most mindegy)

Nem x86 neztem, (--runtime-cpudetect, igy remelem alabol kilove) es kurva sok feature nelkul (5 sor disable), elsore valami 4Mb -lett, 8Mb memoria van a cel szutyban (igy is, ment a film :)). Haver par CFLAGS es LDFLAGS + disable sereggel nezte ugy lett talan 2.7Mb. De azt mondja van meg mit disablezni.

Konstans tabla kb. mekkora lehet ?

"openoffice miert akkora? vagy az x11? a kde-t ne is emlitsuk."
Passz. Valahogy bele terem a sok szemet :)

> Tul nagy kod meret meg artalmas lehet (cache miss -ek)
felteve hogy az egeszet hasznalja is egyszerre...

> Konstans tabla kb. mekkora lehet ?
passz. de a libavcodecben alapbol benne van az osszes codec (van vagy 100, nagy reszet a kutya se hasznalja, pl. regi videojatekok introjanak formatuma stb), valamint az osszes encoder(!) is. es ez bele van forditva a playerbe, igy ha az egesz mplayer csak 1 sorbol allna akkor is 2-3mb lenne minimum a binaris miatta.

a libavcodecet kell kiherelni elso korben.
(nekem csaj ugy sikerult hogy kikommentezgettem a codeceket az egyik structban)

plane ha embedded alkalmazasra kell, ott altalaba 1 codec kell csak, de max 3-4, igy azon rengeteget lehet nyerni.
(pl. az svq1/svq3 eleve egy rakas tablat hasznal)

A'rpi

( Hiena v | 2007. 11. 25., v – 21:44 )

+1

Király doksi. Ilyent szeretnék látni a kulönféle buszokra, jó alaposan, esetleg regiszter méységig lemenve.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

USB -röl. az usb.org -on találsz infót.
zip

Linux szemszögéböl: ddk

Intel,Via,sun(sparc) busz vezerlőkröl többnyire találsz datasheet -et, regiszterekkel.

Az can,I2C,RS232,RS*,IEEE 1284 (ppdev),Dallas 1 wire,.. egyéb egyszerű serialhoz találsz infót.
Soros, parhuzamos prot meg mindig kompatibilis modon megy az osi gepekkel a PC-k -ben.

ISA halál egyszerű.