Eclipse-plugin van AMD meet prestaties van Java-applicaties

AMD heeft de Eclipse-plugin Codesleuth onder een opensourcelicentie beschikbaar gemaakt. De tool kan gegevens direct uit een processor lezen, zodat Java-ontwikkelaars hun code kunnen optimaliseren op cpu-gebruik.

AMD heeft op Eclipsecon, een conferentie voor Eclipse-gebruikers, aangekondigd dat Codesleuth als opensourceprogramma beschikbaar wordt gemaakt. Met deze Eclipse-plugin kunnen ontwikkelaars inzicht krijgen in de performance van hun Java-code: Codesleuth ontsluit de data die Codeanalyst Performance Analyzer uit processors leest. Met behulp van de analysedata kan de Java-code aangepast worden om optimale prestaties te leveren.

De plugin moet ontwikkelaars tijd besparen door het zoeken naar performance-problemen te versnellen. Door gebruik te maken van de in processors ingebouwde performance counters kan de Codeanalyst-software analyseren hoe de cpu op de aangeboden code reageert. Vertragingen in de verwerking worden door Codesleuth naar de Java-code herleid, zodat eventuele fouten door de programmeur hersteld kunnen worden. Aangezien de Codesleuth-software afhankelijk is van Codeanalyst, werkt de plugin alleen met data afkomstig van Barcelona-processors. Sourceforge heeft de code onder de Eclipse Public License in Subversion gezet.

Reacties (20)

[Verwijderd]

Vast een knap stukje technologie maar de praktische waarde lijkt me heel beperkt. Eigenlijk meer iets voor ontwikkelaars van JVM's. Als applicatie-ontwikkelaar ga je er toch vanuit dat een JVM zijn werk goed doet. Dit tool lijkt me erg JVM afhankelijk - het hangt er maar net vanaf hoe de engine de code optimaliseert voor die mooie AMD processor.

Java is een hogere orde taal. Om dan te gaan zitten zoeken naar optimalisaties voor een specifieke processor. Ik moet er niet aan denken. Dan ga ik alsnog wel Fortran leren.

Dat je er buitengewoon slechte code mee zou kunnen ontdekken, dat kan. Maar de vraag is of je daarvoor dit tool nodig hebt.

[kozue]

Wat is dat nou weer voor attitude... Hoezo zou de JVM voor goede performance moeten zorgen? Dat wordt hoofdzakelijk bepaald door je eigen code. Als jij een of ander raar loopje hebt wat iedere keer hetzelfde uitrekent en daardoor 10x zo veel cpu gebruikt, kan jouw JVM je daar echt niet bij helpen, die doet alleen wat m opgedragen wordt.

En de vraag is niet of je het nodig hebt, de vraag is of er mensen zijn die er wat aan hebben. En dat antwoord is ongetwijfeld ja, anders hadden ze het niet geschreven. Als iets bestaat en jij vind het zelf niet handig, gebruik het dan niet, maar ga niet lopen roepen dat het nutteloos is, want er is altijd wel iemand die er wat aan heeft.

[.oisyn]

Volgens mij snap je echt compleet de toegevoegde waarde van deze plugin niet. Waar jij het over hebt is gewoon standaard profiling - waar in mijn code wordt het meeste tijd gespendeerd. Daar zijn al zat tools voor, dus daar heb je deze plugin niet voor nodig. Deze tool analyseert dingen als cache misses, pipeline stalles en branch mispredictions. Micro-details waar je met je Java code zo goed als geen invloed op uit kunt oefenen omdat je afhankelijk bent van hoe de VM jouw java(byte)code omzet naar x86 instructies.

Interessant om te weten natuurlijk, maar het zegt meer over de VM dan over jouw code. Kans is groot dat als jij een andere VM (zels een andere versie van dezelfde VM) installeert je ineens hele andere resultaten krijgt. Het idee van java code was write once, run anyware. Op het moment dat je na een update van de VM elke keer je code opnieuw moet gaan profilen en aanpassen loop je een beetje achter de feiten aan. Sowieso, op het moment dat micro optimalisaties belangrijk gaan worden in je project moet je je eens goed achter je oren krabben of je eigenlijk wel het juiste platform voor je project gekozen hebt.

