Bedoel je niet juist dat je het niet expliciet moet regelen (want dat moet in C++ juist)?
hihi woeps. ge-edit
Heb je hier documentatie over?
In een handige plek, heh, ben bang van niet. Er zitten veel pareltjes tussen slides van javaone/jug en verwante sessies van de bijbehorende conferenties. Ook is er het nodige verspreid te vinden in blogs. Daarnaast zitten er dingen verstopt tussen andere lange verhalen over performance algemeen. Hopelijk vergeef je het me als ik niet mijn hele avond er aan spendeer om deze terug te zoeken.
Dingen die je waarschijnlijk als had gevonden staan vermoedelijk wel hier:
http://java.sun.com/perfo...e/whitepapers/tuning.html (gedateerd 2005) Kiezen van de juiste garbage collector kan best grote impact hebben.
Fancier /onbekende dingen moet je denken aan:
Geheugen dat er standaard gereserveerd word bij een nieuw thread kan je opgeven(als je heel veel kort levende threads gebruikt kan dit handig zijn.
Technieken voor het manage van lifecylces van je objecten en wat de (sun) jvm blindelings wel kan weg optimaliseren.
En dat wil je aandragen als voorbeeld dat code in Java sneller is dan vergelijkbare code in PHP?
Hier bedoel je waarschijnlijk c++ (zend interperter voor php is volgens mij in c++

) Maar nee dat was mijn punt niet helemaal. Ik probeerde meer een kanttekening te plaatsen bij 'basaal'.
Java blijft sneller worden bij c++ verandert er minder(daar koop je trouwens helemaal niets voor, maar om een of andere rede vonden mijn vingers dat ik dat moest typen

)
Er is een budget van tijd, energie en/of geld en binnen dit kader is het verschil dat nu tussen c++ en java ligt niet heel significant als je de kunde van de developer er bij betrekt. (wat je eigenlijk ook zelf zegt middels je voorbeeld)
Ik zeg ook niet dat de VM er geen gebruik van maakt, ik zeg dat jij (als programmeur) er geen gebruik van kunt maken. De effectiviteit van SIMDing compilers is (helaas nog) ver te zoeken
Ja, ok, ligt aan je perspectief, als jij je code zo opschrijft dat je er zo goed als zeker van uit kan gaan dat het gebruikt word, gebruik je het nog altijd niet direct zelf. Ik heb me er niet ver in verdiept ik herinner me alleen de discussie dat iemand klaagde over SIMD support en dat het antwoord was dat de jvm optimalisatie uitvoert mbv SIMD sinds (ik dacht) 1.4 en dat het wat serieuze vormen aan nam in 6 en 7. Hij melde dat het idd nog al tricky was. Ik zal me er nog een keer verder in gaan verdiepen.
Technieken voor het manage van lifecylces van je objecten en wat de (sun) jvm blindelings wel kan weg optimaliseren.
Hmm, nou krijg ik het idee dat we het niet over hetzelfde hebben. Vooral als ik even de alinea van tegen het einde van je reactie erbij haal:
Er is een budget van tijd, energie en/of geld en binnen dit kader is het verschil dat nu tussen c++ en java ligt niet heel significant als je de kunde van de developer er bij betrekt. (wat je eigenlijk ook zelf zegt middels je voorbeeld)
Daar ben ik het helemaal mee eens, maar het punt was dat de VM voor het grote deel verantwoordelijk was voor het soepel laten lopen van Java (dmv optimalisaties die min of meer automatisch tailored zijn aan het gebruik van de applicatie omdat ze at runtime plaatsvinden).
Waar deze discussie mee begon is de opmerking van alex3305 die zei dat Java juist langzaam was door de VM. Reinste kolder natuurlijk, het is juist andersom - Java kan door de VM juist goed meekomen met native talen

. Vandaar mijn punt - als je de VM uit Java weg zou denken zou het stroperig gaan werken wegens taalconstructies die het mist (zoals ruwe pointers, maar denk ook aan het feit dat elke method automatisch 'virtual' is terwijl je daar in C++ voor kunt kiezen - voor het aanroepen van een virtual method betaal je een performance penalty om de simpele reden dat de CPU niet vantevoren weet waar de call naartoe leidt, wat een pipeline flush als gevolg heeft).
That said, niets weerhoudt je ervan (iig niet de C++ specificatie) om een C++ applicatie in een VM te draaien, zodat die gebruik kan maken van dezelfde voordelen

.
Hier bedoel je waarschijnlijk c++
Euh ja idd, "woeps" van mijn kant

[SIMD in Java]
Hmm interessant, daar zal ik het eea over opzoeken
