Frage zu x86 Prozessoren: Schneller durch direkte Programmierung? [Archiv]

Muh-sagt-die-Kuh

2003-12-01, 00:56:47

Original geschrieben von Herr Doktor Klöbner
Hallo ,
wenn ich die Sache richtig verstanden habe sind aktuelle x86 Prozessoren nichts anderes als in Hardware gegossene Emulatoren für den Intel 80386 Prozessor die dessen Befehlssatz ( samt Erweiterungen )für den eigentlichen Prozessorkern , einen sehr viel moderneren Risc Prozessor mit wesentlich mehr Registern , übersetzen.Prinzipiell schon, nur finde ich den Begriff "Emulation" hier nicht sonderlich passend.
Meine Frage ist nun folgende : wäre es möglich zum Beispiel eine P4 oder Athlon XP Variante zu entwickeln bei der ich diesen " Übersetzer " deaktiviere und den Softwareentwicklern die Möglichkeit geben würde direkt Code für " das wahre Ich " dieser Prozessoren zu programmieren?Ja, das ist möglich, wenn ich mich recht entsinne hat VIA so etwas ähnlichen schon mal in einer ihrer C3 Inkarnationen eingebaut. Würde das überhaupt merkliche Geschwindigkeitsvorteile bringen ?Ja, da man deutlich mehr Register zur freien Verfügung hätte als die mageren 8 der x86 ISA.

Sinnvoll wäre das ganze aber nicht, schliesslich müsste man für jede CPU einen eigenen Compiler schreiben, da die internen Befehlssätze proprietär sind.

Eine neue, modernere ISA (Instruction Set Architecture = Befehlssatz) ohne Altlasten zu definieren ist der sinnvollere Ansatz.Wäre Software mit einem Mischmasch aus x86 Code und "echten" p3/p4/k6/Athlon Code ( nicht identisch , proplematisch , ich weis ) überhaupt schneller oder würde das Umschalten zwischen den beiden Betriebszuständen endlos dauern und unterm Strich jede Software eher ausbremsen ?Innerhalb eines Prozesses sollte der Code kein Mischmasch sein, würde das gehen hätte man praktisch eine neue ISA definiert.
Mehrere Prozesse mit unterschiedlichen Befehlssätzen führend zu kaum einem Leistungseinbruch, siehe Athlon 64 / Opteron unter einem 64-bit OS mit 32-bit Applikationen.

Zool

2003-12-01, 09:54:26

Als richtige Emulationsprozessoren wären die Crusoeprozessoren von Transmeta mit ihrer x86-Emu zu nennen.

zeckensack

2003-12-01, 12:56:31

Original geschrieben von Herr Doktor Klöbner
Meine Frage ist nun folgende : wäre es möglich zum Beispiel eine P4 oder Athlon XP Variante zu entwickeln bei der ich diesen " Übersetzer " deaktiviere und den Softwareentwicklern die Möglichkeit geben würde direkt Code für " das wahre Ich " dieser Prozessoren zu programmieren ?Möglich wär's sicher. Bei den x86-Prozessoren von AMD und Intel geht's derzeit nicht. Diese Prozessoren sehen es architektonisch überhaupt nicht vor, ihren 'nativen' Code einzulesen. Alles - von fetch, decode, bis zur I-Cache-Architektur - ist auf x86-Code ausgelegt.

Außerdem wäre das IMO sogar richtiggehend doof für einen Massenmarkt, wie es der PC nunmal ist: indem man die interne Architektur dokumentiert und zugänglich macht, 'riskiert' man, daß dafür auch Code produziert wird. Und dann hat man den Salat, man müßte dann die nächste Generation so ausstatten, daß sie abwärtskompatibel ist. Denn Code der nur auf einer einzigen Generation überhaupt lauffähig ist, ist in dem Bereich komplett uninteressant (in anderen Bereichen wie embedded und Konsolen natürlich nicht).
Würde das überhaupt merkliche Geschwindigkeitsvorteile bringen ?Ich behaupte: nein.
Ein großer Vorteil von x86-Code ist die variable Instruktionslänge, der Code ist dadurch sehr kompakt und spart somit Bandbreite und Cache-Größe.
Der offensichtliche Nachteil ist die Notwendigkeit zur Dekodierung, das Silizium dafür ist allerdings bereits in den Prozessoren vorhanden, womit das Problem als gelöst betrachtet werden kann. Würde man die x86-Decoder nicht nutzen, hätte man lediglich einen Haufen brachliegende Transistoren 'gewonnen'.

Zum Vergleich, RISC-Code hat idR keine 'escapes', die Instruktionslänge ist daher meistens konstant, seltener sind 2, noch seltener 3 verschiedene Instruktionslängen möglich; die Instruktionsgröße wird natürlich so bemessen, daß man alles darstellen kann, was die ISA hergibt. Der seelige Alpha 21264 zB braucht für jeden Befehl 16 Bytes. x86-Ops sind 'stufenlos' zwischen 1 und 15 Byte lang. edit: Im Mittel nur 3 Bytes - wirklich wahr :D

Man kann x86-Code mit gutem Gewissen als "transparente Code-Kompression" bezeichnen, was ich hier nicht zum ersten Mal schreibe :)

Bei den Registern sehe ich auch keinen großen Gewinn, weil 1)wieder das register rename-Silizium bereits fest eingeplant ist, und 2)dieses benötigt wird, um sinnvoll OOOE (out of order execution) zu betreiben.

Ein Ur-x86 mit nur 8 physikalisch überhaupt vorhandenen GP-Registern steht natürlich dumm da. Das heißt aber nicht, daß eine ISA mit nur 8 Registern schlecht ist, die aktuellen Cores leisten hier gewaltige Optimierungsarbeit, sodaß unterm Strich eigentlich kein Nachteil besteht.

Und 3)gibt es tatsächlich bereits so eine Art "Bypass" in den x86-CPUs: MMX/SSE etc erlauben ja bereits, Ausführungseinheiten brutal effizient zu nutzen, ohne dafür das Code-Format umschalten zu müssen. Bitte das nicht vergessen :)

(btw leistet SIMD primär nur eins: erhöhte Code-Dichte, sowohl im Speicher, als auch im Scheduler; diese Parallele zu x86-Code halte ich durchaus für erwähnenswert)
Wäre Software mit einem Mischmasch aus x86 Code und "echten" p3/p4/k6/Athlon Code ( nicht identisch , proplematisch , ich weis ) überhaupt schneller oder würde das Umschalten zwischen den beiden Betriebszuständen endlos dauern und unterm Strich jede Software eher ausbremsen ?Man könnte das sicherlich so lösen, daß es kaum oder garnicht teurer ist als ein 'normaler' Thread-Wechsel. Als erste Idee könnte man ein weiteres Bit in den Segment-Deskriptoren aufwenden, und damit Code-Segmente entweder als "x86" oder "nativ" markieren. Innerhalb eines Threads das Code-Format zu mischen, wäre damit allerdings nicht möglich.

Muh-sagt-die-Kuh

2003-12-01, 13:21:27

Original geschrieben von zeckensack
Ich behaupte: nein.

Man kann x86-Code mit gutem Gewissen als "transparente Code-Kompression" bezeichnen, was ich hier nicht zum ersten Mal schreibe :)

Bei den Registern sehe ich auch keinen großen Gewinn, weil 1)wieder das register rename-Silizium bereits fest eingeplant ist, und 2)dieses benötigt wird, um sinnvoll OOOE (out of order execution) zu betreiben.

Ein Ur-x86 mit nur 8 physikalisch überhaupt vorhandenen GP-Registern steht natürlich dumm da. Das heißt aber nicht, daß eine ISA mit nur 8 Registern schlecht ist, die aktuellen Cores leisten hier gewaltige Optimierungsarbeit, sodaß unterm Strich eigentlich kein Nachteil besteht.8 GPR sind einfach zu wenig, da hilft auch noch so intelligentes Register Renaming nicht, siehe die Leistungssteigerung durch die 16 GPR von AMD 64.

Außerdem: Je mehr architektonische Register man hat, desto weniger Renaming muss man betreiben.

zeckensack

2003-12-01, 13:33:12

Original geschrieben von Muh-sagt-die-Kuh
8 GPR sind einfach zu wenig, da hilft auch noch so intelligentes Register Renaming nicht, siehe die Leistungssteigerung durch die 16 GPR von AMD 64.Dafür braucht AMD64 statt drei Bits nun (im Mittel) sieben Bits, um die Register zu addressieren. Nicht daß das enorm viel wäre, aber das ist halt ein Tradeoff, den man berücksichtigen muß.
Und nein, die bezifferten 10~15% Mehrleistung (im echten Leben wohl eher 5%) halte ich nicht wirklich für eine schlagkräftige Demonstration von "zu wenig ISA-Register".

Man schaue sich nur mal den 6502 mit seinen zweieinhalb GP-Registern an. Das ist eine echte Register-Verklemmung.

Außerdem: Je mehr architektonische Register man hat, desto weniger Renaming muss man betreiben. Jein. RR kann helfen, Instruktionen zu überlappen und senkt Latenzen. Ohne RR bleibt diese Bürde dem Compiler überlassen (der das nicht wirklich kann - Stichwort "dynamische branches").
Selbst die PPCs mit ihrer "RISC"-ISA, 32 Registern und drei-Operanden-Form machen noch RR.

Bokill

2003-12-01, 13:42:54

@zeckensack
Dein Beitrag war wirklich gut..., jedoch entfällt ja eine komplette Ausführungseinheit, die Engine welche den x86 Code umwandelt in die jeweilige "Familiensprache".

Eigentlich müsste daher doch die Nackte CPU dann schneller sein, der Nachteil ist jedoch aufgeblähter Code (siehe EPIC- Konzept) und eine Vielzahl von Dialekten, die garantiert inkompatibel zueinander sind.

Der Vorteil liegt lediglich meiner Meinung darin, dass ohne Tricks alle Register/Funktionseinheiten transparent vorliegen.

Zur Sinnahaftigkeit solch eines nackten Codes stimme ich dir aber zu, das Karma der Kompatibelität wiegt schwer... sehr schwer... deswegen konnte x86 ja alles plattmachen.

zeckensack

2003-12-01, 13:52:18

Original geschrieben von Bokill
@zeckensack
Dein Beitrag war wirklich gut..., jedoch entfällt ja eine komplette Ausführungseinheit, die Engine welche den x86 Code umwandelt in die jeweilige "Familiensprache".

Eigentlich müsste daher doch die Nackte CPU dann schneller sein, der Nachteil ist jedoch aufgeblähter Code (siehe EPIC- Konzept) und eine Vielzahl von Dialekten, die garantiert inkompatibel zueinander sind.

Der Vorteil liegt lediglich meiner Meinung darin, dass ohne Tricks alle Register/Funktionseinheiten transparent vorliegen.

Zur Sinnahaftigkeit solch eines nackten Codes stimme ich dir aber zu, das Karma der Kompatibelität wiegt schwer... sehr schwer... deswegen konnte x86 ja alles plattmachen. Tjajo :)
Btw, wenn der Befehlssatz wirklich schnuppe ist, würde ich statt einer 'nackten' CPU direkt zu einer 'halbnackten' Architektur ala PPC raten. Dann hat man auch die garantierte Abwärtskompatibilität der nächsten Generation zurückgewonnen.

Muh-sagt-die-Kuh

2003-12-01, 14:41:14

Original geschrieben von zeckensack
Dafür braucht AMD64 statt drei Bits nun (im Mittel) sieben Bits, um die Register zu addressieren. Nicht daß das enorm viel wäre, aber das ist halt ein Tradeoff, den man berücksichtigen muß.
Und nein, die bezifferten 10~15% Mehrleistung (im echten Leben wohl eher 5%) halte ich nicht wirklich für eine schlagkräftige Demonstration von "zu wenig ISA-Register".

Man schaue sich nur mal den 6502 mit seinen zweieinhalb GP-Registern an. Das ist eine echte Register-Verklemmung.Man muss aber auch beachten, dass AMD 64 Compiler noch nicht die Reife von IA-32 Compilern haben, ich zumindest sehe hier noch Steigerungsmöglichkeiten.
Sicher, mit 8 Registern kann man klarkommen, knappe Resourcen erfordern aber einen überproportional hohen Entwicklungsaufwand bei Compilern um trotzdem auf hohe Leistung zu kommen. 32 GPRs sehe ich persönlich als einen guten Mittelwert zwischen Verwaltungsoverhead und sinnvoller Nutzung an.
Jein. RR kann helfen, Instruktionen zu überlappen und senkt Latenzen. Ohne RR bleibt diese Bürde dem Compiler überlassen (der das nicht wirklich kann - Stichwort "dynamische branches").
Selbst die PPCs mit ihrer "RISC"-ISA, 32 Registern und drei-Operanden-Form machen noch RR. Ich habe auch nicht gesagt, dass RR mit mehr GPRs wegfällt, sondern nur, dass man mit weniger Überlappungen zu kämpfen hat, außerdem spart man eine ganze Menge Push/Pop Operationen ein.

micki

2003-12-01, 16:24:22

[SIZE=1]Original geschrieben von zeckensack
Ein großer Vorteil von x86-Code ist die variable Instruktionslänge, der Code ist dadurch sehr kompakt und spart somit Bandbreite und Cache-Größe.
Der offensichtliche Nachteil ist die Notwendigkeit zur Dekodierung, das Silizium dafür ist allerdings bereits in den Prozessoren vorhanden, womit das Problem als gelöst betrachtet werden kann. Würde man die x86-Decoder nicht nutzen, hätte man lediglich einen Haufen brachliegende Transistoren 'gewonnen'.

da kann man dir ARM cpus wohl gut anführen, denn die kann man mit ARM-befehlssatz und mit Thumb-Befehlssatz (komprimierter ARM-B.), ARM ist das schnellste, thumb hat ca 50% performance und das neue Thumb2 soll 95% der ARM performance erreichen, mich würde es nicht wundern wenn in einigen fällen, wo die bandbreite das limit ist, Thumb2 in führung liegt. codecompression bei der resource und intern RISC find ich persönlich auch als schlauste möglichkeit.

was gegen viele register spricht, ist zum teil der taskwechsel. servercpus die stumpf ohne taskwechsel möglichst viel rechnen müssen, bei denen ist es gut viele register zu haben. aber bei desktop-cpus, die dauernt hunderte von USB,graka,sound,... interrupts auffangen müssen und noch in mehreren threads laufen, da ist es performancenmindernd viele register zu haben. da ist ein intelligentes handling innerhalb der cpu wohl besser.

MfG
micki

AchtBit

2003-12-01, 17:09:30

Original geschrieben von Herr Doktor Klöbner
Hallo ,
wenn ich die Sache richtig verstanden habe sind aktuelle x86 Prozessoren nichts anderes als in Hardware gegossene Emulatoren für den Intel 80386 Prozessor die dessen Befehlssatz ( samt Erweiterungen )für den eigentlichen Prozessorkern , einen sehr viel moderneren Risc Prozessor mit wesentlich mehr Registern , übersetzen.
Meine Frage ist nun folgende : wäre es möglich zum Beispiel eine P4 oder Athlon XP Variante zu entwickeln bei der ich diesen " Übersetzer " deaktiviere und den Softwareentwicklern die Möglichkeit geben würde direkt Code für " das wahre Ich " dieser Prozessoren zu programmieren ? Würde das überhaupt merkliche Geschwindigkeitsvorteile bringen ? Wäre Software mit einem Mischmasch aus x86 Code und "echten" p3/p4/k6/Athlon Code ( nicht identisch , proplematisch , ich weis ) überhaupt schneller oder würde das Umschalten zwischen den beiden Betriebszuständen endlos dauern und unterm Strich jede Software eher ausbremsen ?
Sollte ich jetzt eine oder mehrere dumme Fragen gestellt haben bitte ich um Entschuldigung , bin halt kein Hardwareingenieur sondern gelernter Kaufmann dessen letzes Assemblerprogramm in 6502 Maschinensprache ertellt wurde ( Da war der noch up to date und der HSV war Meister )

Jup, es sind Emulatoren.
Wurdest Du das Mapping fuer den Risc Opcode deaktivieren, dann haettest Du im Kern nur 14 80x86 Register zur Verfuegung, etwas mehr als die Haelfte der ansonsten 32 RISC Register. Das wuerde die CPU brutal bremsen, es sei den Du schreibst den Code in reinem 16bit asm, was aber bei komplexen Programmen bis zur naechsten Steinzeit dauern wuerde. Zudem wird ab dem P4 die Compilierung bereits vor dem Lv1 Cache vorgenommen, so dass sich im Lv1 Cache bereits der fertige Risc Opcode befindet.

würde das Umschalten zwischen den beiden Betriebszuständen endlos dauern und unterm Strich jede Software eher ausbremsen ?

Das ausserdem. Damit wuerdest Du wahrscheinlich nen Farcall erzeugen der zum Pipline Stall fuehrt. Koenntest sogar die CPU damit abrauchen lassen.

Muh-sagt-die-Kuh

2003-12-01, 17:51:47

Original geschrieben von micki
was gegen viele register spricht, ist zum teil der taskwechsel. servercpus die stumpf ohne taskwechsel möglichst viel rechnen müssen, bei denen ist es gut viele register zu haben. aber bei desktop-cpus, die dauernt hunderte von USB,graka,sound,... interrupts auffangen müssen und noch in mehreren threads laufen, da ist es performancenmindernd viele register zu haben. da ist ein intelligentes handling innerhalb der cpu wohl besser.

MfG
micki Gegenüber dem Aufwand, den ein Prozesswechsel sonst noch erfordert ist der Aufwand für das Sichern der architekturalen Register (auch wenn es 32 64 bit Register sein sollten), meiner Meinung nach, fast schon vernachlässigbar.

MeLLe

2003-12-01, 23:43:37

Original geschrieben von AchtBit
Jup, es sind Emulatoren.
Jein. Siehe dazu oben!

Original geschrieben von AchtBit
Wurdest Du das Mapping fuer den Risc Opcode deaktivieren, dann haettest Du im Kern nur 14 80x86 Register zur Verfuegung, etwas mehr als die Haelfte der ansonsten 32 RISC Register.
Ich habe mal die mir sich noch nicht ganz erschliessenden Pünktchen markiert ...

Original geschrieben von AchtBit
Das wuerde die CPU brutal bremsen, es sei den Du schreibst den Code in reinem 16bit asm, was aber bei komplexen Programmen bis zur naechsten Steinzeit dauern wuerde.
Dafür gibt es ja Compiler, die jeder profitbedachte CPU-Bauer den Entwicklern zur Hand gibt!

Original geschrieben von AchtBit
Zudem wird ab dem P4 die Compilierung bereits vor dem Lv1 Cache vorgenommen, so dass sich im Lv1 Cache bereits der fertige Risc Opcode befindet.
Und warum tut man das? Das decodieren geht am Ende imho schneller als das Ausführen des decodeten Materials, da wäre es sinnvoller die "rohen" noch unkodierten Anweisung in jeglichen 1st-, 2nd- oder 3rd-Level-Caches zu haben.

Original geschrieben von AchtBit
Das ausserdem. Damit wuerdest Du wahrscheinlich nen Farcall erzeugen der zum Pipline Stall fuehrt. Koenntest sogar die CPU damit abrauchen lassen.
Ist ein Pipeline-Stall nicht so etwas wie zusätzliche Wait-states, damit die Pipeline leer läuft, bevor sie wieder gefüllt werden kann? Wie kann die CPU beim Warten abrauchen?

Muh-sagt-die-Kuh

2003-12-02, 00:03:44

Original geschrieben von MeLLe
Und warum tut man das? Das decodieren geht am Ende imho schneller als das Ausführen des decodeten Materials, da wäre es sinnvoller die "rohen" noch unkodierten Anweisung in jeglichen 1st-, 2nd- oder 3rd-Level-Caches zu haben.
Man verkürzt den kritischen Ausführungspfad um einige Pipelinestufen und spart sich eine Menge Transistoren für parallele Decoder, dazu erfüllt der Trace-Cache auch noch Branch-Prediction Funktionen.

Xmas

2003-12-02, 04:25:46

Original geschrieben von AchtBit
Zudem wird ab dem P4 die Compilierung bereits vor dem Lv1 Cache vorgenommen, so dass sich im Lv1 Cache bereits der fertige Risc Opcode befindet.
Dies nennt man üblicherweise Decodierung, nicht Kompilierung.

Das ausserdem. Damit wuerdest Du wahrscheinlich nen Farcall erzeugen der zum Pipline Stall fuehrt. Koenntest sogar die CPU damit abrauchen lassen.
Ein Far Call ist der Aufruf einer Prozedur in einem anderen Codesegment. Ich weiß nicht wie du darauf kommst dass die CPU eine solche Anweisung erzeugen kann. Noch weniger, warum sie deswegen "abrauchen" sollte.

AchtBit

2003-12-03, 12:36:39

Original geschrieben von MeLLe
Jein. Siehe dazu oben!

Kann man drueber streiten. Solang kein Hersteller seine Core normen kann, bleibt es fuer mich ein Emulator.

Original geschrieben von MeLLe
Dafür gibt es ja Compiler, die jeder profitbedachte CPU-Bauer den Entwicklern zur Hand gibt!

Ich weis schon was Du sagen willst, jeder x86er ab dem Pentium verwendet eine spezifische RISC Core von der keine architekturischen Details enthuellt sind.
Ist klar, jeder Konzern kocht hier seine eigene Suppe. Der ausgelagerte Compiler von Intel im P4 hat damit aber nichts zu tun, sondern war hoechstwahrscheinlich notwendig.
Zur Compilierung waeren nur 2 ALU's verfuegbar, bei den vorhergehenden Modellen waren es 3. Ich nehm an Intel wollte hier Transistoren sparen. Die zwei doppelt getakteten ALUs sind zwar fuer Datenstreams so schnell wie 4, nicht aber bei intensiven math. Operationen.

Original geschrieben von MeLLe
Ist ein Pipeline-Stall nicht so etwas wie zusätzliche Wait-states, damit die Pipeline leer läuft, bevor sie wieder gefüllt werden kann? Wie kann die CPU beim Warten abrauchen?

Die neueren Intel Prozessoren(ab Choppermine, glaub ich) sind aufgrund des spekulativen Cache Controllers nicht so anfaellig dagegen aber ich hab irgendwann mal gelesen, dass sich bestimmte Zugriffskombinationen auf Steuer - und Statusregister problematisch auf jeweilige CPU Typen auswirken koennen.

Original geschrieben von Xmas
Dies nennt man üblicherweise Decodierung, nicht Kompilierung.

Ohne auf die Uebersetzung des Codes einzugehen. Der Code fuer den P4 wird vor dem Lv1 Cache mit einem ausgelagerten Compiler gruppiert und sortiert. Vorher war der Compiler fest in der Recheneinheit und benutzte die ALUs und FPUs fuer die Gruppierung und Sortierung.
Man koennte auch sagen, nach dem Prinzip eines Compilers, das Ding verwendet einen Compiler Compiler.

Theoretisch waer es moeglich die CPU auf Risc Ebene zu programmieren. Voraussetzung waere zum einem eine angepasste Plattform u. z. a. Kenntnis ueber den Befehlssatz.
Der P4 erlaubt aber nicht die volle Kontrolle, sondern er aendert ausserdem den Code um ihn auf seine Cacheline anzupassen.

ShadowXX

2003-12-03, 13:13:10

Original geschrieben von AchtBit
Kann man drueber streiten. Solang kein Hersteller seine Core normen kann, bleibt es fuer mich ein Emulator.

Jeder Hersteller für sich hat seine Core's durchaus "genormt".
Davon abgesehen: Was hat der Begriff "Emulator" deiner Meinung nach mit "genormten" Core's zu tun?

Ich weis schon was Du sagen willst, jeder x86er ab dem Pentium verwendet eine spezifische RISC Core von der keine architekturischen Details enthuellt sind.
Ist klar, jeder Konzern kocht hier seine eigene Suppe. Der ausgelagerte Compiler von Intel im P4 hat damit aber nichts zu tun, sondern war hoechstwahrscheinlich notwendig.
Zur Compilierung waeren nur 2 ALU's verfuegbar, bei den vorhergehenden Modellen waren es 3. Ich nehm an Intel wollte hier Transistoren sparen. Die zwei doppelt getakteten ALUs sind zwar fuer Datenstreams so schnell wie 4, nicht aber bei intensiven math. Operationen.

Nochmal: Compilieren und Decodieren sind zwei paar verschiedene Schuhe.
Ein Compiler übersetzt (zum Beispiel) ein C-Programm in x86 Code...
Der Decoder innnerhalb der CPU zerlegt den x86-Code, in für den RISC-Kern verständliche micro-ops.

Davon abgesehen glaube ich nicht das Intel jemals seine ALUs zum Decoden von x86-Code in micro-ops benutzt hat ( AMD wohl auch nicht;D ).

Was du (sehr wahrscheinlich) mit "ausgelagertem Compiler" meinst ist, dass der P4 bestimmten Code lieber mag als anderen.
OOO ist nämlich nicht gerade die Stärke des P4, deshalb hat Intel für den P4 einen neuen Compiler rausgegeben, der bei der Codeerzeugung tunlichst darauf achtet, dass möglichst kein/wenig OOO auftritt...

Aber ja...das haben Sie durchaus deshalb gemacht um Transistoren zu sparen....

Die neueren Intel Prozessoren(ab Choppermine, glaub ich) sind aufgrund des spekulativen Cache Controllers nicht so anfaellig dagegen aber ich hab irgendwann mal gelesen, dass sich bestimmte Zugriffskombinationen auf Steuer - und Statusregister problematisch auf jeweilige CPU Typen auswirken koennen.
[QUOTE]

Jo...der alte PIII hatte sogar ein arges Stallproblem.
Aber weder der P4-Kern, noch der vom Banjas haben noch sehr viel mit den alten Coppermine-Kernen zu tun....
Du zielst wieder auf OOO ab...allerdings ohne es zu wissen.

[QUOTE]
Ohne auf die Uebersetzung des Codes einzugehen. Der Code fuer den P4 wird vor dem Lv1 Cache mit einem ausgelagerten Compiler gruppiert und sortiert. Vorher war der Compiler fest in der Recheneinheit und benutzte die ALUs und FPUs fuer die Gruppierung und Sortierung.
Man koennte auch sagen, nach dem Prinzip eines Compilers, das Ding verwendet einen Compiler Compiler.

Wenn dem so wäre, wäre der P4 auch mit 100Ghz nichz wirklich konkurenzfähig...
Du wirfst Branch Prediction, OOO und etliches anderes zusammen und "erklärst" es über "ausgelagerte" Compiler....
Wohin ist dein P4-Compiler-Compiler ausgelagert??
L2-Cache, Hauptspeicher??

Ich verstehe durchaus was du Erklären willst...und das Grundprinzip ist auch "richtig" (auch wenn ich jetzt bestimmt von unseren CPU-Gurus für diese Aussage gehenkt werde)...aber die Vorstellung von dem wo, wie und von wem wann was und warum gemacht wird ist bei dir zum Teil Grundlegend falsch....

J.S.Shadow

P.S.
Ich bin nicht nicht nur studierten Informatiker, sondern auch noch ausgebildeter Anwendungsentwickler und Programmiere seit ca. 20 Jahren auf allen möglichen CPUs mit allen möglichen Sprachen.....
Nur falls wieder einer deiner ...ach ein Studi...ach ein was weiss ich kommen sollte....

Muh-sagt-die-Kuh

2003-12-03, 15:55:29

Original geschrieben von AchtBit
Ich weis schon was Du sagen willst, jeder x86er ab dem Pentium verwendet eine spezifische RISC Core von der keine architekturischen Details enthuellt sind.Falsch, der Pentium (P5) hatte noch keinen RISC Core, der kam erst mit dem P6.Ist klar, jeder Konzern kocht hier seine eigene Suppe. Der ausgelagerte Compiler von Intel im P4 hat damit aber nichts zu tun, sondern war hoechstwahrscheinlich notwendig.Decoder, nicht Compiler.Zur Compilierung waeren nur 2 ALU's verfuegbar, bei den vorhergehenden Modellen waren es 3. Ich nehm an Intel wollte hier Transistoren sparen. Die zwei doppelt getakteten ALUs sind zwar fuer Datenstreams so schnell wie 4, nicht aber bei intensiven math. Operationen.Irgendwie habe ich nach diesem Absatz das Gefühl, dass du von CPUs nicht wirklich ahnung hast...was da steht ist einfach nur zusammenhangsloses Gerede.Die neueren Intel Prozessoren(ab Choppermine, glaub ich) sind aufgrund des spekulativen Cache Controllers nicht so anfaellig dagegen aber ich hab irgendwann mal gelesen, dass sich bestimmte Zugriffskombinationen auf Steuer - und Statusregister problematisch auf jeweilige CPU Typen auswirken koennen.Coppermine bitte, es geht hier um keine Harley ;)

Und was soll bitte ein "spekulativer Cache-Controller" sein? Deine eigene Wortkreation für eine Prefetching-Einheit? Was danach kommt ist wieder vollkommen konfus...Ohne auf die Uebersetzung des Codes einzugehen. Der Code fuer den P4 wird vor dem Lv1 Cache mit einem ausgelagerten Compiler gruppiert und sortiert. Vorher war der Compiler fest in der Recheneinheit und benutzte die ALUs und FPUs fuer die Gruppierung und Sortierung.
Man koennte auch sagen, nach dem Prinzip eines Compilers, das Ding verwendet einen Compiler Compiler.Autsch, wenn man keine Ahnung hat ist es manchmal besser, einfach ruhig zu sein.Theoretisch waer es moeglich die CPU auf Risc Ebene zu programmieren. Voraussetzung waere zum einem eine angepasste Plattform u. z. a. Kenntnis ueber den Befehlssatz.
Der P4 erlaubt aber nicht die volle Kontrolle, sondern er aendert ausserdem den Code um ihn auf seine Cacheline anzupassen. Ähm....der letzte Satz gibt mir endgültig den Rest, mach dir vielleicht erstmal die Bedeutung von einigen Begriffen klar, bevor du sie verwendest ;)

Muh-sagt-die-Kuh

2003-12-03, 15:57:49

Original geschrieben von ShadowXX
Ich verstehe durchaus was du Erklären willst...und das Grundprinzip ist auch "richtig" (auch wenn ich jetzt bestimmt von unseren CPU-Gurus für diese Aussage gehenkt werde)...aber die Vorstellung von dem wo, wie und von wem wann was und warum gemacht wird ist bei dir zum Teil Grundlegend falsch....
<= baut schon mal den Galgen auf *eg* ;)

Aquaschaf

2003-12-03, 16:25:17

Hier bahnt sich wieder etwas interessantes an :D

ShadowXX

2003-12-03, 17:02:53

Original geschrieben von Muh-sagt-die-Kuh
<= baut schon mal den Galgen auf *eg* ;)

Ok ok...das "richtig" war schon zuviel, weiss ich.

Ich konnte aus seinen "Text" halbwegs herauslesen, was er so aufgeschnappt hatte...nur seine Interpretation dessen war natürlich völlig falsch...

Aber ich stelle mich trotzdem freiwillig unter die Motorsäge:

:chainsaw:

Gruß,
J.S.Shadow

BlackBirdSR

2003-12-03, 17:16:38

manchmal wundere ich mich wirklich...

das ist jetzt nicht böse gemeint, aber manche Leute schmeissen nur so mich Fachbegriffen und Internas um sich, so dass man meinen müsste, sie hätten sich mit der Sache beschäftigt.
Dann kommt aber ein zusammenhangsloses Zeugs dabei raus, das zudem noch falsch ist, dass man sich nur noch fragen kann: Wie kommen die an diese Begriffe?
Oder ist das Absicht?

Bokill

2003-12-03, 17:46:35

Glaube ich nicht!

Viele beschäftigen sich hobbymässig damit... gilt auch für mich.

Is bestimmt ein Unterschied so etwas per Forum und Dokus herauszuziehen als von der Lehrbank...

Da sollte man ruhig gnädig sein.

Hier im Forum wird mir zuviel zu gerne herumgechoppt, einige machen mit Freuden noch die Kettensäge schön stumpf damit der Schnitt in das Fleisch auch wirklich schön schmerzhaft ist, andere stehen genüsslich dabei und haben schon Kies und Steine zur Steinigung...

oder halten schmutziges Salz in den Händen, damit die Wunden schön nachbrennen und nicht verheilen...

zeckensack

2003-12-04, 13:31:15

