Memória viszonya a processzorhoz

 ( tordai_hasadek | 2014. február 4., kedd - 23:51 )

Kiveszek 4 GB ramból 2-őt, kipróbálom ugyanazt az alkalmazást, akad. Vissza beteszem a másik memória modult minden jó.
Nézem, fele annyit zabál dupla annyi memóriával, swap memória 0. Mi lehet ennek az oka?
Processzor használat 2 GB ramnál duplájára ugrik a rendszernek.
Mért terjeszkedik ki jobban kisebb memórián a rendszer mint nagyobb memórián? Ubuntu-t használok, de ez régebben windows xp alatt is hasonló volt nekem.
Ezek szerint részlegesen megoldás lenne 8 GB memóriára való bővítés?
Természetesen én ebbe a laptopba már egy kavicsot nem fogok venni, majd a következő modellbe 8 GB lesz minimum.
Valaki úgy tudna magyarázni erről, milyen arányok, viszonyok vannak itt?
lényegében a Neumann architektúrát tanultuk, hogy ADC adatbuszokon kommunikál a cpu és a memória, ennél többről nem tudok.

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

Megkérlek, most ezt mellőzzed.
Normális írásokat szeretnék látni, nem flamegenerátort emberkéket.
--
mc futtatására képes eszközt munkagépnek nevezzük | 640 KB mindenki számára elég kell hogy legyen

Nem arról van szó, hogy egy alkalmazás 2 GB RAM esetén megevett 10 % memóriát, 4 GB RAM esetén meg 5 %-ot? Mert az ugyanannyi.


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

LOL! Ez a veg, ha a hupon ilyet kell magyarazni :D

Nem tudtam hirtelen másra gondolni a problémája kapcsán, csak arra, hogy benézte. :)


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

Elsőre indokolatlannak tűnhet, de volt memtest?

Roppant precíz a kérdés! :)
Azt meg már rég megbeszéltük, hogy Neumannak semmi köze sincs a mai rendszerekhez. Legfeljebb előbb élt mint mi. :)

Tehát, ha ubuntu, akkor töltsd le az nmon csomagot, ha nincs akkor az IBM oldalain megtalálod!
A c, m, d, t billentyűket megnyomva sokkal többet tudhatunk a futó programról.
Jó helyette az export NMON=cmdt is.
A két memória-konfigurációval futtatás közben készítsél képet, és rakd fel valahova!

Azt meg már rég megbeszéltük, hogy Neumannak semmi köze sincs a mai rendszerekhez.

Már miért ne lenne? Ugyanaz a programtár, mint az adattár. Ugyanonnan történik az utasítás fetch, mint az adat elhozása, illetve írása.


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

Aztán megint megsértődsz! :(
Természetesen igazad van.
Hogy közelebb kerülj a való világhoz el kellene olvasnod legalább ezt a cikket, különös tekintettel az utolsó bekezdésre!
Amire hivatkoztam az ez az ág.
Szóval megállapításod igaz, mint az, hogy a Laokoón-csoport rendelkezik olyan metszettel, ami tökéletes körszelet. Bár nem ez a jellemző. :))
Egy számítógép,(ideális PFC-vel, ha nem cseszegeted) pedig pont úgy működik, mint egy ellenállás. Ez is igaz, de általában másképp szokták körülírni. :)
Így tordai_hasadek barátunk gépéről is készíthető olyan metszet, amely a von Neumann architektúra jeleit mutatja, de gondolom ettől baromi ideges lenne. :D

Na haragudj, egy kicsit pontosítanád, hogy mire gondolsz?
A wikipedia oldal utolsó bejegyzését elolvasva azt láttam, hogy egy teljesítménybeli probléma van, ami a mai gépek nagy részét érinti, és különféle megoldásokkal, mint pl. cache igyekeznek a hatását tompítani.

Ennek alapján én azt gondolnám, hogy inkább pont azt igazolja, amit Lócsemege kolléga írt, illetve amit tanítani szoktak. Hiszen ha a te állításod lenne igaz és a mai gépeknek semmi köze nem lenne ehhez, akkor az általad mutatott probléma sem érinthetné a mai gépek nagy részét.

Nem?

