C programmieren

[noox]

naja, wegen präemtiven Multitasking dürfte auch ohne DoEvent noch was gehen...

[stinky5]

VB is jo ka Programmiersproch

[noox]

he, ich hab bei einer Firma auch vB Programmieren müssen . Naja, wenn ich dort dann fix anfange, dann werde ich mich bald dafür einsetzen, dass wir auf C# umsteigen. Was ich bis jetzt gesehen habe, kann das .NET schon einiges.

[stinky5]

Ich programmiere in der Arbeit Java, C und C++, wobei ich immer wieder froh bin, wenn ich Java mache. IMHO ist C++ zu aufgebläht, C unterstützt bekanntermassen kein objektorientiertes Programmieren und Garbage Collector gibts a net serienmässig.

[noox]

Java kann ich nicht. Hab zwar schon ein, zwei Progrämmchen geschrieben und auch die Klausur auf an einser gemacht. Aber können tu ich's net.

Mein Problem ist meine Vergangenheit: Ich hab zu Zeiten programmiert, wo du jeden Prozessortakt ausnützen musstest. (Damals brauchte auch ein Prozessor noch mehrere Taktzyklen für einen Befehl. Heute kann er dank Pipelines und die mehrfach parallel einige Befehle pro Takt fertigstellen.) Und damals hab ich eben viel Assembler und C programmiert.

C++ zu aufgebläht kann ich net so nachvollziehen. Ich hab mir damals zwar Gedanken gemacht, ob des schon g'scheit ist, in C++ zu programmieren, wo ja beim Methodenaufruf über den Umweg einer Sprungtabelle gegangen werden muss, um je nach Typ des Objekts die richtige ("virtual") Funktion zu finden.

Da kannst dir vorstellen, welche Krisen ich bekomme, wenn ich mit ana Sprache mit Garbage-Collection programmieren muss

Vor an dreiviertel Jahr habe ich aber von der Firma einen Auftrag nach genau meinem Geschmack erhalten. Eine fehlertolleranten Dublettensuche für mehrere 100.000 Adressedatensätze. Hab zwar ewig net gewußt, wie ich das machen sollte. Aber nach ein, zwei Wochen - ich sitz grad so in der Sonne - kommt mir ein alter c't Artikel in den Sinn und ich hab die Idee. Nach einigen Stunden war der Protyp fertig. Hatte anfangs noch ziemliche Probleme, weil ich da ziemlich viel mit Zeiger auf Zeiger usw. hantieren musste, und ich davor zwei Jahre nimmer C programmiert hatte. Aber man kommt schnell wieder rein. Der erste Prototyp brauchte hochgerechnet nur mehr 31 Stunden für 400.000 Datensätze (oder 500.000 weiß nimmer genau). Die hatten das ganze vorher mit VB (!!!) probiert und das hätte 100 Tage gedauert. Naja, es hat dann noch ca. 2, 3 Wochen gedauert, bis es auch wirklich mit Echtdaten, Datenbankanbindung und Websteuerung funktioniert hat. War dann allerdings durch Algorithmusoptimierung schon auf 7 Stunden (auf meinem Athlon 800MHz)herunteroptimiert. Wobei es praktisch linear mit Taktfrequenz oder Speicherinterface (was halt der Flaschenhals ist) skaliert.

Freu mich auch schon, wenn ich das ganze auf 64-Bit Prozessoren optimieren kann. Dann kann ich nämlich bei einem sehr oft verwendeten Vergleich 8 Bytes, statt 4 gleichzeitig vergleichen. Das daugt ma halt. Taktzyklen-Schinden.

Bei sowas denke ich, das eben nur C(++) geeignet ist. Ich musste dabei extrem viel im Speicher herumjonglieren. (einige 100MBs). Meistens eben mit Zeiger auf Arrays, oder Arrays von Zeiger. Hat Java überhaupt Zeiger? Und ich denke mit Garbage Collection ginge das nie so schnell. Überhaupt habe ich das Gefühl, dass Java eher speicherhungrig ist. Aber das kann ich nur als Anwender von Java-Programmen beobachten. Meine Erfahrungen mit Javaprogrammen sind leider eher negativ.