Original geschrieben von Aquaschaf
Hier bahnt sich wieder etwas interessantes an :D Ya ;(
:karate:
Original geschrieben von AchtBit
Jup, es sind Emulatoren.
Wurdest Du das Mapping fuer den Risc Opcode deaktivieren, dann haettest Du im Kern nur 14 80x86 Register zur Verfuegung, etwas mehr als die Haelfte der ansonsten 32 RISC Register.Wie kommst du auf 32? :|
Außerdem, man kann nicht einfach nur den Decoder abschalten, man muß auch eine Möglichkeit haben, nativen Code durchzuschleusen. Und daß dieser eingeschleuste native Code weniger Register ansprechen können soll, als der vom Decoder erzeugte native Code, das will mir nun überhaupt nicht einleuchten.
Das wuerde die CPU brutal bremsen,Bitte begründen.es sei den Du schreibst den Code in reinem 16bit asm, was aber bei komplexen Programmen bis zur naechsten Steinzeit dauern wuerde.Was soll das denn jetzt schon wieder? Schreiben wir jetzt nativen Code für den ("RISC"-)Core, der sicher mit mehr als 16 Bit umgehen kann, oder schreiben wir "16bit asm"?
Und wieso ASM? Es gibt für so ziemlich jede Prozessorarchitektur der letzten zwanzig Jahre zumindest C-Compiler. Weder das eine ("16bit"), noch das andere ("asm") hat hier überhaupt irgendeine Relevanz.
Zudem wird ab dem P4 die Compilierung bereits vor dem Lv1 Cache vorgenommen, so dass sich im Lv1 Cache bereits der fertige Risc Opcode befindet.Treffer. Stichwort "trace cache" (wobei ich mich hier wiederholen muß, "compiler" ist eigentlich etwas anderes).
Das ausserdem. Damit wuerdest Du wahrscheinlich nen Farcall erzeugen der zum Pipline Stall fuehrt.Was hat das Code-Format mit far calls zu tun?Koenntest sogar die CPU damit abrauchen lassen.Könnte man eben nicht.
Original geschrieben von Muh-sagt-die-Kuh ...was da steht ist einfach nur zusammenhangsloses Gerede.Ack ;(
Original geschrieben von Bokill
Glaube ich nicht!

Viele beschäftigen sich hobbymässig damit... gilt auch für mich.

Is bestimmt ein Unterschied so etwas per Forum und Dokus herauszuziehen als von der Lehrbank...

Da sollte man ruhig gnädig sein.

Hier im Forum wird mir zuviel zu gerne herumgechoppt, einige machen mit Freuden noch die Kettensäge schön stumpf damit der Schnitt in das Fleisch auch wirklich schön schmerzhaft ist, andere stehen genüsslich dabei und haben schon Kies und Steine zur Steinigung...

oder halten schmutziges Salz in den Händen, damit die Wunden schön nachbrennen und nicht verheilen... Gut gebrüllt, Löwe.

Eine wichtige Funktion dieser Veranstaltung hier ist die Verbreitung von Information aka Wissen.

Damit das funktioniert, braucht man ein günstiges Verhältnis von Nutzsignal zum Rauschboden.
Oder in poetischeren Worten, Wissen muß man sauber halten, sonst kann man es eines Tages nicht mehr von GZSZ unterscheiden.
... oder in Bill Gaytes' Worten, Wissen ist viral. Es vermehrt sich. Halbwissen und Unwissen vermehren sich auch, wenn sie lautstark geäußert auf trockenen Boden fallen.
... oder in konstruktivistischen Worten, Wissen ist subjektiv. Wenn man sich davon überzeugen lässt, daß etwas Wissen ist, dann wird es zu Wissen.
... oder in darwinistischen Worten, wenn das Wissen sich gegen das Halbwissen nicht durchsetzen kann, dann stirbt es aus.

Wie du siehst, es gibt viele schöne Gründe, ab und an mal korrigierend einzugreifen. Das hat mit Boshaftigkeit nichts zu tun.

Hauwech

2003-12-04, 13:47:57

Original geschrieben von zeckensack

*snip*

Gut gebrüllt, Löwe.

Eine wichtige Funktion dieser Veranstaltung hier ist die Verbreitung von Information aka Wissen.

Damit das funktioniert, braucht man ein günstiges Verhältnis von Nutzsignal zum Rauschboden.
Oder in poetischeren Worten, Wissen muß man sauber halten, sonst kann man es eines Tages nicht mehr von GZSZ unterscheiden.
... oder in Bill Gaytes' Worten, Wissen ist viral. Es vermehrt sich. Halbwissen und Unwissen vermehren sich auch, wenn sie lautstark geäußert auf trockenen Boden fallen.
... oder in konstruktivistischen Worten, Wissen ist subjektiv. Wenn man sich davon überzeugen lässt, daß etwas Wissen ist, dann wird es zu Wissen.
... oder in darwinistischen Worten, wenn das Wissen sich gegen das Halbwissen nicht durchsetzen kann, dann stirbt es aus.

Wie du siehst, es gibt viele schöne Gründe, ab und an mal korrigierend einzugreifen. Das hat mit Boshaftigkeit nichts zu tun.

Endgeil!!! :D

DAS ist doch mal ein Grund dicke Sigs wieder zuzulassen :D

ShadowXX

2003-12-04, 14:06:28

Original geschrieben von zeckensack
Was soll das denn jetzt schon wieder? Schreiben wir jetzt nativen Code für den ("RISC"-)Core, der sicher mit mehr als 16 Bit umgehen kann, oder schreiben wir "16bit asm"?
Und wieso ASM? Es gibt für so ziemlich jede Prozessorarchitektur der letzten zwanzig Jahre zumindest C-Compiler. Weder das eine ("16bit"), noch das andere ("asm") hat hier überhaupt irgendeine Relevanz.

Darauf wollte ich erst gar nicht eingehen, weil sich spätestens bei diesem Satz, jedem der auch nur ansatzweise etwas von (heutigen) CPUs versteht, der Magen umdreht bzw. die Zehennägel abfallen....

J.S.Shadow

P.S.
Beim nicht drazf eingehen, meine ich den "Satz" von AchtBit, nicht den von Zeckensack!!!

Bokill

2003-12-04, 15:35:01

Oder in poetischeren Worten, Wissen muß man sauber halten, sonst kann man es eines Tages nicht mehr von GZSZ unterscheiden.
... oder in Bill Gaytes' Worten, Wissen ist viral. Es vermehrt sich. Halbwissen und Unwissen vermehren sich auch, wenn sie lautstark geäußert auf trockenen Boden fallen.
... oder in konstruktivistischen Worten, Wissen ist subjektiv. Wenn man sich davon überzeugen lässt, daß etwas Wissen ist, dann wird es zu Wissen.
... oder in darwinistischen Worten, wenn das Wissen sich gegen das Halbwissen nicht durchsetzen kann, dann stirbt es aus.

Schöne wahre Worte, dagegen hab ich ja auch nichts...

Es geht mir nur um das überfallartige Auskübeln von Häme... man kann nicht alles wissen.

Man kann aber von Wissensquellen ferngehalten werden. Man kann sich mit Dummheit die Pfoten verbrennen, nur muss man als Medizin gleich die ganze Hand abhacken?

Wo 3 Richtigstellungen reichen, braucht es meiner Meinung nach nicht noch weiterer 3 korrekter Kommentare... da leidet auch die Übersicht und der Inhalt darunter.

Ansonsten kann ich nur bestätigen, dass man hier viel Gutes erfahren kann.

MFG Bokill

ShadowXX

2003-12-04, 15:39:12

Original geschrieben von Bokill
Schöne wahre Worte, dagegen hab ich ja auch nichts...

Es geht mir nur um das überfallartige Auskübeln von Häme... man kann nicht alles wissen.

Man kann aber von Wissensquellen ferngehalten werden. Man kann sich mit Dummheit die Pfoten verbrennen, nur muss man als Medizin gleich die ganze Hand abhacken?

Wo 3 Richtigstellungen reichen, braucht es meiner Meinung nach nicht noch weiterer 3 korrekter Kommentare... da leidet auch die Übersicht und der Inhalt darunter.

Ansonsten kann ich nur bestätigen, dass man hier viel Gutes erfahren kann.

MFG Bokill

Ich will da jetzt auch nicht weiter drauf eingehen, aber wie man so schön sagt:

Wie man in den Wald hineinruft, so schallts auch wieder herraus....

(anders gesagt: es war nicht die erste Auflistung von "Merkwürdigkeiten, die 8Bit hier gepostet hat und er war damals nicht gerade freundlich zu uns bei seinen Antworten...
Ja...ich weiss, ist Kindisch...aber sind wir Männer nicht alle noch irgendwie Kinder...)

J.S.Shadow

Bokill

2003-12-04, 16:05:34

ahhhh... das erklärt einiges...
dann stehen einige auf Handamputationen bei ganz milden Verbrennungen...

Wo ist das schmutzige Salz?

ShadowXX

2003-12-04, 16:22:38

Original geschrieben von Bokill
ahhhh... das erklärt einiges...
dann stehen einige auf Handamputationen bei ganz milden Verbrennungen...

Wo ist das schmutzige Salz?

http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=106993

Haarmann

2003-12-06, 09:45:57

Setzen wir mal den Fall, dass jemand nen x86 im Realmode mit allen Präfixen nutzt und somit auch auf alle 4GB zugreiffen kann (natürlich nur, wenn se auch vorhanden sind), aber sich den ganzen Protected Mode Mist (dafür werde ich wohl gehängt) erspart, der natürlich Rechenleistung frisst oder mindestens bei 386ern viel Power frass und auch Heute noch nicht ohne Tabellen usw auskommt (Jede Page hat so ihre "Flags") - wieviel Mehrleistung wäre da erreichbar? Ich weiss nicht, ob sich damit überhaupt je wer beschäftigt hat, aber ich finde, dass inzwischen die Betriebssystem, auch Linux, so viele kleine Sicherheitslöcher haben, dass man sich mal überlegen müsste, ob man diese dadurch nur noch vorgegaukelte Sicherheit durch Speicherschutz, wieder abschaffen will...

Ist natürlich etwas OT, weils ne andere Form von "nativer" Programmierung ist, aber die grundlegende Frage dahinter ist imho interessant. Wieviel Leistung würdet ihr abgeben um diesen Specherschutz, der nur vor böswilligen Programmen schützt resp schlecht programmierten, welche auch jetzt schon euren Rechner lahmlegen können?

P.S. Ich bin nach wie vor ein Begeisterter Swapdateiabschalter, auch wenn unter Windows dann subst nicht mehr geht ;).

aths

2003-12-06, 11:36:58

Paging und Swapping sind doch tolle Mechanismen. Lehnst du dich hier "aus Prinzip" gegen das "Establishment" auf? Geschwindigkeit ist nicht alles, die "Vergeudung" hier ist sogar ziemlich unwichtig wenn man das Moorsche Gesetz bedenkt, Auf- und Abwärtskompatibilität zu bewahrten, erscheint mir deutlich sinniger. Speicherschutz ist per se eine nützliche Einrichtung.

Quasar

2003-12-06, 11:43:58

Mal abgesehen davon, daß dieser Thread anscheinend genauso unterhaltsam werden wird, wie der "Tabula-Rasa"-Thread, heißt es 'Establishment' und nicht "Etablissement" (oder hast du das nur zitiert, aus deinen Anführungszeichen geht das nich eindeutig hervor).

Establishment deshalb, weil man sich 'aus Prinzip' gegen etwas etabliertes, im englischen 'established' auflehnt.

aths

2003-12-06, 11:52:40

"Never correct me in the public again!!" http://www.aths.net/files/smilies/devil.gif

(Das ist ein Zitat.)

(Und nicht ernst gemeint. Ob ich in der Öffentlichkeit auf Fehler aufmerksam gemacht werde, oder privat, ist mir egal.)

Haarmann

2003-12-06, 13:12:40

aths

"Paging und Swapping sind doch tolle Mechanismen."

Also ich frage mal wieder dezent - wieso sind die so toll? Weil man nun PRGs noch mieser und schuseliger schreiben kann? Ein RAM hat ca 50ns Zugriffszeit und eine Festplatte ca 10ms+ (Zugriff ned Seek). Beim Auslagern geht dementsprechend eh CPU-Zeit flöten. Ob das nun ne Temp Datei ist bei Bedarf, oder ne Swap, in die, wie bei Windows, sehr viel eingelagert wird, das ist imho nicht wirklich zentral. Man kann auch nen Temp Space auf der HD reservieren, falls das so wichtig wird. Solange aber alles ins RAM passt, ists bestimmt nicht falsch es dort zu lassen.
Also beantworte mir mal, was die Vorteile dieser 2 Sachen sind gegenüber einem dedizierten Temp Space, der nicht voll wird, auf ner HD?

"Lehnst du dich hier "aus Prinzip" gegen das "Establishment" auf?"

Ich glaube ich habe nur ne Frage gestellt, weil ich mich schon damals übern Sinn der erneuten Segmentierung gewundert hab - ich bevorzuge nunmal grosse und "flache" Adressräume. Da ich mich zudem vom Amiga her mit Assembler beschäftigt hatte und dies wirklich schön zum Proggen war, versuchte ich Selbiges am Anfang auch aufm PC, wo ich leider aufgrund dieser künstlichen Verkomplizierung, die zudem Zeit frisst und deren Sinn ich selbst nicht erkennen kann, schlicht aufgab und nur noch per Inline ab und an was nutze.

"Geschwindigkeit ist nicht alles, die "Vergeudung" hier ist sogar ziemlich unwichtig wenn man das Moorsche Gesetz bedenkt, Auf- und Abwärtskompatibilität zu bewahrten, erscheint mir deutlich sinniger."

Wenn ich 3GHz habe, dann will ich nicht, dass irgendwas daraus ne Geschwindigkeit macht, die man auch mit 1GHz der selben CPU erreichen könnte... Ich hasse Verschwendung und es ist imho auch ne Frage des Umweltschutzes. Stromverbrauch und Resourcenverbrauch lassen grüssen - aber Wachstum ist ja wichtiger als unser Planet...

"Speicherschutz ist per se eine nützliche Einrichtung."

Bei perfektem Code kann ich Dir da noch zustimmen - zu dumm, dass wir keinen perfekten Code haben. Wo liegen die realen Vorteile?

aths

2003-12-06, 13:28:54

Original geschrieben von Haarmann
aths

"Paging und Swapping sind doch tolle Mechanismen."

Also ich frage mal wieder dezent - wieso sind die so toll? Weil man nun PRGs noch mieser und schuseliger schreiben kann? Ein RAM hat ca 50ns Zugriffszeit und eine Festplatte ca 10ms+ (Zugriff ned Seek). Beim Auslagern geht dementsprechend eh CPU-Zeit flöten.Sobald ein Task die Platte will, wird er schlafen gelegt, und der nächste Task kommt auf die CPU. Gilt für Dateizugrffe alle Art.

Ein OS kann nicht sicher sein, für jede Anwendung genügend physikalischen RAM anbieten zu können. Dank Paging und Swapping wird dieses Problem sehr entschärft.

Original geschrieben von Haarmann
Also beantworte mir mal, was die Vorteile dieser 2 Sachen sind gegenüber einem dedizierten Temp Space, der nicht voll wird, auf ner HD?Was heißt bei dir jetzt "dedizierter Temp-Space"?? Swapping erfolgt für die Anwendung transparent, das ist doch schon mal ein großer Vorteil.

Original geschrieben von Haarmann
Ich glaube ich habe nur ne Frage gestellt, weil ich mich schon damals übern Sinn der erneuten Segmentierung gewundert hab - ich bevorzuge nunmal grosse und "flache" Adressräume. Der "Adressraum" kann dir schnurzpipe sein. Du adressierst ein Array entweder über den Array-Operator, oder via Pointer-Arithmetik. Was da intern abläuft, ist nicht von belang.

Original geschrieben von Haarmann
Da ich mich zudem vom Amiga her mit Assembler beschäftigt hatte und dies wirklich schön zum Proggen war, versuchte ich Selbiges am Anfang auch aufm PC, wo ich leider aufgrund dieser künstlichen Verkomplizierung, die zudem Zeit frisst und deren Sinn ich selbst nicht erkennen kann, schlicht aufgab und nur noch per Inline ab und an was nutze.Hm?? Im Real Mode hast du natürlich noch die 64-KB-Segmentierung in 16-Byte-Schritten. Hat Kompatibilitätsgründe. Ansonsten kannst du doch virtuell "flach" adressieren.

Original geschrieben von Haarmann
Wenn ich 3GHz habe, dann will ich nicht, dass irgendwas daraus ne Geschwindigkeit macht, die man auch mit 1GHz der selben CPU erreichen könnte... Du übertreibst maßlos :)

Original geschrieben von Haarmann
Ich hasse Verschwendung und es ist imho auch ne Frage des Umweltschutzes. Stromverbrauch und Resourcenverbrauch lassen grüssen - aber Wachstum ist ja wichtiger als unser Planet...... hier ebenso.

Original geschrieben von Haarmann
"Speicherschutz ist per se eine nützliche Einrichtung."

Bei perfektem Code kann ich Dir da noch zustimmen - zu dumm, dass wir keinen perfekten Code haben. Wo liegen die realen Vorteile? Im Speicherschutz. Ohne Speicherschutz kann jeder Hans und Franz einen Server zum Absturz bringen. Außerdem steht das System jeglichen Angriffen völlig wehrlos gegenüber... imo ist es eine wirklich dämliche Idee, den Speicherschutz abschaffen zu wollen.

Muh-sagt-die-Kuh

2003-12-06, 13:32:43

Original geschrieben von Haarmann
aths

"Paging und Swapping sind doch tolle Mechanismen."

Also ich frage mal wieder dezent - wieso sind die so toll? Weil man nun PRGs noch mieser und schuseliger schreiben kann? Ein RAM hat ca 50ns Zugriffszeit und eine Festplatte ca 10ms+ (Zugriff ned Seek). Beim Auslagern geht dementsprechend eh CPU-Zeit flöten. Ob das nun ne Temp Datei ist bei Bedarf, oder ne Swap, in die, wie bei Windows, sehr viel eingelagert wird, das ist imho nicht wirklich zentral. Man kann auch nen Temp Space auf der HD reservieren, falls das so wichtig wird. Solange aber alles ins RAM passt, ists bestimmt nicht falsch es dort zu lassen.
Also beantworte mir mal, was die Vorteile dieser 2 Sachen sind gegenüber einem dedizierten Temp Space, der nicht voll wird, auf ner HD?Paging und Swapping läuft hardwareunterstützt (MMU), was prinzipiell besser als eine Software-Lösung ist. Es wird übrigens nicht geswappt, solange noch freier Speicher zur Verfügung steht. Für den Programmierer hat es den Vorteil, dass er einfach nur Speicher allozieren und freigeben muss, ohne sich gedanken um den realen Hauptspeicher machen zu müssen.

Durch das Abschalten der Swap-File gewinnst du absolut nichts und es kann vorkommen, dass dein System sich irgendwann über zu wenig Speicher beschwert...Ich glaube ich habe nur ne Frage gestellt, weil ich mich schon damals übern Sinn der erneuten Segmentierung gewundert hab - ich bevorzuge nunmal grosse und "flache" Adressräume. Da ich mich zudem vom Amiga her mit Assembler beschäftigt hatte und dies wirklich schön zum Proggen war, versuchte ich Selbiges am Anfang auch aufm PC, wo ich leider aufgrund dieser künstlichen Verkomplizierung, die zudem Zeit frisst und deren Sinn ich selbst nicht erkennen kann, schlicht aufgab und nur noch per Inline ab und an was nutze.Segmentierung hatte einen einfachen Grund...versuch mal 1 MB Speicher mit nur 16 bit breiten Registern zu adressieren. Der 32 bit Protected Mode unterstützt einfaches, "flaches" Speichermodell."Speicherschutz ist per se eine nützliche Einrichtung."

Bei perfektem Code kann ich Dir da noch zustimmen - zu dumm, dass wir keinen perfekten Code haben. Wo liegen die realen Vorteile? Ohne einen funktionierenden Speicherschutz kann eine amoklaufende Applikation den Kern abschiessen, siehe Win9x im Vergleich zu WinNT....ist dieser Vorteil real genug?

Haarmann

2003-12-06, 14:38:56

aths

"Sobald ein Task die Platte will, wird er schlafen gelegt, und der nächste Task kommt auf die CPU. Gilt für Dateizugrffe alle Art.

Ein OS kann nicht sicher sein, für jede Anwendung genügend physikalischen RAM anbieten zu können. Dank Paging und Swapping wird dieses Problem sehr entschärft."

Da gebe ich Dir vollkommen recht, aber genau da sage ich, dass es eben auch schuselige Programme fördert und zwar, weil man sonst die Programme ja so "bauen" müsste, dass sie sich anpassen. So wird einfach das OS damit "beworfen". Es ist doch viel einfacher die Programme einfach einmal zu optimieren und die Schuld an schwacher Performance der HW in die Schuhe schieben zu können...

"Was heißt bei dir jetzt "dedizierter Temp-Space"?? Swapping erfolgt für die Anwendung transparent, das ist doch schon mal ein großer Vorteil."

Also ein Swapbereich ist ja sowas wie ne "Tempdatei" fürs Betriebsystem. Ich könnte auch jeder Anwendung nen eigenes Swapfeld sprich ne Tempdatei geben, wenn sie dafür Bedarf anmeldet aufgrund der vorhandenen Resourcen. Damit das nicht segmentiert ist, würde mans eben an den Anfang der Platte legen und an einem Stück halten.
Der unterschied ist imho gering und aufgrund der grossen Unterschiede der Performance von Platte/Swap zum RAM wage ich zu Behaupten, dass der Verlust sich im Rahmen hält.

"Der "Adressraum" kann dir schnurzpipe sein. Du adressierst ein Array entweder über den Array-Operator, oder via Pointer-Arithmetik. Was da intern abläuft, ist nicht von belang."

Das mag für ne Hochsprache durchaus gelten, aber ich glaube ich sprach ja von Assembler. Falls das nicht klar war, so hoffe ich, dass es nun klar ist. Um z.B. auf nem Amiga ein Fenster zu öffnen brauchteste aufgrund der "API", wie man das heute nennt, genau eine Zeile Code und kriegtest genau einen Registerwert retour (OK, oben waren die LVOs definiert mit je ner equ Zeile, aber das war quasi ein Include wie eigene Makros). Da gerät man leichter in Versuchung auch grössere Sachen mit Makrosassembler zu schreiben und hat nichtmals soviel Aufwand, wie Du zu Anfang erwartest.
Für gewisse Aufgaben eigent es sich aber dann durchaus den gleichen Bereich mehrfach zu nutzen resp mehrere Arrays "aufeinander zu legen" und diese bei Bedarf z.B. 8, 16, 32 oder 64 bittig anzusprechen. Da ist es praktisch, wenn man flache Räume hat. Wie gesagt rede ich hier nicht von Hochsprachen.

"Hm?? Im Real Mode hast du natürlich noch die 64-KB-Segmentierung in 16-Byte-Schritten. Hat Kompatibilitätsgründe. Ansonsten kannst du doch virtuell "flach" adressieren."

Soweit ich mich entsinne, kann man mit den gleichen Präfixen, mit denen man im "32 Bit Mode" eines i386 statt eax nur ax anspricht auch statt ax eax ansprechen. Da ich das Buch aber nicht hier habe, kann ich den betreffenden Ausdruck und die Codes dazu nicht nachschlagen. Ich kann mich daher durchaus irren.
Virtuel frisst immer Leistung... und genau das will ich ja nicht. Es muss nichtmals im Betrieb einer dafür ausgelegten CPU sein, aber es sind Gatter, die man sich sonst ersparte und die bestimmt nicht beschleunigend wirken.

"Du übertreibst maßlos :)"

Das war nicht für mein BSP hier gedacht, sondern einfach ne globale Feststellung meinerseits, die sich auch auf so Spielereien wie Java und Interpreter etc erweitern lässt. Skripte sind ja wirklich was schönes, aber man übertreibts zZ doch etwas.

"... hier ebenso."

Ich bin da Fundi - wehret den Anfängen und ein Chip frisst seine Energie schon bei der Produktion - wobei dies Heute wohl nicht mehr im gleichen Masse gilt, aber durchaus nocht stimmen mag. Die Energieersparnis, die also aufträte, wenn man das Leben bisheriger Geräte "verlängern" könnte, ist imho immens.

"Im Speicherschutz. Ohne Speicherschutz kann jeder Hans und Franz einen Server zum Absturz bringen. Außerdem steht das System jeglichen Angriffen völlig wehrlos gegenüber... imo ist es eine wirklich dämliche Idee, den Speicherschutz abschaffen zu wollen."

Mit nem Exploit kannst imho auch jeder Hans und Franz - da sehe ich inzwischen keinen grossen Unterschied mehr. Ich bestreite ja auch nicht den Sinn mit perfektem Code - ich bestreite nur den Sinn mit z.B. M$ SW und Co. Würde einem der Rechner einfach mal wieder abkacken, dann müssten die Leute sich wohl weit mehr anstrengen oder ihre Programme würden ziemlich schnell nicht mehr gekauft werden. Damit siehste wohl auch die Intention dahinter.
Wieder zum Vergleich mein Amiga - ausser bei Spielen ist mir das Teil eigentlich nie abgekackt. Ich wage sogar zu sagen, dass mein PC trotz XP oder 2000 Zeitweise weit öfters abgeschmiert ist, denn mein Amiga unter dem letzten Assembler Kickstart (1.3). Unter 2.0, welches C Teile enthielt und doppelt so gross war, gabs dann mehr Problemchen, die aber selten das ganze OS mitrissen. Speicherschutz gab es damals nicht. Aber offensichtlich hielten sich die Leute eher an die Vorgaben bei den Programmen.

Muh-sagt-die-Kuh

Ich weiss und drum fressen solche wahrhaft riesige Teile wie ICQ auch 20MB und mehr Speicher - ich frage mich da immer, was da so gross sein soll. Dagegen ist ein CDR-Win kleiner und kann imho mehr...
Ich sagte ja bereits, dass ich diese Einfachheit nicht für Einfacher, sondern nur bequemer halte - schneller wird dadurch im Schnitt kein PRG.
Und wenn mein Windows XP Taskman nicht lügt, dann sind hier zZ etwa 9MB Kernelspeicher ausgelagert bei über 400MB freiem Platz... Ich weiss echt nicht wozu das dienen soll.

Och schauen wir uns mal an, wie das Motorola beim 68k gelöst hat... 24 Pins aber 32 Bit Register - man kann da natürlich auch 2 16 Bit Register logisch kombinieren, also einfach hinterienanderhängen und schon hätte man von Anfang an 32 Bit Breite gehabt... Da Du sicherlich die CT gelesen hast nehme ich an, das Dir da der Gate A20 Artikel ins Auge stach - da siehste mal, wie blöd die Wintel Welt sein kann und vor allem auch wieso das wo war.
Der 8086 war imho ein einziger grosser Fehler mit seiner 16 Segment/ 16 Offset 32 zu 20 Bit Schnapsidee. Da gibts sicher 10 gute Lösungen für dieses Problem und Intel nahm die Elfte ;).

Wozu sollte ich immer M$ Programme nehmen zum Vergleich? Darf ich auch andere Sachen nehmen? z.B. ein alter Mac? Der schmierte doch auch nur ab, wenn man ihm IE oder Office gab... Kannst mal sonst nen alten ST oder Amiga Nutzer fragen, der damit nicht nur spielte. Es funktionierte wirklich gut ohne.
Das lag ev auch daran, dass das Herz des Betriebsystems nicht im RAM lag, sondern im ROM - dort kann man auch nicht so einfach rumwühlen... Dementsprechend hab ich die Alternative zum "klassischen" Speicherschutz auch schon genannt. In Zeiten von Flashspeichern sollte das nun wirklich kein Problem mehr sein.
Ich weiss nicht, ob Du weisst, wie das OS eines Amigas aufgebaut war, aber ev erinnerst Dich daran oder liest es mal nach. Du wärst erstaunt wie schlau das Ganze war und mit etwas mehr ROM wäre es sogar möglich gewesen das System absurzsicher zu halten ohne "CPU Speicherschutz".

P.S. Imho stelle ich hier nur ne Kosten/Nutzen Frage, die sich erweitern liesse.

Demirug

2003-12-06, 16:22:43

Haarmann,

Speicher ist eine Resource und Resourcen sollten vom System verwaltet werden. Wenn nun der Swap-Speicher pro App verwaltet würde hätte man schnell ein ernsthaftes Problem. Hätte man eine Aggressive App würde die sich vom System so viel "Echten"-Speicher holen wie es nur geht und dann nur das nötigste auslagern. Für die anderen Programme würde dann kaum noch Speicher übrig bleiben. Jetzt können wir aber auch von einer netten App ausgehen die sich nur ein Minimum an echtem Speicher holt und alles andere auslagert. Wenn jetzt noch massenhaft echter Speicher verfügbar wäre verschnekt man Leistung weil die nette App ständig am swapen ist. Die einzige Lösung für das Problem ist das sich die Applikationen untereinader einig werden wer wie viel echten Speicher benutzten darf. Aber was macht man wenn eine App da nicht mitmacht und weiterhin darauf besteht das sie den ganzen Speicher will?

Natürlich sind die gatter für eine MMU die virtuellen Speicher unterstütz erst einmal verschwendet. Nun muss man sich aber die Frage stellen ob in einer Multitasking Umgebung Virtueller Speicher sinnvoll ist oder nicht? IMHO ist es sinnvoll weil man nie wissen kann wie viele Anwendungen jemand starten will. Eine virtuelle Speicherverwaltung ohne CPU unterstützung ist machbar aber ich persönlich habe von sowas die Nase mehr als voll. Zu 16 Bit Dos-Zeiten habe ich sowas einmal programmiert weil mir die 640 KB nicht gereicht haben (32 Bit Dos Extender gab es noch nicht). Es macht echt keinen Spass wenn man jeden Speicherblock vor der Verwendung Looken und danach wieder unlocken muss.

Ich stimme dir allerdings zu das die Tatsache das man Speicher ohne Ende bekommen kann durchaus zur Verschwendung dieses ermutigt.

Speicherschutzt ist doch eine schöne Sache gerade weil Programme nicht perfekt sind. Ich erinnere mich noch an eine App die von 16 Bit Windows auf 32 portiert wurde und dort ein paar Speicherschutz verletzungen ausgelösst hat obwohl sie vorher immer problemlos gelaufen ist. Wie sich dann heraussetellte waren tatsächlich ein paar wilde Zeiger unterwegs die aber nie das Programm selbst abgeschossen haben. Möglicherweise wurden aber manchmal das System oder andere Programme getroffen. Was ich damit sagen will ist das nur wenn man ein Problem nicht bemerkt heisst das nicht das es nicht vorhanden wäre. Es ist sehr wahrscheinlich das wenn Windows keinen Speicherschutz nutzen würde einzelne Programme viel seltener abstürzen würden. Allerdings würde es im Gegenzug mehr merkwürdige und unerklärliche Systemeprobleme geben.

zeckensack

2003-12-06, 16:27:26

Haari,
aufgrund dieses Bildchens grob geschätzt (http://146.82.66.43/news/Opteron_1600x1200.jpg) ist nur ca 1/16 des K8-Dies mit TLBs 'verballert' worden.

Dazu noch dran denken, daß man eine einfache quasi-MMU sowieso braucht, um überhaupt Cache benutzen zu können. Ich empfinde das jedenfalls nicht als Verschwendung.

Das nur, weil du sagtest daß dich auch die verschwendeten Transistoren ärgern.

Daß die MMU im laufenden Betrieb keine Performance zieht, sollte der Vollständigkeit halber natürlich auch erwähnt werden. Das ist nur für single threaded-Programme wirklich richtig, multi threaded kommt's der Realität aber IMO auch noch nahe genug (die TLBs müssen wenn überhaupt nur beim Threadwechsel umgefüllt werden - ca alle 20ms oder so, respektive alle 40Mio Takte, give or take a few).

Als "Beweis" seien hier die dokumentierten Load-Use-Latenzen der L1-D-Caches angeführt: 3 Takte beim K7, 2 Takte beim Pentium 4. Das ist inklusive MMU-'Overhead'.

edit:
Quelle des Bildchens (http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html) | Mehr davon (http://www.chip-architect.com/)

Xmas

2003-12-06, 16:29:48

Haarmann, wenn ich mich recht entsinne bist du doch auch ein eifriger Verfechter von RAD-Tools wie Delphi. Ich bin erstaunt wie gegensätzlich deine Haltung jetzt zu diesem Thema ist.

Muh-sagt-die-Kuh

2003-12-06, 18:12:01

Original geschrieben von Haarmann
Muh-sagt-die-Kuh

Ich weiss und drum fressen solche wahrhaft riesige Teile wie ICQ auch 20MB und mehr Speicher - ich frage mich da immer, was da so gross sein soll. Dagegen ist ein CDR-Win kleiner und kann imho mehr...
Ich sagte ja bereits, dass ich diese Einfachheit nicht für Einfacher, sondern nur bequemer halte - schneller wird dadurch im Schnitt kein PRG.Was du mir hier sagen willst wird mir nicht ganz ersichtlich.Und wenn mein Windows XP Taskman nicht lügt, dann sind hier zZ etwa 9MB Kernelspeicher ausgelagert bei über 400MB freiem Platz... Ich weiss echt nicht wozu das dienen soll.Es spricht prinzipiell nichts dagegen, sehr selten genutzen Kernelspeicher auszulagern um Platz für andere Anwendungen freizuhalten....bei sich selbst weiss das OS, wozu es den Speicher braucht, bei Anwendungen ist dies nicht so.Och schauen wir uns mal an, wie das Motorola beim 68k gelöst hat... 24 Pins aber 32 Bit Register - man kann da natürlich auch 2 16 Bit Register logisch kombinieren, also einfach hinterienanderhängen und schon hätte man von Anfang an 32 Bit Breite gehabt... Da Du sicherlich die CT gelesen hast nehme ich an, das Dir da der Gate A20 Artikel ins Auge stach - da siehste mal, wie blöd die Wintel Welt sein kann und vor allem auch wieso das wo war.
Der 8086 war imho ein einziger grosser Fehler mit seiner 16 Segment/ 16 Offset 32 zu 20 Bit Schnapsidee. Da gibts sicher 10 gute Lösungen für dieses Problem und Intel nahm die Elfte ;).Ein Fehler war die CPU sicherlich nicht, sie hat sich schliesslich durchgesetzt und die, zugegebenermaßen, bescheuerte Adressierung verschwand mit dem 386 auch.Wozu sollte ich immer M$ Programme nehmen zum Vergleich? Darf ich auch andere Sachen nehmen? z.B. ein alter Mac? Der schmierte doch auch nur ab, wenn man ihm IE oder Office gab...Unsauber programmierte Software gibt es immer, nicht nur von MS...genau deswegen braucht man Sicherheitsmechanismen wie Speicherschutz. Kannst mal sonst nen alten ST oder Amiga Nutzer fragen, der damit nicht nur spielte. Es funktionierte wirklich gut ohne.Vielleicht solange man ohne Pointer programmiert hat ;)Das lag ev auch daran, dass das Herz des Betriebsystems nicht im RAM lag, sondern im ROM - dort kann man auch nicht so einfach rumwühlen... Dementsprechend hab ich die Alternative zum "klassischen" Speicherschutz auch schon genannt. In Zeiten von Flashspeichern sollte das nun wirklich kein Problem mehr sein.Damit die CPU ein Programm ausführen kann muss es im RAM liegen und ist damit, ohne Speicherschutz, auch wilden Pointern ausgesetzt, ob das OS nun in einem ROM oder auf Platte gespeichert ist ist vollkommen egal.Ich weiss nicht, ob Du weisst, wie das OS eines Amigas aufgebaut war, aber ev erinnerst Dich daran oder liest es mal nach. Du wärst erstaunt wie schlau das Ganze war und mit etwas mehr ROM wäre es sogar möglich gewesen das System absurzsicher zu halten ohne "CPU Speicherschutz".Ich hatte nie einen Amiga, wenn es dir Spass macht kannst du mir aber gerne eine Quelle geben.

Dass ein ROM als Speicherschutz dienen kann ist, siehe oben, schlicht und einfach falsch.