Egész konkrétan arra célozgatok, hogy blokkvázlat szinten a mai rendszerekre ráfogható a neumannság.
Ugyan az eggyel utolsóbb :) bekezdésre gondoltam, de pont a cache után pár szóval írja, hogy ez Harvard, azaz pont nem Neumann! ("Providing a cache between the CPU and the main memory, providing separate caches or separate access paths for data and instructions (the so-called Modified Harvard architecture)...)
Mondhatjuk ez a CPU belsejében van, bár Neumann mester idejében még nem pont így nézett ki a CPU. :)
Lócsemege úrfiank igaza van - elméletileg. Gyakorlatilag a CPU nem a memóriára van kötve, hanem a cache-re. A memória sem a CPU-ra van kötve, hanem a chipset/MMU-ra. Az emlitett topicban azért hivatkoztam a POWER5 processzorra, mert az abba beépített MMU egyszerre több csatornán képes írni és olvasni (8/12) a memóriát.
Konkétan a kisebb pc MMU esetén az 1-2-(3)-4 slotban elhelyezett memória olvasása is történhet párhuzamosan 2 vagy több csatornán. Ilyen esetben alaplap speckójában is beleírják, ha a teljes memóriasebesség nem érhető el 1 vagy páratlan számú memória modullal.
Tehát a Neumann modell egy régi, elméleti, valami. Arra kiválóan alkalmas, hogy pl. a GPU pipeline feldolgozását ne keverd össze mással. Alkalmazható a mai gepekre is, amennyiben van bennük memória, CPU és busz. És annyira nem alkalmazható, hogy akár már két memóriamodul esetén sem vizsgálható segítségével a topicnyitó probléma.

No, mégegyszer: A Neumann architektúra egyik eleme az ALU. Akkoriban még regiszterek (avagy register file) sem voltak. Ehhez képest ide rakok egy szép képet. Ez egy 1995-ös IBM konstrukció, pontosan a System RS/6000 J30 modell. A maximum 8 CPU (symmetric multiprocessing) switch rendszeren keresztül kapcsolódik a memóríakártyákra. A memória rendszer 256 bit széles, és egy ciklus alatt képes egyszerre több helyről írni/olvasni. Az egyes CPU-kban 6 végrehajtó egység van, amelyek párhuzamosan működnek. Fogadjunk, ebből még elméletben sem tudod kifűrészelni a Neumann modellt!

Attól, hogy van adat és utasítás cache, az operatív tárban ugyanazon a buszon, mi több, ugyanabban a memóriában helyezkedik el a futtatható kód és a feldolgozandó valamint a feldolgozott adat.


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

Köszi

Nem sértődöm meg, nincs miért. Arra gondoltam, hogy a mai PC-k továbbra is Neumann felépítésűek, nem pedig Harvard architektúrájúak, mint pl. a PIC mikrokontrollerek, amelyekben külön memóriában foglal helyet a program, s másik buszon lévő memóriában az adat. Ez utóbbi előnye, hogy egyidőben lehet prefetchelni az utasítás végrehajtásával, hátránya, hogy például táblázatokat immidiate címzésű utasításokkal, PIC-ek esetében computed goto és retlw konstans formában lehet megoldani, ami jó-jó ugyan, de azért eléggé bénázás.


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

Ezek a fájdalmas emlékeim! A 8085 ami igazán jó volt vezérlésre, aztán jöttek a "magasszintű nyelvek". Neki kellene futni a PIC-eknek. Kíváncsi lennék milyen fordítót adnak hozzá, mert komolyan mondom egy C fordítóval nehezebb kivitelezni azt, ami egy Macro80 segítségével gyerekjáték volt. A makrók segítségével meg el lehet rejteni a problémáidat. :)
Ez az achitektúrásdi meg tényleg nem állje meg a helyét. Csináltam már Z80-nal (Neumann) RAM nélküli gépet (???), de a Neumannál nincs register file. Viszont külön van input és output, tehát az IO busz ugyanúgy nem felel meg neki, mint a memory mapped IO. Aztán milyen gép az, amiben ALU nincsen (nem is Harvard), de biztosan hallottál a sequencer-ről. És ha egy CPU-ban van 4db párhuzamos IEE FP unit (is), az most ALU vagy sem? :)
Az igazi gép pedig a Colossus. Talán még ssházni is tud lukszalagról. :)

Nekem egyáltalán nem problémám a retlw-vel történő táblázat szervezés, mi több, meglepően hatékony, hiszen a táblázat egy-egy indexéhez lehet goto-t írni, amelyik elugrik, majd egy újabb feltétel vizsgálatának függvényében különböző értékekkel tér majd vissza. Tipikus példa a naptár. Van egy táblázatod, amelyik visszatér azzal, hány napos a hónap, de február esetén ugrik, majd ott megnézi, szökőév van-e, s aszerint visszatér 28-cal vagy 29-cel.

Inkább azt mondanám, szokatlan, hogy nem lehet közvetlenül a programtárra címezni, onnan adatot elhozni, illetve szokatlan az is, hogy a program- és adatmemória buszszélessége nem azonos.


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

Nekem spirálos és nem PIC-es naptáram van. :))
Ami hiányzik az pl. a rnz (Return if Not Zero). Mert a magas szintű az, amikor elugrasz a szubrutin végére és csak onnan térhetsz vissza. :(
A szélességet nem is értem. Nagyobb processzoron az utasítás 64bit az adat meg 1 bittől tart a 128 bitig, vagy esetleg még hosszabb. A memória meg 256bit. Persze ez nem PIC. :)

