CPU-limit fejtágító

Sziasztok!

Pár nappal ezelőtt kaptunk az SKL-nél egy cikket, ami a CPU/VGA limit fogalmakat fejti érthető formában. Ajánlom mindenki figyelmébe, mert aki még nem merült el a grafikai megjelenítés világában, azoknak ez a cikk segíthet a tisztánlátásban. Persze nem farag belőlünk profi programozót, de számos sztereotípiát megszüntethet a fejünkben.

http://skl-projekt.hu/readarticle.php?article_id=47

http://skl-projekt.hu

Akinek van véleménye, az nyugodtan írja le a cikk alatti kommentekhez. Amennyiben nincs beregisztrálva, az SKL-es regisztráció végtelenül egyszerű és gyors.

Hozzászólások

értemén, hogy fontos a látogatottság, de ami nemmegy azt nem kell erőltetni :/

Mi alapján következtetted ki, hogy nem megy? Az iwiw és a myvip látogatottságához képest a HUP látogatottsága is elenyésző. Akkor a HUP-nak sem kellene működnie? Mert hát annyira nem megy, mint a nagy oldalak, akkor meg minek erőltetni? Másrészt egyáltalán nem a látogatottság miatt csináltam a bejegyzést. Ahhoz képest, hogy milyen fiatal az oldal, meglehetősen jó látogatottságunk van. Csupán a tájékoztatás miatt tettem ki ide is, mert a szerzőnek sok munkája van benne.

SKL - leírásgyűjtemény és informatikai portál

Nem teljesen rossz, de..

"-Ne futtass hosszú tömbökön többször ciklusokat végig, lehetőleg mindig mindent egy menetben végezz el, amíg az értékek a cacheben vannak, mert a memória elérése lassú és nehézkes. Inkább hajts végre több műveletet a ciklusmagban, minthogy mégegyszer végignyálazd a tömböt. Akár 2x-es sebességet is nyerhetsz."

Cache -> regiszter
Meg szerintem adott jellemzőkkel bíró tömbre kell választani a pl. rendező algoritmust, és tesztelgetni hogy hány művelettel végez, nem az a lényeg hogy a ciklusmag hányszor fut le, hanem hogy hány konkrét művelet zajlik le mire végez.

"Egy 5 kbyteos forrásban meg fogja. Egy 500 kbyteosban nem fogja."
Nem nagyon értem hogy a compiler képességei miért függnek a loc-tól.

OOP-s résznél az hogy rövid élettartamú lokális változók helyett egy globálisabb tmp változót használunk (és műveletet kevesebbszer hajtunk rajta végre) az oké, de szerintem ennek nem sok köze van az OOP-hez. Ráadásul ha játékot fejleszt az ember, valszeg sokkal többre megy OOP-vel, mint hogy ráerőltet egy C-t aztán olyan redundáns adatszerkezetei meg vezérlései lesznek mint az állat.
Volt is vmi game amit nézegettem, talán az OpenTTD, ami sima C-ben volt megírva, és szépen nézett ki benne a hússzorosan beágyazott if/switch/stb szerkezet.

A lassú C függvényeket meg szerintem inkább hagyjuk, akinek ez a cikk szól nem hiszem hogy ír helyettük optimálisabbakat.

A nagy forráskód (értsd: sok loc) nem jelent semmit a teljesítmény szempontjából, lehet hogy a vezérlés sosem kerül rá a 70%-ára annak amit megírsz.

"A PCI sín sebessége 33 mhz."
http://en.wikipedia.org/wiki/Conventional_PCI
Azt hiszem közvetlenül az AGP előtt 66 mhz-es PCI-okra raktuk a VGA kártyákat, de ez már régen volt.

Az AGP-vel meg inkább az volt a gond, hogy aszinkron volt (mint az ADSL), így aztán felesleges volt továbbszorozgatni.

********************
"Aki nem backupol az tehetsegtelen :-)"
"...ha nem tévedek!" (Sam Hawkins)
http://holo-media.hu

Ráadásul ha játékot fejleszt az ember, valszeg sokkal többre megy OOP-vel, mint hogy ráerőltet egy C-t aztán olyan redundáns adatszerkezetei meg vezérlései lesznek mint az állat.

