Jar zu Maschinencode

[FabianLurz]

Hallo Leute,
1.
ich wollte einfach mal fragen, ob schon mal jemand Bytecode zu Maschinencode gewandelt hat, sodass man keine VM mehr benötigt? Falls ja, hat das eine Leistungssteigerung gebracht? Die Ergebnisse, die mir google geliefert hat, haben mich nicht zufrieden gestellt deswegen hier der Post
2.
Ich habe vorhin mal etwas mit dem gcj experimentiert bekomme aber immer einen Error:

ICDS_maincore_engine.java:3: error: The import main.java.db cannot be resolved
        import main.java.db.read.FilmReader;
               ^^^^^^^^^^^^
ICDS_maincore_engine.java:4: error: The import main.java.db cannot be resolved
        import main.java.db.read.UserFilmRead;
               ^^^^^^^^^^^^
ICDS_maincore_engine.java:12: error: FilmReader cannot be resolved to a type
        FilmReader film = new FilmReader();
        ^^^^^^^^^^
ICDS_maincore_engine.java:12: error: FilmReader cannot be resolved to a type
        FilmReader film = new FilmReader();
                              ^^^^^^^^^^
ICDS_maincore_engine.java:14: error: UserFilmRead cannot be resolved to a type
        UserFilmRead user = new UserFilmRead();
        ^^^^^^^^^^^^
ICDS_maincore_engine.java:14: error: UserFilmRead cannot be resolved to a type
        UserFilmRead user = new UserFilmRead();
                                ^^^^^^^^^^^^
6 problems (6 errors)

Hat einer eine Idee, an was das liegen könnte? Klar hab ich dazu auch schon gegoogled aber wieder nichts passendes gefunden..
Gruß Fabian

 

[Guybrush Threepwood]

Wenn Du Maschinencode willst, dann ist Java keine gute Wahl. Nimm dann lieber eine andere Programmiersprache.
Java kann sehr performant sein, durch den JIT ggf. sogar performanter als C++, wobei das immer vom Anwendungsszenario abhängt und normalerweise in Foren zu Flamewars führt. Entscheidender ist im Grunde, wie gut Du programmierst.

Mein Tipp zur Übersetzung von Java in Maschinencode: Lass es. Es führt zu nichts.

 

[FabianLurz]

Danke für den Tipp Dachte mir auch schon, dass es nicht sonderlich sinnvoll sein wird; wollte eben alle Möglichkeiten ausloten, um die Performance weiterhin zu steigern. Da ich aber nicht sonderlich erfahren bin mit C/C++ und es ein recht komplexes Programm ist, war Java die erste Wahl für mich (weil ich es einfach besser beherrsche).
Gruß Fab

 

[Tomate_Salat]

Performance weiterhin zu steigern

Eben weil Java zur Laufzeit optimiert werden kann, wird deine Performance wohl eher schlechter. Zudem kann es beim "umwandeln" zu Fehlern kommen.

Da kannst du imho nur verlieren. Wenn du mal native Elemente brauchst, dann nimm JNI oder JNA.

 

[tfa]

... und wenn du keine Performance-Probleme hast, versuche sie auch nicht zu lösen.

 

[FabianLurz]

Naja schwer zu sagen ob ich welche habe oder nicht. Aktuell haben wir einen relativ..naja eigentlich absolut...schlechten Server:
2,1 Ghz
512MB Ram

Es müssen dort 67k*67k Berechnungen durchgeführt werden. Bei diesem Server würde das gut 1 Jahr dauern.
Werde morgen einen besseren Server mit 6 CPU-Einheiten bestellen....da werde ich dann sehen, ob es dort schneller geht (Ziel ist in unter zwei Tagen).
Die Optimierung zur Laufzeit stimmt natürlich. Wahrscheinlich wird es wenig bis gar nichts bringen, das in Maschinencode umzuwandeln.

 

[tfa]

OK, du hast Performance-Probleme
Hast du dir schon den Algorithmus bzw. die Implementierung (Number-Crunching?) angesehen? Oder ein Profiling gemacht? Vielleicht kann man da noch was rausholen.

 

[FabianLurz]

