[Alg] Waarom .net?*

[Verwijderd]

Voorheen heb ik regelmatig met c++ en Delphi geprogd voor hobbie projecten.
Momenteel zie je een verschuiving naar .net en ipv c++ wordt meer naar c# verwezen.

Wat zijn de voordelen van .net t.o.v. de 'oude' environment?
Heeft het effect of verbeteringen wanneer er alleen executables worden geschreven voor typische win32 applicaties?
Waar past c# in dit verhaal?
Betekent dit wellicht het einde van talen als delphi en java?

[Verwijderd]

C++ is nog steeds aanwezig onder .NET, maar waarom C#: managed code. Je kan sneller ontwikkelen, en natuurlijk de web interfaces die steeds meer gebruikt worden i.p.v. rich clients.

[Soultaker]

Over dit onderwerp is genoeg geschreven om een paar boeken te vullen. De voordelen van .NET komen grotendeels overeen met de voordelen van het Java platform ten op zichte van traditionele programmeeromgevingen.

Persoonlijk lijkt de opkomst van .NET me absoluut niet het einde van de meeste bestaande talen, al kan ik me voorstellen dat deze wel uit een aantal toepassingsgebied verdreven worden. Vooral bijvoorbeeld een taal als Delphi die veel gebruikt wordt voor typische maatwerksoftware waarbij een gebruikersinterface en een databasekoppeling van belang is, lijkt het .NET platform me een grote concurrent. In de maatwerksector lijken ontwikkelings- en onderhoudskosten me beide bepalende eigenschappen van een product. Voor dit soort toepassingen lijkt .NET en een taal als bijvoorbeeld C# me uitermate geschikt.

In toepassingsgebieden waarvoor veel nauwkeurigere controle over platformspecifieke onderdelen vereist is, zie ik traditionele programmeertalen nog niet zo snel verdwijnen. Het is waarschijnlijk dat .NET applicaties en traditionele applicaties gecombineerd worden. Je hebt al C++ voor .NET, waarmee je behalve van .NET functionaliteit ook van traditionele C++ functionaliteit gebruik kunt maken. Op het Java platform is het ook al erg gebruikelijk om platformspecifieke functionaliteit in C te implementeren.

[Cuball]

zo als ik het zie is het ganse .NET verhaal speciaal ontworpen voor web applicaties en andere adminstratieve toepassingen, maar van zodra je games gaat programeren blijft C++ gewoon bestaan hoor, geen twijfel over...

[whoami]

.NET is niet speciaal ontworpen voor web applicaties, maar oa voor applicaties die geintegreerd zijn met het internet. Dit kunnen dus zowel webapplicaties zijn, als smart clients.

De voordelen van .NET zijn legio: een uitgebreide class - library, die goed in elkaar zit, side - by - side execution, private assemblies, geen 'DLL hell' meer, ontwikkelen in C#, een nieuwe, krachtige OO taal waar je de mogelijkheid hebt om bepaalde dingen mbhv attributes te verwezenlijken.
Het is in theorie ook mogelijk om platform-onafhankelijke code te schrijven. Op 'Windows platforms' is dit nu al mogelijk, en van zodra er een volledig geimplementeerde .NET runtime is voor *nix, kunnen je apps in theorie ook op dat *nix platform draaien.

Cuball: games ontwikkelen in .NET is in principe mogelijk. Quake 2 werd al in .NET geimplementeerd.

Verwijderd schreef op 20 maart 2004 @ 20:34:
C++ is nog steeds aanwezig onder .NET, maar waarom C#: managed code. Je kan sneller ontwikkelen, en natuurlijk de web interfaces die steeds meer gebruikt worden i.p.v. rich clients.

Hum, daar ben ik het niet mee eens. Met .NET is het nl. mogelijk om makkelijk met een rich interface te werken, terwijl je applicatie logica op 1 centrale plaats staat, en beschikbaar is via .NET remoting, of via Web Services.
Je hebt dan de voordelen van beide systemen: een rijke user interface, en een gecentraliseerde plek voor de applicatie - logica.
Trouwens, met Indigo zou het verschil tussen web-interface en rich client moeten vervagen heb ik vernomen.

