.NET vs Qt

C/C++

Szeretném a véleményeteket kérni.

Tételezzük fel a következő szituációt:

Adott egy vadonatúj project. A project rengeteg számításigényes algoritmust használ, ezért csak compiled nyelv jön szóba a project jelentős részének a leprogramozásakor. A projectnek szüksége van egy GUI-ra is. Hogy példákat mondjak olyesmi projectekre gondoltam, mint pl. egy zene/videó enkódoló, egy neurális háló betanítását végző framework, mindegy, valami számításigényes desktop problémát képzeljünk el.

Operációs rendszerre nincs megkötés.

Ha C++-t választunk, akkor ma reálisan két alternatíva van a GUI kifejlesztésére: Qt és a .NET.

Rengeteg érvet tudok mondani a Qt mellett, a .NET ellen.

Kérlek írjátok meg, hogy szerintetek miért lenne érdemes mégis .NET-et választani.

.NET alatt nem vagyok tapasztalt, eddig elkerültem elsősorban emocionális, másodsorban performance okokból. A környezetemben sokan preferálják, de enyhén szólva nem nem győztek meg. Szeretném mérlegelni több szempontból is, hogy mi szólhat mellette egy új projectnél, ha nincsennek kényszerű microsoftos függőségeink.

  • 3027 megtekintés

( joco01 v | 2010. 03. 29., h – 22:32 )

Nekem az egyik legjobb érvem a .NET mellett a Visual Studio. Használtam már sok más eszközt, mindentől fényévekkel gyorsabban tudok VS-sel fejleszteni. Meg úgy általában menedzselt nyelvekkel is sokkal könnyebb az élet.

--
joco voltam szevasz

A Visual Studio C# esetén tényleg nagyon jó, de C++-nál már messze nem annyira.
Az IntelliSense nálam rendszeresen összeszarja magát, vannak cpp fájljaim ahol egyáltalán nem működik a kódkiegészítés, de még nem jöttem rá, hogy miért...

Vicces, de igaz, hogy a QtCreator sokkal jobb (pedig csak 1-2 éves a project).
Egyedül talán a debug része jobb egy kicsit a VS-nek.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Érdemes.
Én most már használtam gcc-vel és VC-vel is, ugyanaz az érzés.
A debugger is használható, egyedül az "egeret ráviszem a változóra és látom a tartalmát" dolog nem működik olyan jól, min VS-ben.

Illetve van ez a debugging helper ami jól jön, ha bele akarsz nézni mondjuk egy QList-be, aminek a valódi szerkezete ezt gyakorlatilag lehetetlenné teszi normál debugger-rel. Csak ez hajlamos nem működni... :(

Ami hatalmas előnye a Creatornak az a gyorsaság: pl hihetetlen gyorsan beindexeli a fájlokat. Beírok egy include-ot, és a következő sorban már működik a kódkiegészítés, míg VS-ben várnom kell vagy fél percet mire ha szerencsém van, akkor elkezd működni...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

( andrasf | 2010. 03. 29., h – 23:08 )

.netben nincsenek layout managerek ha jól tudom (és ha ez számít valamit)

( uid_15426 | 2010. 03. 29., h – 23:43 )

En mindenkeppen .Netben csinalnam a GUIt, ezerszer fejlettebb (van tapasztalat mindkettoben). Rengeteg kesz kontroll, grid, konyvtar, layout, kb. 10x-es a sebessegkulonbseg a Qt es a .Net alapu GUI-fejlesztesben. Es a legtobb idot a GUI veszi el, nem a backend, ilyen az elet. Ja, most WPF-re gondolok, nem Winformsra, persze, Winformsszal ne foglalkozz. A Qt igazi pain in the ass, olyan ezoterikus bugokat tud produkalni, hogy az elkepeszto.

Esetleg azt is fontold meg, hogy a GUI-t C#-ban irod, hiszen a WPF-hez mindenkepp menedzselt kodra van szukseged, szoval legfeljebb managed C++-rol lehet szo.

En meg azt is atgondolnam, hogy biztos-e, hogy C++-ra van szukseg a szamitasigenyes oldalon. A JITter csomo feladatnal gyorsabb kodot tud generalni a futasideju optimalizalas miatt, mint a C++ compiler. Annyi, hogy meg kell tanulni a VM haklis dolgait - pl. el kell kerulni a GC leterheleset, egyebek. Es meg azt is vedd bele, hogy a menedzselt kodot joval gyorsabb fejleszteni (tobbszor gyorsabb).

Ha az algoritmus magja jol korulhatarolhato, kompakt es sok lebegopontos szamitast igenyel, akkor C++-ban megcsinalnam, a tobbit .Netben.

Persze ha erzelmi alapon allsz a fejleszteshez, illetve azok alapjan, hogy 'miket hallottal', akkor mindez irrelevans. :)