Demirug

2003-12-06, 18:35:53

Original geschrieben von Muh-sagt-die-Kuh
Dass ein ROM als Speicherschutz dienen kann ist, siehe oben, schlicht und einfach falsch.

Da muss ich Haarmann recht geben. Damals war Speicher noch teuer und deswegen hat man sich das spiegeln des ROMs in das RAM gespart und direkt aus dem ROM geladen. Da die CPUs dann meist auch noch keinen Cache hatten war es technisch nicht möglich da was zu überschreiben. Das System im ROM war also sicher.

zeckensack

2003-12-06, 20:02:09

Original geschrieben von Demirug
Da muss ich Haarmann recht geben. Damals war Speicher noch teuer und deswegen hat man sich das spiegeln des ROMs in das RAM gespart und direkt aus dem ROM geladen. Da die CPUs dann meist auch noch keinen Cache hatten war es technisch nicht möglich da was zu überschreiben. Das System im ROM war also sicher. Die MMU des 386ers konnte auch schon Schreibschutz auf Code-Segmente setzen ;)
Beim Brechen dieser Regeln gibt's eine Exception. Ich kann mir nicht vorstellen, daß bei einem Code-ROM etwas sinnvolleres machbar ist :)

Btw, wie schreibt man ein OS, das ganz ohne variable Daten auskommt? Garnicht? :bäh:

Demirug

2003-12-06, 20:17:29

Original geschrieben von zeckensack
Die MMU des 386ers konnte auch schon Schreibschutz auf Code-Segmente setzen ;)
Beim Brechen dieser Regeln gibt's eine Exception. Ich kann mir nicht vorstellen, daß bei einem Code-ROM etwas sinnvolleres machbar ist :)

Zecki, ich liebe doch den Speicherschutz ich weiss nicht wie oft mich dieses Feature schon vor schlimmerem bewart hat.

Gab es den Speicherschutz nicht sogar schon beim 286?

Btw, wie schreibt man ein OS, das ganz ohne variable Daten auskommt? Garnicht? :bäh:

Ja, OK die Daten kann man noch zerschiessen. Ich sagte ja auch nicht das es 100% sicher ist. Der Speicherschutz durch die CPU kann ja auch unterlaufen werden.

zeckensack

2003-12-06, 20:39:34

Original geschrieben von Demirug
Zecki, ich liebe doch den Speicherschutz ich weiss nicht wie oft mich dieses Feature schon vor schlimmerem bewart hat.Das hast du dir selbst zuzuschreiben: "Da muss ich Haarmann recht geben." :naughty:
Gab es den Speicherschutz nicht sogar schon beim 286?Ja, AFAIR schon. Danke.
Ja, OK die Daten kann man noch zerschiessen. Ich sagte ja auch nicht das es 100% sicher ist. Der Speicherschutz durch die CPU kann ja auch unterlaufen werden. Ja, aber das ist eher unwahrscheinlich. Der Zugriff auf die Segment-Attribute ist ja nur im Kernel-Ring überhaupt möglich ... das 'aus Versehen' hinzukriegen ist IMO ungefähr genauso wahrscheinlich, wie einen Writeback-Cache für ein Code-ROM zu aktivieren und 'aus Versehen' zu benutzen.

:grübel:

Demirug

2003-12-06, 20:50:53

Original geschrieben von zeckensack
Das hast du dir selbst zuzuschreiben: "Da muss ich Haarmann recht geben." :naughty:

Ja, ich sollte aufhören zu programmieren das kann man der Menschheit nicht länger zumuten.

Aber als Sadist sage ich die Menschheit hat Strafe verdient und darum mache ich weiter. Wobei es mit C# verdammt schwer ist Speicherschutzverletzungen zu produzieren. Mit unsafe Blöcken geht es aber noch gut genug

Ja, aber das ist eher unwahrscheinlich. Der Zugriff auf die Segment-Attribute ist ja nur im Kernel-Ring überhaupt möglich ... das 'aus Versehen' hinzukriegen ist IMO ungefähr genauso wahrscheinlich, wie einen Writeback-Cache für ein Code-ROM zu aktivieren und 'aus Versehen' zu benutzen.

:grübel:

Ja, aus Versehen wird das verdamt schwer.

zeckensack

2003-12-06, 20:54:22

Original geschrieben von Demirug
Ja, ich sollte aufhören zu programmieren das kann man der Menschheit nicht länger zumuten.Oh nein, bitte nicht aufhören!

Du mußt dringend noch mindestens ein Spiel zur Marktreife bringen. Aufhören kannst du in zwanzig Jahren auch noch :)

Haarmann

2003-12-07, 11:16:41

Demirug

Du verlagerst hier gerne die Probleme, die Programme verursachen aufs OS. Das genau wollte ich ja mit meinem Ansatz verhindert wissen. Dementsprechend sollte diese Grundregel auch mal zeigen, dass die Programme mehr "Eigenverantwortung" haben sollten und nicht einfach alles aufs OS schieben. Auch beim Speicherschutz sagst Du, dass dies PRG mangelhaft war und es keiner bemerkt hat ohne Speicherschutz. Ohne mangelhaftes PRG wär ja auch kein Problem da gewesen. Wieder diese böse Eigenverantwortung, die imho schon lange abhanden gekommen ist.

So schlimm isses wohl auch nicht, man könnte ja nen Speicherschutz emulieren zu Debugzwecken ...

zeckensack

Kleine Nebenfrage - Wenn man von Ring 3 auf Ring 0 springen will, ist das schneller, gleichschnell oder langsamer als einfach ein normaler, direkter Sprung?

Xmas

Ich rede hier auch von nem grossen Systemwechsel. Mit der Umgebung von PCs, ist jede andere Art etwas zu proggen imho bereits zu langsam. Der Mensch passt sich eben an... auch an solch tragische Sachen wie Wintel Welten.

Muh-sagt-die-Kuh

Ich wollte mal wieder die Eigenverantwortlichkeit von Programmierern hervorheben, die inzwischen verloren ging und jedes Schundprogramm, z.B. mein Mouseicon unten rechts, holt sich soviel Speicher, dass es mir fast schlecht wird vom Hinsehen. Mein alter DOS Maustreiber war etwa gleich mächtig, aber mit 27KB vs heute ~4MB etwas kompakter...

Der Wraparound und der 8086 Mode ist doch noch immer mit drin bei neuen CPUs - der Mist ist also nach wie vor vorhanden.

"Unsauber programmierte Software gibt es immer, nicht nur von MS...genau deswegen braucht man Sicherheitsmechanismen wie Speicherschutz."

Wie wärs mit sauberen Programmen statt Speicherschutz?

"Vielleicht solange man ohne Pointer programmiert hat"

Assembler besteht wohl durchaus aus dem, was Du Pointers nennst, besonders beim 68k sind wohl die Dinger in A0-A7 schlichte Pointers ;).

Demirug

2003-12-07, 12:36:50

Haarmann, natürlich verursachen Programme Probleme (die wir ohne sie gar nicht hätten). Wenn man sich die Restfehler statistiken anschaut kann einem schon durchaus angst werden. Genau aus diesem Grund muss ein gutes OS sich selbst und andere Programme gegeneinader schützen.

Natürlich ist dieser Schutz nur ein Mittel um die Folgen so gering wie Möglich zu halten und lösst das eigentlichen Problem nicht. Aber für das eigentliche Problem hat man bis heute keine Lösung gefunden. Es gibt einfach keine Möglichkeit die Fehlerfreiheit eines Programms nachzuweisen.

Du willst auf Eigenverantwortung setzten? Was ist aber wenn von 100 Programmierer 99 sehr genau aufpassen aber einer nicht und sein Programm regelmässig die anderen abschiesst? Glaubst du das der normale Anwender in der Lage ist dieses eine Programm als Ursache des ganzen zu erkennen? Ich nicht.

Damals. Ja damals war alles besser. Mein C128 ist eigentlich auch nie abgestürzt. Fehler in einzelnen Programmen gab es aber auch. Wilde Zeiger waren damals ein relative unbekanntes Problem weil man kaum mit den dafür notwendigen Strukturen gearbeitet hat. Bei BASIC Programme ging es ja gar nicht und bei Assemblerprogramme hat man sich seine 64K Speicher eben einmal fest eigeteilt und gut war. Dynamische Speicherverwaltung war ein Fremdwort. Feste Speicheraddressen für einzelne Dinge waren noch nie Problem. Kritisch wird es immer wenn an einer Speicheraddresse eine andere Speicheraddresse gespeichert wird und dann auch öfter verändert werden muss.

PS: Mein Maustreiber hier braucht 22KB.

mrdigital

2003-12-07, 13:07:16

Haarmann, ich weiss nicht genau, auf was du hinaus willst. Ich kann gut verstehen, dass du dich ärgerst, wie viel von der potenziellen (Rechen-)Leistung in so einem PC in den verschieden Bereichen versandet, aber die einzige Möglichkeit diese "Verschwendung" zu beenden, wäre den gesammten PC in Handoptimiertem Assembler zu programmieren, aber dann wäre man niemals bei einer solchen Funktionsvielfalt angelankt. So ein doofer PC ist doch eine unglaubliche eierlegende Wollmichsau, wenn man sich mal das mögliche Einstazspektrum ansieht. Und um eben eine solche Funktionsvielfalt zu ermöglichen, braucht man Mechanismen (im OS und auch in der Hardware) die eine schnelle Programmentwickling möglich machen, was wiederum die Assemblerentwicklung ausschliesst (oder eben auf absolut kritische Bereiche beschränkt). Alleine die Möglichkeit verschieden Betriebsysteme einzusetzten ist doch ein fantastischer Innovationsbeschleuniger, weil es dadurch konkurrenz auf Entwicklungsebene gibt, was sonst nicht so wäre. Wenn du einmal einen Microkontroller programmiert hast, dann weisst du was es heisst, wenn man kein OS hat, das man mit lästigen Aufgaben betrauen kann und wie lange es dauert selbst simple Funktionen umzusetzten (ich muss im Moment ein SMTP auf nem µC implementieren und es gibt einen rudimentären TCP/IP Stack ohne dass es ein OS gibt und du glaubst nicht, wie oft man sich ein Windows herwünscht, das einem viele lästige Dinge abnimmt, wie z.B. das TCP Connection Handling...)
Lange Rede, ohne diese Abstahierung (und der damit verbundenen Ineffizienz) wäre eine solche Funktionsvielfalt auf dem PC absolut undenkbar.
Gruss

Muh-sagt-die-Kuh

2003-12-07, 13:26:17

Original geschrieben von Haarmann
Muh-sagt-die-Kuh

Ich wollte mal wieder die Eigenverantwortlichkeit von Programmierern hervorheben, die inzwischen verloren ging und jedes Schundprogramm, z.B. mein Mouseicon unten rechts, holt sich soviel Speicher, dass es mir fast schlecht wird vom Hinsehen. Mein alter DOS Maustreiber war etwa gleich mächtig, aber mit 27KB vs heute ~4MB etwas kompakter...mouclass.sys ist unter Windows XP genau 22 kb groß, siehe Demirug. Ich dachte du stehst so auf Resourcenschonung...wieso schaltest du dann das sinnlose Tray-Dienstprogramm nicht einfach ab?Der Wraparound und der 8086 Mode ist doch noch immer mit drin bei neuen CPUs - der Mist ist also nach wie vor vorhanden.Ja, er ist aus Kompatibilitätsgründen noch vorhanden, wird aber nicht mehr benutzt.Wie wärs mit sauberen Programmen statt Speicherschutz?Es gibt keine sauberen Programme, ab einem gewissen Punkt stimmt das Verhältnis von Aufwand zur Suche von Fehlern und Nutzen der Beseitigung nicht mehr, außerdem kann es immer passieren, dass ein Fehler lange Zeit unbemerkt bleibt.Assembler besteht wohl durchaus aus dem, was Du Pointers nennst, besonders beim 68k sind wohl die Dinger in A0-A7 schlichte Pointers ;). Ich gehe davon aus, dass die meisten Hobbyprogrammierer eine einfache Hochsprache wie Basic benutzt haben, also keine Pointer hatten. Wenn man in Assembler schreibt, ist es kein Problem vollkommen wild mit Pointern zu hantieren und das System oder andere Programme abzuschiessen.

Haarmann

2003-12-07, 14:18:38

Demirug

Sucht man denn für das eigentliche Problem nach ner Lösung? Also ich kann das nicht erkennen bisher.

Ich bin mir ziemlich sicher, dass es Leute geben wird, die dies Program erkennen und es dann nimmer gekauft wird, wenns Alternativen gibt.

Manchmal frage ich mich ehrlich, wo denn der Fortschritt hin ist bei neuen Programmen und Betriebsystemen...

Meine Maus ist ne MX-700 und deren Treiber ist ein Schwergewicht - es reicht ja nicht, wenn nur die normalen Funktionen dieser Maus gehen - das Trayicon ist hierbei nicht relevant...

mrdigital

Ich höre immer Windows hat so und soviele Codezeilen. Wieviele davon beinhalten wohl die Klickibunti Funktionen und Assistenten etc, die nicht notwendig sind? Brauche ich Funktionen wie animierte Mauszeiger und Hintergrundbilder denn wirklich? Wäre mir nicht besser gedient mit ner schnelleren und funktionierenden Umgebung, die Ausnahmsweise mal das tut, was sie tun sollte?

Muh-sagt-die-Kuh

Mein BIOS soll im Realmode funktionieren... Dementsprechend wird der wohl doch noch genutzt.

Vielleicht sollte man sich mal nach den Gründen für die Fehler der Programme auf die Suche machen. Tut man imho nicht.

Mit Interpretersprachensollte es einem auch nicht gelingen nen Rechner abzuschiessen. Betonung auf sollte ;).

GRiNSER

2003-12-07, 14:39:59

Original geschrieben von Haarmann
...
Manchmal frage ich mich ehrlich, wo denn der Fortschritt hin ist bei neuen Programmen und Betriebsystemen...

...

Ich höre immer Windows hat so und soviele Codezeilen. Wieviele davon beinhalten wohl die Klickibunti Funktionen und Assistenten etc, die nicht notwendig sind? Brauche ich Funktionen wie animierte Mauszeiger und Hintergrundbilder denn wirklich? Wäre mir nicht besser gedient mit ner schnelleren und funktionierenden Umgebung, die Ausnahmsweise mal das tut, was sie tun sollte?

...
Der Fortschritt liegt darin, dass Betriebssysteme immer einsteigerfreudlicher werden - dafür braucht man Assistenten, damit es auch den weniger erfahrenen/mit Computer bewanten Leuten möglich ist, sachen zu machen, die du als profi vielleicht per commandozeilen funktionen erledigen würdest...

Klickibunti Funktionen und animierte dinge bringen mehr style auf den desktop und vermitteln eine freundlichere arbeitsweise und gleichzeitig hat das auch was mit lifestyle zutun...

all diese dinge haben dem computer erst zu dem großen durchbruch verholfen, wo Microsoft, wie schlimm der konzern auch ist, einen großen beitrag geleistet hat. früher hätte es das nicht gegeben, das schon in fast jedem haushalt mindestens 1 pc vorhanden ist!

grakaman

2003-12-07, 14:46:41

Matti

2003-12-07, 15:09:54

Original geschrieben von GRiNSER
Der Fortschritt liegt darin, dass Betriebssysteme immer einsteigerfreudlicher werden - dafür braucht man Assistenten, damit es auch den weniger erfahrenen/mit Computer bewanten Leuten möglich ist, sachen zu machen, die du als profi vielleicht per commandozeilen funktionen erledigen würdest...

Klickibunti Funktionen und animierte dinge bringen mehr style auf den desktop und vermitteln eine freundlichere arbeitsweise und gleichzeitig hat das auch was mit lifestyle zutun...

all diese dinge haben dem computer erst zu dem großen durchbruch verholfen, wo Microsoft, wie schlimm der konzern auch ist, einen großen beitrag geleistet hat. früher hätte es das nicht gegeben, das schon in fast jedem haushalt mindestens 1 pc vorhanden ist!
Also einsteigerfreundlich ist Windows beim besten Willen nicht. Damit Windows eine brauchbare Performance bekommt, muß man erst zig Einstellungen ändern, Dienste deaktivieren...
Und daß "persönlich angepaßte Menüs" und dieser ganze Käse einem Einsteiger das Leben leichter machen, kann ich mir nicht vorstellen!

Unter einem einsteigerfreundlichen Betriebssystem verstehe ich folgendes:
-ein von sich aus schon perfekt getuntes Betriebssystem
-es sollte eine optimale Performance erreichen, so daß es auch auf leistungsschwachen Einsteiger-Rechnern flott läuft
-alle System-Einstellungen sollten übersichtlich auf 2-3 Bildschirmseiten erreichbar sein, und nicht wie bei Windows 20 System-Steuerung-Icons, wo jedes wieder 3-4 oder noch mehr Unter-Fenster hat. Selbst ein Profi muß ja bei Windows oft überlegen, wie er zu einer bestimmten Einstellung kommt.
-die Oberfläche sollte selbst-erklärend sein, so daß man kein Handbuch braucht
-bunt und ansprechend soll die Oberfläche natürlich sein, aber nicht mit so viel sinnlosem Schnickschnack, wie bei WindowsXP

Exxtreme

2003-12-07, 15:13:03

Demirug

2003-12-07, 15:19:42

Original geschrieben von Haarmann
Demirug

Sucht man denn für das eigentliche Problem nach ner Lösung? Also ich kann das nicht erkennen bisher.

Ich bin mir ziemlich sicher, dass es Leute geben wird, die dies Program erkennen und es dann nimmer gekauft wird, wenns Alternativen gibt.

Manchmal frage ich mich ehrlich, wo denn der Fortschritt hin ist bei neuen Programmen und Betriebsystemen...

Es gibt da zwei Seiten der gleichen Münze auf der einen Seite sind die Entwickler die sich des Problems durchaus bewusst sind.

Dort sucht man, sogar recht verzweifelt. Bisher erreichte man mit diesen Versuchen aber nur recht bescheidene Teilerfolge die von der steigenden Komplexität der Programme schnell wieder aufgefressen werden.

Aber es gibt auch die andere Seite.

Die Benutzung von völlig unzureichenden Entwicklungsumgebungen trägt natürlich auch iheren Teil dazu bei. Jeder der eine IDE ohne guten Debugger benutzt gehört IMHO einen kräftigen Tritt in den Hintern. Aber viele sogenannte "Entwickler" wissen ja noch nicht einmal was ein Debugger ist und was man damit tut.

Ein grosses Problem ist auch die Tatsache das es heute nicht mehr möglich ist das ein Entwickler aleine ein wirklich grosses Programm schreiben kann. Sobald sich aber Menschen unterhalten kommt es immer wieder zu missverständnissen. Hatte gerade wieder so einen Fall bei dem eine Funktionsbeschreibung von zwei Leuten unterschiedlich interpretiert wurde und deswegen etwas nicht immer richtig funktioniert hat.

Die nächste IDE von MS hat aber wieder ein paar nette Sache um die Komplexität besser in den Griff zu bekommen. Automatische Erzeugung von UML-Diagrammen welche immer den aktuellen Code wiederspiegeln und die Integration von Refaktoriungsfunktionen ist das wirklich sehr hilfreich.

Exxtreme

2003-12-07, 15:20:11

Original geschrieben von Haarmann
Ich höre immer Windows hat so und soviele Codezeilen. Wieviele davon beinhalten wohl die Klickibunti Funktionen und Assistenten etc, die nicht notwendig sind? Brauche ich Funktionen wie animierte Mauszeiger und Hintergrundbilder denn wirklich? Wäre mir nicht besser gedient mit ner schnelleren und funktionierenden Umgebung, die Ausnahmsweise mal das tut, was sie tun sollte?

Bitte nicht von Windows auf andere Betriebssysteme schliessen. :D

Demirug

2003-12-07, 15:23:49

Original geschrieben von Exxtreme
Bitte nicht von Windows auf andere Betriebssysteme schliessen. :D

Wenn du bei Linux alles zusammenzählts was du brauchst um auf den gleichen Funktionumfang wie bei Windows zu kommen bist du in etwa beim gleichen Codeumfang. Das bei Windows auch eine Menge dabei ist was nicht jeder braucht spielt dabei ja ersteinmal eine untergeordnete Rolle.

Exxtreme

2003-12-07, 15:29:09

Original geschrieben von Demirug
Wenn du bei Linux alles zusammenzählts was du brauchst um auf den gleichen Funktionumfang wie bei Windows zu kommen bist du in etwa beim gleichen Codeumfang. Das bei Windows auch eine Menge dabei ist was nicht jeder braucht spielt dabei ja ersteinmal eine untergeordnete Rolle.
Mir ging es weniger um den Codeumfang sondern eher darum, daß es Betriebssysteme gibt, bei denen man viel mehr Einflussmöglichkeiten hat, was alles in den Speicher geladen wird und was nicht. Ist KDE zu fett? Kein Problem, dann nimmt man XFCE oder WindowMaker. Unter Windows kriege ich nicht einmal den, für mich überflüssigen IE aus dem Speicher. Und zum Booten brauche ich sogar eine Grafikkarte. ;)

grakaman

2003-12-07, 15:35:03

Demirug

2003-12-07, 15:36:55

Original geschrieben von Exxtreme
Mir ging es weniger um den Codeumfang sondern eher darum, daß es Betriebssysteme gibt, bei denen man viel mehr Einflussmöglichkeiten hat, was alles in den Speicher geladen wird und was nicht. Ist KDE zu fett? Kein Problem, dann nimmt man XFCE oder WindowMaker. Unter Windows kriege ich nicht einmal den, für mich überflüssigen IE aus dem Speicher. Und zum Booten brauche ich sogar eine Grafikkarte. ;)

Natürlich lässt sich Linux wesentlich besser Rightsizen als Windows. Aber gerade das mancht es für kommerzielle Softwareentwickler nicht gerade sehr verlockend. Mach mal Support für ein System wo du den Kunden erst mal ewig ausfragen musst was für eine Konfiguration er jetzt auf dem Rechner hat. Und wenn der Kunden dann nicht viel Ahnung hat gute Nacht.

Für geschlossene Systeme bei denen der End-Kunde nichts an der Konfiguartion verändern kann gibt es von MS auch ein Windows bei dem man genau festlegen kann welche Teile man haben möchte. Das Teil läuft dann auch ohne Grafikkarte.

grakaman

2003-12-07, 15:37:19

Original geschrieben von Exxtreme
Was kann ein Assistent besser als ein Texteditor? Also ich empfinde Assistenten eher als eine lästige Behinderung meiner Arbeit da man sich durch etlich Dialoge durchklicken muss.

Einen die Arbeit abnehmen und anhand von einigen wenigen Angaben komplette Konfigurationen erstellen.

grakaman

2003-12-07, 15:38:26

Original geschrieben von Demirug
Natürlich lässt sich Linux wesentlich besser Rightsizen als Windows. Aber gerade das mancht es für kommerzielle Softwareentwickler nicht gerade sehr verlockend. Mach mal Support für ein System wo du den Kunden erst mal ewig ausfragen musst was für eine Konfiguration er jetzt auf dem Rechner hat. Und wenn der Kunden dann nicht viel Ahnung hat gute Nacht.

Für geschlossene Systeme bei denen der End-Kunde nichts an der Konfiguartion verändern kann gibt es von MS auch ein Windows bei dem man genau festlegen kann welche Teile man haben möchte. Das Teil läuft dann auch ohne Grafikkarte.

100% Zustimmung.

Exxtreme

2003-12-07, 15:42:49

Original geschrieben von grakaman
Der IE ist nicht überflüssig, weil der z.B. für Hilfesysteme benötigt wird. Und es ist nun mal ungemeint einfach, strukturierte XML Daten in HTML zu konvertieren.
Ich weiss. Aber trotzdem, wieso muss das Teil ständig im RAM bleiben auch wenn es nicht benötigt wird? Die Hilfe rufe ich in den seltensten Fällen auf. Der IE ist ein Riesenbrocken Software, der von vielen Windows-Funktionen und anderen Applikationen genutzt wird. Das Teil schleppt einen riesigen Rattenschwanz an Komponenten, Funktionen etc. mit, die ich persönlich nie brauche, die aber trotzdem zwangsweise im Speicher verbleiben und womöglich Angriffsfläche für Viren, Würmer, Hacker etc. bieten. Das ist IMHO eine Vergewaltigung des Prinzips der modularen Programmierung. Wenn ich einen DB-Server betreibe, für was muss die HTML-Rendering-Engine im Speicher bleiben?

Exxtreme

2003-12-07, 15:48:41

Original geschrieben von Demirug
Natürlich lässt sich Linux wesentlich besser Rightsizen als Windows. Aber gerade das mancht es für kommerzielle Softwareentwickler nicht gerade sehr verlockend. Mach mal Support für ein System wo du den Kunden erst mal ewig ausfragen musst was für eine Konfiguration er jetzt auf dem Rechner hat. Und wenn der Kunden dann nicht viel Ahnung hat gute Nacht.

Dafür gibt es Zertifizierungen. SAP und andere Hersteller machen's ja auch so. Zertifiziert für Distri xyz. Wenn man da wichtige Systemkomponenten durch distributionsfremde ersetzt, verfällt halt der Support. Ist aber unter Windows genauso. Extrem ist es bei Datev. Da reicht schon das falsche Service Pack und der Support wird nicht mehr gewährleistet. Von daher wird sich jeder Admin hüten, da was zu drehen.

grakaman

2003-12-07, 15:50:31

Original geschrieben von Exxtreme
Ich weiss. Aber trotzdem, wieso muss das Teil ständig im RAM bleiben auch wenn es nicht benötigt wird? Die Hilfe rufe ich in den seltensten Fällen auf. Der IE ist ein Riesenbrocken Software, der von vielen Windows-Funktionen und anderen Applikationen genutzt wird. Das Teil schleppt einen riesigen Rattenschwanz an Komponenten, Funktionen etc. mit, die ich persönlich nie brauche, die aber trotzdem zwangsweise im Speicher verbleiben und womöglich Angriffsfläche für Viren, Würmer, Hacker etc. bieten. Das ist IMHO eine Vergewaltigung des Prinzips der modularen Programmierung. Wenn ich einen DB-Server betreibe, für was muss die HTML-Rendering-Engine im Speicher bleiben?

Das hat schon Vorteile, Extreme. Die IE dll enthält z.B. auch Outlook Express. Wenn du nun eine Applikation entwickelst, die Mails empfangen und senden soll und du nicht den Aufwand betreiben willst, einen POP3 Client zu programmieren (ich hab das schon gemacht), dann kannst du einfach über MAPI (RPC) zugreifen. Ansonsten müsstest du nämlich immer erst dein EMail Programm zurvor öffnen. Voraussetzung ist allerdings, dass OE als Standard definiert wurde. Trotzdem macht das vor allem bei automatisierten Anwednungen reichlich sinn, da man auch bei OE die Sicherheitseinstellungen so einstellen kann, dass bei RPC nicht diese Hinweis Message Boxen aufpoppen. Bei O geht das nicht und du brauchst da 3Party Software wie "ClickYes". Das nur mal als Bsp. für ne sinnvolle Anwendung.

MfG

Exxtreme

2003-12-07, 15:51:02

Original geschrieben von grakaman
Einen die Arbeit abnehmen und anhand von einigen wenigen Angaben komplette Konfigurationen erstellen.
Ob ich jetzt 5 Optionen im Assistenten oder direkt im Config-File ändere, was macht es da für einen Unterschied?

Demirug

2003-12-07, 15:52:31

Original geschrieben von Exxtreme
Dafür gibt es Zertifizierungen. SAP und andere Hersteller machen's ja auch so. Zertifiziert für Distri xyz. Wenn man da wichtige Systemkomponenten durch distributionsfremde ersetzt, verfällt halt der Support. Ist aber unter Windows genauso. Extrem ist es bei Datev. Da reicht schon das falsche Service Pack und der Support wird nicht mehr gewährleistet. Von daher wird sich jeder Admin hüten, da was zu drehen.

Du redest hier von Software für Firmen ich bezog mich auf den Homeuser.

grakaman

2003-12-07, 15:54:08

Original geschrieben von Exxtreme
Ob ich jetzt 5 Optionen im Assistenten oder direkt im Config-File ändere, was macht es da für einen Unterschied?

Das macht den Unterschied, dass man im Assistenten vielleicht bloß 5 Optionen anklicken brauch und es werden bedeutend mehr Einstellungen vorgenommen. Es ist ja weiss Gott nicht so, dass 5 Mausklicks immer 5 Zeilen in einer Config bedeuten.

aths

2003-12-07, 15:57:12

Original geschrieben von Matti
Also einsteigerfreundlich ist Windows beim besten Willen nicht. Damit Windows eine brauchbare Performance bekommt, muß man erst zig Einstellungen ändern, Dienste deaktivieren...Eigentlich nicht mehr. Seit Win2000, eigentlich schon seit Win98 ist die Grundeinstellung imo performancemäßig ok.

Original geschrieben von Matti
Und daß "persönlich angepaßte Menüs" und dieser ganze Käse einem Einsteiger das Leben leichter machen, kann ich mir nicht vorstellen! Ich schon :)

Exxtreme

2003-12-07, 15:58:41

Original geschrieben von grakaman
Das hat schon Vorteile, Extreme. Die IE dll enthält z.B. auch Outlook Express. Wenn du nun eine Applikation entwickelst, die Mails empfangen und senden soll und du nicht den Aufwand betreiben willst, einen POP3 Client zu programmieren (ich hab das schon gemacht), dann kannst du einfach über MAPI (RPC) zugreifen. Ansonsten müsstest du nämlich immer erst dein EMail Programm zurvor öffnen. Voraussetzung ist allerdings, dass OE als Standard definiert wurde. Trotzdem macht das vor allem bei automatisierten Anwednungen reichlich sinn, da man auch bei OE die Sicherheitseinstellungen so einstellen kann, dass bei RPC nicht diese Hinweis Message Boxen aufpoppen. Bei OE geht das nicht und du brauchst da 3Party Software wie "ClickYes". Das nur mal als Bsp. für ne sinnvolle Anwendung.

MfG

Auch da hat es keinerlei Vorteile, diverse Komponenten ständig im RAM zu halten. Wenn meine Anwendung eine DLL benötigt, dann kann ich diese auch zur Laufzeit laden. Diese DLL muss sich nicht vorher im RAM befinden und Speicherplatz verschwenden. Und wenn ich diese nicht mehr brauche, dann kann ich diese DLL auch wieder entladen. Voraussetzung ist natörlich, daß kein anderes Programm diese DLL geladen hat. Von daher sehe ich keinerlei logische und technische Begründung, warum ein IE im Speicher bleiben MUSS.

aths

2003-12-07, 16:01:12

Original geschrieben von Exxtreme
Ich weiss. Aber trotzdem, wieso muss das Teil ständig im RAM bleiben auch wenn es nicht benötigt wird?Der Explorer ist afaik seit einiger Zeit praktisch "Unified". Ich bin einigermaßen sicher, dass nicht genutzte Funktionalität entweder gar nicht erst geladen, oder zumindest ausgelagert wird. Außerdem sind ein paar MB RAM keine kritische Größe mehr.

grakaman

2003-12-07, 16:06:23

Original geschrieben von Exxtreme
Voraussetzung ist natörlich, daß kein anderes Programm diese DLL geldan hat. Von daher sehe ich keinerlei logische und technische Begründung, warum ein IE im Speicher bleiben MUSS.

Wobei dein ganzer oberer Abschnitt auch gleich ad abusrdum ist. Denn das genau ist der Sinn von MAPI, damit Programme eine einheitliche Schnittstelle benutzen können. Du kannst freilich auch andere Mailclients verwenden. Nur woher weisst du schon welche MailClients auf dem Rechner des Users ist. Denn der müsste erst gestartet werden. Und was ist wenn ein Programm dieses nicht mehr benötigt, die dll entläd und andere Programme nicht mehr ausgeführt werden können? Und da du ja sowieso ein Verfechter der Vollständigen Deinstallation des IE bist, was machst du dann wenn die dll gar nicht auf dem System ist? Neuregistrieren? Wieviele andere Programme machen das dann auch und es kommt zur DLL Hell? Es ist nunmal sinnvoll einen kleinen gemeinsamen Nenner zu haben.

MfG

Demirug

2003-12-07, 16:06:48

Original geschrieben von Exxtreme
Auch da hat es keinerlei Vorteile, diverse Komponenten ständig im RAM zu halten. Wenn meine Anwendung eine DLL benötigt, dann kann ich diese auch zur Laufzeit laden. Diese DLL muss sich nicht vorher im RAM befinden und Speicherplatz verschwenden. Und wenn ich diese nicht mehr brauche, dann kann ich diese DLL auch wieder entladen. Voraussetzung ist natörlich, daß kein anderes Programm diese DLL geldan hat. Von daher sehe ich keinerlei logische und technische Begründung, warum ein IE im Speicher bleiben MUSS.

DLLs die nicht genutzt werden aber trotzdem im Speicher sind verschwenden defakto keinen Speicher. Wenn das System Speicher braucht wirft es die entsprechenden Pages einfach raus (Rauswerfen != Swappen). Wird die DLL dann später doch wieder gebraucht kann sie mit den Funktionen des virtuellen Speichermanagers sehr schnell wieder eingeladen werden.

grakaman

2003-12-07, 16:07:31

Da wollte ich mich wohl selbst quoten, bitte löschen :stareup:

Exxtreme

2003-12-07, 16:09:49

Original geschrieben von Demirug
Du redest hier von Software für Firmen ich bezog mich auf den Homeuser.
So groß ist der Unterschied in der Praxis auch nicht. :) Auf jeder Homeuser-Software-Schachtel stehen Voraussetzungen, die benötigt werden, damit diese Software läuft. Spielt der Homeuser was anderes ein, läuft's Programm auch nicht und der Support muss wiederum fragen, was der User alles installiert hat. Schlimmer wird's wenn ein fehlerhaftes Installationsprogramm einer Anderen Anwendung, falsche DLLs einspielt. Dann wird wohl auch der Support aufgeben müssen und die Empfehlung aussprechen, Windows neuzuinstallieren.

Exxtreme

2003-12-07, 16:15:06

