kleines tool für c# hacker - Seite 2

Seite 2 von 3 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/kleines_tool_fuer_c_hacker_98552/page_2 - zur Vollversion wechseln!

Zitat von crashman

c# verwendet eine virtuelle maschine analog zu java -> folglich brauchst du die vm die bei c# imho VES heisst und im .net package dabei ist.

aehm, nur zur info:

beim compilieren wird der c# code in MSIL code übersetzt = microsoft intermediate language
kann man mitn java byte-code vergleichen

dieser code wird dann vom CLR = common language runtime in maschinennahen code übersetzt, der dann eben von der CLR ausgeführt wird.
kein vergleich zur java-vm, da es sich bei der CLR dumm gesagt um einen geschützten speicher handelt -> managed code
ausserdem übernimmt die CLR auch alle security-kontrollen

übersetzung vom MSIL code geschieht bei der ersten anfrage, danach liegt der compilierte code + metadaten im assembly-cache des system



aber eigentlich gehts ja um das tool

Zitat von Oculus

kein vergleich zur java-vm, da es sich bei der CLR dumm gesagt um einen geschützten speicher handelt -> managed code
ausserdem übernimmt die CLR auch alle security-kontrollen

eben nicht

java verwendet einen interpreter, der den byte-code interpretiert (duh!)
MSIL code wird nicht interpretiert, sondern läuft annähernd native -> massiver performance-schub gegenüber java

nachteil: bereits in MSIL compilierter code muss nochmals bei der ersten anfrage vom plattformabhängigen CLR-compiler übersetzt werden. dann ists nimma plattformunabhängig

wobei sich die plattformunabhängigkeit beim .net eh auf intel, amd und alpha beschränkt

Hast du schon mal was von Java JIT Compilern gehört?

EDIT: Ich mach meine Diplomarbeit über Java JIT Compilation, da kenn ich mich aus, das kannst mir glauben.

glaub ich dir schon, dass du dich auskennst

stimmt doch, dass der JIT den byte-code für die plattformabhängige java-VM kompiliert, damit dieser dann vom java-interpreter der VM ausgeführt werden kann, oder?

edit: warum diskutieren wir jetzt über des?
es geht um mein tool

zur info:
ich verwend den CodeDom-Namespace vom framework, mit dem man code zur laufzeit kompilieren und ausführen, speichern oder wwi kann.
den code, den man in der commandline von meinem tool eingibt, wird in eine template-methode eingefügt, die dann vom tool aus aufgerufen wird.
also hatman die beschränkung, dass man nur code wie im rumpf einer methode programieren kann. was aber für solch kleine testereien völlig ausreicht.
brauchtman spezielle klassen, muss man sie halt vollqualifiziert angeben
zb. System.IO.StreamReader oda System.Collections.ArrayList

Der Java Compiler (javac oder jikes) macht aus .java Files .class Files. Diese enthalten Bytecode für die VM.
Die VM enthält entweder einen Interpreter oder einen JIT Compiler (oder beides) und führt den Bytecode aus. Im Falle des JIT Compilers bedeutet das, dass jede Methode, bevor sie ausgeführt wird, von Bytecode in Maschinencode (für die jeweilige CPU) übersetzt wird.

Bei .NET ist es genau gleich, nur dass die Dinge ein bisschen anders heißen.

Und wo ist jetzt der Sourcecode?

Zitat von Ringding

Der Java Compiler (javac oder jikes) macht aus .java Files .class Files. Diese enthalten Bytecode für die VM.
Die VM enthält entweder einen Interpreter oder einen JIT Compiler (oder beides) und führt den Bytecode aus. Im Falle des JIT Compilers bedeutet das, dass jede Methode, bevor sie ausgeführt wird, von Bytecode in Maschinencode (für die jeweilige CPU) übersetzt wird.

Bei .NET ist es genau gleich, nur dass die Dinge ein bisschen anders heißen.

Zitat von Oculus

woher kommt dann der performancevorteil beim .net?
(is jetzt als frage gemeint, und net als konter )

Zitat von Oculus

mir war heut recht fad in da firma
und da hab ich mir endlich ein kleines tool programmiert, was ich schon lang hätte brauchen können

einen kleinen code-tester
wenn man also fragmente eines codes testen will, braucht man sich nimma extra a file schreiben und compilieren

keine ahnung, obs andere auch noch brauchen können
für mich ists sehr hilfreich

programm ist selbsterklärend

für wünsche/anregungen/kritik bin ich grundsätzlich offen, solangs sie ungleich aussagen wie "wozu brauchtma das?" oder "bringt nix, so a schas" ist

Infos:

http://csharpfriends.com/Articles/g...px?articleID=89

http://csharpfriends.com/Articles/g...px?articleID=90


Sorry - habs vorhin vergessen dazuzuschreiben

@crashman: Ich hab mal das Descent probeweise für .net compiliert, da ist es haargenau gleich schnell gelaufen wie native.

Leider weiß ich auch noch keine vernünftige Erklärung für den oft enormen Performanceunterschied / .NET. Es gibt durchaus Sachen, da ist Java auch recht schnell. .NET ist halt doch neuer und hat schon ein bisschen aus den Fehlern von Java gelernt und hat auch ein paar Tweaks und Möglichkeiten mehr eingebaut.

hier muß sun unbedingt aufholen - so wie .net von java gelernt hat, muß java von .net lernen.

nur dass SUN derzeit finanziell eher schlecht da steht ... :/

overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025