----------------------
while (!sleep) sheep++;

"A JITter csomo feladatnal gyorsabb kodot tud generalni a futasideju optimalizalas miatt, mint a C++ compiler."

Az az igazság, hogy ez maximum speciális benchmarkokon jön ki, valós projecteknél soha.

A managed nyelveknek van egy hatalmas hátrányuk, és ez a memóriaéhségük. Amire sajnos nem lehet legyinteni, mondván, hogy vegyél még 2 GB ramot, mert sajnos a proci cache-ét már nem tudod növelni. A magasabb cache miss szám pedig mérhető lassulást okoz, a JIT és a managed környezet minden előnyét könnyen eltünteti.

"el kell kerulni a GC leterheleset, egyebek"
Gondolom using és társai. Itt is látszik, hogy ha gyors kódot akarsz, akkor elkezded nem használni azokat a feature-öket, amik miatt eredetileg a managed környezetet használtad, és amik miatt könnyebb kéne hogy legyen a fejlesztés.

Személyes véleményem egyébként, hogy túlértékelik a GC-t:
Egyrészt a GC-nek hála, az alkalmazás lényegesen több memóriát foglal, mert:
- az adatok használat után is a memóriában vannak amíg a GC rájuk nem néz
- ha a megszüntetendő objektumok destruktorral rendelkeztek, akkor minimum 2x kell a GC-nek ránézni, mire megszűnnének
- egy csomó többlet információt kell tárolni az adatok mellett
- a GC jobb esetben csak akkor takarít, ha a programban szünet van, viszont egy komoly számítás közepén ilyen nincs, azaz csak foglalódik a memória megállás nélkül

Ezzel szemben C++-ban én többezer soros kódokat írok egyetlen delete nélkül, és nem, nem szivárog sehol a memória.
A trükk az, hogy modern/rendesen tervezett C++-os libeket kell használni (pl Qt ilyen, de van még sok), és a saját kódoknál is használni kell a lib-ektől ellesett trükköket.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

"A managed nyelveknek van egy hatalmas hátrányuk, és ez a memóriaéhségük. Amire sajnos nem lehet legyinteni, mondván, hogy vegyél még 2 GB ramot, mert sajnos a proci cache-ét már nem tudod növelni. A magasabb cache miss szám pedig mérhető lassulást okoz, a JIT és a managed környezet minden előnyét könnyen eltünteti."

Igen, ez teny. Ezert vetettem fel, hogy esetleg a numerikus reszt meg lehet irni nativ C++-ban, es a vegeredmenyt siman (=nem tul nagy faradtsaggal) at lehet tolni a megjelenito resznek. Ez attol fuggoen ertelmes vagy nem, hogy mennyire bonyolult a vizualizacio. Nehany grafikon es tablazat miatt valoszinuleg nem kevernek bele .Netet, de komolyabb feluletnel megerheti, hogy kell par napot foglalkozni a marshalinggal.

"Gondolom using és társai. Itt is látszik, hogy ha gyors kódot akarsz, akkor elkezded nem használni azokat a feature-öket, amik miatt eredetileg a managed környezetet használtad, és amik miatt könnyebb kéne hogy legyen a fejlesztés."