Original geschrieben von grakaman
Wobei dein ganzer oberer Abschnitt auch gleich ad abusrdum ist. Denn das genau ist der Sinn von MAPI, damit Programme eine einheitliche Schnittstelle benutzen können. Du kannst freilich auch andere Mailclients verwenden. Nur woher weisst du schon welche MailClients auf dem Rechner des Users ist. Denn der müsste erst gestartet werden. Und was ist wenn ein Programm dieses nicht mehr benötigt, die dll entläd und andere Programme nicht mehr ausgeführt werden können? Und da du ja sowieso ein Verfechter der Vollständigen Deinstallation des IE bist, was machst du dann wenn die dll gar nicht auf dem System ist? Neuregistrieren? Wieviele andere Programme machen das dann auch und es kommt zur DLL Hell? Es ist nunmal sinnvoll einen kleinen gemeinsamen Nenner zu haben.

MfG
Nochmal. :eyes:

Eine DLL muss nicht VORHER im Speicher sein, damit man sie nutzen kann. Man kann sie in den RAM laden wenn man sie benötigt. Und entladen kann man sie auch nicht, wenn ein anderes Programm diese offen hat. Ich sprach nicht davon, daß man diese DLL durch eine andere ersetzen soll.

GRiNSER

2003-12-07, 16:23:02

grakaman

2003-12-07, 16:25:37

Original geschrieben von Exxtreme
Nochmal. :eyes:

Eine DLL muss nicht VORHER im Speicher sein, damit man sie nutzen kann. Man kann sie in den RAM laden wenn man sie benötigt. Und entladen kann man sie auch nicht, wenn ein anderes Programm diese offen hat. Ich sprach nicht davon, daß man diese DLL durch eine andere ersetzen soll.

Wenn jeder nur die IE DLL benutzen würde und sie auf dem Computer auch vorhanden ist, wäre das, wie du es schilderst, in diesem Fall wohl kein Problem.

Demirug

2003-12-07, 16:29:33

Original geschrieben von Exxtreme
So groß ist der Unterschied in der Praxis auch nicht. :) Auf jeder Homeuser-Software-Schachtel stehen Voraussetzungen, die benötigt werden, damit diese Software läuft. Spielt der Homeuser was anderes ein, läuft's Programm auch nicht und der Support muss wiederum fragen, was der User alles installiert hat. Schlimmer wird's wenn ein fehlerhaftes Installationsprogramm einer Anderen Anwendung, falsche DLLs einspielt. Dann wird wohl auch der Support aufgeben müssen und die Empfehlung aussprechen, Windows neuzuinstallieren.

Doch der Unterschied ist gewaltig. Die meisten Homeuser wissen doch gar nicht was sie genau auf iherem System haben und sind daher gar nicht in der Lage die Voraussetzungen auf der Schachtel zu verstehen. Du darfst nicht von dir ausgehen sondern von Leuten die nicht mal in der Lage sind aleine ein Treiberupdate für ihere Grafikkarte zu instalieren.

Muh-sagt-die-Kuh

2003-12-07, 16:31:42

Original geschrieben von Haarmann
Muh-sagt-die-Kuh

Mein BIOS soll im Realmode funktionieren... Dementsprechend wird der wohl doch noch genutzt.Ich meinte im normalen Betrieb...Vielleicht sollte man sich mal nach den Gründen für die Fehler der Programme auf die Suche machen. Tut man imho nicht.Der menschliche Faktor ist der Grund für die Fehler und den kann man nicht abschalten.Mit Interpretersprachensollte es einem auch nicht gelingen nen Rechner abzuschiessen. Betonung auf sollte ;). Wieso nicht? Schliesslich kann auch der Interpreter fehlerhaft sein.

aths

2003-12-07, 16:33:57

Original geschrieben von Demirug
Doch der Unterschied ist gewaltig. Die meisten Homeuser wissen doch gar nicht was sie genau auf iherem System haben und sind daher gar nicht in der Lage die Voraussetzungen auf der Schachtel zu verstehen. Du darfst nicht von dir ausgehen sondern von Leuten die nicht mal in der Lage sind aleine ein Treiberupdate für ihere Grafikkarte zu instalieren. Ich habe gerade mit Entsetzen gelesen, dass die AoM-Macher die Graka erkennen, und zumeist auf ein vorgespeichertes Caps-Profil zurück greifen, weil sie nicht sicher sein können, dass irgendwelche Uralt-Treiber die richtigen Caps melden... das Treiber-Datum detecten die übrigens auch, offenbar gucken die direkt auf eine Treiber-Datei.

Exxtreme

2003-12-07, 16:35:39

Original geschrieben von Demirug
Doch der Unterschied ist gewaltig. Die meisten Homeuser wissen doch gar nicht was sie genau auf iherem System haben und sind daher gar nicht in der Lage die Voraussetzungen auf der Schachtel zu verstehen. Du darfst nicht von dir ausgehen sondern von Leuten die nicht mal in der Lage sind aleine ein Treiberupdate für ihere Grafikkarte zu instalieren.
Und wie willst du da Support leisten? Da hängst du mindesten 2 Stunden lang an der Strippe und gehst mit dem User alle Einstellungen/Softwareaktualisierungen durch.

Exxtreme

2003-12-07, 16:43:54

Original geschrieben von aths
Ich habe gerade mit Entsetzen gelesen, dass die AoM-Macher die Graka erkennen, und zumeist auf ein vorgespeichertes Caps-Profil zurück greifen, weil sie nicht sicher sein können, dass irgendwelche Uralt-Treiber die richtigen Caps melden... das Treiber-Datum detecten die übrigens auch, offenbar gucken die direkt auf eine Treiber-Datei.
Also das habe ich schon öfter gehört, daß die Coder Treiberbugs per Code umgehen. Da wird schlicht die Treiberversion abgefragt und ein Workaround aktiviert, wenn der fragliche Treiber vorliegt. Normalerweise sollten die Programmierer den IHVs in den Hintern treten wenn sowas vorliegt.

Demirug

2003-12-07, 16:48:00

Original geschrieben von Exxtreme
Und wie willst du da Support leisten? Da hängst du mindesten 2 Stunden lang an der Strippe und gehst mit dem User alle Einstellungen/Softwareaktualisierungen durch.

In der Regel reicht es wenn man die Windowsversion + Servicepack kennt. Die User die ich meine Verändern in der Regel ja nichts an den Grundeinstellungen. Das einzige wo man dann noch reinlaufe kann ist die DLL-Hell aber das hat ja bald ein Ende.

Exxtreme

2003-12-07, 16:54:44

Original geschrieben von Demirug
In der Regel reicht es wenn man die Windowsversion + Servicepack kennt. Die User die ich meine Verändern in der Regel ja nichts an den Grundeinstellungen.

Naja, das würde der Homeuser bei einer Linux-Distri aber auch nicht machen... ich meine was verändern. Um den Kernel auszutauschen braucht man einiges an Knowhow und das hat ein Homeuser in der Regel nicht. Bei den Fenstermanagern spielt das keine Rolle solange die nötigen Libs installiert sind und das sind sie in aller Regel. Von daher würde auch die Angabe der Distri reichen.
Original geschrieben von Demirug
Das einzige wo man dann noch reinlaufe kann ist die DLL-Hell aber das hat ja bald ein Ende.
Meinst du wirklich, daß .Net es richten wird?

Haarmann

2003-12-07, 16:57:42

GRiNSER

Ich glaube nicht, dass die Mehrheit der Leute Neulinge sind inzwischen. Fast alle haben mal so ein Teil gesehen und kommen bei immer mehr buntem Zeugs nimmer nach. Das ist jedenfalls meine Erfahrung mit Nutzern. Die klagen Heute imho viel mehr denn Früher.
Offenbar sehen das auch andere hier im Forum so, dass z.B. XP Style mehr Leute verwirrt, denn anspricht.

Kennst Du wen, der diesen gottverfluchten Hund bei der Dateisuche sinnvoll findet? Ich nicht.

grakaman

Du hast die jüdische Weltverschwörung noch vergessen...
Wenn man in ner miesen umgebung arbeiten muss, dann passt man sich eben an oder geht unter. So ists leider.

In dieser Hilfe findet man eh nix - gebt mir ne Deinstallationsmöglichkeit für den Mist und es fliegt in hohem Bogen.

Exxtreme

Du ersparst mir gerade ein paar Zeilen - Danke.

Ich dachte dabei auch an KDE - Hintergründe und Animierte Mauszeiger liefen weit schneller, als andere Dinge. Und ich hätte nach wie vor gerne nen grafischen Gerätemanager wie bei Windows ;).

Demirug

Homeuser kriegen Support von M$? Seit wann gibts denn auch das? ;) Sagt Dir ja sicher DSP Version was...

Aber der mitem Debugger is fast so klassisch wie Profiling mit Java ;).

aths

also bei XP hilft es sehr, wenn man mal die grafischen Sachen alle abschaltet...
NT4 nutzte soviel Speicher nach dem Boot, wie mir der Taskman fürn Explorer anzeigt...

Muh-sagt-die-Kuh

Mir reichte eigentlich ne CPU mit einer Betriebsart...

Man kann Fehler aber provozieren oder vermindern - imho wird zZ noch das erste gemacht - leider.

Natürlich kann der Interpreter das sein, dementsprechend wollte ich das auch verstanden wissen. Anscheinend ist das nicht richtig rübergekommen.

Demirug

2003-12-07, 16:57:46

Original geschrieben von Exxtreme
Also das habe ich schon öfter gehört, daß die Coder Treiberbugs per Code umgehen. Da wird schlicht die Treiberversion abgefragt und ein Workaround aktiviert, wenn der fragliche Treiber vorliegt.

Ja, solche Listen sind durchaus üblich. In der Regel enthalten diese bekannte Fehlmeldungen von Caps und eine Liste welche Effekte mit diesem Chip/Treiber nicht funktionieren obwohl sie es sollten. In Verbindung mit Shaderhardware ist es allerings nicht mehr ganz so schlimm wie früher.

Gesucht wird dabei nach Vendor-ID, Device-ID, Treiber-Version.

Äussert beliebt ist es bei den GF4MX Chips die VS Version generel auf 0 zu setzen.

Normalerweise sollten die Programmierer den IHVs in den Hintern treten wenn sowas vorliegt.

Macht man ja. Aber davon verschwindet der Fehler in den alten Treiber auch nicht. Und ich sagte ja gerade das es genügend Leute gibt die zu unwissend sind um Treiber zu installieren.

Demirug

2003-12-07, 17:00:16

Original geschrieben von Exxtreme
Naja, das würde der Homeuser bei einer Linux-Distri aber auch nicht machen... ich meine was verändern. Um den Kernel auszutauschen braucht man einiges an Knowhow und das hat ein Homeuser in der Regel nicht. Bei den Fenstermanagern spielt das keine Rolle solange die nötigen Libs installiert sind und das sind sie in aller Regel. Von daher würde auch die Angabe der Distri reichen.

Wenn ich mir aber anschaue wie viele Distris es in wie vielen Versionen gibt wird mir durchaus Angst.

Meinst du wirklich, daß .Net es richten wird?

Ja, das DLL-Hell Problem ist damit gelösst. Habe ich selber schon ausprobiert.

Demirug

2003-12-07, 17:05:45

Original geschrieben von Haarmann
Demirug

Homeuser kriegen Support von M$? Seit wann gibts denn auch das? ;) Sagt Dir ja sicher DSP Version was...

Ich meinte den Support von der Seite der Anwendungsentwicklern.

Aber der mitem Debugger is fast so klassisch wie Profiling mit Java ;).

Ja, es verursacht aber nach wie vor schmerzen bei mir wenn ich bei Leuten die riesige Softwaresysteme schreiben nur ein Fragezeichen im Gesicht sehe wenn ich von einem Debugger spreche. Noch schlimmer sind dann Profs/Lehrer die erzählen das ein guter Entwickler keinen Debugger braucht weil er sowieso keine Fehler macht die man damit finden könnte.

grakaman

2003-12-07, 17:10:36

Original geschrieben von Haarmann
In dieser Hilfe findet man eh nix - gebt mir ne Deinstallationsmöglichkeit für den Mist und es fliegt in hohem Bogen.

Ich rede ja auch nicht speziell von Windows, sondern fast alle Windows Applikationen benutzen heute CHM Hilfedateien und dazu braucht man nun mal den IE.

GRiNSER

2003-12-07, 17:19:25

Original geschrieben von Haarmann
GRiNSER

Ich glaube nicht, dass die Mehrheit der Leute Neulinge sind inzwischen. Fast alle haben mal so ein Teil gesehen und kommen bei immer mehr buntem Zeugs nimmer nach. Das ist jedenfalls meine Erfahrung mit Nutzern. Die klagen Heute imho viel mehr denn Früher.
Offenbar sehen das auch andere hier im Forum so, dass z.B. XP Style mehr Leute verwirrt, denn anspricht.

Kennst Du wen, der diesen gottverfluchten Hund bei der Dateisuche sinnvoll findet? Ich nicht.

verstehe die leute nicht die sich bei den klaren darstellungen nicht auskennen... - inwifern kann man da nicht nachkommen?!

ich für meinen teil habe schon alle windows versionen ab Win 95 [9x-/dos-basierte reihe] und Win 2000 [also NT reihe] verwendet und für mich is XP die beste...

du kannst ja jederzeit die alte suche einschalten bzw. den hund abdrehen - hindert dich nix dran wenn der dir nicht gefällt - kannst auch einen von office einstellen... ;) - es gibt halt auch leute die den hund niedlich finden... ein wenig komisch finde ich den hund allerdings auch -> wiso is der nur bei der suche und sonst nirgendwo zu finden...

aths

2003-12-07, 17:43:27

Original geschrieben von Exxtreme
Also das habe ich schon öfter gehört, daß die Coder Treiberbugs per Code umgehen. Da wird schlicht die Treiberversion abgefragt und ein Workaround aktiviert, wenn der fragliche Treiber vorliegt. Normalerweise sollten die Programmierer den IHVs in den Hintern treten wenn sowas vorliegt. Es ist ja leider so, dass die nicht garantieren können, dass sie bis zur Auslieferung des Spiels den Bug im Treiber fixen. Selbst wenn sie das tun, viele User installieren mit einem Spiel nicht gleich noch den aktuellen Grafik-Treiber. Die kaufen sich ihren PC und belassen ihn treibermäßig in diesem Zustand, bis er verschrottet wird.

aths

2003-12-07, 17:46:42

Original geschrieben von Haarmann
aths

also bei XP hilft es sehr, wenn man mal die grafischen Sachen alle abschaltet...
NT4 nutzte soviel Speicher nach dem Boot, wie mir der Taskman fürn Explorer anzeigt...Ich habe Luna meist deaktiviert, aber nur, weil mir das grafisch nicht zusagt, nicht etwa wegen dem Speicherverbrauch. WinXP ist per se etwas träger als Win2000. Bei Win2000 bemerkte ich praktisch nie Latenzen, was die GUI angeht. Dafür ist bei XP der Speicherschutz weiter gediehen http://www.aths.net/files/smilies/cartman.gif.

Xmas

2003-12-07, 18:59:41

Original geschrieben von Matti
Also einsteigerfreundlich ist Windows beim besten Willen nicht. Damit Windows eine brauchbare Performance bekommt, muß man erst zig Einstellungen ändern, Dienste deaktivieren...
Und daß "persönlich angepaßte Menüs" und dieser ganze Käse einem Einsteiger das Leben leichter machen, kann ich mir nicht vorstellen!
Ein bisschen Phantasie hilft ;)
Damit Windows eine brauchbare Performance bekommt, muss ich es - installieren. Reicht auf meinem Rechner jedenfalls aus. Die Performance ist nicht optimal, aber sehr brauchbar.

Unter einem einsteigerfreundlichen Betriebssystem verstehe ich folgendes:
-ein von sich aus schon perfekt getuntes Betriebssystem
-es sollte eine optimale Performance erreichen, so daß es auch auf leistungsschwachen Einsteiger-Rechnern flott läuft

"Perfekt getunt" hat absolut gar nichts mit "einsteigerfreundlich" zu tun.
Einsteiger-Rechner: siehe Aldi, Lidl... Leistungsschwach?

-alle System-Einstellungen sollten übersichtlich auf 2-3 Bildschirmseiten erreichbar sein, und nicht wie bei Windows 20 System-Steuerung-Icons, wo jedes wieder 3-4 oder noch mehr Unter-Fenster hat. Selbst ein Profi muß ja bei Windows oft überlegen, wie er zu einer bestimmten Einstellung kommt.
Man kann beim besten Willen nicht alle Systemeinstellungen übersichtlich auf 2-3 Seiten präsentieren. Dann doch lieber Thematisch gruppieren. Die meisten Einstellungen sind auch nicht für Einsteiger gedacht, deswegen gibt es in XP auch zwei Ansichten für die Systemsteuerung, eine überaus einsteigerfreundlich.

-die Oberfläche sollte selbst-erklärend sein, so daß man kein Handbuch braucht
-bunt und ansprechend soll die Oberfläche natürlich sein, aber nicht mit so viel sinnlosem Schnickschnack, wie bei WindowsXP
Die Oberfläche von Windows ist recht selbsterklärend, und Hilfe ist häufig verfügbar.
Was sinnloser Schnickschnack ist, liegt im Ermessen jedes Einzelnen. Dass ich keine animierten Mauszeiger brauche, heißt nicht dass sich jemand anders nicht darüber freut (kann übrigens die Erkennbarkeit für Sehbehinderte erhöhen).

Original geschrieben von Exxtreme
Was kann ein Assistent besser als ein Texteditor? Also ich empfinde Assistenten eher als eine lästige Behinderung meiner Arbeit da man sich durch etlich Dialoge durchklicken muss.
Ein Assistent kann Eingabehilfen geben, Einstellungen auf Konsistenz prüfen, unsinnige Eingaben gleich ablehnen und garantieren, dass die Einstellungen fehlerfrei sind und an allen relevanten Stellen geändert wurden. Mit einem Texteditor kannst du schon durch Tippfehler jede Menge Mist bauen.
Ein Assistent der eine INI-Datei schreibt, würde es jedem recht machen.

Exxtreme

2003-12-07, 19:02:50

Original geschrieben von Haarmann
Exxtreme

Du ersparst mir gerade ein paar Zeilen - Danke.

Ich dachte dabei auch an KDE - Hintergründe und Animierte Mauszeiger liefen weit schneller, als andere Dinge. Und ich hätte nach wie vor gerne nen grafischen Gerätemanager wie bei Windows ;).

Bei KDE kannst du vieles abschalten und es bringt tatsächlich auch einen Geschwindigkeitsvorteil. Falls dir KDE immer noch zu fett ist, dann installier dir XFCE (http://www.xfce.org/) oder WindowMaker. Klein, schlank und schnell und XFCE sieht sogar optisch ansprechend aus. Daß diese nicht die Effektspielereien bieten wie KDE oder Gnome, sollte klar sein. Klickibunti frisst halt Performance. Das war so und wird wohl immer so sein.

GRiNSER

2003-12-07, 21:04:23

Original geschrieben von Xmas
Ein bisschen Phantasie hilft ;)
Damit Windows eine brauchbare Performance bekommt, muss ich es - installieren. Reicht auf meinem Rechner jedenfalls aus. Die Performance ist nicht optimal, aber sehr brauchbar.

"Perfekt getunt" hat absolut gar nichts mit "einsteigerfreundlich" zu tun.
Einsteiger-Rechner: siehe Aldi, Lidl... Leistungsschwach?

Man kann beim besten Willen nicht alle Systemeinstellungen übersichtlich auf 2-3 Seiten präsentieren. Dann doch lieber Thematisch gruppieren. Die meisten Einstellungen sind auch nicht für Einsteiger gedacht, deswegen gibt es in XP auch zwei Ansichten für die Systemsteuerung, eine überaus einsteigerfreundlich.

Die Oberfläche von Windows ist recht selbsterklärend, und Hilfe ist häufig verfügbar.
Was sinnloser Schnickschnack ist, liegt im Ermessen jedes Einzelnen. Dass ich keine animierten Mauszeiger brauche, heißt nicht dass sich jemand anders nicht darüber freut (kann übrigens die Erkennbarkeit für Sehbehinderte erhöhen).

Ein Assistent kann Eingabehilfen geben, Einstellungen auf Konsistenz prüfen, unsinnige Eingaben gleich ablehnen und garantieren, dass die Einstellungen fehlerfrei sind und an allen relevanten Stellen geändert wurden. Mit einem Texteditor kannst du schon durch Tippfehler jede Menge Mist bauen.
Ein Assistent der eine INI-Datei schreibt, würde es jedem recht machen.
FullAck... mhm bin ich also doch nicht der einzige der so denkt...

GRiNSER

2003-12-07, 21:14:19

Original geschrieben von aths
Ich habe Luna meist deaktiviert, aber nur, weil mir das grafisch nicht zusagt, nicht etwa wegen dem Speicherverbrauch. WinXP ist per se etwas träger als Win2000. Bei Win2000 bemerkte ich praktisch nie Latenzen, was die GUI angeht. Dafür ist bei XP der Speicherschutz weiter gediehen http://www.aths.net/files/smilies/cartman.gif.
naja wenn dir die 3 standard luna designs nicht zusagen, dann kannst du ja aus "einigen" styles z.b. bei www.themexp.org wählen... ich hab auch nicht den luna style laufen, obwohl der mir auch gefallen würde, nur der style den ich verwende gefällt mir besser... ;)

Haarmann

2003-12-07, 21:21:19

GRiNSER

Aus Rücksicht auf meine geplagten und gelangweilten Nerven ist kein Luna und kein Klickibunti mehr aktiv ... Das Gerät fühlt sich damit glatt 3 mal so schnell an und in der Vergangenheit hat CT auch solche Aussagen getätigt.

Wieviel Performance verschenkst Du, nur damit der Mauszeiger was auch immer tut oder Du auf irgendwelche "Tittenbilder" gucken kannst als Hintergrund?

Exxtreme

Ich nutze eh kein KDE, sondern Gnome. Schnell genug ist der Rechner ja noch und gegen ein Luna Theme is wohl alles als Renner zu bezeichnen.

GRiNSER

2003-12-08, 01:15:54

Original geschrieben von Haarmann
GRiNSER

Aus Rücksicht auf meine geplagten und gelangweilten Nerven ist kein Luna und kein Klickibunti mehr aktiv ... Das Gerät fühlt sich damit glatt 3 mal so schnell an und in der Vergangenheit hat CT auch solche Aussagen getätigt.

Wieviel Performance verschenkst Du, nur damit der Mauszeiger was auch immer tut oder Du auf irgendwelche "Tittenbilder" gucken kannst als Hintergrund?

deine argumente werden immer schlechter, weil sonst müsstest du diese nicht mit solchen untergriffigen bemerkungen unterstützen...

kannst ja gerne mal mein wallpaper haben - ist aber eher unspannend - Macro aufnahme von meinem Sharkoon Luminous LED Fan mit Thermaltake Fan Grill gemacht mit ner Sony Digicam...

Mhm also von Performance einbußen merke ich gar nix, nur geht mir eher eine graue und aber graue oberfläche auf den keks...
Wie ich mal eine zeit lang auf Win 2000 gearbeitet habe [ferialjob] bin ich mir vorgekommen, wie wenn ich vor einer lahmen kiste sitze, obwohl diese eine ähnliche syskonfig hatte wie mein rechner... also das speedgefühl is immer relativ...

Capt'N Coax

2003-12-08, 03:25:03

Meine Meinung ist ganz entschieden:
ALLES, und zwar ALLES was mir Arbeit abnimmt ist gut für mich. Weil ich die Zeit wesentlich besser in andere Sachen investieren kann. Ob es das System lahmer macht kann mir egal sein, wenn die Optimierung mir 1000 Mausklicks am Tag erspart.
Bestes Beispiel:
Programmiersprachen - Klar ist es toll und bis zu einer bestimmten Stelle reizvoll sich durch hunderte Zeilen ASM Code zu kämpfen, aber was ist denn das für ein bekloppter Zeit- Nutzen Aufwand? Oder Zeiger in C? NÜTZLICH sagen viele, ja, aber fehleranfällig. Was ist mit der Syntax? Kryptisch. Was ich sagen will ist: Wenn ich was proggen will, möchte ich nicht erst 3 Programmiersprachen lernen, wenn es auch eine tut, die evtl. sogar noch einfacher ist (aber ein klitze langsamer). Das kann man nicht immer anwenden, aber für die meisten Sachen doch schon. Und Java - C++, mmh, Ich tendiere eindeutig zu Java, was die Geschwindigkeit und den Komfort des Programmierens angeht.

Davon abgesehen:
Mitdenkende Umgebung ist das Stichwort.Und da ich ein Singletask- Mensch bin mit begrenztem Kurzzeitgedächtnis ist Programmierung und Handling der aktuellen Systeme für mich in der jetzigen Form eigentlich eine Qual.
Blitzbasic etc. gehen doch einen Schritt in Richtung Verständlichkeit (auf Geekebene), Betriebssysteme werden so langsam nutzerfreundlich. Ich brauche Windows eben NICHT zu konfigurieren um es nutzen zu können (im Idealfall), mit Linux muss ich mich aber auseinandersetzen. Es wäre doch viel sinnvoller, wenn nicht jeder sein eigenes Fenstersüppchen kocht, sondern alle gemeinsam ein FUNKTIONIERENDES UND SIMPLES System entwickeln. Wie der Unterbau ausschaut interessiert mich echt einen Dreck, wenn ich schön simpel meine Fenster programmieren kann (ätzend: Hungarian N.). Wenn mans Speed-optimized will gibts dafür ein Knöpfchen, wenn man Service und Assis braucht auch. Und wenn man ein Geek ist, gibts eine Einstellung "Transparent", da kann man dann ALLES abstürzen lassen.

IMO ist der ganze Ansatzpunkt verkehrt, der Kontext falsch in dem heutzutage im Computerbereich gearbeitet wird. Alles kann mehr, besser und holt das letzte bischen Geschwindigkeit aus der Software heraus, aber ich brauche keine 2% mehr Speed wenn ich dafür ein halbes Jahr optimieren muss. Und dem Normalanwender ist es eh egal. Man muss sich darüber klar werden, das bestimmt die Hälfte der heutigen PC User nicht mit dem PopUp- Menue der rechten Maustaste klarkommen (Erfahrungswert, kann ich nicht beweisen). Nehmen wir doch zum Beispiel Bildverarbeitung: Klar, ich, Ihr und viele andere hier nutzen Freeware, Shareware oder Profi Lösungen, aber wer nur mal ruppzupp n Bild kleiner machen will und keinen Plan hat wird vom Betriebssystem kontextmässig im Stich gelassen. Es wäre doch nur konsequent, unter Win z.B. schon in der Infoanzeige links (XP) die Größe ändern zu können. Oder wozu brauche ich eigentlich 100e Bildformate? Reicht es denn nicht, Bilder "fürs Internet" zu speichern? Muss ich mich als User denn wirklich damit beschäftigen, aus GIF, JPG, PNG etc. zu wählen? Eigentlich nicht...Überhaupt ist z.B. Konvertierung eine Sache, die je nach Anwendungen viel Zeit in Anspruch nimmt. Man sollte sich fragen, ob dies alles nötig ist.

-Haarmann
Ich bin mir echt nicht sicher, ob dieser Unterschied so extrem ausfällt wie du sagst. Diese ganzen PC Welt Optimierungen zum "PFEILSCHNELLEN" System haben bestenfalls Imagewert (Wenn man von Einstellungen wie DMA mal absieht). Ist die Kiste zu langsam? OCen oder neuer Prozessor, 10 MHZ bringen mehr als das ganze rumgeklicke.
Aber ich verstehe dich, es geht halt manchmal ums Prinzip.

Ich fand die alte Win98 Oberfläche nicht besser als XP, mittlerweile tu ich mich sogar schwer mit 98. Klar, Assis etc. schalte ich auch ab, aber das ganze "tunen" meines Systems kostet mich vielleicht eine Stunde. Mit Linux?
pfff

So, ich geh jetz Bett.

Haarmann

2003-12-08, 08:45:00

Eigentlich ging es ja darum mal den Gegenstandpunkt zum Heutigen System darzustellen. Statt die heiligen Kühe der Kompatibilität immer weiter zu pflegen und all die kleinen Fehlerchen der Programme abzufangen versuchen könnte man ja einfach mal was wirklich Neues hinkriegen, was nur läuft und nicht vollgestopft ist. Des Amiga Workbench Oberfläche lief mit nem 2.3 KB "Loader" aus nem 128 KB ROM. Das ROM war meines Wissens in Assembler geschrieben (es wurde so verkauft - man weiss aber nie) und hatte nur wenige Fehler, die per 1.5KB File glaub gepatcht wurden.
Wär doch mal ne Alternative, wenn man sich vom ganzen Krempellöst und ein wirklich neues OS mit ner wirklichen API auf die Beine stellt. Den Bedarf an sowas gibts bestimmt. Von mir aus mit Swapping und Speicherschutz, aber bitte mal was Handliches, was nur den Zweck der Funktion hat.

Als ich jung war (Ich mag diesen Satz immer so), sprach man übrigens von recht happigen Unterschieden der Ausführungsgeschwindigkeit von Assembler und Compilercode. Da warens nicht Prozente, sondern zT 2 stellige Faktorzahlen auch gegenüber C. Natürlich hab ich sowas niecht nachgemessen und kann das auch Heute nicht nachmessen, aber es ist schon immer wieder erstaunlich, wie die Ansichten sich ändern.

Erwähnenswert ist in diesem Zusammenhang das "Russendos", das soll auch grosse Assemblerteile enthalten und bei Word4Dos sogar 5% Mehrleistung geboten haben. Immerhin das - abgesehen davon war dafür der Speicherbedarf minimal. Die Freude Seitens M$ hielt sich wohl in Grenzen...

GRiNSER

Ich inste keine Wallpaper im Gegenteil ich lösche gleich die Vorhandenen, das macht das Windows leerer und die Verzeichnisse schneller. Spätestens bei 5k Files lernt man schnell, das Verzeichnisse langsam werden bei zuviel Müll drinnen. Schlimmstenfalls geht kopieren der Nutzdaten und Format X: schneller als irgendwelche Löschversuche (auch unter NTFS, denn damit passierte es mal). Dementsprechend setzte ich lieber auf Prävention.

Nun würde es mich mal interessieren, wann Du Dein Hintergrundbild überhaupt siehst... Ich für meinen Teil habe eigentlich den PC nicht als Verzierung durch Bilder Schaukasten in Betrieb, sondern öfne dabei oft Programme, die den Hintergrund eh komplett verdecken. Wozu also ein Hintergrundbild, wenn das PRG, das ja den Sinn ergibt nen PC zu haben dies schlicht überdeckt?

Capt'N Coax

Ich hab über Java und Profiling schon weiter Oben gelacht. Das ist brotlose Kunst.

Ich definiere mal Java als Sammlung von Geräteemulationen nichtexistierender und erdachter Computer, die je nach Endgerät unterschiedlich Funktionsreich sind. Nur bleibt die Frage - wieso sollte man auch 95% X86 Kisten nen Gerät emulieren lassen, das es nicht gibt, wo doch jeder weiss, dass Emulationen nie schnell sind?

Legolas

2003-12-08, 09:04:36

Original geschrieben von Haarmann
Wär doch mal ne Alternative, wenn man sich vom ganzen Krempellöst und ein wirklich neues OS mit ner wirklichen API auf die Beine stellt. Den Bedarf an sowas gibts bestimmt. Von mir aus mit Swapping und Speicherschutz, aber bitte mal was Handliches, was nur den Zweck der Funktion hat.

MenuetOS (www.menuetos.org)

Klein ist es (Es passt auf ne gute, alte Floppy). Handlich vielleicht auch. Anwendungen? gibts ein paar, kannst dir aber alles was du brauchst in ASM selber schreiben (Das macht doch soviel Spass, und außerdem bedeutet das maximale Konfigurierbarkeit). Funktionieren tut es (man kann es sogar auf Festplatte installieren). Und das BESTE: Es besteht zu 100% aus Assemblercode und du kannst daran mitschreiben.

GRiNSER

2003-12-08, 10:01:14

Original geschrieben von Haarmann
...
GRiNSER

Ich inste keine Wallpaper im Gegenteil ich lösche gleich die Vorhandenen, das macht das Windows leerer und die Verzeichnisse schneller. Spätestens bei 5k Files lernt man schnell, das Verzeichnisse langsam werden bei zuviel Müll drinnen. Schlimmstenfalls geht kopieren der Nutzdaten und Format X: schneller als irgendwelche Löschversuche (auch unter NTFS, denn damit passierte es mal). Dementsprechend setzte ich lieber auf Prävention.

Nun würde es mich mal interessieren, wann Du Dein Hintergrundbild überhaupt siehst... Ich für meinen Teil habe eigentlich den PC nicht als Verzierung durch Bilder Schaukasten in Betrieb, sondern öfne dabei oft Programme, die den Hintergrund eh komplett verdecken. Wozu also ein Hintergrundbild, wenn das PRG, das ja den Sinn ergibt nen PC zu haben dies schlicht überdeckt?
...
Also von dem Verzeichnis langsamer werden hab ich wirklich noch nichts bemerkt...
Ich sehe mein hintergrundbild beim windows starten und beenden, wenn ich nur den Arbeitsplatz offen hab zum teil und wenn ich ein Prog vom desktop starten will... Ein Hintergrundbild war vielleicht vor ein paar Jährchen noch ein wirkliches Performanceproblem, aber zu heutigen Zeiten in sachen RAM-Speichergröße und CPU-Geschwindigkeit ist das ja wohl ein Gimmick was man sich leisten kann! Vorallem da ich auch keinen merkbaren Unterschied mit oder ohne Wallpaper merke - zumindest Geschwindigkeitsmäßig...
Mir wurde mein Rechner noch nie wirklich zu langsam [sowas passiert nur beim Spielen], auch wenn ich mal wieder am Homepage basteln bin und 20 Programme offen hab...

grakaman

2003-12-08, 11:37:14

Original geschrieben von Haarmann
Eigentlich ging es ja darum mal den Gegenstandpunkt zum Heutigen System darzustellen. Statt die heiligen Kühe der Kompatibilität immer weiter zu pflegen und all die kleinen Fehlerchen der Programme abzufangen versuchen könnte man ja einfach mal was wirklich Neues hinkriegen, was nur läuft und nicht vollgestopft ist. Des Amiga Workbench Oberfläche lief mit nem 2.3 KB "Loader" aus nem 128 KB ROM. Das ROM war meines Wissens in Assembler geschrieben (es wurde so verkauft - man weiss aber nie) und hatte nur wenige Fehler, die per 1.5KB File glaub gepatcht wurden.
Wär doch mal ne Alternative, wenn man sich vom ganzen Krempellöst und ein wirklich neues OS mit ner wirklichen API auf die Beine stellt. Den Bedarf an sowas gibts bestimmt. Von mir aus mit Swapping und Speicherschutz, aber bitte mal was Handliches, was nur den Zweck der Funktion hat.

