News AMD Befehlserweiterung zur Java-Beschleunigung

...riod ... will da jemand einen flame thread auf machen :) - ja ist denn heut schon freitag :)

<- is sich Java-Entwickler :) - sitzt sozusagen an der Quelle :) - Auch wenn enter-preis-anwendungen auch nur formular-ausfüll-seite-mit-auswertung sind - irgendwie ändern sich nur die daten :)

Auch wenn ich zugebe das C++ schneller sein mag, mag ich mein PHP und Java lieber - gute Entwickler sind faul :)
 
Sascha L schrieb:
DIE NEWS IST FALSCH
Hat der News-Autor überhaupt die Quelle gelesen?
Es wurde weitestgehend richtig formuliert:
News schrieb:

Außerdem steht noch in der News, dass das Betriebssystem mitspielen muss, somit dürfte die Funktionsweise der angedachten Befehle verständlich sein, zumindest den Leuten, die es interessiert.
 
Zuletzt bearbeitet:
@riod
Selbstverständlich basieren Enterprise Anwendungen auf Java bzw. in kleinerem Ausmaße auf .Net. Java ist in diesem Bereich absolut marktführend.
 
Die alten Vorurteile werden aber auch immer wieder aufgewärmt hier :rolleyes:

Java an sich war noch nie wirklich langsam, nur die grafische Ausgabe mit SWT und Swing hatte gewisse Probleme, aber da hat sich viel getan in letzter Zeit.
Und dass erst die JRE starten muss bevor das Prog zum ersten mal läuft, kann man Java nun wirklich nicht ankreiden.

Desweiteren hat die JRE Vor- und Nachteile, konzeptional bedingt.

Nartürlich ist nen Java-Programm in einer Laufzeitumgebung nicht so performant wie ein C-Programm das direkt auf dem OS läuft.

Dafür ist es aber größtenteils plattform-unabhängig und bietet schier unendlich viele vorgefertigte Klassen. Damit kann man in kürzester Zeit respektable Ergebnisse vorweisen.

Ich persönlich möchte Java jedenfalls nicht mehr missen.
Imho bekomm ich da nämlich für ein paar kleine Nachteile ein Riesenhaufen Vorteile geboten ;)


Daher find ich auch alles gut, was hilft, Java zu verbessern. :freaky:


Gruß, Bam
 
du hast fast so ein Smiley drang wie ich :) :) :) und aus meiner Sicht recht. (im Vergleich zu C++).
Aber um einen Flame-Thread Java vs .NET zu vermeiden, ja beide sind gut, ja beiden haben Vor und Nachteile :)

... ich sollte mir wieder abgewöhnen Smilies als Satzzeichen zu verwenden.
 
Zuletzt bearbeitet von einem Moderator: (Beiträge zusammengeführt. Bitte Regeln beachten.)
Naja, die Erweiterung als "Java-Beschleuniger" hinzustellen finde doch etwas hergeholt, oder hab ich da was übersehen?

Man kann damit zuverlässig ermitteln wo die performancekritischen "hot spots" liegen(egal ob Java/C++ oder Assembler), jedoch muss immer noch der Programmierer selbst den optimierten Code schreiben.

Was damit gut geht:
Man kann mehrere Versionen einer Funktion programmieren, alle auf dem Anwendersystem benchmarken und die schnellste davon dann verwenden. Aber erst mal muss man sich die Arbeit machen, und die verschiedenen Versionen schreiben... (ok bei der Java/.net-Runtime macht man sich vielleicht teilweise die Arbeit).
 
Sehr schön, da geht AMD in die richtige Richtung. Wenn man bedenkt, dass heute noch nicht einmal die hälfte aller aktuellen Software einen Dualcore vernünftig nutzen kann. Mit Java und .net hat man sich auch zwei Entwicklungszweige herausgesucht, bei denen das Sinn macht. Es laufen so viele Proggis mit Java bzw. .net, dass eine effizientere Nutzung der CPU eine gute Sache ist.

Weiter so AMD.

greetz
 
Das ist doch mal eine interessante Nachricht. Ich hoffe nur, daß das auch alles so funktioniert. :)
 
@CB

diese News beschreibt LWP in keinster Weise und stellt den Verhalt der massen Falsch da, das dieser schnellst Moeglich korregiert werden sollte, oder besser geloescht wird.

AMD wuerde gerne die Moeglichkeit fuer ein besseres Profiling schaffen damit Programmierer Flaschenhaelse in ihrem Code aufspueren koennen und Messungen sowie Statistiken erhalten und das besonders im Hinblick wenn Multithreading gefragt ist. Damit Multicore Chips besser ausgelastet werden und Anwendungen auf heute 2nd Level Cache groessen optimiert werden.

