PicoJava-Prozessoren?

[Kadaj]

Hey Leute,

ich hab in einem Javabuch ganz am Anfang gelesen, dass es sogenannte PicoJava-Prozessoren gibt, die den Bytecode direkt ausführen, wodurch Java-Software erheblich schneller wird. Zwischen 20 und 50 mal so schnell hab ich auf verschiedenen Seiten gelesen. Weiß jemand mehr darüber? Sun scheint diese bereits zu verwenden, allerdings finde ich nur wenig Informationen darüber ob diese auch für den "normaler Informatiker" zugänglich sein werden bzw wann überhaupt was geplant ist.

Gruß

[flashpixx]

siehe picoJava - Wikipedia, the free encyclopedia

Du brauchst letztendlich ein Developerboard und entsprechendes Wissen über die Ansteuerung von CPUs d.h. entsprechendes Wissen über Elektrotechnik

[Kadaj]

Ok, ich hätte gedacht, dass geplant ist die PicoJava irgendwann standartmäßig in alle Rechner einzubauen, damit diese dann automatisch alle Java-Anwendungen ausführen. Das würde Anwendungen, die in C++ geschrieben sind, ganz schön alt aussehen lassen, aber damit ist wohl nicht zu rechnen. Schade eigentlich...

[flashpixx]

Das würde Anwendungen, die in C++ geschrieben sind, ganz schön alt aussehen lassen, aber damit ist wohl nicht zu rechnen. Schade eigentlich...

Ich ziehe C++ Java vor, sowohl aus Performance als auch der Möglichkeiten die C++ bietet. Z.B. Numerische Algorithmen sind mit Java nicht möglich bzw. man braucht auch externe Komponenten. Java setzt letztendlich Bibliotheken ein, die via JNI angesteuert werden, was dann letztendlich C/C++ ist.

Außerdem möchte ich sicher keinen nativen Javacode in meinem CPU laufen haben, alleine aus Sicherheitsaspekten.

[Kadaj]

Außerdem möchte ich sicher keinen nativen Javacode in meinem CPU laufen haben, alleine aus Sicherheitsaspekten.

Was meinst du damit?

[flashpixx]

Die Frage ist, was bringt die native Codeausführung im CPU. Letztendlich muss ja auf CPU Ebene ein passender Interpreter vorhanden sein, d.h. dieser Interpreter hat zum Herstellungszeitpunkten einen Stand und wenn eben Sicherheitslücken enthalten sind, dann kann ich diese nicht patchen (wie z.B. Vulkanausbruch auf Java | heise Security ).

Weiterhin ist das Problem, dass es für Java keine nativen numerischen Bibliotheken gibt, letztendlich werden C/C++ Aufrufe via JNI mit Hilfe eines Javawrapper gekapselt. Solche Bibliotheken braucht man durchaus z.B. bei Anwendungen im Ingenieurbereich / naturwissenschaftlichen Bereich. Selbst Android nutzt JNI um eben die Hardware anzusteuern. Somit ist die Frage, wo ein solcher Prozessor Sinn machen würde. Ich sehe nicht den Sinn in einem CPU der mir meinen Java Bytecode nativ ausführen kann, denn wenn ich Performance oder Hardwaresteuerung benötige, dann nutze ich C/C++ und rufe dann die spezifische DLL via JNI aus Java aus. Dabei ist der Vorteil, dass nur die DLL systemspezifisch sein muss, der Javacode bleibt somit gleich. Wenn Du für eine Javaanwendung einen eigenen CPU benötigst, dann würde ich als Anwender eher auf eine solche Anwendung verzichten, denn warum soll ich für eine spezielle Software eine eigenen Architektur kaufen und warten, nur um eine spezielle Software laufen lassen zu können.

Bearbeitet 19. November 2012 von flashpixx

[Kadaj]

Ok, nun hast du mich so heftig mit Dingen überschüttet, die ich noch nicht einmal verstehe, dass ich nur sagen kann: "Verdammt, du hast ja Recht" ^^

Ich hätte den PicoJava aber nicht unbedingt als eine Architektur angesehen, sonder viel mehr als eine Komponente. Die Leute kaufen sich ja Grafikkarten auch nur der besseren Performance wegen, obwohl sie schon eine auf ihrem board haben. ;-)

[flashpixx]

Schau mal in dem Wikiartikel nach:

picoJava-based microprocessors can also execute C/C++ code as efficiently as comparable RISC CPU architectures