Als ich jung war (Ich mag diesen Satz immer so), sprach man übrigens von recht happigen Unterschieden der Ausführungsgeschwindigkeit von Assembler und Compilercode. Da warens nicht Prozente, sondern zT 2 stellige Faktorzahlen auch gegenüber C. Natürlich hab ich sowas niecht nachgemessen und kann das auch Heute nicht nachmessen, aber es ist schon immer wieder erstaunlich, wie die Ansichten sich ändern.

Erwähnenswert ist in diesem Zusammenhang das "Russendos", das soll auch grosse Assemblerteile enthalten und bei Word4Dos sogar 5% Mehrleistung geboten haben. Immerhin das - abgesehen davon war dafür der Speicherbedarf minimal. Die Freude Seitens M$ hielt sich wohl in Grenzen...

GRiNSER

Ich inste keine Wallpaper im Gegenteil ich lösche gleich die Vorhandenen, das macht das Windows leerer und die Verzeichnisse schneller. Spätestens bei 5k Files lernt man schnell, das Verzeichnisse langsam werden bei zuviel Müll drinnen. Schlimmstenfalls geht kopieren der Nutzdaten und Format X: schneller als irgendwelche Löschversuche (auch unter NTFS, denn damit passierte es mal). Dementsprechend setzte ich lieber auf Prävention.

Nun würde es mich mal interessieren, wann Du Dein Hintergrundbild überhaupt siehst... Ich für meinen Teil habe eigentlich den PC nicht als Verzierung durch Bilder Schaukasten in Betrieb, sondern öfne dabei oft Programme, die den Hintergrund eh komplett verdecken. Wozu also ein Hintergrundbild, wenn das PRG, das ja den Sinn ergibt nen PC zu haben dies schlicht überdeckt?

Capt'N Coax

Ich hab über Java und Profiling schon weiter Oben gelacht. Das ist brotlose Kunst.

Ich definiere mal Java als Sammlung von Geräteemulationen nichtexistierender und erdachter Computer, die je nach Endgerät unterschiedlich Funktionsreich sind. Nur bleibt die Frage - wieso sollte man auch 95% X86 Kisten nen Gerät emulieren lassen, das es nicht gibt, wo doch jeder weiss, dass Emulationen nie schnell sind?

Ich habe mich zwar noch nicht so intensiv mit Assembler auseinandergesetzt (nur äußerst rudimentäre Grundkenntnisse), aber du darfst dabei einwas nicht vergessen, Haarmann. Der Amiga ist ja quasi, wie der C64 etc., eine geschlossene Plattform. Es ist demzufolge viel leichter (vermute ich) für die 68k Familie zu optimieren und Abwärtskompatibilität zu wahren, als wenn das unterschiedliche Prozessortypen von unterschiedlichen Firmen wären, wie wir es im PC Bereich haben. Aber du hast mich dabei auf eine Idee gebracht, denn ich hatte früher auch einen Amiga. Vielleicht ersteiger ich noch einen Amiga und beschäftige mich über Weihnachten mit ASM Programmierung für den Amiga.

MfG

Capt'N Coax

2003-12-08, 15:24:57

Ich definiere mal Java als Sammlung von Geräteemulationen nichtexistierender und erdachter Computer, die je nach Endgerät unterschiedlich Funktionsreich sind. Nur bleibt die Frage - wieso sollte man auch 95% X86 Kisten nen Gerät emulieren lassen, das es nicht gibt, wo doch jeder weiss, dass Emulationen nie schnell sind?

Weil der Produktionsprozess von Software stark erleichtert wird. Es war doch eigentlich schon immer so (simplizifiert): schnell und aufwendig oder einfach und lahm.
Abgesehen davon würde ich Java nicht als wirklich lahm bezeichnen, aber die Diskussion wäre OT.
Es wird mit Speicher und Power so verschwenderisch umgegangen, weil diese Komponenten schlicht vorhanden ist (das Beispiel beziehe ich NUR auf den Desktop und evtl. Serverbereich, industrielle Chipprogrammierung etc. fällt da aus).
Und die Software wird immer komplizierter während sich die Umgebung daran nur langsam anpasst. Das Ergebnis ist entweder schlampig programmierte Software (Deadline etc.) oder Software die sich auf die Sicherheit des Systems verlässt. Wenn ich anstatt 1000 100000 Zeilen Code schreiben muss, mein zeitlicher Rahmen aber nahezu derselbe ist (übertrieben, ich weiss), und dann noch 50 Mann mehr an einem Programm schreiben, kann ich den Entwicklern nicht wirklich einen Vorwurf machen. Zeit ist halt Geld.
Und wir Kunden nehmen diese Entwicklung doch stillschweigend an...

Kurz und kanpp:
Fehlerfreie Software ist ein Segen, aber die Realisierung derselbigen muss so weit wie möglich automatisiert werden. Sprachen müssen vereinfacht werden, Fehlerquellen wie wilde Zeiger ausgeschlossen werden, das kann nur die Entwicklungsumgebung übernehmen.

Haarmann

2003-12-08, 20:49:04

Legolas

Ich suche nach nem PC mit RTL 8139 ;). Nette Sache.

Capt'N Coax

Wieso kann man dann nicht einfach ne "TeilAPI" von nem x86 System, welches dann auf 95% der Rechner nativ läuft, emulieren?

Naja... Sag mir mal nen RAD System mit Java...
Deine These befürworte ich, aber Java daraus zu folgern, halte ich für falsch.

Fehlerquellen sind imho nicht die Zeiger, sondern die APIs und die heiligen Kühe. Abgesehen von der kläglichen Syntax von 99% aller "Sprachen".

Muh-sagt-die-Kuh

2003-12-08, 21:01:12

Original geschrieben von Haarmann
Wieso kann man dann nicht einfach ne "TeilAPI" von nem x86 System, welches dann auf 95% der Rechner nativ läuft, emulieren?Java ByteCode ist mit Absicht so gehalten, dass das Schreiben einer Virtual Machine für verschiedene Architekturen so einfach wie möglich ist. Hätte man ein x86 Subset ausgewählt wäre dies deutlich schwerer.

Java ist übrigens bei weitem nicht so lahm wie manche Leute behaupten, der ByteCode wird zur Laufzeit in Maschinensprache übersetzt (JIT-Compilation) und nicht interpretiert.

grakaman

2003-12-08, 22:02:52

Original geschrieben von Haarmann
Wieso kann man dann nicht einfach ne "TeilAPI" von nem x86 System, welches dann auf 95% der Rechner nativ läuft, emulieren?

Die Aussage verstehe ich nicht. Nativ läuft es sowieso, wenn der ByteCode gejittet wurde. Du kannst wohl aber unter Java den Code auch gleich direkt in Systemeigenen Code kompilieren. Nur ergibt sich mir nicht der Sinn, denn das läuft auf Grund von Binärinkompatibilitäten sowieso nicht unter allen BS'en.

Naja... Sag mir mal nen RAD System mit Java...
Deine These befürworte ich, aber Java daraus zu folgern, halte ich für falsch.

JBuilder, Eclipse (mit zig Plugins), SunOne Studio ...
Die beste IDE hat freilich Microsoft mit VS.NET :D (um mal jetzt ganz unverschämt das Thema zu wechseln)

Fehlerquellen sind imho nicht die Zeiger, sondern die APIs und die heiligen Kühe. Abgesehen von der kläglichen Syntax von 99% aller "Sprachen".

Warum sollte die API die hauptsächliche Fehlerquelle sein? Heutige Betriebssysteme laufen doch äußerst stabil. Was ist denn an der Java/NET/WIN32... API so fehlerträchtig?
Bei Zeigern kannst du direkt die Adresse manipulieren. Das ist nicht nur eine potentielle Fehlerquelle bei der Entwicklung sondern auch ein großes Sicherheitsrisiko. Als Angreifer kannst du so viel leichter eingeschleusten Code ausführen.
Die Syntax ist eine reine Geschmacksfrage. Ich finde die Syntax von C Sprachen sehr effektiv.

MfG

Demirug

2003-12-08, 23:17:01

Also meine richtig harten Programmabstürze waren bisher bis auf einen alles Pointerfehler. Und dieser eine war im weitesten Sinn auch ein Zeigerfehler weil ein Thread ein dynamisches Objekt freigegeben hat welches ein anderer noch benutzt hat. Der Rest gehörte alles in den Bereich Logikfehler die dazu führten das das Programm nicht genau das gemacht hat was es sollte.

Ich war ja auch skeptisch was Jitten und Bytecode angeht aber inzwischen mag ich die Technik. MSIL finde ich zum zum Beispiel viel besser lessbar und auch programmierbar als x86 Code. Der Jiter baut dabei letztende Endes auf den normalen Compilern auf kennt aber noch ein paar zusätzliche Tricks. Zum Beispiel inlinen über DLL Grenzen hinweg. Aber der unschätzbare Vortiel ist das beim Jitten genau auf die Zielplatform optimiert werden kann. Eine Anwendung die jetzt auf einer 32 Bit CPU läuft kann ich 1 zu 1 auf einen Opteron übernehmen und der Jitter dort erzeugt dann x86-64 Code daraus welcher die zusätzlichen Register auch nutzen kann. Gerade das macht es doch erst möglich das wir uns mittelfristig von den alten Sachen lösen. Wir hängen doch immer noch auf x86 weil es einfach zu viel Software dafür gibt die keiner neu schreiben will oder kann.

Haarmann

2003-12-09, 09:17:02

Demirug

Wie kriegt man eigentlich Pointerfehler hin? Also ich schaffte sowas nie, wobei ich sogar bei diesen einfachen PRGs ne Ausnahme war. Allerdings war ich nicht die Einzige - im Prinzip waren alle vom Amiga ASM stammenden Leute recht immun dagegen (Noch seltsamerweise haben alle das selbe Buch genutzt, die ich kenne). Hab Selbiges auch über einen gehört, der an der Uni inzwischen seinen Dr hinter sich gebracht hat und ich auch noch vom Gymnasium her kenne. Ich hab manchmal wirklich das Gefühl, dass dies nur ein Problem der Arbeitsweise ist, zu der man dabei verknurrt wird. Wer damit begonnen hat ist natürlich immer im Vorteil. Über welche Stationen kamst Du denn zu diesen Pointers?

Bytecode hatte immer den Vorteil, dass ich bei Übungen per Winrar die JARs ummodelte und per HEX-Edit meinen Namen einfügte, weil ich nichts selber machte... Aber dass ich das einfach so tun kann, spricht nicht für dieses Verfahren - Sicherheit?

Also wenn man nen Opteron nimmt, so müsste sich jedes 32 Bit PRG in 32-Bit ASM auch in 64 Bit übersetzen lassen, aber ohne Speedgewinn. Das geht nur dann nicht, wenn die eine Plattform derb überlegen ist, ansonsten kann man fehlende Befehle "Makroisieren", wobei Makros eh schon die Konvertierung übernehmen von alt in neu.

Kleines Trivialbsp zur Veranschaulichung

Da mov ax,bx für 68k ASM nichts heisst, kann man per Makro das mov gegen ein move.w (ich mag das w dort) austauschen lassen und aus AX ein A0 resp D0 machen, je nach Befehl resp eher je nach Registerteil. Glücklicherweise hat ja der 68K genug Register für diesen Murks, denn al und ah lassen sich in A0 nicht nutzen, das die A Register nur ganz oder halb angesprochen werden können und nicht zu 8 Bit, sehr wohl aber in D0 geht das dann. Dies ist nicht optimal, aber sehr schnell fürs Erste und müsste reichen um alles portierbar zu halten (Ausser eben Protected Mode). Ich sehe also keinen Grund für nen JIT.

mrdigital

2003-12-09, 10:05:16

Demirug

2003-12-09, 10:31:55

Original geschrieben von Haarmann
Demirug

Wie kriegt man eigentlich Pointerfehler hin? Also ich schaffte sowas nie, wobei ich sogar bei diesen einfachen PRGs ne Ausnahme war. Allerdings war ich nicht die Einzige - im Prinzip waren alle vom Amiga ASM stammenden Leute recht immun dagegen (Noch seltsamerweise haben alle das selbe Buch genutzt, die ich kenne). Hab Selbiges auch über einen gehört, der an der Uni inzwischen seinen Dr hinter sich gebracht hat und ich auch noch vom Gymnasium her kenne. Ich hab manchmal wirklich das Gefühl, dass dies nur ein Problem der Arbeitsweise ist, zu der man dabei verknurrt wird. Wer damit begonnen hat ist natürlich immer im Vorteil. Über welche Stationen kamst Du denn zu diesen Pointers?

Alles was mit dynamischem Speicher zu tun hat kann zu Pointer Fehlern führen. Dazu zählen zum Beispiel solche Sachen wie Hash-Tables, Verkettete Listen, usw. In der grundform sind diese Dinge relative harmloss fängt man nun aber an in komplexen Systemen einen Zeiger auf diese Objekte zu streuen wird es schnell gefährlich. Es kommen dann solche Fragen auf wie. Wer erzeugt ein Objekt und wer löscht es wieder? An welchen Stellen wird der Verweiss (Pointer) überall gespeichert? Und dann natürlich noch die zeitliche abfolge des Ganzen. In der ersten Version eines Systems funktioniert das meist ohne grössere Probleme aber Software neigt dazu zu wachsen. Da wird schnell ein neues Feature implementiert welches mit dem gleichen Objekt arbeiten muss. Dadurch hat man dann schnell das ursprüngliche Timeing zerstört. Auch beliebt ist das benutzten von ungebrüften NULL-Zeigern. Man geht davon aus das ein Zeiger schon auf etwas zeigt und spart sich aus Performancegründen die Prüfung. Diese Annahme wird getroffen weil man weiss wer eine Funktion alles aufruft und ja dort schon gebrüft hat. Nun wird das System mal wieder erweitert und man ruft die Funktion ohne die Prüfung von einer anderen Stelle auf. Wenn es dann dumm läuft prüft diese vorher nicht und man hat einen schönen Absturz.

Zu meiner Assemblerhochzeit (C64) ist mir sowas auch nie passiert aber da gab es ja auch keine dynamische Speicherverwaltung. Auch bei den einfachen Programmen habe ich kein Problem mit Zeigerfehler weil ich dort in der Regel schlicht und ergreifend den dynamischen Speicher höchstens indirekt (Speicher wird an Anfang reserviert und am Ende wieder freigegeben) brauche. Problematisch wird es eben erst wenn zur Laufzeit ständig Speicher angelegt und wieder freigegeben wird.

Bytecode hatte immer den Vorteil, dass ich bei Übungen per Winrar die JARs ummodelte und per HEX-Edit meinen Namen einfügte, weil ich nichts selber machte... Aber dass ich das einfach so tun kann, spricht nicht für dieses Verfahren - Sicherheit?

Ich habe auch schon in x86 Binärcode gepatcht. Also da kann ich nun wirklich keinen unterschied entdecken.

Also wenn man nen Opteron nimmt, so müsste sich jedes 32 Bit PRG in 32-Bit ASM auch in 64 Bit übersetzen lassen, aber ohne Speedgewinn. Das geht nur dann nicht, wenn die eine Plattform derb überlegen ist, ansonsten kann man fehlende Befehle "Makroisieren", wobei Makros eh schon die Konvertierung übernehmen von alt in neu.

Ja, Cross-Assembler gibt es schon aber diese arbeiten eben 1 zu 1 und erzeugen meist Code der schlechter ist als wenn man den ursprünglichen Hochsprachencode mit einem Compiler für die entsprechenden CPU nimmt.

Kleines Trivialbsp zur Veranschaulichung

Da mov ax,bx für 68k ASM nichts heisst, kann man per Makro das mov gegen ein move.w (ich mag das w dort) austauschen lassen und aus AX ein A0 resp D0 machen, je nach Befehl resp eher je nach Registerteil. Glücklicherweise hat ja der 68K genug Register für diesen Murks, denn al und ah lassen sich in A0 nicht nutzen, das die A Register nur ganz oder halb angesprochen werden können und nicht zu 8 Bit, sehr wohl aber in D0 geht das dann. Dies ist nicht optimal, aber sehr schnell fürs Erste und müsste reichen um alles portierbar zu halten (Ausser eben Protected Mode). Ich sehe also keinen Grund für nen JIT.

Du hast gerade selbst den Grund geliefert. Jede CPU hat so ihere Vorlieben und Begrenzungen die sich nicht Vereinheitlichen lassen. Da lobe ich mir echt MSIL. Kein Ärger mit den Register oder dem Stack.

.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )
// Codegröße 61 (0x3d)
.maxstack 3
.locals init ([0] float32 a,
[1] float32 b,
[2] float32 c,
[3] float32 d,
[4] float32 e)
IL_0000: ldc.r4 1.
IL_0005: stloc.0
IL_0006: ldc.r4 2.
IL_000b: stloc.1
IL_000c: ldc.r4 3.
IL_0011: stloc.2
IL_0012: ldc.r4 4.
IL_0017: stloc.3
IL_0018: ldloc.0
IL_0019: ldloc.1
IL_001a: mul
IL_001b: ldloc.2
IL_001c: ldloc.3
IL_001d: mul
IL_001e: add
IL_001f: stloc.s e
IL_0021: ldloc.s e
IL_0023: ldc.r4 0.0
IL_0028: ble.un.s IL_002c
IL_002a: br.s IL_003c
IL_002c: ldloc.0
IL_002d: ldloc.1
IL_002e: mul
IL_002f: ldloc.2
IL_0030: ldloc.3
IL_0031: mul
IL_0032: add
IL_0033: ldc.r4 0.0
IL_0038: ble.un.s IL_003c
IL_003a: br.s IL_003c
IL_003c: ret
} // end of method Class1::Main

Der Jitter macht daraus diesen X86 Code. Das ist die unoptimierte Version. An die optimierte kommt man schlecht ran deswegen habe ich mir das gespart.

00000000 push ebp
00000001 mov ebp,esp
00000003 sub esp,18h
00000006 mov dword ptr [ebp-4],ecx
00000009 mov dword ptr [ebp-8],0
00000010 mov dword ptr [ebp-0Ch],0
00000017 mov dword ptr [ebp-10h],0
0000001e mov dword ptr [ebp-14h],0
00000025 mov dword ptr [ebp-18h],0
0000002c mov dword ptr [ebp-8],3F800000h
00000033 mov dword ptr [ebp-0Ch],40000000h
0000003a mov dword ptr [ebp-10h],40400000h
00000041 mov dword ptr [ebp-14h],40800000h
00000048 fld dword ptr [ebp-8]
0000004b fmul dword ptr [ebp-0Ch]
0000004e fld dword ptr [ebp-10h]
00000051 fmul dword ptr [ebp-14h]
00000054 faddp st(1),st
00000056 fstp dword ptr [ebp-18h]
00000059 fld dword ptr [ebp-18h]
0000005c fld qword ptr ds:[06EB00F0h]
00000062 fcomip st,st(1)
00000064 fstp st(0)
00000066 jp 0000006D
00000068 jae 0000006D
0000006a nop
0000006b jmp 0000008C
0000006d fld dword ptr [ebp-8]
00000070 fmul dword ptr [ebp-0Ch]
00000073 fld dword ptr [ebp-10h]
00000076 fmul dword ptr [ebp-14h]
00000079 faddp st(1),st
0000007b fld qword ptr ds:[06EB00F8h]
00000081 fcomip st,st(1)
00000083 fstp st(0)
00000085 jp 0000008C
00000087 jae 0000008C
00000089 nop
0000008a jmp 0000008C
0000008c nop
0000008d mov esp,ebp
0000008f pop ebp
00000090 ret

IMHO ist der MSIL Code wesentlich besser von einer CPU zu einer anderen zu übertragen als der x86 Code.

Crushinator

2003-12-09, 10:42:20

Original geschrieben von Capt'N Coax
-Haarmann
Ich bin mir echt nicht sicher, ob dieser Unterschied so extrem ausfällt wie du sagst. Diese ganzen PC Welt Optimierungen zum "PFEILSCHNELLEN" System haben bestenfalls Imagewert (Wenn man von Einstellungen wie DMA mal absieht). Ist die Kiste zu langsam? OCen oder neuer Prozessor, 10 MHZ bringen mehr als das ganze rumgeklicke.
Aber ich verstehe dich, es geht halt manchmal ums Prinzip. Also, ich bin zwar nicht Haarmann, aber dazu sag' ich nur Folgendes: Ich sitze auf der Arbeit aus nicht näher genannten Gründen hauptsächlich vor einem P3 mit 650 MHz und 512 MB RAM auf Win2K. Das System ist soweit wie nur möglich getunt damit das "Arbeiten" mit der Oberfläche möglichst nicht von den anderen > 2 GHz XP-Kisten (ohne Luna) unterscheidet, und ob Du's glaubst oder nicht, es läßt sich fast nie ein Unterschied feststellen. Das einzig ärgerliche ist, wenn ich zu Hause am ähnlich getunten Win2K auf 'nem Athlon XP2000+ arbeite und nächsten Tag wieder den P3 vor mir habe. :D
Ich fand die alte Win98 Oberfläche nicht besser als XP, mittlerweile tu ich mich sogar schwer mit 98. Klar, Assis etc. schalte ich auch ab, aber das ganze "tunen" meines Systems kostet mich vielleicht eine Stunde. Womit genau kommst Du unter Win98 eigentlich nicht mehr zurecht?

Crushinator

2003-12-09, 10:57:09

Original geschrieben von Demirug
(...) IMHO ist der MSIL Code wesentlich besser von einer CPU zu einer anderen zu übertragen als der x86 Code. Da kommen wir aber schnell zu einer Lösung, für die es IMHO keine echte Problemstellung gibt. Ich meine, wenn ich den Sourcecode einer Anwendung in C++ habe, weil ich diese selbst entwickelt habe, warum kann ich die Anwendung nicht gleich mit einem entsprechenden Nativ-Compiler auf die gewünschte Zielplattform portieren? Zumal ich nicht wüßte, auf welchen ernstzunehmenden Architekturen außer Win-x86 ordentliche Jitter für MSIL existieren.

grakaman

2003-12-09, 11:03:11

Original geschrieben von crushinator
Also, ich bin zwar nicht Haarmann, aber dazu sag' ich nur Folgendes: Ich sitze auf der Arbeit aus nicht näher genannten Gründen hauptsächlich vor einem P3 mit 650 MHz und 512 MB RAM auf Win2K. Das System ist soweit wie nur möglich getunt damit das "Arbeiten" mit der Oberfläche möglichst nicht von den anderen > 2 GHz XP-Kisten (ohne Luna) unterscheidet, und ob Du's glaubst oder nicht, es läßt sich fast nie ein Unterschied feststellen. Das einzig ärgerliche ist, wenn ich zu Hause am ähnlich getunten Win2K auf 'nem Athlon XP2000+ arbeite und nächsten Tag wieder den P3 vor mir habe. :D
Womit genau kommst Du unter Win98 eigentlich nicht mehr zurecht?

Also ich hab zwar auf Arbeit knapp 300Mhz mehr als du, dafür 256MB weniger. Und da läuft W2k richtig schnell und da wird und "darf" sowieso nichts getuned werden. Zu hause hab ich auf nem 2GHz P4 XP Pro mit Luna drauf. Das geht schon "bedeutend" langsamer, allerdings nur weil ich da auch bloss 256MB Ram habe (muss ich mal aufrüsten). Nur mal so als Gegenbeispiel.

MfG

Crushinator

2003-12-09, 11:10:28

Original geschrieben von grakaman
Also ich hab zwar auf Arbeit knapp 300Mhz mehr als du, dafür 256MB weniger. Und da läuft W2k richtig schnell und da wird und "darf" sowieso nichts getuned werden. Zu hause hab ich auf nem 2GHz P4 XP Pro mit Luna drauf. Das geht schon "bedeutend" langsamer, allerdings nur weil ich da auch bloss 256MB Ram habe (muss ich mal aufrüsten). Nur mal so als Gegenbeispiel. Sorry, das ist noch kein Gegenbeispiel, weil die Mindestaustattung unserer XP-Kisten schon 512 MB beinhalten. ;)

Exxtreme

2003-12-09, 11:14:48

Original geschrieben von crushinator
Da kommen wir aber schnell zu einer Lösung, für die es IMHO keine echte Problemstellung gibt. Ich meine, wenn ich den Sourcecode einer Anwendung in C++ habe, weil ich diese selbst entwickelt habe, warum kann ich die Anwendung nicht gleich mit einem entsprechenden Nativ-Compiler auf die gewünschte Zielplattform portieren? Zumal ich nicht wüßte, auf welchen ernstzunehmenden Architekturen außer Win-x86 ordentliche Jitter für MSIL existieren.
Es gibt schlicht und ergreifend Dinge, die für jede Plattform spezifisch sind. Nehmen wir zum Beispiel die Registry. Das Teil gibt's AFAIK ausschliesslich unter Windows. Wenn dein Programm viel mit der Registry arbeitet, dann kannste eine Portierung ohne viel Aufwand vergessen. 100%ig portabel wird man nie sein können mit C++ ausser man beschränkt sich auf reine Konsolenanwendungen. Man kann sich's aber leichter machen wenn man für mehrere Plattformen programmiert. Man muss zusätzlich einige Layer einschieben bezüglich I/O.

Demirug

2003-12-09, 11:15:27

Original geschrieben von crushinator
Da kommen wir aber schnell zu einer Lösung, für die es IMHO keine echte Problemstellung gibt. Ich meine, wenn ich den Sourcecode einer Anwendung in C++ habe, weil ich diese selbst entwickelt habe, warum kann ich die Anwendung nicht gleich mit einem entsprechenden Nativ-Compiler auf die gewünschte Zielplattform portieren? Zumal ich nicht wüßte, auf welchen ernstzunehmenden Architekturen außer Win-x86 ordentliche Jitter für MSIL existieren.

Schon einmal Anwendungen für Windows.CE programmiert?
Aufgrund der unterschiedliche CPUs die CE unterstützt ist das dort ein vorhandenes Problem. Ohne .Net muss man sich da immer die passenden Binary suchen. Hat der Autor keine passende erstellt ist man gekniffen.

Das gleiche Problem entsteht aber gerade auch bei der "normalen" Windows Version. Inzwischen sind es 3 Platformen.

grakaman

2003-12-09, 11:56:29

Aber die Plattforminteroperabilität ist meiner Meinung nach sowieso nicht das Hauptargument für Zwischencode. Vielmehr: Reflections, Code Access Security, Versioning (Latebinding), Interoperabilität zwischen verschiedenen Sprachen, Delayed Signing und und und ...
Im Prinzip geht es hauptsächlich darum auf eine äußerst effektive Weise die alten COM Paradigmen über Board zu werfen.

Crushinator

2003-12-09, 12:08:07

Original geschrieben von Demirug
Schon einmal Anwendungen für Windows.CE programmiert?
Aufgrund der unterschiedliche CPUs die CE unterstützt ist das dort ein vorhandenes Problem. Ohne .Net muss man sich da immer die passenden Binary suchen. Hat der Autor keine passende erstellt ist man gekniffen. Laß mich damit bloß in Ruhe ;) Mein mir gegenübersitzender Kollege versucht sich seit 2 Wochen einen Krampf mit .Net Hausmitteln unter "Pocket PC 2002" zu drucken. Also, nix mit "ordentlichem" Framework geschweige denn Jitter.
Das gleiche Problem entsteht aber gerade auch bei der "normalen" Windows Version. Inzwischen sind es 3 Platformen. Nunja, ich habe es ehrlich gesagt noch nie geschafft, eine Nativ-App zu entwickeln, die auf einer von den 3 Probleme macht, solange die eingesetzte API/Runtime/HW/Treiber unter dem jeweiligen OS überhaupt existiert.

grakaman

2003-12-09, 12:18:47

Original geschrieben von crushinator
Laß mich damit bloß in Ruhe ;) Mein mir gegenübersitzender Kollege versucht sich seit 2 Wochen einen Krampf mit .Net Hausmitteln unter "Pocket PC 2002" zu drucken. Also, nix mit "ordentlichem" Framework geschweige denn Jitter.

Am besten mal bitte Code posten. Anhand von irgendwelchen Kollegen oder Storys kann man ja schlecht ernsthafte Rückschlüsse auf das Framework schließen.

Nunja, ich habe es ehrlich gesagt noch nie geschafft, eine Nativ-App zu entwickeln, die auf einer von den 3 Probleme macht, solange die eingesetzte API/Runtime/HW/Treiber unter dem jeweiligen OS überhaupt existiert.

Wie entwickelst du bitten eine plattformunabhängige Applikation, die distributed Transaction, Object Pooling etc. benutzt? .NET greift da zwar noch auf COM+ zu, aber das Problem wurde zumindest über Interop abstrahiert. Es ist also ein leichtes bei der Portierung des Frameworks, dass die entsprechenden managed Klassen dann aben auf Technologien unter anderen Plattformen zugreifen können. Aber deine bestehenden Anwendungen laufen weiter.

Crushinator

2003-12-09, 12:23:35

Original geschrieben von Exxtreme
Es gibt schlicht und ergreifend Dinge, die für jede Plattform spezifisch sind. Nehmen wir zum Beispiel die Registry. Das Teil gibt's AFAIK ausschliesslich unter Windows. Wenn dein Programm viel mit der Registry arbeitet, dann kannste eine Portierung ohne viel Aufwand vergessen. =) Nichts leichter als das. Ich stand mal vor einer solchen Aufgabe und bog dann schließlich die benötigten API-Aufrufe innerhalb von 1 Std. auf Ini-Dateien alias *.conf um. :)
100%ig portabel wird man nie sein können mit C++ ausser man beschränkt sich auf reine Konsolenanwendungen. Man kann sich's aber leichter machen wenn man für mehrere Plattformen programmiert. Man muss zusätzlich einige Layer einschieben bezüglich I/O. Das stimmt, aber auch dafür gibt es Crossplattform-Libraries. Es ist nur eine Frage, ob man die Anwendung von Anfang an mit dem Hintergedanken es portierbar zu halten entwickelt hat.

grakaman

2003-12-09, 12:28:41

Original geschrieben von crushinator
=) Nichts leichter als das. Ich stand mal vor einer solchen Aufgabe und bog dann schließlich die benötigten API-Aufrufe innerhalb von 1 Std. auf Ini-Dateien alias *.conf um. :)

Und wenn eine Applikation auf COM Komponenten basiert oder gar COM+ Services benutzt? Spätestens dann kommst du einfach nicht von der Registry weg.

edit: Aber Konfigurationsdateien zu benutzen, ist eine gute Idee. Unter .NET sollte man auch nur noch XML Konfigurationsdateien verwenden.

Crushinator

2003-12-09, 12:33:08

Original geschrieben von grakaman
Am besten mal bitte Code posten. Anhand von irgendwelchen Kollegen oder Storys kann man ja schlecht ernsthafte Rückschlüsse auf das Framework schließen. Das Framework hat a) kein normales Printer-Object und b) kann ich den Code nicht posten, da ich damit meinen Arbeitsvertrag verletze.
Wie entwickelst du bitten eine plattformunabhängige Applikation, die distributed Transaction, Object Pooling etc. benutzt? .NET greift da zwar noch auf COM+ zu, aber das Problem wurde zumindest über Interop abstrahiert. Es ist also ein leichtes bei der Portierung des Frameworks, dass die entsprechenden managed Klassen dann aben auf Technologien unter anderen Plattformen zugreifen können. Aber deine bestehenden Anwendungen laufen weiter. Kurze Antwort: CORBA-Implementierungen und das, was damit nicht realisierbar ist, interessiert mich in der Regel auch nicht. =)

grakaman

2003-12-09, 12:45:37

Original geschrieben von crushinator
Das Framework hat a) kein normales Printer-Object und b) kann ich den Code nicht posten, da ich damit meinen Arbeitsvertrag verletze.

Außerdem, wie willst du denn überhaupt auf einem PPC drucken, per Infrarot oder wie? Das geht wohl imho nur über WLAN, wenn ein Netzwerkdrucker vorhanden ist. Und das .NET Framework besitzt freilich ein Druckobjekt und das verhält sich genauso wie das Grafiksobject bei Winforms. Du brauchst dazu nur die PrintDocument Klasse und löst dort das Print Ereignis aus. Drucker etc. kannst du auch einstellen.

Kurze Antwort: NET .... :bäh:

Crushinator

2003-12-09, 13:43:01

Original geschrieben von grakaman
Außerdem, wie willst du denn überhaupt auf einem PPC drucken, per Infrarot oder wie? Das geht wohl imho nur über WLAN, wenn ein Netzwerkdrucker vorhanden ist. Und das .NET Framework besitzt freilich ein Druckobjekt und das verhält sich genauso wie das Grafiksobject bei Winforms. Du brauchst dazu nur die PrintDocument Klasse und löst dort das Print Ereignis aus. Drucker etc. kannst du auch einstellen. a) Schau' Dir das Compact-Framework bitte nur ein einziges mal an bevor Du sowas verzapfst :bäh: und b) ja, es gibt sowohl PPCs als auch mobile Drucker, die sowohl irDa als auch RS232 haben, ganz zu schweigen davon c) daß es schwierig wird auch noch ein WLAN Access-Point zum mobilen arbeiten mitzunehmen. :D

PS: So doll ist des auch NET. ;)

grakaman

2003-12-09, 14:41:00

Original geschrieben von crushinator
a) Schau' Dir das Compact-Framework bitte nur ein einziges mal an bevor Du sowas verzapfst :bäh: und b) ja, es gibt sowohl PPCs als auch mobile Drucker, die sowohl irDa als auch RS232 haben, ganz zu schweigen davon c) daß es schwierig wird auch noch ein WLAN Access-Point zum mobilen arbeiten mitzunehmen. :D

PS: So doll ist des auch NET. ;)