> A szélességet nem is értem. Nagyobb processzoron az utasítás 64bit az adat meg 1 bittől tart a 128 bitig, vagy esetleg még hosszabb. A memória meg 256bit. Persze ez nem PIC. :)
Nem vagyok PIC-es, de harvard architekturanal megszokott, hogy teljesen mas az adat es az utasitas memoria cimezhetosege. Pl. az adat memoria byte-onkent cimezheto es 16b a cimter, mig az utasitas memoria utasitasonkent (ami nem is feltetlenul egesz szamu tobbszorose egy byte-nak) cimezheto es a cimter is mas meretu.

A kollégám 16 bites (2x8 bit ALU) és 22 bites utasításszélességgel dolgozott. ROM programtár és úgy emléxem 16 bites memóriabusz. No, és ez bipoláris processzor volt.

Párszor kiszoptam már ezzel a memória kezeléssel alkalmazott számítástechnikán.
Lehet perverzió, de én egyszer egy pic-ből de csinálnék "asztali" gépet.
Tehát monitor, billentyű rá és szöveget írnék be rajta és a kijelzőn megjelenne, floppyra meg ki lehetne menteni pld :)
Vagy ezt már Arduinoval(avr) tervezem, hogy lcd-mini keyboar, ethernet sheild, 2őt csinálni belőle és interneten tudnék irkálni a kiszemelt haveromnak.
--
mc futtatására képes eszközt munkagépnek nevezzük | 640 KB mindenki számára elég kell hogy legyen

btfss STATUS, Z
return


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

Miről is szóltak a Neumann-elvek? (forrás: Wikipédia)

1. Soros utasításvégrehajtás (az utasítások végrehajtása időben egymás után történik. Ellentéte a párhuzamos utasításvégrehajtás, amikor több utasítás egyidejűleg is végrehajtható)
2. Kettes (bináris) számrendszer használata
3. Belső memória (operatív tár) használata a program és az adatok tárolására
4. Teljesen elektronikus működés
5. Széles körű felhasználhatóság
6. Központi vezérlőegység alkalmazása

Amikor Von Neumann ezeket lefektette, akkor még ugye nem létezett mikroprocesszor, memóriamodul, cache, HDD, registerfile, és még egy halom trükk, amit a mai processzoroko alkalmaznak.

Vegyük sorba, hogy teljesülnek-e a feltételek:
1. Soros utasításvégrehajtás
Ez általában teljesül programozási szempontból, ugyanis a mikroprocesszor garantálja, hogy az utasításaid *hatása* úgy fog érvényesülni, mint ahogy te azt a programodban előírtad. Persze ez mikroarchitektúrális szinten már nem teljesen igaz. Például a memóriába kerülhet más sorrendbe az írás, mint ahogy végrehajtódtak, de a CPU-n belül és a CPU-k között is mindent megtesznek azért, hogy ez ne lehessen hatással egy futó program működésére.
2. bináris számrendszer: egyértelműen teljesül.
3. Belső memória. Vagyis a RAM. Ez egyértelműen teljesül. Neumann idejében pl. egyik soros adattárolóról a másikra másolás közben hajthattak végre műveleteket.
4. Teljesen elektronikus működés. Teljesül.
5. Széles körű felhasználhatóság. Teljes mértékben teljesül, hisz tetszőleges programot írhatsz rá.
6. Központi vezérlőegység alkalmazása: CPU. Ez is teljesül.

Szóval átnézve egyesével a Neumanni elveket azt lehet kijelenteni, hogy egy ami rendszer architektúrálisan egy módosított Neumann rendszer, mely programozási szempontból igyekszik teljes mértékben garantálni a Neumann-elvek betartását.

Ezzel szemben a (módosított) Harvard-architektúra esetén nem tudod írni a program memóriát. Szóval azt se lehetne mondani, hogy Harvard-architektúra állunk szemben. Valójában a CPU mélye általában implementációs szinten Harvard architektúra, de általában az L2 cache szintjén már ez nem teljesül.
Ott lehet nyakon csípni azt, hogy belül a programkód előtöltésre kerül külön programmemóriába (D-cache), majd betöltésre kerül a prefetch egységbe és a pipelineban különböző feldolgozottsági állapotokon megy végig, hogy van egy memóriatávolság amin belül már nem tudja a program a saját kódját módosítani. Ez általában a prefetch fokozat vagy a D-cache szokott lenni. Processzortól függően a D-cache még invalidálásra kerül egy ilyen írástól, de pl. ha előfordított kódok vannak benne (gyakorlatilag az összes mai X86 processzor előfeldolgozza a programkódot, lefordítja/szétbontja belső utasításokra), akkor ez se feltétlen igaz.
Amúgy ez az a pont is, ahol például egy 386-485-pentium között inkompatibilitás lépett fel. De hát a mai világban nem normális dolog 1-2 bájtnyi távolságra az éppen végrehajtott utasítástól előre módosítani a programkódot.