Wo Java allerdings hervorragend sein soll, ist der Web-Bereich. Servlets, Java-Beans, .. usw. Aber leider kenn ich mich da auch zuwenig aus.

Und jetzt hat ja da Sun mit .NET eine ziemlich starke Konkurrenz bekommen. Das was ich mir bis jetzt so von .NET angeschaut habe, ist das schon verdammt vielversprechend. Bin echt schon auf die ersten unabhängigen Test gespannt, was schneller ist. Java hat halt in dem Bereich einen großen Vorsprung und hat sich schon bewährt. Ob das Microsoft auch gelingen kann?

Für meine kleinen Sachen (wie z.B die Rangers-Seiten) mache ich alles mit PHP. Mit PHP kann man echt super programmieren. Mit Acceleratoren gibt es Produkte, die den compilierten Code cachen, sodass das ganze schon schneller als mit einem JIT (oder gar Interpreter) läuft. PHP bietet so gut wie alle benötigten Funktionen schon von Haus aus mit und es arbeitet hervorragend mit MySQL zusammen. Und MySQL ist mindestens so schnell, wie die anderen großen DBs, und bei diesen kleinen Projekten braucht man keine Transaktionssicherheit. (Bei den neuesten MySQL-Versionen, sollte das aber auch immer besser funktioniern.)

Aber selbst bei PHP habe ich immer im Hinterkopf: Was macht der Prozesser, wenn ich dieses, oder jenes schreibe

Vorteil ist auch, dass die Software gratis ist, und dass es Server mit Linux, Apache, PHP, MySQL und allem drum und dran eigentlich zu Spott-Preisen gibt.

Außerdem sind diese System alle für Fernwartung ausgelegt. Ich weiß nicht, wie das mit Microsoft-Umgebungen (die könnte ich mir sowieso nicht leisten) oder Java-Umgebungen aussieht. Nett wär's natürlich schon, wenn man sich den Server selber zusammenbaut und dann beim Provider um die Ecke reinstellt. Aber in Österreich oder auch Deutschland könnte ich mir den Datentransfer nicht leisten, den unsere Seiten verursachen. Vor allem wennst dann vielleicht auch noch a multihomed burstable Verbindung haben willst...

[Leuschner]

Hat Java überhaupt Zeiger?

es gibt keine wirklichen zeiger in java bzw. keinen datentyp pointer. es gibt aber referenz variablen mit denen sich das gleiche realisieren läßt.

Und ich denke mit Garbage Collection ginge das nie so schnell.

auch wahr, dafür nimmt er einem wirklich viel arbeit ab find ich.

Überhaupt habe ich das Gefühl, dass Java eher speicherhungrig ist. Aber das kann ich nur als Anwender von Java-Programmen beobachten.

stimmt. das is halt das problem mit dem bytecode. der muss ja irgendwie so verpackt werden, das der auf allen system läuft und da bleibt die geschwindigkeit und der speicher auf der strecke.

[stinky5]

Da ich gerade eine Java Virtual Machine und begleitende Bibliotheken auf ein eingebettetes System portiere (VM in C, GUI in C++) beschäftige ich mich zwangsläufig ein wenig mit den Innereien, aber die Aussage das der Bytecode für langsame Speicherhungrige Programme sorgt ist schlichtweg falsch. Es stimmt zwar, dass bei Java ein gewisser Overhead besteht, weil ein String z.B. kein char* auf einen Speicherbereich ist und sondern ein Object und auch Arrays prinzipiell von java.lang.Object abstammen und net nur ein einfacher gemallocter Speicherbereich irgendwo (Am End ist es natürlich schon irgendwo ein gemallocter Speicher, aber da ist halt noch eine Abstraktionsebene dazwischen)