Ich muss zugeben, das Drucken habe ich mir nicht beim C Framework angesehen, sondern mich nur mal kurz mit ASP.NET Mobile Controls beschäftigt :-( Aber im schlimmsten Fall müsste das doch über PInvoke gehen.

MfG

Crushinator

2003-12-09, 15:32:29

Original geschrieben von grakaman
(...) Aber im schlimmsten Fall müsste das doch über PInvoke gehen. Womit wir dann wieder ganz am Anfang sind, nämlich es nicht mit .NET Hausmitteln erschlagen zu können. ;(

grakaman

2003-12-09, 15:53:00

Original geschrieben von crushinator
Womit wir dann wieder ganz am Anfang sind, nämlich es nicht mit .NET Hausmitteln erschlagen zu können. ;(

Was genau für ein PPC ist das denn (Hersteller)?

MfG

Crushinator

2003-12-09, 16:41:08

Die "Industrie tauglichen" PPCs sind von der britischen Firma Symbol und heißen PPT 2800 (http://www.symbol.com/products/mobile_computers/mobile_ppc_ppt2800.html).

/edit: Ich habe mich mit britisch geirrt, sie sind aus den USA, nur mein Ansprechpartner sitzt im EMEA-Office in UK.

grakaman

2003-12-09, 21:40:27

Ich habe folgenden Link in der msdn NG dazu gefunden:

http://groups.google.com/groups?q=compactframework+printing&ie=UTF-8&oe=UTF-8&hl=en

Da sind einige interessante Links dabei. Von HP gibt es ein printer SDK, was glaube ich auch mit anderen PDA's funktionieren müsste. Dann gibt es von Symbol ein Mobility Kit, was viele Drucker unterstützt. Einfach mal die Links durchstöbern.

MfG

Haarmann

2003-12-09, 22:22:11

Demirug

Natürlich ist X86 Assembler nicht ideal portierbar. Es reicht, wenn mans soso lala mal rüber kriegte. Imho noch immer schneller als ein Emu. Mehr will man ja kaum erreichen.

Ich glaube ich war bisher immer nur zu faul um Probleme zu generieren. Das liegt sicherlich an meiner Vorliebe für Objekte, die ich bereits gar nicht erst selbst erschaffe... Bin klassischer "Flachprogger" und werde das auch bleiben.

grakaman

2003-12-09, 22:26:04

Demirug

2003-12-09, 22:37:22

Original geschrieben von Haarmann
Demirug

Natürlich ist X86 Assembler nicht ideal portierbar. Es reicht, wenn mans soso lala mal rüber kriegte. Imho noch immer schneller als ein Emu. Mehr will man ja kaum erreichen.

Ich glaube du bringst da gerade etwas durcheinader. Die CLR (damit werden .Net Programme ausgeführt) emuliert nicht eine CPU die MSIL versteht. Der MSIL Code wird Funktionsweise vor der Verwendung einem Compiler übergeben. Im Prinzip ist das nichts anderes als den letzten Pass eines 3 Pass Compilers auf die Zielmaschine zu überführen. Ein "normaler" Compiler arbeitet ja nach dem folgenden Prinzip

1. Quellcode parsen und in Zwischencode übersetzten
2. Zwischencode optimieren
3. Zwischencode in den Maschinencode der Zielcpu übersetzen und optimieren.
4. Programm beim Kunden instalieren

Braucht man eine andere Sprachen tauscht man den ersten Teil aus. Hat man es mit einer anderen CPU zu tun wird der dritte teil ausgetauscht.

Bei .Net läuft das ganze jetzt wie folgt ab.

1. Quellcode parsen und in MSIL übersetzten
2. MSIL optimieren und speichern.
3. Programm beim Kunden instalieren.
4. MSIL laden und vor der Verwendung in den Maschinencode übersetzten

Haarmann

2003-12-09, 23:14:58

Demirug

Ich glaube wir reden von 2 Paar Schuhen...
Ich jedenfalls redete nicht von explizit .NET. Dementsprechend bitte nicht auf das beziehen - sonst gehts wohl schief.

Demirug

2003-12-10, 07:38:10

Original geschrieben von Haarmann
Demirug

Ich glaube wir reden von 2 Paar Schuhen...
Ich jedenfalls redete nicht von explizit .NET. Dementsprechend bitte nicht auf das beziehen - sonst gehts wohl schief.

Das MSIL war ja jetzt nur als Beispiel für Bytecode der gejittet wird gemeint.

Eine Portierung von x86 Code sehe ich ehrlich gesagt nur als Notlösung. Es wurde ja einmal versucht und es hat auch funktioniert allerdings war die Performance nicht wirklich gut. Und je besser der Code auf x86 optimiert war desto schlechter war er zu portieren.

Um es einmal mit den Worten von Zeckensack zu sagen. Beim Compilieren in den CPU-Code geht zuviel Semantik verloren.

Ich verstehe ja durchaus deine Überlegungen. Der grösste Teil aller Computer läuft auf einer x86 Basis. Also macht es auch durchaus Sinn Anwendungen primär auf dieser Basis zu erstellen. Aber gerade solange das jeder macht wird sich nicht daran ändern das wir x86 am Hals haben. Den wer kauft sich ein System mit einer anderen CPU wenn seine Software dort dann plötzlich langsamer oder überhaupt nicht läuft? Da werden sich nur sehr wenige finden.

Haarmann

2003-12-10, 09:18:03

Demirug

Es könnte aber immerhin mal das SW Problem für andere Plattformen entschärfen. Leistung hat man imho Heute genug, so dass man auch mal 50% verlochen kann, wenns wirklich dringend ist (Das ist keine Aufforderung zu .NET und JAVA). Besonders bei CS Anwendungen mit dünnen Klienten kann man sich sowas wohl guten Gewissens erlauben, auch wenn mir da Chrushinators Variante mehr entspricht, dass man nur ne ZwischenAPI nimmt, die es auf allen nötigen Systemen gibt, die sich ja inzwischen finden lässt, so man denn will. Natürlich braucht sowas voraussicht seitens der Leute, die sowas durchziehen, die imho fast immer fehlt.

aths

2003-12-10, 09:25:00

Original geschrieben von Haarmann
Leistung hat man imho Heute genug, so dass man auch mal 50% verlochen kann, Original geschrieben von Haarmann
Wenn ich 3GHz habe, dann will ich nicht, dass irgendwas daraus ne Geschwindigkeit macht, die man auch mit 1GHz der selben CPU erreichen könnte... Ich hasse Verschwendung und es ist imho auch ne Frage des Umweltschutzes. Stromverbrauch und Resourcenverbrauch lassen grüssen - aber Wachstum ist ja wichtiger als unser Planet...:???:

Was denn nun?

Haarmann

2003-12-10, 11:01:00

aths

Es besteht ein Unterschied, ob man für eine Anwendung, die man einfach portieren will, 50% verlocht oder das ganze System ausbremst. Braucht die Anwendung nur 20% CPU Zeit, dann sinds ja eigentlich auch keine 50% mehr.

Ich dachte ich hätte irgendwo noch ein "zur Not" hingesetzt, aber offenbar ist das nicht der Fall gewesen. Dementsprechend bitte mental einfügen. Dann ergibts den Sinn, den ich erdacht, aber offenbar nicht formuliert hab.

Crushinator

2003-12-10, 11:40:11

Original geschrieben von grakaman
(...) Dann gibt es von Symbol ein Mobility Kit, was viele Drucker unterstützt. Einfach mal die Links durchstöbern. Klar, womit wir uns wieder auf einen Hersteller einschießen, was nicht ganz der Sinn des Ganzen sein sollte. Egal, inzwischen hab' ich die relativ simple Anwendung mit embedded VC++ und dem Symbol SDK nativ geschrieben, was dem Kollegen durch die enorme Ablaufgeschwindigkeit auf dem mit einem 206 MHz StrongARM ausgestatteten Gerät - ganz im Gegensatz zu seiner .NET Variante - doch "etwas" besser gefiel.

grakaman

2003-12-10, 12:06:35

Original geschrieben von crushinator
Klar, womit wir uns wieder auf einen Hersteller einschießen, was nicht ganz der Sinn des Ganzen sein sollte. Egal, inzwischen hab' ich die relativ simple Anwendung mit embedded VC++ und dem Symbol SDK nativ geschrieben, was dem Kollegen durch die enorme Ablaufgeschwindigkeit auf dem mit einem 206 MHz StrongARM ausgestatteten Gerät - ganz im Gegensatz zu seiner .NET Variante - doch "etwas" besser gefiel.

Also hast du doch das Symbol SDK auch benutzt, wo ist denn jetzt der Unterschied?

Crushinator

2003-12-10, 12:25:01

Original geschrieben von grakaman
Also hast du doch das Symbol SDK auch benutzt, wo ist denn jetzt der Unterschied? Der Unterschied liegt darin, daß die Nativ-Anwendung nach meinen Messungen ca. 800% schneller arbeitet. Wenn ich eh' schon darauf angewiesen bin, herstellerspezifische SDKs zu verwenden, kann ich auch gleich auf .NET verzichten und nehme dafür dankend die Geschwindigkeit.

aths

2003-12-10, 13:29:23

Original geschrieben von Haarmann
aths

Es besteht ein Unterschied, ob man für eine Anwendung, die man einfach portieren will, 50% verlocht oder das ganze System ausbremst. Braucht die Anwendung nur 20% CPU Zeit, dann sinds ja eigentlich auch keine 50% mehr.

Ich dachte ich hätte irgendwo noch ein "zur Not" hingesetzt, aber offenbar ist das nicht der Fall gewesen. Dementsprechend bitte mental einfügen. Dann ergibts den Sinn, den ich erdacht, aber offenbar nicht formuliert hab. Haarmann, ich versuche das größere Bild zu sehen. Entweder findet man es akzeptabel, CPU-Zeit zu verballern, nur um mehr Komfort zu haben. Unter Komfort verstehe ich sowohl die Portierbarkeit, als auch Speicherschutz und Swapping-Mechanismen. Oder man möchte immer maximale Geschwindigkeit, und nimmt die ganzen Nachteile inkauf.

Angenommen, alle Vorteile zusammen kosten glatt 50% Leistung. Dann muss man 12-18 Monate warten, danach ist die Leistung wieder da. Noch später gibts dann ohnehin wieder mehr Leistung, siehe Moorsches Gesetz. Man verliert aber erst mal 12-18 Monate. Imo holt man die aber durch geringeren Portierungs-Aufwand und durch weniger System-Abstürze auch wieder rein.

Hat man eine zeitkritische Anwendung, so wird diese ja in aller Regel auch auf Geschwindigkeit optimiert, weil sich für spezielle Probleme der Aufwand lohnt, dem Komfort zu vernachlässigen.

Haarmann

2003-12-10, 14:38:14

aths

Wir leben zZ in einer IT Welt ohne ideales OS mit mehr schlecht, denn rechten PRGs usw.

Wenn man daran was ändern will, dann gibts ne Übergangsfrist und die Notwendigkeit alte Sachen noch am Leben zu erhalten. Dementsprechend ists z.B. sinnvoller ne Architektur A abzusetzten und stattdessen B einzusetzen und gewisse Teile SW aus der A Zeit zu übernehmen, wenn diese auch nicht dem B Std entspricht. Man verliert dann zwar vs B Std 50%, aber das heist nicht, dass die SW aus A angepasst unter B halb so schnell ist, wie mit A.

Natürlich sollte die Folge davon nicht sein, dass man nun B mit SW von A zumüllt und gar nichts rein B entwickelt ;).

grakaman

2003-12-10, 15:42:10

Original geschrieben von Haarmann
aths

Wir leben zZ in einer IT Welt ohne ideales OS mit mehr schlecht, denn rechten PRGs usw.

Wenn man daran was ändern will, dann gibts ne Übergangsfrist und die Notwendigkeit alte Sachen noch am Leben zu erhalten. Dementsprechend ists z.B. sinnvoller ne Architektur A abzusetzten und stattdessen B einzusetzen und gewisse Teile SW aus der A Zeit zu übernehmen, wenn diese auch nicht dem B Std entspricht. Man verliert dann zwar vs B Std 50%, aber das heist nicht, dass die SW aus A angepasst unter B halb so schnell ist, wie mit A.

Natürlich sollte die Folge davon nicht sein, dass man nun B mit SW von A zumüllt und gar nichts rein B entwickelt ;).

Haarmann, wir leben in der Realität und nicht in einer idealen Welt. Es gibt nun mal verschiedenen Hardware- und Softwareplattformen, die wird es immer geben. Schon mal deshalb, weil wir in einer Gesellschaft leben, die vom Wettbewerb bestimmt ist. Es ist also folglich sinnvoll auf Interoperabilität zu achten. Aber ich verstehe immer noch nicht so richtig, was dich am Zwischencode stört. Die Geschwindigkeit kanns ja nicht sein.

Haarmann

2003-12-11, 00:03:24

grakaman

Gäbs wirklich Wettbewerb, hätten wir Heute OS/2 statt Windows, aber weil IBM noch nen offenes Antitrust Verfahren hatten, wolltens das nicht durchsetzen...
OS/2 ist nicht das beste OS, aber aus allen Murksereine ausgewäht (bedenke Haarmanns Ideal OS) isses dann doch das Beste.

Also wenn crushinator sagt, dass er sagenhafte 800% der .NET Leistung hat unter nem klassischen Kompiler, dann stört mich die Geschwindigkeit dann doch irgendwie... Dann muss ich mir mental nen 400 MHz Pentium 4 vorstellen und das erinnerte mich dann ca an nen P233MMX - Nein Danke.

aths

2003-12-11, 08:26:59

Original geschrieben von Haarmann
aths

Wir leben zZ in einer IT Welt ohne ideales OS mit mehr schlecht, denn rechten PRGs usw.... und in einer Welt, in dem ein Moorsches Gesetz bislang gegolten hat. Geschwindigkeit zu opfern sehe ich daher per se nicht als großes Problem, schon gar nicht bei Alltags-Anwendungen. Portierbarkeit und Maschinenunabhängigkeit sehe ich als viel wichtiger an. Paging- und Swapping-Mechanismen sind da z. B. praktisch unumgänglich. Und dass bei Java und Co. nicht direkt auf 86-er Code gegangen wird ist doch bestens. Andernfalls müsste man den Source neu compilieren, um z. B. neue CPU-Befehle nutzen zu können. Mit der aktuellen Lösung entfällt das, man kompiliert lediglich den Byte-Code neu.

grakaman

2003-12-11, 08:32:10

Original geschrieben von Haarmann
grakaman

Gäbs wirklich Wettbewerb, hätten wir Heute OS/2 statt Windows, aber weil IBM noch nen offenes Antitrust Verfahren hatten, wolltens das nicht durchsetzen...
OS/2 ist nicht das beste OS, aber aus allen Murksereine ausgewäht (bedenke Haarmanns Ideal OS) isses dann doch das Beste.

Das trifft vielleicht auf OS/2 Merlin zu (im Vgl. zu damals), aber laut meinen Erfahrungen nicht auf Warp 3.0. Und das war damals auch der Konkurrent zu Win95. Ich kann mich noch sehr gut an die TV Werbekampagnen beider erinnern. Und genau deswegen hat sich Win95 auch durchgesetzt, weil man realisitisch gedacht hat und auf Kompatibilität achtete. Frag dich doch mal warum es dein Lieblings OS immer mit W32 (W16???) Kompatibilitätsmodus gab. Übrigens fande ich Warp 3.0 total benutzerunfreundlich.

Also wenn crushinator sagt, dass er sagenhafte 800% der .NET Leistung hat unter nem klassischen Kompiler, dann stört mich die Geschwindigkeit dann doch irgendwie... Dann muss ich mir mental nen 400 MHz Pentium 4 vorstellen und das erinnerte mich dann ca an nen P233MMX - Nein Danke.

Es ging hier um das Drucken auf dem Compact Framework. Meine Versuche in Richtung CF habe ich bisher immer im VS.NET emuliert (Also auf dem Desktop) und auch da habe ich nie gedruckt. Deswegen kann ich dazu nichts genaueres sagen, aber laut NG gibt es das Problem wirklich. Auf dem Desktop trifft das aber 100% nicht zu! Dort bist du genauso schnell, wenn nicht schneller! Selbst wenn der Code bei der Ausführung noch gejittet werden muss, hast du mind. 90% der Leistung von C++ (ausser du greifst vielleicht exzessiv auf viele COM Komponenten zu). Du darfst nicht vergessen, MSIL ist ja ein Assembler Derivat. Einmal gejittet, greift die CLR dann immer auf den optimierten nativen Code zu. Also bist du sogar noch schneller als bei unoptimierten C++, was ja i.d.R der Fall ist. Nur wenn du die Files auf einen neuen Computer kopierst oder einen Neustart machst, muss bei der nächsten Ausführung wieder gejittet werden. Jedenfalls war das beim 1.0er Framework so. Und hier unterscheidet sich .NET auch von Java, denn der gejittete Code wird bei Java nicht gecached. Bei jedem Neustart des Programms wird da immer neu gejittet. Nur bei total komplexen und aufwändigen 3D Games könnte es unter dem jetzigen NET Framework zu Problemen kommen, wenn der GC sich einschaltet.

MfG

Haarmann

2003-12-11, 09:00:10

aths

Neue Befehle nutzten setzt A ne entsprechende VM voraus, pro CPU und nicht pro Architektur, und B auch nen entsprechenden Befehlssatz. Bei Letzterem lasse ich mich ja belehren, aber ersteres ist schlicht nicht vorhanden -> nette Theorie, keine Praxis.
Auch ist die Frage, ob diese VM nicht gerade die Leistung weniger bringen kann, denn man mit den neuen Befehlen rausholen wird...

Doppelt soviele Transistoren machten noch keine CPU doppelt so schnell ;).

grakaman

Wie lange lief Win95a stabil, so man sowas je behaupten konnte? Wieviele Partitionen passten auf ne durchaus bezahlbare 9GB HD und wieviel Kapazität lag damit unter 95a brach? Der Slack bei Win95a frass schon bei 2GB nette 20% der Kapazität weg. Ich nutzte OS/2 seit 2.1 und war sehr zufrieden, denn echte OS/2 Anwendungen waren ein Segen mit der Möglichkeit alles aus den Dropdowns auf die Iconleisten zu pappen mit Drag&Drop. Man konnte sogar MP3 hören und arbeiten ;). Das ganze lief lange als OS auf nem DX4 Notebook mit 8MB RAM und das schon zu 3.1 Zeiten. Im Gegensatz zum normalen 3.1 stürzte einem dort aber nicht gleich alles ab... Das Dashboard nutzte ich allerdings auch nie.

Crushinator

2003-12-11, 14:53:16

Original geschrieben von grakaman
(...) Auf dem Desktop trifft das aber 100% nicht zu! Dort bist du genauso schnell, wenn nicht schneller! Selbst wenn der Code bei der Ausführung noch gejittet werden muss, hast du mind. 90% der Leistung von C++ (ausser du greifst vielleicht exzessiv auf viele COM Komponenten zu). Das stimmt so nicht ganz, denn ja nach verwendetem Compiler ist .NET Code zwischen 10% und 80% langsamer. Selbst der VC++ 6 erzeugt teilweise 20% schnelleren Nativ-Code als der Neuere aus dem VS.NET, und wir wollen erst gar nicht anfangen vom Intel-Compiler zu sprechen. ;)
(...) Nur bei total komplexen und aufwändigen 3D Games könnte es unter dem jetzigen NET Framework zu Problemen kommen, wenn der GC sich einschaltet. Ich halte mich da einfach an die Logik, die mir sagt, daß Anwendungen um so langsamer werden, je mehr fette Schichten durch Runtimes zwischen ihnen und der eigentlichen API liegen. Wenn ich eine Anwendung habe, die rein gar nichts von den ach so toll klingenden OLE- alias COM(+) Komponenten geschweige denn Webservices Gebrauch machen muß, sehe ich nicht die geringste Notwendigkeit, das fette Runtime zu bemühen.

grakaman

2003-12-11, 16:16:05

Original geschrieben von crushinator
Das stimmt so nicht ganz, denn ja nach verwendetem Compiler ist .NET Code zwischen 10% und 80% langsamer. Selbst der VC++ 6 erzeugt teilweise 20% schnelleren Nativ-Code als der Neuere aus dem VS.NET, und wir wollen erst gar nicht anfangen vom Intel-Compiler zu sprechen. ;)

Wie gesagt, wenn einmal kompiliert, ist der Code genauso schnell oder schneller als C++. Ich wüßte nicht warum in unmanaged C++ optimierter Code schneller sein sollte als nativer Code aus der MSIL. Außer vielleicht, dass einige Compiler besser optimieren als andere. Und du kannst ja auch schon gleich beim Deployen den Code komplett jitten (ngen.exe), dann läuft die Anwendung sofort genauso schnell/schneller als unmanaged C++ Code. Ich hab auch ehrlich gesagt persönlich noch keinen Performanceunterschied gesehen, bestes Bsp. ist ja VS.NET. Das läuft ja wirklich total schnell. Das soll aber nicht heißen, dass es den nicht geben kann. Das Problem sehe ich da eher, wenn bei komplexen 3D Grafikanwendungen permanent tonnenweise MB's durchs RAM fließen. Dann kann schon mal der GC für ein paar Aussetzer sorgen (Threads werden ja beim säubern angehalten). Allerdings habe ich von 3D Entwicklung keine Ahnung (noch :)) und das sind nur Vermutungen, ev. kann da Demirug mehr sagen. Die Bsp. im DirectX SDK liefen aber ohne Probleme (Tiger - war wohl das aufw. Bsp).

Ich halte mich da einfach an die Logik, die mir sagt, daß Anwendungen um so langsamer werden, je mehr fette Schichten durch Runtimes zwischen ihnen und der eigentlichen API liegen. Wenn ich eine Anwendung habe, die rein gar nichts von den ach so toll klingenden OLE- alias COM(+) Komponenten geschweige denn Webservices Gebrauch machen muß, sehe ich nicht die geringste Notwendigkeit, das fette Runtime zu bemühen.

OLE hat mit COM+ so nichts zu tun ;) Und COM+ ist in unmanaged C++ geschrieben und gibts schon seit vielen, vielen Jahren (hieß vor W2k MTS). Und das benutzt btw. jede ernstzunehmende Anwendung in kritischen Umgebungen (wegen distributed Transaction, Object Pooling, JIT etc.). ;) MSMQ ist ebenfalls ein äußerst nettes Feature und für skalierbare Anwendungen sehr vorteilhaft. Freilich benutzt du das nicht überall, es macht ja auch nicht immer Sinn. Außer bei Installern ist das recht praktisch, wegen der distributed Transaktionsunterstützung von COM+.
Unter .NET gibt es noch keine komplette managed Implementierung von COM+, nur Klassen, die das wrappen und die Benutzung erheblich vereinfachen. Ansonsten ist das Framework eine komplett "neue" API. Mit WinFX ist die ganze Windows API dann "komplett" in managed Code verfügbar.

Crushinator

2003-12-11, 20:18:45

Original geschrieben von grakaman
(...) Ich hab auch ehrlich gesagt persönlich noch keinen Performanceunterschied gesehen, bestes Bsp. ist ja VS.NET. Das läuft ja wirklich total schnell. (...) Dann laß uns bitte darauf einigen, daß Deine und zumind. meine Deffinition von "schnell" sich gravierend unterscheiden. ;)
OLE hat mit COM+ so nichts zu tun ;) Und COM+ ist in unmanaged C++ geschrieben und gibts schon seit vielen, vielen Jahren (hieß vor W2k MTS). (...) Naja, COM+ (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/htm/complusportal_9o9x.asp) ist die Vereinheitlichung von OLE später -> COM/DCOM und dem MTS und nichts weiter. Auf den Rest gehe ich jetzt nicht mehr ein, weil Du mich wahrscheinlich gar nicht verstehen möchtest, wenn ich schreibe, daß wenn die Anwendung NICHTS von COM(+) und generell Verteilungsmechanismen braucht, weil es a) zu 80% auf einem PC ohne eine Netzwerkverbindung läuft und b) ganz allein in der Lage ist seine anfallenden Daten zu verwalten und c) Controls benutzt, welche in Source-Form vorliegen, außerdem sprachen wir ursprünglich von einem fetten Runtime also dem CLR von .NET und nicht vom Objektmodell bzw. dem DTS. ;)

PS: Nicht daß wir uns falsch verstehen, ich benutze sehr wohl verteilte Objektmodelle allerdings hauptsächlich nativ, CORBA-basiernd und manchmal sogar DCOM auf Linux (http://www.softwareag.com/entireX/download/), aber eben nur da wo es Sinn ergibt bzw. wo es anders nicht geht. Denn die ganze Sache dient nur zur vereinfachung der Interkommunikation zwischen verscheidenen "Komponenten" von ggf. verschiedenen Herstellern bzw. Plattformen und stellt das Ganze - durch komplexe Modelle - auf durchdachte Beine, Selbstzweck ist es jedoch nicht. Gute Anwendungen sind meist nach der KISS-Methode (keep it stupid simple) entwickelt.

grakaman

2003-12-11, 21:49:22

Original geschrieben von crushinator
Dann laß uns bitte darauf einigen, daß Deine und zumind. meine Deffinition von "schnell" sich gravierend unterscheiden. ;)
Naja, COM+ (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/htm/complusportal_9o9x.asp) ist die Vereinheitlichung von OLE später -> COM/DCOM und dem MTS und nichts weiter. Auf den Rest gehe ich jetzt nicht mehr ein, weil Du mich wahrscheinlich gar nicht verstehen möchtest, wenn ich schreibe, daß wenn die Anwendung NICHTS von COM(+) und generell Verteilungsmechanismen braucht, weil es a) zu 80% auf einem PC ohne eine Netzwerkverbindung läuft und b) ganz allein in der Lage ist seine anfallenden Daten zu verwalten und c) Controls benutzt, welche in Source-Form vorliegen, außerdem sprachen wir ursprünglich von einem fetten Runtime also dem CLR von .NET und nicht vom Objektmodell bzw. dem DTS. ;)

DCOM und COM+ sind getrennte Dinge. Und COM+ braucht man freilich nicht nur bei irgendwelchen Netzwerksachen, sondern überall wo a) Performance, b) Konsistenz, c) Skalierbarkeit und d) Sicherheit gefragt ist ;) Wobei NET viel mehr Möglichkeiten bietet als nur Role based Security wie unter COM+.
Noch ein Bsp. zu Verteilten Transaktionen.: Du hast eine Installation, wo viele Dinge gemacht werden: Dateien kopieren, Komponenten registrieren, eventuell Konfigurationsfiles schreiben, Datenbanken erstellen oder irgend etwas anders, egal was. Wenn nun eine Operation, in irgend einer Art und Weise fehl schlägt, hast du einen inkosistenten Zustand. Stell dir mal vor, bei der Installation tritt ein Fehler auf oder dein Programm crashed und in der Registry sind ein paar Komponenten registriert, aber nicht alle. Ein paar Files wurden kopiert, aber nicht alle. Auf Deutsch, ist scheiße gelaufen. Und genau deswegen gibts Verteilte Transaktionen.
Übrigens, die Runtime zu COM+ liegt im system32 Verzeichnis (komm jetzt nicht auf den Namen). Ich wollte das nur mal sagen, denn es ist wirklich nicht so, dass das nicht sinnvoll wäre und durchaus zu benutzen ist. Bei .NET untersützten zum Glück die Installationen automatisch Verteilte Transaktionen von COM+. COM+ ist aber noch eine Menge mehr, da kenne ich auch nur einen Bruchteil von.

PS: Nicht daß wir uns falsch verstehen, ich benutze sehr wohl verteilte Objektmodelle allerdings hauptsächlich nativ, CORBA-basiernd und manchmal sogar DCOM auf Linux (http://www.softwareag.com/entireX/download/), aber eben nur da wo es Sinn ergibt bzw. wo es anders nicht geht.

Ich sehe jetzt hier nicht den genauen Bezug zu COM+ :???:
Und warum sollte COM+ nicht nativ sein? Es ist doch alles nativ und auch unter .NET läuft es nativ. Unter .NET muss halt nur hin- und hergemarshalled werden, was in der Tat etwas Performance kosten kann. Aber das wird ja im 1.2er NET Framework unter WinFX alles anders ;)

Denn die ganze Sache dient nur zur vereinfachung der Interkommunikation zwischen verscheidenen "Komponenten" von ggf. verschiedenen Herstellern bzw. Plattformen und stellt das Ganze - durch komplexe Modelle - auf durchdachte Beine, Selbstzweck ist es jedoch nicht. Gute Anwendungen sind meist nach der KISS-Methode (keep it stupid simple) entwickelt.

Mmmhm, ich glaube du verwechselst hier etwas. COM+ sind lediglich Services, die zum Windows DNA gehören.

MfG

Crushinator

2003-12-12, 12:09:21

Original geschrieben von grakaman
DCOM und COM+ sind getrennte Dinge. Und COM+ braucht man freilich nicht nur bei irgendwelchen Netzwerksachen, sondern überall wo a) Performance, b) Konsistenz, c) Skalierbarkeit und d) Sicherheit gefragt ist ;) Wobei NET viel mehr Möglichkeiten bietet als nur Role based Security wie unter COM+. Nehmen wir an, daß dem so wäre, dann versuche bitte mir zu erklären, was genau durch Verwendung von COM+ performanter sein sollte, als ein nativ Code, der direkt die Win32-API nutzt und nicht wie bei COM+ erst durch mehrere Schichten das ausführt, was zum selben Ziel führt.

Was genau ist mit Skalierbarkeit durch COM+ gemeint wenn ich schon selbst durch entsprechende Threads dafür sorge, daß die Performance der Standalone Anwendung auf dem PC soweit wie nur geht optimal verteilt wird, aber sicherlich kannst Du mir im Einzelnen erklären, was genau an meiner Überlegung falsch sei.
Noch ein Bsp. zu Verteilten Transaktionen.: Du hast eine Installation, wo viele Dinge gemacht werden: Dateien kopieren, Komponenten registrieren, eventuell Konfigurationsfiles schreiben, Datenbanken erstellen oder irgend etwas anders, egal was. Wenn nun eine Operation, in irgend einer Art und Weise fehl schlägt, hast du einen inkosistenten Zustand. Stell dir mal vor, bei der Installation tritt ein Fehler auf oder dein Programm crashed und in der Registry sind ein paar Komponenten registriert, aber nicht alle. Ein paar Files wurden kopiert, aber nicht alle. Auf Deutsch, ist scheiße gelaufen. Und genau deswegen gibts Verteilte Transaktionen.
Übrigens, die Runtime zu COM+ liegt im system32 Verzeichnis (komm jetzt nicht auf den Namen). :kratz2: Toll, jetzt mußt Du mir nur noch erklären, was bei mir schiefgehen sollte, wenn a) keine Komponenten registriert werden b) die Anwendung durch hinschmeißen in ein beliebiges Verzeichnis "installiert" wird und zu allerletzt c) die Anwendung und alles was sie an Treibern benötigen sollte, wegen (vorher angesprochen) fehlender Netzwerkverbindung manuell durch eine natürliche Person installiert wird?
Ich wollte das nur mal sagen, denn es ist wirklich nicht so, dass das nicht sinnvoll wäre und durchaus zu benutzen ist. Bei .NET untersützten zum Glück die Installationen automatisch Verteilte Transaktionen von COM+. COM+ ist aber noch eine Menge mehr, da kenne ich auch nur einen Bruchteil von. Ich gebe zu, daß vieles dieser Dinge in sogenannten Enterprise-Umgebungen mit vielen Windows-PCs/Servern Sinn machen, nur frage ich mich ernsthaft, warum ich solche Enterprise-Umgebungen viel heterogener und mit viel weniger Windows kenne. :D
Ich sehe jetzt hier nicht den genauen Bezug zu COM+ :???: Nochmal: COM+ beinhaltet auch (D)COM weil es COM/DCOM und MTS zusammenfaßt:

"COM+ builds on and extends applications written using COM, MTS, and other COM-based technologies. COM+ handles many of the resource management tasks that developers previously had to program, such as thread allocation and security."
Und warum sollte COM+ nicht nativ sein? Es ist doch alles nativ und auch unter .NET läuft es nativ. Unter .NET muss halt nur hin- und hergemarshalled werden, was in der Tat etwas Performance kosten kann. Aber das wird ja im 1.2er NET Framework unter WinFX alles anders ;) Eine .NET Anwendung ist managed und dadurch laufen nicht nur COM+-Aufrufe durch das CLR und werden gemanaged. Wenn man das Runtime umgehen möchte und dazu noch COM+ braucht, kann man die Anwendung nativ schreiben, wenn man Letzteres auch nicht braucht kann man es erst recht.
Mmmhm, ich glaube du verwechselst hier etwas. COM+ sind lediglich Services, die zum Windows DNA gehören. Nein, ich verwechsle nichts, ich brauch' sie nur meistens NICHT, weil ich meist Anwendungen entwickle, bei denen der Kunde auch in 10 Jahren noch Support möchte und ich zwangsläufig bei "Techniken" lande, die a) offener sind b) möglichst in Source-Form vorliegen und c) NICHT größtenteils auf Windows beschränkt sind.

grakaman

2003-12-12, 13:28:42

Original geschrieben von crushinator
Nehmen wir an, daß dem so wäre, dann versuche bitte mir zu erklären, was genau durch Verwendung von COM+ performanter sein sollte, als ein nativ Code, der direkt die Win32-API nutzt und nicht wie bei COM+ erst durch mehrere Schichten das ausführt, was zum selben Ziel führt.

Mit performant meinte ich natürlich spezielle Situationen, da trifft es hauptsächlich auf verteilte Anwendungen zu. Mit Object Pooling wird z.B. das erzeugte Objekt nach Benutzung wieder zurück in einen Pool gelegt und muss nicht wieder neu erstellt werden, wenn es ein anderer Client anfordert.

Was genau ist mit Skalierbarkeit durch COM+ gemeint wenn ich schon selbst durch entsprechende Threads dafür sorge, daß die Performance der Standalone Anwendung auf dem PC soweit wie nur geht optimal verteilt wird, aber sicherlich kannst Du mir im Einzelnen erklären, was genau an meiner Überlegung falsch sei.