2. bináris számrendszer: egyértelműen teljesül.
Be is b@szna, analóg jelekkel vagy 10es számrendszerbe működne(zuse pld)
4. Teljesen elektronikus működés. Teljesül.
Még a Harvard szerű gépeknél is ugyanis a relékkel max másodpercenként 10 csattanást jó ha lehet csinálni, nem vicc ma kipróbáltam.
-Ezzel szemben a (módosított) Harvard-architektúra esetén nem tudod írni a program memóriát. Szóval azt se lehetne mondani, hogy Harvard-architektúra állunk szemben. Valójában a CPU mélye általában implementációs szinten Harvard architektúra, de általában az L2 cache szintjén már ez nem teljesül.
-Érdekes, mert arm, powerpc inkább Harvardra hajaz szerintem, viszont a két faszi jól kitalálta a dolgokat. Eltudnék róla filozófiázni.
Az is érdekes, hogy az x86-os processzorok vas szinten risc processzorok és a cisc csak egy emuláció rajta.
Megéri?
Másik érdekesség, a g4es cpu-k az én core2 duo-mat mérföldekről veri.
--
mc futtatására képes eszközt munkagépnek nevezzük | 640 KB mindenki számára elég kell hogy legyen

lol

- Mintha én is ezeket mondtam volna, nem? Amúgy minek tépjem a szám, itt le van írva szépen: http://hu.wikipedia.org/wiki/Harvard-architekt%C3%BAra#Bels.C5.91_.C3.A9s_k.C3.BCls.C5.91_fel.C3.A9p.C3.ADt.C3.A9s
- Igen, cisc emuláció és 15 éve egyértelműen azt mondtam volna, hogy rohadtul nem éri meg az x86 emuláció, de a piac mást mondott, aztán eljött az a pont, hogy a cpu mag (cache nélkül) olyan kis részévé vált egy mai IC-nek, hogy asztali és szerver környezetben annyira azért nem is gond. Ott nem éri meg, ahol számít minden pikowatt fogyasztás, pl. okostelefonok. Meg azért az is ott van még, hogy az Intel a legfejlettebb gyártástechnológiával nyomatja a chipjeit, rengeteg erőforrást tud áldozni arra, hogy optimalizálja az áramköröket. Végső soron a legerősebb RISC vagy RISC-szerű processzormagot gyárthatná az Intel. Egy előnye mindenképp van az x86-nak: tömörebb programkód.
Ami nekem a PowerPC-kben tetszett, hogy nem mentek végig 15 SIMD utasításkészlet verzión, hanem megcsináltak egyet (AltiVEC, ha jól emlékszem, amúgy meg IBM VMX vagy mi), amiben figyelembe vették azt is, hogy hálózati eszközökben és szuperszámítógépekben mire van szükség és kész. Amikor ez a G4-ben megjelent, sokkal kifinomultabb volt, mint az MMX.
Az, hogy a G4 megveri-e a C2D-t, tesztelni kellene többféle felhasználási területen is és többféle szempontból is lehet az egyik jobb a másiknál. De már mindkettő csak történelem, nem?

"De már mindkettő csak történelem, nem?"
Ahogy t_h is.

Hát elég rég óta mászkál valami csótány a Marson ilyen processzorral. :)
Jó sokat fizethetett az IBM, hogy ne Intel CPU menjen! :D

Hát nem is tudom erre a tudományos elemzésre mit mondjak.
Inkább tudomásul veszem, hogy mondjuk a
- 8 végrehajtó egység, és
- a vektor egység (mondjuk 4 db 32 bites összeadást végez párhuzamosan), szóval
a fenti 12 utasítás egy órajel alatt, az nem más mint soros végrehajtás. :)

A gyakorlatilag hardveres memóriaszegmens védelmet jelentő védett üzemmód esetén a Neumann architektúra memória egyes blokkjai nem írhatók, és csak program van benne. Akkor ez milyen modell?

A cache leírásod nem rossz, csak az I-cache maradt ki. A mai CPU-k "egy kicsit előre lefuttatják" a programot, megelőzve a a végrehajtóegységeket, aztán egyszer csak jön a branch prediction, ami manapság roppant ravasz és több szintű. Ez is soros végrehajtásra utal, vagy inkább a bejövő lyukszalagból néha ki kell tépni egy-egy darabot, mert feleslegessé vált?