Az using sajnos nem segit eleget, ennel jobban at kell gondolni a dolgot. :/

A GC-t tenyleg meg kell tanulni, de azert lehet hasznos.

Egyszer reszt vettem egy neuralis halos (stb.) projektben, harom fejleszto, 150e sor C++ kod -- en ugy ereztem, hogy a fejlesztesi idot harmadolhattuk volna, igy tobb ido maradt volna a kutatasra, ha mondjuk Java-t hasznalunk (az algoritmus meg mondjuk egy honap helyett 40 napig futott volna, de fel evvel hamarabb indult volna a futas..).

Mindezek mellett nagyon szeretem a C++-t, foleg a templatek miatt, de a fejlesztesi sebessege es a library-valaszteka joval alacsonyabb.

----------------------
while (!sleep) sheep++;

A Javahoz elég sok lib van, ez tény, bár pont ilyen "neuralis halos (stb.) projektben" ezekből szinte semmit nem lehet használni...
Bennem fel nem merülne, hogy egy számolós projektet Java-ban kezdjek, mert bármit amit esetleg máshonnan használnék tuti, hogy C-ben (vagy fortran-ban C felülettel), vagy ha mázlim van C++-ban találok meg (bár ez néha nem mázli :) )

Én abban sem hiszek, hogy sokkal gyorsabb lenne a fejlesztés Java-ban, vagy C#-ban. Jól kitalált felületekkel nagyon hatékonyan lehet C++-ban fejleszteni. Az igaz, hogy ezek sajnos ritkák.
De még mindig kevesebb meló egy C-s libhez jó wrappert írni, mint Managed C++-szal P/Invoke-kal, meg jni-vel szórakozni...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

"A magasabb cache miss szám pedig mérhető lassulást okoz, a JIT és a managed környezet minden előnyét könnyen eltünteti."

erre tudnal adni valami forrast? erdekelne

"- az adatok használat után is a memóriában vannak amíg a GC rájuk nem néz"

a malloc is kb igy mukodik a hatterben :)

--
NetBSD - Simplicity is prerequisite for reliability

Komolyan nem értem az ez irányú kételyeket.

Ahol nagyon komolyan szükség van sebességre, ott még a malloc/new használatát is kerülni kell, esetleg saját, spéci memoria-managerre van szükség.

Órajelben néha ki lehet mérni, hogy egy pointerre szögletes zárójellel (c[i]), vagy pointer aritmetikával ( *(c+i) ) hivatkozol, legalábbis szarabb fordítóknál.

Ehhez képest a VM, a GC annyi adminisztrációt hoz már elvben is, hogy az elképesztő.

Az pedig, hogy a malloc hogy működik a háttérben, erősen oprendszer és lib függő.

Ezeket az optimalizaciokat azert _altalaban_ egyetemrol kiszabadult sracok szoktak alkalmazni, a vegeredmeny pedig altalaban gyengebb, mintha tiszta kodot irtak volna, jo algoritmusokkal. Ez nem rad vonatkozik, es vannak esetek, ahol esetleg tenyleg szamithat a pointer aritmetika vagy a sima indexeles kulonbsege, de a legtobbszor ezek csak elmeletek.

A VM es a GC elvben, elsore lehet, hogy plusz adminisztracio, de pl. a memoriafoglalas koltsege Javaban kozel 0. (A felszabaditase persze nem, de azt peldaul utemezheted akkorra, amikor nincs epp mas teendo). A Java JITter pedig tenyleg okos - a Microsoft meg nem annyira. Nezz meg egy JITtelt assembly kodot, amit mar jol optimalizalt a Hotspot -- olyanokat megcsinal, amire forditasi idoben eselyed sincs (a legkulonfelebb loop unrollingok, cache optimalizalas, etc.)

Szoval tovabbra is elhiszem, hogy neked a C++ a legjobb valasztas (jelenleg en is azt tolom, mert pl. halozatrol erkezo adatot betolni a managed kornyezetbe nem mindig idealis), de kozel sem ennyire fekete-feher mar a vilag.

