Natív vs CLR, managed vs unmanaged kód

[mapboy]

Sziasztok!

 

Mint programozót egyre inkább foglalkoztat mostanában hogy mit hoz a jövõ számunkra? Egyre gyakrabban hallani, hogy a Vistát követõ op.rendszer már csak managed kódot fog szeretni, és natív kódot csak emulált környezetben futtat. Vajon ez igaz, el fog tûnni a C/C++ és lesz Java,C#,J# meg hasonló managed precompiled kódot elõállító környezetek? De akkor miben lehet majdigazán erõforrásigányes programot írni, valljuk be a C#-ban lévõ GDI+ játszani jó, de képfeldolgozáshoz, játék íráshoz stb. ahol nagyfelbontású képekkel kell dolgozni, és minél többel "végezni" adott idõ alatt, nos ehhez alkalmatlan, ez saját tapasztalat, próbáltam irni egy olyan progit ahol 1-2GB térképeket kellett megjeleníteni és feldolgozni, de reménytelen volt valós idõben C# alatt. Eleve a pointerek hiánya - na jó tudom, hogy erõltetve azért még lehet használni - egy súlyos veszteség, minimum 2-3x gyorsabb egy algoritmus pointerek használatával.

Igazából épp most állok neki egy nagyobb projectnek, és már most is elgondolkodtam, vajon miben álljak neki, C++-ban biztos gyorsabb lenne a program, de akkor majd irhatom újra késõbb ha pl. Vistán is futtatni akarom, és ki tudja meddig lesz még benne a "hagyományos" - nem CLR - C++ a Visual Studio késõbbi kiadásaiban? Vajon eltûnik a natív kód, vagy jól megfér a CLR nyelv mellett?

[Calyd]

Hali!

 

Kifejtenéd bõvebben, hogy mi is a natív illetve a CLR közti különbség? Ezzel egyelõre nem vagyok gépben.

De, hogy a témához is szólják (bár a fent említett kérdés miatt kisség laukisan), nehezen tudom elképzelni, hogy ne a gyorsaság lenne a jövõben a szempont... Bár gondolhatják úgy is a nyelvek fejlesztõi, hogy már olyan teljesítményekkel rendelkeznek a gépek, hogy felesleges ennyire kukacoskodni a gyorsaságon. Minden esetre érdekes a felvetett probléma...

[mapboy]

CLR = Common Language Runtime

 

Arról van szó, hogy a forrsákódodat a forditó egy ún. köztes kódba fordítja (MSIL kód) és csak futás időben fogja a processzor számára értelmezhető natív kóddá "konvertálni". Előnye, hogy amennyiben ez a JIT (JIT = Just-In-Time) forditót (ez a JIT forditót úgy ismeri e legtöbb felhasználó, hogy .NET FrameWork) megirják több oprendszerre, úgy a progid ezeken is futni fog mindenféle változtatás nélkül, bár ehhez az kell, hogy semmilyen hardver specifikus algoritmust ne használj, pl. ha a DirectX-hez nyúlsz akkor az már ilyen. És ez a hátránya is, vagyis, hogy nem igazán tudsz "lenyúlni a mélységekbe", pl. grafikához "használd a GDI+-t hiszen az olyan jó", nos ez hangzatos de nem teljessen igaz, mert lassú és feleslegessen memória zabáló. Illetve gondolom mindenkinek egyértelmű, hogy eleve csak lassabb lehet egy program futása a valós időben történő fordítás miatt, sőt a .NET keretrendszer nem csak egyszerűen lefordítja, hanem ellenörzi is, ez persze biztonságosabbá, felügyelhetőbbé teszi a futást, de még lassabbá is. Egyébként ezért hívják managed kódnak, mert felügyelt futás közben.

 

Egy kis ábra:

 

 

Forrás kód ------------------ Byte kód --------------------- Natív kód

 

------ C# forditó ------------------------- CLR

C# --------------------->MSIL Code -----------------> native code

------ fordítási időben ----------------- futás időben

 

A sok'-' jel csak azért kellett, mert a fórum motor kiszedte a space-eket.

 