Verwijderd schreef op 20 maart 2004 @ 20:28:
Betekent dit wellicht het einde van talen als delphi en java?

Het einde van die talen zal het niet zijn. Borland heeft met Delphi Octane zelfs de mogelijkheid om .NET applicaties te schrijven in Delphi.
Voor enterprise applications zullen er 2 grote stromingen zijn imo: .NET en J2EE.

[ Voor 44% gewijzigd door whoami op 21-03-2004 09:15 ]

[EfBe]

Voor MS developers is .NET 'the next big thing', dus de volgende stap in de cyclus van platforms waartegen ze kunnen programmeren. De talen die met .NET zijn geintroduceerd zijn een hele verbetering tov bestaande talen.

Als je Java programmeert is .NET niet veel meer dan een platform wat kan wat je met Java ook al kunt. (behalve ASP.NET dan).

.NET heeft zelf erg veel dingen die het de moeite waard maken ermee te werken. Dat neemt niet weg dat bv Java die niet heeft en je dus altijd naar .NET moet kijken. Het is wel zo dat wanneer iemand op dit moment nog een traject in C++ + COM start, VB6 of ASP je wel goed moet nadenken waarom je die talen gaat gebruiken, want .NET levert allerlei zaken die het bouwen van dezelfde logica veel gemakkelijker maken. Dat neemt niet weg dat bv de C++/COM wereld dead is, in tegendeel. VS.NET is ermee gemaakt .

[Verwijderd]

whoami schreef op 21 maart 2004 @ 09:11:

Cuball: games ontwikkelen in .NET is in principe mogelijk. Quake 2 werd al in .NET geimplementeerd.

offtopic:
.NET bestond toen nog geen eens, en als het zo is waarom draait Quake 2 dan op *nix als er nog geen .NET platform daarvoor is?

[pjvandesande]

Verwijderd schreef op 21 maart 2004 @ 12:50:

offtopic:
.NET bestond toen nog geen eens, en als het zo is waarom draait Quake 2 dan op *nix als er nog geen .NET platform daarvoor is?

http://www.vertigosoftware.com/Quake2.htm

[Verwijderd]

offtopic:
Die kende ik nog niet, maar dan is het nog altijd Quake 2 .NET en niet Quake 2

[Zoijar]

Hmmm zou managed code niet gaan zorgen voor "slechtere" code? Run-time buffer checks en garbage collection etc is natuurlijk erg handig, maar eigenlijk schreef ik toch al C++ op zo'm manier dat ik daar niet zo veel last van had. Als je goed C++ kan schrijven, dan weet je dat je bepaalde dingen niet moet doen (bv. alloceren met ruwe pointers, ipv smart-pointers)

Nou snap ik dat het handig is als je snel iets wilt ontwikkelen, om je dan niet druk te hoeven maken om dit soort dingen. Maar gaan programmeurs dan niet steeds luier worden, en op een gegeven moment geen unmanaged code meer kunnen schrijven?

[Soultaker]

Dat Quake II project was te realiseren doordat het mogelijk is om managed C++ te schrijven voor .NET. Als het iets demonstreert, dan is het wel dat traditionele code (C code, in dit geval) gecombineerd kanworden met het .NET platform; niet dat het praktisch is om game engines in een .NET taal te schrijven.

[ Voor 6% gewijzigd door Soultaker op 21-03-2004 15:14 ]

[whoami]

Verwijderd schreef op 21 maart 2004 @ 13:13:

offtopic:
Die kende ik nog niet, maar dan is het nog altijd Quake 2 .NET en niet Quake 2

Ik bedoelde dus dat men Quake 2 in .NET heeft geimplementeerd om aan te tonen hoe .NET overweg kan met dergelijke dingen.
Tuurlijk bestond Q2 al toen er van .NET nog geen sprake was.

[whoami]

