Is java de grootste vloek in de informatica?

[RayNbow]

Zoijar schreef op vrijdag 19 december 2008 @ 19:07:
[...]
Misschien ben ik dom, maar wat is eigenlijk het nut van een (java) VM?

Wat is het nut van een OS? Precies, het vormen van een abstractielaag voor de applicaties die voor dat OS draaien. Een VM is niet veel anders, behalve dat tussen de VM en de hardware meer lagen zit.

Ik heb dat nooit zo begrepen. De x86 is toch ook een VM, welliswaar in hardware geimplementeerd en lekker snel.

Maar wat is het nut van de x86 instructieset? Juist, een abstractielaag vormen bovenop de microcode.

Iedereen lijkt daar altijd zo dol op; owh, java, VM, niiice... snap het niet helemaal.

De reden is misschien dat mensen soms van wat meer abstractie houden zodat ze op een hoger niveau kunnen werken?

Enige dat ik kan bedenken is dat het gedistribueerde executables wat makkelijker maakt, i.e. je kan makkelijk een remote object downloaden en rechtstreeks draaien. Maar dat zou ook kunnen met een on-the-fly compiler.

Een JVM kan (en doet dat ook) on-the-fly compilen. Het verschil zit dus in abstractie.

Bovendien, wie gebruikt dat nou echt veel? Platform onafhankelijk.

Ik ben wel blij als een door mij geschreven programma zonder moeite op een ander systeem draait.

Uhmm ja, mijn code ook.

Ik ken jouw code niet, dus daar kan ik geen uitspraken over doen. Toch valt het me op dat ik als Windows gebruiker vaak genoeg code tegenkom die ik niet werkende krijg. In de gevallen dat ik het werkende kreeg, moest ik vaak door veel hoepels springen.

Secure. Dat is aan je OS lijkt me.

Security is iets wat meerdere lagen beslaat. Je OS regelt de security voor alle OS-gerelateerde zaken (diensten), maar het lijkt me best moeilijk voor een OS om te bepalen wat "secure" is in de hogere lagen.

[Verwijderd]

RayNbow schreef op zaterdag 20 december 2008 @ 01:30:
[...]

Maar wat is het nut van de x86 instructieset? Juist, een abstractielaag vormen bovenop de microcode.

Inderdaad. Je zou ook een microcode ISA kunnen maken die de Java VM implementeert. Het maakt weinig uit waar je de abstractielaag zet, behalve dat je misschien minder hardware nodig hebt als je de x86-laag er tussenuit haalt. Als Java zo populair zou zijn dat je eigenlijk nog maar weinig x86 code draait, zou je x86 kunnen implementeren bovenop de JVM.

Voordeel van zulke goocheltrucs is dat je pijnloos kan switchen naar betere hardware-architecturen, maar de noodzaak moet natuurlijk wel aanwezig zijn.

[Zoijar]

roy-t schreef op vrijdag 19 december 2008 @ 23:14:
Het nut van een VM is heel simpel.
-Je schrijft 1x code en die draait op elk systeem waar het VM op draait.

C++ code draait ook op elk systeem waar de compiler back-end op draait. Of je nou een back-end moet implementeren of een VM, weinig verschil.

-Een vm kan je code beter optimalizeren voor snelheid. (je zou in theorie een java VM kunnen maken die via CUDA e.d. met je videokaart kan praten, dat VM zou er dan voor kunnen zorgen dat floatingpoint operaties op de videokaart worden uitgevoerd en de rest op de processor.)

Dat betwijfel ik. Ik denk dat een C++ compiler het beter zou moeten kunnen ivm een context op hoger niveau; in ieder geval niet minder goed.

-Een VM kan ook gebruikt worden voor extra veiligheid omdat een VM er voor kan zorgen dat de code niet buiten het VM komt. Ook kunnen applicaties die in een VM draaien meestal niet zomaar aan geheugen zitten dat niet door het VM gealloceerd is. (als in: slechte code, programma crashed, niet het hele systeem).

Native code kan niet buiten je process komen, daar is protected mode voor. Dat is een kwestie van een goed OS, wat er tegenwoordig wel is.

RayNbow schreef op zaterdag 20 december 2008 @ 01:30:
Wat is het nut van een OS? Precies, het vormen van een abstractielaag voor de applicaties die voor dat OS draaien. Een VM is niet veel anders, behalve dat tussen de VM en de hardware meer lagen zit.

[...]

Maar wat is het nut van de x86 instructieset? Juist, een abstractielaag vormen bovenop de microcode.

[...]

De reden is misschien dat mensen soms van wat meer abstractie houden zodat ze op een hoger niveau kunnen werken?

Maar het lijkt me een overbodig abstractie niveau. Er is weinig verschil tussen een compiler back-end en een VM, en back-ends waren er al voor vrijal alle systemen.

Een JVM kan (en doet dat ook) on-the-fly compilen. Het verschil zit dus in abstractie.

Ja, dus je gaat eerst een abstractie maken, en dan ga je alsnog compilen omdat het te traag loopt anders. Nodeloos ingewikkeld?

Ik ben wel blij als een door mij geschreven programma zonder moeite op een ander systeem draait.

Ik ken jouw code niet, dus daar kan ik geen uitspraken over doen. Toch valt het me op dat ik als Windows gebruiker vaak genoeg code tegenkom die ik niet werkende krijg. In de gevallen dat ik het werkende kreeg, moest ik vaak door veel hoepels springen.

Eerlijk gezegd heb ik nooit problemen meer tegenwoordig. Alles compiled en draait moeiteloos op meerdere systemen. Tenzij je echt iets op laag niveau met de hardware doet. Maar daar loop je met een VM helemaal meteen vast.

Security is iets wat meerdere lagen beslaat. Je OS regelt de security voor alle OS-gerelateerde zaken (diensten), maar het lijkt me best moeilijk voor een OS om te bepalen wat "secure" is in de hogere lagen.

Het is wel handig dat je security model platform onafhankelijk is, maar het niet iets dat je niet in een OS zou kunnen stoppen per process.

Ik zie het idd als een extra laag, die traag is en weinig toevoegt voor het merendeel van de applicaties. Het enige nuttige dat ik nog steeds zie is het draaien van remote code, zoals in een browser. Dat was volgens mij ook het hele doel aan het begin, totdat iedereen er ineens volledige applicaties in ging schrijven.

Verwijderd schreef op zaterdag 20 december 2008 @ 01:43:
Voordeel van zulke goocheltrucs is dat je pijnloos kan switchen naar betere hardware-architecturen, maar de noodzaak moet natuurlijk wel aanwezig zijn.

Dat klinkt allemaal leuk in theorie, maar in de praktijk is er vaak geen efficiente mapping naar een andere architectuur.

Overigens vind ik niks mis met java hoor, nu het er is. Op het moment dat je het kan compilen naar native code EN er is een VM aanwezig, dan is dat natuurlijk strict beter dan alleen een compiler. Ook vind ik de multi-threading support in java goed. Ik vond het alleen altijd vervelend om in te programmeren; de taal is zo... langdradig. Ook vind ik de argumenten om java te gebruiken vaak slecht. Uiteindelijk is het een keuze, en het maakt niet zo veel meer uit wat je kiest.

[ Voor 10% gewijzigd door Zoijar op 20-12-2008 05:47 ]

[Confusion]

Zoijar schreef op zaterdag 20 december 2008 @ 05:28:
Dat betwijfel ik. Ik denk dat een C++ compiler het beter zou moeten kunnen ivm een context op hoger niveau; in ieder geval niet minder goed.

Het is onvermijdelijk dat een dynamische compiler, die optimaliseert aan de hand van runtime benodigdheden en gewoon meer informatie tot zijn beschikking heeft, sneller kan zijn dan welke statische compiler dan ook. De moderne JVM blijkt in veel gevallen Java code sneller uit te voeren dan vergelijkbare C++ code, door Just-In-Time optimalisaties. Ik vind dat verder geen doorslaggevende reden, omdat de verschillen in het grootste deel van de gevallen marginaal zijn.

Native code kan niet buiten je process komen, daar is protected mode voor. Dat is een kwestie van een goed OS, wat er tegenwoordig wel is.

Het Java security model staat meer fine-grained security toe dan dat. Als je de security aan zet, dan heeft code bijvoorbeeld standaard geen enkel schrijfrecht, waar dan ook. Dat biedt in sommige gevallen meerwaarde, maar in veruit de meeste gevallen wordt de security uit gezet. Zo'n security model is zonder VM een stuk moeilijker te bouwen, maar niet onmogelijk. Misschien dat er voor C++ al zoiets is.

Ik vond het alleen altijd vervelend om in te programmeren; de taal is zo... langdradig.

Misschien is dat juist een sterk punt: het maakt glashelder wat er gebeurd en het maakt het moeilijk bochtjes af te snijden. Scripting talen als Python zijn expressiever, in de zin dat ze meer operaties in minder regels toestaan. Het grote nadeel daarvan is dat ze het voor programmeurs heel makkelijk maken hun opvolger in de voet te schieten, door fancy-dancy constructies, die zich niet gemakkelijk laten begrijpen door een andere programmeur. Je moet bij wijze van spreken in Java moeite doen om code te schrijven die de volgende niet gaat begrijpen, terwijl je in Python moeite moet doen om je niet te laten verleiden tot schijnbaar elegante oplossingen die eigenlijk heel ondoorzichtig zijn.

Hoeveel regels code je moet schrijven zou geen criterium moeten zijn om voor een bepaalde taal te kiezen: code wordt tenslotte veel vaker gelezen dan geschreven.

[ Voor 28% gewijzigd door Confusion op 20-12-2008 11:32 ]

[Zoijar]

Confusion schreef op zaterdag 20 december 2008 @ 11:08:
Het is onvermijdelijk dat een dynamische compiler, die optimaliseert aan de hand van runtime benodigdheden en gewoon meer informatie tot zijn beschikking heeft, sneller kan zijn dan welke statische compiler dan ook. De moderne JVM blijkt in veel gevallen Java code sneller uit te voeren dan vergelijkbare C++ code, door Just-In-Time optimalisaties. Ik vind dat verder geen doorslaggevende reden, omdat de verschillen in het grootste deel van de gevallen marginaal zijn.

Ok, ik dacht er verkeerd over na idd. In dat geval zal het niet veel uitmaken, Java en C++ zijn eigenlijk allebei compiled languages nu, maar java wrapped de compiler in de executable als het ware. Dynamische optimalisaties kunnen sneller zijn, maar er hangt natuurlijk wel een cost aan... dus in de praktijk wisselt het. Beetje flauwe discussie dan eigenlijk. Ik heb de java ontwikkelingen niet zo bijgehouden. Laatste keer dat ik het gebruikte was in 1999. Dus helaas ben ik denk ik schuldig aan het uit m'n nek lullen op basis van oude informatie