Egyébként sajnos azt hiszem tévedés azt hinni, hogy a sebesség fontos szempont a nyelvek megalkotásánál, ahogy a végén irtad is, úgy gondolkodnak, hogy majd tesz alá a felhasználó erősebb vasat. Ja és ilyen a Java és a Basic is, és eddig tudtommal nem is igazán irtak -illetve nem is akartak - ezeken a nyelveken nagyon erőforrás igényes progikat irni, vagy hardverközelit.

 

Ja és félreértés ne essék ezek nagyon jó nyelvek és nagyon jó az elv is, de vannak feladatok, amikhez - legalábbis most - nem igazán alkalmassak.

[mapboy]

És örülök, hogy érdekesnek találod a témát, mert látszólag senkit nem érdekel. Vajon csak rossz helyen vetettem fel a dolgot, vagy nem foglalkoztat senkit, vagy szimplán a téma rossz?

[Calyd]

Amiket sikerült ma kiderítenem a témáról az az, hogy elvileg pl. C#-ban lehet unmanaged kódot írni. Meg állítólag ezek a managed dolgok úgy kéne mûködjönek, hogy az elsõ futáskor lefordítja, és utána nem kell, mert megjegyzi. Ha ez így lenne, akkor jó lenne, mert ugye akkor meg volna az elõnye az ellenõrzésnek és mégsem volna lassú.

 

Aztán lehet, hogy buta gondolad, de ugyan a mutatók veszélyesek ez tény, de akkor miért nem készítenek ellenõrizhetõ függvényeket, amikkel lehetne mutatózni. Vagy olyan szintaxist követelnének meg, amikkel nem lehetne vagy kevesebb hiba lehetne. Szemantikai ellenõrzések egyébként is vannak, lehetne nyugodtan a mutatók használatára is.

 

Lehet, hogy buta dolgokat vettem fel, akkor elnézést.

[mapboy]

