BGAFC Vendégkönyv

Σ: 1 post

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