[farlane]

Confusion schreef op zaterdag 20 december 2008 @ 11:08:
Het is onvermijdelijk dat een dynamische compiler, die optimaliseert aan de hand van runtime benodigdheden en gewoon meer informatie tot zijn beschikking heeft, sneller kan zijn dan welke statische compiler dan ook. De moderne JVM blijkt in veel gevallen Java code sneller uit te voeren dan vergelijkbare C++ code, door Just-In-Time optimalisaties. Ik vind dat verder geen doorslaggevende reden, omdat de verschillen in het grootste deel van de gevallen marginaal zijn.

Nou is dit al de weet ik veel hoeveelste keer dat ik dit argument hoor om aan te tonen dat Java / .Net toch echt wel sneller zou zijn dan vergelijkbare code in C of C++, terwijl ik nog geen enkele keer overtuigend bewijs heb mogen zien van die stelling. ( Dat het theoretisch sneller zou moeten kunnen zijn heb ik weinig aan )

Mijn subjectieve ervaring is echter nog steeds dat .Net code ( Java heb ik minder ervaring mee ) orde groottes langzamer draait dan een vergelijkbaar iets in C of C++.

[MBV]

Jack Walsh schreef op zaterdag 20 december 2008 @ 00:25:
[...]
Alsof compileren zo moeilijk is.

Ja: veel bedrijven willen geen sourcecode meeleveren om te zorgen dat de klant het op zijn specifieke platform kan draaien, je moet maar genoegen nemen met executables. Ik geloof dat Adobe nog steeds geen flash-plugin levert voor BSD. Even compileren is leuk, maar dan moet je het nieuwe platform ook expliciet gaan supporten, en ondanks de vele standaarden lukt het maar niet om te zorgen dat C++-code overal werkt. Vaak werkt die POSIX-library toch net iets anders in BSD, of ontbreken er tools die in een ander OS wel aanwezig zijn.

Leuk dat dat in theorie kan maar als dat in de praktijk niet het geval is, dan is dat dus geen voordeel van een VM.

Zoek eens op wat JIT betekent, en wat de voordelen zijn Gebeurt standaard in Java, en daardoor hoef je door een stuk minder hoepels te springen om dezelfde snelheid te halen.

Verwijderd schreef op zaterdag 20 december 2008 @ 01:43:
[...]

Inderdaad. Je zou ook een microcode ISA kunnen maken die de Java VM implementeert.

Die is er ook: nieuws: Azul kondigt tweede generatie Java-processor aan
En het leeft nog steeds: Wikipedia: Azul Systems.

Zoijar schreef op zaterdag 20 december 2008 @ 05:28:
[...]

C++ code draait ook op elk systeem waar de compiler back-end op draait. Of je nou een back-end moet implementeren of een VM, weinig verschil.

Da's heel aardig, maar wil jij een niet-triviaal systeem schrijven wat zonder problemen op Windows en Linux draait, dan heb je een probleem. Daarbij zal je namelijk óf netwerk, óf een GUI nodig hebben, en dat zit allebei niet in C++. Met QT kan je dan weer prima portable applicaties schrijven, maar dat is amper nog een toolkit te noemen.

[...]

Dat betwijfel ik. Ik denk dat een C++ compiler het beter zou moeten kunnen ivm een context op hoger niveau; in ieder geval niet minder goed.

Runtime is er veel meer info beschikbaar, zoals hoe vaak een functie wordt aangeroepen etc.

Ja, dus je gaat eerst een abstractie maken, en dan ga je alsnog compilen omdat het te traag loopt anders. Nodeloos ingewikkeld?

Que Je zal wel JIT moeten compileren, anders kan het niet worden uitgevoerd. Simpel toch?

Ik zie het idd als een extra laag, die traag is en weinig toevoegt voor het merendeel van de applicaties. Het enige nuttige dat ik nog steeds zie is het draaien van remote code, zoals in een browser. Dat was volgens mij ook het hele doel aan het begin, totdat iedereen er ineens volledige applicaties in ging schrijven.

Heb je een benchmark waaruit blijkt dat java (exclusief opstarttijd VM) veel trager (minimaal 2x) in een real-time applicatie?

Ik vond het alleen altijd vervelend om in te programmeren; de taal is zo... langdradig. Ook vind ik de argumenten om java te gebruiken vaak slecht. Uiteindelijk is het een keuze, en het maakt niet zo veel meer uit wat je kiest.

Ik dacht eigenlijk dat een toolkit als QT minstens zo langdradig is als Java, maar daar kan ik naast zitten.

[MBV]

farlane schreef op zaterdag 20 december 2008 @ 11:58:
[...]


Nou is dit al de weet ik veel hoeveelste keer dat ik dit argument hoor om aan te tonen dat Java / .Net toch echt wel sneller zou zijn dan vergelijkbare code in C of C++, terwijl ik nog geen enkele keer overtuigend bewijs heb mogen zien van die stelling. ( Dat het theoretisch sneller zou moeten kunnen zijn heb ik weinig aan )

Mijn subjectieve ervaring is echter nog steeds dat .Net code ( Java heb ik minder ervaring mee ) orde groottes langzamer draait dan een vergelijkbaar iets in C of C++.

http://shootout.alioth.de...all&lang=gpp&lang2=javaxx De eerste en een-na-laaste test _{Ja ik heb gezien dat de recentere tests op die site java nergens meer als winnaar aanmerken}


En wat bedoel je met ordes? ik neem aan dat een lineair programma lineair blijft in Java
Ik denk dat als een taal 2x zo langzaam is, dat helemaal geen probleem is. Zolang je algoritmen maar snel genoeg zijn en het schaal-gedrag dus goed is. Extra ontwikkeltijd is veel duurder dan een extra computer.

[Zoijar]

Ik zie al dat het een holy war is als ik even google Volgens mij maakt het allemaal niet zo veel uit. Wel zie ik veel benchmarks van Java JIT tegen slecht optimized C++. Beetje flauw om JIT gewoon SSE etc te laten gebruiken en dan je C++ code te compilen met -march=i386. Verder kan je op je C++ compilatie ook dingen doen als -fprofile-generate, -fprofile-use dat dan ook run-time info gebruikt. Voor dat soort optimized benchmarks komt (volgens mij, ik heb zelf geen data) toch nog steeds wel uit dat java iets trager is. Het zal geen gigantisch verschil zijn, maar veel mensen doen wel erg makkelijk over 20-30%.

Ik wil best Java gebruiken hoor, dat zei ik eerder al. Lijkt me een prima taal tegenwoordig. Maar ik vind wel dat pro-Java mensen altijd een beetje oneerlijke vergelijkingen maken. Bij Java mag je altijd alles meerekenen: de JIT compiler, de gehele library, het feit dat voor elk platform een JVM/JIT implementatie moet worden/is geschreven, etc. Dat hoort erbij, dat is Java! Ja, maar dat kan ik met C++ bv toch ook allemaal. Oh, je gebruikt QT, nee dat kan natuurlijk niet, DAT is geen C++... Compilen en run-time optimizen op je platform? Nee, dat mag niet, je moet op de allerdomste manier je C++ code genereren: een keer op een 386 compilen en dan overal draaien. Maar ondertussen mag Java wel die hele JIT compiler draaien voor elk programma

Maar nogmaals, prima talen allemaal. C# kan je ook nog uit kiezen.

[Creepy]

MBV schreef op zaterdag 20 december 2008 @ 12:08:
[...]

http://shootout.alioth.de...all&lang=gpp&lang2=javaxx De eerste en een-na-laaste test _{Ja ik heb gezien dat de recentere tests op die site java nergens meer als winnaar aanmerken}


En wat bedoel je met ordes? ik neem aan dat een lineair programma lineair blijft in Java
Ik denk dat als een taal 2x zo langzaam is, dat helemaal geen probleem is. Zolang je algoritmen maar snel genoeg zijn en het schaal-gedrag dus goed is. Extra ontwikkeltijd is veel duurder dan een extra computer.

