Fragen: JAVA (Geschwindigkeit), D()

rapso schrieb:

Schnellgeschwindigkeit schrieb:

volkard schrieb:

Kleine Speicherbereiche auf dem Heap anfordern

siehe "small object allocator" , zum beispiel in "modern c++ design" von alexandrescu.

natürlich kann man sich nen workaround bauen, aber standardmäßig ist es nicht gerade schnell.

Das ist eine optimierung, kein work around. Du ersetzt einen algorithmus durch einen besseren. bei java musst du work-arounds einbauen z.b. garnicht allokieren zur laufzeit (ueblich auf vielen handy/smartphones) oder eigene free/alloc listen, weil du garnicht optimieren kannst und bei den einfachsten dingen ploetzlich einen furtchbar langen GC einspringen siehst.... oder im schlimmsten fall garnichts davno weisst.

Das ist eine optimierung, kein work around. :p

*john 0

under_cover schrieb:

1.Ist Java wirklich SO LAHM, dass es jeder 2. der über Java redet erwähnt?

Ja, ist es. Jedes größere GUI Programm ist in Relation zu einem nativ Compilierten GUI Programm ziemlich lahm. Bei GUI-losen Programmen fällt es nicht so sehr ins Gewicht, da gibt es den größten Ärger wenn der GC herumzickt. Wenn man in die GC Falle gefallen ist, dann hat man einen ziemlichen Ärger am Hals.

hustbaer

~john schrieb:

under_cover schrieb:

1.Ist Java wirklich SO LAHM, dass es jeder 2. der über Java redet erwähnt?

Ja, ist es. Jedes größere GUI Programm ist in Relation zu einem nativ Compilierten GUI Programm ziemlich lahm. Bei GUI-losen Programmen fällt es nicht so sehr ins Gewicht, da gibt es den größten Ärger wenn der GC herumzickt. Wenn man in die GC Falle gefallen ist, dann hat man einen ziemlichen Ärger am Hals.

Die Lahmheit der GUIs liegt an den GUI Frameworks.
Zu behaupten Java ist langsam, bloss weil die GUI Frameworks langsam sind, ist wohl ein schlechter Scherz.
Dasselbe trifft im Übrigen auf C# und die "Forms" Klassen des .NET Framework zu. Die sind auch scheisse langsam (und nicht nur die).

Und wir werden sicher auch irgendeine langsame GUI Library für C++ finden, damit wir dann behaupten können dass C++ langsam ist.

Wenn es gehen würde hätte Sun Swing schon längst schneller gemacht. Aber es geht einfach nicht da Java zu langsam ist.

Helium

Tim schrieb:

D ist erstmal ein ganz großer Hype. Von "C++ überholen" kann nicht im Ansatz die Rede sein. Es mangelt an Tools etc. Der Hype ist wohl auch schon vorbei: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Kurz:

hustbaer schrieb:

ad 3: vergiss D

Danke, dass du mich an tiobe erinnerst. Ich wollte doch möglichst oft ein "delphi programming" einbringen.

pointercrash**

Also, VB(.NET) und Java sehe ich von der Erlernbarkeit auf dem gleichen Niveau und VB war früher ein echter Schnarchzapfen (wie Java auch), trotzdem hielt sich das Gemotze über das Laufzeitverhalten von VB in Grenzen, obwohl da nur ein p-code- compiler dahintersaß und für die Ausführung das Systemverzeichnis mit z.T. zueinander inkompatiblen vbrun- DLLs zugemüllt werden mußte. So von wegen ist ja BASIC, ganz nett für Einsteiger, paar Buttons und Fensterchens hinzukriegen, hat man einfach hingenommen.
SUN/Java ist da vollmundiger eingestiegen (vs. die damalige WINTEL- Front), hat seine Versprechen aber auch erst schrittweise eingelöst und dabei ignoriert, daß die Welt das nur Microsoft vollständig verzeiht - naja, nach Vista auch nicht mehr ohne Murren.

Mit den JIT- Compilern ist bei Java geschwindigkeitsmäßig viel passiert, VB baut jetzt auf dem .NET- Framework auf, aber als Gelegenheitsschnitzer fürn PC fasse ich Java dennoch ernsthaft ins Auge. Wenn man den Benchmarks glauben darf, spielt die Entscheidung für oder gegen Java keine wesentliche Rolle mehr, schnarchigen Müll zusammenschreiben kann man in jeder Sprache. Und wenn man eine in VB.NET(VS 03)geschriebene Mini-GUI unter Vista ums Verrecken nicht zum Laufen bekommt, besteht auch kein zwingender Grund, sich an ein müdes Framework zu binden.

~john schrieb:

under_cover schrieb:

1.Ist Java wirklich SO LAHM, dass es jeder 2. der über Java redet erwähnt?

Ja, ist es. Jedes größere GUI Programm ist in Relation zu einem nativ Compilierten GUI Programm ziemlich lahm.