Az megvan ugye, hogy az OOP egy programozasi FILOZOFIA a C meg egy programozasi NYELV. Vagyis szinte barmilyen nyelven lehet OOP filozofiaban programozni. Assemblyben is. C-ben is.

Maskeppen fogalmazva, a jo programozo semmilyen nyelven nem ir redundans adatszerkezetet meg vezerlest. A szar programozonak meg mindegy mit tolsz ala, elbassza.

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

A C nyelv az OOP meg módszertan (a filozófia szerintem kicsit erős), ezzel senki se vitatkozott, de C-ben nem fogsz OOP módszertan szerint programozni (maximum részben) tekintve hogy hagyományos strukturált nyelv.
A lényeget megleled ott ahol mondtam, C-ben írt játékok forrásfájában.

********************
"Aki nem backupol az tehetsegtelen :-)"
"...ha nem tévedek!" (Sam Hawkins)
http://holo-media.hu

Latom nem erted. Az azert megvan ugye, hogy a processzor csak gotot meg pointert tud, objektumot nem? :) Vagyis elso korben a hiper OOP nyelvi elemekkel teletuzdelt cuccodbol a fordito kiszorja az OOP-t, es csinal belole strukturalt kodot, hogy tovabb dolgozhasson vele. Az ojjekt->metodus(a,b,c,d); szeru hivasaidbol metodus_magledname(ojjekt,a,b,c,d); lesz. A nyelv szabalyai szerint implicit meghivodo konstruktorok, szupermetodusok, destruktorok, helyere beszurja a szukseges fuggvenyhivasokat, letrehozza a metodusok hivotablazatait, amikben mar fuggvenypointerekrol beszelunk, stb, stb, stb.

Ha tudod mit muvel egy OOP koddal a fordito, ahhoz hasonlo viselkedest sima stukturalt nyelvbol is siman tudsz prezentalni, sot, megtervezheted ugy a kodot, hogy modszertan (ha igy jobban tetszik) szerint OOP legyen, megis joval tobb legyen annal, mint hogy kezzel szimulalod egy (peldaul) C++ fordito munkajat.

Egyebkent en fejlesztettem C-ben jatekot, es nem otthon a sajat oromomre, hanem ebbol eltem evekig. A fejlesztes a fentebb vazolt vezerelvek menten zajlott, es sehol sem lattam benne olyasmit, amit te "lenyeg"-nek gondolsz. Biztos bennunk volt a hiba.

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

Ertem mire gondolsz, de a trukk, hogy forditva kell gondolkodni. Ha szem elott tartod, hogy mit fog csinalni a fordito az OOP kododdal, pl. mi tortenik egy metodussal, amig az objektumodbol tenylegesen futtathato kod lesz, akkor mar sokkal erthetobb, megis hogy kell OOP nyelvi elemek (pl. osztalyok) nelkul alapvetoen megis OOP kodot irni.

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

Egy pontig igaz. (pl. C , C++ esetben)
De ha továbbviszed a gondolatmenetet akkor filozófiai területre tévedsz:
pl. elméletileg a c++ lefordítható lambda-kalkuluszra. Az "objektum" mint fogalmi struktúra minden konverziós lépésben elveszíthet olyan speciális tulajdonságot amit te az objektumnak tulajdonítottál korábban.

Ezt te fejben, és tudással pótolhatod!

Egy idő után (és itt a filozófia, hogy mikor is?) annyi tulajdonságot veszít, hogy már mégsem tudod objektumnak tekinteni.

Pl. analógia:
van egy ház (mint strukturált objektum) -> nem kell ház elegek a téglák (majd én mellé rakom a struktúrát és ház lesz) -> nem kell tégla, elég az agyag (majd a hő konvertálja a struktúráját) -> nem kell agyag, elég a vizek üledékképző hatása az majd idővel átalakítja a bemeneteit agyaggá

Hiába vagy tisztában a konverziós struktúrával, valahol mégis van különbség a vizek üledéke és egy felépült ház között.

Az egész nem feltétlen csak részek összege, hanem több is lehet annál.
http://xkcd.com/659/

+1