Auch hier gilt die Skalierbarkeit mehr bei verteilten Anwendungen, obwohl das natürlich auch auf einem lokalen Rechner stattfinden kann, wenn dort Interprocesskommunikation stattfindet. Da hast du Recht, das braucht man normalerweise nicht bei normalen Desktopanwendungen.
Mit JIT wird z.B. das Objekt erst erstellt, wenn eine Methode aufgerufen wurde und nach Beenden dieser sofort wieder gelöscht. Object Pooling erhöht auch die Skalierbarkeit (siehe oben).
MSMQ ist auch sehr sinnvoll, weil man damit "richtig" asynchron Arbeiten kann (vorausgesetzt man braucht das). Bsp: Eine Anwendung übernimmt Bestellungen und kümmert sich um die Logik. Der Benutzer soll dann mit einer EMail benachrichtigt werden, der Zeitpunkt spielt aber eine untergeordnete Rolle. Dann kann man einfach die Objekte aus der einen Anwendung in der MSMQ speichern und eine andere Applikation kümmert sich um den Mailversand und greift, je nach Priorität, auf die Queue mit den Objekten (da kannst du jede beliebige Instanz einer Klasse drin speichern) und verschickt dann die Mails.

:kratz2: Toll, jetzt mußt Du mir nur noch erklären, was bei mir schiefgehen sollte, wenn a) keine Komponenten registriert werden b) die Anwendung durch hinschmeißen in ein beliebiges Verzeichnis "installiert" wird und zu allerletzt c) die Anwendung und alles was sie an Treibern benötigen sollte, wegen (vorher angesprochen) fehlender Netzwerkverbindung manuell durch eine natürliche Person installiert wird?

Nochmal, das hat mit Netzwerk nichts zu tun! Freilich verwendet man das auch in Netzwerkumgebungen, aber der Zweck ist doch daran nicht gebunden. Verteilt heisst hier, wenn mehrere Objekte an einer Transaktion partizipieren, nicht weil sie verteilt irgendwo auf verschiedenen Rechnern zugreifen müssen. Das kann so sein, muss aber nicht. Überall wo die Gefahr von Inkosistenz bei einer Reihe von Operationen besteht, ist Distributed Transaction sinnvoll. Wenn du das nicht brauchst, heisst das nicht, dass es niemand anderes braucht. Und der Installer war ja nur ein Bsp.

Ich gebe zu, daß vieles dieser Dinge in sogenannten Enterprise-Umgebungen mit vielen Windows-PCs/Servern Sinn machen, nur frage ich mich ernsthaft, warum ich solche Enterprise-Umgebungen viel heterogener und mit viel weniger Windows kenne. :D
Nochmal: COM+ beinhaltet auch (D)COM weil es COM/DCOM und MTS zusammenfaßt:
"COM+ builds on and extends applications written using COM, MTS, and other COM-based technologies. COM+ handles many of the resource management tasks that developers previously had to program, such as thread allocation and security."

Nein, COM+ und DCOM sind verschiedene Frameworks und bieten unterschiedliche Services an. DCOM ist rein nur für Remoting. Dass die auf COM basieren ist logisch, denn es wäre ja ziemlich blöd, wenn das nur unter C++ funktionieren würde.

Eine .NET Anwendung ist managed und dadurch laufen nicht nur COM+-Aufrufe durch das CLR und werden gemanaged. Wenn man das Runtime umgehen möchte und dazu noch COM+ braucht, kann man die Anwendung nativ schreiben, wenn man Letzteres auch nicht braucht kann man es erst recht.

COM+ hat aber ebenfalls eine Runtime. Natürlich muss NET Code, der auf COM+ zugreift durch die CLR und diese Ruft die legacy Objekte über die COM+ Runtime auf und kümmert sich um das Marshalling zwischen beiden Runtims. Das hat aber rein gar nichts damit zu tun, ob etwas nativ oder nicht nativ laufen muss, wenn eine Runtime im Spiel ist. Die Runtime "überwacht" ja nur in dem Fall. Dass dafür extra Prozessorleistung benötigt wird, ist klar (spielt aber hier eine untergeordnete Rolle). Und eine Runtime braucht man, um solche Services zu benutzen.

Um noch mal zu COM+ zu kommen. Wie angesprochen ist auch die Sicherheit sehr interessant (mehr für unmanaged C++ als unter NET). So kann ja deine Anwendung bestimmte Bereiche nur Administratoren zugänglich machen, oder Hauptbenutzer oder was weiss ich. Oder deine Anwendung reagiert unterschiedlich auf verschiedene Rollen. Vielleicht willst du ja auch bei der Installation neue Rollen für deine Applikation erstellen, die Möglichkeiten sind enorm.

MfG

Crushinator

2003-12-12, 15:30:30

@grakaman

Ich finde es toll, daß Du mir all dieses Zeug versuchst zu erklären, auch wenn ich es mehr oder weniger zwangsläufig durch die CORBA-basiernden DTSe kenne. Wir entfernen uns aber gerade weit vom eigentlichen Thema, nämlich ob es Sinn ergibt, so ziemlich alles als managed Code zu erzeugen oder nicht. Ich stehe jedenfalls auf dem Standpunkt, daß unsere Anwendungen, solange sie unter Windows laufen müssen, möglichst ohne jeglichen Extra Runtimes (welche z.B. nicht mit Win9x von Haus aus mitgeliefert werden) erstellt werden, um a) die bestmögliche "Out of the Box" Abwärtskompatibilität und b) die bestmögliche Performance mitzubringen. Dieser Standpunkt ist teilweise so extrem zu verstehen, daß ich in manchen Situationen es sogar bevorzuge, komplexe, meist technische Anwendungen ganz ohne MFC und unter alleiniger Verwendung der Win32-API zu schreiben. Dann habe ich zwar je nach Komplexität größere Executables, dafür aber die Gewissheit, daß es nichts an OS-, 3rd-P-Komponenten- oder Runtime-Updates geben kann, welche die Anwendung aus der Ruhe bringen könnten, ganz zu schweigen davon, daß dann die Performance der eigentlichen Aufgabe der Anwendung nur noch vom verwendeten Compiler und der eingesetzten x86-CPU abhängt. Wenn man gewährleisten möchte, daß auf jeder CPU die optimale Performance rauskommt, nimmt man am besten den Intel-C++ Compiler und sagt ihm, daß er den Code für alle von ihm unterstützten CPU-Typen erzeugen soll.

Was die Portierbarkeit angeht bin ich da auch relativ unabhängig, da wir ja sowas nicht zum ersten mal machen, was soviel heißt wie, daß entsprechende (in großen Mengen selbstgeschriebene) Klassen unsere verwendeten GUI-Elemente und den größten Teil der Win32-API 1:1 auf GCC, ProDev, CodeWarrior respektive VisualAgeC++ tauglichen Code abbilden können. Die Interkommunikation wird dann mit CORBA-Technik realisiert, weil sie bereits auf allen verwendeten Plattformen implementiert worden ist.

Nichtsdestotrotz sehe ich ein, daß die o.g. Vorgehensweise gut ausgearbeitete Templates zur Wiederverwendung braucht, und daß vielleicht nicht Jedermann soviel Aufwand mal betrieben hat oder gar die Zeit bekommt den Aufwand mal zu betrieben. Wenn man aber schon soweit ist, sehe ich nicht ein, warum man alles vom Bord werfen und nach Microsofts Nase tanzen soll.

zeckensack

2003-12-12, 16:17:26

grakaman, du drehst dich IMO etwas im Kreise :)

Wer keine COM-Objekte nutzt, braucht weder Klassen zu registrieren, noch braucht er verteilte Transaktionen. Du beschreibst lediglich, wie man Problemstellungen die sich ohne COM garnicht ergeben würden mit COM löst.

:kratz2:

Nicht dass ich das ganze über Gebühr abwerten möchte, aber bei weitem nicht jede Applikation braucht 'standardisierten' Datenbankzugriff, oder muss sich in MS-Office 'einpluggen' können oä.

Demirug

2003-12-12, 16:48:44

grakaman

2003-12-12, 16:53:52

Original geschrieben von zeckensack
grakaman, du drehst dich IMO etwas im Kreise :)

Wer keine COM-Objekte nutzt, braucht weder Klassen zu registrieren, noch braucht er verteilte Transaktionen. Du beschreibst lediglich, wie man Problemstellungen die sich ohne COM garnicht ergeben würden mit COM löst.

Zeckensack, verteilte Transaktionen gibt es doch nicht wegen COM. Wenn du z.B. eine Operation machst und Daten aus einer Datei liest und in eine andere Textdatei auf deinem Computer schreibst und irgend etwas geht schief, weil z.B. irgend eine Ausnahme ausgelöst wird, dann sorgt COM+ automatisch dafür, dass die Transaktion scheitert und ein Roleback erfolgt. Jetzt stell dir das nur noch in viel größeren Dimensionen vor, wo noch viel mehr Dinge gemacht werden (wohlmöglich noch Datenbankverarbeitungen) oder vielleicht voneinander abhängig sind. Es geht hier nur um "Konsistenz".

Crushinator

2003-12-12, 17:29:38

^^ Das muß man sich aber auch in der Praxis nur in größeren Dimensionen vorstellen, damit es den richtigen Sinn ergibt. Transaktionsbasiernde Dateioperationen und damit Rollbacks sind nämlich relativ einfach nachzubilden, und wenn was direkt beim Beschreiben von Dateien schiefgeht, kann man normalerweise davon ausgehen, daß etwas mehr auf der Maschine passiert ist, was bedeutet, daß ein Rollback seitens "Transaction Coordinator" mit größter Wahrscheinlichkeit auch nicht mehr funktionieren wird.

grakaman

2003-12-12, 18:12:41

Original geschrieben von crushinator
^^ Das muß man sich aber auch in der Praxis nur in größeren Dimensionen vorstellen, damit es den richtigen Sinn ergibt. Transaktionsbasiernde Dateioperationen und damit Rollbacks sind nämlich relativ einfach nachzubilden, und wenn was direkt beim Beschreiben von Dateien schiefgeht, kann man normalerweise davon ausgehen, daß etwas mehr auf der Maschine passiert ist, was bedeutet, daß ein Rollback seitens "Transaction Coordinator" mit größter Wahrscheinlichkeit auch nicht mehr funktionieren wird.

Naja, also es ist ja aber nun wirklich nichts besonderes, dass irgendwelche Ausnahmen auftreten können und sich ev. Programme aufhängen. Es haben sich doch schon oft mal Applikationen aufgehangen und dann war man froh, dass es sowas wie Speicherschutz gab und andere Prozesse und das OS selbst nicht betroffen war. Also ich bin jedenfalls froh, dass z.B. die Installation von VS.NET (die ja bei Komplettinstall. gute 30min dauert, wenn nicht länger) Transaktionen unterstützt. Ich hab das nämlich nur übers Netz installieren können (auf Arbeit), da mein Rechner kein DVD hier hat. Und da gab es auf Grund von falscher Nezwerkkonfig immer Ausnahmen in der Mitter der Installation und VS.NET konnte wenigstens einen Roleback durchführen. Also ich halte das für ein absolut nützliches Feature, natürlich nicht in jeder Situation. Und es beschränkt sich ja auch nicht nur auf IO Ebene. Aber z.B. überall wo Finanzielle Transakionen getätigt werden ist das imo ein "Muss".

Crushinator

2003-12-12, 19:03:22