kennste nicht Java-programme wie azureus und eclipse? die haben 'ne schnelle GUI. richtig lahme GUIs haben irgendwelche, ursprünglich aus der linux-welt stammenden programme, die nach windows portiert wurden. z.b. wireshark, eine echt geile software, aber die oberfläche ist total stokelig, wenn man's auf 'nem älteren rechner betreibt (ich glaub das gui-framework, das wireshark benutzt, heisst GTK oder so).

byto

piko schrieb:

Wenn es gehen würde hätte Sun Swing schon längst schneller gemacht. Aber es geht einfach nicht da Java zu langsam ist.

Single Threaded Swing Anwendungen sind in der Tat langsam.
Man kanns aber auch richtig machen. Dann sehe ich keinen Geschwindigkeitsunterschied.

tntnet

Schnellgeschwindigkeit schrieb:

volkard schrieb:

Gregor schrieb:

Es ist auch heute noch möglich, äquivalente Programme in C++ und Java zu schreiben, die in Java vielleicht um einen Faktor 5 langsamer sind. Umgekehrt ist das sicherlich auch möglich, aber wesentlich schwerer.

dazu müßtest du eine konkrete und durch den programmierer nicht behebbare deutliche performance-schwäche von c++ finden. ich bezweifle, daß es die gibt.

Kleine Speicherbereiche auf dem Heap anfordern

Ich denke, Volkard hat es auf den Punkt gebracht: Mit C++ kannst Du alles machen, was der Rechner hergibt. Es gibt keine prinzipiellen Beschränkungen in C++. Man kann in C++ einfach alles machen (sogar eine Java-VM schreiben ). Die unbegrenzten Möglichkeiten bringen natürlich eine gewisse Komplexität mit sich. C++ hat als Sprache einfach viele Möglichkeiten, die man erst lernen muß. Andere Sprachen lassen Möglichkeiten weg. Dadurch werden sie leichter erlernbar.

Die kleinen Speicherbereiche auf dem Heap anfordern ist keine prinzipielle Schwäche von C++. Das ist ein algorithmisches Problem, das mit jeder Sprache genauso langsam ist. C++ bringt allerdings Möglichkeiten mit, womit die Anforderung von kleinen Speicherbereichen auf dem Heap vermieden werden kann, wenn es für den konkreten Anwendungsfall notwendig sein sollte. Beispielsweise anstatt 1000 int-Variablen einzeln auf dem Heap anzulegen kann man gleich ein Array von 1000 int-Variablen oder noch besser ein std::vector<int> anlegen, welches das elegant kapselt. Man muß halt damit umgehen können.

Und bitte bitte hört mit diesem lächerlichen Java-bashing auf.

rapso

Schnellgeschwindigkeit schrieb:

rapso schrieb:

Schnellgeschwindigkeit schrieb:

volkard schrieb:

Kleine Speicherbereiche auf dem Heap anfordern

siehe "small object allocator" , zum beispiel in "modern c++ design" von alexandrescu.

natürlich kann man sich nen workaround bauen, aber standardmäßig ist es nicht gerade schnell.

Das ist eine optimierung, kein work around. Du ersetzt einen algorithmus durch einen besseren. bei java musst du work-arounds einbauen z.b. garnicht allokieren zur laufzeit (ueblich auf vielen handy/smartphones) oder eigene free/alloc listen, weil du garnicht optimieren kannst und bei den einfachsten dingen ploetzlich einen furtchbar langen GC einspringen siehst.... oder im schlimmsten fall garnichts davno weisst.

Das ist eine optimierung, kein work around. :p

anderer meinung? work around ist fuer mich wenn man nicht ohne das auskommt worum man drum arbeitet, es also noch beibehalten muss. aber belehre mich des besseren

hustbaer

@tntnet:
Man kann auch in Java eine Java-VM schreiben
Wäre mal ein geiles Projekt.

So ala VirtualBox in einer VMware VM laufen lassen

nman

hustbaer schrieb:

Man kann auch in Java eine Java-VM schreiben
Wäre mal ein geiles Projekt.

Auf GitHub gibts ein Lisp in Awk. Ich bastle gerade an einem Awk in Lisp. Mal schaun, wie oft man das auf einem modernen Rechner dann verschachteln kann.

OT: Erinnert mich an folgenden Versuch: Starte aus Windows eine Windows-VM via VMware. In der VM starte VNC und verbinde dich auf den Host

pointercrash**

Tim schrieb:

OT: Erinnert mich an folgenden Versuch: Starte aus Windows eine Windows-VM via VMware. In der VM starte VNC und verbinde dich auf den Host

Geht nicht nur, sondern macht sogar manchmal Sinn, zumindest bei der Einrichtung von VMs für externe Entwickler, da will ich ja nicht, daß der auf meinen VM-Server zugreift. Meist gehe ich dabei sogar den Umweg über einen externen Port- Forwarder, um den Zugriff "durch" das lokale Gateway zu checken. Ganz ulkig übrigens anzusehen, wie sich das Delay von der VMWare- Remote Console zur VNC- Konsole durchzieht.

