Staňte se programátorem: Jak na C# pod Linuxem

Článek by se mohl věnovat trošku více první půstění mono. Jaký si mám vytvořit projekt a kam vkládat svůj kod.

Preco sa na vyvoj multiplatformnych aplikacii pouzivaju vseliake pseudojazyky ako C#, java a pod. Je problem vytvorit nativnu aplikaciu ?

Nokia od marca vyda QT pod LGPL. Difam ze sa potom vyskytne viac nativnych multiplatformnych aplikacii.

Ak by si mal realne skusenosti s vyvojom komercnych aplikacii tak by si vedel, ze pisat v "nativnom" jazyku oproti C# ci Jave je neproduktivne.

tak tomuto nerozumiem.

Podla teba napr. v delphi, ktore generuje nativny kod sa pomalsie vyvija ako v jave ?

Je jedno co jazyk/IDE generuje, dolezite je mnozstvo prace, ktoru treba urobit aby bola aplikacia multiplatformova.

presne tak, skus si niekedy v netbeans urobit vacsiu aplikaciu a pochopis

a hlavne NET v kombinaci se C# je jeste dal nez Java

takze radsi zkus obe platformy at muzes srovat a vybrat si

Myslis treba tim ze je oficialne jenom pro win32 a porty jako mono nemaj naimplementovany uplne vsechno? :D

to nemeni nic na tom ze to je efektivnejsi nez java

vecina firem radeji udela aplikaci pouze pro windows za tretinovy cas nez vytvaret multiplatformni aplikaci 3x tak dlouho. Protoze leckdy pak naklady prerostou potencionalni vydelek z potencionalnich jinych platforem.

Reknu priklad... nova verze Photoshopu kdyby ji psali i pro linux by stal treba 20% nakladu na vic. To znamena aby se to vyvazilo, musela by byt kazda pata prodana kopie ve verzi pro linux. To je nerealne, domaci uzivatel ktery nechce platit za system windows protoze je "drahy" si jen tezko koupi photoshop ktery stoji jeste vice. A vyvojova studia, graficka studia nebo marketingove agentury jiz pravdepodobne pouzivaji Mac OS nebo pripadne windows, takze ty uz svou licenci do OS zaplatili a tezko by skrz to prechazeli jinam jen proto ze nova verze Photoshopu je dostupna i pro Linux. samozrejme je to jen priklad a zrovna Photoshop je velice uzce specificky program ktery tuto kalkulaci jen podtrhuje, jiste by se nasli jine priklady kde naopak rozsireni na jine platformy prinese vyssi zjisky protoze potencionalnich klientu na Linuxu by bylo hodne a samotna implementace verze pro linux by treba tak draha nebyla (muzeme mluvit treba o jednodusich aplikacich typu IM messangeru). To uz je pak spise neschopnosti managementu nebo nejakym lobingem jinych spolecnosti, pripadne neschopnosti vyvojarskeho teamu.

Navic uvedeny priklad nemluvi o multiplatformni aplikaci jako takove, ale spise o verzi aplikace dostupne pro jiny OS. Nicmene to spolu muze uzce souviset. Napriklad nebudu programovat databazovy engine v Jave, protoze jeho rychlost by asi nebyla takova jakou bych ocekaval. Nebo se muze jednat o tolik specifickou cinnost ze funkce zajistujici kompatibilitu se vsemi OS by byli na naprogramovani tolik slozite, ze cas potrebny k jejich naprogramovani by presahoval cas programovani jednotlivych verzi.

Jeste doplnim, zamozrejme .NET framework je v podstate zase jen nastavba mezi aplikaci a OS a do strojiveho kodu se to preklada az na samotnem operacnim systemu. Ale zrovna tahle "aplikace" je prizpusobena vola integrovane funkce operacniho systemu a diky tomu je to i pri realtime prekladu velmi rychle, protoze preklad se provede rychle a pak uz se to preklada primo do strojoveho kodu.

Java je v podstate totez, ale je to klasicka aplikace, velice to pripomina spise emulator nez nejaky preklad.

Mono jsem nezkousel, ale pokud je dobre postaveno a dobre si poradi s nestandartnima funkcema pro windows i na Linuxu, muze byt vysledek velmi dobry. Tuhle zalezitost ale na linuxu neznam a nevim jakych dosahuje kvalit. Kazdopadne pokud je implementace dobra, muze to byt velmi dobra alternativa pro vytvareni ruznych verzi pro ruzne OS.

...sakra... to nemelo byt sem...

V současné době je implementovaná většina z .NET Frameworku 2.0 (až na pár problematických částí). Dále podpora některých částí z .NET 3.0/3.5 (více viz. web projektu). Pracuje se na implementaci Silverlightu, apod. Celkově se s tím pracuje velice dobře.