----------------------
while (!sleep) sheep++;

Ha ilyen kérdések nem merülnek fel, akkor nincs értelme C/C++-szal szívni, szvsz.
:)))

Pl. képen gyors pixelműveleteket nem tudom hogyan lehet pointerek nélkül csinálni. Leginkább sehogy, vagy nagyon lassan. Java-t nem tudom, de egy jól megírt C# elemi képfeldolgozó kód 1.5-5x lassabb, mint az alig optimalizált C++-os változata.

Oke, a kepfeldolgozas az szigoruan numerikus feladat, ahol az adatok altalaban negyzetes strukturaja miatt meginkabb megeri C++-ban kodolni. Mondjuk egy nem tul primiv neuralis halonal(tehat nem 1+2 retegu, elorecsatolt backprop halora gondolok, amit lenyegeben egyszeru matrixszorzasokkal szimulalsz / tanitasz, hanem mondjuk valami 'komolyabbra') mar kicsit mas a helyzet, siman lehet, hogy adott fejlesztesi ido alatt gyorsabb szoftver az eredmeny.

Nade: probaltal mar teljesitmeny-kritikus alkalmazast irni menedzselt kodban (nem primszamkeresore gondolok)? Csak kerdezem.

Meg mielott tovabb tepnem a szamat: nem gondolom, hogy a C++-nal lehet (lenyegesen) gyorsabb kodot irni menedzselt kornyezetben. A kerdes az, hogy C++-ban sikerul-e tenyleg optimalis kodot irnod, illetve hogy a megoldando feladat egesze hamarabb kesz lesz-e es gyorsabb lesz-e, mint C++-ban. Es itt most nyilvanvaloan olyan feladatokra gondolok, ahol komoly UI van, hiszen innen indult el a beszelgetes, nem altalanos C++ / etc. osszehasonlitasokbol.

----------------------
while (!sleep) sheep++;

"Ezeket az optimalizaciokat azert _altalaban_ egyetemrol kiszabadult sracok szoktak alkalmazni, a vegeredmeny pedig altalaban gyengebb, mintha tiszta kodot irtak volna, jo
algoritmusokkal. Ez nem rad vonatkozik, es vannak esetek, ahol esetleg tenyleg szamithat a pointer aritmetika vagy a sima indexeles kulonbsege, de a legtobbszor ezek csak elmeletek."

Csak erre reflektaltam, hogy ezek nem elmeletek, hanem gyakorlatok. ;-)

"A magasabb cache miss szám pedig mérhető lassulást okoz"
Ezt gondolom nem kell magyarázni. :)

Az egészre meg nincs konkrét forrásom, de ha megnézek bármely komolyabb benchmarkot (ami nem megy rá mondjuk arra, hogy hány objektumot tudsz létrehozni másodpercenként), illetve elfogadom azt, hogy a JIT hatékonyabb kódot generál, akkor nem marad más magyarázatom arra, hogy a C++ miért tud gyorsabb, vagy ugyanolyan gyors maradni mint a java...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

"elfogadom azt, hogy a JIT hatékonyabb kódot generál"

Ne fogadd el, mert a JIT jo esetben ha pont mazlid van akkor tud a te platformodra jo kodot generalni, ami egyebkent a szegeny kokori c++-nal (szinte szegyen, hogy azzal akarjak mindenhol osszehasonlitani) ujabb statikus nyelvnel pontosan ugyanugy megteheto.

Szinte erzem a felhordulest a sok Java szakitol, ugyhogy inkabb arra kernem oket, hogy a felesleges szalak helyett most inkabb szivesen hallanek egy osszefoglalot arrol, hogy a Java hol es miben gyenge, milyen projekteknel nem hozta az elvarasokat, stb. A kudarcokbol ugyanis tobbet lehet tanulni mint a majmolt sikersztorikbol. Ha mar ennyi szaki van itt, hasznaljuk oket, akkor tanulunk is.

