BGAFC Vendégkönyv

Σ: 16 post

saxus (statz)

#9, Agyfasz (419)

422 | #1be0 | ^ | Idézet | Tue, 17 Apr 2012 15:15:13 +02

84.3.*.*

*.catv.pool.telekom.hu

Ja, azért, hogy pozitívumokat is emlegessek:

Az első P1-esemen egy Word 97 vagy egy Excel 97 indítása jó fél-egy percet vett igénybe W95-ön. Ma, W7-en egy átlagos gépen egy Office 2010 kb. néhány mp hideg indításból, másodszorra, kb. azonnal.

Ugyanígy egy MSVC++6->2008 -as lassulás, majd a 2010-ben szerencsére sok igen lassú dolgot száműztek. (Mindezt úgy, hogy a korábbi UI jó részét átírták .NET-re meg WPF-re ;)

TCH (statz)

#1, Főfasz (10443)

5783 | #1be1 | ^ | Idézet | Tue, 17 Apr 2012 15:35:02 +02

80.98.*.*

*.catv.broadband.hu

saxus írta/wrote:
Hát... C++ -hoz képest a BDS triviális dolgokat sem feltétlen optimalizált ki.

Lehet. A Delphi is csak egy lehetőség.

saxus írta/wrote:
Uhum, és azért a ciklus az egy viszonylag ritkán használt fogalom ugye?

A ciklust nem biztos, hogy lehet párhuzamosítani. Ha ami mögötte jön épül az eredményre, akkor meg pláne nem.

saxus írta/wrote:
Attól, hogy jelenleg minden arra van ráálva, hogy egy szálon csinálsz mindent (UI Thread ismerős valakinek?), attól még szépen lassan el lehetne kezdeni gonodlkodni azon, hogy mit hogyan lehet párhuzamosítani.

Egyáltalán nincs minden erre ráállva, van ami már most párhuzamosan hajtódik végre.

saxus írta/wrote:
Meglehetősen sok mindent lehet.

Igen, de sokmindent meg nem. Úgyhogy a 2x annyi mag === 2x annyi nafta úgy ahogy van bullshit. :P

saxus írta/wrote:
Delhpi VCL egy baromi nagy réteg a Windows saját GUI-ja felett, amelyet - breaking news - sokáig tart inicializálni egy MFC-hez képest. ;)

Lehet, pár éve még nagyon fürge volt. De mondom a Delphi is csak egy lehetőség.

saxus írta/wrote:
Na de mennyi CPU időt vesz el az a sok lib? :)

Alapvetően semennyit se kéne, mert csak az fordul bele a kódba, ami included és used. Ami meg befordul, az nem feltétlen lassít, attól függ, hogyan írták meg. Mondom nem csak libcé van.

saxus írta/wrote:
tisztább syntax

Xcuzeme WTF?! A dzsuvánál és a cisztánál obskurusabb szintaxist nehezen lehetne találni. :P

saxus írta/wrote:
Tévedsz. A virtuális memória kezelésében a CPU csak hardveres támogatást nyújt, de az operációs rendszer is részt vesz benne.

Nem mondtam, hogy nem, de tök mindegy, a lényeg, hogy akár CPU full, akár CPU/OS, nem a fosnet csinálja, max parancsot ad ki, amit C-ből is lehet nyugodtan.

saxus írta/wrote:
Egyébként igen, a C is csinálhat ilyen átrendezgetéseket, csak épp nem a háttérben egy külön szálon, hanem egy szálon, mikor malloc()-olsz.

Ez sem igaz. C-ben is létezik szálkezelés.

saxus írta/wrote:
Másrészt a virtuális címtér (amit a programodban látsz) és a fizikai címtér (amit a programodból nemigazán látsz, csak OS szinten) az eléggé két különböző dolog.

Nem mondod. Te most kajakra ki akarsz engem okítani CPU-kból? :) Erről beszéltem végig, hogy az az egyazegyben relokálás az nem a dotnet varázslata. :P

saxus írta/wrote:
hanem arra, hogy átláthatóbb és rugalmasan bővíthetőbb. Meg hogy ne egy mindent keresztül-kasul hivogató cucc legyen a szoftver.

Hát szerintem nem lett átláthatóbb. Legalábbis az MVC esetén. Csak fragmentáltabb. Énnekem a library, modul, template modell jön be. :P