ano, presne tak.

Delphi je dnes pro vyvoj jiz zastaraly jazyk. (delal jsem leta v Delphi a ted v C#)

V QT sa multiplatformove aplikacie (napr. http://tora.sourceforge.net/... ) , ale aj tak musi existovat verzia pre kazdu platformu zvlast. Java a .NET su v tomto ovela vyhodnejsie, Ten isty .jar subor je mozne v 95% pripadov pustit na vsetkych podporovanych platformach.

Tak ja radsej skompilujem zvlast aplikaciu pre kazdu platformu, aku potrebujem (je to jednorazove) ako potom stracam vykon a pamat na interpreter byte-code jazyka (java, python, C#....)

Ano, ale to zalezi na konkretnej aplikacii. Dnes je to na uvazenie. Ked programujem v C++, tak dostanem +- to, co si napisem, zalezi na kvalite kompilatora, ako dokaze zoptimalizovat kod. Pre kazdu platformu si teda musim robit optimalizacie sam. Cize je otazne, ci dokazem napisat rychlejsi kod v jave, kde optimalizacie robi java runtime alebo v C++ za pomoci nejakej kniznice. Dolezite je aj IDE, v ktorom sa aplikacia programuje a Eclipse, Netbeans alebo Visual Studio su velmi kvalitne.

Pre kazdu platformu si teda musim robit optimalizacie sam -> a to ako preco ? ved sa ma pouzit nejaka multiplatformova kniznica, ktora riesi platformove zavislosti

V zasade ani tak nezalezi na tom, ci je home adresar v /home/user alebo v c:\Users\user (aleco c:\Docments and Settings\User), ale na specifikach danej platformy, ina sprava pamate, ina sposob prace s diskom a pod. Toto nevyriesi ziadna kniznica. Niektore veci sa z hladiska vykonu jednoducho musia robit inak.

V tejto oblasti nemam velke skusenosti, opravte ma niekto, ak sa mylim

Praca s diskom a pamatou je u desktopovych aplikacii rovnaka na oboch systemoch.

Na oboch kterych systemech? Myslis Win32, Mac os X/Intel, Mac os X/PPC, Solaris/Intel, Solaris/Sparc popripade OS/2?

Na uplne vsetkych systemoch. Kazdy system ma funkcie open, close, read, write...... Tie sa viac menej rovnako pouzivaju vsade. Rozdiely moze tiez zastriet nejaka libka (libc trebars). Beznym desktopovym aplikaciam takyto pristup staci...

Rozdiely medzi systemami vznikaju az pri volani specifickych funkcii ako mmap, nastavovanie prav ci acl a pod. Ale 95% desktopovych aplikacii co sa bez toho zaobide.

Vzhledem k tomu, že C++ nativně nepodporuje Unicode, může být i ten open problém, natož pak zpracování textového souboru. Java i C# tohle mají nativně v sobě, což jsou ty detaily, které těmto jazykům umožňují obrovskou produktivitu.

je videt, ze o NETu nic nevis!

Aplikace (nevizualni) napsana v NETu je ryuchlejsi nez aplikaci v nativnim Delphi.

Delphi ma problem, ze Borland usnul na starych instrukcnich sadach CPU. NET kompiluje aplikaci do strojovyho kodu az PRI spusteni KONKRETNI funkce za runtime a tech instr.sad ma (nebo bude mit) rozhodne vice nez jakykoliv nativni kompilator.

A dalsim faktem je i to, ze dnes uz je vykon pocitacu relativne dostatecny i na pomalejsi veci.

Ty zasa nevies nic o nizkourovnovych jazykoch.

Ano to je jasne borland mal vzdy najhorsie kompilatory.

Kompilator delphi sa zastavil na urovni pentia. Ale vznikli odvtedy nejake ine instrukcie ktore su vyuzitelne na desktope ? NIE! Mozno ze dokazu rychlejsie mazat/kopirovat pamat a to je asi tak vsetko.

SSEx, MMXx, 3Dnow su na multimedia/hry. ja som myslel skor kancelarske aplikacie. Tam ti postaci instrukcna sada i486.

no koukam, ze jste uplne mimo!

Borland mel NEJLEPSI kompilatory co se rychlosti tyce! Taky mel 100x lepsi memory management nez C++ veci od MS.

A Delphi kompilator se zastavil vicemene u 386

A diky bohu za to, ze nevim nic o nizkourovnovych kompilatorech (coz je assembler a ne Delphi), protoze dekuji nechci.

oprava: diky bohu za to, ze nevim nic o nizkourovnovych JAZYCICH...

NEJLEPSI mozno v case dosu ked bol turbo pascal/c.

Ale prichodom win to s borlandom slo dole vodou...

Jestli muzu dovolim si taky poznamku... ono opravdu je to sporne mate pravdu oba...

read write je sice vsude stejne a na disku se sice deje vsude to same, ale co treba si uvedomit problemy nejakeho filesystemu ktery dana platforma pouziva... FAT16 je velmi limitujici FAT32 je na tom o dost lepe, nicmene na dnesni dobu uz to taky je dost zastarale a i jeji limitujici faktory mohou v nekterych pripadech znacne narazit.

Faktem je ze v dnesni dobe jsou pocitace dost rychle, takze si muzeme dovolit nejakou tu knihovnu ktera se o rozdili postara a vyresi je za nas, misto do configu to nacpe nekam do registru, pripadne obracene... to je ale vedlejsi. Pokud bude vetsina vyvojaru postupovat tim, ze "dnes jsou stroje ktere tohle utahnou, tak proc to tak neudelat" tak se dostaneme tam kam se dostava herni prumysl... koupite si novy pocitac aktualne nejvykonejsi, date za nej pres 1 000 euro s tim ze je dost vykonej a tak mate na delsi dobu vystarano, pak prijde nejakej programator kterej si rekne, udelame graficke orgie a naprogramuje hru ktera na takovem pocitaci pojede s odrenejma usima, starsi pocitace maji smulu. Co je horsi za pul roku vyjde dalsi hra, ktera se zase chytne nejake novinky a nove technologie a pouzije ji do sve hry a vy presto ze mate super naslapanej stroj, tak si hru nezahrajete, ptrotoze nema potrebne technologie.

Dalsi veci je, proc budu delat multiplatformni aplikace, ktera pak bude hodne narocna a tim padem dosti uzivatelum ani nepojede a radeji sahnou po alternative ktera jim jede bez zateze procesoru. Chci rict, ano stroje na to jsou, zarizeni take, takze knihovna ktera se o to postara to rozcleni a urychli tak programovani, na druhou stranu celkem realne hrozi problem s narocnosti aplikace na slabsich PC. A pak teda pokud mam plnohodnotnou aplikaci pouzitelnou Windows ale nenarocnou spustitelnou i na starsim kusu HW a ja se rozhodnu udelat to multiplatformni, ale ve vysledku hodne narocne, tak hrozi ze spoustu uzivatelu na Windows ztratim a pocet zjiskanych uzivatelu u jinych platforem nenahradi ztratu zpusobenou na Windows. Jinymy slovy sice to bude rozsiritelnejsi, ale mene pouzitelne.

Vspomenme na legendarni Winamp 2.xx Do te doby temer neohrozeny a takrka bez konkurence, nasledne Nullsoft vydal verzi 3, ktera byla strasne narocna a i na novejsich pocitacich to vykazovalo jiste prodlevy i v relativne beznych ukonech. Vysledek byl ten ze hodne lidi zustalo u dvojkove verze, par lidi si nechalo novinkovou trojku a zbytek se poohledl po alternativach. Nullsoft pote vydal verzi 5 (casem) ktera tyhle nedostatky poupravila, nicmene si tak Nullsoft trosku posramotil povest a rada uzivatelu legendarni Winamp opustila a pouzivaji alternativu, protoze az tyto problemy jim otevreli oci ze Winamp neni jediny.

no mozna to je i tim, ze winamp 2 byl maly a kompaktni nastroj, 3 verze prinesla vice funkci, ktere mely naroky na ram i cpu i kdyz se vlastne nepouzivaly... dle meho toto prinutilo lidi odejit, neschopnost nepotrebne moduly vypnout! Pokud by byl w3 takovy jaky byl a mel by moznost nepouzite moduly vypnout a tim zcela modul odstavit, tim padem by to winampu prospelo (a kdyby se to dalo tahat jako jednotlive pluginy pres nejakeho winamp spravce... bylo by to gut)

toto byl muj duvod odchodu

stejny problem s nerem... pred 8 lety jsem si koupil pc, pote vypalovacku na CD za nekrestansky prachy. Byl k tomu SW nero, tehdy jeste pro W98, takze hnusnej, ale za to velice pouzitelnej. Postupem casu jsem stale upgradova a upgradoval, az jsem se dostal k nero 7 a misto 5MB baliku jsem zacal sosat 50MB (a porad to narustalo, s kazdou verzi jsem sosal vice a vice), pote 60 a dnes ma nero snad 300MB v zakladu (a dalsi veci se daji sosnout... no kdyz k tomu pridam manualy, tak se dostanu

na DVD). Proboha na co, ja chtel jen palit, vytvorit si obal a jeste byl kvalitni ten program na tvorbu vlastnich DVD... zbytek je nepouzitelna, proc bych si mel platit licenci na vypalovaci program a dostat k tomu rpogram na zalohovani, program na telefonovani po netu, program na editaci hudby... nechci TO!!! Muzu si najit kolikrat i lepsi alternativy a zdarma....

a toto byl muj duvod odchodu od nera (ps mel jsem koupene licence 5, 6 a 7)

Ano, ale myslel som vnutorne, metody na pracu so subormi alebo pamatou su rovnake. Mozno som zvolil zly priklad

Proste, zalezi na konkretnom pripade. Java/C# sa lahsie uci a je "blbovzdornejsia" ako C++, na druhej strane C++ je rychlejsi. Ale rychlost je nenic, ked si programator neustriehne pamat a aplikacia ma memory leak-y. Dalo by sa pokracovat, naozaj zalezi na type aplikacie a skusenosti timu, co ju programuje. Ale nemyslim si, ze zmena licencie Qt nejako zasadne ublizi jave alebo C#. Hlavne po tom ako Sun podrobil javu diete a M$ naucil .NET 3.5 LINQ ( http://en.wikipedia.org/wiki/Language_Integrated_... ... )

Nechapem ako vnutorne. Vnutorne v kerneli ? To nikoho nezaujima. Aplikacia komunikuje s kernelom prostrednictvom libc/c++ a tam je to rovnake.

To ze je java lahsia je diskutabilne. Nemozem povedat ze by niekto zvladol javu rychlejsie ako c++ builder/delphi.

Tie memory leaky sa daju tiez ustriehnut. Existuju tooly ako valgrind, mpatrol a pod ktore toto riesia. Takisto existuje kopec rozsirujucich kniznic pre c++.

Na zaver uvediem oblubenost azureus vs utorrent. Kazdy nadava na jeho pomalost a velku spotrebu pamate. .Net je na tom tak isto. nejake mini desktopove aplikacie sa daju ale nieco vacsie ako napr office si v tom nechcem predstavit. Staci vidiet aky je oofice bordel.

nevim jak je to s javou, zkousel jsem ji ale nic moc.

Rozhodne je C# a VS pro vyvoj aplikaci nejrychlejsi pro stare i nove programatory proti vsem prostredim ktere znam ... Delphi, C++ Builder....

Syntax C# je po 7 dnech prehlednejsi nez cokoliv jineho a hlavne jde o moznosti jazyka .... tem se cecko ani delphi nemuze rovnat.

Co se náročnosti využití systémových prostředků týče, je to C/C++, kterému se nemůže nic rovnat. Zatímco rychlost vývoje v C# nebo Javě je výrazně vyšší, běh aplikací u malých utilitek srovnatelný, co se třeba spotřeby paměti týče, tam není o čem diskutovat. C# nebo Java se tak dokonale hodí pro rychlý vývoj aplikací typu použij a zahoď.

Až se budou programy pro grafiku nebo třeba CAD systémy vyvýjet v C#, můžem o tom diskutovat.

ja takovy program vyvijim v C#.

a podvej se na projekt XNA.

http://msdn.microsoft.com/en-us/xna/default.aspx...

Doteraz som si myslel, ze hry su narocnejsie, kvoli dokonelejsej AI a grafike

Quake 6 bude urcite napisany vo VBScripte

No, ale vazne, nechce sa mi googlovat, existuju nejake benchmarky?

to nevim, ja verim jenom bencharkum z praxe ... tj. testuji to co delam ja v situaci kterou v praxi pouzivam.

Teorie ruznych teoretiku jsou vetsinou jenom teoreticke.

Štěstí všech PR oddělení je to, že se vždycky najde pár joudů, kteří žerou jejich marketingové plky i s navijákem. Neříkám, ře by v tom nešly udělat kvalitní plošinovky nebo závody autíček, ale tohle odpovídá tak stavu v roce 2000. Klidně dej link na ty benchmarky nebo hry srovnatelné třeba s posledními GTA. Se nemůžu dočkat. Jo, a změň si nick...

No u GUI aplikaci mas bezesporu pravdu, ale minimalne u Javy neni rychlostni problem v nicem jinem nez v pomalosti Swingu... Jinak enterprise aplikace co se pisou v Jave bych teda rozhodne nepovazoval za "pouzij a zahod"

Ked pises prispevky do diskusie, ujisti sa, ze si triezvy.

Syntax C# je po 7 dnoch prehladnejsi... Taky jazyk sa mi rozhodne paci, napisem kod, necham ho 7 dni nech vykvasi, vybubla a hopla mame tu prehladny syntax!

staci zdravy selsky rozum ...

ale ok, povim to polopatisticky i pro tebe:

proste pro novacka je jazyk C#, po 7 dnech prace s nejakym seniorem, naprosto bajecny jazyk.

Hm, cize, ked budem 7 dni s babkou rylovat zahradu, tak sa naucim C#?

Sorry, ale nedalo mi nerypnut si

Uz si skusal aj ine jazyky, alebo c# je prvy?

S puvodnim nazorem vicemene souhlasim a ano - uz jsem zkusil vicero jazyku. Kdysi davno na osmibitech jsem zacal s basicem, pres pascal se dostal k C a C++. Na skole jsme pricichnul k smalltalku, lispu a prologu. Ze zajmu jsem zkousel javu. Vetsinu sveho profesionalniho zivota jsem stravil s C++. Pote, co jsme si nejaky cas rochnil v kombinaci gcc + vim, tak jsem vyzkousel nekolik IDE (eclipse, anjuta, vide...) a pak dlouha leta travil nad C++ builderem a kylixem. Pres znacny odpor jsem byl v praci dotlacen do sveta MS k visual studiu a C#. Chvili jsem nadaval a nevidel na tom ani chlup dobry, po tydnu jsme prestal a po cca rocnim projektu v C# za pouziti VS2003 s resharperem jsme se vracel hodne nerad. Pozdeji jsme uz jen prechazel na vyssi verze VS a totalne propadl mezi MS fanatiky - aspon co se vyvojovych nastroju tyce. Ne ze bych nemel na co nadavat, ale kdyz to srovnam s cimkoliv jinym, co jsme zkusil a jeste obcas zkusim, tak jde o mimoradne dobre navrzeny jazyk a kvalitni prostredi. Co se tyce rychlosti - na zacatku jsem o tomto jazyce nic moc nevedel a veril, ze je to neustale interpretovani bytekodu. Napsal jsem si nekolik ruznych testu, kde melo jasne zvitezit C++. Typicky zvitezilo o nejaka 3%. Nejhorsi testy byly asi o 5% pomalejsi v C#. Co me ale tenkrat vydesilo, ze v pokusech, kde jsem intenzivne alokoval a dealokoval pamet, nebo kde jsem pouzival slozitejsi rekurzi, dokazalo o par procent zvitezit C#. Dneska, kdyz uz docela slusne znam slabiny tohoto jazyka, dokazu napsat priklady na prvni pohled ekvivalentnich kodu C# a C++, kde C++ zvitezi skoro o 10%. Ale taky dokazu napsat priklady spatne vymyslenych trid, kde diky nevypnutelne optimalizaci bude C# nekolikanasobne rychlejsi dokonce i bez ulozeni do GAC.

Samozrejme - dobre vymysleny a dobre napsany algoritmus bude vzdy rychlejsi a mene narocny na zdroje, pokud ho napiseme v asm, neznatelne horsi, kdyz bude v C, opet o trochu horsi, kdyz zacneme pouzivat C++ a jeho objekty, virtualni metody a o znatelny kus hure dopadnu, kdyz to zacnu psat v .NET. Jenze ta ztrata vykonu programu je v jednotkach procent a zisk na usetrenem case a tim i financich na vyvoj, je v desitkach procent. Je zapotrebi si vybirat spravne nastroje - pokud jde o RT system, tak pouzit neco s garbage collectorem proste nejde. Kdyz budu psat neco, co ma bezet na mnoha platformach, kde mi nejde v prvni rade o vykon, neni nad javu. Na vetsine aplikaci se ale neni treba ohlizet na to, jestli mam odezvu na stisk tlacitka milisekundu nebo dvacet. Ovsem koukam, jestli me vyvoj a zakaznika pak soft, bude stat o pulku vic, protoze se budu nimrat v optimalizacich, ktere nakonec nikdo neoceni. Ale C# a .NET nejsou nijak pomale - uz i pomerne narocna hra se s v C# napsat da, jak bylo jasne ukazano na projektu Quake II .NET. Vysledek je, co se tyce zatizeni CPU, prakticky stejny jako v pripade puvodni verze. Narostla pametova narocnost - o nekolik desitek MB, coz je sice dle meho nazoru hodne, ale da se.

Myslis ten ooffice ktery je napsany v C++? :D :D :D

oofice je mix vsetkeho mozneho.. hlavne javy

Prdlajz, jenom par veci tam je v Jave, viz http://wiki.services.openoffice.org/wiki/Java_and_OpenOffice.org... .Je videt ze varis z vody, takze dalsi debata je IMHO pomerne bezpredmetna. Hezkej vikend.

v .NET bude programovani narocnejsich aplikaci rozhodne pohodlnejsi nez v cemkoliv jinem.

Navic .Net neni jen o "cecku" ale nezapominejme treba na Visual Basic. S tim si opravdu poradi vicero zacatecniku nez C++. Po prelozeni vznika (mel by vznikat) stejny kod, takze vysledek by mel byt temer totozny.

Samozrejme pokud stavime neco kde jde primarne o rychlost pak je urcite na rade C a v kritickych castech primo assembler, ale to uz veskera multiplatformost jde pomalu ale jiste dohaje, protoze udelat mlutiplatformni aplikaci pak ji na linuxu optimalizovat v assembleru tak na 90% jinych strojich stejne nepojede.

Tak multiplatformost jde do háje i v případě .NET, ne?

ano, multilpatformnost je pouze marketingova navnada pro manazery

Třeba takové Visual Studio (zhruba polovina v .NET) a Expression Studio nejsou nijak pomalé aplikace (i když své nároky mají). Pokud si dobře vzpomínám, tak se při jejich instalaci generuje nativní obraz pro danou platformu (nástroj ngen.exe), díky tomu odpadá zdržování, které by způsoboval JIT kompilátor.

Konkretne LINQ to SQL mi připadá jako velmi vhodný kandidát pro SQL injection.

Pak je krásně vidět, že o tom vlastně mnoho nevíte. Pokud pro přístup k datům použijete LINQ (to SQL, to Entities), tak vám SQL injection nehrozí. Ovšem u ostatních providerů tomu tak být nemusí -> záleží na tom, jak je expression tree transformován na výsledný dotaz.

Pokud je dotaz přenášen standardním postupem přes "pojmenované trubky", příp. po TCP/IP protokolu - je problém dotaz po cestě odchytit a modifikovat nebo ne? Píšete, že o dané problematice nic nevím, ale můžete mi uvést pro své tvrzení argument?

Výborně. To je takový problém si ty informace dohledat?

Q. How is LINQ to SQL protected from SQL-injection attacks?

A. SQL injection has been a significant risk for traditional SQL queries formed by concatenating user input. LINQ to SQL avoids such injection by using SqlParameter in queries. User input is turned into parameter values. This approach prevents malicious commands from being used from customer input.

Z čehož vyplývá - sql injection není možné provést vstupem na úrovni parametru, ale úpravou dotazu na úrovni přenosu ano.

Navíc má tento přístup nevýhodu v tom, že je třeba pokaždé počítat exekuční plán, proč bychom nemohli zbytečně zvyšovat zátěž serveru?

To už ale není problém LINQ to SQL/Entities, protože tam k přenosu dat na server nedochází. Používají se standardní prostředky ADO.NET.

Co konkrétně není problém u problém LINQ to SQL/Entities?

Až na ten detail, že v .NETu nikdy žádnej interpreter nebyl (v Javě byl, ale myslím, že se by default nepoužívá). JIT kompilátor je poněkud efektivnější řešení.

Pletete jabka s hruškama.

C, C++, C#, Java... = JAZYKY

GTK+, QT, wxWidgets = GUI TOOLKITY (Frameworky)

Jsou možné různé kombinace, a to jak multiplatofmní, nebo ne. Pojem "nativni aplikace" je zavadejici. Co je na Windows nativni aplikace? QT to rozhodne neni, to je stack bezici nad MFC. Co je nativni aplikace na Linuxu? GTK+ aplikace, nebo QT aplikace? Existuje mnoho toolkitu.

Vas prispevek je o nicem.

Nativna aplikacia pre mna je taka, ktora priamo vykonava strojovy kod:

su to aplikacie napisane prostrednictvom C/C++/DELPHI......

NO a byte-code aplikacia je ta co ju vykonava nejaky interpreter ako napr JAVA, C#, python....

JAVA ani C# nejsou interpretery ale jazyky. Navíc MSIL bytecode se na cílové platformě kompiluje do nativního (kódu který zpracovává procesor) kódu pomocí JIT. Navíc .NET obsahuje Native Image Generator (ngen), který z assembly vytvoří nativní nativní aplikaci najednou.

A preco sa tento "nativny kod" rovno neulozi do .exe ? Preco sa kompiluje na cielovej platforme ?

Asi to az take ruzove nebude.

jak jsem psal jiz vyse, radsi zopakuju:

duvod je ten, aby se kod finalne "zkompiloval" pro instrukci sadu CPU primo na stroji na kterem bezi!!!

To znamena, ze tak dosahnete vyssiho vykonu nez u nativniho jazyka jakym je delphi, protoze Delphi nekompiluje instrukce do EXE souboru pro kazdy CPU na kterem app bezi !!!!

proste si zkuste napsat nejaky nevizualni test v Delphi v C++ a NETu ... spuste to na PC aspon 10x a sectete trvani z posldenich 7 mereni a budete koukat jak je C++ chciple, delphi taky nestiha a NET aplikace vyhrava.

(Samozrejme, netvrdim to obecne, zalezi i na konkretnim HW a typu ukolu, ale prevazne to takhle je, aspon dle nasich testu na nase typy aplikaci, ktere delame)

Vizualni apliakce jsou v NETu pomalejsi, protoze ani NET neni dokonalej a MS naprsoto blbe napsal obalky na standardnimi WinControls.

Jenomze na NETu mate Silverlight, WPF a XNA, takze jste zase dal o nekolik levelu proti jave, c++ a delphi a cemukoliv jinymu.

Zkoušel jste porovnat spuštění MSIL kompilovaného jen pro konkrétní procesor (32/64 bit) nebo zkompilovaný MSIL jen pro daný tep procesoru?

"Preco sa kompiluje na cielovej platforme ?"

Protože platofrmy se liší. Jiný kód (z pohledu instrukcí) bude pro x86, jiný pro Sparcy a v rámci stejné HW platofrmy by se lišil (z pohledu API, hlaviček atd.) i pro Windows a Linux. Tyhle rozdíly abstrahuje CLR resp. Mono (nebo JVM v případě Javy) tím, že kompiluje bytecode na cílové platformě. V podstatě je to jako místo aplikace distribuovat zdroják, ale MSIL se kompiluje rychleji než ze zdroják.

na 99 % bezi ta aplikacia na x86. preco potom neodlahcit cielovu platformu od kompilacie ?

jenomze instrukci sada nekonci u x86

Jak jsem psal, .NET Framework obsahuje Native Image Generator, se kterým se dá předkompilovat celou aplikaci a uložit výsledek do cache. S tím odlehčením to taky nebude taková výhra, protože JIT kompilátor kompiluje jen to, co zrovna potřebuje, takže po spuštění nekompiluje všechno najednou.

A jak psal vyznamse, instrukční sada x86 procesorů neustále roste. V nejhorším případě (starý kompilátor) je nutné C++ aplikaci zkompilovat nejen pro Windows / Linux / Solaris atd. ale navíc ještě varianty s MMX / SSE / SSE2... Moderní kompilátory umí vygenerovat kód pro většinu těchto rozšíření ale musí za běhu testovat, na kterém běží procesoru. Navíc jestli se nepletu, Intel tyto optimalize provádí jen na svých procesorech, takže když se zkompiluje aplikace s kompilátorem od Intelu a spustí na AMD, tak se to stejně neprojeví.

A těch 99% se mi zdá v době, kdy má každej nějaký ten komunikátor, trochu nadsazený číslo.

To jo, není jenom Linux a Windows, ale taky mobilní telefony, jsou taky SSE a podobný blbinky, pak taky 32bit a 64bit systémy, podle architektury se taky může lišit pořadí bitů, nebo bajtů v paměti - tohle všechno .NET a JAVA řeší. V případě C/C++ to musí řešit programátor.

A o výkonu se nedá říct, že .NET je pomalejší, než C++.

V c++, když napíšete for .... tak je to for a hotovo.

Když v C# napíšete foreach - tak kompilátoru dojde, že chcete projít všechny prvky a může (v závislosti asi na milionu další věcí) rozdělit tu činnost třeba na víc procesorů. takže by v tomhle případě byl nejspíš rychlejší .NET, než nativní kód v C++

> Když v C# napíšete foreach - tak kompilátoru dojde, že chcete projít všechny prvky a může (v závislosti asi na milionu další věcí) rozdělit tu činnost třeba na víc procesorů

A tak ked budem chciet cez foreach obratit poradie pola, poslat vsetky prvky po sieti alebo spravit hoc len sprosty ladiaci vypis do terminalu, stravim naslednym hladanim chyby tyzden

Velmo zly priklad, nastatie nepravdivy.

A co když budu chtít všechny prvky vynásobit dvěma?

Jak jste správně do svého příspěvku vložil mojí větu - v závislosti asi na milionu dalších věcí

PS: nevím jak pomocí foreach otočit pořadí pole.

Nemyslim, ze by bolo v moci kompilatora rozoznat, ci je vhodne a bezpecne vykonavat iteracie cyklu pararelne. A pole cez foreach... Vytvorim druhe pole a cez foreach cyklus don odhora nahadzem vsetky prvky povodneho. Ale to bol len priklad.

Ne tak docela. Parallel FX obsahuje konstrukce pomocí kterých lze programovat paralelní iterace.

for (int i = 0; i < 100; i++) {

a[i] = a[i]*a[i];

}

se může jednoduše paralelizovat pomocí anonymní funkce

Parallel.For(0, 100, delegate(int i) {

a[i] = a[i]*a[i];

});

Čitelnost sice utrpěla, ale nepochybuju že v někateré z dalších verzí C# to zabudují do syntaxe podobně jako LINQ. Každopádně uživatel bude ten kdo určuje, zda se blok bude vykonávat paralelně. Nedokážu si předdstavit, že by kompilátor pomocí nějaké heuristiky zjišťoval, jestli se dá cyklus vykonávat asynchroně :)

Pokud vím, tak by to mělo bejt součástí .NET 4.0

V nejhorším případě (starý kompilátor) je nutné C++ aplikaci zkompilovat nejen pro Windows / Linux / Solaris atd. ale navíc ještě varianty s MMX / SSE / SSE2... Moderní kompilátory umí vygenerovat kód pro většinu těchto rozšíření ale musí za běhu testovat, na kterém běží procesoru

Tak toto je blbost. Gentoo vam moze potvrdit ze rozdiel medzi aplikaciou skompilovanou pre mmx a bez mmx nie je ziadny rozdiel (ak tato aplikacia nema iste rutiny pisane v asm). Podobne je to aj u SSE /SSE2... Skratka aby sa vyuzili moznosti tychto instrukcii musi byt kod pisany v asm.

>> Tak toto je blbost. Gentoo vam moze potvrdit ze rozdiel medzi aplikaciou skompilovanou pre mmx a bez mmx nie je ziadny rozdiel (ak tato aplikacia nema iste rutiny pisane v asm)

http://www.gentoo.org/doc/en/gcc-optimization.xml...

... hm, mozno sa len nepozorne pozeram

Ale ten pripad to asi nebude, ak ano, tak by som potreboval vysvetlenie naco ma gcc parametre "-msse, -msse2, -msse3, -mmmx, -m3dnow", ked sa nedaju vyuzit, jedine ak sa priamo pouziju v asembleri.

neviem co tie prepinace robia.

ale skus si nejaku aplikaciu skompilovat s nimi a bez nich a porovnaj si vysledok....

rozdiel nespoznas.

Pise sa tam:

"These are useful primarily in multimedia, gaming, and other floating point-intensive computing tasks, though they also contain several other mathematical enhancements."

Cize prejavi sa to pri praci s multimediami, v hrach a vsade tam kde sa intenzivne pouzivaju vypocty s pohyblivou desatinnou ciarkou. Myslim si, ze aplikacie ako VLC by si absenciu hw podpory asi vsimli

V ostatnych pripach s tebou suhlasim, rozdiel si asi nevsimnes.

ale rutiny pre tieto aplikacie su pisane v asm ! a tymto to koncim lebo asi nema vyznam sa hadat s niekyk kto neovlada asm.

Já sice neznám operační kódy všech instrukcí, takže asi nic neznamenám :) ale podle Davida Notaria (CLR JIT Compiler Engineer), který asm zná, měla optimalizace MSIL kódu pomocí SSE2 vliv na počty v plovoucí čárce, kopírování paměti nebo konverze floating point čísel na celočíselné typy (double na int se zrychlil až 40x).

Jen doplním, že v C# z principu psát metody v assembleru pro konkrétní platformu nelze, takže ty oprimalizace prováděl JIT kompilátor.

Já netvrdil že kompilátory to umí lépe než člověk, já tvrdil že moderní kompilátory dokážou generovat alternativní kód používající instrukční rozšíření.

Java virtual machine ma dynamicky JIT compilator, ktory rekompiluje bytecode do strojoveho kodu, nativneho pre danu platformu. JIT moze vygenerovat casti kodu (v extremnych pripadoch cely kod), ktory velmi slusne konkuruje kodu kompilovanemu statickym kompilatorom. Python s PyPy (byvale psyco) ma tiez JIT kompilator, takze tazko hovorit o cisto interpretovanom jazyku.

Pokial chces mat supernativnu aplikaciu, chod do assembleru: ziskas procesor beziaci takmer naprazdno, poloprazdnu pamat, jediny, kto sa pri tom namaka, budes ty.

Huh?

Qt nemá s MFC absolútne NIČ spoločného...

Zrovna po iba zopar tutorialoch pre zaciatocnikov uvadzat rovno mono nieje rozumne.

Sice se clanek venuje C# pod linuxem, ale kdyz uz se vyuzilo Mona, je skoda, ze se prikladem neprezentuje to multiplatformni vyuziti programu Skoda no, mozna v pristim pokracovani

Teda mel jsem presneji na mysli, to ze program nebezi primo pod .NETem, ale je potreba jej spoustet pres Mono.