Sőt a sorosnak írt és vélt program helyes sorrendjét igen gyakran nem csak a CPU, hanem a fordító is biztosítja. Olyan 12 éve a Motorola G5-ös processzorhoz írt fordító sikersztorijáról olvastam, hogy háromszoros sebességét értek el a rename regiszterek tudatosabb kihasználásával. A wikipédia így kezdi a magyarázatot: In computer architecture, register renaming refers to a technique used to avoid unnecessary serialization of program operations imposed by the reuse of registers by those operations.

Általában azt hányják a szememre, hogy 20-30 éves (elavult!) tudásommal okoskodok. Sajnos a rename regisztrek használata több mint 20-30 éves múltra tekint vissza (már pl. a PentiumPro is tudott ilyet), és abszolút nem felel meg a Neumann modellnek, hanem pont az ellenkezője.

A Neumann elv legfőbb ismérveként a közös utasítás és adat memóriát tekintem. A védett móddal kapcsolatban: szerintem ring 0-ban írható, olvasható az operatív tár. Önmagában a védett módot érvként felhozni az Neumann elv ellen elég sánta. Például azért, mert user space-ben is írható, olvasható a saját maga által lefoglalt terület.


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

Azért ennél jobban is értesz a hardverhez!
Fogok két darab valamilyen írható-olvasható memóriát. Az egyiknél nem kötöm be az írás engedélyezést.
Ez megegyezik azzal az esettel, ha az egyik memória csak olvasható. Azaz ROM.

Azt most ne firtassuk, hogy milyen módon került bele a program! Ezen kívül az sem számít, hogy az operatív tár hány és milyen csip felhasználásával alakult ki. De ha mégis számít, akkor legyen két memória modul, és az egyiket teszem csak írhatatlanná.

Fejlesszük tovább a kapcsolást! Egy IO művelettel engedélyezem vagy tiltom az egyik memória írását. Ebben a pillanatban a Neumann átment Harvardba szoftveres úton. Bár nagyon primitív a megoldás, de ez egy "kezdetleges védett mód" modell.

Menjünk tovább az adatutak vizsgálatára! Az egy vagy több memória modul a mai gépekben is (kisebbekben is) csatlakozhat több buszon a CPU irányába. Tehát az egybefüggő, annak látszó, több részből vagy egyből álló operatív tár milyensége mindegy.

Az az apróság, hogy az operációs rendszer mit támogat, vagy a memória egy része írható-olvasható, az az alapjelenséget nem befolyásolja. Lényegében a protected mód az operatív tár olyan tulajdonságait befolyásolja hardveresen, amely menet közben megváltoztatja az egyszerű architektúrát. Ez nyilvánvalóan a Neumann architektúra továbbfejlesztése, és így nem egyezik meg vele.