saxus írta/wrote:
Írjad, van rá három napod.

Mert az angribörcöt három napig fejlesztették, mi? Elmész te a fárasba. :P Majd egy évig fejlesztették. Egy év alatt egy ilyen kaliberű játékot egy képzett team akármelyik 3. vagy 4. generációs konzolra megcsinált annakidején.

saxus írta/wrote:
Miért, mit vártál?

Többet. Fejlődésből.

saxus írta/wrote:
Na meg programozható pixel/vertex/texture/uniform shaderek.

Mármint hardware-sen. Software-sen ezek voltak már annakidején is, csak persze kevesebbet tudtak és mivel sw-ből ment, sokkal lassabb volt.
Oké vannak új dolgok, de igazából a mai cuccok nagy része létezett már negyed évszázada is, csak lassabb volt, kisebb tudású, meg mittudomén. A lényeg, hogy a kurwa nagy "fejlődés" kimerült abban, hogy mindenbe beleöntöttük a gigahertzeket, a gigabyteokat, na meg pár gyakran használt funkciót beépítettünk a hw-be.

saxus írta/wrote:
Mellesleg az egész 3D grafikás mizériának a "mellékterméke" a GPGPU, amivel viszont párhuzamosíott matekolást nagyon durván jól lehet csinálni.

Tény, de a GP²U működése sem mai ötlet, csak annakidején külön gépek voltak ilyen célra, ma meg benne van a chipben.

saxus írta/wrote:
És csinálja a fordító meg ;)

WTF? Ezt elmagyaráznád?

saxus írta/wrote:
A példakódod meg nagyon jól mutatja, hogy nem tudod, hogy mire jó az OOP.

Na, hát akkor világosíts fel. Már nagyon régen várom, hogy valaki mutasson valamit, amit nem lehet OOP nélkül megcsinálni, vagy legalábbis szarabb lesz a végeredmény.

saxus írta/wrote:
Ácsi, a Java meg a C# nem erlang, meg lisp, imperatív az is ;)

Rendben van, de én tisztán funkcionális megoldásokra gondoltam. Szokás szerint balfaszul fejeztem ki magam, előfordul.

saxus írta/wrote:
Csak az OOP itt segít pl. azzal, hogy nem szükséges ismerned még az osztályt sem, bőven elég az interface-ját. Amikor egy modulból meg akarsz hívni egy másikat, ... Így a modul a háttérben teljesen jól cserélhető, önállóan egységtesztelhető, stb.

Már bocsánat de egy normális interfésszel bíró függvénykönyvtár is tudja ezt.

saxus írta/wrote:
C way ezzel szemben pl. az lehetne, hogy fogsz egy függvénypointert és/vagy egy structot függvénypointerekkel és azon keresztül mókolsz.

Nem csak C van. Vannak olyan nyelvek, amiket lehet funkcionális megközelítéssel is használni, mindenféle görcs nélkül.

saxus írta/wrote:
Szvsz, akkor már inkább legyen nyelvi feature, biztosabb, hogy a fordító betartat dolgokat.

Delphiben pl. így van. Érdekes módon mindenféle pointerezés nélkül lehet benne simán fügvényekkel tolni. Nem csak a C way van. :P

Prometheus (statz)

#3, Főfasz (1824)

192 | #1be2 | ^ | Idézet | Tue, 17 Apr 2012 18:08:37 +02

84.0.*.*

*.dsl.pool.telekom.hu

Kemi, már 3 féle Skyrimet telepítettem föl a tieddel együtt, de mindegyik bénázik. Árnyak tűnnek föl hirtelen, nem látszanak a fénycsóvák és nem tudok frissíteni újabb verzióra. Mihez kezdjek?

saxus (statz)

#9, Agyfasz (419)

3517 | #1be3 | ^ | Idézet | Tue, 17 Apr 2012 18:15:02 +02

84.3.*.*

*.catv.pool.telekom.hu

TCH írta/wrote:
A ciklust nem biztos, hogy lehet párhuzamosítani. Ha ami mögötte jön épül az eredményre, akkor meg pláne nem.