Zoijar schreef op 21 maart 2004 @ 13:45:
Hmmm zou managed code niet gaan zorgen voor "slechtere" code? Run-time buffer checks en garbage collection etc is natuurlijk erg handig, maar eigenlijk schreef ik toch al C++ op zo'm manier dat ik daar niet zo veel last van had. Als je goed C++ kan schrijven, dan weet je dat je bepaalde dingen niet moet doen (bv. alloceren met ruwe pointers, ipv smart-pointers)

Geheugen allocatie in een managed omgeving gaat sneller dan in een non-managed omgeving.
In .NET heb je een managed heap, waarbij alle gealloceerd geheugen contiguous is gealloceerd. Als er geheugen moet gealloceerd worden, dan moet er dus geen linked list doorlopen worden om vrije geheugen blokken te vinden.
De runtime weet direct waar het eerstvolgende vrije stuk geheugen zich bevindt, en kan direct de gewenste hoeveelheid alloceren.
Wat dan wel weer trager is, is het vrijgeven van geheugen aangezien de heap dan weer moet 'gecompacted' worden.

Nou snap ik dat het handig is als je snel iets wilt ontwikkelen, om je dan niet druk te hoeven maken om dit soort dingen. Maar gaan programmeurs dan niet steeds luier worden, en op een gegeven moment geen unmanaged code meer kunnen schrijven?

Ook in .NET moet je je zelf wel bezig houden met het op tijd vrijgeven van 'unmanaged' resources (bv. files) dmv Disposers en/of Finalizers.

[.oisyn]

whoami schreef op 21 maart 2004 @ 15:28:
[...]

Geheugen allocatie in een managed omgeving gaat sneller dan in een non-managed omgeving.

Beetje kort door de bocht, geheugenroutines zijn in een unmanaged omgeving ook enorm te optimaliseren. Met mijn eigen memory-library doe ik allocaties van <= 256 bytes ook gewoon in O(1) tijd door vrijgegeven stukjes ergens op te slaan aan de hand van hun grootte zodat ze hergebruikt kunnen worden

[xerix]

whoami schreef op 21 maart 2004 @ 15:25:
[...]


Ik bedoelde dus dat men Quake 2 in .NET heeft geimplementeerd om aan te tonen hoe .NET overweg kan met dergelijke dingen.
Tuurlijk bestond Q2 al toen er van .NET nog geen sprake was.

Wat is er precies 'geimplementeerd in .NET' in deze versie van q2? Behalve het radarschermpje is er geen .NET te bespeuren in deze q2 versie.


Leuk detail:

Running Quake II.NET in the timedemo test indicates the managed version performs about 85% as fast as the native version.

Door em alleen als managed c++ te compilen is ie al 15% trager geworden en dan is de code nog hetzelfde gebleven.

[ Voor 27% gewijzigd door xerix op 22-03-2004 01:25 ]

[.oisyn]

Je geeft je antwoord zelf al: het is managed C++, dus het is .net. Ik snap je ook niet helemaal; wat is je punt precies mbt die opmerking dat het trager wordt? Dat het niet eens zoveel trager is en dat dat wel cool is, of juist dat het idioot is dat het trager is terwijl de code hetzelfde is gebleven (Voor mij geldt dat eerste, het is .net, natuurlijk is het trager, maar het valt reuze mee)

Bovendien is de code niet hetzelfde gebleven, ze moesten het porten naar C++ omdat je C code niet als managed kunt compilen

[ Voor 14% gewijzigd door .oisyn op 22-03-2004 01:29 ]

[whoami]

.oisyn schreef op 21 maart 2004 @ 22:11:
[...]


Beetje kort door de bocht, geheugenroutines zijn in een unmanaged omgeving ook enorm te optimaliseren. Met mijn eigen memory-library doe ik allocaties van <= 256 bytes ook gewoon in O(1) tijd door vrijgegeven stukjes ergens op te slaan aan de hand van hun grootte zodat ze hergebruikt kunnen worden

Misschien is het een beetje kort door de bocht, maar het is gewoon zo dat op een managed heap, alle gealloceerde geheugen contiguous is 'opgeslagen'.
Een pointer houdt het adres bij van het eerstvolgende vrije geheugen adres. Eens dat gekend is, kan het volledige gevraagde geheugenblok in een keer gealloceerd worden.