Damit Programmierer nicht verschiedene Tools fuer div. CPUs brauchen soll natuerlich angestrebt werden das die Erweiterungen in der Mehrzahl der x86 CPUs zur Verfuegung steht. Das wird dann auch fuer den OS Hersteller einfacher zu implementieren.

Wer mal mit Profiling Werkzeugen wie SpeedShop und Co. hantiert hat weis was ich meine. Indirekt profiert jede Anwendung davon sofern die Programmierer ihre Hausaufgaben gemacht haben.

Mit JAVA hat das Oberflaechlich nichts am Hut was man schon daran erkennt das dieses Wort in der Beschreibung nicht einmal erwaehnt wird.

Gruss
Joerg
 
AMD Releases Specification Designed to Enable Real-Time Performance Optimization for Software Applications

LWP is designed to enable code to make dynamic and real-time decisions about how best to improve the performance of concurrently running tasks, using techniques such as memory organization and code layout, with very little overhead. These capabilities are particularly beneficial to runtime environments like Java and .NET, which can run multiple threads and are used to develop an increasingly large percentage of applications.

With more developers turning to managed code and the number of individual concurrent interactions growing over time, LWP is designed to help optimize multithreaded applications running on multi-core systems by reducing bottlenecks, increasing performance and enabling dynamic adaptation to changes in application behavior.


Und aus der Spec selbst:

1 Introduction
The lightweight profiling (LWP) proposal extends the AMD64 architecture (in both legacy and long mode) to allow user mode (CPL=3) processes to gather performance data about themselves with very low overhead. The goal is to enable modules such as dynamic optimizers and managed runtime environments to monitor the currently running program with high accuracy and resolution, thereby allowing them to report on performance problems and opportunities and fix them immediately.
 
Zuletzt bearbeitet:
Das verlinkte Proposal nennt keine Programmiersprachen weil es indirekt jede beinflusst. Wenn SUN sein JRE optimiert ist doch davon auszugehen das die Applikationen beeinflusst werden und diese evt. schneller laufen. Evt. koennte man ja noch auf die Presseerklaerung vom AMD verlinken damit man zu Nachlesen kann was da sonst noch so berichtet wurde bzw. was das Marketing noch so von sichgegeben hat :)

Imho ist die Aussage zum JRE und .Net gleichbedeutend mit der Tatsache das wenn Nvidia oder AMD ihre GFX Treiber optimieren viele Spiele mehr FP/s haben ohne das der Hersteller des Spiels eine Zeile Code geandert haette.

Anderseits ist es doch gut zuwissen das viele davon Profitieren koennten.... ohne was zu machen sofern Intel dem Wege von AMD anschliesst.

Gruss
Joerg
 
@_Grisu
Wie wäre es denn mal mit einer hardwareseitigen Windowsbeschleunigung, da hätten alle Applikationen was davon.
Schonmal was von Vista gehört ?
 
origin schrieb:
Das verlinkte Proposal nennt keine Programmiersprachen weil es indirekt jede beinflusst.
Es werden Programmiersprachen genannt. Alles was in einer Laufzeitumgebung läuft, ist primäres Ziel.
Man braucht ein BS, das mit den Befehlen umgehen kann sowie eine entsprechend angepasste Laufzeitumgebung auf der einen Seite und auf der anderen Seite die Implementierung in die Hardware sowie natürlich Multicore-Ressourcen.

Die News ist richtig, die Überschrift ist recht unglücklich gewählt. Das habe ich bereits in meinem ersten Posting erwähnt. Passender als "zur Java-Beschleunigung" wäre z. B. "soll Beschleunigung durch Multithreading erreichen".
 
Ich denke was origin und Winterday sagen wollen ist, dass AMD keine Beschleunigung für Java und .net im eigentlichen Sinn vornehmen möchte, das tut AMD nur indirekt, weil Java und .net Multithreading sehr effizient nutzen können und dies heute auch schon tun.

AMD möchte Entwicklern (im Zuge von Multicore-Prozessoren) mit seiner Befehlserweiterung ein Werkzeug an die Hand geben, um Umgebungen und Programme effizienter auf Multicore-CPUs auszurichten und deren Leistungsfähigkeit durch stärkeres Multithreading performanter nutzen zu können.

Wie mein Vorredner (MacroWelle) schon kommentiert hat, die Überschrift ist ünglücklich gewählt.

so long..
 