Ha ez így volna, nem lennének párhuzamos összesítő, rendező, kereső, stb. algoritmusaink. Egyébként a tapasztalatom az, hogy sokkal kevesebb olyan ciklust használunk, ahol szükséges az előző érték, mint ahol nem. Ld. listázások, akár PHP-ben. Miért ne lehetne egy 100 elemű lista elemeit mondjuk 4 szálon legenerálni és a végén összefűzni? Vagy pl. listák feldolgozása. Rengeteg ilyen művelet van, valamint rengeteg olyan művelet van, ami aszinkron módon elvégezhető. Nem véletlen, hogy a C#5 -ben is az egyik jelentősebb újítás a C# async lesz.

TCH írta/wrote:
Egyáltalán nincs minden erre ráállva, van ami már most párhuzamosan hajtódik végre.

Az a helyzet, hogy de. UI rajzolásra UI thread van, IO műveletek jórészt blocking műveletek, egyedül hálózatkezelés terén vannak jelei az eseménykezelt megoldásokra.

TCH írta/wrote:
Ez sem igaz. C-ben is létezik szálkezelés.

Léccineee... A C minden memóriabuzeráló műveletet (foglalás, felszabadítás) szinkron csinál a free/malloc-al. Ezzel szemben a Java/.NET az ilyeneket háttérben csinálja.

C-ben meg önmagában nincs szálkezelés, a fork és a threading mindenhol az OS (és a hozzá tartozó libekből) ered. Eleve C++ dettó, ott is jellemzően valamilyen libet használ mindenki arra, hogy elfedje a különböző OS-ek különböző szálkezelési megoldásait. C++11 e téren mondjuk előrelépés, ott már végre része lesz a standard library-nak.

TCH írta/wrote:
WTF? Ezt elmagyaráznád?

Mit magyarázzak? Azért van a fordító, hogy ne nekem kelljen pointerekkel meg gotokkal foglalkoznom, ha nem muszáj.

TCH írta/wrote:
endben van, de én tisztán funkcionális megoldásokra gondoltam. Szokás szerint balfaszul fejeztem ki magam, előfordul.

Sose gondoltam volna, hogy haskell fan lennél, főleg, hogy utálod a matekot ;) Na az tisztán funkcionális ;) (Amire te gondolsz a struktúrált, imperatív)

TCH írta/wrote:
Delphiben pl. így van.

Igen, de a Delphi egy részben OOP nyelv :P

TCH írta/wrote:
amit nem lehet OOP nélkül megcsinálni, vagy legalábbis szarabb lesz a végeredmény.

Egy eseménykezelt, UI toolkitnél adja magát. Egyébként egy szóval nem mondtam, hogy amit OOP-ben meg lehet csinálni, azt ne lehetne megcsinálni procedurális modellben. (Hisz, ha ez nem lenne igaz, eleve egy OOP kódot se tudnál lefordítani gépi kódra. És az OOP-nek nem is az a célja, hogy minden esetben hatékonyabb legyen az elkészült kód.

Az OOP-nek az a célja, hogy sok feladatra adjon egy absztraktabb, magasabb szintű, rugalmasabb, újrafelhasználhatóbb fejlesztési módszert. Van a programtervezési minták című könyv, érdemes elolvasni. Engem az tanított meg arra, hogy mit jelent OOP-ben programozni, mi az, hogy felületre (interface) fejleszteni, stb.

TCH írta/wrote:
Énnekem a library, modul, template modell jön be. :P

Legalább pontosan idéznél ;) Modulok voltak meg blokkok. Aztán utána kiegészítettük még egy model réteggel is, mert kellett. Az MVC meg pont nem webre alkalmas szerintem, de mindegy. Mellesleg a BC ilyen szempontból utólag visszatekintve meg se közelítette az OOP kódokat, csak vannak benne néhol objektumok :)

kemi (statz)

#2, Főfasz (2970)

298 | #1be4 | ^ | Idézet | Tue, 17 Apr 2012 18:17:40 +02

94.21.*.*

*.pool.digikabel.hu

Hát tudni kéne, milyen videokártyád van, meg csinálsz egykét screenshotot, meg leírod pontosan mi a probléma, felteszed egy hivatalos support fórumra, (nem kell tudniuk, hogy crackelt a játék :)) és biztos tudnak segíteni. Nekem nem volt ilyesmi problémám, úgyhogy fingom sincs hogy kéne megoldani.