[xerix]

.oisyn schreef op 22 maart 2004 @ 01:29:
Je geeft je antwoord zelf al: het is managed C++, dus het is .net. Ik snap je ook niet helemaal; wat is je punt precies mbt die opmerking dat het trager wordt? Dat het niet eens zoveel trager is en dat dat wel cool is, of juist dat het idioot is dat het trager is terwijl de code hetzelfde is gebleven (Voor mij geldt dat eerste, het is .net, natuurlijk is het trager, maar het valt reuze mee)

Bovendien is de code niet hetzelfde gebleven, ze moesten het porten naar C++ omdat je C code niet als managed kunt compilen

Op het compilebaar maken voor een c++ compiler, wat niet echt veel voorsteld, is er niets veranderd. Dan valt het mij tegen dat het dan al 15% trager is. Stel dat je alles '.NET style' zou coden, dan wordt het nog een factor x trager.
Dus whoami's punt dat .NET geschikt is voor games lijkt mij niet waar. Tuurlijk is het mogelijk maar niet wenselijk, in mijn optiek, als je kijkt naar de performance hit.

[whoami]

xerix schreef op 22 maart 2004 @ 12:09:
[...]


Op het compilebaar maken voor een c++ compiler, wat niet echt veel voorsteld, is er niets veranderd.

C code kan je zowiezo al door een C++ compiler halen, maar dat maakt het daarom nog geen C++.
Daarnaast is managed C++ (wat dus nodig is om het onder .NET te laten draaien), ook niet zomaar C++.

[xerix]

whoami schreef op 22 maart 2004 @ 12:15:
[...]

C code kan je zowiezo al door een C++ compiler halen, maar dat maakt het daarom nog geen C++.
Daarnaast is managed C++ (wat dus nodig is om het onder .NET te laten draaien), ook niet zomaar C++.

Niet als je expliciet aangeeft dat het als c++ code gecompiled moet worden. En kijk anders de source door van dat project, er is weinig tot niets veranderd met de orginele code.
Ik vind het dan ook een beetje vreemd dat dit gepresenteerd wordt als zijnde een .NET port. Het enige wat men heeft gedaan is het orignele VC6 project geopend in .NET, geconverd, en Compile as C++ code aangezet (met de hierbij minimaal benodigde aanpassingen)
Het enige managed C++ in het project is ook hun eigen radar klasse. Wat het project laat zien is dat traditionele C code kan samenwerken met nieuwe .NET technieken.

[igmar]

whoami schreef op 21 maart 2004 @ 15:28:
Geheugen allocatie in een managed omgeving gaat sneller dan in een non-managed omgeving.
In .NET heb je een managed heap, waarbij alle gealloceerd geheugen contiguous is gealloceerd.

Die heap wordt niet uit zichzelf contiguous, daar is code voor nodig. En code kost tijd. Het alloceren is misschien dan erg snel, het vrijgeven een stuk trager. Ik heb d'r zelf twijfels over of de .NET implementatie dan werkelijk wezelijk sneller is als de malloc inplementatie die nu wordt gebruikt door de C runtime.

[whoami]

igmar schreef op 22 maart 2004 @ 13:17:
[...]


Die heap wordt niet uit zichzelf contiguous, daar is code voor nodig. En code kost tijd. Het alloceren is misschien dan erg snel, het vrijgeven een stuk trager.

Dat heb ik ook al in m'n eerdere post gezegd: alloceren gaat snel, vrijgeven gaat trager omdat de heap na garbage collection gecompacted moet worden.

Objects that are not in the graph are unreachable from the application's roots. The garbage collector considers unreachable objects garbage and will release the memory allocated for them. During a collection, the garbage collector examines the managed heap, looking for the blocks of address space occupied by unreachable objects. As it discovers each unreachable object, it uses a memory-copying function to compact the reachable objects in memory, freeing up the blocks of address spaces allocated to unreachable objects. Once the memory for the reachable objects has been compacted, the garbage collector makes the necessary pointer corrections so that the application's roots point to the objects in their new locations. It also positions the managed heap's pointer after the last reachable object. Note that memory is compacted only if a collection discovers a significant number of unreachable objects. If all the objects in the managed heap survive a collection, then there is no need for memory compaction.