"Ne fogadd el, mert a JIT jo esetben ha pont mazlid van akkor tud a te platformodra jo kodot generalni, ami egyebkent a szegeny kokori c++-nal (szinte szegyen, hogy azzal akarjak mindenhol osszehasonlitani) ujabb statikus nyelvnel pontosan ugyanugy megteheto."

Azért ez nem ilyen egszerű.
Tényleg van, hogy a JIT hatékonyabb kódot generál, egyszerűen azért mert több információ van a kezében. Erre példák is vannak. Több oldal is van a neten, ahol beharangozták már a C++ vereségét, mert találtak egy kódot ahol a Java gyorsabb.
Az egy más kérdés, hogy már más bechmarkoknál sem jön ki ez az előny, konkrét nagy projecteknél meg kb soha...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

( blr v | 2010. 03. 30., k – 00:29 )

C++ és .NET?
Akkor inkább C#-ban gondolkodj. (Vagy Managed C++-ban, de annál azért a C++/Qt jobb megoldás.)

( bocs | 2010. 03. 30., k – 00:53 )

_nagyon_ számításigényes cuccokat csinálunk Qt-vel, visual studio-val, CUDA-val
alapvetően egy nagyon-nagyon jó minőségű toolkit ez, de néha látszanak a hátrányai

.net mellett szól
- ha már komolyabb rendszert akarsz benne összerakni (>300kloc), akkor Qt/c++-ban neked kell megírni pl. property-ket, databinding-ot, introspecting-et, szépen mindent az alapokról, amit a .net nyelvek nyújtanak. Ez talán inkább GUI intenzív alkalmazásoknál jön elő, ott viszont több év alap library fejlesztési munkát spórolhat neked a .net
- layout rendszere a Qt-nek valahogy nem intuitív, iszonyú időt rabol el a komponensek össze-vissza átméreteződése, nem lehet rájönni a logikájára

Qt mellett szól
- többplatformos! linuxra átteheted a rendszered pl egy klaszterben futtatva, és ingyen van minden szoftvered hozzá. ez a mai "cloud" buzzword miatt döntő lehet.
- kiforrott párhuzamosítás támogatása van (OMP), míg .net-nél párhuzamos futtatás támogatás most lép be
- Elég jó a c++ CUDA támogatása, pl debuggolható. Alaposan nézz utána, mennyire jó a .net CUDA támogatása, mert ha ez nem OK, akkor falnak mész.

signal slot az egy primitív, funkcionális módszer az eseménykezelésre. nagy rendszernél már a könyöködön jön ki, hogy 555-ször kell megcsinálni:
- editbox változásra slotot csinálni
- abban kiparsolni az editbox-ból az értéket
- az értéket besettelni valami osztály példány memberének
- frissítést hívunk 1,2,3,4 objektumra

ellenkező irányú frissítésre ugyanez még egyszer, plusz lekezelni hogy ne legyen hurok a frissítésben

ehelyett databinding:
x objektum z property-je legyen összekötve y objektum w propetyjével és kész

igen sokat lehet vele spórolni

Lehet, hogy én nem csináltam még ennyire perverz felületet, de nekem a Qt layout teljesen jól működik.
Néha mondjuk 3 szintnyi layout kell hogy azt kaptam amit szeretnék, de utána hiba nélkül méreteződik. WinForms-nál biztosan fényévekkel jobb.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

A tizedet sem irtad le a borzaszto nagy Qt elonyoknek, de termeszetesen amiket leirtal, azok nagyon nagy elonyok :-) Mindamellett a Mono linuxon nem eleg jo, es sokat bugzik meg mai napig is, ugyhogy, ha cross-platform megoldas kell a legkonnyebben, akkor Qt, ha csak kindoz, akkor viszont a .NET szerintem nyerobb lehet.

http://djszapi.homelinux.net

( tr3w v | 2010. 03. 30., k – 08:54 )

Ha azt kérdeznéd, hogy C#-.Net, vagy C++-Qt, akkor még lehetne érvelni,
de a C++-.Net nem embernek való.