Original geschrieben von grakaman
(...) Also ich halte das für ein absolut nützliches Feature, natürlich nicht in jeder Situation. Und es beschränkt sich ja auch nicht nur auf IO Ebene. Aber z.B. überall wo Finanzielle Transakionen getätigt werden ist das imo ein "Muss". Da gebe ich Dir ja auch 100%ig recht. Aber gerade bei dem angesprochenen Finnanzsektor wird großen Wert darauf gelegt, daß das eingesetzte DTS nicht nur auf Windows beschränkt ist, da noch kein Windows auf den Mainframes (http://www.ibm.com/de/pressroom/presseinfos/2002/020830_1.html) oder den Massiv-Parallel-Maschinen (http://www.ibm.com/software/success/cssdb.nsf/CS/NAVO-5DU23R?OpenDocument&Site=eserverpseries) namens RS/6000 SP (http://www.ibm.com/de/pressroom/presseinfos/2001/010117_2.html) alias pSeries (http://www.ibm.com/de/pressroom/presseinfos/2002/020327_1.html) "verfügbar" ist. ;)

zeckensack

2003-12-12, 19:29:00

Original geschrieben von grakaman
Zeckensack, verteilte Transaktionen gibt es doch nicht wegen COM. Wenn du z.B. eine Operation machst und Daten aus einer Datei liest und in eine andere Textdatei auf deinem Computer schreibst und irgend etwas geht schief, weil z.B. irgend eine Ausnahme ausgelöst wird, dann sorgt COM+ automatisch dafür, dass die Transaktion scheitert und ein Roleback erfolgt.Wenn meine Applikation keinen Schreibzugriff bekommt, oder nicht schreiben kann, dann kann sie diese Fehler mit jahrzehntealten Mitteln (Standard-C-Library) selbst lösen. Also bitte. Dann schreibe ich die Datei eben nicht ignorant ins Nirvana, und hoffe dass trotzdem irgendwas nützliches passiert, nein, dann breche ich den Schreibvorgang eben ab und schmeisse optional noch eine Fehlermeldung auf den Bildschirm.
Jetzt stell dir das nur noch in viel größeren Dimensionen vor, wo noch viel mehr Dinge gemacht werden (wohlmöglich noch Datenbankverarbeitungen) oder vielleicht voneinander abhängig sind. Es geht hier nur um "Konsistenz". Konsistenz kann man auch innerhalb der Applikations-Logik erschlagen, oder delegiert das eben an eine dahinterliegende Datenbank.

Was ist denn das für eine Applikation, die, sagen wir mal, eine Datei zum Lesen offenhat, und gleichzeitig von vorne nach hinten überschreibt? Das muss sowieso in die Hose gehen, selbst wenn keine Katastrophen passieren (ie "alte" Datensätze bleiben am gleichen Platz) ist es zumindest mal ineffizient.

Und exakt wohin rollt so eine Transaktion denn zurück? Da hätte ich auch lieber die Gewissheit (sprich: ich schreib's selbst), was denn nun im Fehlerfall passiert, anstatt nur zu wissen, dass irgendetwas passiert. Mal ganz davon abgesehen dass man - wie bereits geschrieben - die meisten Fehlerquellen eh durch anderes Design umgehen kann, und wenn nicht, ist wohl schlicht das Dateisystem kaputt.

Wer einen ATM über Excel automatisieren will, gehört sowieso blutig gepeitscht ...

zeckensack

2003-12-12, 19:33:25

Original geschrieben von grakaman
Naja, also es ist ja aber nun wirklich nichts besonderes, dass irgendwelche Ausnahmen auftreten können und sich ev. Programme aufhängen. Es haben sich doch schon oft mal Applikationen aufgehangen und dann war man froh, dass es sowas wie Speicherschutz gab und andere Prozesse und das OS selbst nicht betroffen war. Also ich bin jedenfalls froh, dass z.B. die Installation von VS.NET (die ja bei Komplettinstall. gute 30min dauert, wenn nicht länger) Transaktionen unterstützt. Ich hab das nämlich nur übers Netz installieren können (auf Arbeit), da mein Rechner kein DVD hier hat. Und da gab es auf Grund von falscher Nezwerkkonfig immer Ausnahmen in der Mitter der Installation und VS.NET konnte wenigstens einen Roleback durchführen. Also ich halte das für ein absolut nützliches Feature, natürlich nicht in jeder Situation. Und es beschränkt sich ja auch nicht nur auf IO Ebene. Aber z.B. überall wo Finanzielle Transakionen getätigt werden ist das imo ein "Muss". Case in point:
VS.NET ist MS-Software, und muss eben zu COM-Mitteln greifen, um COM-Probleme zu lösen.
Normale Installationen legen ein paar Verzeichnisse an, kopieren Dateien dort hinein, und schreiben einen neuen Schlüssel in die Registry.

Du kannst dir sicher selbst ausmalen, wieviel dabei schief gehen kann.

grakaman

2003-12-12, 19:37:05

Original geschrieben von zeckensack
Case in point:
VS.NET ist MS-Software, und muss eben zu COM-Mitteln greifen, um COM-Probleme zu lösen.
Normale Installationen legen ein paar Verzeichnisse an, kopieren Dateien dort hinein, und schreiben einen neuen Schlüssel in die Registry.

Du kannst dir sicher selbst ausmalen, wieviel dabei schief gehen kann.

VS.NET ist .NET und benutzt COM+ zumindest bei der Installation. Jeder Installer, der mit .NET gemacht wird unterstützt Verteilte Transaktionen, wenn du es möchtest. Ansonsten hat NET mit COM überhaupt nichts zu tun.

grakaman

2003-12-12, 19:39:41

Original geschrieben von zeckensack
Wenn meine Applikation keinen Schreibzugriff bekommt, oder nicht schreiben kann, dann kann sie diese Fehler mit jahrzehntealten Mitteln (Standard-C-Library) selbst lösen. Also bitte. Dann schreibe ich die Datei eben nicht ignorant ins Nirvana, und hoffe dass trotzdem irgendwas nützliches passiert, nein, dann breche ich den Schreibvorgang eben ab und schmeisse optional noch eine Fehlermeldung auf den Bildschirm.
Konsistenz kann man auch innerhalb der Applikations-Logik erschlagen, oder delegiert das eben an eine dahinterliegende Datenbank.

Was ist denn das für eine Applikation, die, sagen wir mal, eine Datei zum Lesen offenhat, und gleichzeitig von vorne nach hinten überschreibt? Das muss sowieso in die Hose gehen, selbst wenn keine Katastrophen passieren (ie "alte" Datensätze bleiben am gleichen Platz) ist es zumindest mal ineffizient.

Und exakt wohin rollt so eine Transaktion denn zurück? Da hätte ich auch lieber die Gewissheit (sprich: ich schreib's selbst), was denn nun im Fehlerfall passiert, anstatt nur zu wissen, dass irgendetwas passiert. Mal ganz davon abgesehen dass man - wie bereits geschrieben - die meisten Fehlerquellen eh durch anderes Design umgehen kann, und wenn nicht, ist wohl schlicht das Dateisystem kaputt.

Wer einen ATM über Excel automatisieren will, gehört sowieso blutig gepeitscht ...

Bsp.: Du schreibst etwas in eine bestehende Datei, dann erstellst du eine neue Datei und liest aus einer anderen dazu Informationen aus, die du dazu benötigst. Dabei gehst du bei der letzten Datei davon aus, dass es eine XML datei ist un benutzt deswegen auch XML Klassen. Nun ist das aber gar keine XML Datei und prompt gibts eine Ausnahme.
Nun stehen aber schon in deiner ersten Datei die neueingetragenen Informationen, obwohl die Transaktion (als logische Einheit) fehlgeschlagen ist.
COM+ macht nicht irgend etwas, sondern entweder die Transaktion funktioniert oder alles schlägt fehl und wird wieder im Ausgangszustand versetzt. So einfach ist das. Und das wird überall in Enterpriseumgebungen auf Windowssystemen eingesetzt, weil es notwendig ist.

grakaman

2003-12-12, 19:42:02

Original geschrieben von crushinator
Da gebe ich Dir ja auch 100%ig recht. Aber gerade bei dem angesprochenen Finnanzsektor wird großen Wert darauf gelegt, daß das eingesetzte DTS nicht nur auf Windows beschränkt ist, da noch kein Windows auf den Mainframes (http://www.ibm.com/de/pressroom/presseinfos/2002/020830_1.html) oder den Massiv-Parallel-Maschinen (http://www.ibm.com/software/success/cssdb.nsf/CS/NAVO-5DU23R?OpenDocument&Site=eserverpseries) namens RS/6000 SP (http://www.ibm.com/de/pressroom/presseinfos/2001/010117_2.html) alias pSeries (http://www.ibm.com/de/pressroom/presseinfos/2002/020327_1.html) "verfügbar" ist. ;)

Es wird aber auch im Bankenbereich auf Servern NT eingesetzt, wobei ich das nur von Bekannten gehört habe (z.B. CoBa) und nicht selbst bestätigen kann. Auch die Bahn hat ein riesiges NT Netzwerk.

zeckensack

2003-12-12, 20:00:33

Original geschrieben von grakaman
COM+ macht nicht irgend etwas, sondern entweder die Transaktion funktioniert oder alles schlägt fehl und wird wieder im Ausgangszustand versetzt. So einfach ist das. Und das wird überall in Enterpriseumgebungen auf Windowssystemen eingesetzt, weil es notwendig ist. Designfehler. Wenn man sowas unbedingt haben will, dann macht man es halt im Dateisystem (http://www.namesys.com/v4/v4.html#atomic_fs), wo es hingehört.

Denn - wir wiederholen uns - wenn das Dateisystem die Fehlerursache ist, hilft dir übergelagertes Rollback überhaupt nichts mehr. Wenn das Dateisystem nicht die Fehlerursache ist, dann ist die Applikation kaputt.

grakaman

2003-12-12, 20:04:16

Original geschrieben von zeckensack
Designfehler. Wenn man sowas unbedingt haben will, dann macht man es halt im Dateisystem (http://www.namesys.com/v4/v4.html#atomic_fs), wo es hingehört.

Denn - wir wiederholen uns - wenn das Dateisystem die Fehlerursache ist, hilft dir übergelagertes Rollback überhaupt nichts mehr. Wenn das Dateisystem nicht die Fehlerursache ist, dann ist die Applikation kaputt.

Und woher will dein Dateisystem wissen, welche Operationen alles zu einer Transaktion gehören?
PS. NTFS ist transaktionsorientiert, hat aber nichts mit der Problematik hier zu tun.

Demirug

2003-12-12, 20:15:02

Original geschrieben von zeckensack
Designfehler. Wenn man sowas unbedingt haben will, dann macht man es halt im Dateisystem (http://www.namesys.com/v4/v4.html#atomic_fs), wo es hingehört.

Denn - wir wiederholen uns - wenn das Dateisystem die Fehlerursache ist, hilft dir übergelagertes Rollback überhaupt nichts mehr. Wenn das Dateisystem nicht die Fehlerursache ist, dann ist die Applikation kaputt.

Und was machst du bei Transaktionen die nicht nur das Dateisystem betreffen?

Oder noch schlimmer. Transaktionen die über mehrer Rechner verteilt ablaufen müssen?

zeckensack

2003-12-12, 20:37:27

Original geschrieben von Demirug
Und was machst du bei Transaktionen die nicht nur das Dateisystem betreffen?Was sonst?
Wenn ich die Daten eines anderen Rechners manipulieren will, ist das auch wieder eine Dateisystem-Transaktion, nur eben auf dem anderen Rechner.
Dass eine Transaktion über's Netzwerk geht, kann ich kontrollieren. Die (Erfolgs-)Meldung von der Gegenseite auch.

Wenn dabei was schief geht, liegt's aber im Grunde sowieso wieder im Zuständigkeitsbereich des anderen Rechners. Um ein Rollback über's Netzwerk zu machen, muss ich erstmal den Ursprungs-Zustand über's Netzwerk holen (damit ich zur Not - im Zweifelsfall sowieso erfolglos - versuchen kann, diesen wiederherzustellen). Was das bringen soll, muss mir erstmal jemand erklären.
Oder noch schlimmer. Transaktionen die über mehrer Rechner verteilt ablaufen müssen? Siehe oben, nur noch komplizierter. Urzustand holen, Anfragen rausschicken, auf alle Antworten warten, checken, im Fehlerfall alles zurückrollen und dann dabei grandios scheitern.

Macht auch wirklich wahnsinnig viel Sinn, auf einem Server "Haben" und auf einem anderen Server "Soll" zu speichern, und das dann zu synchronisieren ...

Crushinator

2003-12-12, 20:39:51

Original geschrieben von grakaman
Es wird aber auch im Bankenbereich NT eingesetzt, wobei ich das nur von Bekannten gehört habe (z.B. CoBa) und nicht selbst bestätigen kann. Es wird im Bankensektor selbstverständlich auch auf NT/2K und zwar zu 80% bei Clients gesetzt, neben dem immer noch anzutrefenden OS/2. Ich meine aber mit Sicherheit zu wissen, daß die Finnanz-Transaktionen auf den großen Maschienen ausgeführt bzw. koordiniert werden und zwar hauptsächlich über CICS/TXSeries (http://www.ibm.com/software/htp/cics/txseries/), welche allerdings neben CORBA auch COM+ Schnittstellen bieten.

grakaman

2003-12-12, 20:43:08

Original geschrieben von crushinator
Es wird im Bankensektor selbstverständlich auch auf NT/2K und zwar zu 80% bei Clients gesetzt, neben dem immer noch anzutrefenden OS/2. Ich meine aber mit Sicherheit zu wissen, daß die Finnanz-Transaktionen auf den großen Maschienen ausgeführt bzw. koordiniert werden und zwar hauptsächlich über CICS/TXSeries (http://www.ibm.com/software/htp/cics/txseries/), welche allerdings neben CORBA auch COM+ Schnittstellen bieten.

Ja, soweit ich gehört habe haben die bei er DB ihre Client auf W2k umgestellt. Aber es wird auch im Serverbereich verwendet, natürlich nicht überall. Und! es wird ja oft immer nur in schwarz/weiß diskutiert, aber es laufen ja auch neben den üblichen Geschäften andere wichtige Projekte, wo extra Netzwerke für existieren.

grakaman

2003-12-12, 20:51:02

Original geschrieben von zeckensack
Was sonst?
Wenn ich die Daten eines anderen Rechners manipulieren will, ist das auch wieder eine Dateisystem-Transaktion, nur eben auf dem anderen Rechner.

Zeckensack, du kannst ja ein Objekt haben, von dem irgend eine Methode mehrere andere Objekte aufnimmt und bearbeitet ohne eine IO Operation zu machen.

Dass eine Transaktion über's Netzwerk geht, kann ich kontrollieren. Die (Erfolgs-)Meldung von der Gegenseite auch.

So? Interessant, wie möchtest du das bei Remoting herausfinden?

Wenn dabei was schief geht, liegt's aber im Grunde sowieso wieder im Zuständigkeitsbereich des anderen Rechners. Um ein Rollback über's Netzwerk zu machen, muss ich erstmal den Ursprungs-Zustand über's Netzwerk holen (damit ich zur Not - im Zweifelsfall sowieso erfolglos - versuchen kann, diesen wiederherzustellen). Was das bringen soll, muss mir erstmal jemand erklären.
Siehe oben, nur noch komplizierter. Urzustand holen, Anfragen rausschicken, auf alle Antworten warten, checken, im Fehlerfall alles zurückrollen und dann dabei grandios scheitern.

Macht auch wirklich wahnsinnig viel Sinn, auf einem Server "Haben" und auf einem anderen Server "Soll" zu speichern, und das dann zu synchronisieren ...

Das Stichwort liegt bei Distributed Transaction auf "Distributed". Es können auch 99% aller Operationen erfolgreich sein, wenn eine Fehl schlägt müssen alle fehl schlagen, auf allen anderen Rechnern.

Demirug

2003-12-12, 21:00:49

Original geschrieben von zeckensack
Was sonst?
Wenn ich die Daten eines anderen Rechners manipulieren will, ist das auch wieder eine Dateisystem-Transaktion, nur eben auf dem anderen Rechner.
Dass eine Transaktion über's Netzwerk geht, kann ich kontrollieren. Die (Erfolgs-)Meldung von der Gegenseite auch.

Wenn dabei was schief geht, liegt's aber im Grunde sowieso wieder im Zuständigkeitsbereich des anderen Rechners. Um ein Rollback über's Netzwerk zu machen, muss ich erstmal den Ursprungs-Zustand über's Netzwerk holen (damit ich zur Not - im Zweifelsfall sowieso erfolglos - versuchen kann, diesen wiederherzustellen). Was das bringen soll, muss mir erstmal jemand erklären.
Siehe oben, nur noch komplizierter. Urzustand holen, Anfragen rausschicken, auf alle Antworten warten, checken, im Fehlerfall alles zurückrollen und dann dabei grandios scheitern.

Macht auch wirklich wahnsinnig viel Sinn, auf einem Server "Haben" und auf einem anderen Server "Soll" zu speichern, und das dann zu synchronisieren ...

Haben und Soll auf unterschiedlichen Servern zu haben macht wirklich keinen Sinn. Es gibt allerdings Fälle in denen man es unvermeidlich mit unterschiedlichen Rechner zu tun hat.

Ich hatte mal einen Fall da hat Firma A etwas produziert. Allerdings gab es direkt bei der Anlage keine Lagermöglichkeit. Das Silolager für das Zeug war ein paar Kilometer entfernt und gehörte dazu auch noch Firma B. Die Grundstoffe für die Produktion waren vor Ort allerdings mussten diese mit anderen Produktionen geteilt werden.

Bevor nun ein Job gestartet werden konnte musste Silokapazität und die Pipeline für die richtigen Zeiträume reserviert werden. Dazu noch die Rohstoffmengen usw. usw. Und für jeden kremple gab es eigene Rechner und nur wenn alle Reservierungen erfolgreich waren durfte der Job zum gebene Zeitpunkt anlaufen. Ging aber irgendwas schief mussten alle bereits erfolgten Reservierungen wieder Rückgängig gemacht werden. Ich hatte dabei nur einen kleinen Job zu erledigen (Bereitstellen einer Schnittsstelle zu den Automatisierungssystemen) aber die Jungs die dafür das Transaktionssystem schreiben mussten haben ständig nur geflucht. Es gab eben noch nichts fertiges. Wenn du solche Dinge zurückrollen musst ist es wirklich praktisch wenn du einen Transaktionsmanager dafür hast.

Crushinator

2003-12-12, 21:01:29

Original geschrieben von zeckensack
Dass eine Transaktion über's Netzwerk geht, kann ich kontrollieren. Die (Erfolgs-)Meldung von der Gegenseite auch. Jo, ietzt stell' Dir nur noch vor, daß die Gegenseite nicht von Dir selbst geschrieben ist, und schon brauchst Du ein "standarisiertes" Verfahren, um mit ihr zu kommunizieren. Damit man das Rad NICHT immer wieder neu erfinden muß, kann man auf fertige Modelle greifen. Hauptsache es läßt sich "vernünftig" integrieren und ist überhaupt verfügbar.
Macht auch wirklich wahnsinnig viel Sinn, auf einem Server "Haben" und auf einem anderen Server "Soll" zu speichern, und das dann zu synchronisieren ... Es macht allerdings Sinn, eine Transaktion auf der Kreditverwaltung zu starten, parallel zu den nächsten, nämlich den Betragsbuchenden und später abhängig von der Freigabe des Kreditsystems zu committen oder zu rollbacken. :)

Xmas

2003-12-12, 21:22:48

Original geschrieben von zeckensack
Wenn dabei was schief geht, liegt's aber im Grunde sowieso wieder im Zuständigkeitsbereich des anderen Rechners. Um ein Rollback über's Netzwerk zu machen, muss ich erstmal den Ursprungs-Zustand über's Netzwerk holen (damit ich zur Not - im Zweifelsfall sowieso erfolglos - versuchen kann, diesen wiederherzustellen). Was das bringen soll, muss mir erstmal jemand erklären.
Wieso den Ursprungs-Zustand übers Netzwerk holen? Das kann doch der Rechner lokal tun. Und wenn der Rollback "im Zweifelsfall" scheitert, taugt dein Transaktionssystem an der Wurzel nix.

zeckensack

2003-12-12, 21:25:51

Original geschrieben von grakaman
Zeckensack, du kannst ja ein Objekt haben, von dem irgend eine Methode mehrere andere Objekte aufnimmt und bearbeitet ohne eine IO Operation zu machen.Wenn ich nur bis zum nächsten Absturz in flüchtigem Speicher arbeite, wofür soll ich mir dann Transaktionen ans Bein binden?

Der ganze Sinn ergibt sich doch daraus, dass man eben einen konsistenten Zustand in den nichtflüchtigen Daten haben will.

So? Interessant, wie möchtest du das bei Remoting herausfinden?Wenn eine lokal laufende Runtime das hinbekommt, dann sei dir versichert, dass es einen irgendwie gearteten Rückkanal gibt. Wenn es diesen nicht gibt, dann erkläre mir bitte warum das mit COM funktionieren sollte.

Das Stichwort liegt bei Distributed Transaction auf "Distributed". Es können auch 99% aller Operationen erfolgreich sein, wenn eine Fehl schlägt müssen alle fehl schlagen, auf allen anderen Rechnern. Ja.
Und wozu braucht man das, ausser für den Fall "zwei Konten, zwei Banken, zwei Server, eine Transaktion"?

Um im Firmennetzwerk Patches einzuspielen? =)
(die Frage ist nicht ernst gemeint, ich will Beispiele locken)

Mein Gefühl sagt mir, dass wenn mehr als zwei Rechner an einer Transaktion beteiligt sind, dann ist schon beim Design irgendwas schiefgelaufen. Sowas kann man immer in mehrere, kleinere Transaktionen splitten, die auch für sich gesehen noch Sinn machen.

Gerade dein VS.NET-Beispiel überzeugt mich absolut nicht.
if (platte_voll())
{
löschen();
mach_die_registry_wieder_sauber();
user_anbrüllen();
überlegen_ob_man_das_nicht_schon_vorher_hätte_ahnen_können();
return(false);
}

zeckensack

2003-12-12, 21:30:08

Original geschrieben von Xmas
Wieso den Ursprungs-Zustand übers Netzwerk holen? Das kann doch der Rechner lokal tun.Genau das wollte ich damit deutlich machen. Rollback über's Netzwerk, wenn nur ein Rechner überhaupt beteiligt ist, ist sinnlos.
Und wenn der Rollback "im Zweifelsfall" scheitert, taugt dein Transaktionssystem an der Wurzel nix. Exakt.
Wenn der Zugriffsversuch fehlschlägt, könnt's ja auch am Netzwerk liegen, oder daran, dass der Remote-Rechner vom Tisch gefallen ist.
Dann kann ich auch nicht "rollbacken".

Crushinator

2003-12-12, 21:32:47

:D

Ich glaub' aber daß grakamann eher das meinte:
if (NetzwerkInstallPath_wech())
{
löschen();
mach_die_registry_wieder_sauber();
admin_anbrüllen();
nein_das_haette_man_nicht_wissen_koennen();
return(false);
}
Original geschrieben von zeckensack
Wenn der Zugriffsversuch fehlschlägt, könnt's ja auch am Netzwerk liegen, oder daran, dass der Remote-Rechner vom Tisch gefallen ist. Dann kann ich auch nicht "rollbacken". Zu erfolgreichen D-Transaktionen gehören immer mehrere die ihr OK geben müssen. Wenn Teilnehmer A keine Erfolgsmeldung vom Coordinator (der kann auch auf ihm selbst laufen) bekommt, teilt er ihm auch nicht mit, daß er das OK empfangen hat, und Teilnehmer B wird nicht committen solange er das OK vom Coordinator bekommen hat. Erst wenn die letzte Aktion einer Transaktion bis zum letzten Byte (inkl. Sicherung für Rollback) erfolgreich abgeschlossen ist und alle dem Coordinator ihr OK gegeben haben gilt die gesamte Transaktion als abgeschlossen. Diesen Zustand teilt der Coordinator jedem Teilnehmer dann mit. Ansonsten sollte/würde alles nach einer gewissen Timeout-Zeit für ungültig erklärt und verworfen.

Demirug

2003-12-12, 21:41:25

Original geschrieben von zeckensack
Mein Gefühl sagt mir, dass wenn mehr als zwei Rechner an einer Transaktion beteiligt sind, dann ist schon beim Design irgendwas schiefgelaufen. Sowas kann man immer in mehrere, kleinere Transaktionen splitten, die auch für sich gesehen noch Sinn machen.

Nichts, gegen dein Gefühl aber hier täuscht es dich. Um zum Beispiel eine Bestellung abzuwickeln brauchst du schon mindesten 3 Systeme.

1. Dein eingens für die Lagerhaltung, Kundenverwaltung, usw.
2. Den Sever der Kreditkarten Geschelschaft wenn der Kunde mit seinem guten Namen bezahlen möchten.
3. Den Server des Packtservie damit das Zeug auch zum Kunden kommt.

Was dann auch noch passieren könnte ist das du dem Server deines Grosshändlers eine Bestellung zukommen lässt weil die Kundebestllung den Lagerbestand unter das Minimum bringt. Damit wären wir dann schon bei 4 Systemen.

Xmas

2003-12-12, 22:19:21

Original geschrieben von zeckensack
Genau das wollte ich damit deutlich machen. Rollback über's Netzwerk, wenn nur ein Rechner überhaupt beteiligt ist, ist sinnlos.
Davon habe ich aber nicht geredet. Wenn mehrere Rechner beteiligt sind, muss nicht der eine vom anderen den alten Zustand holen, sondern den behält jeder für sich. Nicht der alte Zustand wird übertragen, sondern nur der Auftrag zur Änderung, sowie die passende Erfolgsmeldung.

Exakt.
Wenn der Zugriffsversuch fehlschlägt, könnt's ja auch am Netzwerk liegen, oder daran, dass der Remote-Rechner vom Tisch gefallen ist.
Dann kann ich auch nicht "rollbacken".
Nein, dann kannst du nicht committen! Klar, wenn eine Festplatte defekt ist, können auch Transaktionen nicht viel helfen, da hilft nur Redundanz.
Wenns am Netzwerk liegt, gibts einen Timeout und die alten Daten bleiben (die müssen nicht "wiederhergestellt" werden, weil sie nie überschrieben wurden in einem wirklich sicheren Transaktionssystem).

zeckensack

2003-12-12, 22:22:18

Original geschrieben von Demirug
Nichts, gegen dein Gefühl aber hier täuscht es dich. Um zum Beispiel eine Bestellung abzuwickeln brauchst du schon mindesten 3 Systeme.

1. Dein eingens für die Lagerhaltung, Kundenverwaltung, usw.
2. Den Sever der Kreditkarten Geschelschaft wenn der Kunde mit seinem guten Namen bezahlen möchten.
3. Den Server des Packtservie damit das Zeug auch zum Kunden kommt.

Was dann auch noch passieren könnte ist das du dem Server deines Grosshändlers eine Bestellung zukommen lässt weil die Kundebestllung den Lagerbestand unter das Minimum bringt. Damit wären wir dann schon bei 4 Systemen. Und wenn der Grosshändler nicht liefern mag, dann hole ich mir das Paket vom Kunden zurück, oder wie? :kratz2:

Nachbestellen kann ich auch, wenn ich letztlich doch nichts verkauft habe. Geld eintreiben brauche ich frühestens wenn ich den Versand sicherstellen kann.
Stellt sich heraus dass der Kunde sowieso pleite ist, brauche ich erst garnicht zu verschicken. Habe ich schon verschickt, dann schmeisse ich eine Exception (http://www.russisch-inkasso.de/).

Es ist völlig utopisch und IMO auch unsinnig, dieses Bündel von Vorgängen zu einer Transaktion zusammenfassen zu wollen.

Nach unserem allgemeinen Konsens hier würde das ja bedeuten, dass wenn eine Sache schiefläuft, ich bestrebt bin alles rückgängig zu machen. Das kann's ja nun nicht sein, das Beispiel das ich suchte ...

zeckensack

2003-12-12, 22:38:39

Original geschrieben von Xmas
Davon habe ich aber nicht geredet. Wenn mehrere Rechner beteiligt sind, muss nicht der eine vom anderen den alten Zustand holen, sondern den behält jeder für sich. Nicht der alte Zustand wird übertragen, sondern nur der Auftrag zur Änderung, sowie die passende Erfolgsmeldung.Wir reden aneinandervorbei. Du bist schon bei der (über mehrere Rechner) verteilten Transaktion, während ich noch von einem ferngesteuerten Einzelsystem sprach.
Und da ist's wohl weniger fehlerträchtig, wenn die Transaktion am Zielort durchgesetzt wird, und nicht durch die Fernsteuerung.
Der Auftrag kann wohl eine Transaktion sein. Die Entscheidung, ob diese dann erfolgreich verlaufen ist oder eben nicht, muss aber nicht die Fernsteuerung treffen.

Hausfrauenbeispiel:
move \\rechnor\verzeichnis1\*.* \\rechnor\verzeichnis2\

Nein, dann kannst du nicht committen! Klar, wenn eine Festplatte defekt ist, können auch Transaktionen nicht viel helfen, da hilft nur Redundanz.
Wenns am Netzwerk liegt, gibts einen Timeout und die alten Daten bleiben (die müssen nicht "wiederhergestellt" werden, weil sie nie überschrieben wurden in einem wirklich sicheren Transaktionssystem). Hmmmm :)
Ein guter Grund, Transaktionen möglichst klein zu halten, sonst dauert das commit zu lange :naughty:

Xmas

2003-12-12, 22:44:49

Original geschrieben von zeckensack
Und wenn der Grosshändler nicht liefern mag, dann hole ich mir das Paket vom Kunden zurück, oder wie? :kratz2:

Nachbestellen kann ich auch, wenn ich letztlich doch nichts verkauft habe. Geld eintreiben brauche ich frühestens wenn ich den Versand sicherstellen kann.
Stellt sich heraus dass der Kunde sowieso pleite ist, brauche ich erst garnicht zu verschicken. Habe ich schon verschickt, dann schmeisse ich eine Exception (http://www.russisch-inkasso.de/).

Es ist völlig utopisch und IMO auch unsinnig, dieses Bündel von Vorgängen zu einer Transaktion zusammenfassen zu wollen.

Nach unserem allgemeinen Konsens hier würde das ja bedeuten, dass wenn eine Sache schiefläuft, ich bestrebt bin alles rückgängig zu machen. Das kann's ja nun nicht sein, das Beispiel das ich suchte ...
:???:
Der Kunde erklärt seine Bereitschaft zur Bestellung. Das erste System prüft nach ob das Produkt vorrätig ist und dass der Kunde nicht gesperrt ist/keine Schulden hat. Das zweite regelt die Bezahlung mit der Kreditkartengesellschaft, und das dritte erteilt dem Paketservice den Versandauftrag.
Das alles gehört zusammen, und wird alles "in einem Augenblick" erledigt, nicht erst nachdem schon versendet wurde. Scheitert eine der Aktionen wird entweder nachbestellt oder die Bestellung ganz einfach nicht akzeptiert.

Zugegeben, das Beispiel ist etwas unpassend, weil eine Bestellung auch dann akzeptiert wird wenn nachbestellt werden kann, oder auch wenn mal der Server des Paketdienstes ausfällt - es sei denn es handelt sich um einen Eilauftrag.

Gast

2003-12-13, 04:12:56

Haarmann

2003-12-13, 12:56:27

Demirug

Nichts, gegen dein Gefühl aber hier täuscht es dich. Um zum Beispiel eine Bestellung abzuwickeln brauchst du schon mindesten 3 Systeme.

1. Dein eingens für die Lagerhaltung, Kundenverwaltung, usw.
2. Den Sever der Kreditkarten Geschelschaft wenn der Kunde mit seinem guten Namen bezahlen möchten.
3. Den Server des Packtservie damit das Zeug auch zum Kunden kommt.

Was dann auch noch passieren könnte ist das du dem Server deines Grosshändlers eine Bestellung zukommen lässt weil die Kundebestllung den Lagerbestand unter das Minimum bringt. Damit wären wir dann schon bei 4 Systemen.

Nun irrst Du aber mal gewaltig (jaa ich wollte das immer mal sagen).

Erst nimmt man die Bestellung auf - entweder die kommt rein oder halt ned - das lässt sich aber deutlich zeigen. Dafür ist ja nur ein System zuständig. Nun wird die Bestellung ausgewertet, was nur lesende Zugriffe erfordert und dementsprechend Repeat bis es klappt erlaubt und keine Änderungen vornimmt. Gibts nun ein OK von all diesen Leseoperationen, weil alles funktioniert und die Bestellung an einen Kreditwürdigen Kunden ginge etc. , dann kann man das in der Bestellung vermerken. Nun wird erst das Lager benötigt und da es wieder nur ein System ist, geht auch das ohne Probleme über die Bühne und sonst muss sich das System selbst helfen. Ist das Lager fertig, kann man auch das in der Bestellung vermerken. Nun erst geht der Auftrag an den "Packservice" und je nach je wirds dort ankommen oder nicht - es ist wieder nur ein System beteiligt. In der Bestellung kann nun ein weiteres Mal ein "Kreux" gesetzt werden. Ists ausgelifert, dann gibts wieder nen Kreuz usw. Genau so funktionieren z.B. viele E-Distributionssysteme - auch zT auf M$ SW.

Es ging nur einmal was verloren bei nem Disti, aber das war nicht meine Bestellung. Der Grund dafür war ein einfacher... SAP ;). Das nutzte eben nicht dies einfache Konzept, welches sich vom klassischen Papierweg nicht unterscheidet und drum auch funktioniert.

Demirug

2003-12-13, 14:53:43

Haarmann, wenn ich gewusst hätte das man dich so einfach glücklich machen kann...

Ich fürchte das ich mich äuserst unglücklich ausgedrückt habe so das Zeckensack und du meine Aussage falsch verstanden haben.

Ich habe schlicht und ergreifend den gesamten Prozess der Bestllungsabwicklung mit dem Begriff Transaktion gleichgesetzt. In dem Moment muss mir ein alter Kunde durch den Kopf gegangen sein der diese Angewohnheit hatte den gesamten Vorgang als eine Transaktion zu sehen. Das was du und Zeckensack aber sicherlich mit Transaktion gemeint haben war ein Teilschritt des gesamten Vorgangs. Ich habe das bei diesem Kunden dann immer als Atomare-Transaktion bezeichnet.

In diesem Sinn hat Zeckensack natürlich Recht das ein System das bei einer Atomaren-Transaktion mehr als 2 Datenbanken braucht einen Designfehler hat. 3 Rechner könnten es allerdings denoch sein. 2 davon verwalten jeweils eine der Datenbanken und der 3 wickelt den Teilschritt gerade ab.

Was nun aber deine Kreuze (oder auch den Auftragsstatus) angeht so ist da bei weitem nicht nur ein System beteiligt. Nehmen wir uns einmal den Teilschritt der Kreditkartenbezahlung vor. Dieser Vorgang besteht aus mindestens 2 Teilaufgaben.

1. Belastung des Kreditkarten Kontos des Kunden
2. Aktualisieren des Auftragsstatus.

Dafür sind aber jeweils unterschiedliche Systeme zuständig. Desweiteren muss entweder beides durchgeführt werden oder eben nicht. Der perfekte Anwendungsfall für eine verteilte Transaktion. Für solche Sachen ist der DTC gedacht.

Was der DTC allerdings nicht kann ist für komplette Aufträge einen Rollback durchzuführen. Gerade weil es ja wie Zeckensack schön dargestellt immer wieder Teilaktionen gibt die nicht einfach zurückgenommen werden können. Für solche Fälle muss man dann im Zustandsdiagramm des Abwicklungssystem schon genau festlegen wie sich ein Abbruch zu einem beliebigen Zeitpunkt auswirkt.

GRiNSER

2003-12-13, 16:32:42

waah! warum müsst ihr gerade über transaktionen, commit und rollback reden wenn ich das gerade in der schule lerne?!:D
is ne interessante thematik!
btw: manchmal mag ich diese zufälle, meistens aber hasse ich sie - weil sie einfach zu oft vorkommen...

zeckensack

2003-12-13, 17:49:02

Original geschrieben von Gast
Um in deiner Sprache zu bleiben, es ist völlig utopisch und unsinnig ein Produkt vom Großhändler zu ordern, wenn es nicht benötigt wird.Benötigt wird es, wenn das Lager leerläuft. Auch wenn ein einzelner Kunde storniert, dann macht das die Nachbestellung noch lange nicht unsinnig.

Der Zustand "Lager läuft leer" hat nur sehr entfernt etwas mit "ein Kunde springt ab" zu tun. Bestenfalls bei Produkten mit horrenden Stückpreisen, von denen man nur alle paar Monate mal eins verkauft (=> "Ausnahmen bestätigen die Regel").

Und noch eins: Stichwort "auslaufendes Produkt". Der Distri wird wohl früher oder später nicht nachliefern können, und ja, es ist unsinnig, dann jeglichen Abverkauf der vorhandenen Restbestände zu verweigern.

Da muss man mit Intelligenz ran, nicht mit einer all-umfassenden "Transaktion" ... und ja, wo immer ich "Transaktion" schrieb, hätte ich wohl besser "atomare Transaktion" schreiben sollen. Ich hatte gehofft, das wäre klar ?-) :(

doch Echt?

zeckensack

2003-12-13, 17:52:37

Original geschrieben von Demirug
Haarmann, wenn ich gewusst hätte das man dich so einfach glücklich machen kann...

Ich fürchte das ich mich äuserst unglücklich ausgedrückt habe so das Zeckensack und du meine Aussage falsch verstanden haben.

Ich habe schlicht und ergreifend den gesamten Prozess der Bestllungsabwicklung mit dem Begriff Transaktion gleichgesetzt. In dem Moment muss mir ein alter Kunde durch den Kopf gegangen sein der diese Angewohnheit hatte den gesamten Vorgang als eine Transaktion zu sehen. Das was du und Zeckensack aber sicherlich mit Transaktion gemeint haben war ein Teilschritt des gesamten Vorgangs. Ich habe das bei diesem Kunden dann immer als Atomare-Transaktion bezeichnet.

In diesem Sinn hat Zeckensack natürlich Recht das ein System das bei einer Atomaren-Transaktion mehr als 2 Datenbanken braucht einen Designfehler hat. 3 Rechner könnten es allerdings denoch sein. 2 davon verwalten jeweils eine der Datenbanken und der 3 wickelt den Teilschritt gerade ab.Puuuh, danke.
*schweissvonderstirnwisch*
:)

grakaman

2003-12-13, 18:39:46

Original geschrieben von Demirug
In diesem Sinn hat Zeckensack natürlich Recht das ein System das bei einer Atomaren-Transaktion mehr als 2 Datenbanken braucht einen Designfehler hat. 3 Rechner könnten es allerdings denoch sein. 2 davon verwalten jeweils eine der Datenbanken und der 3 wickelt den Teilschritt gerade ab.

Warum soll das ein Designfehler sein? Oder redest du hier speziell von der Bestellabwicklung?

MfG

Ganon

2003-12-13, 18:43:00

Original geschrieben von zeckensack
Puuuh, danke.
*scheissvonderstirnwisch*
:)

Du hast dir auf die Stirn geschissen? *gggggggg* :D;)

Haarmann

2003-12-13, 18:44:31

Demirug

Ich hab gerne auch kleine Sachen, die mir Freude bereiten... Dann krieg ichs ab und an auch mal ;).

"Ich fürchte das ich mich äuserst unglücklich ausgedrückt habe so das Zeckensack und du meine Aussage falsch verstanden haben."

Das glaube ich Dir aufs Wort - das ist oft der Fall im Leben.

"In diesem Sinn hat Zeckensack natürlich Recht das ein System das bei einer Atomaren-Transaktion mehr als 2 Datenbanken braucht einen Designfehler hat. 3 Rechner könnten es allerdings denoch sein. 2 davon verwalten jeweils eine der Datenbanken und der 3 wickelt den Teilschritt gerade ab. "

Ich bin mal wieder gemein - es sind auch dann wieder 2 "subatomare" Transaktionen möglich von Abwickler zu je einer DB. Der Abwickler kann das ja unterteilen.

"1. Belastung des Kreditkarten Kontos des Kunden
2. Aktualisieren des Auftragsstatus."

Mein angenommener "Auftragsstatusrechner" hat aber die Kontrolle darüber, denn wenn er wirklich zum genau falschen Zeitpunkt versagt, dann hilft eh nix mehr. Das Gleiche Problem tritt nämlich immer auf, da der "Kreditkartenrechner" immer ausserhalb Deines Einflusses liegen wird. Ich kann also die Buchung dort nicht mehr rückgängig machen - das ist mindestens bei den Bezahlterminals in der Schweiz so - das Terminal kann keine gemachte Buchung mehr stornieren. Da kannste COM+ -en wie de willst.

Für mich ist das Ganze ein klassischer KISS Fall.

StefanV

2003-12-13, 18:51:04

Original geschrieben von zeckensack
Puuuh, danke.
*scheissvonderstirnwisch*
:)

Sorry 4 spam, aber hast du d kein W vergessen, Zecke??

Weil Scheiß-von-stirn-wisch klingt irgendwie nicht gerade 'erfrischend'...

zeckensack

2003-12-13, 19:03:44

Böse Tastatur :|

grakaman

2003-12-13, 19:37:17

Original geschrieben von Haarmann
Mein angenommener "Auftragsstatusrechner" hat aber die Kontrolle darüber, denn wenn er wirklich zum genau falschen Zeitpunkt versagt, dann hilft eh nix mehr. Das Gleiche Problem tritt nämlich immer auf, da der "Kreditkartenrechner" immer ausserhalb Deines Einflusses liegen wird. Ich kann also die Buchung dort nicht mehr rückgängig machen - das ist mindestens bei den Bezahlterminals in der Schweiz so - das Terminal kann keine gemachte Buchung mehr stornieren. Da kannste COM+ -en wie de willst.

Also ich kann mir beim besten Willen nicht vorstellen, dass Kreditkartenabrechnungen nicht Transaktionsgestützt sind. Wo der Server steht und ob du darauf Einfluss hast oder nicht, spielt doch imo keine Rolle.

Haarmann

2003-12-13, 19:52:58

grakaman

Der Fall, dass Dein Koordinationsrechner im falschen Moment wegbricht, den musste auch berücksichtigen. Der Moment, wo Deine Rechner etwas weiss ist ungleich dem, bei dem er das an "harte" Speicher weitergeben kann.

Es hilft Dir in dem Moment auch nichts, wenn Du weisst, das was schief gelaufen ist, denn wenn die Buchung durch ist, ist sie durch. Du wirst VISAs rechner nicht vom Gegenteil überzeugen können...

Xmas

2003-12-13, 20:04:42

Original geschrieben von Haarmann
grakaman

Der Fall, dass Dein Koordinationsrechner im falschen Moment wegbricht, den musste auch berücksichtigen. Der Moment, wo Deine Rechner etwas weiss ist ungleich dem, bei dem er das an "harte" Speicher weitergeben kann.

Es hilft Dir in dem Moment auch nichts, wenn Du weisst, das was schief gelaufen ist, denn wenn die Buchung durch ist, ist sie durch. Du wirst VISAs rechner nicht vom Gegenteil überzeugen können...
Na genau dagegen helfen doch verteilte Transaktionen.

Crushinator

2003-12-13, 20:08:22

Original geschrieben von Demirug
(...) In diesem Sinn hat Zeckensack natürlich Recht das ein System das bei einer Atomaren-Transaktion mehr als 2 Datenbanken braucht einen Designfehler hat. 3 Rechner könnten es allerdings denoch sein. 2 davon verwalten jeweils eine der Datenbanken und der 3 wickelt den Teilschritt gerade ab. (...) ...und Ihr habt beide vergessen, daß es Cluster gibt, bei denen auch eine logische Datenbank physikalisch auf zig Einzelmaschinen verteilt ist. Wo genau dann die atomare Transaktion ausgeführt wird weiß dabei nur der interne TC der verwendeten DB-Engine, zumal die angesprochene Transaktion (im schreibenden Fall) normalerweise ähnlich eines RAID-Systems auf mehreren Mitgliedern ausgeführt wird.

In solchen Fällen macht es übrigens auch mit einer logischen Datenbank Sinn, mehrere (größere) zusammenhängend ausführbare Transaktionen gleichzeitig und am besten je auf einem logischen Applikationsserver zu starten, welche wiederum das DB-Cluster gemeinsam und optimal auslasten würden.
(...) Was der DTC allerdings nicht kann ist für komplette Aufträge einen Rollback durchzuführen. Gerade weil es ja wie Zeckensack schön dargestellt immer wieder Teilaktionen gibt die nicht einfach zurückgenommen werden können. Für solche Fälle muss man dann im Zustandsdiagramm des Abwicklungssystem schon genau festlegen wie sich ein Abbruch zu einem beliebigen Zeitpunkt auswirkt. Genau, welche Transaktion man nun wann und wieso committed bzw. rollbackt hängt stark von der Aufgabe ab. Manche Transaktionen dürfen (zwecks Nachvollziehbarkeit oder Gesetzesanforderung) bzw. können physikalisch (z.B. reine Lese-Aktionen) gar nicht rollbacked werden, was aber die Sache der jeweiligen Middleware ist, sie tut dann bei einem Rollback-Befehl so als hätte sie ihn ausgeführt. Bei fehlgeschlagegenen commits wird außerplanmäßiges rollback angenommen, und bei fehlgeschlagenen rollbacks sollte eigentlich nur enfernbarer temporärer Datenmüll im "Transaktionsprotokll" entstehen und sonst nichts. Man bricht dann den Vorgang einfach ab und gibt die allozierten Objekte umcommitted wieder frei, was schlimmstenfalls nach einer Timeout einem Gesamt-Rollback (soweit wie nur möglich/erlaubt) gleichkommen sollte.

Wie grakaman schon sagte, muß man sich die Sache nur wesentlich größer und die Teilnehmer nicht physikalisch als je eine Maschine vorstellen, damit es ordentlich Sinn ergibt. Bei einer relativ einfachen DB-Anwendung mit einem Server und meinetwegen 20 Clients hat DTS in den meisten Fällen einfach nur akademischen Wert.

zeckensack

2003-12-13, 20:32:36

Original geschrieben von Xmas
Na genau dagegen helfen doch verteilte Transaktionen. Nicht endgültig.
Selbst wenn erstmal alles glatt gelaufen ist, kann's dir immer noch passieren, dass du ein commit veranlassen willst, und dir genau in dem Moment die Netz-Verbindung wegklappt.

Dann hast du auf einem System den commit ausgeführt, und auf dem anderen nicht ... wohl dem, der sich die Ursprungsdaten des Systems vor dem commit gesichert hat, und dieses dann noch zurückrollen kann.

Zugegeben, es ist durch die (verteilte, atomare) Transaktion wesentlich fehlertoleranter als ohne (soll heissen: die statistische Wahrscheinlichkeit für einen "ungünstigen" Ausfall ist geringer).

Dass durch verteilte Transaktionen aber plötzlich alles total sicher ist, ist eine Illusion. Wenn Transaktionen, dann bitte möglichst kleine, die schnell über die Bühne gehen, und nicht auf zwanzig Rechner verteilt, die ich womöglich noch über 200ms+ Pings überhaupt erst erreichen kann.

Haarmann

2003-12-13, 20:40:29

Xmas

Ich rechne immer mit worst worst cases und dann eben isses immer möglich, dass was schief geht (Jaja der Murphy), was man zwar korrigieren kann, aber jegliche Automatik versagen wird. Ich kann z.B. schlicht nicht bei nem Fremdsystem nachfragen, ob es dies oder jenes gemacht hat, denn das wäre fürs andere System zT letal - ebenso wie die ne Rückbuchung.
Sowas kann ich nur bei mir selber verhindern, wenn ich quasi "Vollzugriff" habe. Den habe ich aber schlicht nicht immer. Wo dieser aber fehlt, haperts derbe.

Diese Option ist immer sehr selten, aber möglich. Und wie zeckensack schon sagte, nimmt sowas mit der Latenz einer Operation zu.

Demirug

2003-12-13, 20:43:17

zeckensack, genau für solches Hardwareversagen führen die Transaktionsmanager ja entsprechenden Transaktionslogs. In diesem wird dann vermerkt das der Commit nicht vollständig ausgeführt werden konnte. Die Infos aus dem Log nutz der Manager dann auch um nach der Wiederherstellung der Netzwerkverbindung den Commit doch noch auszuführen.

Desweiteren haben die Transaktionsmanger ja extra Tools mit denen man sich anschauen kann welche Transkationen noch ausstehen und notfalls auch von Hand eingreifen kann. Für irgendwas müssen die Admins ja auch noch bezahlt werden. Einfach Fehler stecken die Systeme aber weg. Kritisch wird es wenn es zu Mehrfachfehler kommt. Je besser der Transaktionsmanager ist desto mehr steckt er aber auch davon weg.

Ein Transaktionsmanger ist nichts anderes als ein Framework der es einem eben ersparen soll das man den ganzen Krempel selbst entwickeln muss. Mit allen Vor und Nachteilen welche die Verwendung von Frameworks eben haben.

Haarmann

2003-12-13, 21:20:12

Demirug

Haarianischer Worst Worst case... beim schreiben des Logs schmiert die Kiste ab... mitten im Sektor ;).

Prost Mahlzeit.

grakaman

2003-12-13, 21:39:46

Original geschrieben von Haarmann
Demirug

Haarianischer Worst Worst case... beim schreiben des Logs schmiert die Kiste ab... mitten im Sektor ;).

Prost Mahlzeit.

Dann macht das Dateisystem einen Roleback und die Transaktion vom DTC ist gescheitert.

Haarmann

2003-12-13, 21:49:40

grakaman

Du warst schneller, denn ich ändern konnte ;).

Es schmiert natürlich dann ab, wenn das Journal da is, aber die Änderung nicht resp umgekehrt, denn eines der 2 muss erst da sein ;).

Nun aber kommt ein System zum Einsatz, dass nicht Dir unterliegt und wo Du nicht nachfragen kannst, obs gemacht wurde oder nicht.

So wollte ichs ausdrücken

grakaman

2003-12-13, 22:00:09

Original geschrieben von Haarmann
grakaman

Du warst schneller, denn ich ändern konnte ;).

Es schmiert natürlich dann ab, wenn das Journal da is, aber die Änderung nicht resp umgekehrt, denn eines der 2 muss erst da sein ;).

Nun aber kommt ein System zum Einsatz, dass nicht Dir unterliegt und wo Du nicht nachfragen kannst, obs gemacht wurde oder nicht.

So wollte ichs ausdrücken

Korrektur: In dem Fall veranlasst ein Timeout des Root Objects den Roleback der anderen Transaktionsteilnehmer.
Da kümmern sich dann die DTC's der einzelnen Transaktionsteilnehmer drum.

Haarmann

2003-12-13, 22:33:53

grakaman

Tja... Du kannst aber den Server von "VISA" nicht zu nem Rollback veranlassen... Der wird das schlicht nicht tun. Er darfs auch nicht tun wegen der Sicherheit. Und genau dann kann Dich Murphy ficken. Ansonstens gibts IMMER nen Weg zurück. Nur den kann ich auch selber finden ;).

Demirug

2003-12-13, 22:50:52

Original geschrieben von Haarmann
grakaman

Tja... Du kannst aber den Server von "VISA" nicht zu nem Rollback veranlassen... Der wird das schlicht nicht tun. Er darfs auch nicht tun wegen der Sicherheit. Und genau dann kann Dich Murphy ficken. Ansonstens gibts IMMER nen Weg zurück. Nur den kann ich auch selber finden ;).

Warum sollte der VISA-Server keinen Rollback erlauben dürfen? Alles was man dafür braucht ist ein Server mit Transationsschnitstelle.

Zumindestens VISA U.S.A hat mit dem DirectExchange System welches mit TUXEDO läuft sowas. TUXEDO hat unter anderem ein XA interfaces welches man mit COM+ ansprechen kann.

Haarmann

2003-12-13, 23:01:15

Demirug

Dann werde ich mal per man in the middle "etwas" abzweigen gehen in den USA ;). Imho is sowas suizid für so ne Firma.

Demirug

2003-12-13, 23:10:09

Original geschrieben von Haarmann
Demirug

Dann werde ich mal per man in the middle "etwas" abzweigen gehen in den USA ;). Imho is sowas suizid für so ne Firma.

Wie willst du da was abzweigen? Das DirectExchange System erlaubt Firmenkunden ihere Forderungen zu übermitteln und dann eben zu comitten oder einen Rollback einzuleiten. Abhänig davon belastet VISA dann das Konto des Karteninhabers und überträgt das Geld auf ein Konto des Firmenkunden oder eben nicht. Für VISA hat das ganze doch 0 Risiko.

Haarmann

2003-12-13, 23:48:59

Demirug

In der Schweiz hat sowas ein sehr grosses Risiko - denn woher weiss Visa, wer hier wer is?

Demirug

2003-12-13, 23:57:24

Original geschrieben von Haarmann
Demirug

In der Schweiz hat sowas ein sehr grosses Risiko - denn woher weiss Visa, wer hier wer is?

Ich verstehe die Frage nicht. Alles was VISA wissen muss ist die Nummer des Kartenkontos das belastet werden soll und die Information welchem Konto das Geld gutgeschrieben wird. Und dann wird entweder gebucht oder eben nicht.

grakaman

2003-12-14, 00:22:27

Original geschrieben von Haarmann
Demirug

In der Schweiz hat sowas ein sehr grosses Risiko - denn woher weiss Visa, wer hier wer is?

Haarmann, jeder Transaktionsteilnehmer "weiss", dass er sich in einer Transaktion befindet. Und eine Transaktion ist "eindeutig".

MfG

Crushinator

2003-12-14, 02:12:10

Original geschrieben von Haarmann
Es schmiert natürlich dann ab, wenn das Journal da is, aber die Änderung nicht resp umgekehrt, denn eines der 2 muss erst da sein ;). Ein seeeeeehr theoretischer Fall, denn es werden zum Committen normalerweise nur ganz wenige Bits im Journal gesetzt und der Datenbestand aus jenem wird wenn überhaupt erst zu einem späteren Zeitpunkt an den "richtigen" Platz gebracht. Ein durchdachtes System weiß dann, daß der richtige Zustand sich aus mehreren Stellen, nämlich ggf. Teilen des Journals und dem eigentlichen Bestand zusammensetzt, und wenn die Comitted Bits im Journal nicht gesetzt sind, ist der alte Zustand noch gültig. :)
Nun aber kommt ein System zum Einsatz, dass nicht Dir unterliegt und wo Du nicht nachfragen kannst, obs gemacht wurde oder nicht. Tjaaaahhh, dafür hat man dann Protokolle in Form von Papierlisten oder ...-Dateien, die von Zeit zu Zeit oder einfach "on Demand" zwischen den Partnern ausgetauscht werden. :D Da aber schon "normale" Systeme inzwischen mehr als 99.9% (http://www.ibm.com/software/success/cssdb.nsf/CS/NAVO-5CTQX4?OpenDocument&Site=default) und die "Besseren" mehr Verfügbarkeit (http://www.uni-koeln.de/rrzk/kompass/95/k9513a.html) bieten, tritt Dein worst case Fall sehr selten und dann auch meist durch "fehlerhafte" Software ein. Außerdem sieht eine vernünftige Interkommunikation vor, daß erst dann "return true;" gemeldet würde, wenn alle dazu notwendigen Transaktionen erfolgreich abgeschlossen seien.

grakaman

2003-12-14, 03:16:38

Original geschrieben von crushinator
Ein seeeeeehr theoretischer Fall, denn es werden zum Committen normalerweise nur ganz wenige Bits im Journal gesetzt und der Datenbestand aus jenem wird wenn überhaupt erst zu einem späteren Zeitpunkt an den "richtigen" Platz gebracht. Ein durchdachtes System weiß dann, daß der richtige Zustand sich aus mehreren Stellen, nämlich ggf. Teilen des Journals und dem eigentlichen Bestand zusammensetzt, und wenn die Comitted Bits im Journal nicht gesetzt sind, ist der alte Zustand noch gültig. :)

Eigentlich werden die Bits im "Context" gesetzt (bei COM+). Objekte mit bestimmten Eigenschaften werden ja in bestimmten Contexten im Prozess gespeichert. Und genau dort setzt man die Bits (done Bit, happy Bit). Bevor eine Transaktion commited wird, untersucht COM+ den Context jedes Transaktionsobjektes, ob das done Bit und das happy Bit der Transaktionsobjekte gesetzt ist (true/false). Das Rootobjekt bekommt das z.B. durch eine Exception heraus. Wenn das Happy Bit von einem Transaktionsobjekt false ist, dann wird das doomed Bit der Transaktion auf true gesetzt und die Transaktion ist gescheitert, wird sofort beendet (mit verlassen der Methode) und ein Roleback erfolgt. Es ist dabei wichtig, dass die Transaktion nur commiten kann, wenn das Rootobjekt erfolgreich (und legal) deaktiviert wurde, also das done Bit auf true gesetzt wurde.
Wenn jetzt nun irgendwie der Server mit dem Rootobjekt weg ist, dann gibt es bei dem DTC auf dem anderen Server einen Timeout und ein Roleback erfolgt. Mit Transaktionsobjekten meine ich hier übrigens normale Objekte im Arbeitsspeicher, die alle auf dem selben Rechner sind. Und jedes hat einen eigenen DTC und kommuniziert z.B. mit einer Datenbank, die auf einem anderen Server sein kann und in der dann natürlich auch ein DTC implementiert ist.

MfG