saxus (statz)

#9, Agyfasz (419)

1317 | #1be5 | ^ | Idézet | Tue, 17 Apr 2012 18:28:03 +02

84.3.*.*

*.catv.pool.telekom.hu

Egyébként, ha már itt tartunk: a hardver lehetőségei és korlátai jól mutatják a trendeket: a 97-es P1-esem és a 2002-es Thunderbirdem közötti különbség kb. ég és föld. Utána elkezdtek megerősödni a konzolok játékok terén, ezzel magával rántva az egész high end PC piacot. Most ott tartunk, hogy a PS3 és az Xbox 360 hosszú-hosszú évek óta "A platform", amelyre fejleszteni kell és mindent ehhez mérten optimalizálnak. Mivel fix a hw, bővíteni nem lehet, arra kell optimalizálni. Ebből kifolyólag - bár PC-n most már jó ideje szebb, nagyobb felbontású, részletesebb, stb. - felülről le lett limitálva a játékok gépigénye. Ezért van az a nem ritka állapot, hogy egy adott játék következő része jobban fut, mint az előző része. Erre pl. jó példa az Mass Effect 1-2-3 fejlesztése. Mindegyik UE3 engine-el megy, mégis egyre szebb lett, hiszen az évek során folyamatosan optimalizáltak rajta.

Másrészről a CPU erőssége és a memória mennyisége jelenleg ott tart, hogy általános dologban egyszerűen nem tudsz olyat adni neki, ami kevés lenne (HTML5+JS és a flashes ökörséget most hagyjuk). Gyakorlatilag nem tudsz olyan szar gépet venni, amelyen ne futna jól egy W7, Office 2010, internetes cumó páros. Talán a HD film, ami még trükkös belépő szintű cumóknál.

A maradéknál persze marad a kőkemény optimalizálás.

kemi (statz)

#2, Főfasz (2970)

1161 | #1be6 | ^ | Idézet | Tue, 17 Apr 2012 18:34:44 +02

94.21.*.*

*.pool.digikabel.hu

saxus írta/wrote:
Egyébként, ha már itt tartunk: a hardver lehetőségei és korlátai jól mutatják a trendeket: a 97-es P1-esem és a 2002-es Thunderbirdem közötti különbség kb. ég és föld. Utána elkezdtek megerősödni a konzolok játékok terén, ezzel magával rántva az egész high end PC piacot. Most ott tartunk, hogy a PS3 és az Xbox 360 hosszú-hosszú évek óta "A platform", amelyre fejleszteni kell és mindent ehhez mérten optimalizálnak. Mivel fix a hw, bővíteni nem lehet, arra kell optimalizálni. Ebből kifolyólag - bár PC-n most már jó ideje szebb, nagyobb felbontású, részletesebb, stb. - felülről le lett limitálva a játékok gépigénye. Ezért van az a nem ritka állapot, hogy egy adott játék következő része jobban fut, mint az előző része. Erre pl. jó példa az Mass Effect 1-2-3 fejlesztése. Mindegyik UE3 engine-el megy, mégis egyre szebb lett, hiszen az évek során folyamatosan optimalizáltak rajta.

Pont erről beszélt Cevat Yerli, a Crytek fejese, amikor a Crysis 2-ről kérdezték egy interjúban. Korábban belinkeltem valahol. Amúgy a Crysis 2-nek tényleg szebb a grafikája mint az 1-nek, és kisebb a gépigénye.

TCH (statz)

#1, Főfasz (10443)

3025 | #1be7 | ^ | Idézet | Tue, 17 Apr 2012 18:52:05 +02

46.107.*.*

*.catv.pool.telekom.hu

saxus írta/wrote:
Miért ne lehetne egy 100 elemű lista elemeit mondjuk 4 szálon legenerálni és a végén összefűzni? Vagy pl. listák feldolgozása.

A listákat lehet párhuzamosítani, de egy igen nem jelent mindig igent.

saxus írta/wrote:
Az a helyzet, hogy de.

De igen. Pl. ha renderelsz egy 3D képet és ha több magod van, akkor több szálon renderel, mert a kép teteje független az aljától.

saxus írta/wrote:
Ezzel szemben a Java/.NET az ilyeneket háttérben csinálja.