To improve performance, the runtime allocates memory for large objects in a separate heap. The garbage collector automatically releases the memory for large objects. However, to avoid moving large objects in memory, this memory is not compacted.

Ik heb d'r zelf twijfels over of de .NET implementatie dan werkelijk wezelijk sneller is als de malloc inplementatie die nu wordt gebruikt door de C runtime.

Heb je daar plausibele aanleidingen toe?

[ Voor 51% gewijzigd door whoami op 22-03-2004 13:50 ]

[.oisyn]

whoami schreef op 22 maart 2004 @ 12:15:
[...]

C code kan je zowiezo al door een C++ compiler halen, maar dat maakt het daarom nog geen C++.

da's ook niet helemaal waar

xerix schreef op 22 maart 2004 @ 12:53:
[...]

Niet als je expliciet aangeeft dat het als c++ code gecompiled moet worden. En kijk anders de source door van dat project, er is weinig tot niets veranderd met de orginele code.
Ik vind het dan ook een beetje vreemd dat dit gepresenteerd wordt als zijnde een .NET port. Het enige wat men heeft gedaan is het orignele VC6 project geopend in .NET, geconverd, en Compile as C++ code aangezet (met de hierbij minimaal benodigde aanpassingen)
Het enige managed C++ in het project is ook hun eigen radar klasse. Wat het project laat zien is dat traditionele C code kan samenwerken met nieuwe .NET technieken.

Ik denk dat jij nog even bij moet gaan lezen over managed C++ in whidbey en dat quake2 project. Ze hebben de code eerst geconverteerd naar C++ omdat de managed compiler geen C code slikt. Vervolgens is het als managed C++ gecompileerd, zodat het onder de CLR kan runnen. Wat ze willen bewijzen is dat je C++ code met de komst van whidbey vrijwel direct naar .net code kunt compileren, en native C++ <-> .net dus enorm goed gaat, en bovendien dat de .net runtime helemaal nog niet zo langzaam is.

Quake2 werd in dat voorbeeld dus niet gecompileerd naar native code

[EfBe]

igmar schreef op 22 maart 2004 @ 13:17:
Ik heb d'r zelf twijfels over of de .NET implementatie dan werkelijk wezelijk sneller is als de malloc inplementatie die nu wordt gebruikt door de C runtime.

malloc gebruikt onderwater gewoon HeapAlloc() van win32. De CLR doet dat niet, die gebruikt zn eigen memory management (maar, zal wanneer zn eigen heap volloopt of uitgebreid moet worden, gewoon ook een HeapAlloc doen).

Dus de CLR kan sneller zijn, wanneer het geheugen voorradig is, anders moet ook de CLR via win32 nieuw memory alloceren wat dan dus trager is dan een normale malloc.

[igmar]

whoami schreef op 22 maart 2004 @ 13:38:
Dat heb ik ook al in m'n eerdere post gezegd: alloceren gaat snel, vrijgeven gaat trager omdat de heap na garbage collection gecompacted moet worden.

Data rondcopieeren is een vrij dure operatie, en IMHO een vrij zinloze.

Heb je daar plausibele aanleidingen toe?

Ja, ik weet hoe de glibc malloc() functie werkt

Een aantal punten (vooral uitgaande van het stuk in jouw post) :

glibc :

- de glibc malloc gebruikt een list voor het bijhouden van gealloceerde objecten
- vrijgegeven objecten worden pas echt verwijderd als een bepaalde treshold is bereikt
- grotere objecten worden gedaan met mmap()

.NET :

- Contigiuous memory, geregeld door de allocator zelf
- Stack wordt naar elke free (?) gecompact
- Geen hergebruikt van objecten

memmove operaties zijn vrij duur : Data lezen, data weer wegschrijven. Met een beetje geluk kun je hele pages moven in de TLB, maar voor kleinere allocaties gaat dat domweg niet. Algoritmes om de best-fit te regelen zijn ook vrij duur, O(n) in worst-case.

