Dat artikel waar je naar linkt staat vol met onzin, vooral in het stukje over de theorie waarom Java sneller dan C of C++ zou kunnen zijn.
In cases where the compiler cannot determine the necessary information at compile time, the C pointer problem may actually be the bigger performance hit
Dat "C pointer problem" heet het aliasing probleem, en moderne compilers hebben de optie om je code te compileren waarin de compiler aanneemt dat er geen aliasing optreedt. Daarnaast kun je ook hinten dat er geen aliasing optreedt ('__restrict' keyword). En ruwe pointers overal naartoe hebben is sowieso bad practice.
In the java case, the loop bound(s) can be kept in registers, and the index is certainly in a register, so a register-register test is needed. In the C/C++ case a load from memory is needed.
Waarom? Onzin.
With GC, a) the allocator doesn't need to look for memory, it knows where it is,
Ook onzin. De performance van heap allocaties hangt af van de gebruikte heuristieken, en die hoeven voor GC-based heaps niet anders te zijn dan voor nonmanaged heaps. De spec van C en C++ sluiten overigens geen GC uit (zie bijv. het werk van
Hans Boehm), dus alleen al zeggen dat C/C++ geen GC heeft is onzin (en in de C++0x spec worden GC features juist expliciet toegevoegd, en de net genoemde Boehm is daar ook zeer bij betrokken).
The JIT compiler knows more than a conventional "pre-compiler", and it may be able to do a better job given the extra information
Er is niets dat het JITen van C of C++ code tegenhoudt. En hier bestaan geloof ik al implementaties van.
Overigens, ik vind niet dat Java traag is. Java applicaties zijn dat echter vaak wel, door een over de top geabstraheerd design van zowel de applicaties zelf als frameworks als Swing. Wat ik wel vind is dat Java of .Net geen geschikte kandidaten zijn voor high performance applicaties zoals games en simulaties. Simpelweg omdat veel 'native' talen je veel meer vrijheid geven om daadwerkelijk met de hardware te interfacen (door bijv. expliciete SIMD intrinsics te gebruiken zoals SSE op de x86, of de cache te instructen)
[Reactie gewijzigd door .oisyn op woensdag 3 september 2008 15:23]
Correct.
Met C/C++ heb ik overigens maar een beperkte ervaring, dus daar ga ik geen uitspraak over doen.
Ik doelde met het artikel dan ook vooral op de laatste sectie: Conclusions: Why is "Java is Slow" so Popular?, omdat sommigen blijkbaar toch nog altijd de onzin verkondigen dat de taal java op zich traag zou zijn, zonder ook maar enige kennis van zaken.
En omdat voor enkele jaren (pre-JIT) Java ook daadwerkelijk langzaam was. Maar het hele probleem is gewoon dat eentje zegt dat Java traag is, en anderen nemen dat gewoon over. Was ik zelf ook schuldig aan, als ik heel eerlijk ben.
Hier ben je toch wel een beetje te defensief. Want [quote]Er is niets dat het JITen van C of C++ code tegenhoudt. En hier bestaan geloof ik al implementaties van.[/quite] is natuurlijk volkomen waar. Het is echter net zo waar dat je JAVA gewoon native kan compileren. Je argument dat
Java of .Net geen geschikte kandidaten zijn voor high performance applicaties zoals games en simulaties. Simpelweg omdat veel 'native' talen je veel meer vrijheid geven om daadwerkelijk met de hardware te interfacen (door bijv. expliciete SIMD intrinsics te gebruiken zoals SSE op de x86, of de cache te instructen)
gaat daar volkomen aan voorbij.
ik ben het toch wel in grote lijnen met je eens. Java wordt nu eenmaal voornamelijk met een JIT gebruikt en C++ als native code. Een JIT heeft voor en nadelen en kan betere prestaties leveren dan een statische executable die niet voor een bepaald platform geoptimaliseerd is. Tegelijkertijd is een statische executable die alle optimalisaties heeft voor een bepaald platform waarschijnlijk sneller dan wanneer er een JIT gebruikt wordt. Een JIT weet nu eenmaal minder dan de ontwikkelaar.
Als je dus een programma ontwikkeld voor een bekend platform (zeg PS3) en met een voorspelbare inputstroom zul je waarschijnlijk het effectiefste in native talen kunnen werken. Is het platform onbekend of is het gebruik van het programma onvoorspelbaar kan een JIT compiler afhankelijk van het platform en het gebruik optimalisaties toepassen waardoor de performance van de applicatie verbetert wordt.
De keuze voor een JIT of niet betekent nu in feite ook de keuze voor een taal. Als we die keuze los laten is er geen reden waarom Java sneller of langzamer is dan C++. Beide talen zijn dan redelijk gelijkwaardig. Maken we de koppeling wel zijn er situaties waarbij het gebruik van Java (met JIT) optimaal is (mobiel en server based) en situaties waarbij native(zonder JIT) beter uitpakt. (consoles en Windows)
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
Volgens Google wijst eigen onderzoek uit dat als pagina's zelfs maar een fractie van een seconde sneller laden, meer mensen zijn diensten gebruiken. Gegeven de enorme aantallen Google-gebruikers vertaalt dat zich al snel in meer advertentieomzet voor het bedrijf. Met Chrome probeert het bedrijf dan ook de snelheids-bottleneck van traditionele browsers aan te pakken.
15:21
13:28
![[show]](http://tweakimg.net/g/if/comments/button_down.gif "Reactie uitklappen")
Door 
Thuis geen last op Vista x64 daar vind ik hem echt superfijn.
.
Een plugin die alleen advertenties van andere providers zou blocken zou ook nogal hypocriet zijn. Mousegestures zou ik ook wel graag zien ja, wellicht is het er vlug genoeg.