Az objektumorientált (objektumközpontú) programozás egy programozási mód – a „jó”
programok írása közben felmerülõ sereg probléma megoldásának egy megközelítése (paradigma).
Ha az „objektumorientált programozási nyelv” szakkifejezés egyáltalán jelent
valamit, olyan programozási nyelvet kell hogy jelentsen, amely az objektumokat középpontba
helyezõ programozási stílust támogató eljárásokról gondoskodik.
Itt fontos megkülönböztetnünk két fogalmat: egy nyelvrõl akkor mondjuk, hogy támogat
egy programozási stílust, ha olyan szolgáltatásai vannak, melyek által az adott stílus haszn
álata kényelmes (könnyû, biztonságos és hatékony) lesz. A támogatás hiányzik, ha kivé-
teles erõfeszítés vagy ügyesség kell az ilyen programok írásához; ekkor a nyelv csupán
megengedi, hogy az adott megközelítést használjuk. Lehet strukturált programot írni
Fortran77-ben és objektumközpontút C-ben, de szükségtelenül nehezen, mivel ezek a nyelvek
nem támogatják közvetlenül az említett megközelítéseket.
Az egyes programozási módok támogatása nem csak az adott megközelítés közvetlen haszn
álatát lehetõvé tévõ nyelvi szolgáltatások magától értetõdõ formájában rejlik, hanem a ford
ítási/futási idõbeni ellenõrzések finomabb formáiban, melyek védelmet adnak a stílustól
való akaratlan eltérés ellen. A típusellenõrzés erre a legkézenfekvõbb példa, de a kétértelm
ûség észlelése és a futási idejû ellenõrzések szintén a programozási módok nyelvi támogat
ásához tartoznak. A nyelven kívüli szolgáltatások, mint a könyvtárak és programozási
környezetek, további támogatást adnak az egyes megközelítési módokhoz.

Az "elfelejtettem" meg "sok" bejegyzések (nem is egy!) az adatösszehasonlító táblázatokban nem kicsit gagyi. Ha nem tud/nem akar utánanézni akkor ne tegye bele a cikkbe...

Persze, ott volt, csak nem mindenki tudta megfizetni. Mar pedig nem csak a gazdag gyerekek szeretnenek szamitogepet, hanem bizony a csoringerek is, nekik pedig az AGP kartya volt megfizetheto. Arrol nem is beszelve, hogy meg 2 eve is eleg sok AGP-s alaplap-birtokos volt SZVSZ. Foleg azok, akik nem felevente cserelgetik a gepeiket.

Alapvetoen az a baj, hogy ket kulonbozo szegmensbol jottunk, igy mas iranybol szemleljuk a vilagot. Ami masnak koltseghatekony megoldas, azt te ganyolasnak nevezed, mert nem echte minosegi, kozvetlen a gyartotol vett hardverbol epitkezik. Amit mas szeretne lepesrol-lepesre felepiteni maganak, hogy megtanulja, az nalad megintcsak a ganyolas kategoria, csak mert nem hajlando hasznalni egy mar kesz termeket, hanem szeretne latni reszleteiben hogyan is mukodnek a dolgok.

Ertem en, hogy te nem ugy tanulsz/elsz mint masok, de engedtessek meg a jog arra, hogy mas ne a te utadon kozlekedjen. Esetleg nem mindenkinek tetszik annak az utnak minden aspektusa. Ha valaki segitseget ker, es te nem akarsz neki adni, a "nem tudom" sokkal jobb valasz, mintha belebonyolodsz egy veg nelkuli vitaba.

Erre probaltam meg ravilagitani a Sun-os mondattal, es nem arra, hogy sunberenc lennel.

A cikkrol meg egybol latszik, hogy nem igazan szakmai, de mivel nem en irtam, talan nem nekem kellene ilyen nagy elannal nekem esni.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

nem, nem maradt le. kicsit unalmas, hogy mindig ezzel a "nem mindekni sunbol epit" dologgal jossz, holott baromira nem irtam semmi ilyesmit.
csupan 2 eve is elvetve lehetett mar agps alaplapokat venni, manapsag meg mar mindenen pci-e van. ennyi.

az, hogy egy 10 eves gepen mi van, engem hidegen hagy.

Amikor nem bővít, akkor nem a 8989 Ft-os AGP-s alaplapot veszi hanem a 8990 Ft-os PCI-E-set. Azonos kategóriás VGA-k ára közt kb ugyanennyi a különbség. Már évek óta.

Pontosabban, most már csak nagyítóval találsz AGP-set egyátalán, tehát a minimális árkülönbség mellett még járhatsz is utána jó sokat....