Léccineee... Szerinted, ezeknek a compilere és interpretere miben van írva? Talán Java-ban vagy .NET-ben? Szerinted, ha a C-ben nem lehet megoldani a több szál kezelését, akkor hogy oldották meg a Java és a .NET motorjában?

saxus írta/wrote:
Mit magyarázzak? Azért van a fordító, hogy ne nekem kelljen pointerekkel meg gotokkal foglalkoznom, ha nem muszáj.

Az istenit! Szakadj már el a C-től! Nem csak a kibaszott dzsuva meg a ciszta oldja meg helyetted a pointerekkel és gotokkal való tökölést!

saxus írta/wrote:
Sose gondoltam volna, hogy haskell fan lennél, főleg, hogy utálod a matekot ;) Na az tisztán funkcionális ;) (Amire te gondolsz a struktúrált, imperatív)

Nem tudok Haskellban programozni, az elnevezésekkel meg mindig is bajban voltam. De ha meg tudod, hogy mire gondolok (arra, hogy semmi ojjektum), akkor meg mit szívózol?

saxus írta/wrote:
Igen, de a Delphi egy részben OOP nyelv :P

De nem kötelezően, míg a Java és a C# igen! Minden változó egy objektum.

saxus írta/wrote:
Az OOP-nek az a célja, hogy sok feladatra adjon egy absztraktabb, magasabb szintű, rugalmasabb, újrafelhasználhatóbb fejlesztési módszert. Van a programtervezési minták című könyv, érdemes elolvasni. Engem az tanított meg arra, hogy mit jelent OOP-ben programozni, mi az, hogy felületre (interface) fejleszteni, stb.

Sajnos megdögleni sincs időm, pedig kiváncsivá tettél. Viszont azt, hogy valami újrafelhasználható az nem feltétlen pozitív. Van olyan kód, amit pár év után jobb a kukába lökni.

saxus írta/wrote:
Legalább pontosan idéznél ;) Modulok voltak meg blokkok.

Nem. Nem tudom te miről beszélsz, az én cuccaim néznek ki úgy, hogy vannak a függvénykönyvtárak, meg vannak a modulok, meg vannak a template fileok és ennyi a fene nagy rendszer.

saxus írta/wrote:
Az MVC meg pont nem webre alkalmas szerintem, de mindegy.

Ezt ne nekem mondd, nem én erőltetem...

saxus írta/wrote:
Másrészről a CPU erőssége és a memória mennyisége jelenleg ott tart, hogy általános dologban egyszerűen nem tudsz olyat adni neki, ami kevés lenne

Általános, ja. De én leszarom, hogy az egységsugarúaknak mi kell. Na nem nekem kell teljesítmény, de pl. az öcsém Maya-zik, meg fotosoppozik és ahhoz kell kajak.

Viszont az Oracle-s kérdésemre nem válaszoltál.

Prometheus (statz)

#3, Főfasz (1824)

201 | #1be8 | ^ | Idézet | Tue, 17 Apr 2012 20:14:29 +02

84.0.*.*

*.dsl.pool.telekom.hu

Itt vannak az adataim:

Windows 7 Home Premium
Service Pack 1

Processzor: Pentium(R) Dual-Core CPU E6300 2.80 Ghz 2.79 Ghz
Telepített memória(RAM): 4 Gb (3,19 Gb használható)
Rendszer típusa: 32 bites

saxus (statz)

#9, Agyfasz (419)

2831 | #1be9 | ^ | Idézet | Tue, 17 Apr 2012 20:48:29 +02

84.3.*.*

*.catv.pool.telekom.hu

TCH írta/wrote:
A listákat lehet párhuzamosítani, de egy igen nem jelent mindig igent.

