großes Problem

<< . 1 . 2 .

Autor	Mitteilung
roland registriert	Gesendet: 31 Mar 2005 00:33:48 wir wollten so wenig wie möglich extra datentypen. das is ein zu großer overhead. (siehe GC-diskussion). nur leider ist selbst ein array in java nich unbedingt ne gute wahl.. für eine indezierung werden 6 ops ausgeführt glaube.. und bei zwei eben doppelt so viel. kann man besser selber ausrechnen wo man da hin muss im speicher, aber das geht nich in java... für manche glück, für andere ein krux.. kann man auf verschieden weises sehen...
linap registriert	Gesendet: 31 Mar 2005 10:26:59 Ja, Java war ne schlechte Wahl für ne Sprache gewesen. Vielleicht wäre sowas wie Brainf**k besser zum spielen gewesen ;D Da hätte man in guter C-Manier wenigstens die anderen Schlangen mit Zeigern angreifen können ^^
schnueptus registriert	Gesendet: 31 Mar 2005 10:40:48 ja warum machst du dan nicht bei "Krieg der Programme" mit?
Strati registriert	Gesendet: 31 Mar 2005 12:04:20 Was hat dieses Problem mit einer schlechten Sprachwahl zu tun? Es geht doch nicht darum die andere Schlange "anzugreifen" sondern nur Informationen ueber diese zu bekommen. Wenn Du die Schlange "angreifen" moechtest (in C z.B. mit einem Zeiger) dann kannst Du dies auch in Java tun, allerdings mit etwas biegen und brechen, aber es geht auch hier wenn man das will. Bloss damit haste ja nichts gekonnt, denn beim Wettbewerb darfste so nicht dran teilnehmen! Sicher ist in Java ein Array kein Speicherbereich, ganz einfach weil es ja im Prinzip ein Objekt ist. Von daher kannste gar kein O(1) Zugriff im internen haben, aber es ist trotzdem ein konstanter Zugriff, anders als Vector & Co.! Und eins ist auch klar, man kann auch C/C++ und erst recht Assembler versauen, es ist nur dann effektiver wenn genau weiss was man tut. So kann man auch aus Java einiges rausholen, klar man kommt nicht an echten Maschinencode ran, da es interpretiert wird, aber man recht viel rausholen! Also Glueck auf und viel Erfolg! :-D
linap registriert	Gesendet: 31 Mar 2005 18:39:25 Die JVM ist AFAIK eine rein Stack-basierte Maschine und bietet damit im Bytecode keine Möglichkeit zur wahlfreien Speichermanipulation ;( Das Java interpretiert wird ist auch nich ganz richtig, da ja ein JIT-Compiler verwandt wird, der mehr oder weniger gut optimiert... Aber du hast Recht damit, dass sowohl in Java als auch in allen anderen Sprachen die Geschwindigkeit vom Wissen des Programmierers abhängt.
Strati registriert	Gesendet: 1 Apr 2005 15:59:40 Hmm, sehr interessant mit Deiner rein Stack basierenden Maschiene. Wenn ich in X86 ASM folgendes schreibe: push eax push ebx push ecx ... Komme ich als nicht wieder an eax ran ohne die anderen 2 vorher runter zu nehmen??? Ich komme aber mit einem direkten Zugriff an eax ran: mov eax, [esp+8] !!! Ist doch eine wahlfreie Moeglichkeit der Speichermanipulation!!! Wieso soll aehnliches im Bytecode nicht funktionieren??? Java interpretiert, egal ob JIT Compiler oder nicht, auch wenn der JIT Compiler den Code zur Laufzeit in Maschieneninstruktionen umwandelt wird der Bytecode wieder als Input, sprich als zu interpretierenden Code aufgenommen. Man koennte vielleicht sagen, ein optimierter Interpreter fuer bestimmte Hardware. Klar das ist jetzt eine Interpretationsfrage, ob man das als Interpreter anzieht oder nicht, aber fuer mich ist der Vorgang Interpretation. Streng genommen gibt es gar keinen Java-Compiler, denn als Compiler bezeichnet man ein Programm welches MASCHIENENINSTRUKTIONEN erzeugen kann und das tut Java nun wirklich nicht, viel mehr handelt es sich um einen "Optimierer"! Bytecode ist optimierter Quellcode, welcher besser und schneller interpretiert werden kann.
linap registriert	Gesendet: 1 Apr 2005 19:56:09 x86-Assembler ist keine JVM. In x86-Assembler habe ich, wie du schon gezeigt hast, im Prinzip Zugriff auf jeden Speicherbereich, den ich will, denn der Stack ist Teil des Speichers. Wenn du dich aber mal ein bisschen näher mit Java-Bytecode, der nichts anderes ist als eine Reihe von Opcodes für eine (virtuelle Java-)Maschine (was im Übrigen nach deiner Definition die Existenz eines Compilers impliziert, vom GNU Java Projekt mal ganz abgesehen , wirst du folgendes sehen: Es gibt keine für den Assembler wahlfreie Speicherorganisation. Alle arithmetischen und sonstigen Operationen finden auf Operanden, die auf dem Stack liegen, statt. Es gibt eine Art von Register (lokale Variablen) und die übrigen Objekte und Methoden. In JVM-Assembler/Bytecode gibt es keine Möglichkeit über irgendwelche esps oder ähnliches auf die reale Speicheradresse zuzugreifen. Der Unterschied zwischen Interpreter und Compiler ist sicherlich ein Stück weit Definitionssache... So long, Thomas.
Strati registriert	Gesendet: 2 Apr 2005 13:24:26 Ja vom Prinzip her hast Du ja recht, wenn ich auch in Kleinigkeiten da nicht ganz mitgehe, aber nun ja haben wir genug diskutiert! Viel Erfolg im Wettbewerb! Gruss Strati

<< . 1 . 2 .

Um einen Eintrag zu schreiben müsst ihr euch als Nutzer des snEADy-iBoards registrieren!