Wenn der CPU Java Bytecode just-in-time laufen lassen kann und zusätzlich C/C++ Code interpretieren kann, wofür brauche ich ihn dann? Denn alles was ich in Java machen kann, kann ich auch mit C++ machen. Wenn ich dann doch noch eine hübsche Javaklasse haben will, naja dann nehme ich eben meine C++ Klasse, verpacke sie in eine DLL und greife von Java via Java Native Interface drauf zu. Die Latenz, die dabei entsteht, ist lediglich die Datenumwandlung und das ist nativer C Code.

Wenn ich das jetzt so sehen würde, dass man diesen CPU zusätzlich zu einem bestehenden CPU setzt und eben "nativ Javacode ausführen will", siehe

The picoJava specification does not include any memory or I/O interface logic, so that developers can add their own logic to customize memory and an interface. [...] The open-source version of picoJava has been implemented in an FPGA.

dann wäre dort für mich der Ansatz direkt eben den FPGA zu programmieren. D.h. wenn ich eben eine besondere Architektur wie einen FPGA brauche, dann nehme ich direkt einen passenden CPU und programmiere diesen eben genauso wie ich ihn brauche.

In beiden Fällen sehe ich nicht die Notwendigkeit eines eigenen Java CPUs, denn warum diese spezielle Hardware verwenden, wenn ich es eben mit einem direkten Ansatz genauso machen kann. Ein weiterer Aspekt ist für mich das Design: Als Beispiel eine einfache Eigenwertzerlegung. Wenn ich es pure in Java machen will, dann muss ich mir erst mal eine Datenstruktur für eine Matrix überlegen und dann eine QR / QZ Zerlegung programmieren damit ich dann diesen Javacode nativ auf einem eigenen CPU ausführen kann. Mache ich es in C++ lade ich mir die Boost runter, installiere mir die LAPack und die Numeric Bindings, schiebe meine Daten in die Boost UBlas Matrix rein und lasse mir die Eigenwerte durch die LAPack berechnen. Diese Bibliotheken sind extrem performant und schon sehr detailliert getestet. Brauche ich das in Java, dann muss ich nur einen JNI Wrapper drum herum bauen und habe meine Javaklasse (den Wrapper kann man sogar automatisch via Swig bauen lassen). Also für mich keine Anwendung eines eigenen CPUs.

Weiterhin ist die Frage, was hat der Java CPU real implementiert, d.h. inwieweit ist der Befehlssatz kompatibel z.B. zu einem aktuellen JDK, sprich werden alle aktuellen JDK Befehle unterstützt oder nur Teile. Wie sieht es aus, wenn Fehler in der Sprachimplementierung existieren, also kann man den CPU flashen oder ist der Befehlssatz unveränderbar. Damit ergeben sich dann auch ggf. Bedingungen, die man beachten muss.

Java ist durchaus ein sinnvolles System und sicherlich auch nicht unperformant. Es kommt halt eben auf die Anwendung an. Wenn man wirklich hohe Performance für einen Algorithmus braucht, dann wäre die erste Frage "ist Java überhaupt die geeignete Sprache um das Problem sinnvoll zu lösen". Es gibt Fälle (wie z.B. numerische Algorithmen), die man eben nicht in Java implementieren würde, weil es eben umständlich und nicht performant geht, d.h. ich nehme eine andere Sprache und verbinde eben diese mit Java.

Nur weil man evtl 1/2 Sekunde darauf warten muss, bis ein Programm startet, rechtfertigt dies nicht den Einsatz einer speziellen Hardware. Gerade im Bereich der Algorithmen ist extrem viel Potential für Performance möglich, nur dort liegt auch das Problem, man nimmt oft einen naiven Ansatz und dadurch ist eben dann auch der Algorithmus ineffizient, zusätzlich kommt dann häufig noch eine ineffiziente Implementierung. Oft reicht es aus, einen anderen Algorithmus zu verwenden, um das Problem effizienter zu lösen. Der Ansatz "neue / bessere Hardware löst das Problem schneller" ist auf ein Trugschluss. Ein schlechter Algorithmus kann auch auf einer besseren Hardware keine besseren Ergebnisse liefern und dann für einen schlecht entworfenen Algorithmus noch eigene Hardware zu verwenden, ist für mich wirtschaftlich nicht zu rechtfertigen

Bearbeitet 19. November 2012 von flashpixx

[Gast runtimeterror]

Ich sehe das etwas anders. Die vielzitierten Sicherheitslücken beschränken sich nahezu ausschließlich auf die Java-Applets und das damit verbundene Rechtesystem. Des Weiteren ist es unwahrscheinlich, dass das vollständige JRE in der CPU implementiert wird. Die sog. Java-Prozessoren die ich kenne implementieren lediglich einen Bytecode-Interpreter, was aus Sicht der Mikroarchitektur nichts anderes ist, als eine Art Stack-basierte Assembler-Sprache.