Nem attól lesz valami Harvard architektúra, mert írásvédett részen van a programmória, hanem attól, hogy a VÉGREHAJTÓ EGYSÉG külön busszal csatlakozik az utasítás és az adatmemóriához. A mai CPUk belsejében külön utasítás és adat memória (L1 cache) van és külön adatbuszon csatlakoznak. Ez a utasítás cache akár előfeldolgozott utasításokat is tartalmazhat, mely esetben az adatbusz szélessége eltérhet az adatmemória adatbuszától. Pl. lehet, hogy ez már a behelyettesített mikrókódokat és az x86-ból normalizált belső utasításokat tartalmazza (pl. itt már lehet egyetlen utasításkészlet az IA-32 és az x86-64 számos utasításkészlete közül. De akár a számtalan MMX, 3DNow, SSE stb. utasításai is lefordulhatnak itt egy közös belső vektor utasításnyelvre.

Na most ezek után még abba is beleköthetünk, hogy nem is gépi kódú programot tölt be a memóriából!

Olyan dolgokat vetsz fel, melyek még messze nem is léteztek amikor Von Neumann pontokba szedte a javaslatait egy általános célú számítógép architektúrális jellemzőire.
Soros végrehajtás: én is tisztában vagyok ezekkel a dolgokkal (amúgy az I-cache miben létét rosszul tudod). Elkerülendő a hosszas magyarázkodást, elmondom, hogy mi az, ami nem soros végrehajtás: amikor az utasításaid hatása attól függetlenül más sorrendben jut érvényre, mint ahogy te azokat a programban leírtad. Amúgy történik ilyen: kötegelt memóriaelérés, melyeknél a sorrendiséget külön tranzakciós utasításokkal kell kikényszerítened ha valamiért kritikus. De ez általában jelentéktelen.
A memóriaszegmens védelemnek, virtuális memóriának és hasonlóknak semmi köze ahhoz, hogy Neumanni elv vagy nem. Egyrészt a védelmet a processzor kapcsolgatja ki/be, a processzor tudja feltölteni is programkóddal, így igazából az érvelésed meg se állja a helyét.
Szerintem a vektor egység is bőven belefér a Neumanni elvbe. Az utasítások ott is sorosan hajtódnak végre és az eredményük is sorosan jut érvényre, csak egyszerre több adaton hajtja végre ugyanazt az utasítást.

Register átnevezés, utasítások előre végrehajtása: igen, ez mikroarchitektúrálisan zajlik, programozói szempontból fogalmad se lehet, hogy ott mi történik és a processzormagot úgy tervezték, hogy ennek egyetlen hatását érezhesd csak: a sebességet.
Fordítóoptimalizáció: persze, hogy ha ismered a mikroarchitektúrát és annak a hatását arra, hogy mikor tud valamit gyorsabban végrehajtani, akkor az kihasználható valamelyest, de egy fordítóprogram által generált kódban sok egyéb rész van még, ahol lehet optimalizálni és nem csak egy adott processzormag verzióra érvényes. Ahogy a címben is kiemelted: azt igyekeztek elérni, hogy ki lehessen használni a superscalar tulajdonságot, tehát, hogy az egymásra hatást gyakorló utasítások közé beraknak olyat mást is. Ettől a végrehajtás (az utasítások hatása, ami a program szempontjából a lényeg) még soros marad. A mai processzorok ezt az utasításátrendezést már automatikusan csinálják (néhány utasításig előre szkennelnek, hogy mi az aminek elkezdhetik úgy a végrehajtását, hogy hatással lenne egy előtte álló utasításra).

20-30 éves tudás? Már egy első generációs pentium processzor is 23 éves, a meg RISC 30 körüli. A fent tárgyalt technológiák egy egy része meg visszanyúlik a 60-as évek elejére (pl. MMU: védett memória, virtuális memória).

A PentiumPro pont megfelelt a Neumanni elveknek a futó program felől nézve. Az meg ki a fenét érdekel, hogy belül hogyan oldja meg a processzor? Viszont a RISC processzorok pont híresek voltak arról, hogy nem minden esetben garantálták az utasítások végrehajtásának sorrendiségét. Például a lebegőpontos kivételkezelés volt egy érdekes dolog valamelyiknél (talán a HP processzoraiban), mert nem lehetett megmondani, hogy pontosan melyik utasítás váltotta ki. Vagy a branch gap, amikor a jump utasítás utáni utasítást még végrehajtotta a prcocesszor, mert a prefetch már lefutott. Ugye ez az aminél ma vagy törlik az egész pipeline-t, vagy meg vannak jelölve az utasítások feltételesnek és a pipeline végén a regiszterbe visszaírás előtt megnézi, hogy tényleg ráfutott-e az utasítás végrehajtás és akkor érvényteleníti. De ezt a mai processzorok még szándékosan is csinálják karöltve a branch predictionnel (végrehajtják mindkét ág első néhány utasítását).

Én ugy tudom, hogy a cpu-memória kommunikáció még mindig ugyanaz.
--
mc futtatására képes eszközt munkagépnek nevezzük | 640 KB mindenki számára elég kell hogy legyen

Én nem vettem észre 2->4GB váltásnál túl sok változást. Bár lehet, azért, mert alapba kivolt a rendszer már, és csak bevágtam az új ramokat telepítés, állítgatás stb. nélkül. Az openSUSE 12.2 -> 13.1 volt nagy változás, de nem tudom mennyi köszönhető az SSD-nek, sok memónak, és mennyi a friss rendszernek...

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

Mifele alkalmazasrol van szo?

Az OS a hasznalaton kivuli memoriat lemez cache-nek fogja hasznalni, tehat ha gyakran nyul a lemezhez az alkalmazas akkor ez is magyarazhatja.

Kevés az információ.
IGP-t használsz vagy dedikált videót saját memóriával ?
Dual vagy single channel a 2 memória modul konfigurációja ?
A memória vezérlő a processzorban van vagy az északi hídban ?

Igp, dual ch, északi hidat "láttam" most szétszedésnél, de ha a core2duo t5760 mond neked valamit akkor jobban tudni fogod.
--
mc futtatására képes eszközt munkagépnek nevezzük | 640 KB mindenki számára elég kell hogy legyen

GM 965 chipset & GMA x3100 video ?
http://www.xbitlabs.com/misc/picture/?src=/images/mobile/toshiba-satellite-u300111/scheme.png&1=1
Elég ádáz harc dúl az 1 db memória modulért , az északi híd ami a videó vezérlőt is tartalmazza , és a processzor között.
A videó memória is ebben a ram modulban van , és a RAMDAC is bejeltkezik mert ő is olvasná.
Ha beteszed a második modult akkor abban lesz.
IGP használatánál a dual channel mód sokkal többet hoz mint dedikált kártya esetén.
Ez a gép , valószínűleg 2x1 GB memóriával lényegesen jobb mint 1x2 GB-tal.

Tehát alapból sz@r a chipset?
Csak hogy ezt a 815-nél is eljátszottam és ugyanez.
Gme965 amúgy.
--
mc futtatására képes eszközt munkagépnek nevezzük | 640 KB mindenki számára elég kell hogy legyen

"Tehát alapból sz@r a chipset?"
Miért volna az , azért mert te lerontod a memória elérés idejét ?
A processzorod sebességét is degradálod a memóriára való várással.
Ezért találták ki a dual channel , triple channel eléréseket , hogy az iGP-s rendszereket is helyzetbe hozzák.
A mostani rendszerek is hasonló gondokkal küzdenek , csak magasabb szinten.
Dedikált videónál a dual channel 6-12% között javít a teljesítményen , mig az IGP-s rendszereknél akár 80% is lehet.
Egy kis olvasni való.
http://logout.hu/cikk/single_channel_vs_dual_channel/a10-5800k.html

Köszi az írást :)
+1
--
mc futtatására képes eszközt munkagépnek nevezzük | 640 KB mindenki számára elég kell hogy legyen