Egy szóval nem mondtam, hogy minden esetben. Csupán azt, hogy sok esetben. (Persze, ehhez is jó lenne valami threadnál sokkal low levelebb cucc, mert egy thread indítása jelenleg elég költséges, OpenMP-t meg nem láttam még olyan embert, aki ne szidta volna. C# async mondjuk ígéretes, meglátjuk.)

TCH írta/wrote:
Léccineee... Szerinted, ezeknek a compilere és interpretere miben van írva? Talán Java-ban vagy .NET-ben? Szerinted, ha a C-ben nem lehet megoldani a több szál kezelését, akkor hogy oldották meg a Java és a .NET motorjában?

Ember, elolvastad egyáltalán, hogy miről van szó? A CLR és a JVM külön, a háttérben intézi a GC-t (kivételes esetektől eltekintve, mikor nagyon kell). C-ben C++-ban, de még Delphiben vagy más hasonló statikus nyelvben ilyen nincs, maximum, ha használsz valami dinamikus memóriamenedzsment libet (C++-ban nem ritka az olyan projekt). A C minden ilyen memóriabizgerálást a malloc/realloc/free-ben (illetve C++ esetén a new/delete operátornál) csinál. Amikor a függvényt meghívod.

Azt a mellékes tényt meg ne hagyd ki, hogy a .NET az user space címteret rendezgeti át, ami menedzselt referenciák nélkül nem túlzottan kivitelezhető. C-ben meg olyan nincs, csak pointer van. C++ -ban már legalább van referencia, dehát sokkal előrébb nem vagyunk ilyen téren. (JVM-et ilyen mélységekben nem ismerem, de nem lepődnék meg, ha okosítana valamit az is, mert a JVM igencsak szereti előre foglalni magának a ramot, hogy aztán egyedileg rendezkedjen benne. .NET ilyen szempontból jobban alapozik az alatta lévő rendszerre).

TCH írta/wrote:
Nem tudok Haskellban programozni, az elnevezésekkel meg mindig is bajban voltam. De ha meg tudod, hogy mire gondolok (arra, hogy semmi ojjektum), akkor meg mit szívózol?

Jobb helyeken illik nevén nevezni a dolgokat, anélkül csak levegőbe beszélés az egész.

TCH írta/wrote:
De nem kötelezően, míg a Java és a C# igen! Minden változó egy objektum.

Uhum, mert ha egy osztályba belehányok egy valagnyi statikus metódust, az aztán valóban OOP megoldás ;)

TCH írta/wrote:
Viszont azt, hogy valami újrafelhasználható az nem feltétlen pozitív. Van olyan kód, amit pár év után jobb a kukába lökni.

?????

TCH írta/wrote:
Na nem nekem kell teljesítmény, de pl. az öcsém Maya-zik, meg fotosoppozik és ahhoz kell kajak.

Maja meg a Fotóbolt az nem kifejezetten az átlagfelhasználás kategóriája.

TCH írta/wrote:
Viszont az Oracle-s kérdésemre nem válaszoltál.

Mi volt az? Nem találom.

saxus (statz)

#9, Agyfasz (419)

606 | #1bea | ^ | Idézet | Tue, 17 Apr 2012 20:50:34 +02

84.3.*.*

*.catv.pool.telekom.hu

kemi írta/wrote:
Pont erről beszélt Cevat Yerli, a Crytek fejese, amikor a Crysis 2-ről kérdezték egy interjúban. Korábban belinkeltem valahol. Amúgy a Crysis 2-nek tényleg szebb a grafikája mint az 1-nek, és kisebb a gépigénye.

Mondjuk a CryEngine-el elmehetnek a ... LOD rendszere akkora egy igénytelenség. Már a Crysis Warheadban is illúzióromboló volt a semmiből előtűnő fák, Crysis 2-ben külön vicc volt. Pl. lövök vkit egy szemközti ház tetején, nézem lófasz se történik. Semmi gáz, sniper elő... Jahhogy ott volt előtte egy bazinagy szellőzőrendszer? FAIL.

TCH (statz)

#1, Főfasz (10443)

1461 | #1beb | ^ | Idézet | Tue, 17 Apr 2012 21:59:45 +02

46.107.*.*

*.catv.pool.telekom.hu

saxus írta/wrote:
A CLR és a JVM külön, a háttérben intézi a GC-t

Hát, ha neked az a threadkezelés, hogy nem kell leprogramoznod a gc-t... De egyébként, ha normálisan építed fel az adatszerkezetet, akkor nem is nagyon van szükség rá.

saxus írta/wrote:
Jobb helyeken illik nevén nevezni a dolgokat, anélkül csak levegőbe beszélés az egész.

Pfft, na te is szép vagy ám a 3 nap alatt megírt angribörccel, meg a 3 szoba méretű AGC-vel. :P