Also, mein Senf hierzu. LWP dient, wie der Name schon sagt, dem Profiling. Die CPU erhält ein paar Statusregister (Register sind kleine schnelle Speicher ;) ) mehr. In diesen Registern speichert ein Prozess bestimmt Daten, wie z.B.:
-Cache-Hit/Miss Rate etc.
-Wann der Prozess ausgelagert wurde etc.
-Wann und Wo (auf welchem Kern) der Prozess läuft etc.
Die Register müssen bei einem Kontextwechsel gespeichert bleiben, deswegen muss das BS mitspielen.
Aus den o.g. Daten kann der Prozess bestimmt Rückschlüsse ziehen, z.B., wenn die Cache-Hit Rate zu niedrig ist, dass er bestimmt Sachen öfters wiederholt um im Cache zu bleiben.
Oder aber, wenn der Prozess merkt, dass er immer kurz vor dem "aufwachen" ausgelagert, so kann er dem BS mitteilen, dass er mal bitte nicht mehr ausgelager wird.
Oder aber, wenn ein Prozess abwechseln auf den Kernen ausgeführt wird und deshalb immer warten muss, bis die Daten aus dem Cache des anderen Kerns zur Verfügung stehen, so kann er dem BS mitteilen, dass der Scheduler doch bitte den Prozess auf einem Kern lassen soll. Beim k10 erfolgt der Austausch der Cache-Lines über den L3-Cache, das dauert natürlich etwas. Beim C2Q geht das über den FSB, dass dauert natürlich noch länger, also wenn Kerne der 2 Dies beteiligt sind, ansonsten natürlich auch über den gemeinsamen L2-Cache.
Also, wie man sieht muss das BS beteiligt sein, die Programme etc. und die Beschleunigung erfolgt nur indirekt.
Zur direkten JAVA-Beschleunigung gab (gibt?) es mal einen Prozessor der Java-Byte-Code nativ ausführen konnte (kann?), so etwas ähnliches wird AMD dann als Extra-Kern (zum Fusion-Ding hinzu) einpflanzen, etc. etc. Es gibts noch so viele Möglichkeiten....
Hoffe ich konnte beim Verständnis helfen

MfG
 
Also wenn man Java schon als "größtenteils" plattformunabhängig bezeichnet, kann man die gleiche Eigenschaft auch auf C++ übertragen. Sicher, vom Kompilat will ich jetzt mal gar nicht sprechen. Und dann sieht Java alt aus...

Außerdem sind Java-Kompilate auch nur quasi-plattformunabhängig, denn die JRE ist sehr wohl plattformabhängig.


Aber gut, ich bleib bei meinem geliebten C++, wenn ich meine, der Speicher gehört nicht freigegeben, dann gehört der auch nicht freigegeben :)
 
Ist echt traurig was hier teilweise verzapft wird... Java und .net sind genau deshalb so beliebt, weil man sich bei einer VM (fast) keine Gedanken um irgendwas beim Programmieren mehr machen muss, sondern sich auf die Entwicklung der Software konzentrieren kann und auf ein gewaltiges Bibliotheksarsenal zurückgreifen kann. Kurzum: die Softwareentwicklung mit Java und .net ist deutlich billiger und geht deutlich schneller von statten als mit C++. Zudem wird das Testen sehr viel unkomplizierter. C++ ist überhaupt nicht zur Entwicklung von Standardsoftware gedacht, sondern für OS nahe Entwicklung. Leider hält sich C++ immernoch als Standard (vor allem aufgrund der ganzen Firmeneigenen Bibliotheken, die sich mit den Jahren ansammeln), aber das wird sich auf lange Sicht gesehen deutlich ändern, eben wegen des Kostenaufwandes. In Zukunft werden die VMs bei normaler Software eine gewaltige Rolle spielen. Viele professionellen Client-Server Programme wie z.B. HiPath oder andere Geschichten laufen schon längst auf Java Basis, weil man mit Java den saubersten und einfachsten Netzwerkcode mit sehr wenig Aufwand hinbekommt. Auch die Serveranteile von vielen MMORPGs laufen auf Java Basis (z.B. SW Galaxies oder EQ2). Viele IT Firmen fordern schon jetzt JBoss+JSP Kenntnisse und den Umgang mit .net und/oder Java zu beherrschen. In der IT Landschaft ist Java ganz gross im kommen, schon seit Jahren und .net ist nunmal der neue Standard für Standardsoftware, Vista sieht das auch explizit so vor. Auch in Windows Vista selber läuft jetzt schon viel über .net.
Das was hier grösstenteils über Java bzw. .net verzapft wurde sind grösstenteils Unkenntnis und Vorurteile...
Auch der Mist mit der angeblichen Langsamkeit wird immer wieder gerne verbreitet. Java rechnet nicht langsamer als C++. Jedoch benötigen Java Programme, je nach grösse etwas mehr RAM, haben dafür aber keine Probleme mit der 32bit Grenze.
 
Zuletzt bearbeitet:
Zurück
Oben