Használt gépek vásárlása [v. öröklése] esetén meg egyértelműen nem a teljesítmény a fő tényező, így valószínűleg nem cserél benne semmit. Ha mégis, a bontóban fillérekért, és nem újonnan.

Manapsag meg azert igencsak lehet AGP-s VGA kartyakat kapni, mig pl. ISA-s vagy PCI-sokat nem igazan. Mig ez utobbi tenylegesen kihaltnak tekintheto, addig az AGP-sek nem tekinthetok kihaltnak, max "elozo szerias"-nak vagy ilyesminek. Amig valamire - barmilyen okbol - igeny van (es itt nyilvan nem az 1-2 fanatikus igenyerol beszelek), addig szerintem az semmikepp nem nevezheto kihaltnak.

Az mar csak hab a tortan, hogy az egesz cikk temakorehez hogy jott az AGP kihaltsaganak kerdese. A cikk elsosorban videokartyakkal, CPU-kkal es limitekkel foglalkozik, es leirja az AGP limitjeit, ami nyilvan a PCI Express eseteben maskepp nez ki, de a cikkiro gondolom errol rendelkezett - vagy velte, hogy rendelkezik - melyebb ismeretekkel, mig a PCIE-rol nem.

Az meg mar tenyleg csak az en ertetlensegem, hogy miert kell igy letamadni. Ha PCI-vel irta volna a cikket, akkor azt mondom, hogy igazad van, am az AGP (meg ha manapsag mar egyre inkabb kiszoruloban is van, amit keszseggel elismerek) meg mindig letezo es mukodo technologia - bar valoban egyre kevesbe tamogatott. Azonban nem ertem, miert ne szerepelhetne egy alapvetoen ismeretterjesztonek szant cikkben.

Kulonben, ha gondolod, leirhatnad a PCIE mukodeset es limitjeit, biztos sokat tanulnank belole.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

kit letamadni? a cikkirot? mert sut a cikkrol, hogy baromsag, minimalis szakmai alappal. egy 10 eves pc worldbe elmegy. (persze sajat uberkiraly linuxos howto oldalra azt rak ki az ember, amit akar ;-)
teged meg azert mert csak az olyan baromsagokkal tudsz jonni allandoan, hogy "csak sunban tudsz gondolkodni blahblahblahblah". egyreszt komoly kisebbsegi komplexusod lehet, hogyha mindenutt csak ezt latod, masreszt baromira semmi koze nincs a sunnak mint cegnek a topichoz, meg _erintolegesen sem_, ugyanis desktop gepet nem gyart, de neked ez mar a sokaig menet volt, ahol ezzel tudtal csak jonni.

aki meg muvelodni akar, annak wikipedia, ennel jobban en sem tudom leirni.

Te meg folyamatosan ezen lovagolsz. Vedd mar eszre, hogy kepletesen ertettem, en sem vagyok ostoba, tudom, hogy a Sun jo ideje nem gyart mar desktop gepeket (pontosabban vastag klienseket). Azonban nem kedvelem kulonoskeppen azokat az embereket, akik lenezik azokat, akiknek nem tegnap kigurult brand gepuk van, hanem maguknak rakjak ossze, es esetleg nem a legujabb, legtrendybb alkatreszekbol. Mondhattam volna a Sun helyett akar Dell-t is, a lenyeg nem valtozott volna.

Hogy valami kihalt-e vagy sem, azt pedig nem a te velemenyed alapjan allapitjak meg.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

sosem volt meg brand gepem, de kb tudod mit csinalok azzal, hogy Te mit nezel le ;-)

es nezz korbe: AZ AGP KIHALT. mondogasd nyugodtan, mert ez az igazsag, jobb, ha elhiszed. tudod, bontoban is van ISAs alaplap + kartya, biztos.

(ja, es nekem nem kell hinni, wikipedia: "No new motherboard chipsets are equipped with AGP support").

Szerintem azert ertjuk felre egymast, mert mast ertunk azalatt, hogy kihalt. Te azt erted alatta, hogy nem forgalmaznak mar ilyen porttal alaplapot, en pedig azt, hogy nem forgalmaznak ilyen csatlakozoval kartyat.
Abba ugye megegyezhetunk, hogy ez utobbi nem igaz? Illetve abba, hogy nem ertunk egyet :-)
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.