BGAFC Vendégkönyv

Σ: 1 post

saxus (statz)

#9, Agyfasz (419)

6130 | #1bdf | ^ | Idézet | Tue, 17 Apr 2012 15:00:53 +02

84.3.*.*

*.catv.pool.telekom.hu

TCH írta/wrote:
kemi: Próbáld ki Delphivel is, kiváncsi vagyok az mit dob.

Tippre lassabb lesz, mint a C. Anno nézegettem, hogy melyik fordító mit optimalizál ki és mit nem (BDS2005, C#2.0 v C#3.5, MSVC++2005 v 2008, már nem emlékszem). Hát... C++ -hoz képest a BDS triviális dolgokat sem feltétlen optimalizált ki.

TCH írta/wrote:
A több mag csak párhuzamosítható feladatoknál jelent nagyobb teljesítményt, amúgy kb. semmit sem jelen

Uhum, és azért a ciklus az egy viszonylag ritkán használt fogalom ugye? 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. Meglehetősen sok mindent lehet.

TCH írta/wrote:
akkor mi lesz az erőforrásigényes részekkel?

Write only? Az erőforrásigényes részekre kell koncentrálni nem azokra, amelyeknél tökmindegy.

TCH írta/wrote:
hogy egyfelől a C-t csak példának hoztam fel, mondhattam volna C++-t meg Delphi-t is

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. ;) Csak épp mindenki leszarja, mert annyival nem lassabb, mint amennyivel gyorsabb vele dolgozni. WinForms, WPF detto, főleg, hogy a WPF a WinFormshoz képest képes kihasználni a DirectX-et is.

TCH írta/wrote:
Ne akard nekem bemagyarázni, hogy egy minden szarral ellátott C++ vagy egy megszámlálhatatlan Unittal települő Delphi, amiben pikpak össze lehet kattingatni még a GUI-t is, az több fejlesztési időt enne meg, mintha Java-ban csinálnád ugyanazt, nem is beszélve a végeredmény sebességéről.

Na de mennyi CPU időt vesz el az a sok lib? :) .NET meg a Java sem a nyelv miatt lassú, hanem a sok-sok osztálykönyvtár miatt, ami miatt gyors lesz a fejlesztés. Na meg az egyéb kényelmi dolgok miatt (tisztább syntax, új nyelvi featurek, sok egyéb menedzselt dolog, amit levesz a válladról a VM, ami alatta van, stb.)

TCH írta/wrote:
ha virtuális memóriaáthelyezéssel csinálja a .NET, akkor az C-ben is megy, lévén az nem szoftveres, hanem az MMU műve.

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. Ld. a swapolás megvalósítása szoftveres. 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. 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.

TCH írta/wrote:
Pl. a mostanság kurwára divatos MVC modell is 30 éves, csak valami hülye kitalálta, hogy ez valami nagyon új dolog és ezért nagyon modern, meg nagyon menő.

Egyik patternre sem mondtam, hogy mai találmány lenne (A Design patterns című könyv pl. 94-es és az is összefoglalni igyekezett a patterneket), csupán weben jött be, mint új fogalom, mert rájöttek, hogy ott is csak kellene valami rendszer a káoszba. De megjegyzem, az MVC, vagy az MVVM, meg a DIC, sőt még egy kósza abstract factory sem arra szolgál, hogy gyorsabb legyen a szoftvered, 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.

TCH írta/wrote:
Akár SNES-en is futhatna egy ilyen játék, csak meg kéne írni.

Írjad, van rá három napod.

TCH írta/wrote:
Negyed évszázaddal ezelőtt is komplett sorozatokat rendereltek le 3D-ben.
Ehhez képest ma maximum nagyobb lett a felbontás és esetleg kevésbé szögletes a mozgás, mert gyorsabban renderelnek le több fázist.

Miért, mit vártál? Több CPU idő -> nagyobb, szebb, részletesebb grafika. Na meg programozható pixel/vertex/texture/uniform shaderek.

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.

TCH írta/wrote:
"gotokra és pointerekre fordul az egész", hogy saxust parafrazáljam. :P

Uhum. És csinálja a fordító meg ;) A példakódod meg nagyon jól mutatja, hogy nem tudod, hogy mire jó az OOP.

kemi írta/wrote:
Az meg, hogy a compiler optimalizál helyetted, sajnos oda vezet, hogy képzett programozók helyett "betanított munkásokat" alkalmaznak, ami mégjobban a szofterek elhízásához vezet.

Azzal egyetértek, hogy túl sok a kontár. Viszont valahol pozitívnak tartom, hogy kevesebb időt kell bizonyos technikai dolgokra fecsérelni és több marad a konkrét feladatra. És igen, ebbe beletartozik az is, hogy hol milyen algoritmus, milyen adatstruktúrával, stb. Probléma az, hogy ezek használatához (főleg, ha az ember jól akarja csinálni) ugyanúgy kell tudás, ráadásul OOP-ben jól tervezni nehéz. Ezt mindenki elismeri.

TCH írta/wrote:
Imperatív módon is meg lehet írni a modult

Ácsi, a Java meg a C# nem erlang, meg lisp, imperatív az is ;) 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, pl. egy DIC-ből* elkérsz egy adott interface-jű objectet és azon keresztül birizgálod. Így a modul a háttérben teljesen jól cserélhető, önállóan egységtesztelhető, stb.

* A DIC is egy érdekes állatfaj és vannak hátrányai, de vannak dolgok, amire pl. jó. Ez pl. egy ilyen.

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. Ilyen pl. egy drivernek az interface-ja valamelyik oprendszerben. (Talán FreeBSD, nem emlékszem már.). Szvsz, akkor már inkább legyen nyelvi feature, biztosabb, hogy a fordító betartat dolgokat.