Da Java in einigen Problemdomänen bereits heute performancetechnisch mit C konkurrieren kann, halte ich die angesprochene Beschleunigung um den Faktor 20-50 für maßlos übertrieben (C ist schon dicht am Limit). Das mag noch aus einer Zeit stammen, in der Java ausschließlich interpretiert wurde.

Java hat seine Wurzeln tatsächlich im Embedded-Bereich (u.a. Smart-Cards), konnte dort aber nie Fuß fassen. Java versagt bei direktem Hardware-Zugriff genauso wie C bei der Wartbarkeit. Jede Sprache hat halt ihre eigenen Stärken und Schwächen.

[flashpixx]

Die sog. Java-Prozessoren die ich kenne implementieren lediglich einen Bytecode-Interpreter, was aus Sicht der Mikroarchitektur nichts anderes ist, als eine Art Stack-basierte Assembler-Sprache.

Naja jeder CPU macht letztendlich nichts anderes, nur dass bei einem nativen Code eben die Assembleraufrufe durch den Compiler erzeugt werden, bei dem Java CPU wird eben ein "Metacode" dann auf Hardware in den realen Assemblercode übersetzt, was letztendlich eine Art "just-in-time" Umsetzung ist.

Die Frage ist aber immer, was kennt der CPU an Befehlen, sprich muss man evtl beachten, ob der mit javac erzeugte Bytecode direkt kompatibel zum CPU ist oder nicht. Weiterhin besteht ja Java nicht nur aus Code, der interpretiert wird, man hat ja eben noch diverse andere Strukturen drum herum, die ja auch irgendwie in den CPU gelangen müssen.

Java versagt bei direktem Hardware-Zugriff genauso wie C bei der Wartbarkeit.

Das stimmt, darum kapselt man ja dann eine C/C++ Interface, das man auf die Architektur compiliert via JNI mit Java. Android macht es ja genau so.

Das was dann spezifisch für die Hardware ist, wird in C/C++ entwickelt und compiliert und über Java kann man dann das Interface abstrahieren. Bei anderer Hardware muss man lediglich die C/C++ Basis anpassen.

Jede Sprache hat halt ihre eigenen Stärken und Schwächen.

Das ist richtig. Die Frage ist nur, würde irgendetwas den Einsatz eines solchen CPUs rechtfertigen. Meines Erachtens nicht, denn sowohl Java wie auch C/C++ sind bei richtiger Anwendung durchaus auf einem handelsüblichen CPU extrem performant. Performanceprobleme sind meist nicht auf der CPUbasis vorhanden, sondern liegen oft an anderer Stelle.

Bearbeitet 19. November 2012 von flashpixx

[Gast runtimeterror]

Der letzte Absatz gefällt mir besonders!

Man kommt mit Java schon extrem weit, auch bei performancekritischen Sachen. Aber in dem Moment wo mit komplexeren mathematischen Gebilden gearbeitet wird (komplexe Zahlen, Tensoren), wird die Sprache schlichtweg unhandlich.

Ob ich jetzt Boost oder eine für Numerik konzipierte Java-Bibliothek samt darauf spezialisierten Compiler einsetze (spart den Umweg über JNI) ist ja eigentlich egal. Schön wäre in meinen Augen eigentlich eine Sprache, die von sich aus komplexe Zahlen, Vektoren, Mengen, Intervalle, etc. unterstützt, so dass man ohne Krückenbibliotheken auskäme.

Aber ich schweife ab

[Gast runtimeterror]

Das ist richtig. Die Frage ist nur, würde irgendetwas den Einsatz eines solchen CPUs rechtfertigen. Meines Erachtens nicht, denn sowohl Java wie auch C/C++ sind bei richtiger Anwendung durchaus auf einem handelsüblichen CPU extrem performant. Performanceprobleme sind meist nicht auf der CPUbasis vorhanden, sondern liegen oft an anderer Stelle.

Ack! Hauptursache sind (aus meiner Erfahrung heraus) Wahl des falschen Algorithmus und nicht ausreichende Ausnutzung der verfügbaren Hardware-Funktionen. Letzteres kann durch einen JIT-Compiler verbessert werden, sofern die zu Grunde liegende Sprache ausreichend abstrakt und mächtig ist (Java ist dies definitiv nicht). Ersteres wird sich wohl nie bessern

[dr.dimitri]