En dáárom zet jwvirtual zijn kanttekeningen bij deze tool (en ik ben het met 'm eens). Daar hoef je het niet mee eens te zijn, maar dan hoef je 'm nog niet meteen monddood te maken door te zeggen dat hij geen kritiek mag uitten alleen omdat hem het praktische nut ervan ontgaat.

[Verwijderd]

Echter, deze applicatie doet dus 'iets' tussen de JVM en de processor. De applicatie kijkt naar wat de JVM naar de processor stuurt, zegmaar.

Maar inderdaad, zoals je zegt, het is ook handig om domme fouten (rare loopjes en meerdere keren hetzelfde doen valt daar ook onder, imho) in je eigen code eruit te filteren.

[Mr_Light]

profile-en van grote apps geeft nog al een grote aanslag op je (cpu) resources wanneer je dit doet middels code instumentation. Als je dit 'goedkoper'/efficiënter kan doen door performance counters uit te lezen van de cpu is het een erg welkome toevoeging.

Overgens vraag ik me af of dit wel AMD specifiek is, ik zie nergens 'requires AMD-processor' staan en volgens mij heeft intel ook performance counters er op zitten. Anders kan support voor intel er wel bij gebouwd worden, het is tenslotte opensource.

[Reactie gewijzigd door Mr_Light op 24 juli 2024 08:55]

[.oisyn]

CodeAnalyst (de basis van deze plugin, en is niet open source) is AMD-only wat betreft de counters. Werkt volgens mij wel op andere CPUs, maar dan ben je gelimiteerd aan code sampling (gewoon steeds kijken waar de program counter is in 1ms intervals oid), en die geven nou niet bepaald een goede indicatie. Intel heeft idd ook performance counters, uit te lezen middels VTune. Die werkt echter alleen op Intel procs. Uiteraard zijn de counters van beide processoren niet compatible

[Reactie gewijzigd door .oisyn op 24 juli 2024 08:55]

[Cameleon73]

In dezelfde lijn ligt deze JDepend plugin voor Eclipse (hoewel dit meer een analyse van abstractie en stabiliteit geeft). De maker van deze plugin (Andrei Loskutov) heeft wel trouwens meer interessante plugins.

[GrooV]

Waarom dit alleen limiteren aan een IDE en taal? Lijkt mij dat hier erg veel vraag naar is, ook in .net/VS en andere JAVA IDE's zoals Netbeans

[.oisyn]

Het nieuws-item gaat over een Eclipse plugin. Het feit dat iets niet genoemd wordt betekent niet dat iets niet bestaat . Zo werkt AMD al jaren aan CodeAnalyst, een vergelijkbare profiler voor native code (CodeAnalyst moet overigens ook geïnstalleerd zijn om deze Eclipse plugin te kunnen gebruiken)

Daar heb je als Java developer natuurlijk weinig aan, want de native code is niet makkelijk herleidbaar naar je Java code. Alleen vraag ik me af hoe zinnig een dergelijke tool is - de VM is het meest verantwoordelijk voor optimalisaties aan jouw code. De enige dingen die je zelf kunt doen in Java zijn meer van algoritmische aard, macro-optimalisaties dus. Je kunt wel micro-optimalisaties toepassen (zoals het cachen van vaak gebruikte gegevens van allerlei plekken in lokale members), maar dan interfereer je weer met de optimalisaties die de VM mogelijk kan doen. Bovendien zijn je metingen met deze tool eigenlijk ook alleen maar van toepassing op de VM die je op dat moment gebruikt. Een andere VM kan weer hele andere resultaten geven. Maar goed, in feite ben je natuurlijk sowieso al processor-specifiek bezig.

[Reactie gewijzigd door .oisyn op 24 juli 2024 08:55]

[Verwijderd]

waarschijnlijk omdat eclipse veel gebruikt wordt en dat er voor andere IDE's en talen nog geen Codesleuth is wil niet zeggen dat ie er niet komt.

[kozue]

Misschien kan hun VS of Netbeans wel helemaal niet schelen? Die vraag die jij nu stelt is dezelfde vraag als "Waarom applicatie X limiteren aan 1 operating system?" als het gaat om windows-only bouwsels. De maker van codesleuth heeft nou eenmaal voor eclipse gekozen, Als jij geen eclipse gebruikt, maar wel zoiets wil hebben, zijn er vast wel anderen die wel iets om .net geven (of weetikveel waar jij in progt) en zoiets hebben gemaakt. En anders kan je het altijd zelf maken.
Maar het punt blijft dat jouw opmerking niks met het nieuwsitem te maken heeft. Vraag me zowiezo af wat je in een topic over een eclipse plugin doet als je het niet eens gebruikt...

[Mitsuko]

Is dit niet gewoon hetzelfde als code profiling in een taal als C++ of Haskell?

[Thrillseekah]

Brengt dit niet een veiligheids risico mee? Virussen die direct de cpu aanspreken en bv 100% load er op gooien?

[voodooless]

Het ding kijkt enkel naar performance counters, en je kunt er dus niet actief iets mee doen.

Bovendien is 100% load genereren niet zo lastig

[YopY]

while(true) {} en je komt al een heel eind.

[freaq]

rekent Pi uit....

[Verwijderd]

Even voor de duidelijkheid, deze applicatie draai je alleen op de machine waar je ook de code hebt staan. Het is geen feature van AMD's processoren dus, maar een manier om te kijken wat de gecompileerde code doet bij de processor (grofweg gesproken, anyway).

[Verwijderd]

Hierbij gaat AMD er vanuit dat de applicatie op dezelfde soort hardware wordt ontwikkeld als dat het in productie draait.
Dit is niet altijd het geval.

[aap]

Testen doe je natuurlijk altijd op je targetplatform (op je testplatform kun je natuurlijk ook Eclipse installeren).

Maar inderdaad, dit lijkt me alleen zinnig als de data die je krijgt representatief is voor alle processoren. Java is immers bedoeld om op ieder platform te kunnen runnen, dus als je gaat optimaliseren voor een bepaalde processor, ben je strijdig met de idee achter Java bezig.

[Verwijderd]

Het lijkt me echter wel dat de JVM op vergelijkbare manier de processor zal aanspreken.

Daarnaast, die optimalisaties kan je dan apart publiceren. Stel, je heb een programma waarvan 90% van de, roep wat leuks, 100.000 gebruikers, op windows zitten (Azureus, anyone?) , dan kan je voor die 90.000 gebruikers best een optimalisatie uitbrengen.

Het heeft wel degelijk voordelen, je kan bijvoorbeeld ook inefficiente code in general opsporen.