Der schlechte Ruf von Java stammt aus der Zeit, als viele Java Virtual Machines noch interpretierten. Heutzutage wird mit JIT Compilern bzw. AOT Compilern gearbeitet. Ich habe schon mit einem Java Echtzeitbetriebssystem (harte Echtzeit!) gearbeitet, das hat net schlecht funktioniert (und das geilste war, du hast von Java aus Assembler programmieren können, weil irgendwie musst jo z.B. Register setzen.)


Grundsätzlich gilt (und I zähl nur die Punkte auf, die mir sofort nach dem zweiten Pint einfallen):

Pluspunkte für Java:
+ Sichere Sprache
+ Fehler nach dem Verursacherprinzip (D.h. du kannst net irgendeinem anderen den Speicher freen und all die lustigen Fehler, wenn 30 Leute an einem einzigen System arbeiten)
+ Plattformunabhängig (wobei das IMHO net ganz richtig ist)

Minuspunkte:
- Durch die CPU <-> OS <-> VM <-> Bytecode sitzt man nicht direkt auf der CPU, was Vor und Nachteile hat. Es gibt durchaus Betriebsysteme, die nach dem Schema CPU <-> OS/VM <-> Bytecode aufgebaut sind, zusammen mit einem AOT Compiler pfeift die Sache dann schon ordentlich. Das gibts aber hautpsächlich in der Welt der Embedded System, z.B. Esmertec.
- Keine direkte Speicherzugriffe (Manipulation), wobei das net unbedingt ein Nachteil ist.

Es ist halt ein Tradeoff zwischen Geschwindigkeit bei der Ausführung/Geschwindigkeit bei der Entwicklung/Korrektheit des Programms.

[noox]

Was ist AOT? So ein Compiler, der den Bytecode (oder Java-Code?) Direct in Maschinenbefehle übersetzt?

Die Sicherheit von Java hat schon seine Vorteile. Bei dem oben angesprochenen Programm hab ich sicher ein, zwei Stunden damit verbracht zu kontrollieren, ob alle Speicherbereiche auch korrekt wieder freigegeben wurden. Hab mir bei jedem new und bei jedem delete ausgeben lassen, wieviel Speicher reserviert bzw. wieder freigegeben wurde. War net so einfach, weil wirklich viele verschachtelte Speicherreservierungen vorgenommen wurde, und das oft mit verschiedenen Datentypen (1, 2 oder 4 Bytes pro Wert)... Hab dabei einige Fehler entdeckt. Das könnte ich mir bei Java sparen.

Und Geschwindigkeit verliert mit schnelleren Rechnern immer mehr an Bedeutung. Allerdings gibt's natürlich immer wieder mal Anwendungen, die nicht schnell genug sein können.

Wie gesagt, ich bin kein Java-Profi. Eigentlich net mal ein Einsteiger. Was mir halt an Java auch net daugt ist, dass es meist schon sehr kompliziert ist ein Programm zu starten. Welches Java-Zeugs muss ich mir da runterladen? Ich lad dann immer irgendwas von der Sun-Seite runter, installier das, und schau dann ob das Programm damit geht. Dann muss ich die noch so kompliziert aufrufen mit java .... Dazu müssen aber wieder die Pfade passen (inkl. CLASSPATH...)

Dann gibt's halt so negative Erfahrungen:
2 GUI-Anwendungen in Java: Extrem instabil, extrem langsam, und sie machen dann noch dazu den ganzen Rechner langsam... Programme brauche dabei extrem viel Speicher...

eine Text-Applikation (FOP, die aus meiner Dipl im XSL-FO Format ein PDF macht) bricht plötzlich ab. Fehlermeldung: "Error". Hatte so Fehler schon, weil dieses Programm halt net wirklich fehlerfrei ist. Diesmal hing der Fehler aber net vom Inhalt der Quelldatei ab, sondern von dessen Länge. Ok, vermutlich Speicherproblem. Komisch, alle anderen Appls geschlossen, und es ist noch genügend Speicher frei: Trotzdem Fehler. Nach Suche im Usenet: java mit einem Parameter starten, damit Java mehr Speicher verwendet. Sonst verwendet es einfach net mehr.

Bei einer exe Datei gäbe es das halt nicht...