Das ist richtig. Die Frage ist nur, würde irgendetwas den Einsatz eines solchen CPUs rechtfertigen. Meines Erachtens nicht, denn sowohl Java wie auch C/C++ sind bei richtiger Anwendung durchaus auf einem handelsüblichen CPU extrem performant. Performanceprobleme sind meist nicht auf der CPUbasis vorhanden, sondern liegen oft an anderer Stelle.

Davon ausgehend, dass handelsübliche PCs immer mehr von Tablets etc. verdrängt werden, ist nicht mehr die theoretisch verfügbare Rechenleistung das Limit, sondern andere Kriterien wie Akku, Abwärme, Größe und Gewicht.

Eine CPU, die speziell dafür ausgerichtet ist eine spezielle Sprache zu unterstützen, hat da natürlich Vorteile gegenüber eine konventionellen Hardware. Alleine der Overhead für die JVM wäre im Java Bereich schon eine erhebliche Einsparung.

Haben nicht z.B. BluRay Player einen speziellen Chip, in dem die JVM hartverdrahtet ist?

Dim

[flashpixx]

Eine CPU, die speziell dafür ausgerichtet ist eine spezielle Sprache zu unterstützen, hat da natürlich Vorteile gegenüber eine konventionellen Hardware. Alleine der Overhead für die JVM wäre im Java Bereich schon eine erhebliche Einsparung.

Ack, nur wenn ich da letztendlich optimieren möchte, dann würde ich eben direkt passenden Maschinencode erzeugen, also sprich C/C++ nehmen und passend für meine Architektur compilieren. Warum soll ich dann einen "Umweg" über Java machen, wenn ich eben "perfekten Code für meine Architektur brauche" !?

Ich denke das Argument in Java kann man besser cross-plattform arbeiten, ist denke ich nicht richtig, denn ich kann auch cross-plattform in C++ arbeiten. Ich muss eben mir nur vorher Gedanken darum machen und dann meinen Code passend organisieren.

Im Embedded Bereich sind natürlich wirklich viele Algorithmen durch die limitierende Hardware bestimmt, aber wenn ich da dann wirklich Performance o.ä. benötige, dann wäre ein auf die Maschine angepasster nativer Code wohl die beste Wahl. Abstraktion ist zwar manchmal sinnvoll, aber kann eben auch zu Problemen führen

[dr.dimitri]

Warum soll ich dann einen "Umweg" über Java machen, wenn ich eben "perfekten Code für meine Architektur brauche" !?

Für eine echte Java-CPU ist Bytecode der native Code. Oder hab ich das falsch verstanden?

Ich muss eben mir nur vorher Gedanken darum machen und dann meinen Code passend organisieren.

Ja, aber deutlich mehr. 16 Bit, 32 Bit, 64 Bit? Ggf. Endianness, einbinden von Libs (DDL, .so ...), ich brauche für jedes System eine komplette Buildumgebung und wehe ich benutze OS spezifische Erweiterung (z.B. Windows Threads vs. Unix Prozesse).

Wir haben hier RedHat 64Bit in den Versionen 4 und 6, WinXP 32Bit und Win7 64 Bit, auf dem unsere Anwendung läuft. Da bin ich ganz froh drum, dass ich keine Compilerdirektiven mehr sehen muss

Ideal wäre natürlich eine CPU mit dedizierte Java Cores, die für den Bytecode zuständig sind und somit sowohl als auch kann.

Dim

[flashpixx]

Für eine echte Java-CPU ist Bytecode der native Code. Oder hab ich das falsch verstanden?

Nein, so habe ich das auch verstanden. Die Frage wäre halt, warum soll ich "Spezialhardware" kaufen, wenn ich durch ein entsprechendes Konzept in der Entwicklung diese nicht brauche

Ja, aber deutlich mehr. 16 Bit, 32 Bit, 64 Bit? Ggf. Endianness, einbinden von Libs (DDL, .so ...), ich brauche für jedes System eine komplette Buildumgebung und wehe ich benutze OS spezifische Erweiterung (z.B. Windows Threads vs. Unix Prozesse).

Naja eigentlich nur den Cross-Compiler mit entsprechend compilierten Libs.

Wir haben hier RedHat 64Bit in den Versionen 4 und 6, WinXP 32Bit und Win7 64 Bit, auf dem unsere Anwendung läuft. Da bin ich ganz froh drum, dass ich keine Compilerdirektiven mehr sehen muss

Es stimmt schon, dass man gerade bei cross-platformen Dingen mit Java weniger Arbeit hat, aber ich erkaufe mir dieses weniger eben durch die JRE bzw eben dann durch spezielle Hardware.