Ik vraag me dan sterk af waarom men deze oplossing kiest : memory access wordt door de CPU geregeld, en userspace is virtual adressering.

Het enige probleem wat ik me kan bedenken is dat er veel kleine ongebruikte objecten aanwezig zijn, die in dat geval ruimte kosten.

Maar zo even wat losse gedachten

[igmar]

EfBe schreef op 22 maart 2004 @ 14:23:
malloc gebruikt onderwater gewoon HeapAlloc() van win32. De CLR doet dat niet, die gebruikt zn eigen memory management (maar, zal wanneer zn eigen heap volloopt of uitgebreid moet worden, gewoon ook een HeapAlloc doen).

Het probleem van de vrij dure move operaties blijft dan echter staan.

Dus de CLR kan sneller zijn, wanneer het geheugen voorradig is, anders moet ook de CLR via win32 nieuw memory alloceren wat dan dus trager is dan een normale malloc.

Alloceren zeker, maar dat voordeel wordt teniet gedaan door de dure vrijgeef operaties. Het kan op zich sneller wezen, als je applicatie zodanig is ingericht dan men allocaties opspaart en opnieuw gebruikt. Voor langlopende processen is dit zowiezo wel aan te raden.

[ Voor 4% gewijzigd door igmar op 22-03-2004 14:36 ]

[xerix]

.oisyn schreef op 22 maart 2004 @ 14:14:
[...]


da's ook niet helemaal waar


[...]


Ik denk dat jij nog even bij moet gaan lezen over managed C++ in whidbey en dat quake2 project. Ze hebben de code eerst geconverteerd naar C++ omdat de managed compiler geen C code slikt. Vervolgens is het als managed C++ gecompileerd, zodat het onder de CLR kan runnen. Wat ze willen bewijzen is dat je C++ code met de komst van whidbey vrijwel direct naar .net code kunt compileren, en native C++ <-> .net dus enorm goed gaat, en bovendien dat de .net runtime helemaal nog niet zo langzaam is.

Quake2 werd in dat voorbeeld dus niet gecompileerd naar native code

Ik denk dat jij mij verkeerd begrijpt. Ik beweer nergens dat het naar native c++ code compiled wordt. Ik zeg alleen dat de orginele C code is aangepast zodat het compilebaar door de managed C++ compiler. Maar verder heeft dit project weinig met de ontwerp filosofie achter .NET te maken.
Maar als het doel puur en alleen is geweest om de code te compilen onder de managed C++ compiler dan zijn ze daar wel in geslaagd ja. Alleen dan vind ik de manier waarop dit project gepresenteerd wordt op de microsoft site een beetje misplaatst.

[whoami]

igmar schreef op 22 maart 2004 @ 14:36:
[...]


Het probleem van de vrij dure move operaties blijft dan echter staan.

Note that memory is compacted only if a collection discovers a significant number of unreachable objects

[EfBe]

igmar schreef op 22 maart 2004 @ 14:36:
Het probleem van de vrij dure move operaties blijft dan echter staan.

Hoeft niet, aangezien de CLR zn eigen memory management doet en dus de move virtueel zou kunnen uitvoeren (maar of dit op den duur sneller is betwijfel ik)

Mem moven is altijd 'duur', maar alleen wanneer je tegelijk iets anders wilt doen.

Alloceren zeker, maar dat voordeel wordt teniet gedaan door de dure vrijgeef operaties. Het kan op zich sneller wezen, als je applicatie zodanig is ingericht dan men allocaties opspaart en opnieuw gebruikt. Voor langlopende processen is dit zowiezo wel aan te raden.

De GC gaat niet tijdens een processor intensieve thread de handel compacten, dat gebeurt wanneer er weinig te doen is (en dat is in veel systemen het merendeel van de tijd), waardoor je er niets van merkt. Het kan dan wel trager zijn, je merkt het niet, omdat de compacting in idle-time wordt uitgevoerd.

Maar deze thread gaat over waarom .NET, en waar men over praat is malloc (over crappy routines gesproken, malloc is de basis van erg veel security leaks), of quake2 op .net draait en heaps.