Also bei mir ging das voll in die Hose. War aber auch schon ein paar Jährchen her. Kann gut sein, dass die Kiste das leistungsmäßig nicht verkraftet hat. Ist aber auch egal.

pointercrash**

Mit dem aktuellen VMWare Server und UltraVNC klappt's ganz gut, solange der VNC- Client nicht über die Internetverbindung in den Scrollwahn kommt. Ich hab' auch nicht wirklich die Bomber- Hardware, die 4 GB RAM helfen halt. Das schöne ist, daß man mehrere VMs in eine Workgroup sperren kann. Noch'n Skype dazu und man hat 'ne Stimmung wie im Großraumbüro.
Das "wo war ich denn gerade noch?" könnte allerdings mit der Zahl offener Konsolen exponentiell zunehmen ...

rapso schrieb:

Schnellgeschwindigkeit schrieb:

rapso schrieb:

Schnellgeschwindigkeit schrieb:

volkard schrieb:

Kleine Speicherbereiche auf dem Heap anfordern

siehe "small object allocator" , zum beispiel in "modern c++ design" von alexandrescu.

natürlich kann man sich nen workaround bauen, aber standardmäßig ist es nicht gerade schnell.

Das ist eine optimierung, kein work around. Du ersetzt einen algorithmus durch einen besseren. bei java musst du work-arounds einbauen z.b. garnicht allokieren zur laufzeit (ueblich auf vielen handy/smartphones) oder eigene free/alloc listen, weil du garnicht optimieren kannst und bei den einfachsten dingen ploetzlich einen furtchbar langen GC einspringen siehst.... oder im schlimmsten fall garnichts davno weisst.

Das ist eine optimierung, kein work around. :p

anderer meinung? work around ist fuer mich wenn man nicht ohne das auskommt worum man drum arbeitet, es also noch beibehalten muss. aber belehre mich des besseren

Sind natürlich beides workarounds, weil nicht das Problem da gelöst wird, wo es auftritt, sondern eine eigene Speicherverwaltung verwendet wird, um die standard Speicherverwaltung zu umgehen.

Dravere

Schnellgeschwindigkeit schrieb:

rapso schrieb:

Schnellgeschwindigkeit schrieb:

rapso schrieb:

Schnellgeschwindigkeit schrieb:

volkard schrieb:

Kleine Speicherbereiche auf dem Heap anfordern

siehe "small object allocator" , zum beispiel in "modern c++ design" von alexandrescu.

natürlich kann man sich nen workaround bauen, aber standardmäßig ist es nicht gerade schnell.

Das ist eine optimierung, kein work around. Du ersetzt einen algorithmus durch einen besseren. bei java musst du work-arounds einbauen z.b. garnicht allokieren zur laufzeit (ueblich auf vielen handy/smartphones) oder eigene free/alloc listen, weil du garnicht optimieren kannst und bei den einfachsten dingen ploetzlich einen furtchbar langen GC einspringen siehst.... oder im schlimmsten fall garnichts davno weisst.

Das ist eine optimierung, kein work around. :p

anderer meinung? work around ist fuer mich wenn man nicht ohne das auskommt worum man drum arbeitet, es also noch beibehalten muss. aber belehre mich des besseren

Sind natürlich beides workarounds, weil nicht das Problem da gelöst wird, wo es auftritt, sondern eine eigene Speicherverwaltung verwendet wird, um die standard Speicherverwaltung zu umgehen.

Dir ist aber schon bewusst, dass diese Features von der Sprache eingebaut sind, falls einem die Speicherverwaltung nicht gefällt, bzw. wenn man sie spezialisieren möchte.

Der "Small Object Allocator" nutzt einfach die Sprachmöglichkeiten für die eigene Speicherverwaltung. Das ist kein Hack, das ist kein hinbiegen, das ist nur ein Nutzen von Features.

Da könntest du auch sagen, dass ein while ein Workaround für ein if & goto ist.

Grüssli

Jester

Dravere schrieb:

Das ist kein Hack, das ist kein hinbiegen, das ist nur ein Nutzen von Features.

Hast Du grad mal ein Beispiel für einen Hack, der nicht nur das Nutzen von Features beinhaltet?

Dravere schrieb:

Der "Small Object Allocator" nutzt einfach die Sprachmöglichkeiten für die eigene Speicherverwaltung. Das ist kein Hack, das ist kein hinbiegen, das ist nur ein Nutzen von Features.

Workaround bedeutet auch nicht Hack. Wenn bei deinem Browser das anklicken von Links nicht geht und du sie stattdessen in die Adressleiste kopierst, dann ist das ein Workaround, auch wenn das kopieren von Adressen in die Adressleiste ne ganz normale Funktion ist.