Aber das liegt teilweise an meine Unwissenheit.

[stinky5]

Was ist AOT? So ein Compiler, der den Bytecode (oder Java-Code?) Direct in Maschinenbefehle übersetzt?

Ahead Of Time, ja übersetzt direkt.

Ok, vermutlich Speicherproblem. Komisch, alle anderen Appls geschlossen, und es ist noch genügend Speicher frei: Trotzdem Fehler. Nach Suche im Usenet: java mit einem Parameter starten, damit Java mehr Speicher verwendet. Sonst verwendet es einfach net mehr.

Man muss sich halt immer vor Augen halt, dass Java ein Computer für sich ist, mit eigener CPU und eigenem Speicher (Der Virtual Machine nämlich und dem Speicher, den die VM mallocen darf).

Dann gibt's halt so negative Erfahrungen:
2 GUI-Anwendungen in Java: Extrem instabil, extrem langsam, und sie machen dann noch dazu den ganzen Rechner langsam... Programme brauche dabei extrem viel Speicher...

Gebe ich dir recht, Java auf dem PC, besonders sobald AWT/Swing im Spiel ist momentan noch nicht das Wahre (Ich arbeite mit Sun Studio ONE als IDE für Java, ist nach dem Laden schnell genug und angenehm zu bediene, aber braucht Speicher!).

Ich sehe viel Vorteile von Java im Embedded Systems Bereich. Dort ist es schon schnell genug, und Prozessorleistung gibts mittlerweile schon massig. (Mein Embedded System hat 8 Megs RAM und einen 200 MHz MIPS!). Vorteil ist einfach die Speicherverwaltung und die geringere Wahrscheinlichkeit, sich ins Knie zu schiessen.

[noox]

AOT habe ich noch nie gehört. Ahead of Time? Heißt das, dass (mindestens) ein Thread den Code übersetzt, etwas versetzt, der bereits übersetzte Code in eigenen Threads ausgeführt wird? Also dass nicht, wie beim JIT, zuerst compiliert und dann ausgeführt wird, sondern eben fast gleichzeitig mit beidem begonnen wird? Aber halt die Übersetzung - wenn möglich - etwas voraus ist.

[stinky5]

Vü anfocher, bevor der Code das erste Mal ausgeführt wird, is a fix und fertig compiliert (in CPU opcodes), während bei JIT des Werkl erst die Hot Spots finden muss um die zu optimieren (So, jetzt wissn wir ah warum Sun seine VMs "HotSpot" nennt.

AOT is net sehr weit verbreitet, zumindest in der Desktopwelt, aber wennst in Embedded Systems auf einen Interrupt wartest kannst net erst wenn die ISR ausgeführt wird zum optimieren beginnen . Entweder wird bei AOT der Code am Entwicklungssystem schon fertig kompiliert oder es gibt einen Target Byte Code Compiler, der beim runterladen des Codes das dann erledigt.

[noox]

Alles klar. Nur finde ich dann den Begriff AOT eher irreführend.

Einen Vorteil hat ja der Zwischencode (Bytecode by Java, MSIL bei MS): Man kann die VM bzw. den JIT-Compiler auf den Prozessor optimieren. Der Entwickler gibt also Bytecode/MSIL weiter, der wird aber dann, da er erst auf dem Zielrechner entgültig compiliert wird, genau auf einen Prozessor optimiert.

Das kannst mit einem fertigcompilierten Executable nicht machen. Da musst dich meist auf den kleinsten gemeinsamen Nenner einigen.

Dann kann auch je nach Prozesser usw. Bytecode oder MSIL schneller sein als nativer Code.

[stinky5]

Alles klar. Nur finde ich dann den Begriff AOT eher irreführend.

Hab ich nicht erfunden!

Mit MSIL habe ich leider nix gemacht, hab zwar des Microsoftzeugs .NET am Rechner, aber ich brauch davon eh nur den C++ Compiler.

[Old Anonym]

Versuch es mal mit dem Befehl sleep(x); fur x setzt man einfach ne zahl ein 1=eine Sekunde chaos_blader@web.de