A managed-sima C++ keverésével óriási nagyokat lehet szívni. Amit viszont nem nagyon tudsz elkerülni ha külső lib-eket használsz, már pedig gondolom biztos fogsz mátrix libeket és hasonlókat használni...

Pont most volt egy project amit C#-ban kezdtünk, számolgatott is dolgokat, nagyrészt C++-ban, működött is, de annyit szívtunk vele mikor máshol is futtatni akartuk, illetve a .Net i18n támogatása olyan hihetetlenül nevetséges, hogy átírtuk az egészet Qt-ra.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Szerintem már az egész rendszer gáz kicsit, de arra például nem jöttem rá, hogy hogyan lehet a már létrehozott form összes stringjét frissíteni nyelvváltásnál...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Cirka 10 perc alatt implementáltam egy ilyen megoldást - úgy, hogy nem vagyok desktop fejlesztő, ez volt életem kb. tizedik WebForms alkalmazása. Tény, hogy nem túl elegáns megoldás (meg a példa-applikációm is elég Móricka-alkalmazás volt), de azért ez miatt nem írnék újra semmit egy teljesen más platformon... De ti tudjátok. :) A kibicnek semmi sem drága, ugye.
A késésért én kérek elnézést, sajnos van saját, valódi életem, nem tudom minden időmet a hup-on tölteni. :)
--
geri / otperc.net

Nem ezert mondtam, apr. 1.-i trefanak jo az otlet, semmi egyeb masra nem jo. Egy 10-15 kontrollos ablakocskanal meg talan megoldas, de komplexebb alkalmazasnal akar ket percet is elhomokorazhat ha igy akarsz nyelvet valtani. Raadasul rengeteg esetet le kell kezelni, szoval nem biztos, hogy a legjobb dolog csak vegigmaszni egy List elemein.
-- 


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

A mi alkalmazásunk nem túl komplex, de _nem_vagyok_hajlandó_ egyenként végigmenni az összes form összes stringjén, és frissíteni. Azért használok fejlett UI-t és magas szintű nyelvet, hogy ilyeneket ne kelljen.
Hogy a rengeteg plusz hibalehetőségről ne is beszéljek amit egy módosítás hoz magával.

Én egyébként megoldottam úgy, hogy kilőttem a fő formot, és újra létrehoztam,(azaz lényegében újraindult a program). Működik, csak undorító.

Nem ez volt egyébként a fő oka a váltásnak, ez csak az egyik...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

A Qt3-as részt gyorsan el kell felejteni, a maradéknak meg egyetlen előnye lehet, hogy magyarul van, de egyrészt az már nem kezdőknek szól, másrészt magyarázat nélkül van.

A Qt hivatalos dokumentációja egyébként igen jó, én azt javasolnám inkább.

Szerk:
Kezdőknek inkább ez:
http://people.inf.elte.hu/gt/eva1/eva1.html

De csak akkor, ha egy szót sem tud az illető angolul...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

( sz332 v | 2010. 03. 30., k – 14:33 )

Nem lehet elosztott rendszert használni? Igy azt az időt, amit kód hegesztéssel/javítással töltötök,
meg lehetne spórolni...

( asch v | 2010. 04. 05., h – 19:12 )

Mielőtt optimalizálsz, lődd be a célplatformot és a probléma méretét is. Simán kiderülhet, hogy Javában vagy C#-ban is meg lehet csinálni, és az is, hogy ASM-ben sem.

Azután döntsd el, hogy a programod melyik része teljesítménykritikus, és ennek milyen interfésze van a - természetesen - nem teljesítménykritikus nyomogatós felület felé. 99%, hogy teljes mértékben megfelel a menedzselt programnylev a GUI megírásához.

Érdemes lehet a teljesítménykritikus részből egy erősebb hardveren magasabb szintű nyelven prototípust csinálni (erősebb vasra), ezzel idejekorán ellenőrzöd az interfészeid működőképességét, és demozni tudod a rendszert a megrendelő felé.