Nem. Unixon/Linuxon is állítható az alap prioritás. Lásd getpriority()/setpriority(). Csak ez bizonyos feltételekkel használható, miközben a nice szabadabban, viszont maga a nice korlátozottabb.
win-en a prioritás állítod. Linuxon te a nice-t állítod (meg a class-t), amibõl a scheduler számol egy dinamikus prioritást. A felhasználó szempontjából a nice megfelel a win-es prioritásnak. A többi az eltérõ scheduler algoritmusból adódik.
"Igen, de ez a prioritás nem az a prioritás, mint win-en." -- Egy prioritás van, amit a nice is befolyásol.
"Annak a nice felel meg" -- Csak távolról felel meg neki.
"amit viszont kizárólag a programozó állít." -- Láttam én már olyat, ahol a nice-t állították.
"A prioritás itt a kernel által dinamikusan számolt érték, ami segíti az ütemezést." -- Lásd, amit fent írtam.
"Le van írva pontosan, hogy mi a nice. A kernel által számolt prioritáshoz adódik hozzá, így a júzer tudja befolyásolni a számolt értéket." -- Aham, jó.
"Ezek az osztályok azt mondják meg, hogy hogyan kezelje a scheduler az adott process-t, nem a prioritás állítás/nem állítás a lényegük." -- Természetesen. De ehhez hozzátartozik a prioritás-állítás engedélyezése/tiltása is.
"Win-en hasonlóan mûködnek a prioritások, csak ott a scheduler algoritmus fix." -- Távolról hasonlít, közelrõl eléggé más.
"Itt nincs félreértés. Mint látod, dinamikusan állítja az OS a prioritást."
Igen, de ez a prioritás nem az a prioritás, mint win-en. Annak a nice felel meg, amit viszont kizárólag a programozó állít. A prioritás itt a kernel által dinamikusan számolt érték, ami segíti az ütemezést.
"Azt hiszem, a nice is a tulajdonképpeni prioritást állítja, csak korlátok között"
Le van írva pontosan, hogy mi a nice. A kernel által számolt prioritáshoz adódik hozzá, így a júzer tudja befolyásolni a számolt értéket.
"Ja, és még kérdezted, hogy jelzi a program, hogy átállíthatja-e az OS a prioritását. Nos, két módja is van. 1. különféle classok vannak, úgy mint realtime, time-sharing, fair-share, fixed-priority. Továbbá ezeken belül is beállíthatók bizonyos policy-k erre vonatkozólag (pl. átmenetileg)."
Ezek az osztályok azt mondják meg, hogy hogyan kezelje a scheduler az adott process-t, nem a prioritás állítás/nem állítás a lényegük. És egyébként, ha akarom így is el tudom venni teljesen a CPU-t a többiektõl. Win-en hasonlóan mûködnek a prioritások, csak ott a scheduler algoritmus fix. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/scheduling_priorities.asp Érdemes elolvasni a többi részt is.
Na nézzük: "Early Unix implementations use a scheduler with Multilevel Feedback Queues with round robin selections within each Feedback Queue. In this system, processes begin in a high priority queue (giving a quick response time to new processes, such as those involved in a single mouse movement or keystroke), and as they spend more time within the system, they are preempted multiple times and placed in lower priority queues. Unfortunately under this system older processes may be starved of CPU time by a continual influx of new processes, although if a system is unable to deal with new processes faster than they arrive, starvation is inevitable anyway. Process priorities could be explicitly set under Unix to one of 40 values, although most modern Unix systems have a higher range of priorities available (Solaris has 160). Instead of the Windows NT 4.0 solution to low priority process starvation (bumping a process to the front of the round robin queue should it be starving), early Unix systems used a more subtle aging system, to slowly increase the priority of a starving process until it was executed, whereupon its priority would be reset to whatever it was before it started starving."
(Hozzátenném: késõbbi unix verziókban és implementációkban újabb megoldások születtek, de többnyire mindnek sajátja ez a dinamikus módosítás.)
Itt nincs félreértés. Mint látod, dinamikusan állítja az OS a prioritást.
Most az, hogy prioritásnak vagy nice-nak hívjuk, egy másik kérdés. Azt hiszem, a nice is a tulajdonképpeni prioritást állítja, csak korlátok között (magát a számot tekintve, illetve csak user processeké állítható, stb.). Mindenesetre általában nice-ként szokták emlegetni a unix-os prioritást, mivel user szinten az az.
Ja, és még kérdezted, hogy jelzi a program, hogy átállíthatja-e az OS a prioritását. Nos, két módja is van. 1. különféle classok vannak, úgy mint realtime, time-sharing, fair-share, fixed-priority. Továbbá ezeken belül is beállíthatók bizonyos policy-k erre vonatkozólag (pl. átmenetileg).
Nos azért számít az év, mert idõ kell, amíg a felhasználók hiányolni kezdenek valamit. Talán nem is lehet az aktuális implementációt csak úgy megváltoztatni, de egy új eltérhet. Persze ha a gyártó nem figyel oda a részletekre, akkor neki mindegy.
"És? Két dolog van odaírva: 1. dinamikus prioritás-állítás az OS részérõl, 2. pontosítás, miszerint unixon nem a prioritást, hanem a nice-t állítja át (mint késõbb írtam, a prioritás helyett van a nice, ami nem teljesen ugyanaz)."
1. Az OS nem állítja a nice-t. 2. A nice nem a prioritás alparamétere, hanem tulajdonképpen a user által állítható prioritás.
Az a "kevés köz" az az API egyes elemeinek visszafelé kompatibilitása. Miközben alapvetõ eltérések is vannak, és rengeteg új elem.
"Ezt én is írtam" -- Hol is?
"de te az egész win-rõl beszéltél, amire már nem igaz." -- Inkább úgy lehetne mondani, nem teljesen igaz, vagyis nagyrészt igaz.
"Egyébként meg, ha te is elismered, hogy nem nagy ügy egy scheduler-t paraméterezni, akkor miért érdekes, hogy 13 vagy 30 vagy akárhány évük volt rá?" -- Csak mert még ma sem tették meg.
"Inkább te szoktad." -- Dedós dolog így visszadobni a pöttyöslabdát, fõleg, hogy a tiéd.
"Én ezt írtam : "A win a mai napig cipeli a 16-bites történelmet." Te erre azt írtad, hogy : "Már csak egy elkülönített dobozban (soapboxban)." Erre mondtam, hogy ez így ebben a formában nem igaz. A 16 bites programok persze elkülönítve futnak, de ez csak egy része a kompatibilitásnak, mint ahogy a linkek is mutatják." -- Oké, ebben valamennyire igazad van. De az a "történelemcipelés" az API kis részét érinti.
"És igaz, hogy a scheduler szempontjából ez nem számít, de te általánosabban beszéltél a 16/32 bites win-ekrõl, nem pedig csak a cooperative és preemptive mûködés különbségeirõl. Hogy a két váltás egybeesik, az nem szükségszerû (bár nem is véletlen)." -- Nagyon nem véletlen, mivel összefügg a 32 bites x86-ok bizonyos új képességeivel. A korábbi procikon nehézkes lett volna a pre-emptive multitask.
És? Két dolog van odaírva: 1. dinamikus prioritás-állítás az OS részérõl, 2. pontosítás, miszerint unixon nem a prioritást, hanem a nice-t állítja át (mint késõbb írtam, a prioritás helyett van a nice, ami nem teljesen ugyanaz).
Ezt írtad: "Nos, a legelsõ, kezdetleges, 16 bites Windowst 1985-ben mutatták be. De a mai Windowsnak nem sok köze ehhez."
"Amirõl itt beszélünk, abban alapvetõen más. A pre-emptive multitasking finomítására 13 évük volt, mert azóta létezik pre-emptive multitaskos Windows."
Ezt én is írtam, de te az egész win-rõl beszéltél, amire már nem igaz. Egyébként meg, ha te is elismered, hogy nem nagy ügy egy scheduler-t paraméterezni, akkor miért érdekes, hogy 13 vagy 30 vagy akárhány évük volt rá?
"Már unom, hogy állandóan meghamisítod itt a történelmet."
Inkább te szoktad.
"Azt írtad, "nem egészen", és belinkeltél olyan lapokat, ahol visszafelé kompatibilitási miatti esetek vannak taglalva. Csak éppen ezt teljesen félreértetted, nem azért van ez a visszafelé kompatibilitás itt, hogy a WIN16-os exe-k fussanak WIN32-n."
Én ezt írtam : "A win a mai napig cipeli a 16-bites történelmet." Te erre azt írtad, hogy : "Már csak egy elkülönített dobozban (soapboxban)." Erre mondtam, hogy ez így ebben a formában nem igaz. A 16 bites programok persze elkülönítve futnak, de ez csak egy része a kompatibilitásnak, mint ahogy a linkek is mutatják. És igaz, hogy a scheduler szempontjából ez nem számít, de te általánosabban beszéltél a 16/32 bites win-ekrõl, nem pedig csak a cooperative és preemptive mûködés különbségeirõl. Hogy a két váltás egybeesik, az nem szükségszerû (bár nem is véletlen).
"Ez egy újabb tévedés. Mégis, hogy képzeled? Csak egyszerûen rosszul volt implementálva a WIN16-os környezet, kevésbé volt szeparált."
Ezt írtad : Inkább talán az az oka, hogy a Windows nem 30 éves... És a MS nem foglalkozik ilyenekkel. Ott nincs a process leíróban olyan, hogy átállíthatja-e a rendszer a prioritást.
(Pontosabban, itt talán inkább a prioritás "al-paraméterérõl" van szó, amit Unixon "nice"-nak hívnak. Asszem -5 és +5 között változhat. Ilyen Windowson eleve nincs.)
"Nem ugyanazt írták meg természetesen. De nem is totál különbözõt." -- Tudnád hanyagolni az ilyen semmitmondó, tök fölösleges kijelentéseket? Senki sem mondta, hogy totál különbõzõ. Azt mondtam, bizonyos alapvetõ és sok kisebb dologban más. Amirõl itt beszélünk, abban alapvetõen más. A pre-emptive multitasking finomítására 13 évük volt, mert azóta létezik pre-emptive multitaskos Windows. Ezt tényleg ilyen hihetetlen nehéz felfogni?
"Ezt nem próbáltam cáfolni, mivel így van." -- Már unom, hogy állandóan meghamisítod itt a történelmet. Azt írtad, "nem egészen", és belinkeltél olyan lapokat, ahol visszafelé kompatibilitási miatti esetek vannak taglalva. Csak éppen ezt teljesen félreértetted, nem azért van ez a visszafelé kompatibilitás itt, hogy a WIN16-os exe-k fussanak WIN32-n.
"Egyébként csak az NT vonalon, mert a 9x-ekben vegyes 32/16 bites kernel volt (többek közt ennek volt köszönhetõ a sok stabilitási probléma)." -- Ez egy újabb tévedés. Mégis, hogy képzeled? Csak egyszerûen rosszul volt implementálva a WIN16-os környezet, kevésbé volt szeparált.
"Értem a különbséget, de eddig nem errõl beszéltél." -- De igen, pontosan errõl beszéltem. Ezt írtam a nice-rõl: "..a nice azt állítja-e, hogy azonos prioritáson lévõ processek hogyan osztozzanak a prociidõn..". Meg azt is írtam, hogy unix-on nem win-féle prioritás van, hanem.. a nice. Azt egy szóval sem mondtam, hogy ez a nice állítaná saját magát.
"Az meg nem is derül ki a szövegbõl, hogy pontosan ki mennyi procit kap." -- Most tized %-ra, vagy mi? :D Lényeg, hogy arányosan többet-kevesebbet a nice értéktõl függõen.
"Valamennyi procit win-en is kap minden process, kivéve az idle prioritásúak." -- Aha, pár másodpercenként 0.1s-t.
"Egyébként ez csak egy beállítás a scheduler-ben, nem egy olyan nagy bonyolult technolóia. Nyílván megvan az oka, hogy miért úgy mûködik a win ahogy." -- Senki sem mondta, hogy olyan hû de bonyolult. De mindent el lehet ugye hanyagolni.
"Amirõl beszéltél, hogy az OS állítja a process prioritását." -- Nézd meg jobban a unix-os schedulereket. Több kicsit eltérõ implementáció is van.
"Jaj, de nehéz megértened, hogy hiába próbálták volna ugyanazt megírni, csak már 32 bitesen, amikor alapvetõ különbségek vannak."
Nem ugyanazt írták meg természetesen. De nem is totál különbözõt.
"Különben is te itt azt a tényt próbáltad cáfolni, hogy a WIN16-os programok egy soapboxban futnak, ami biztosítja nekik a WIN16-os körülményeket."
Ezt nem próbáltam cáfolni, mivel így van. Egyébként csak az NT vonalon, mert a 9x-ekben vegyes 32/16 bites kernel volt (többek közt ennek volt köszönhetõ a sok stabilitási probléma).
"Úgy látom te nem tudsz." -- De tudok, sõt veled ellentétben értelmezni is. ;)
"A nice ilyenkor az arányokat állítja, ezzel ellentétben winen egy magasabb prioritású process az idõ 99.9%-át megkapja, és a maradék 0.1%-ot is a rendszer kapja meg, nem az alacsonyabb prioritású processek. Nem érted a különbséget?"
Értem a különbséget, de eddig nem errõl beszéltél. Az meg nem is derül ki a szövegbõl, hogy pontosan ki mennyi procit kap. Valamennyi procit win-en is kap minden process, kivéve az idle prioritásúak. Egyébként ez csak egy beállítás a scheduler-ben, nem egy olyan nagy bonyolult technolóia. Nyílván megvan az oka, hogy miért úgy mûködik a win ahogy.
"Itt milyen befolyásolásra gondolsz?"
Amirõl beszéltél, hogy az OS állítja a process prioritását.
"Hasonló a célja és a hatása is, így nem teljesen más. Mondtam is, hogy csak hasonló, nem ugyanaz." -- Ilyen alapon igen távoli dolgok is hasonlóak valahol, valamiben.
"Úgy látom te nem tudsz." -- De tudok, sõt veled ellentétben értelmezni is. ;)
"Lefordítom magyarra: Ha a CPU nem képes kiszolgálni az összes process-t, akkor a magasabb prioritású kap több CPU idõt. Ez lényegében a prioritás definíciója." -- Tévedés. A nice ilyenkor az arányokat állítja, ezzel ellentétben winen egy magasabb prioritású process az idõ 99.9%-át megkapja, és a maradék 0.1%-ot is a rendszer kapja meg, nem az alacsonyabb prioritású processek. Nem érted a különbséget?
"Nincs szó arról, hogy a szoftver íróján kívül bárki hozzápiszkálna a prioritásokhoz." -- Naná, hogy itt nincs róla szó, mert az egy másik téma, még ha van is köze ehhez.
"Hanem? Nem találtam hivatkozást más paraméterre, amivel a scheduler-t lehetne befolyásolni." -- Itt milyen befolyásolásra gondolsz?
Megpróbálom egyszerûbben elmagyarázni: Szerinted az alábbi két változat közül melyik a valószínûbb? a) A win32 fejlesztését úgy kezdték, hogy kitörölték az egész win16 kódot, kirúgták az összes programozót, és nulláról újrakezdték. b) Ugyanazok a programozók írtak egy új 32 bites kernelt, felhasználva a korábbi tapasztalatokat, majd módosították a kód többi részét ahol kellett.
Egyébként, ha konkrétan csak a preemptive multitasking-ról beszélünk, akkor igaz, hogy saját tapasztalatuk nem volt. Viszont ehhez meg volt több évtizednyi tapasztalat más OS-ekkel (pl. unix). És ezek a tapasztalatok nem hétpecsétes titokként voltak õrizve, hanem többnyire részletesen publikálták, és tanították az egyetemeken õket. Meg simán unix programozás közben is lehetett tapasztalatot szerezni.
Hasonló a célja és a hatása is, így nem teljesen más. Mondtam is, hogy csak hasonló, nem ugyanaz.
"Nem igaz. Tudsz olvasni?"
Úgy látom te nem tudsz.
Nice becomes useful when several processes are demanding more resources than the CPU can provide. In this state, a higher priority process will get a larger chunk of the CPU time than a lower priority process.
Lefordítom magyarra: Ha a CPU nem képes kiszolgálni az összes process-t, akkor a magasabb prioritású kap több CPU idõt. Ez lényegében a prioritás definíciója. Nincs szó arról, hogy a szoftver íróján kívül bárki hozzápiszkálna a prioritásokhoz.
"És én nem is csak a nice-rõl beszéltem."
Hanem? Nem találtam hivatkozást más paraméterre, amivel a scheduler-t lehetne befolyásolni.
Félreérted. A WIN16-os programok a WIN16-os alrendszeren futnak, nem a WIN32-esen. Itt arról van szó, hogy az új API (WIN32) egy része próbál kompatibilis lenni a régivel (WIN16), hogy ne kelljen minden egyes korábban megírt függvényt átírni.
"Egyébként van is a win-ben hasonló mechanizmus, bár egyszerûbb. Minden process idõnkén egy nagyon rövid idõre magasabb prioritást kap, így biztosan hozzájut a CPU-hoz." -- Ez teljesen más, mint amirõl én beszéltem.
"Egyébként, egyáltalán nem úgy mûködik a dolog, ahogy leírtad. A nice egyszerûen a prioritást jelenti a unix-okon." -- Nem igaz. Tudsz olvasni? Nice becomes useful when several processes are demanding more resources than the CPU can provide. In this state, a higher priority process will get a larger chunk of the CPU time than a lower priority process. És én nem is csak a nice-rõl beszéltem.
"Igen, de ez nem jelenti azt, hogy a 32 bites win egy alapvetõen más OS lenne." -- Több alapvetõ, és sok kisebb különbség van.
"Itt a tapasztalatról van szó leginkább. Az, hogy 16 vagy 32 bites az OS, elsõsorban a kernelt érinti, ami bármenyire is fontos, csak kis része az OS-nek." -- És a kooperatív vs. pre-emptive multitask nem jelent tapasztalati különbséget? Nagyon is. És mivel az API-k is eléggé mások, egy applikáció-programozó számára is jól tapasztalható a különbség...
"Ez azt akarja jelenteni, hogy megoldott ez a dolog, hogy egy process jelezheti, hogy az OS magától átállíthatja a prioritását, ha nagyon terjeli a procit, és az OS ezt meg is teszi?"
Nem. Ezt kérdezted, foglalkozik-e az MS ilyesmivel. Nem konkrétan ezzel, hanem ilyesmivel. Egyébként van is a win-ben hasonló mechanizmus, bár egyszerûbb. Minden process idõnkén egy nagyon rövid idõre magasabb prioritást kap, így biztosan hozzájut a CPU-hoz.
"Aztért azt tegyük hozzá, hogy a WIN16-os programok egy az OS többi részétõl elkülönített, virtuális környezetben futnak, kooperatív módban, aminek nem sok köze van a rendszer többi részéhez."
Igen, de ez nem jelenti azt, hogy a 32 bites win egy alapvetõen más OS lenne.
"Átvehettek kódrészeket, de alapvetõen más környezet, és itt most errõl van szó."
Itt a tapasztalatról van szó leginkább. Az, hogy 16 vagy 32 bites az OS, elsõsorban a kernelt érinti, ami bármenyire is fontos, csak kis része az OS-nek.
"Igen. Neked is tudom ajánlani ezt a blogot : http://blogs.msdn.com/oldnewthing/" -- Ez azt akarja jelenteni, hogy megoldott ez a dolog, hogy egy process jelezheti, hogy az OS magától átállíthatja a prioritását, ha nagyon terjeli a procit, és az OS ezt meg is teszi?
Ha így van, mégis miért kell állandóan kézzel csinálni?
"Te nem érted. Az alkalmazás mondja meg, hogy az ütemezõ hogy bánjon vele." -- Hogyan?
"Lehet, hogy unix-on jobban be lehet állítani, de ez keveset ér, ha a programozó bénázik." -- Gondolom az alapeset az, hogy átállíthatja. Ha fontos, hogy ne állíthassa át, csak nem felejti el a programozó.
"De van köze. A 16 bites API ma is mûködik. Elvileg a win 1.0-ra írt programok mennek Vistán is. Ez tette a win-t siekressé, de pont emiatt van annyi baj is vele." -- Aztért azt tegyük hozzá, hogy a WIN16-os programok egy az OS többi részétõl elkülönített, virtuális környezetben futnak, kooperatív módban, aminek nem sok köze van a rendszer többi részéhez.
"Nem nulláról kezdték a fejlesztést. Az NT is a korábbi win-ekre épült, csak már egy sokkal fejlettebb proci volt alatta, amit ki is használt." -- Átvehettek kódrészeket, de alapvetõen más környezet, és itt most errõl van szó.
"~'85-ben? Az M68000-es, belülrõl. (Kívülrõl meg multiplexelt volt az adatbusz, így - bár két hozzáféréssel - szépen ki tudta írni/be tudta olvasni a 32 bites adatot! De ezzel nem kellett foglalkoznia a programozónak.) Így a MacOS, AmigaOS, stb. eleve 32 bitesek voltak. Utóbbi pre-emptive is volt már akkor."
Hát, sokkal fejlettebb procira könnyû jobb OS-t írni. A win a mai napig cipeli a 16-bites történelmet.
A Task Manager? Próbáltad már? Rettenetesen sokat tud segíteni. Csak az a bánata, hogy ha egy nagyon magas prioritású szál ragad be, akkor neki sem jut proci. Szerencsére több magnál ez már sokkal ritkábban fordulhat elõ (1 beragadt szál nem fogja le az összes magot).
Te nem érted. Az alkalmazás mondja meg, hogy az ütemezõ hogy bánjon vele. Lehet, hogy unix-on jobban be lehet állítani, de ez keveset ér, ha a programozó bénázik.
"Nos, a legelsõ, kezdetleges, 16 bites Windowst 1985-ben mutatták be."
The history of Windows dates back to September 1981, when the project named "Interface Manager" was started. It was first presented to the public in November 10, 1983, renamed to "Microsoft Windows" http://en.wikipedia.org/wiki/Windows_1.0
"De a mai Windowsnak nem sok köze ehhez."
De van köze. A 16 bites API ma is mûködik. Elvileg a win 1.0-ra írt programok mennek Vistán is. Ez tette a win-t siekressé, de pont emiatt van annyi baj is vele.
"Az elsõ 32 bites, normálisabb Windowst (NT) csak 1993-ban! Ez csak 13 év..."
Nem nulláról kezdték a fejlesztést. Az NT is a korábbi win-ekre épült, csak már egy sokkal fejlettebb proci volt alatta, amit ki is használt.
Megint nem figyeltél eléggé, csak kötekedsz csípõbõl. Egy olyan fícsörrõl volt szó, aminek csak pre-emptive rendszerben van értelme. Pre-emptive Windows meg csak 1993-tól van. Kapís? :)
Ne magyarazkodjal mar. A kerdes az volt, hogy miota letezik Windows az pedig 21 eve, teljesen fuggetlenul attol a marhasagtol, hogy szerinted mindosze csak 13 eve van "normalisabb".
"Nos, a legelsõ, kezdetleges, 16 bites Windowst 1985-ben mutatták be. De a mai Windowsnak nem sok köze ehhez. Az elsõ 32 bites, normálisabb Windowst (NT) csak 1993-ban! Ez csak 13 év..."
Akkor ha most elkezdunk beszelni a PCrol akkor ugyanezt allithatnam a 286 os es Core 2 Duo processzorokrol is. De ettol meg mindketto PC processzor. Tehat igenis az elso Windows 21 eve jelent meg, es teljesen mindegy te mit gondolsz rola, attol meg az is Windows volt es kar keresni az eltereseket a reszletekben. Az 1908as T Model (Ford) is auto volt, pedig kozel sem hasonlitott a mai autokra es megsem hivja senki biciklinek, vagy "normalatlan" gepjarmunek.
1. Gondoltam, talán úgy érted, létezett-e egyátalán 32 bites proci, 32 bites OS. 2. Ki mondott olyat, hogy a 16 bites Windows "nem igazi Windows"? Mert én nem. Azt mondom, mint eddig, hogy a mai és az akkori Windows teljesen más alapokon nyugszik, és szinte csak a nevük egyezik meg. Mindegy, hogy miért. De még próbálgathatod össze-vissza kiforgatni. Csak rajta.
Te oreg eddig a winfosrol es a PCkrol beszeltunk, szerinted temat valtok ? A lenyeg pedig az, hogy hiaba nem gondolod, hogy a 16bites Windows nem igazi Windows (Ilyen marhasagot is csak te irhatsz le.) Nem veletlenul irtam le, hogy mivel akkor (1985-ben) csakj 16 bites PC-s processzor volt, kar dobalozni a 32 bites Windows fogalmaval.
Ezt mondtad: "Mutass nekem olyan processzort, ami abban az idoben 32bites volt." Nem kötötted ki, hogy csak x86-os lehet. Akkor meg mit úristenezel? :P
De nem ez a lényeg. Tök mindegy, hogy miért volt 16 bites, WIN16 rendszerû, kooperative multitaszkos az elsõ Windows. Olyan volt és kész. A mai meg már teljesen más, és közben több nagy változás következett be. Így már csak a neve ugyanaz. A technológiák nagyban mások. A mai formájában, mai alapjaival kb. 13 éve létezik.
Uristen 2. Te hol futattal Windows-t M6800on ? Joember a PCkrol beszelunk, nem pedig az amigarol vagy mas szamitogeprol. 1985-ben a legfejlettebb x86 processzor az Intel 80286 volt, ami 16bites processzor.
Szóval, applikáció szinten nagyrészt mindegy, hogy milyen HW van alatta (bár vannak inkompatibilitások - még ha ezt te nem is ismered el, lásd amit tõlem idézel az aláírásodban...), de az már nem, milyen Windows.
~'85-ben? Az M68000-es, belülrõl. (Kívülrõl meg multiplexelt volt az adatbusz, így - bár két hozzáféréssel - szépen ki tudta írni/be tudta olvasni a 32 bites adatot! De ezzel nem kellett foglalkoznia a programozónak.) Így a MacOS, AmigaOS, stb. eleve 32 bitesek voltak. Utóbbi pre-emptive is volt már akkor.
Nos, a PC nem egy adott HW, hanem egy architektúra. Ez a Windowsokról nem mondható el, hiszen alapoktól más az NT. Sõt, itt 2 különálló nagy lépcsõ is volt (és több kicsi): 16 bit (WIN16) 32 bit (WIN32), kooperatív multitask -> pre-emptive multitask.
Uristen. Mutass nekem olyan processzort, ami abban az idoben 32bites volt. De ha a te erdekes elmeletedet vesszuk, akkor a PCnek is csak a neve egyezik meg a mostani gepekhez kepest.De ettol a mostani gepek ettol meg ugyanugy PCk.
A gepek fejlodesevel fejlodott ez az operacios rendszer is, de attol meg az is Windows volt, mint ahogy a neve is mutatja.
"Valóban csak 25. Miért érdekes ez?" -- Ebbe a DOS-t is beleszámoltad? :P Nos, a legelsõ, kezdetleges, 16 bites Windowst 1985-ben mutatták be. De a mai Windowsnak nem sok köze ehhez. Az elsõ 32 bites, normálisabb Windowst (NT) csak 1993-ban! Ez csak 13 év...
De igazad van, nem a kor számít elsõsorban, hanem a kidolgozottság.
"Miért ne foglalkozna?" -- Foglalkozik...?
"Akor megint ott tartunk, hogy az alkalmazásnak kell önként megmondani, hogy mennyi procit igényel. Erre való a prioritás." -- Nem értetted a lényeget. Próbáld újra!
"Mondjuk valami egyszerûsített dolog van Winen is, mert a registryben valahol lehet állítani, hogy az aktív ablak processe több prociidõt kapjon-e, vagy ilyesmi. De ez nem sokat ér."
De tényleg használ az, én próbáltam. Gond inkább akkor van, ha egy magas prioritású process ragad be, azon már csak a task manager segít, ha az még elindul.
Már nem emlékszem pontosan, hogy a nice azt állítja-e, hogy azonos prioritáson lévõ processek hogyan osztozzanak a prociidõn, vagy a fõprioritáson belüli további prioritás.
Mondjuk valami egyszerûsített dolog van Winen is, mert a registryben valahol lehet állítani, hogy az aktív ablak processe több prociidõt kapjon-e, vagy ilyesmi. De ez nem sokat ér.
Ha nem érted, miért nem olvasod el lassabban, vagy mittudomén? Mondom, a prioritást lehet állítani Windowson is, de nice nincs. A kettõ nem teljesen ugyanaz.
Inkább talán az az oka, hogy a Windows nem 30 éves... És a MS nem foglalkozik ilyenekkel. Ott nincs a process leíróban olyan, hogy átállíthatja-e a rendszer a prioritást.
(Pontosabban, itt talán inkább a prioritás "al-paraméterérõl" van szó, amit Unixon "nice"-nak hívnak. Asszem -5 és +5 között változhat. Ilyen Windowson eleve nincs.)
Erosebb csakhogy csomo emberke sir, ugyanis a Core2 ala nincs patch mint az AMD ala es belassul nekik a proci a winfos Read Time Stamp Counter hivasai vagy mas problema miatt.
""Az inkább a vinyón múlik, nem a procin. próbáld dolgoztatni." Ezért tökmind1 mennyi magod van."
Az erõ nem akkor kell, amikor az ember pihen. Ha nem használod CPU intenzív feladatokra a géped, akkor neked nem kell több mag.
"Ez az üresjárat állapothoz közeli ámikor a vinyó használódik a töltésnél - mert te mondod, hogy az dolgozik lényegében az inditáskor - 2 mag meg rá vár = > kell a 4 mag feltétlenül"
Nem a gép elindulásához kell a sok mag, hanem a tényleges dolgozáshoz.
"Amennyire ehhez kell, annyira tudja: pl. ha egy program úgy terheli agyon a procit, hogy nem fogad/vár inputeventeket, azt kicsivel lejjebb kapcsolja prioritásban. Unix rendszereken vannak ilyen megoldások."
Nem ennyire egyszerû a probléma. Pl. lehet, hogy tényleg kell a proginak az egész proci. Nem tudom, hogy unix-ban hogy van, de az amit leírtál kb. 2 perc munkával berakható a win-be is, tehát nyílván oka van, hogy nem így mûködik.
"Az inkább a vinyón múlik, nem a procin. próbáld dolgoztatni."
Ezért tökmind1 mennyi magod van.
"Üresjáratban tök nyolc, hogy hány magod van."
Ez az üresjárat állapothoz közeli ámikor a vinyó használódik a töltésnél - mert te mondod, hogy az dolgozik lényegében az inditáskor - 2 mag meg rá vár = > kell a 4 mag feltétlenül
renderelés - erre egy szavam nem lehet - életet ment a két mag.
Annyit tennek hozza,hogy a core2 procis gepem 1Gb ddr2-vel lassabb mint az amd 3000+ -om 2Gb ddr1 rammal....:(((( Vagyis inkabb szamit a ram, mint a magok szama......
Az XP nem is lesz feltûnõen gyorsabb. Gondoljunk csak bele 5 éves operációs rendszer... Nem 2-3-4 Ghz-s procikra, rendszerekre írták. Ahogy haladt az idõ sosem éreztem hogy most hû mennyivel gyorsabb mint a 900-as Duronon volt. Szó mi szó aktuális már a Vista, mert technológiailag az XP már egy elavult OS. Kétségtelen mûködik, de ez is lassan annyira toldozgatva foltozgatva lesz mint anno a Win98. Service Pack ide vagy oda, lassan váltani kell. Ezért nem látszik meg a teljesítmény növekedése, bár egy bizonyos szint felett ezt nem is az OS-tõl kell elvárni.
Amennyire ehhez kell, annyira tudja: pl. ha egy program úgy terheli agyon a procit, hogy nem fogad/vár inputeventeket, azt kicsivel lejjebb kapcsolja prioritásban. Unix rendszereken vannak ilyen megoldások.
"Ha azt mondjátok a Dual Core pl. jobb mint a Solo, én elhiszem nektek, de Mindezt a multitaskingoteddig is meg lehetett valósitani simán, nemhalt meg az egymagos sem 1 csiga rammal."
Ha nem használja ki az alkalmazás, akkor mindegy, hogy hány mag van. Ha kihasználja, akkor viszont a 2 mag közel dupla teljesítményt jelenthet. Ma még nincs túl sok ilyen progi, de idõvel lesznek.
"Esetleg pl. a Photoshop egy jó példa erre - ugyanolyan gagyin indul mint a Solon"
Az inkább a vinyón múlik, nem a procin. próbáld dolgoztatni.
"és a 95% ban amikor üresjáratban áll"
Üresjáratban tök nyolc, hogy hány magod van.
"gondolom kell egy háztartásnak az 500W os táp."
Nem fogyasztanak sokat. Az én X2 4200+-omnak nevetségesen kicsi a gyári hûtése, ennek ellenére se nem meleg, se nem hangos.
Informatika és tudomány