[EfBe]

xerix schreef op 22 maart 2004 @ 14:37:
Ik denk dat jij mij verkeerd begrijpt. Ik beweer nergens dat het naar native c++ code compiled wordt. Ik zeg alleen dat de orginele C code is aangepast zodat het compilebaar door de managed C++ compiler. Maar verder heeft dit project weinig met de ontwerp filosofie achter .NET te maken.
Maar als het doel puur en alleen is geweest om de code te compilen onder de managed C++ compiler dan zijn ze daar wel in geslaagd ja. Alleen dan vind ik de manier waarop dit project gepresenteerd wordt op de microsoft site een beetje misplaatst.

Het heeft er juist alles mee te maken. MC++ geeft je de mogelijkheid een brug te slaan tussen .NET en native win32. Hierdoor kun je dus hybride applicaties maken door EN al bestaande code te hergebruiken en nieuwe code in .NET te schrijven, en die aan elkaar te lijmen met MC++.

[xerix]

EfBe schreef op 22 maart 2004 @ 15:26:
[...]

Het heeft er juist alles mee te maken. MC++ geeft je de mogelijkheid een brug te slaan tussen .NET en native win32. Hierdoor kun je dus hybride applicaties maken door EN al bestaande code te hergebruiken en nieuwe code in .NET te schrijven, en die aan elkaar te lijmen met MC++.

Ja dat is dus wat ik in een eerdere post al schreef.

[igmar]

whoami schreef op 22 maart 2004 @ 14:38:
Note that memory is compacted only if a collection discovers a significant number of unreachable objects

Wat is in deze de definitie van 'significant' ? Is dat 10, 100, 1000, 10000 ? Feit blijft dat de moves een dure operatie blijven, dus ik vraag me dan af wat voor de gemiddelde applicatie sneller is.

Verder zorgt de management code die dit allemaal regelt ook voor overhead.

[whoami]

igmar schreef op 22 maart 2004 @ 16:12:
[...]

Verder zorgt de management code die dit allemaal regelt ook voor overhead.

Het is de .NET runtime die dat regelt, en zoals EfBe al zei gebeurt dat enkel op momenten waarop de CPU zo goed als idle is.

The .NET Framework's garbage collector manages the allocation and release of memory for your application. Each time you use the new operator to create an object, the runtime allocates memory for the object from the managed heap. As long as address space is available in the managed heap, the runtime continues to allocate space for new objects. However, memory is not infinite. Eventually the garbage collector must perform a collection in order to free some memory. The garbage collector's optimizing engine determines the best time to perform a collection, based upon the allocations being made. When the garbage collector performs a collection, it checks for objects in the managed heap that are no longer being used by the application and performs the necessary operations to reclaim their memory.

Dat het vrijgeven van geheugen in een unmanaged environment sneller is, dat ga ik niet betwisten (zie ook m'n eerdere post). Het ging mij dan ook om het alloceren van het geheugen.
Garbage collection zorgt wel voor een vertragende factor, maar ik heb nog geen enkele user van m'n applicaties horen klagen dat de applicatie plots veel te traag is.

[igmar]

whoami schreef op 22 maart 2004 @ 16:22:
Het is de .NET runtime die dat regelt, en zoals EfBe al zei gebeurt dat enkel op momenten waarop de CPU zo goed als idle is.

Dat scheelt, dat doen de meeste malloc inplementaties namelijk niet (over het algemeen als een trigger gebaseerd op het aanroepen van free())

Dat het vrijgeven van geheugen in een unmanaged environment sneller is, dat ga ik niet betwisten (zie ook m'n eerdere post). Het ging mij dan ook om het alloceren van het geheugen.
Garbage collection zorgt wel voor een vertragende factor, maar ik heb nog geen enkele user van m'n applicaties horen klagen dat de applicatie plots veel te traag is.

De runtime zal ook bij moeten houden hoe groot blokken zijn, of in ieder geval de pointers waar blokken starten, anders kun je blokken niet meer hergebruiken / vrijgeven.

Ach, al met al toch wel een reden om eens naar .net te kijken in de toekomst