En met de -server commenline optie is java in nog wat meer gevallen sneller (http://shootout.alioth.debian.org/u32q/java.php)

Maar zolang er nog zat programma's zijn die op de 1 of andere manier I/O bound (disc, memory, netwerk, keyboard ) zijn hoeven we ons om dit soort vergelijkingen niet echt druk te maken wat mij betreft.

[farlane]

MBV schreef op zaterdag 20 december 2008 @ 12:08:
http://shootout.alioth.de...all&lang=gpp&lang2=javaxx De eerste en een-na-laaste test _{Ja ik heb gezien dat de recentere tests op die site java nergens meer als winnaar aanmerken}

Haha, ja en de rest van de 15 is C++ sneller, waarbij er toch 20% en meer verschil in zit.

En wat bedoel je met ordes?

Daar bedoel ik mee dat het verschil niet klein is.

Ik denk dat als een taal 2x zo langzaam is, dat helemaal geen probleem is. Zolang je algoritmen maar snel genoeg zijn en het schaal-gedrag dus goed is. Extra ontwikkeltijd is veel duurder dan een extra computer.

Jah dat is de algemene opvatting, waar ik me absoluut niet in kan vinden, misschien geldt dat voor "enterprise" applicaties maar er zijn genoeg voorbeelden te verzinnen waar dit niet opgaat. ( embedded software bv )
Ik heb het idee dat dit argument te vaak wordt gebruikt om maar niet al te veel moeite te hoeven doen om een goed stuk software af te leveren.

[MBV]

Creepy schreef op zaterdag 20 december 2008 @ 12:36:
[...]

En met de -server commenline optie is java in nog wat meer gevallen sneller (http://shootout.alioth.debian.org/u32q/java.php)

Wel met C++ vergelijken, die is veel sneller

Zoijar schreef op zaterdag 20 december 2008 @ 12:23:
Ik zie al dat het een holy war is als ik even google Volgens mij maakt het allemaal niet zo veel uit. Wel zie ik veel benchmarks van Java JIT tegen slecht optimized C++. Beetje flauw om JIT gewoon SSE etc te laten gebruiken en dan je C++ code te compilen met -march=i386. Verder kan je op je C++ compilatie ook dingen doen als -fprofile-generate, -fprofile-use dat dan ook run-time info gebruikt. Voor dat soort optimized benchmarks komt (volgens mij, ik heb zelf geen data) toch nog steeds wel uit dat java iets trager is. Het zal geen gigantisch verschil zijn, maar veel mensen doen wel erg makkelijk over 20-30%.

Enig idee hoeveel ontwikkeltijd dat kost op een groot project? Het voordeel van Java is dat dat allemaal 'gratis' is, en je dus direct die performance geniet. March=386 is inderdaad niet eerlijk, maar 100.000 compile-opties geven voor het laatste beetje performance ook niet.

Ik wil best Java gebruiken hoor, dat zei ik eerder al. Lijkt me een prima taal tegenwoordig. Maar ik vind wel dat pro-Java mensen altijd een beetje oneerlijke vergelijkingen maken. Bij Java mag je altijd alles meerekenen: de JIT compiler, de gehele library, het feit dat voor elk platform een JVM/JIT implementatie moet worden/is geschreven, etc. Dat hoort erbij, dat is Java! Ja, maar dat kan ik met C++ bv toch ook allemaal. Oh, je gebruikt QT, nee dat kan natuurlijk niet, DAT is geen C++... Compilen en run-time optimizen op je platform? Nee, dat mag niet, je moet op de allerdomste manier je C++ code genereren: een keer op een 386 compilen en dan overal draaien. Maar ondertussen mag Java wel die hele JIT compiler draaien voor elk programma

Maar nogmaals, prima talen allemaal. C# kan je ook nog uit kiezen.

QT riep ik specifiek, omdat het ook een uitbreiding op de taal is (voegt syntactic sacharin toe ). Behalve dat is QT geen onderdeel van de taal: het is een library daarin om programmeren makkelijker te maken. Dus in C++ zelf zit helemaal niks om cross-platform een GUI te schrijven, net zoals er in Java niks cross-platform zit om de com-poort aan te sturen.

[MBV]

farlane schreef op zaterdag 20 december 2008 @ 12:56:
[...]

Haha, ja en de rest van de 15 is C++ sneller, waarbij er toch 20% en meer verschil in zit.

Hij was ook niet serieus bedoeld, maar er vroeg iemand om een voorbeeld waar Java sneller was. Alstu

Daar bedoel ik mee dat het verschil niet klein is.

Ok, dus 20% is een orde? Voor mij is een orde-verschil het verschil tussen een lineair en een kwadratisch algoritme.

Jah dat is de algemene opvatting, waar ik me absoluut niet in kan vinden, misschien geldt dat voor "enterprise" applicaties maar er zijn genoeg voorbeelden te verzinnen waar dit niet opgaat. ( embedded software bv )
Ik heb het idee dat dit argument te vaak wordt gebruikt om maar niet al te veel moeite te hoeven doen om een goed stuk software af te leveren.

Voor embedded high-performance dingen zal ik niet snel java aanraden, o.a. vanwege het geheugengebruik. Voor sommige specifieke applicaties is 20% performance wel cruciaal (3d), en daar moet je vooral gaan bit-fucken.
Maar Java is prima voor algemene software. Voor veel software op de desktop is het verschil tussen 50ms en 100ms verwerkingstijd niet relevant, zolang het maar snel blijft werken bij grotere aantallen (gegroeid aantal medewerkers/klanten/artikelen/...). Daar is de big-O-notatie zo belangrijk voor.

[Creepy]

MBV schreef op zaterdag 20 december 2008 @ 12:59:
Wel met C++ vergelijken, die is veel sneller

Whoops...

[.oisyn]

MBV schreef op zaterdag 20 december 2008 @ 12:59:
March=386 is inderdaad niet eerlijk, maar 100.000 compile-opties geven voor het laatste beetje performance ook niet.

Ik heb nog nooit 100.000 compile opties mee hoeven geven, en ik heb ook nog nooit mijn compile opties voor een specifiek app aan hoeven passen om dat app sneller te draaien. In VC++ kies je simpelweg voor whole program optimization en een minimum gesupporte architectuur (bijv. SSE2), that's it.

En waar de vele C++ compilers helemaal mee winnen is dat ze intrinsics ondersteunen voor bijv. SSE, zodat je gewoon vector classes kunt maken die direct compileren naar inline SSE code. Ik heb nog geen compiler/jitter gezien die generiekere float bewerkingen fatsoenlijk kunnen parallelliseren naar SIMD.

Overigens kan ik in 10 minuten tijd die binary_tree app sneller maken dan z'n java implementatie, simpelweg door een andere memory allocator te gebruiken.

[ Voor 30% gewijzigd door .oisyn op 20-12-2008 13:29 ]

[RayNbow]

MBV schreef op zaterdag 20 december 2008 @ 13:05:
Maar Java is prima voor algemene software.

Java is ook prima voor wireless sensor nodes.

[Zoijar]

Ik ook nog drie puntjes

- Waarom is de ontwikkeltijd van een java project zoveel lager dan een C++ project? Het lijken me redelijk dezelfde talen als je ze beheerst. Zie niet in waarom hier een significant verschil in zit.

- Iedereen roept altijd: je moet niet op de snelheid van de taal letten, maar op de algoritmes. Uiteraard implementeer je dezelfde algoritmes in beide talen. Het enige performance verschil komt dan uit de taal. 2x verschil vind ik aanzienlijk. Natuurlijk kan je er een computer bij zetten, maar dat kan dan in het andere geval ook. Het blijft een factor 2 (bijvoorbeeld). Soms maakt dat niet uit, soms wel, maar waarom zou je het niet sneller willen hebben? Dat is die hele code bloat mentaliteit van tegenwoordig en naar mijn idee een van de redenen dat ik nog steeds 5 minuten moet wachten op een boot tot ik mijn mail kan checken op een multi-Ghz quad core. (iets dat overigens niet veel sneller gaat nu dan 10 jaar geleden op m'n pentium 60)

- Eens met oisyn over geheugen management. Ik lees vaak dat een voordeel van garbage collection het contiguous alloceren van geheugen oid zou zijn, dat dat het zelfs sneller maakt. Het is vrij common practice om in C++ verschillende allocators te gebruiken (indien van belang), bijvoorbeeld een small-object-allocator die rechstreeks uit een block alloceert en vele maller sneller is dan default new.

[ Voor 3% gewijzigd door Zoijar op 20-12-2008 15:07 ]

[Confusion]

farlane schreef op zaterdag 20 december 2008 @ 11:58:
Nou is dit al de weet ik veel hoeveelste keer dat ik dit argument hoor om aan te tonen dat Java / .Net toch echt wel sneller zou zijn dan vergelijkbare code in C of C++, terwijl ik nog geen enkele keer overtuigend bewijs heb mogen zien van die stelling. ( Dat het theoretisch sneller zou moeten kunnen zijn heb ik weinig aan )

Op basis van willekeurige benchmarks is geen overtuigend bewijs te geven, aangezien het er juist om gaat dat een JIT bijvoorbeeld ziet welke codepaden vaak gebruikt worden en het programma dan voor die veelgebruikte paden optimaliseert. Een benchmark heeft onvoldoende verscheidenheid aan codepaden om dat soort effecten zichtbaar te maken. Je hebt er wel degelijk iets aan dat het theoretisch sneller zou moeten zijn, omdat dit juist theorie is die zich in de gebruikspraktijk manifesteert. Je kan het effect demonstreren en je zou het demonstratieprogramma een benchmark kunnen noemen, maar als je er op staat dat het in een willekeurige benchmark sneller zou moeten zijn, dan is het per definitie niet aan te tonen.

Zoijar schreef op zaterdag 20 december 2008 @ 12:23:
Ik zie al dat het een holy war is als ik even google

Volgens mij is dat omdat het discussies zijn waar zowel de voor- als de tegenstanders eigenlijk niet begrijpen, of niet goed verwoorden, op welke manier de JIT nu eigenlijk voordeel kan bieden boven een statische compiler. Op basis van een set benchmarks, zoals de Debian shootout, hierover discussieren, is zoiets als vergelijken welke auto op een F1 circuit sneller is, terwijl het punt was dat een Subaru Impreza over een gemiddelde van tal van terreinsoorten een snellere tijd neer zal zetten dan een Lotus Esprit. God mag ook weten waarom ze zich er zo druk over maken, aangezien de verschillen waarschijnlijk voor de meeste applicaties marginaal blijven, hoewel het verschil met de toenemende kwaliteit van de JIT natuurlijk wel groter wordt en iedere tiende procent voor serverfarms een behoorlijk verschil kan betekenen.

Zoijar schreef op zaterdag 20 december 2008 @ 15:05:
- Waarom is de ontwikkeltijd van een java project zoveel lager dan een C++ project? Het lijken me redelijk dezelfde talen als je ze beheerst. Zie niet in waarom hier een significant verschil in zit.

Ik ken de cijfers niet en zonder een standpunt in te nemen: ik kan me voorstellen dat er de laatste jaren in Java zo ontzettend veel libraries en frameworks zijn uitgebracht, dat je jezelf door het gebruik van zo'n library aardig wat tijd kan besparen, die je in C++ wel moet besteden, omdat een vergelijkbare library ontbreekt. Maar dit geheel zonder enige kennis van C++ en de daar beschikbare libraries.

Telkens als ik de nieuwe TIOBE rankings zie, dan vraag ik me af waarom Java zo ontzettend veel meer gebruikt wordt dan andere talen. Ik kan me niet voorstellen dat dat enkel door marketing komt.

[ Voor 26% gewijzigd door Confusion op 20-12-2008 15:34 ]

[farlane]

Confusion schreef op zaterdag 20 december 2008 @ 15:19:
Op basis van willekeurige benchmarks is geen overtuigend bewijs te geven, aangezien het er juist om gaat dat een JIT bijvoorbeeld ziet welke codepaden vaak gebruikt worden en het programma dan voor die veelgebruikte paden optimaliseert. Een benchmark heeft onvoldoende verscheidenheid aan codepaden om dat soort effecten zichtbaar te maken. Je hebt er wel degelijk iets aan dat het theoretisch sneller zou moeten zijn, omdat dit juist theorie is die zich in de gebruikspraktijk manifesteert. Je kan het effect demonstreren en je zou het demonstratieprogramma een benchmark kunnen noemen, maar als je er op staat dat het in een willekeurige benchmark sneller zou moeten zijn, dan is het per definitie niet aan te tonen.

Het zou dan toch gemiddeld over de vele verchillende benchmarks die gedraaid worden moeten aangeven dat het even snel zo niet sneller zou zijn dan C en/of C++, ook die indruk krijg ik niet.
Het blijft altijd bij de uitspraak dat het theoretisch zo zou moeten zijn, mijn punt is dat het zo lang het in de praktijk niet zo is het een bewering is waar ik niets mee kan.

Ik ken de cijfers niet en zonder een standpunt in te nemen: ik kan me voorstellen dat er de laatste jaren in Java zo ontzettend veel libraries en frameworks zijn uitgebracht, dat je jezelf door het gebruik van zo'n library aardig wat tijd kan besparen, die je in C++ wel moet besteden, omdat een vergelijkbare library ontbreekt. Maar dit geheel zonder enige kennis van C++ en de daar beschikbare libraries.

Als er ergens veel libraries voor te krijgen zijn is het wel C. (en daarmee dus ook C++)

Telkens als ik de nieuwe TIOBE rankings zie, dan vraag ik me af waarom Java zo ontzettend veel meer gebruikt wordt dan andere talen. Ik kan me niet voorstellen dat dat enkel door marketing komt.

Omdat Java developers vaker dingen intikken op Google? Geen idee eerlijk gezegd..

[RayNbow]

Zoijar schreef op zaterdag 20 december 2008 @ 15:05:
Ik ook nog drie puntjes

- Waarom is de ontwikkeltijd van een java project zoveel lager dan een C++ project? Het lijken me redelijk dezelfde talen als je ze beheerst. Zie niet in waarom hier een significant verschil in zit.

Is er uberhaupt ooit onderzoek gedaan naar de productiviteit van programmeertalen? Vervolgens is de vraag van wat het belangrijkst is. Ontwikkeltijd? Is dit dan de totale ontwikkeltijd of alleen de tijd die je nodig had om de code in te tikken? Is het belangrijk om rekening te houden met hoeveel tijd je kwijt bent aan onderhoud na de ontwikkeling? Hoeveel invloed heeft de taal op vermindering van bugs en fouten? Heeft deze vermindering daadwerkelijk te maken met de taal zelve of met de programmeurs die het aantrekt om erin te gaan programmeren? Et cetera.

- Iedereen roept altijd: je moet niet op de snelheid van de taal letten, maar op de algoritmes.

Je moet letten op de requirements.

Uiteraard implementeer je dezelfde algoritmes in beide talen. Het enige performance verschil komt dan uit de taalcompiler.

Het verschil in performance zou ik eerder aan de compiler toekennen dan de taal, maar .oisyn zal hier vast nog wel een voetnoot bij plaatsen.

2x verschil vind ik aanzienlijk. Natuurlijk kan je er een computer bij zetten, maar dat kan dan in het andere geval ook. Het blijft een factor 2 (bijvoorbeeld).

Krijg je die factor 2 altijd gratis als je bijv. C++ kiest in plaats van Java? Of hangt het ook nog af van het soort toepassing waar je aan werkt?

Soms maakt dat niet uit, soms wel, maar waarom zou je het niet sneller willen hebben?

Sneller is altijd mooi meegenomen, maar je moet wel afwegen of het niet ten koste van andere dingen gaat.

Dat is die hele code bloat mentaliteit van tegenwoordig en naar mijn idee een van de redenen dat ik nog steeds 5 minuten moet wachten op een boot tot ik mijn mail kan checken op een multi-Ghz quad core. (iets dat overigens niet veel sneller gaat nu dan 10 jaar geleden op m'n pentium 60)

Tanenbaum zou in dit geval de monolithische kernels de schuld geven.

- Eens met oisyn over geheugen management. Ik lees vaak dat een voordeel van garbage collection het contiguous alloceren van geheugen oid zou zijn, dat dat het zelfs sneller maakt.

Ik weet wel dat in Java het opruimen van de meeste objecten geen tijd kost.

Het is vrij common practice om in C++ verschillende allocators te gebruiken (indien van belang), bijvoorbeeld een small-object-allocator die rechstreeks uit een block alloceert en vele maller sneller is dan default new.

In dit geval biedt C++ meer flexibiliteit door de programmeur meer controle te geven. Ik heb geen idee hoeveel vrijheid de JVM biedt met het finetunen van de GC, maar de standaardinstellingen zijn denk ik good enough voor de meesten.

(In feite is dit gewoon een geval van hoeveel tijd je wilt en hebt te besteden.)

farlane schreef op zaterdag 20 december 2008 @ 16:00:
[...]

Het zou dan toch gemiddeld over de vele verchillende benchmarks die gedraaid worden moeten aangeven dat het even snel zo niet sneller zou zijn dan C en/of C++, ook die indruk krijg ik niet.
Het blijft altijd bij de uitspraak dat het theoretisch zo zou moeten zijn, mijn punt is dat het zo lang het in de praktijk niet zo is het een bewering is waar ik niets mee kan.

"In de praktijk"?
The Dangers of Benchmarks

[...]

Als er ergens veel libraries voor te krijgen zijn is het wel C. (en daarmee dus ook C++)

Louter het aantal beschikbare libraries is niet het enige wat belangrijk is. Is de library stable? Is het portable? Wordt het nog onderhouden? Hoe is de documentatie? Is er support? Is het gemakkelijk te installeren en te gebruiken?

[ Voor 13% gewijzigd door RayNbow op 20-12-2008 16:18 ]

[.oisyn]

Die index is dan ook best suf. Ze pakken gewoon search engine ratings voor de zoekterm "<language> programming". Dus ze tellen ten eerste gewoon het aantal websites over dat onderwerp (is niet gelijk aan hoeveel het gebruikt wordt), en ten tweede alleen die websites waar de programmeertaal gevolgd wordt door het woord "programming".

Neem bijvoorbeeld PHP, "PHP Programming" heeft bij google 1.35 miljoen hits. Echter wordt er bij PHP vaak ook gesproken over scripting, en als ik zoek naar ["PHP programming" OR "php scripting"], dan kom ik op 3.17 miljoen hits. Dat is meer dan "Java programming" (3.28 miljoen hits). Dus waarom staat PHP niet bovenaan? En denk je ook dat PHP daadwerkelijk meer gebruikt in de software industrie dan Java? En waarom gebruiken al die mensen dan Java, als PHP blijkbaar zo populair is?

RayNbow schreef op zaterdag 20 december 2008 @ 16:10:
Ik weet wel dat in Java het opruimen van de meeste objecten geen tijd kost.

Het is dan ook geen opruimen, maar gewoon aan de kant schuiven totdat je de resources daadwerkelijk weer nodig hebt. Ik heb een C++ memory allocator gemaakt die precies dat doet, en dat zorgt in m'n got contest implementatie voor een factor 3 tot 4 snelheidsverschil. En je daadwerkelijke programmacode hoeft er niet eens anders voor geschreven te worden.

[ Voor 24% gewijzigd door .oisyn op 20-12-2008 16:29 ]

[MBV]

Zoijar schreef op zaterdag 20 december 2008 @ 15:05:
Ik ook nog drie puntjes

- Waarom is de ontwikkeltijd van een java project zoveel lager dan een C++ project? Het lijken me redelijk dezelfde talen als je ze beheerst. Zie niet in waarom hier een significant verschil in zit.

- Geen garbage collector zelf schrijven/uitzoeken/overal netjes verwijderen.
- Daardoor minder kans op memory leaks, die best wel wat tijd kunnen kosten in de onderhoudsfase
- Eenvoudiger debuggen
- Minder quirks (ik hoor steeds iets roepen over bools in vectors in C++, wat is daarmee?)

- Iedereen roept altijd: je moet niet op de snelheid van de taal letten, maar op de algoritmes. Uiteraard implementeer je dezelfde algoritmes in beide talen. Het enige performance verschil komt dan uit de taal. 2x verschil vind ik aanzienlijk. Natuurlijk kan je er een computer bij zetten, maar dat kan dan in het andere geval ook. Het blijft een factor 2 (bijvoorbeeld). Soms maakt dat niet uit, soms wel, maar waarom zou je het niet sneller willen hebben? Dat is die hele code bloat mentaliteit van tegenwoordig en naar mijn idee een van de redenen dat ik nog steeds 5 minuten moet wachten op een boot tot ik mijn mail kan checken op een multi-Ghz quad core. (iets dat overigens niet veel sneller gaat nu dan 10 jaar geleden op m'n pentium 60)

Ik weet niet wat voor flut-OS jij gebruikt , maar Linux is echt veel sneller geworden, en met de technieken die nu voor de deur staan wordt dat alleen maar beter. Probleem is dat het OS veel groter wordt, steeds meer moet kunnen doen (bluetooth, wifi, fancy 3d-animaties), en bij het opstarten gelimiteerd wordt door de HDD. Wil je 2x zo veel doen, dan zal je waarschijnlijk 2x zoveel van je HDD moeten halen, en zo veel sneller zijn de harde schijven (relatief gezien) niet geworden de afgelopen jaren.
Dat je hetzelfde algoritme implementeert in verschillende talen vind ik niet vanzelfsprekend: als de libraries een heel efficiente sort-functie hebben, ga ik dat gebruiken, en geen eigen algoritme. Ga je functionele programmeertalen gebruiken, dan wordt het nog leuker.

RayNbow schreef op zaterdag 20 december 2008 @ 16:10:
[...]

Is er uberhaupt ooit onderzoek gedaan naar de productiviteit van programmeertalen? Vervolgens is de vraag van wat het belangrijkst is. Ontwikkeltijd? Is dit dan de totale ontwikkeltijd of alleen de tijd die je nodig had om de code in te tikken? Is het belangrijk om rekening te houden met hoeveel tijd je kwijt bent aan onderhoud na de ontwikkeling? Hoeveel invloed heeft de taal op vermindering van bugs en fouten? Heeft deze vermindering daadwerkelijk te maken met de taal zelve of met de programmeurs die het aantrekt om erin te gaan programmeren? Et cetera.

Een paper "Comparing observed bug and productivity rates for Java and C++" uit '99 door ene Geoffrey Philips is een van de weinige papers die ik via google scholar kon vinden. Summary:

An experiment was conducted to compare programmer productivity and defect rates for Java and C++.
A modified version of the Personal Software Process (PSP) was used to gather defect rate, bug rate, and productivity data on C++ and Java during two real world development projects. A bug is defined to be a problem detected during testing or deployment. A defect is either a bug, or an error detected during compile time. A typical C++ program had two to three times as many bugs per line of code as a typical Java program. C++ also generated between 15 per cent and 50 per cent more defects per line, and perhaps took six times as long to debug. Java was between 30 per cent and 200 per cent more productive, in terms of lines of code per minute. When defects were measured against development time, Java and C++ showed no difference, but C++ had two to three times as many bugs per hour. Statistics were generated using student’s t-test at a 95 per cent confidence level. Some discussion of why the differences occurred is included, but the reasons offered have not been tested experimentally. The study is limited to one programmer over two projects, so it is not a definitive experimental result. The programmer was experienced in C++, but only learning Java, so the results would probably favour Java more strongly for equally-experienced programmers. The experiment shows that it is possible to experimentally measure the fitness of a programming language.
Copyright Ó 1999 John Wiley & Sons, Ltd.

Nogal een flutonderzoek dus. Als iemand een betere paper tegenkomt via scholar.google.com ofzo, kan ik ze meestal gratis inzien (TU/e ), ik ben wel benieuwd.

[.oisyn]

MBV schreef op zaterdag 20 december 2008 @ 18:01:
- Geen garbage collector zelf schrijven/uitzoeken

Doe je maar 1 keer.

- Daardoor minder kans op memory leaks, die best wel wat tijd kunnen kosten in de onderhoudsfase

Onzin, ik heb nog nooit meegemaakt dat memory leaks "best wel wat tijd kostte". Een leak in Java lijkt me bovendien veel lastiger te detecteren, maar daar weet ik verder weinig van.

- Eenvoudiger debuggen

Argumentatie?

[PrisonerOfPain]

Zoijar schreef op vrijdag 19 december 2008 @ 19:07:
[...]

Boost heeft dat allemaal. Eigenlijk wil je niet allemaal clutter en bloat aan een taal toevoegen die je ook makkelijk kan implementeren als support library.

TR1 en 2 zijn practisch rechtstreeks gecopieerd uit boost dat neemt niet weg dat het wat mij betreft extreem handig is om deze, toch vrij fundamentele, functionaliteiten als filesystem support centraal in een taal aanwezig zijn.

Dat het in boost aanwezig is vind ik verder prima hoor, alleen vind ik het een beetje triest dat je voor iedere nuttige feature naar een support library word door verwezen. Dat je dingen als boost::order_my_pizza niet in je taal wilt hebben zitten snap ik ook wel.

De taal zelf wil je schoon houden, en de officiele support library wil je ook daadwerkelijk universeel houden.

Dat zijn filesystem support en regular expressions dan wat mij betreft ook, de laatste keer dat ik een filesystem zonder directories zag was in 1783. Regular expressions net zo, op het moment is text parsen in C++ gewoon niet op een normale manier te doen.

Hoe meer je daar aan toevoegt, hoe groter de kans dat er devices zijn die geen C++ runtime library kunnen draaien. Dingen als een multi-threaded memory model kan je niet zo maar als library implementeren, daar moeten echt taal garanties voor worden gegeven.

Ik heb me nog niet in het multi-threaded memory model verdiept maar ik kan me zo voorstellen dat juist dat een van de dingen is die het aantal devices sterk zou kunnen limiteren.

.oisyn schreef op zaterdag 20 december 2008 @ 18:23:
[...]

Doe je maar 1 keer.

Waarna dat ding in maintenance beland en daar door een hoop geld kost.

Onzin, ik heb nog nooit meegemaakt dat memory leaks "best wel wat tijd kostte". Een leak in Java lijkt me bovendien veel lastiger te detecteren, maar daar weet ik verder weinig van.

Probeer iets als dit maar eens te debuggen.

[ Voor 14% gewijzigd door PrisonerOfPain op 20-12-2008 19:37 ]

[.oisyn]

PrisonerOfPain schreef op zaterdag 20 december 2008 @ 19:34:
Probeer iets als dit maar eens te debuggen.

Te simpel. Break op de allocatie. Plaats een data watchpoint op de pointer member van de auto_ptr, en kom erachter dat de pointer wordt overschreven maar het geheugen niet wordt vrijgegeven.

[Zoijar]

Of even door valgrind

Maar ik zie weer dezelfde argumenten mbt beschikbare libraries. Zowel Java als C++ hebben genoeg 'standaard' libraries om het meeste dat je wilt te kunnen doen. Of je nu #include <tr1/regex> moet typen of import java.util.regex, ik zie het verschil niet. Of is import java.* ineens "java" maar een include niet. Onzin natuurlijk. Het ging om de taal. Grappig dat iemand iets zei over monolitische OS kernels: je wilt een taal ook modulair opzetten met zo'n klein mogelijke, gestandaardiseerde "kernel" en de rest in pluggen aan de hand van support libraries. Ik vind dat dus geen argument om deze twee talen te vergelijken. Op dat punt scoren ze gelijk naar mijn idee. (C++ support meer legacy libraries, maar dat terzijde)

Dat Java makkelijker debugged heb ik nog geen overtuigend argument voor gehoord.

Garbage collection is een manier van programmeren in C++ (raii / smart pointers) die je gewoon aan moet houden, dan is het eigenlijk geen enkel probleem en hebben al je objecten precies de lifetime je verwacht. Het ging me ook om twee programmeurs die beide de taal beheersen. Ik kan voor mezelf nog steeds niet het performance verschil verantwoorden.

[RayNbow]

Zoijar schreef op zaterdag 20 december 2008 @ 21:02:
Maar ik zie weer dezelfde argumenten mbt beschikbare libraries. Zowel Java als C++ hebben genoeg 'standaard' libraries om het meeste dat je wilt te kunnen doen. Of je nu #include <tr1/regex> moet typen of import java.util.regex, ik zie het verschil niet. Of is import java.* ineens "java" maar een include niet. Onzin natuurlijk. Het ging om de taal.

Het probleem in discussies is dat met "Java" zowel de taal, de JVM als het gehele platform kan worden bedoeld.

Grappig dat iemand iets zei over monolitische OS kernels: je wilt een taal ook modulair opzetten met zo'n klein mogelijke, gestandaardiseerde "kernel" en de rest in pluggen aan de hand van support libraries. Ik vind dat dus geen argument om deze twee talen te vergelijken. Op dat punt scoren ze gelijk naar mijn idee. (C++ support meer legacy libraries, maar dat terzijde)

Het is idd mooi als een taal zelf zo klein mogelijk blijft. Standaard libraries zijn echter ook belangrijk, het Batteries Included principe. Dit laatste beseften de hackers in de Haskell community laatst en is er een plan opgezet om zo veel mogelijk libraries van GHC af te splitsen en een zo goed mogelijk en kwalitatief Haskell platform op te zetten (1, 2, 3).

Garbage collection is een manier van programmeren in C++ (raii / smart pointers) die je gewoon aan moet houden, dan is het eigenlijk geen enkel probleem en hebben al je objecten precies de lifetime je verwacht. Het ging me ook om twee programmeurs die beide de taal beheersen. Ik kan voor mezelf nog steeds niet het performance verschil verantwoorden.

Ik heb geen verstand van smart pointers, maar kun je met smart pointers ook gemakkelijk iets implementeren als een copying collector?

Ik kwam trouwens net deze OOPSLA paper tegen over GC vs explicit memory management, maar heb 'm nog niet gelezen.

[bomberboy]

Zoijar schreef op zaterdag 20 december 2008 @ 05:28:
C++ code draait ook op elk systeem waar de compiler back-end op draait. Of je nou een back-end moet implementeren of een VM, weinig verschil.

Ik moet toegeven dat ik zeker geen specialist ben wat betreft C++, maar geloof je dat nou echt zelf?
Ok, noch backend, noch VM moet je typisch zelf implementeren, dus daar zit inderdaad geen verschil. Maar de portabiliteit is typisch toch veel minder groot voor C++ code. zeker als er ook GUIs komen bij kijken.
En bv. ook threads, niet altijd vanzelfsprekend dat dezelfde threadinglibraries beschikbaar zijn op alle platformen. Of vergis ik me hierin (oprechte vraag).

Een andere vraag, wat voor applicatieservers bestaan er voor C++ componenten? Het type componenten die in binary vorm aangeleverd worden (denk aan J2EE, JAIN SLEE, OSGi, Tomcat etc)
Hercompileren is leuk, maar soms heb je de source niet of wil je die niet vrijgeven. Bovendien wil je als vendor ook geen 7 verschillende platformen ondersteunen als het ook met één platform kan. (nl een J2EE server, en ja, ik weet dat een typische J2EE app wat massage nodig heeft om op de applicatieservers van verschillende vendors te werken)

Zoals eerder al aangehaald is onderhoud van software op de lange termijn een heel grote kost, en dat is een manier waarop je daar heel grote besparingen kan doen.

Tot slot, in de tweakers programming contest doen de Java applicaties het typisch niet zo slecht ;-) Dus qua performance kan dat niet zo slecht zijn

[MBV]

Zoijar schreef op zaterdag 20 december 2008 @ 21:02:
Of even door valgrind

Maar ik zie weer dezelfde argumenten mbt beschikbare libraries. Zowel Java als C++ hebben genoeg 'standaard' libraries om het meeste dat je wilt te kunnen doen. Of je nu #include <tr1/regex> moet typen of import java.util.regex, ik zie het verschil niet. Of is import java.* ineens "java" maar een include niet. Onzin natuurlijk. Het ging om de taal.

Het is heel simpel. Met Java heb je 1 leverancier, met C++ moet je op 10 plekken je support krijgen. Als iets het niet doet in java kan je als bedrijf java bellen dat ze het moeten fixen, terwijl je van Trolltech te horen krijgt dat GCC een foutje maakt, en het uit eindelijk aan boost bleek te liggen. Je kiest een pakket, en bent klaar.
De taal alleen is C++ zonder stdlib, java zonder imports, en allebei zijn onwerkbaar. Alles wat je los schrijft moet onderhouden worden, en zoals hier al vaker is gezegd: onderhoud is he tduurste.

Dat Java makkelijker debugged heb ik nog geen overtuigend argument voor gehoord.

Misschien is het ook niet eerlijk, omdat ik in Java veel simpelere dingen doe (parser bouwen voor embedded SQL) dan ik in C++ heb gedaan (3D applicatie). Maar in C++ ben ik altijd veel langer bezig geweest met debuggen waar mijn fout zit dan in Java.

Garbage collection is een manier van programmeren in C++ (raii / smart pointers) die je gewoon aan moet houden, dan is het eigenlijk geen enkel probleem en hebben al je objecten precies de lifetime je verwacht. Het ging me ook om twee programmeurs die beide de taal beheersen. Ik kan voor mezelf nog steeds niet het performance verschil verantwoorden.

Daar heb je het dus al: je moet je aan de manier van programmeren houden. Volgend jaar beslis jij dat je iets anders wilt gaan doen, en komt er iemand waarvan jouw baas denkt dat hij C++ kent om jouw applicatie te onderhouden. Doordat je in Java automatische garbage collection hebt, en dat in C++ afhangt van de programmeur, maak je de kans op fouten tijdens onderhoud groter.

En performance is het argument waar je maar op terug blijft komen, ondanks dat iedereen toch wel zo ver wilt gaan dat het (bijvoorbeeld) 20% langzamer is. Is java de grootste vloek van de informatica omdat het 20% langzamer is dan C++? Jij gebruikt Java liever niet omdat jouw applicaties kennelijk heel erg goed moeten performen. Zijn er nog andere redenen?

Even een side-note: welk C++ framework zouden jullie gebruiken om een enterprise-applicatie met webinterface te schrijven?

[PrisonerOfPain]

MBV schreef op zondag 21 december 2008 @ 00:28:
Even een side-note: welk C++ framework zouden jullie gebruiken om een enterprise-applicatie met webinterface te schrijven?

Welke rendering engine zou jij in Java gebruiken om een 3d platformer te maken?

Je raakt met die vraag nu net de essentie van de verschillende standpunten, iedere taal heeft een z'n eigen probleem domein (of domeinen) en dat is meestal ook het geen waar die taal het sterkst in is. Ondanks dat het mogelijk is om beide soorten applicaties in beide talen te schrijven wil het niet zeggen dat de ene taal meer geschikt is om een bepaald probleem op te lossen dan de andere. Daar door ontwikkelt iedere taal zich op een andere manier.

Zo wil C++ waarschijnlijk zo min mogelijk dingen ongespecificeerd laten zodat de verschillende compilers betere optimalisaties kunnen doen voor hun specifieke platform. Terwijl Java meer baat heeft bij een uniform platform omdat het makkelijker en goedkoper is om daar voor te ontwikkelen.

[ Voor 0% gewijzigd door PrisonerOfPain op 21-12-2008 01:48 . Reden: O-) ]

[.oisyn]

PrisonerOfPain schreef op zondag 21 december 2008 @ 01:38:
Java [..] baad

Exactly
Sorry, 't was too obvious

[PrisonerOfPain]

.oisyn schreef op zondag 21 december 2008 @ 01:41:
[...]

Exactly
Sorry, 't was too obvious

My post just entered maintenance .

[writser]

Zoijar schreef op zaterdag 20 december 2008 @ 21:02:
Maar ik zie weer dezelfde argumenten mbt beschikbare libraries. Zowel Java als C++ hebben genoeg 'standaard' libraries om het meeste dat je wilt te kunnen doen. Of je nu #include <tr1/regex> moet typen of import java.util.regex, ik zie het verschil niet.

Een verschil is onder andere dat de C++ versie (nog) niet standaard met je compiler wordt meegeleverd en dat "tr1/regex" nog geen 2000 hits oplevert op google. Ik heb geen idee wat het is. Dat is bij de java-concurrent dan toch wel een stukje beter geregeld.

Garbage collection is een manier van programmeren in C++ (raii / smart pointers) die je gewoon aan moet houden, dan is het eigenlijk geen enkel probleem en hebben al je objecten precies de lifetime je verwacht.

Dat is niet echt een argument imo. Oude code, collega's of bugs kunnen er allemaal voor zorgen dat er memory-leaks optreden in je programma. In C++ _moet_ iedereen zich aan een bepaalde manier van programmeren houden en foutloos programmeren. In Java zorgt de VM er voor dat er geen memory leaks optreden. Dat is toch wel een klein verschil ..

[.oisyn]

writser schreef op zondag 21 december 2008 @ 02:00:
[...]

Een verschil is onder andere dat de C++ versie (nog) niet standaard met je compiler wordt meegeleverd en dat "tr1/regex" nog geen 2000 hits oplevert op google. Ik heb geen idee wat het is.

Zoijar bedoelde <regex>. Std::tr1 zit bijv. al standaard bij MSVC++ 2008 en is ook verkrijgbaar via boost.

In Java zorgt de VM er voor dat er geen memory leaks optreden.

Onzin, waarom denken mensen dat toch altijd? De VM zorgt er hoogstens voor dat de dingen waar jij geen referentie meer naar hebt worden opgeruimd, maar dat betekent niet dat je niet alsnog referenties kunt leaken waarvan je even vergeet dat ze bestaan (zoals bijv. in een eigen ArrayList implementatie waarbij je bij het verwijderen van elementen vergeet de vrijgekomen posities op null te zetten)

[Zoijar]

bomberboy schreef op zaterdag 20 december 2008 @ 22:30:
Ik moet toegeven dat ik zeker geen specialist ben wat betreft C++, maar geloof je dat nou echt zelf?
Ok, noch backend, noch VM moet je typisch zelf implementeren, dus daar zit inderdaad geen verschil. Maar de portabiliteit is typisch toch veel minder groot voor C++ code. zeker als er ook GUIs komen bij kijken.
En bv. ook threads, niet altijd vanzelfsprekend dat dezelfde threadinglibraries beschikbaar zijn op alle platformen. Of vergis ik me hierin (oprechte vraag).

Vroeger had je wel gelijk, maar tegenwoordig heb je op de meeste praktische platforms niet echt last. Als je echt embedded dingen doet weet ik het niet. Maar als het gaat om linux/macos/windows is er geen enkel probleem.

Een andere vraag, wat voor applicatieservers bestaan er voor C++ componenten? Het type componenten die in binary vorm aangeleverd worden (denk aan J2EE, JAIN SLEE, OSGi, Tomcat etc)
Hercompileren is leuk, maar soms heb je de source niet of wil je die niet vrijgeven. Bovendien wil je als vendor ook geen 7 verschillende platformen ondersteunen als het ook met één platform kan. (nl een J2EE server, en ja, ik weet dat een typische J2EE app wat massage nodig heeft om op de applicatieservers van verschillende vendors te werken)

Zoals eerder al aangehaald is onderhoud van software op de lange termijn een heel grote kost, en dat is een manier waarop je daar heel grote besparingen kan doen.

Ja, dat is idd een voordeel van Java. Ik hou me daar eerlijk gezegd niet zo mee bezig, dus ik weet er weinig van...

Tot slot, in de tweakers programming contest doen de Java applicaties het typisch niet zo slecht ;-) Dus qua performance kan dat niet zo slecht zijn

Op zich een mooi voorbeeld. Stel dat je daar een zoekboom hebt en je mag maar een bepaalde tijd rekenen, dan kom je zelfs met slechts 20-30% meer performance gewoon dieper en heb je een goede kans op een beter antwoord. Scheelt het veel? Het kan je de overwinning schelen

---

RayNbow schreef op zaterdag 20 december 2008 @ 22:12:
Ik heb geen verstand van smart pointers, maar kun je met smart pointers ook gemakkelijk iets implementeren als een copying collector?

Geen verstand van. Een collector is dat GC? Is dat iets als two-space GC? Dat is het enige dat ik ooit in C heb geimplementeerd voor een toy OO compiler (uni opdracht...)

Ik kwam trouwens net deze OOPSLA paper tegen over GC vs explicit memory management, maar heb 'm nog niet gelezen.

Wat een abstract... een hele kolom

These results quantify
the time-space tradeoff of garbage collection: with five times as
much memory, an Appel-style generational collector with a noncopying
mature space matches the performance of reachabilitybased
explicitmemory management. With only three times asmuch
memory, the collector runs on average 17% slower than explicit
memory management. However, with only twice as much memory,
garbage collection degrades performance by nearly 70%.

Auw... Het is even snel hoor, als je 5x zo veel geheugen hebt

[ Voor 22% gewijzigd door Zoijar op 21-12-2008 11:31 ]

[Confusion]

.oisyn schreef op zondag 21 december 2008 @ 04:05:
Onzin, waarom denken mensen dat toch altijd? De VM zorgt er hoogstens voor dat de dingen waar jij geen referentie meer naar hebt worden opgeruimd, maar dat betekent niet dat je niet alsnog referenties kunt leaken waarvan je even vergeet dat ze bestaan (zoals bijv. in een eigen ArrayList implementatie waarbij je bij het verwijderen van elementen vergeet de vrijgekomen posities op null te zetten)

Denk je niet dat we als we de hoeveelheid C++ programmeurs die een keer tegen een memoryleak zijn opgelopen afzetten tegen de hoeveelheid Java programmeurs die ooit tegen een memoryleak zijn opgelopen, dat de eerste groep dan orden van grootte groter is?

Overigens kwam ik net dit artikel van Steve Yegge tegen, waarin hij een aantal redenen voor VM's boven compilers geeft, waaronder

Virtual machines are great for language interoperability. If everybody in the world used his language, then yeah, you probably wouldn't need a virtual machine. You'd probably still want one eventually, because of the just-in-time compilers, and all the runtime information they can get.

maar lees vooral verder vanaf daar, want hij heeft een aardig verhaal over een meeting waar een hele rits bekende VM-implementers aanwezig waren.

[bomberboy]

Zoijar schreef op zondag 21 december 2008 @ 11:28:
[TweakersContest]
Op zich een mooi voorbeeld. Stel dat je daar een zoekboom hebt en je mag maar een bepaalde tijd rekenen, dan kom je zelfs met slechts 20-30% meer performance gewoon dieper en heb je een goede kans op een beter antwoord. Scheelt het veel? Het kan je de overwinning schelen

Ik heb het net nog even gechecked, en van de 3 reeds afgelopen contests zijn er 2 gewonnen door een Java oplossing, en één door een C++ oplossing. Niet echt representatief natuurlijk.
Kijkend naar de top 3 waren er 6 java-oplossingen en 2 C/C++ oplossingen.
Nog steeds niet representatief natuurlijk, maar om even terug naar het originele topic te gaan, is Java dan misschien toch niet zo verschrikkelijk. Want als het dan trager is, moeten de algoritmes van de Java-oplossingen toch wel beter zijn dan die van de C++ oplossingen

_{note: deze reactie is niet heel erg serieus bedoeld he}

[Zoijar]

MBV schreef op zondag 21 december 2008 @ 00:28:
En performance is het argument waar je maar op terug blijft komen, ondanks dat iedereen toch wel zo ver wilt gaan dat het (bijvoorbeeld) 20% langzamer is. Is java de grootste vloek van de informatica omdat het 20% langzamer is dan C++? Jij gebruikt Java liever niet omdat jouw applicaties kennelijk heel erg goed moeten performen. Zijn er nog andere redenen?

writser schreef op zondag 21 december 2008 @ 02:00:
Dat is niet echt een argument imo. Oude code, collega's of bugs kunnen er allemaal voor zorgen dat er memory-leaks optreden in je programma. In C++ _moet_ iedereen zich aan een bepaalde manier van programmeren houden en foutloos programmeren. In Java zorgt de VM er voor dat er geen memory leaks optreden. Dat is toch wel een klein verschil ..

Ah, en nu komen we eindelijk bij de conclusie: java programmeurs worden lui en onoplettend, en nieuwe programmeurs worden op die manier opgeleid, en iedereen weet dat daar fouten van komen Het gaat zeg maar van "Java kan niet leaken" naar "Wat is een leak?". (niet dat ik het daar helemaal mee eens ben hoor; je kan natuurlijk prima een top java programmeur zijn die gewoon alles weet.)

Even een side-note: welk C++ framework zouden jullie gebruiken om een enterprise-applicatie met webinterface te schrijven?

Wt? .NET? Geen idee.

Ik vraag me toch een beetje af hoeveel run-time information een (JIT) compiler nou echt nuttig kan gebruiken. Dat lees ik steeds: we have run-time info. En wat doen ze daar dan nuttig mee? Iets meer performance? En dan vervolgens roepen dat een applicatie die 2x zo langzaam is niet uitmaakt? En wat kost het om die run-time info te verzamellen? Meer of minder dan wat het oplevert?

bomberboy schreef op zondag 21 december 2008 @ 11:46:
Ik heb het net nog even gechecked, en van de 3 reeds afgelopen contests zijn er 2 gewonnen door een Java oplossing, en één door een C++ oplossing. Niet echt representatief natuurlijk.
Kijkend naar de top 3 waren er 6 java-oplossingen en 2 C/C++ oplossingen.
Nog steeds niet representatief natuurlijk, maar om even terug naar het originele topic te gaan, is Java dan misschien toch niet zo verschrikkelijk. Want als het dan trager is, moeten de algoritmes van de Java-oplossingen toch wel beter zijn dan die van de C++ oplossingen

_{note: deze reactie is niet heel erg serieus bedoeld he}

En gewogen naar frequentie van inzendingen? 99 mensen die java gebruikten en eentje met C++ die steeds in de top 3 komt?

Ik ben ook niet zo serieus hoor; ik zie gewoon veel argumenten die naar mijn idee niet kloppen

[ Voor 20% gewijzigd door Zoijar op 21-12-2008 11:55 ]

[Confusion]

Zoijar schreef op zondag 21 december 2008 @ 11:51:
Ah, en nu komen we eindelijk bij de conclusie: java programmeurs worden lui en onoplettend, en nieuwe programmeurs worden op die manier opgeleid, en iedereen weet dat daar fouten van komen

Volgens mij beginnen we nu in herhaling te vallen: Zoijar in "Is java de grootste vloek in de informat..."

[RayNbow]

Zoijar schreef op zondag 21 december 2008 @ 11:28:
[...]

Geen verstand van. Een collector is dat GC? Is dat iets als two-space GC? Dat is het enige dat ik ooit in C heb geimplementeerd voor een toy OO compiler (uni opdracht...)

Ja, een Two-space GC is een copying collector.

[...]

Auw... Het is even snel hoor, als je 5x zo veel geheugen hebt

Het is dan altijd ook een tradeoff tussen performance qua geheugen en performance qua tijd. Als je het geheugen tot je beschikking hebt, dan zie ik iig geen probleem om het te gebruiken.

De paper laat wel zien dat GC soms een kleine fractie sneller is met grotere heaps.

[Zoijar]

Confusion schreef op zondag 21 december 2008 @ 12:10:
Volgens mij beginnen we nu in herhaling te vallen: Zoijar in "Is java de grootste vloek in de informat..."

Haha Ja, deze hele discussie is een grote herhaling van andere fora

RayNbow schreef op zondag 21 december 2008 @ 13:52:
Ja, een Two-space GC is een copying collector.

Ah ok. Nee, dat heb je dan dus niet nodig met smart pointers. Die gebruiken reference counting. Het principe gaat op voor alle resources eigenlijk, inclusief geheugen dus. Een "object" blijft bestaan zolang het referencable is. Bij elk kopie van de smart pointer gaat de reference count omhoog, en bij elke destructie omlaag (zijn nog wat details, maar die zijn niet belangrijk nu). Als de reference count naar 0 gaat wordt het opgeruimd. Daar hoef je verder niet op te letten. Zoiets krijg je dan:

C++:

typedef boost::smart_ptr<Object> OPtr;

void foo(OPtr x) {
   // do stuff with x, ie x->foo(); etc.

   // assign new object
   x = new Object();

   // oops, error here
   throw "error";
}

void main() {
   try {
      OPtr obj = new Object(); // make object on heap
      foo(obj);
   } catch (...) {}
}

Deze code leaked niet, zelfs niet bij de exception. Als je ziet hoe makkelijk dit gaat, wat is dan eigenlijk nog het echte nut van GC? Overigens hebben smart pointers ook een cost natuurlijk, zeker in multi-threaded omgevingen.

Het is dan altijd ook een tradeoff tussen performance qua geheugen en performance qua tijd. Als je het geheugen tot je beschikking hebt, dan zie ik iig geen probleem om het te gebruiken.

De paper laat wel zien dat GC soms een kleine fractie sneller is met grotere heaps.

5x zo veel geheugen geen probleem? Dat betekent dat elk huidig 4GB systeem maar effectief 800MB kan gebruiken in een complete GC omgeving. Jouw app is niet de enige die draait Ik vind het wederom een vrij grote cost voor weinig benefit. Uiteraard is dat op te lossen door er gewoon 20GB in te prikken...

[Remus]

writser schreef op zondag 21 december 2008 @ 02:00:
[...]
Dat is niet echt een argument imo. Oude code, collega's of bugs kunnen er allemaal voor zorgen dat er memory-leaks optreden in je programma. In C++ _moet_ iedereen zich aan een bepaalde manier van programmeren houden en foutloos programmeren. In Java zorgt de VM er voor dat er geen memory leaks optreden. Dat is toch wel een klein verschil ..

Dat is dus niet helemaal waar, als ik in Java een referentie vasthoudt terwijl ik het object eigenlijk niet meer nodig heb, dan is er net zo goed sprake van een memory leak, dan als ik in C vergeet een object te free-en.

Hoewel ik zelf meer met Java heb, is het natuurlijk wel zo dat het bewust bezig zijn met (de)allocatie in C de programmeur wel scherper houdt. Het grote nadeel is natuurlijk dat als je dan steken laat vallen (en mensen zijn faalbaar, dus dat gebeurt ook), dat de 'problemen' groter zijn dan in een taal met garbagecollection.

[RayNbow]

Zoijar schreef op zondag 21 december 2008 @ 14:39:
[...]

Ah ok. Nee, dat heb je dan dus niet nodig met smart pointers. Die gebruiken reference counting. Het principe gaat op voor alle resources eigenlijk, inclusief geheugen dus. Een "object" blijft bestaan zolang het referencable is. Bij elk kopie van de smart pointer gaat de reference count omhoog, en bij elke destructie omlaag (zijn nog wat details, maar die zijn niet belangrijk nu). Als de reference count naar 0 gaat wordt het opgeruimd. Daar hoef je verder niet op te letten. Zoiets krijg je dan:

C++:

typedef boost::smart_ptr<Object> OPtr;

void foo(OPtr x) {
   // do stuff with x, ie x->foo(); etc.

   // assign new object
   x = new Object();

   // oops, error here
   throw "error";
}

void main() {
   try {
      OPtr obj = new Object(); // make object on heap
      foo(obj);
   } catch (...) {}
}

Deze code leaked niet, zelfs niet bij de exception. Als je ziet hoe makkelijk dit gaat, wat is dan eigenlijk nog het echte nut van GC? Overigens hebben smart pointers ook een cost natuurlijk, zeker in multi-threaded omgevingen.

Maar werkt reference counting ook als je te maken hebt met cyclische structuren?

[...]

5x zo veel geheugen geen probleem? Dat betekent dat elk huidig 4GB systeem maar effectief 800MB kan gebruiken in een complete GC omgeving. Jouw app is niet de enige die draait Ik vind het wederom een vrij grote cost voor weinig benefit. Uiteraard is dat op te lossen door er gewoon 20GB in te prikken...

Daarom is het ook een afweging. Je kan ook besluiten om een GC te gebruiken en minder performance. Het hangt totaal af van de requirements en je beschikbare resources (CPU, RAM, aantal ontwikkelaars in dienst, beschikbaar budget, beschikbare ontwikkeltijd, aanwezigheid bestaande tools en libs, etc.).

[roy-t]

MBV schreef op vrijdag 19 december 2008 @ 23:36:
[...]

De Zune en XBox360 draaien het compact framework, dus ik weet niet of die alle leuke gimmicks die eerder zijn opgenoemd daarin draaien. O.a. delegates werken niet, de rest kan ik zo 1-2-3 niet vinden.

Zover ik weet, maar ik zou het even moeten testen, werken alle language features zoals delegates juist wel op het compact framework maar zijn het vooral wat libraries die er niet in zitten. Ik zou het even moeten testen door een deploy naar mijn Xbox te doen maar ik ben toevallig niet thuis, zal het snel proberen!

@ Zoijar:

Java ontwikkeltijd is wat lager omdat er minder gekke fouten gemaakt kunnen worden. (je krijgt bij een rare fout meteen een exception naar de regel code waar het fout gaat, terwijl je in C++ zover ik weet door rare mem fouten wel is heel erg op het verkeerde been gebracht kunt worden) Ook omdat Java een managed en safe taal is heb je minder test-tijd nodig (vind men).

Verder is C++ ondanks al die Java en .Net test (en het feit dat ik een ontzettend .Net fanboy ben) imho toch nog steeds sneller, maar dan hebben we het over 10~20% wat in programmeer kosten (C++ programmeurs zijn duurder en de ontwikkeltijd iets langer) natuurlijk niet meer uit maakt voor zoiets als een standaard backoffice programma.

C++ heeft wel nog steeds nut bij het maken van applicaties waar elke ns telt, of waar er erg weinig resources zijn.

Ik vraag me wel heel erg af wanneer/of de game industrie over gaat naar een managed taal, mijn geklooi met C#+XNA/MDX geeft voor mij het gevoel dat managed talen toch rijp zijn om daar gebruikt te gaan worden.Vooral nu de ontwikkelkosten van games zo de pan uit reizen zou het leuk zijn als hiermee de ontwikkeltijd en kosten ietwat gedrukt kunnen worden. Helaas beschik ik zelf niet over de expertise om 2 dezelfde games/test te maken in C++ en C# om te zien of er echt performance verschil is. Maar misschien dat Oisyn hier wat meer over kan vertellen?

[ Voor 52% gewijzigd door roy-t op 21-12-2008 16:45 ]

[.oisyn]

Confusion schreef op zondag 21 december 2008 @ 11:41:
[...]

Denk je niet dat we als we de hoeveelheid C++ programmeurs die een keer tegen een memoryleak zijn opgelopen afzetten tegen de hoeveelheid Java programmeurs die ooit tegen een memoryleak zijn opgelopen, dat de eerste groep dan orden van grootte groter is?

Lees nu nog eens de reactie waar ik op reageer. Sommige mensen hebben de misvatting dat je met Java geen memory leaks kunt hebben. Complete onzin. Ik heb niet gezegd dat het net zo makkelijk is als in C++, en dat brengt ons meteen naar het punt waarom ik je vergelijking zo nutteloos vind - zet nu eens de ervaren C++ programmeurs af tegen de ervaren Java programmeurs, dan geloof ik al niet meer dat het om ordes van groottes gaat. Ik zou niet eens weten of memleaks(C++) > memleaks(Java) in dat geval, juist omdat C++'ers er meer mee bezig zijn dan Java'ers, waarbij die laatste groep veel meer het idee kan hebben "ach, dat wordt toch wel opgeruimd". Maar goed, dat was verder ook niet het punt dat ik probeerde te maken in mijn vorige post.

[ Voor 9% gewijzigd door .oisyn op 21-12-2008 16:37 ]

[Verwijderd]

.oisyn schreef op zondag 21 december 2008 @ 16:34:
Ik zou niet eens weten of memleaks(C++) > memleaks(Java) in dat geval, juist omdat C++'ers er meer mee bezig zijn dan Java'ers, waarbij die laatste groep veel meer het idee kan hebben "ach, dat wordt toch wel opgeruimd". Maar goed, dat was verder ook niet het punt dat ik probeerde te maken in mijn vorige post.

Maar op zich hebben die Java'ers wel gelijk dat de VM dat toch wel opruimt. Zodra je een nieuw object in de arraylist stopt is de reference naar de oude verdwenen. Als je vergeet een verwijderd element te nullen, dan zullen een aantal objecten in de arraylist blijven zitten totdat een nieuw object de plaats inneemt, maar dat kan nooit een significante hoeveelheid geheugen zijn (anders had je toch al niet genoeg geheugen voor de arraylist).

Ik heb geleerd om de VM nooit te proberen te 'helpen', omdat het toch niet nodig is. De VM kan prima zelf bepalen wanneer iets verwijderd moet worden. En in dit geval is het dus ook geen leak.

[Confusion]

.oisyn schreef op zondag 21 december 2008 @ 16:34:
Lees nu nog eens de reactie waar ik op reageer. Sommige mensen hebben de misvatting dat je met Java geen memory leaks kunt hebben. Complete onzin. Ik heb niet gezegd dat het net zo makkelijk is als in C++,

Maar dat is wel een beetje de suggestie die gewekt wordt: mensen geven het argument dat je in Java geen memory leaks kunt hebben en hoewel dat feitelijk onjuist is, maakt dat de strekking van het argument niet direct onwaar. Nu wordt het argument afgedaan op basis van de feitelijke onjuistheid en wordt er aan de strekking voorbij gegaan.

en dat brengt ons meteen naar het punt waarom ik je vergelijking zo nutteloos vind - zet nu eens de ervaren C++ programmeurs af tegen de ervaren Java programmeurs, dan geloof ik al niet meer dat het om ordes van groottes gaat. Ik zou niet eens weten of memleaks(C++) > memleaks(Java) in dat geval, juist omdat C++'ers er meer mee bezig zijn dan Java'ers, waarbij die laatste groep veel meer het idee kan hebben "ach, dat wordt toch wel opgeruimd".

Ervaren programmeurs zijn moeilijk om aan te komen. Mijn idee was meer: de grote hoeveelheid programmeurs die niet ervaren zijn (en misschien dat ook nooit zullen zijn) zullen het er in Java beter vanaf brengen dan in C++, omdat bijvoorbeeld de memory-management kopzorg voor ze weggenomen is (en ze toch nooit dingen hoeven te bouwen die complex genoeg zijn om in Java tegen een memory leak aan te lopen).

[.oisyn]

Verwijderd schreef op zondag 21 december 2008 @ 16:49:
Als je vergeet een verwijderd element te nullen, dan zullen een aantal objecten in de arraylist blijven zitten totdat een nieuw object de plaats inneemt, maar dat kan nooit een significante hoeveelheid geheugen zijn (anders had je toch al niet genoeg geheugen voor de arraylist).

Die redenatie klopt dus niet. Ten eerste hoef je de arraylist niet opnieuw te vullen - stel je doet gewoon een clear() en je laat 'm voor wat ie is, al die objecten blijven dan in leven. En je kunt er geen reet over zeggen of dat veel geheugen kost, omdat de resources niet gelimiteerd zijn door alleen die objecten, maar ook alle objecten die weer door die objecten worden gerefereerd, enzovoorts.

Ik heb geleerd om de VM nooit te proberen te 'helpen', omdat het toch niet nodig is. De VM kan prima zelf bepalen wanneer iets verwijderd moet worden. En in dit geval is het dus ook geen leak.

Het hele punt is dat de VM dat niet kan als jij onnodig referenties houdt naar objecten. Als jij een globale reference hebt voor iets dat je maar heel tijdelijk nodig hebt, dan is het heel verstandig om die reference na gebruik weer op null te zetten. Het is niet dat Java een GC heeft dat je daarom maar niet meer na hoeft te denken over object lifetimes.

http://www.ibm.com/developerworks/library/j-leaks/index.html
Ik las ooit eens een artikel over *ik geloof* AWT die een hele zwik resources vasthield als je ergens vergat een listener te verwijderen van een component, maar die kan ik niet meer vinden. Misschien was het niet AWT, maar het ging iig om een GUI library.

Nou develop ik weinig in Java, maar zijn hier veel mensen die in Java veel gebruik maken van weak references? En dan denk ik met name aan library ontwikkelaars.

[ Voor 12% gewijzigd door .oisyn op 21-12-2008 17:05 ]

[.oisyn]

Confusion schreef op zondag 21 december 2008 @ 16:54:
[...]

Maar dat is wel een beetje de suggestie die gewekt wordt: mensen geven het argument dat je in Java geen memory leaks kunt hebben en hoewel dat feitelijk onjuist is, maakt dat de strekking van het argument niet direct onwaar. Nu wordt het argument afgedaan op basis van de feitelijke onjuistheid en wordt er aan de strekking voorbij gegaan.

Daar ben ik het dus niet mee eens, zie vooral de laatste alinea in mijn vorige post. Nadenken over object lifetime is een essentieel onderdeel van software design imho, en denken "dat de VM het wel opruimt" is iets dat de Java ontwikkelaars geen goed doet. Natuurlijk, als je dat niet doet in C++ dan heb je daar een stuk meer last van dan als je dat niet doet in Java.

Ervaren programmeurs zijn moeilijk om aan te komen. Mijn idee was meer: de grote hoeveelheid programmeurs die niet ervaren zijn (en misschien dat ook nooit zullen zijn) zullen het er in Java beter vanaf brengen dan in C++, omdat bijvoorbeeld de memory-management kopzorg voor ze weggenomen is (en ze toch nooit dingen hoeven te bouwen die complex genoeg zijn om in Java tegen een memory leak aan te lopen).

Ik heb dan ook niet gezegd dat C++ net zo makkelijk is te leren als Java, en dat vind ik ook niet. Java is een heel stuk makkelijker. Misschien zelfs iets te makkelijk.

[ Voor 3% gewijzigd door .oisyn op 21-12-2008 17:06 ]

[Creepy]

Verwijderd schreef op zondag 21 december 2008 @ 16:49:
[...]

Maar op zich hebben die Java'ers wel gelijk dat de VM dat toch wel opruimt.

Nee, dat hebben ze niet altijd en dat is ook .oisyns punt. De JVM ruimt niet alles volautomatisch voor je op. Wel veel, maar niet altijd alles: http://www.google.nl/sear...=UTF-8&q=java+memory+leak

Er zijn mensen die denken dat het onmogelijk is om een mem. leak te hebben in Java. En dat verbaast me aan de ene kant. Aan de andere kant ook niet omdat niet iedereen zich echt lijkt te verdiepen in de omgeving waarmee ze ontwikkelen.

[ Voor 21% gewijzigd door Creepy op 21-12-2008 17:57 ]

[Confusion]

.oisyn schreef op zondag 21 december 2008 @ 17:02:
Daar ben ik het dus niet mee eens, zie vooral de laatste alinea in mijn vorige post. Nadenken over object lifetime is een essentieel onderdeel van software design imho, en denken "dat de VM het wel opruimt" is iets dat de Java ontwikkelaars geen goed doet.

Nadenken over object lifetimes is breder dan nadenken over memory management. Daarin zit geen verschil tussen C++ en Java: de VM beslist bijvoorbeeld niet voor je wanneer een object uit een cache gegooid moet worden. Over hoeveel geheugen je gebruikt moet je in alle talen nadenken, maar niet over de manier waarop dat geheugen gebruikt wordt op het moment dat het gebruikt wordt. Het lijkt me dat dat is wat hier relevant is: stukje boekhouding die je niet meer hoeft te doen.

[Salvatron]

roy-t schreef op zondag 21 december 2008 @ 16:31:
Helaas beschik ik zelf niet over de expertise om 2 dezelfde games/test te maken in C++ en C# om te zien of er echt performance verschil is. Maar misschien dat Oisyn hier wat meer over kan vertellen?

Hier is in ieder geval een vergelijking tussen C en Java bij het spel Quake2:
http://bytonic.de/html/benchmarks.html

[Verwijderd]

.oisyn schreef op zondag 21 december 2008 @ 16:58:
http://www.ibm.com/developerworks/library/j-leaks/index.html
Ik las ooit eens een artikel over *ik geloof* AWT die een hele zwik resources vasthield als je ergens vergat een listener te verwijderen van een component, maar die kan ik niet meer vinden. Misschien was het niet AWT, maar het ging iig om een GUI library.

Hier is een artikel: http://www.oracle.com/tec...masterj2ee/j2ee_wk11.html

Het gaat om EventListeners in het algemeen. Die problemen los je op met een weak reference.

Nou develop ik weinig in Java, maar zijn hier veel mensen die in Java veel gebruik maken van weak references? En dan denk ik met name aan library ontwikkelaars.