Ohh ja Habe da wirklich schon Stunden mit verbracht. TreeMaps/HashMaps alles zu langsam. Am Schnellsten war das einfache array.
Habe wirklich schon sehr sehr viel gemacht und jedes noch so kleine Detail beachtet. Bin wirklich der Ansicht, dass es damit nicht viel schneller geht. Wenn sich allerdings jemand den Code ansehen möchte und mir helfen möchte würde ich mich natürlich freuen (PN).
EDIT:
Number-Crunching habe ich mir noch nicht angesehen. Danke für den Tipp lese mich gleich ein

Prinzipiell ist das was ich machen will recht einfach:

Berechne von 67k Items (bpsw. Filme) die Kosinusähnlichkeit untereinander (also ca. 67k*67k).
Vorher hatte ich es so gemacht, dass erst die Kosinusähnlichkeit aller Items berechnet wird und dann erst in die DB geschrieben. Dann bekommt man aber das Problem, das viel unnötige Berechnungen stattfinden (wenn corr = 0.0) und v.a. braucht man dann ordentlich Speicher (float).
Aktuell wird die Korrelationen eines Items live berechnet und dann direkt eingeschrieben. Bei Filmen gibt es vier Ähnlichkeitsmerkmale: Genre,Actor,Producer,Land. Nur wenn Genrecorr >0 ist werden die anderen berechnet. Das wäre bei der ersten Möglichkeit nicht möglich. Somit spare ich mir viel Rechenzeit.
Dennoch dauert die ca.4 x (für jeden Vektor) 4489000000 x Berechnung der Kosinusähnlichkeit wirklich lange
Evtl. gibts bessere Möglichkeiten das zu implementieren aber da ich schon 5 unterschiedliche Implementierungen ausprobiert habe sehe ich imho keine andere Lösung

 

[Empire Phoenix]

GCj, ja es geht.
GCJ: The GNU Compiler for Java - GNU Project - Free Software Foundation (FSF)

 

[Guybrush Threepwood]

Wie berechnest Du eigentlich die Korrelationen?
Wie viele Variablen enthält ein Datensatz?
Verwendest Du float oder double für die Berechnung?
....

Ich denke, es gibt viele Ansatzpunkte für Optimierungen und vielleicht ist es auch ein konzeptuelles Problem. Ich denke, Maschinencode wird Dein Problem nicht lösen.

 

[FabianLurz]

Ich denke ich werde mich morgen nochmal vernünftig mit dem Thema Multithreading auseinandersetzen. Denke, dass wenn überhaupt es daran liegen wird. Bezüglich Datentypen (also welche Datentypen performanter sind) habe ich mich informiert und meine die richtigen zu haben.
Falls Interesse besteht würde ich den Quellcode privat schicken aber jetzt nicht unbedingt öffentlich posten

 

[FArt]

Ich würde den Algorithmus auf Ganzzahlberechnungen umstellen.... und sicherstellen, dass er auch skalieren kann, sonst bringen dir mehrere CPUs bzw. Kerne gar nichts.
Berechnest du den cos tatsächlich? Dann könnte noch eine LUT helfen...

 

[FabianLurz]

Ahh das mit der LUT Tabelle klingt sehr interessant. Das kennt man noch aus der 6 Klasse Ja die cos Ähnlichkeit wird tatsächlich berechnet. Damit könnte man sich schon nochmal Zeit sparen.

 

[Lumaraf]

Wenn du größere Performancegewinne erreichen willst kannst du das nur über Änderungen am Algorithmus oder mit besserer Hardware erreichen. Alles andere bringt selten mehr als 5-10% Gewinn.

Eventuell bringt dir ja der folgende Ansatz was: Wenn es häufiger bei mehreren Filmen identische Werte in den einzelnen Feldern gibt wäre es vermutlich von Vorteil erst alle vorkommenden Werte herauszufiltern, dann diese miteinander zu vergleichen und diese Daten im nächsten Schritt wieder den Filmen zuzordnen.

Aktuell wird die Korrelationen eines Items live berechnet und dann direkt eingeschrieben. Bei Filmen gibt es vier Ähnlichkeitsmerkmale: Genre,Actor,Producer,Land. Nur wenn Genrecorr >0 ist werden die anderen berechnet. Das wäre bei der ersten Möglichkeit nicht möglich. Somit spare ich mir viel Rechenzeit.
Dennoch dauert die ca.4 x (für jeden Vektor) 4489000000 x Berechnung der Kosinusähnlichkeit wirklich lange

Zum Thema AOT-Compiler wäre btw Excelsior JET noch interessant. (Excelsior JET - Java Virtual Machine (JVM) and Native Code Compiler)