A mutatók használata veszélyes lehet (és C#-ban is használhatod őket bizonyos megkötések mellett), de körültekintően kell kezelni és ennyi, egyébként pedig valamilyen szinten a natív kód is ellenörizhető, hiszen mikor futtat az op.rendszer egy progit kioszt neki egy memória tartományt, ha valamelyik mutató úgymond "kimutat" ebből a címtartományból akkor azt észre tudja venni, illetve mivel el van különítve a kód és adat memória, így figyelni tudja például, hogy futás időben nem irhatsz a kód tartományba, vagyis nem irhatsz önmodósító kódot ami egyébként divat volt a DOS-os korszakban, de manapság már csak a vírusok tesznek ilyet.

 

A managed kód mindig kicsit lassabb lesz, sajnos ahogy korábban is írtam ez a hátránya, de tagadhatatlan hogy előnye is van. Jó példa erre a Java is, ügyeskedhetsz, de sosem írsz olyan hatékony (gyors) kódot mint C++-ban. Idővel biztos olyan teljesítménye lesz a gépeknek, hogy nem lesz jelentősége ennek az egésznek amiről beszélünk, de én mégis örülnék, ha meglenne a lehetősége a mélyebb szintű programozásnak a jövőben is. A mottó ugye az, hogy el kell rejteni minél több dolgot a programozó elől, kész rutinokat adni neki és így lecsökken a fejlesztési idő, de biztos jó ez nekünk? Persze lehet, hogy csak azért zavar mert programozás mellett hardver fejlesztéses projekteket is csinálok, és megszoktam, hogy ha beépítek pl. egy AT91SAM7X 32 bites RISC procit akkor pontosan tudom mikor mit csinál, sarkítva a program minden bitjét ismerem - hiszen nekem kell megirnom - nincsenek elrejtett "Microsoft"-os részek, amiről csak sejteni lehet hogy csinálja amit csinál. Mondjuk az is igaz, hogy ez nem is software hanem firmware.

[arpsoft]

Szerintem soha nem fog eltûnni a natív programozás. Az oprendszereket is csak meg kell írni valahogy. Nem hiszem, hogy interpretált operációs rendszereket fogunk használni a Vista után.

[mapboy]

Teljesen igazad van. de vajon futtatni is fognak natív kódot?

[arpsoft]

Ez attól függ, mennyire fognak belebonyolódni a biztonság kérdésébe. A natív kódot nehezebb kordában tartani, folyamatosan figyelni kell a process tevékenységeit, míg a jit vagy interpreter sokkal egyszerûbben kezelhetõ ebbõl a szempontból. Jó példa erre a php nyelv, ahol a szolgáltatók egyszerûen letilthatnak függvényeket, a programozó meg oldja meg a problémáit, ahogyan tudja.

 

Szerintem nem fogják tudni megoldani, hogy ne lehessen natív kódot futtatni a gépeken, mivel ebben az esetben szinte megbénulna a hardverfejlesztés. Most nem a nagy gyártókra gondolok, hanem aokra, akik céleszközöket fejlesztenek, mint például a DSP alkalmazások vagy csak az egyszerû digitális adatgyûjtés.

[mapboy]

Remélem igazad van, én is így gondolkodom és ebben reménykedem, de más fórumokon olvastam amit fent is pedzegettem. Talán igaz talán nem, végül is majd meglátjuk 3-4 év múlva mikor kijön a köv. op. rendszer. Abban azonban majdnem biztos vagyok, hogy a Win32 API, és az erre épitkezõ MFC/ATL már nem lesz benne a Vista utódjában, valószínûleg a korábbi ilyen programjainkat nem tudjuk majd lefordítani illetve futtatni, ezt váltja le a .NET FrameWork. De semmi sem biztos, de látjuk hogy a Microsoft stratégiája ilyesmi, ez történik most a DirectX-el is, hiszen a DX10-et nem adja ki külön XP-hez mindván hogy nem lehet, de pár napja már tudjuk, hogy ez kamu, egyszerûen marketing oka van és nem technikai.

[mapboy]

Apropó valaki tudja honnan lehet letölteni a .NET 3.0 SDK offline verzióját (nem baj ha több 100MB), és Mûködik XP alatt, van aki már telepítette és netalántán progit is irt alatta? VS2005-el beüzemelhetõ? Nekem az online telepítõ mindig hibát dob, de semmilyen megoldást nem találtam rá.

[gergo66]

Különálló .NET 3.0 SDK nem tölthetõ le, csak a redist csomag. Annak az offline telepítõje XP alá x86-os rendszerhez itt érhetõ el: >> LINK << Az SDK-t beleintegrálták a Windows SDK for Windows Vista csomagba. A WinSDK itt érhetõ el: >> LINK << A redist kb. 50Mb-os, az SDK kicsit nagyon, körülbelül 1.2Gb-os méretû. Írtam már vele programokat, XP alatt is mûködik és teljesen kompatibilis a VS 2005-el.

 

Nem teljesen igaz, hogy a DX10 csak marketing szöveg. Lehet, hogy a futtatókörnyezet adaptálható a régebbi rendszerekre is, de nem azzal a teljesítménnyel, amivel Vistán. Ennek a legfõbb oka, hogy a Vistában egy teljesen újraírt driver modell van, ami a kezdetektõl fogva úgy lett tervezve, hogy kiszolgálja az új videókártyák egyesített memóriaszerkezetét és a nagyobb számítási kapacitást. A programozó srác sem tudott még tökéletes DX10 adaptációt felmutatni, csak annyi sikerült neki, hogy futtatta a DX SDK-s demókat XP-n.

[mapboy]

Ezt amit írtál az SDK-ról tudom, már letöltöttem a setup.exe-t, de azt irja ki, hogy: "SDKSetup encountered an error. Expecting path %SystemRoot% represent a valid system volume." Már mindent kipróbáltam de nem sikerült előbbre jutni, újrahúzni pedig most nem akarom, épp egy nagy melóban vagyok és azt úgy is nagyrészt C++-ban irom, a C#-os részhez pedig a .NET2.0 épp elég.

Már egy fórumon felvetettem a dolgot, de sajnos nem kaptam segítséget azon kivűl, hogy nézem meg jó-e a %SystemRoot% bejegyzésem, illetve hogy telepítsem újra, ez egyébként tipikus rendszergazdás megoldás, a másik az indítsd újra szokott lenni... Na de senkit nem akartam bántani én is voltam rendszergazdi az előző cégemnél, bár hardver fejlesztőként dolgoztam, de rámsózták... Szóval végigbogarásztam a registry-t kézzel és segédprogrammal is, de a SYSTEMROOT bejegyzés rendben van, a "C:\WINOWS"-ra mutat és ott is van a rendszer. Parancssorban a SET paranccsal a környezeti változókat megjelenítve, szintén ott van a listán és jól, ha nem így lenne több program nem jól működne, úgyhogy nem értem...

 

Ezért is kérdeztem a - teljessen - offline telepítőt, hajlandó vagyok letölteni 1.2GB-ot is, hátha úgy felmászik. Valahol már láttam, ISO-ként lehetett leszedni, de azóta sem találom... Microsoft-os honlapon volt...

[gergo66]

Itt van a WinSDK lemezképes változatban: >> LINK <<

Nem ISO, hanem IMG Ki tudod írni ImgBurn-el.

 

UPDATE: Van egy 2007Feb ISO frissített WinSDK is, ezt most talátam. Még a kívánságod is teljesül, mert ez tényleg ISO >> LINK <<

[mapboy]

Köszi, ezt kerestem, már letöltöttem, majd kipróbálom...

[mapboy]

Megpróbáltam telepíteni, de ez is ugyanazt a hibát irta ki, de végülis sikerült feltenni, a következőt kellett tenni:

 

- nyitottam egy DOS ablakot

- beirva a SET parancsot a windir változó értéke %SystemRoot% volt, ez nem is lenne baj, mivel a SystemRoot változó értéke pedig C:\WINDOWS, de gondoltam egyet és a windir változót is C:\WINDOWS-ra állítottam közvetlenül, majd ebből a DOS abalakból elinditottam a setup.exe-t és láss csodát elindult rendessen, érdekes, hogy ha a DOS abalakot bezértam és Total Commander-ből inditottam akkor ugyanaz a hibaüzenet...

 

Apropó, a VS2005-be magától beintegrálódik vagy még tenni kell valamit ez ügyben? És majd beállíthatom, hogy amit irok progit az .NET2.0 vagy .NET3.0? Bár lehet, hogy mire választ kapok már ki is derül...

[mapboy]

Kiderült, szépen beépült, már ki is próbáltam... Nem semmi mennyiségû helyet foglal a HDD-n, egész pontosan 2.3GB-al lett kevesebb az üres helyem telepítés után.

[artur02]

Én az eredeti kérdéshez szólnék hozzá: hová tartunk.

 

Szerintem a feladattól függ, hogy managed vagy natív kódot szeretnék használni. Ha a sebesség számít, akkor marad a natív kód. Ha a fejlesztési sebesség, akkor pedig a managed verzió ajánlott.

 

De kérdés, hogy szükséges-e ezt ennyire külön választani. Elképzelhetõ egy olyan megoldás, hogy a sebesség-kritikus feladatokat natív módon valósítsam meg (pl. C++), de a többi, nem annyira kritikus rész mehet managed (pl. C#, Java) nyelven is. Én egy kicsit úgy érzek ezzel kapcsolatban, mint ahogy megjelentek az ASM betétek a különbözõ programnyelvekben. Ráadásul ha továbbgondoljuk, ahogy a gépek telejsítménye nõtt, úgy csökkent az ASM betétek száma.

 

De visszatérve a jelenhez, szerintem a képfeldolgozás jóideig C++ terület marad, a szokványos irodai alkalmazások esetén pedig Java/C# lesz az uralkodó. Még egy darabig.

[Robsoft]

UP! Úgyéreztem ehhez hozzá kell szólnom.

Sziasztok!

Mint programozót egyre inkább foglalkoztat mostanában hogy mit hoz a jövő számunkra?

Microsoft és lassan már a mac os, linux solaris és a többi is = .NET

 

...De akkor miben lehet majdigazán erőforrásigányes programot írni, valljuk be a C#-ban lévő GDI+ játszani jó, de képfeldolgozáshoz, játék íráshoz stb. ahol nagyfelbontású képekkel kell dolgozni, és minél többel "végezni" adott idő alatt, nos ehhez alkalmatlan, ez saját tapasztalat, próbáltam irni egy olyan progit ahol 1-2GB térképeket kellett megjeleníteni és feldolgozni, de reménytelen volt valós időben C# alatt.

GDI+ nak mi köze van a játékokhoz? Ez egy wines megjelenítő felület, ami független a nyelvtől, ergó C++ ban is ugyanolyan lassú. Játékra ott az XNA, desktopra a WPF, webre pedig Silverlight. Ez egytől-egyig managed már most is.

 

Eleve a pointerek hiánya - na jó tudom, hogy erőltetve azért még lehet használni - egy súlyos veszteség, minimum 2-3x gyorsabb egy algoritmus pointerek használatával...

Igen, a memória kezelés pedig cirka 4* gyorsabb .NET-ben, pont azért, mert rendbeszedve tárolódnak a heap-en a dolgok, nem össze-vissza, mint a pointerezésnél. Több RAM-ot eszik cserébe, de ez a procinak mindegy. Akkor most melyik is a gyorsabb?

 

Illetve gondolom mindenkinek egyértelmű, hogy eleve csak lassabb lehet egy program futása a valós időben történő fordítás miatt, sőt a .NET keretrendszer nem csak egyszerűen lefordítja, hanem ellenörzi is, ez persze biztonságosabbá, felügyelhetőbbé teszi a futást, de még lassabbá is. Egyébként ezért hívják managed kódnak, mert felügyelt futás közben.

Na álljunk meg egy szóra! C++ ban lefordítasz egy x86 fordítást és az AMD, Intel proci meg kezd vele valamit, ha tud, 64 biten meg többnyire nem kezd vele semmit. Túl sok AMD 64 bit only programot még nem láttam. A .NET-es IL 90%-át már a futtatás előtt (!) lefordítja a JIT, méghozzá adott processzorra optimalizált natív kódra (!), a többit pedig menet közben egyszer és cacheli, tehát sok esetben épphogy gyorsabb lesz a futás, pláne, ha a mai többmagos procikat nézzük.

A Vista utáni OS kernel .NET-re fog épülni méghozzá szintén az adott processzor natív kódjára forgatva, tehát az eredendően natív kód (unmanaged) már lasabban fog futni egyértelműen már csak a procira optimlizálás miatt is. Amúgy a Vista Aero is C# WPF-re épül.

[mohacsi]

Sziasztok!

 

Eredeti témához: kb 17 éve foglalkozom szoftverfejlesztéssel, már 13 éves korom óta. Mindig is ezt szerettem csinálni - jelzem, tudok focizni is!!! Először BASIC, aztán VISUAL BASIC, VC++, JAVA. Utóbbi hármat egyszerre. Mindenek előtt a .NET nyerte el igazán a tetszésemet, mert nagyon jól struktúrált, gyorsan lehet fejleszteni benne, bármilyen applikációról legyen is szó. Bár itt hozzáteszem, azért a DirectX-es cuccokat VC++ ban írom, a jó öreg pointerekkel. A webre meg egyértelmű, hogy a JAVA a nyerő. Hogy managed vagy unmanaged? A feladat dönti el, de erre egy programozónak rá kell éreznie...

[TranceDuDe]

Én azon a véleményen vagyok, hogy amennyire csak lehet .NET-ben kell megírni a programokat, mivel legtöbb helyzetben jóval gyorsabban mint C++-os vagy egyéb natív kódú társaik, illetve biztonságosabbak is. Ami a pointereket illeti megint csak a programok gyengéi közé sorolhatóak.

Microsoftnál is megfigyelhetõ a trend: az újabb Windows (Seven/Blackcomb) már a virtualizációról (Hypervisor) fog szólni, aminek esze ágában sem lesz közvetlen gépi kódot fogadni - biztonságilag meg sem engedett, nem is láthatja.