Ideal wäre natürlich eine CPU mit dedizierte Java Cores, die für den Bytecode zuständig sind und somit sowohl als auch kann.

Das müsste ich dann aber für PHP, Python auch machen, d.h. ich habe nachher für jede Sprache einen eigenen CPU. Finde ich jetzt eine gruselige Vorstellung. Ich meine eine Abstraktion in der Sprache ist letztendlich immer mit einer zusätzlichen Schicht und damit durchaus mit Performanceeinbußen verbunden. Natürlich gewinne ich, dass ich mich nicht um die plattformspezifischen Details kümmern muss.

Aber ich sehe da eigentlich kein Problem, denn z.B. bei C++ kann ich cross-plattform arbeiten, denn C++ ist ja erst einmal an sich auf jeder Plattform lauffähig sofern ich einen passenden Compiler habe. Z.B. ermöglicht mir die Boost die gewünschte Abstraktionsschicht z.B. bei Netzwerkzugriffen oder beim Threadding, aber sie wird nativ für die Plattform übersetzt (für GUI wäre dann z.B. Qt eine Möglichkeit).

Ich meine, wenn ich in Java irgendwelche Komponenten benötige dann nehme ich eine weitere Jar und lege sie in den Classpath und greife eben auf die Klassen zu. Auf der Bytecodesicht ist das doch nichts anderes als dass eben die JRE eine "Bibliothek laden" muss. Für mich erschließt sich nicht der Sinn, warum man eine spezielle Hardware für eine spezielle Sprache haben sollte, ich kann doch mit der aktuellen Hardware alles was ich benötige abbilden und z.B. C++ ist zur Compilezeit Turing-complete.

Spezielle Hardware ist doch nur sinnvoll, wenn es die Problemstellung erfordert.

[dr.dimitri]

Spezielle Hardware ist doch nur sinnvoll, wenn es die Problemstellung erfordert.

Z.B. eine Oracle Datenbank, die Java Stored Procedures verwendet. Ist ja durchaus verbreitet. Den PL/SQL Code kann ich bei Bedarf bereits jetzt nativ kompilieren, für Java bin ich noch auf die integrierte JVM angewiesen.

Dim

[flashpixx]

Z.B. eine Oracle Datenbank, die Java Stored Procedures verwendet. Ist ja durchaus verbreitet. Den PL/SQL Code kann ich bei Bedarf bereits jetzt nativ kompilieren, für Java bin ich noch auf die integrierte JVM angewiesen.

Kenne ich von Postgres, da kann ich Python verwenden, aber letztendlich wird auf den installierten Interpreter gesetzt. Aber wenn ich zu dem Schluss komme, dass z.B. eine SP schlecht läuft, wäre die Frage liegt es evtl am Algorithmus, dann wäre es ja eher Ziel den Algorithmus zu ändern. Wenn es nicht am Algorithmus liegt, wäre mein Ansatz es nach C/C++ zu portieren und sich direkt an die API der Datenbank zu hängen. Damit ist man dann auf nativer Ebene. Und falls man doch bei Java bleiben will wäre eine Mischlösung JNI.

Ich sehe nicht wirklich ein Argument für so einen CPU, denn letztendlich würde man ja sagen "du kannst die SP in Java schreiben", wenn ich dann Performance will, dann nutze ich eben eine andere Lösung und z.B. keine reine Javalösung.

[Gast runtimeterror]

Die Probleme, die du beschreibst sind aber Einschränkungen der Programmiersprachen - nicht der CPU und nicht des Kompilats. Java ist plattformunabhängig designt und hat daher von Haus aus weniger Probleme mit der Plattformabhängigkeit. Um mal ein paar Gegenbeispiele zu nennen:

Java:

Welche ByteOrder (Endianess) hat ein ByteBuffer?

Welcher Zeichensatz wird bei String.getBytes() verwendet?

C99:

int8_t, int16_t, int32_t, uint8_t, uint16_t, uint32_t, int64_t, uint64_t definieren plattformunabhängige Zahlenbereiche.

Java-Bytecode ist nicht besser oder schlechter als jede andere Assembler-Sprache. Man könnte theoretisch ein Java-Programm in x86-Maschinencode übersetzen oder ein C-Programm in Java Bytecode.

Eine CPU sollte so konzipiert sein, dass sie ihre Arbeit ressourcenschonend verrichtet. Wenn der Java Bytecode dafür geeignet ist - gerne. Dass der Übersetzungsaufwand zwischen der Programmiersprache und der von der CPU interpretierten Maschinensprache möglichst gering ist, halte ich für das weniger wichtige Ziel.