nicht angemeldet
Hallo,
Was verstehst du unter "fest verdrahtetem" Code?
Ein Programm, das direkt in das Silizium des Chips geätzt ist (oder mit diskreten Transistoren aufgebaut).
Achso, du meinst Hardware...
Der OOP-Teil der Sprache ist SmallTalk, d.h. _zur Laufzeit_ werden Teile des Programmes durch einen SmallTalk-Interpreter gejagt.
"Objective-C is a dynamically typed language, as is Smalltalk. This means that we can send a message to an object which is not specified in its interface. This may seem a bad idea, but in fact this allows for a great level of flexibility - in Objective-C an object can "capture" this message, and depending on the object, can send the message off again to a different object (who can respond to the message correctly and appropriately, or likewise send the message on again). This behaviour is known as message forwarding or delegation. Alternatively, an error handler can be used instead, in case the message can not be forwarded. However if the object does not forward the message, handle the error, or respond to it, a runtime error occurs." http://en.wikipedia.org/wiki/Objective_C
Das bedingt, dass auch zur Laufzeit etwas geschehen muss, darauf basiert das Konzept.
Da steht nirgends, daß da irgendwo ein Smalltalk-Interpreter rumwerkelt.
Kommunikation über Messages bedingt außerdem in keinster Weise die
Ausführung des Codes in einem Interpreter.
Solange du keinen Text lieferst, der eindeutig (und glaubhaft) beschreibt,
daß Objective-C einen Smalltalk-Interpreter verwendet, glaube ich
deine Aussage nicht -- primär deshalb, weil die Aussage unglaubwürdig
ist.
Nein. Du verwechselst einfach Java mit Swing und gute Programmierer
mit schlechten Programmierern.So, ich habe gestern abend ein _simples_ Hello-World in C (puts("Hello World!\n"), C++ (std::cout << "Hello World!\n"), Java (System.out.println("Hello World!"), Perl (print "Hello World!\n") und PHP (echo "Hello World!\n") geschrieben und mittels des Unix-Programmes time die Laufzeiten ermittelt: Java war mit einer halben Sekunde etwas 5mal langsamer als C, das ca. 0,1 s brauchte.
Wie oft hat er das "Hello World" ausgegeben? Einmal?
Wenn ja, hast du bedacht, daß bei Java zuerst eine komplette
Laufzeitumgebung geladen und initialisiert wird?
Wie lange haben denn Perl und PHP gebraucht, bei denen ja auch sowas
wie eine Laufzeitumgebung geladen wird?
Glückwunsch, übrigens.
Mit deinem "Benchmark" hast du jetzt nichts gemessen, außer genau die
Zeit, die ein Programm zum Starten braucht. (Im Falle von Java,
PHP und Perl inkl. der Laufzeitumgebung.) Allerdings dachte ich, daß
die Java-VM länger zum Starten braucht. 0,5s sind ja richtig schnell.
Von den (vermutlich) sehr geringen Auflösung von "time" will ich jetzt
gar nicht erst anfangen...
Selbst ein Programm, dass über 10000 Schleifen durchläuft und den aktuellen Schleifenindex mit 2 XORed, ist in C 5mal schneller. Und das war nicht auf meiner alten DOSe mit 1GHz, sondern auf meinem neuem Mac mit GCC 3.3, Java 1.4.2, Perl 5.8.1 und PHP 4.3.2. Auf der DOSe verschiebt sich das ganze noch weiter zum Nachteil von Java.
Ein XOR braucht seit spätestens einem 286 genau einen Prozessor-Takt
zur Ausführung. Macht also pessimistisch gerechnet inkl. loop
und jump 10 Takte pro Schleifendurchlauf, also 100.000 Takte. Ein
1GHz-Rechner macht das in 0,0001 Sekunden...
Du misst noch immer die Startzeit der Programme. (Außerdem optimiert
ein C-Compiler die Schleife eh praktisch weg -- zumindest die beiden
XORs. Vermutlich noch mehr.)
Wenn du noch eine Bedingung zwischen die beiden XORs packst, die die
Zählvariable abfragt, so daß die XORs nicht mehr wegoptimiert werden
können, und dann die Schleife 4Mrd. mal ausführen läßt, braucht die
Linux-Kiste hier mit Java ca. 23 Sekunden. Ein GCC-kompiliertes Programm
mit -O3 ca. 8 Sekunden.
(Im Falle von Java messe ich den Programmstart nicht mit.)
Bewiesen wäre damit jetzt, daß Java beim Zählen, Vergleichen, usw.
langsamer ist. Stimmt. Arithmetik ist bei Java bekanntermaßen
langsamer als bei kompilierten Programmen. :-)
Der Benchmark ist aber noch immer kein Benchmark. Ein Benchmark wäre es
dann, wenn hier systematisch die Geschwindigkeit von Methodenaufrufen,
Instanzierungen von Objekten uswusf. gemessen würde. Eben alles, was in
aktuellen Programmen wichtig ist. Und da ist Java nicht wirklich
unperformanter als kompilierte Programme.
(Lies die zitierte c't und die von mir verlinkten Diskussionen.)
Perl braucht übrigens ca. 50 Minuten für das ganze. (Hab die Schleife
nur bis 50.000.000 laufen lassen. Das hat schon 38 Sekunden gedauert.)
PHP habe ich nach 10 Minuten mal abgebrochen.
Übrigens beweist auch das noch praktisch gar nichts.
Einen gewissen Anhaltspunkt der allgemeinen Geschwindigkeit dürfte es
aber schon liefern. :-)
Glaub mir. Interpretierte Sprachen sind definitiv und immer langsamer
als kompilierte Sprachen.Ist das nicht meine Rede?
Java ist nicht interpretiert.
(Java wird im Speicher kompiliert).
Siehst du.
Inwieweit es sowas wie einen JIT-Compiler in/für Perl gibt, weiß ich
nicht. Deshalb möchte ich da keine Aussage treffen.Perl wird bei der Ausführung auf jeden Fall in einen Binärcode kompiliert, ich weiß allerdings nicht, ob das der der jeweiligen Architektur ist oder ein plattform-unabhängiger.
"Although Perl has most of the ease-of-use features of an interpreted
language, it does not strictly interpret and execute source code one
line at a time. Rather, perl (the program) first compiles an entire
program to an intermediate byte code (much like Java's byte code),
optimizing as it goes, and then executes that byte code. It is
possible to compile a Perl program to byte code to save the
compilation step on later executions, though the "interpreter" is
still needed to execute that code."
Du kannst davon ausgehen, daß Java schneller ist.
s.o.
Es kommt auf den Einsatz an.
(Ich sagte ja, daß es _im Durchschnitt_ gleich schnell ist.)
Warum sonst wird Perl so häufig benutzt?
Das beantwortet dir wohl jedes Perl-Buch in der Einleitung.
Gegenfrage: Warum ist Java so verbreitet und wird immer beliebter?
Weil es irgendwie cooler ist dem Kunden irgendetwas binäres in die Hand zu drücken, bei Perl und Konsorten hat man ja zwangsläufig Opensource.
Java-Bytecode ist beliebig dekompilierbar. (Der Code läßt sich praktisch
nur dadurch schützen, daß man Variablennamen entfernen läßt usw.)
Außerdem glaube ich, dass sich kommerzielle Sachen in einem kommerziellen Umfeld besser verbreiten als freie.
Java ist kommerziell? Aha.
Warum wird C#, das so ziemlich alles von Java geklaut hat, jetzt
relativ schnell beliebt?Weil z.B. M$ den Windows-Programmierern "droht", "Wer jetzt nicht auf Managed Code umsteigt, wird es später schwierig haben" (iX 05/2004 oder etwas später).
Das ist vielleicht ein Grund, nicht aber "der Grund".
(Außerdem hat Microsoft in diesem Fall wohl recht.)
Gruß
Slyh