saxus írta/wrote:
?????

Az ember fejlődik, meg a technika is. Könnyen lehet, hogy x problémára már létezik jobb megoldás.

saxus írta/wrote:
Maja meg a Fotóbolt az nem kifejezetten az átlagfelhasználás kategóriája.

Épp ezt mondtam, hogy ha az ember komolyan dolgozik a géppel, akkor nem biztos, hogy elég a teljesítmény.

saxus írta/wrote:
Mi volt az? Nem találom.

TCH írta/wrote:
Más. Most szoptam egy sort órákül databézzel. Te futottál már vele össze? Van valami értelmes indoka annak, hogy nincs benne LIMIT parancs, hanem helyette egy a nyelvbe bedrótozott oszlopot kell belehákolni a WHERE klauzába? (Ami ráadásul mindig 1-ről indul, szóval, ha lapozni akarok, akkor egymásba ágyazott kéréseket kell írnom. :P ) Vagy ez csak a demoverzió, a pénzesben nincsenek ilyen fasságok? :P

saxus (statz)

#9, Agyfasz (419)

924 | #1bec | ^ | Idézet | Tue, 17 Apr 2012 23:33:37 +02

84.3.*.*

*.catv.pool.telekom.hu

TCH írta/wrote:
Más. Most szoptam egy sort órákül databézzel. Te futottál már vele össze? Van valami értelmes indoka annak, hogy nincs benne LIMIT parancs, hanem helyette egy a nyelvbe bedrótozott oszlopot kell belehákolni a WHERE klauzába? (Ami ráadásul mindig 1-ről indul, szóval, ha lapozni akarok, akkor egymásba ágyazott kéréseket kell írnom. :P ) Vagy ez csak a demoverzió, a pénzesben nincsenek ilyen fasságok? :P

Annyi, hogy sosem volt SQL standard a LIMIT. Régi programokat figyelembe véve nem is volt rá annyira igény ilyen formában.

MySQL-ben gyanítom azért van, mert webre nagy igény volt rá. MSSQL-ben pl. SELECT TOP x ... van. LIMIT-OFFSET az pg/mysql feature. Deal with it.

Ui.: hallottam vmit arról, hogy állítólag terveznek valamit az SQL standardba. Na most véletlenül sem a legkézenfekvőbb LIMIT/OFFSET-et, hanem valami tárolt eljáráson keresztüli undormányt.

saxus (statz)

#9, Agyfasz (419)

685 | #1bed | ^ | Idézet | Tue, 17 Apr 2012 23:37:01 +02

84.3.*.*

*.catv.pool.telekom.hu

TCH írta/wrote:
Hát, ha neked az a threadkezelés, hogy nem kell leprogramoznod a gc-t... De egyébként, ha normálisan építed fel az adatszerkezetet, akkor nem is nagyon van szükség rá.

Jó, azt hiszem itt vesztette el a társalgás a maradék komolyságát. Takarítani, rendezkedni lehet a háttérben. C ilyenről nem hallott. Ez meg tény. Ez marhára nem befolyásol semmit a szálkezelést illetően.

Mai általános célú programban meg viszonylag nagyon kevés esetet tudok felsorolni, hogy ne kerüljön a képbe a dinamikus memóriafoglalás (akármilyen absztrakt szinten is). Tervezz meg légyszi PHP-ben egy fórummotort, hogy ne kelljen memóriát foglalnia.

kemi (statz)

#2, Főfasz (2970)

307 | #1bee | ^ | Idézet | Wed, 18 Apr 2012 10:45:47 +02

188.143.*.*

*.pool.digikabel.hu

Prometheus írta/wrote:
Itt vannak az adataim:

Windows 7 Home Premium
Service Pack 1

Processzor: Pentium(R) Dual-Core CPU E6300 2.80 Ghz 2.79 Ghz
Telepített memória(RAM): 4 Gb (3,19 Gb használható)
Rendszer típusa: 32 bites

Ez kevés. Videokártyát/GPU-t mondj nekem.

Prometheus (statz)

#3, Főfasz (1824)

12 | #1bef | ^ | Idézet | Wed, 18 Apr 2012 13:10:42 +02

84.0.*.*

*.dsl.pool.telekom.hu

Nvidia PhysX