+1
--
Dropbox:
Dropbox
Ubuntu One

eccerű. 2g ram kevés az os+alkalmazás párosnak, többet swap-el, többet kell manipulálni a page-ekkel, kevesebb ram jut diszk cache-nek. 4g-ből már nem futsz ki.

Neumann-nak semmi köze a jelenséghez.

Valamit félre értesz, maga az architektúra (magja) ilyen, hogy több memóriával kevesebb cpu-t zabál?
Látszólag ugyanazok a programok futottak, mégsem használta ki a gép még a 2 gb-s modulokat sem, mégis a cpu feljebb ugrott.
--
mc futtatására képes eszközt munkagépnek nevezzük | 640 KB mindenki számára elég kell hogy legyen

Dual channel kb 10%-os sebesseg novekedest okoz szintetikus tesztekben.

Szerintem deje nem érti félre. Én is arra tippelek, hogy a 2 GB ramnál kevesebb memória marad a mindenféle pufferekre és cache-ekre. Emiatt többet kell foglalkoznia a memória lapozásával, ami nagyobb overhead-et jelent. Kizárt, hogy a rendszer "jobban kiterjeszkedik" kevesebb memóriával.

Egyébként pedig a topiknyitó hozzászólásodban a probléma megfogalmazásod borzasztóan (idegesítően) pongyola: nagyon nem jól fogalmaztad meg a problémát. Ezért is volt az első poszt egy DAFQU, nagyon is jogosan. Mégis mit jelent az, hogy "fele annyit zabál dupla annyi memóriáal, swap memória 0"????

Valahogy így képzelném el egy helyes probléma definíciót:

"Egy számomra érdekes jelenségre keresem a magyrázatot. Adott egy Ubuntu desktopot futtató gép, 4 GB memóriával. Amikor mind a 4 GB memória benne van, az alkalmazások zökkenőmentesen fut.nak Amikor azonban kiveszek a gépből 2 GB memóriát, azt tapasztalom, hogy az alkalmazások memóriahasználata __számomra_érthetetlen_okból__ megnő."

Majd ezek után a tesztesetek tisztességes dokumentálása kb.:

4 GB RAM esete:
SWAP használat az alkalmazás futtatása...

  • előtt: AAAA KB
  • első futtatás közben: BBBB KB
  • első futtatás után: CCCC KB
  • összes futtatás után: CCCC KB
  • Több futtatás átlaga alapján a TOP-ban a VIRT, RES, SHR értékek: x, y, z
    Az alkalmazás futtatás közben...

  • a /usr/bin/free parancs kimenete: <ide jön az output>
  • az iostat kimenete
  • 2 GB RAM esete:
    * SWAP használat az alkalmazás futtatása...

  • előtt: AAAA KB
  • első futtatás közben: BBBB KB
  • első futtatás után: CCCC KB
  • összes futtatás után: CCCC KB
  • Több futtatás átlaga alapján a TOP-ban a VIRT, RES, SHR értékek: x, y, z
    Az alkalmazás futtatás közben...

  • a /usr/bin/free parancs kimenete: <ide jön az output>
  • az iostat kimenete
  • Ha ezek az adatok megvannak, máris tudnak a többiek segíteni.

    Nem személyeskedésből írom, de úgy tűnik, kettőnk közül te értesz félre valamit, és nem én.

    De ez sajnos személyeskedés, ha leírom, hogy kevesebb memóriával többet zabál a cpu akkor az mért irreális?
    Képeket majd kapsz.
    --
    mc futtatására képes eszközt munkagépnek nevezzük | 640 KB mindenki számára elég kell hogy legyen

    -

    :)

    Ügyetlenkedésem miatt kitöröltem, pont mielőtt válaszoltál. Sebaj, a böngésző history-ja jó, csak már nem tudom vissza-módosítani.

    Ne haragudj, de az a személyeskedés, hogyha a zavaros és hiányos leírásodra küldött egy lehetséges magyarázatomra azzal válaszolsz, hogy nem értek valamit. Ha a hozzászólásomra érdemben válaszoltál volna (érvekkel alátámasztod, megcáfolod, akármi), akkor az nem lett volna személyeskedés. Mindössze ezt szerettem volna közölni veled az előző hozzászólásomban, de sajnos nem sikerült megértened.

    Szóval akkor most ki nem ért micsodát?

    Tévedés ne essék, nem akarok veled veszekedni sem most, sem máskor. Ebbe a fórumtémába több hozzászólást nem küldök be, ha folytatni szeretnéd ezt az eszmecserét, kérlek tegyük ezt privátban.

    +1

    +1

    "Ezek szerint részlegesen megoldás lenne 8 GB memóriára való bővítés?"

    2gb-vel akadozik, 4-el mar okes, akkor upgrade-eljunk 8gb-re, mert 2x4=8..? Vagy hogy?

    ----------------------
    "ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
    --> YouTube csatornám

    Igen :)
    --
    mc futtatására képes eszközt munkagépnek nevezzük | 640 KB mindenki számára elég kell hogy legyen

    tök egyszerű, 2gb ram-mal egy desktop ubuntu minimum page-elni de lehet, hogy swappelni is fog.
    ahhoz pedig cpu kell (és diszk is, amiről nem írtál semmit).
    egyébként lehet, hogy ha pár percig "békén hagyod" és kipageli ami nem kell és csak az van a memóriában ami tényleg muszáj, akkor az 1 alkalmazásodnak a 2gb is elég lehet akadásmentesen, de ez nem biztos, régen láttam desktop ubuntut, pláne régen 2gb memóriával.

    --
    Gábriel Ákos
    http://i-logic.hu

    Ez nem Windows. Linux csak akkor swappel, ha elkerulhetetlen (elfogy a memoria). Windows az aki akkor is swappeli a hatterbe rakott alkalmazasokat, ha meg boven van memoria, ezert is lassu elohivni az ilyen programokat.

    A poster szerint pedig swap 0.

    Kár, hogy a "swap 0" jelentése nem egyértelmű... Jelentheti például azt, hogy a posztoló kikapcsolta a swap-et a tesztelés idejére, és ezért az OS nem tud swapelni. Ez - ahogy Ákos is írta - megemelkedett CPU és I/O használattal jár (például a kevesebb cache-re fordítható memória miatt több diszk műveletet kell végeznie az OS-nek).
    De jelentheti azt is, hogy be volt kapcsolva a swap, de az OS nem használt belőle semmit sem a program futtatása előtt, sem utána.

    Tapasztalatom szerint nem igaz, amit írsz. Például a tmpfs használhat swap-et, a kernel él is vele.


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

    http://wiki.hup.hu/index.php/Swappiness

    -----
    "Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
    rand() a lelke mindennek! :)

    Látszik hogy régiek az ismereteim.
    Igazad van, ez nekem még nem tűnt fel.

    Most megnéztem Fedora 19 alatt:
    total used free shared buffers cached
    Mem: 3.8G 3.6G 213M 0B 517M 1.4G
    -/+ buffers/cache: 1.7G 2.1G
    Swap: 2.8G 3.2M 2.8G

    Valóban használ 3.2 MB swapet, pedig nem kellene neki.

    tordai_hasadékkal mi történt? http://hup.hu/user/20068
    Csak nem megunta a trollkodást és lelépett?

    -----
    "Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
    rand() a lelke mindennek! :)

    Lehet, hogy benézett valamit. :)

    Szerintem végre elérte a felkelő nap sugara a trollt.

    Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

    Végleg elhasadt.

    Szerintem, ha csak egyedül 1db 2gb-os modult használsz, akkor a dual speed helyett csak single speed-ben használod, tehát fele akkora sebességgel.

    Másik, amiatt akadhat a programod, mert nem tud mindent rendesen előre becachelni a oprendszer a memóriába, mert kevés.

    Nem feleződik a sebesség. Max. 10% az ebből fakadó eltérés.

    1. modul sebessége 100%
    2. modul sebessége 0%
    Átlag 50% -> tanujj meg számolni! :)

    Vagy nem.
    Görgesd feljebb , és olvasd el a tesztet.

    Tegnap, saját keresés alapján két tesztet találtam. Kissé ellentmondásosak voltak (egymáshoz képest), de a vége mindkettőnek az lett, hogy bizonyos esetekben gyorsít a dual channel, de nem annyit amennyit sokan várnak. Kb. 10% volt a vége.

    IGP-s rendszerről beszélsz.
    Olvasd el.