Sind Pentiums "echte" RISC-Prozessoren [Archiv]

Gast

2007-08-25, 12:57:51

Zum einen bezieht sich die Definition von RISC und CISC auf das Instruktions-Set (ISA), nicht auf die Art und Weise, wie die Daten im Prozessorkern verarbeitet werden. Und zum anderen ist die Definition von RISC keine Quantitative, sondern eine Qualitative.

Intel setzt weder auf RISC, noch emuliert Intel CISC.
Die P6-Abkömmlinge sind wie gehabt CISC, denn die ISA ist x86 und x86 ist CISC, weil es die Eigenschaften von CISC besitzt: Der x86 verwendet unterschiedlich lange Befehle (zwischen 1 und 10 Byte lang), besitzt spezialisierte Register, nur eine geringe Anzahl von universellen Registern und verschiedene Möglichkeiten den Speicher direkt zu manipulieren.
Intel und AMD benutzen beim Abarbeiten eines Teils der Befehle Technologie im Kernel, es ermöglicht, Dinge zu tun, die mit CISC eigentlich nicht möglich sind und die mit RISC eingeführt wurde. Dafür werrden die CISC-Befehle in kleinere Einheiten zerlegt. Das macht den Prozessor aber noch lange nicht RISC-artig, geschweige denn RISC.

Die Zahl der Instruktionen spielt eine untergeordnete Rolle.
Die geringere Zahl an Instruktionen bei RISC ergibt sich höchstens aus den anderen, wichtigeren Eigenschaften von RISC: Die Load-Store-Struktur (d.h. Daten im Speicher können nur mit Load- und Store-Befehlen manipuliert werden), die identische Größe der Befehle (beim PPC immer 32bit, egal, ob im 32- oder im 64-bit-Modus und egal, ob die Integer, die Fließkomma- oder die Vektor-Einheit Altivec benutzt wird) und die große Zahl an universellen Registern (die mit CISC nicht möglich ist. Beim PPC sind es je 32 für die Integer-, Fließkomma- und Vektor-Einheit).

Quelle: Irgendwo in den Kommentaren gefunden.

Gast

2007-08-25, 13:04:18

Schleichwerbung für sandpile ;)

Das gleiche könnte man auch zu den ersten 68k stellen. War es eine 32bit CPU oder war es nicht? Für mich war es. Der Kode war 32bit, nur der Adressraum war noch beschränkt.

Ab P6 rechnen die x86 wie RISC und lassen sich "bedienen" wie CISC. Es kommt wohl drauf an wie man "echt" für sich selbst definiert. Wirklich nachteilig scheint dieser /RISC/CISC-Betrieb beim K8 und C2D nicht zu sein. Kaum ein anderer purer RISC ist pro ALU (wegen Niagara) und Mhz dermassen schnell und begnügt sich mit so wenig Watts.

Blinx123

2007-08-25, 13:05:03

Jup. Die Definition trifft ziemlich auf den Punkt. x86 CPUs sind CISC basiert und verwenden einige Risc Eigenschaften bzw. haben eine vorgeschaltete Risc Einheit sind aber in der Basis eben CISC.

Gast

2007-08-25, 13:07:34

Vorgeschaltete oder nachgeschaltete? ;)

Gast

2007-08-25, 13:07:47

Blinx123

2007-08-25, 13:14:11

Sorry, aber das ist doch Korintenkackerei. Der Befehlssatz mag CISC sein, aber das hat einfach keine Auswirkungen mehr, da die Nachteile von CISC einfach nicht mehr vorhanden sind. Heutige Prozessoren sind besser als jeder reine RISC oder CISC Prozessor, da sie die Vorteile beider Welten miteinander verbinden und die Nachteile minimieren.

Naja,das würde ich nun wieder nicht behaupten. PowerPCs zählt man auch zu den RISC CPUs und der G5 könnte jeden Core2Duo überholen,würde man ihn mit 2,5Ghz Takt und 2Kernen ausliefern.

Korintenkackerei ist das ausserdem sicher nicht. Die Zuweisung gilt auch heute noch wie man sich auch heute noch an die Virtualisationsprotokolle von vor 50 Jahren hält.

Coda

2007-08-25, 13:17:14

und der G5 könnte jeden Core2Duo überholen,würde man ihn mit 2,5Ghz Takt und 2Kernen ausliefern.
Ganz sicher nicht. Die Pro-Takt-Leistung von Core 2 ist besser und die haben schon >3Ghz.

Zudem gab es PowerMacs mit 2,5Ghz DualCore G5 wenn mich nicht alles täuscht.

Das kann man sogar sehr schön belegen:
http://www.spec.org/osg/cpu2000/results/res2007q1/cpu2000-20070215-08561.html
http://www.spec.org/osg/cpu2000/results/res2006q1/cpu2000-20060208-05549.html

Soviel zu "würde alles überholen". Der G5 mit 2,5Ghz und 2 Kernen ist halb so schnell wie ein moderner Xeon mit 3Ghz in CINT2000. Floating-Point ist nicht ganz so schlimm, aber dennoch.

Gast

2007-08-25, 13:31:40

Naja,das würde ich nun wieder nicht behaupten. PowerPCs zählt man auch zu den RISC CPUs und der G5 könnte jeden Core2Duo überholen,würde man ihn mit 2,5Ghz Takt und 2Kernen ausliefern.

Korintenkackerei ist das ausserdem sicher nicht. Die Zuweisung gilt auch heute noch wie man sich auch heute noch an die Virtualisationsprotokolle von vor 50 Jahren hält.
Das ist schlicht Blödsinn. Der PowerPC ist genausowenig eine RISC CPU wie der Core2 eine CISC CPU ist. Die Architektur und Fertigung sind beim Core2 schlicht besser, ebenso vom K8/K10 als die vom PPC, da diese CPUs einfach die effizienteren Prozessoren sind. CISC und RISC spielen da schlicht überhaupt keine Rolle mehr.

Gast

2007-08-25, 13:36:21

AÄpropos schlichter Blödsinn. Was hat RISC/CISC oder die Effizienz mit der Fertigung zu tun?

Gast

2007-08-25, 13:37:27

Heutige CPUs sind RISC CPUs, denen ein recht komplexer CISC Decoder vorgeschaltet ist.

ich denke du weißt was CISC und RISC bedeutet, und wenn du das ganze ausgeschrieben ansiehst hast du auch schon die antwort auf deine frage.
CISC = Complex Instruction Set Computing
RISC = Reduced Instruction Set Computing

die einordnung in CISC und RISC ergibt sich rein aus dem befehlssatz und nicht wie dieser verarbeitet wird und der x86-befehlssatz ist ein typischer CISC-befehlssatz.

SavageX

2007-08-25, 13:52:20

Kommt wie immer drauf an, worauf man abhebt.

Der x86 Befehlssatz ist ziemlich CISC und für einen (Assembler)Programmierer ist das entscheidend.

Wer sich mehr für den Kern interessiert, dem wird eher interessieren, was in Wirklichkeit verarbeitet wird - und das hat inzwischen fast nichts mehr mit dem externen Befehlssatz zu tun. Heutige x86 Kerne verarbeiten "RISC-artige" interne Befehlssätze - wobei ich mit "RISC-artig" einfach Eigenschaften wie fixe Befehlslänge meine, die historisch gesehen üblicherweise typisch RISC waren.

Im Endeffekt sind die Grenzen inzwischen zu verwaschen, um wirklich noch Gültigkeit zu besitzen. Wie will man z.B. den Transmeta Efficeon einordnen? Dessen Hardware hat nichts von x86, verarbeitet aus Programmiersicht aber ganz klaglos x86.

ShadowXX

2007-08-25, 14:10:52

ich denke du weißt was CISC und RISC bedeutet, und wenn du das ganze ausgeschrieben ansiehst hast du auch schon die antwort auf deine frage.
CISC = Complex Instruction Set Computing
RISC = Reduced Instruction Set Computing

die einordnung in CISC und RISC ergibt sich rein aus dem befehlssatz und nicht wie dieser verarbeitet wird und der x86-befehlssatz ist ein typischer CISC-befehlssatz.
Du willst aber doch wohl den Befehlssatz eines G5 nicht als "Reduced" bezeichnen, oder?

Die alten ARM-CPUs (wie die, die im Archimedes verwendet wurden), das waren wirklich noch "echte" RISC-CPUs. Aber sowas wie der G5 ist genauso ein Mischmasch wie die heutigen x86-CPUs. Das einzige ist, dass man durchaus "bemerkt" aus welcher Richtung diese mal kamen.

Davon angesehen, halte ich die Diskussion für leicht überflüssig, den im Endeffekt zählt eben doch nur das was "hinten rauskommt"....

Blinx123

2007-08-25, 18:05:06

Ich glaube einige verstehen den Zusammenhang von RISC auch nicht ganz. Nur weil die RISC Architektur weniger Befehle aufweist,heisst nicht,dass sie schlechter ist oder weniger komplex. Und ich bezeichne die CPUs immer noch als RISC oder CISC,denn dort haben die jeweiligen Prozessoren nunmal ihre Wurzeln. Und das RISC Prozessoren eine höhere Pro-Takt Leistung haben können sieht man auch ganz gut am Dreamcast mit seiner SH-4 CPU,bloss um nochmal ein Beispiel zu geben.

Gast

2007-08-25, 21:30:37

Juerg

2007-08-26, 10:38:34

Die Aussage damals CISC oder RISC hat auch die Zugehörigkeit zu einem Lager bedeutet. Fast eine Lebensphilosphie. Wenn ich vor 15 Jahren jemand gefragt habe ob er eine RISC oder CISC Architektur im Einsatz hätte, dann ist das heute die Frage: x86 oder was anderes?

BlackBirdSR

2007-08-26, 11:23:09

StefanV

2007-08-26, 11:35:22

Können wir uns nicht darauf einigen, dass es keine tradiotionellen RISCs und CISCs mehr im High-End-Markt gibt?

Weder würde ich PowerPC zu echtem RISC einordnen, noch x86 zu echten CISC.

Warum also keine Post-RISC-Ära in der die Vorteile von CISC und RISC verschmelzen? Das würde mehr Sinn geben, ohne sich über alte Definitionen aus Lehrbüchern zu streiten.
Dem kann ich mich nur anschließen!!

Die Definition von RISC und CISC ist einfach viel zu alt, als das man sie heute noch verwenden könnte, heute ist die Regel, das man beides vorfindet, in einer CPU!
Heutzutage kann man beide Begriffe nur noch in die Tonne kloppen und man sollte von beidem in der Vergangenheitsform sprechen, denn geben tuts beides nicht mehr!
Von daher ist der Streit um CISC oder RISC daher seit einigen Jährchen obsolent, da es beides nicht mehr wirklich gibt, in 'reiner Form', in einem Prozessor gibts das aber sehrwohl noch.

Gut, reine Risc Prozessoren mags vielleicht noch in mobiltelefonen und ähnlichem geben, aber sonst?!

ich denke du weißt was CISC und RISC bedeutet, und wenn du das ganze ausgeschrieben ansiehst hast du auch schon die antwort auf deine frage.
CISC = Complex Instruction Set Computing
RISC = Reduced Instruction Set Computing

die einordnung in CISC und RISC ergibt sich rein aus dem befehlssatz und nicht wie dieser verarbeitet wird und der x86-befehlssatz ist ein typischer CISC-befehlssatz.
Sorry, Gast, aber richtig muss es so heißen:

Die Einordnung in CISC und RISC ergab sich rein aus dem Befehlssatz und wie dieser verarbeitet wurde, der x86 Befehlssatz war ein typischer CISC-Befehlssatz.
Heute ist eine Unterscheidung beider Architekturansätze nicht mehr möglich!
Heutige Prozessoren bedienen sich aus beiden Lagern und versuchen die Vorteile beider zu vereinen und die Nachteile damit auszugleichen

So in etwa wäre es richtiger...

Coda

2007-08-26, 12:25:02

Und das RISC Prozessoren eine höhere Pro-Takt Leistung haben können sieht man auch ganz gut am Dreamcast mit seiner SH-4 CPU,bloss um nochmal ein Beispiel zu geben.
Das hat überhaupt nichts mit RISC oder CISC zu tun.

Bokill

2007-08-26, 12:34:52

Eine Frage und viele Antworten.

Vielleicht hilft ja würfeln ?!?

Andererseits würde ich auf die Frage nun auch nicht mehr antworten wollen, nachdem die Exbärden es schon besser als die Lehrbücher wissen. ... Die Frage war einfach zu unspezifisch und vieldeutig.

"Pentium" ohne weitere Angaben ist ein unspezifischer Markenbegriff:
Es umfasst die ersten Pentiums überhaupt, was klasssische CISC-Prozessoren vom Instruktionssatz und Mikroarchitektur waren. Es beinhaltet aber auch die PentiumPro-Linie, wie auch den Pentium4 und auch die Core-Familie, die auch teilweise als "Pentium" verkauft werden.

Die aktuellen Intel- und AMD-x86-Prozessoren sind von der Mikroarchitektur heute RISC. Sie werden intern auf ein einheitliches Befehlformat "heruntergebrochen". In wie fern sie dort auch reine Load & Store RISC-Kerne sind vermag ich nicht zu sagen.
Geschichtlich hat Intel und AMD aber eine Kehrtwende gemacht mit dem PentiumPro und K5/K6.

Der K6 hatte als Stammvater den Nx586 (http://www.orthy.de/index.php?option=com_content&task=view&id=1541&Itemid=85), der im Grundsatz ein RISC war. Die Vorgaben der Nx586-Geschäftsidee lautete dazu, mit einer vorgelagerten Einheit die 386 CISC-Befehle in ein RISC-Format umzucodieren. NexGen nannte damals ihr RISC: "RISC86".

Dabei ist es für mich unerheblich, in wie weit tatsächlich immer die gleiche Befehlslänge vorliegt. Damals hatte man die Erkenntnisse von IBM industrieweit umgesetzt, dass trotz am Ende grösserer Programmdaten, mit RISC-Instruktionssatz diese Instruktionen schneller verarbeitet werden.

Der CISC-Programmcode ist zwar sehr kompakt, aber mitunter brauchen einige komplexe Anweisungen ewig lange. Bezeichnenderweise geben AMD und Intel (Freescale* ... ) immer wieder Hinweise, diese zu lang andauernden Anweisungen möglichst zu vermeiden.

MFG Bobo(2007)

* = Nicht nur AMD und Intel führen noch Prozessoren mit einer CISC ISA, sondern auch Freescale pflegt immer noch die "Cold Fire" Prozessorenlinie mit einer CISC ISA. Freescale führt hier ebenso die Argumente: "Kompakter Programmcode und Kompatibilität" als Vorteile auf.

Coda

2007-08-26, 13:12:12

Dabei ist es für mich unerheblich, in wie weit tatsächlich immer die gleiche Befehlslänge vorliegt. Damals hatte man die Erkenntnisse von IBM industrieweit umgesetzt, dass trotz am Ende grösserer Programmdaten, mit RISC-Instruktionssatz diese Instruktionen schneller verarbeitet werden.
Das ist überholt.

Der CISC-Programmcode ist zwar sehr kompakt, aber mitunter brauchen einige komplexe Anweisungen ewig lange. Bezeichnenderweise geben AMD und Intel (Freescale* ... ) immer wieder Hinweise, diese zu lang andauernden Anweisungen möglichst zu vermeiden.
Und? 99% des Codes kommt heute aus Compilern die das sehr gut wissen. Und die, die noch Assembler schreiben wissen das auch.

Gast

2007-08-26, 13:33:33

Hallo,
ich hab mir gerade etwas die Seite www.sandpile.org angesehen und mir ist dabei aufgefallen dass dort alle Pentiums ab dem P6/PentiumPro als RISC Prozessoren gelistet sind. Jetzt meine Frage: Ich dachte immer ein "echter" RISC Prozessor zeichnet sich durch einen "schlanken" Befehlssatz ohne viel Schnickschnack aus. Dafür haben "echte" RISCs meines Wissens nach viel mehr Register zur Verfügung (z.B: die IPs von ARM oder MIPS) also die normalen x86er.
Wie kommt die Seite dann zu diesem Schluss (wobei man noch dazusagen muss dass es sich bei der oben genannten Seite um eine viel zitierte Seite handelt)

Ich hoff mal ihr versteht wie ich die Frage meine!
THX

Wie Du aufgrund der Reaktionen inzwischen vielleicht festgestellt hast beinhaltet die Antwort auf Fragen dieser Art schon genug "Streitpotential" an sich.

Du hast es aber durch die, sagen wir mal extrem ungeschickte, Zusammensetzung der Frage noch zusätzlich erschwert.

Sind Pentiums "echte" RISC-Prozessoren ?

Nein so wie die Definition bei ihrem enstehen "echt "gemeint war sind sie es sicher nicht.

Die Ersten waren eh echte CISC.

Sollte die Frage von ihrem Sinn her so gemeint gewesen sein:

Haben heutige Pentiums tatsächlich einen echten RISC Rechenkern ?

Dann lautet die Antwort ja.

Sie werden aber nach einem CISC Instruktionssatz programmiert.

DerHeimatlose

Gast

2007-08-27, 00:04:49

Okay sorry,
wie ich sehe war die Frage wohl echt "unpräzise" gestellt. Ich wollt hier nicht so nen Tumult auslösen wie sonst bei den Intel vs AMD Threads.
Also sorry und FRIEDE :-)

Bokill

2007-08-27, 00:09:29

Okay sorry,
wie ich sehe war die Frage wohl echt "unpräzise" gestellt. Ich wollt hier nicht so nen Tumult auslösen wie sonst bei den Intel vs AMD Threads.
Also sorry und FRIEDE :-) Oder du bist ein professioneller Computerbildfuzzi, der mal was lostreten wollte, um mal ein "Forumreport" zu scheiben. ;D

Blinx123

2007-08-27, 11:29:43

Das hat überhaupt nichts mit RISC oder CISC zu tun.

Hab ich auch nicht behauptet,nur stellen einige die RISC Prozessoren ja wie langsame Monster aus der UrZeit da.

Ich sehe darin übrigens überhaupt kein Problem,die CPU weiterhin in CISC und RISC einzuordnen. Auch wenn moderne CPUs inzwischen das Beste aus beiden Technologien vorweisen,so überragt doch immer eine Seite und abgesehen davon waren die Vorfahren ja schliesslich RISC oder CISC CPUs.

Dazu kenne ich einen guten Vergleich zur Verdeutlichung: Ein Junge mit Englischen Vorfahren wird in Deutschland geboren und spricht auch perfekt Deutsch. Deswegen ist er aber trotzdem noch kein Deutscher, sondern bleibt ein Engländer.

HOT

2007-08-27, 11:49:04

Sowohl reine RISC CPUs als auch reine CISC CPUs sind langsame Monster aus der Vergangenheit. Wenn man heute noch was reissen will, benötigt man die Vorteile beider Welten ;). Dieses Rumgehacke auf dem Thema ist echt überflüssig. Es gibt weder CISC noch RISC heutzutage. Und für einen Assemblerprogrammierer bzw. Compilerentwickler ist es sowohl wichtig, dass der Befehlssatz CISC ist, als auch wichtig, dass die Architekur mehr an RISC angelehnt ist, da diese beiden auf die tatsächliche Geschwindigkeit der Befehlsausführung angewiesen sind, und die ist nunmal anders als bei einem reinen CISC Prozessor.
Da die neueren Prozessoren das selbst optimieren beim decodieren gehört das Assemblern auf PC Prozessoren grösstenteils der Vergangenheit an, da es sich einfach nicht mehr lohnt - ein weiterer Vorteil der Fusion aus CISC und RISC.

Blinx123

2007-08-27, 12:23:30

Sowohl reine RISC CPUs als auch reine CISC CPUs sind langsame Monster aus der Vergangenheit.

Für heutige Maßstäbe vielleicht schon,aber zum Erscheinungszeitpunkt der jeweiligen CPU waren sie eben schnell. Und das gilt für RISC und CISC. Der
SH4 hatte jedenfalls seinerzeit eine weitaus höhere ProTaktLeistung als eine vergleichbare reine CISC CPU oder sogar einer damaligen CISC/RISC Mixtur,da entsprachen die 222Mhz etwa einen Pentium3 600Mhz.

Merke: Es kommt nicht alleine auf die Umsetzung an,sondern auch auf die Entwicklung der nötigen Komponenten zur Umsetzung. Würde man eine Möglichkeit finden,wieder reine CISC oder RISC CPUs zu entwickeln, und diese Mixtur aus CISC/RISC fallen lassen,dann wären RISC,CISC CPUs in 20 Jahren sicher auch wieder vergleichsweise schnell,weil die Entwicklung der "Mix Architektur" dann eben zurückgefallen wäre (ich sage nicht,dass das von Vorteil wäre,würde wohl auch viel der Flexibilität heutiger CPUs nehmen)

Ich kann jedenfalls nicht davon ablassen,auch heutige CPUs noch in das RISC oder CISC Segment einzuordnen. Das liegt wohl weniger an der tatsächlich genutzten Architektur,als eher an dem Aufbau der Vorgänger CPUs. x86 CPUs werden für mich immer CISC bleiben,weil dies nunmal in den ersten CPUs dieser Art die vorherrschende Technologie war. Ebenso würden für mich die CPUs der SH Serie immer RISC bleiben,auch wenn man diese nun mit CISC vereinen würde (was aber wohl nie geschehen wird,da SH CPUs eh fast ausschliesslich für mobilere Consumer Geräte genutzt werden und da die RISC Architektur noch vorherrschend ist).

Verschwinden tut ja beides nicht,weder CISC oder RISC. Nur das reine RISC oder CISC verschwindet eben.

Würden heutige Intel und AMD CPUs auf einer völlig anderen Architektur aufsetzen und wären inkompatibel zu früheren CPUs,dann würde ich sie wohl aber auch nichtmehr als CISC bezeichnen,da CISC ja dann garnicht mehr vorhanden wäre.

Gast

2007-08-27, 13:25:20

Coda

2007-08-27, 13:27:55

da entsprachen die 222Mhz etwa einen Pentium3 600Mhz.
Das glaube ich kaum.

Blinx123

2007-08-27, 13:31:35

Das glaube ich kaum.

Ist aber so. Schau dir doch mal die Dreamcast an. Die Spieleleistung war doch auf P3 Niveau (von Synthetischen Benchmarks bin ich noch nicht ausgegangen) was nicht zuletzt an der guten Optimierungsumgebung lag. Ein G4 mit 1Ghz ist übrigens auch schneller als ein Athlon mit 1,5Ghz,dafür habe ich sogar eine kleine Quake3 Benchmark. Muss nur mal suchen,falls du mir auch das nicht glaubst.

Coda

2007-08-27, 13:42:20

Ist aber so.
Sicher nicht. Nicht mit dem Transistorcount zu der Zeit.

Schau dir doch mal die Dreamcast an. Die Spieleleistung war doch auf P3 Niveau
Konsolen kann man generell nicht mit Desktoprechnern vergleichen. Da wird durch die geschlossene Umgebung viel mehr rausgeholt.

Ein G4 mit 1Ghz ist übrigens auch schneller als ein Athlon mit 1,5Ghz
Da hätte ich gerne die genauen Ramenbedingungen gesehen. Beim G4 kann ich das aber noch halbwegs glauben, weil der wirklich eine starke Pro-Mhz-Leistung und ne sehr kurze Pipeline hatte. Nur leider skalierte das Ding auf viel höhere Taktraten dadurch.

Quake 3 ist vor allem ein sehr komischer Benchmark, da war auch der Pentium 4 stark.

HOT

2007-08-27, 14:11:18

Sagt mal, habe ich euch richtig verstanden, dass man auf modernen x86 Prozzies diese vorgeschaltete Decoder-Ebene gar nicht mehr umgehen kann? Was ist denn, wenn man für ein Produkt entwickelt, wo nur ein Modell zum Einsatz kommt? Das ist eine konsolenartige Umgebung und man könnte doch wunderbar optimieren. Schließlich wird das Decodieren auch seine Zeit brauchen und minimiert daher die Leistung.
Kann man eben genau wegen dem Decoder kaum noch. Es ist zwar so, dass die Decoder einer jeweiligen Architektur Stärken und Schwächen haben und sie so noch beeinflussbar sind was die Leistungsfähigkeit angeht, aber was in der CPU vorgeht, da hat man einfach keinen Einfluss mehr drauf. Das ist auch gut so, denn die interne Befehlsstruktur ist genau eben auf die maximale Performance genau eines bestimmten Prozessortyps mit genau einer bestimmten Revision angepasst und optimal. Die jetzigen Decoder sind derart flexibel, dass es sich nurnoch vor Compilerentwickler lohnt, die Stärken und Schwächen zu ergründen und zu umgehen. Zudem kann man noch SIMD einsetzen, was ja der einzige Weg ist, die CPU überhaupt noch über einen eigenen Befehlssatz abseits von x86(-64) zu beeinflussen.

Blinx123

2007-08-27, 14:33:31

@Coda

Ok,war vielleicht ein etwas blöder Vergleich. Aber mir ging es auch eher um die Optimierungsmöglichkeiten und die daraus resultierenden Geschwindigkeitsvorteile. Die SH Risc Serie ist einfach eine CPU Serie,die wirklich sehr gut zu programmieren ist (abgesehen vom SH2 vielleicht,der etwas komplexer war und den niemand richtig ausnutzen konnte:) )
und dadurch erreicht man schon anwendungsspezifisch mit 222Mhz die relative Geschwindigkeit eines P3 600 (einen guten Programmierer vorrausgesetzt).

EDIT: Und hier noch der kleine G4/AthlonXP Benchmark

http://img442.imageshack.us/img442/7456/g4benchmarkkt7.gif

Achja,und ein Benchmark zwischen G3 und C3,wobei das nicht unbedingt eine starke Pro-Takt Leistung des G3 zeigt,sondern eher eine schwache des C3.

http://img295.imageshack.us/img295/5184/g3benchmarklx1.gif

Coda

2007-08-27, 14:36:31

Sagt mal, habe ich euch richtig verstanden, dass man auf modernen x86 Prozzies diese vorgeschaltete Decoder-Ebene gar nicht mehr umgehen kann? Was ist denn, wenn man für ein Produkt entwickelt, wo nur ein Modell zum Einsatz kommt? Das ist eine konsolenartige Umgebung und man könnte doch wunderbar optimieren. Schließlich wird das Decodieren auch seine Zeit brauchen und minimiert daher die Leistung.
Jede moderne CPU hat eine Decoder-Stage. Auch die RISCs. Im internen Format programmiert wäre es um einiges langsamer, weil der Code viel viel größer wäre.

Die SH Risc Serie ist einfach eine CPU Serie,die wirklich sehr gut zu programmieren ist (abgesehen vom SH2 vielleicht,der etwas komplexer war und den niemand richtig ausnutzen konnte:) )
und dadurch erreicht man schon anwendungsspezifisch mit 222Mhz die relative Geschwindigkeit eines P3 600 (einen guten Programmierer vorrausgesetzt).
Immer noch Blödsinn. So eine gute IPC-Rate hat nicht mal ein Core 2 Duo.

Das Ding ist 2-fach-Superskalar, die P6 waren damals schon 3-Fach-Superskalar mit getrennter FPU.

EDIT: Und hier noch der kleine G4/AthlonXP Benchmark
Gibt's da auch die Testbedingungen irgendwo dazu? Compiler? Betriebssystem? Treiber?

Sieht sehr nach Apple-Propaganda aus.

Blinx123

2007-08-27, 14:51:59

Dann erklär mir bitte mal,warum es auf einen P3 600Mhz noch niemand fertig gebracht hat,auch nur annähernd so gut aussehende Games wie auf dem Dreamcast zu programmieren? Das hat nichtsmehr mit "anderer Plattform" zu tun, sondern liegt an der guten Programmierbarkeit,oder wie ist es anders zu erklären,dass es soviele Homebrew Dreamcast Games gibt,während alle anderen Systeme (einschliesslich PC) da ordentlich hinterherdümpeln? Das liegt ja wohl eindeutig an der leichteren Programmierbarkeit,die wiederrum zu besseren Speedgains in einer dafür programmierten oder optimierten Anwendung führt.

Was die Benchmark angeht: Ne,wenn dann ist es keine Apple Propaganda,sondern Genesi Propaganda:)

Die Config habe ich nichtmehr gefunden,aber ein paar Dinge habe ich noch im Kopf. P3 Mainboard war eins mit SIS Chipset, G4 war auf dem Pegasos2. Beide wurden mit 128MB SD-Ram angetrieben. G4 OS: MorphOS 1.4.

P3 OS: Win98 SE.

Was du mit einen Compiler willst,ist mir aber gerade unklar. Quake3 läuft auf beiden OS' nativ.

HOT

2007-08-27, 16:54:57

Gut aussehen hat nicht unbedingt was mit der CPU zu tun. Da ist es ausreichend, dass sie schnell genug ist und das wird sie für die DC gewesen sein. Die CPUs von GC und WII sind auch keine solchen Leuchten, sind aber optimal für ihren Zweck und genau das ist der springende Punkt. Die Games, die auf Konsolen laufen, sind weniger durch ihre CPU Leistung limitiert, als vielmehr durch den begrenzten Speicherausbau der Konsole. Die DC war von der Grafik her nur deshalb so wuchtig, weil da drin eine PowerVR Serie2 gearbeitet hat, auf die man stark optimieren konnte. Dagegen konnte sogar die PS2 nichts ausrichten. Auch damalige PC Chips waren noch lange nicht auf dem Niveau. Das Teil ist ein echte deferred Renderer mit einer Menge Bums für die damalige Zeit dahinter, wenn man dafür optimiert. Heute hat sich das Bild gewandelt, heute gibt es kaum noch Hersteller für Grafikchips. Die beiden die es noch gibt probieren ihre Technik sowieso erstmal auf dem PC, bevor das in der Konsole landet, das schließt heutzutage bessere Konsolengrafik aus, anders als es damals noch war, als Vielfalt auf dem Markt herrschte.

Zum Q3 Bench: Sieht nach Altivec aus. Da war der G4 extrem stark.

Aquaschaf

2007-08-27, 17:06:25

Dann erklär mir bitte mal,warum es auf einen P3 600Mhz noch niemand fertig gebracht hat,auch nur annähernd so gut aussehende Games wie auf dem Dreamcast zu programmieren?

Auf einem P3 600MHZ kann man z.B. schon Max Payne spielen. Und gutes Aussehen kommt von gutem Content, das steht nur sehr indirekt in Verbindung mit Rechenleistung.

Coda

2007-08-27, 19:27:52

Dann erklär mir bitte mal,warum es auf einen P3 600Mhz noch niemand fertig gebracht hat,auch nur annähernd so gut aussehende Games wie auf dem Dreamcast zu programmieren?
Ich hab dir schonmal gesagt, dass man Konsolen nicht mit Desktopsystemen vergleichen kann. Aus der Playstation 2 wurden auch unglaubliche Dinge rausgeholt obwohl das Ding nicht gerade tolle Hardware hat. Optik hat auch mindestens 50% mit dem Artwork zu tun.

Zudem hat der Dreamcast-SH4 auch Instructions für Matrix-Vektor- und Matrix-Matrix-Multiplikation (RISC :rolleyes:) was natürlich gerade in Spielen schon einiges bringt.

StefanV

2007-08-27, 20:10:02

Ein G4 mit 1Ghz ist übrigens auch schneller als ein Athlon mit 1,5Ghz,dafür habe ich sogar eine kleine Quake3 Benchmark.
Willst mich veräppeln?!

Ein G4 mit ~1Ghz ist ganz sicher NICHT schneller als ein K7 mit 1,5 GHz, nicht bei 'normalen' Integerwerten, da suckt der G4/933 trotz der 2MiB L3 Cache ganz schön, selbst ein 2,533 GHz Sellerie ist da um Welten angenehmer (und wir wissen, wie lahm ein Sellerie ist)....

Und nein, mehr RAM hat der Sellerie auch nicht, ganz im Gegenteil!

€dit:
Der einzige Punkt, wo der G4 besser sein wird, ist, wenn man Altivec nutzen kann, das kann man aber z.B. nicht in 'nem Browser mit Flash, da ist ein G4 schnarchlahm...

Gast

2007-08-27, 20:31:27

Allen Unkenrufen zum trotz sind die Leute mit ihren g4 Powerbooks ziemlich zufrieden und empfinden diese nicht als langsamer als Pentium-M Laptops (teilweise eher als schneller).

Ganon

2007-08-27, 20:35:53

Ein G4 mit 1Ghz ist übrigens auch schneller als ein Athlon mit 1,5Ghz,dafür habe ich sogar eine kleine Quake3 Benchmark. Muss nur mal suchen,falls du mir auch das nicht glaubst.

Ich habe 2 G4s mit jeweils 1,25 Ghz... ich glaube dir nicht ;)

@Gast über mir

LOL. Welche Leute sollen das sein? PPCNUX-Besucher? :D

Ich kann auf meinem nicht mal 720p H.264 Videos ruckelfrei angucken, während auf dem PM Notebook von meinem Vater diese flüssig laufen... und das ist nur eine von vielen Anwendungen. Und in Notebooks haben die letzten G4s zwar höheren Takt aber z.B. kein L3-Cache und nur eine CPU.

Blinx123

2007-08-27, 21:52:17

Mensch Coda,programmiere einfach mal etwas auf einer SH4 Platform,dann verstehst du was ich meine. Es geht mir rein um die Programmierpower,damit kann man nunmal in den meisten Fällen mehr aus einer schwachen Hardware rauskitzeln als aus einer starken. Und zum Thema PowerVR2,damals gab es schon Vergleichbares bzw. sogar einen Desktopabkömmling. Geholfen hats trotzdem nichts,die x86 Architektur ist einfach komplexer zu programmieren als ein SH4.

@StefanV

Das Benchmark Ergebniss zeigt auch keine InternetApplication. Abgesehen davon sollte man vielleicht sagen,dass der G4 im Moment noch die schnellste Platform für MorphOS ist,was eben auch zum SpeedGain beim Quake3 Benchmark beiträgt.

Die x86 Hardware Architektur selbst hält natürlich einen G4 stand (wenn auch gerade so),aber die Software reisst es eben für den G4 raus. MorphOS benötigt nahezu null Ressourcen, Windows schon und deswegen ist das BenchmarkErgebniss eben kein Apple Fake.

@Ganon

So,so. Du betreibst also deine 2 G4s mit genau der selben Software unter genau dem selben OS wie deine x86 CPUs ? Das musst du mir aber zeigen,wie man das ohne VMWare schafft,solange du kein MacOSX auf die x86 Hardware aufsetzt.

Coda

2007-08-28, 00:10:28

Mensch Coda,programmiere einfach mal etwas auf einer SH4 Platform,dann verstehst du was ich meine.
Meinst du jetzt Assembler oder was? Das fasst doch eh keine Sau an.
Und wenn ich wie jeder normale Mensch nen Compiler benützt dann hab ich mit der Architektur gar nix zu tun.

Es geht mir rein um die Programmierpower,damit kann man nunmal in den meisten Fällen mehr aus einer schwachen Hardware rauskitzeln als aus einer starken.
Aber nicht das Dreifache aus einer 2-way Superskalaren CPU mit dem Transistorcount. Nicht über meine Leiche.
Ich gehe jede Wette ein dass die IPC-Rate ungefähr gleich oder womöglich etwas über der eines P6 war.

Und zum Thema PowerVR2,damals gab es schon Vergleichbares bzw. sogar einen Desktopabkömmling. Geholfen hats trotzdem nichts,die x86 Architektur ist einfach komplexer zu programmieren als ein SH4.
Das ist doch Blödsinn. Spiele waren auch damals schon 99% C/C++. Und x86 ist nicht komplex zu programmieren, wenn man die FPU mal außen vor lässt.

Gast

2007-08-28, 00:36:17

Und wenn ich wie jeder normale Mensch nen Compiler benützt dann hab ich mit der Architektur gar nix zu tunTheoretisch oder auch praktisch? Ich frag mich gerade so als Laie... Ist das wirklich nie der Fall, daß man mal ein Algo in C (ab jetzt nur ein Besipeil) für die gleiche Performance vielleicht eben in C leicht umbauen muß (oder könnte), damit irgendein C-Kompiler unter Win und x86 es genauso schnell gebacken bekommt wie irgendein C-Kompiler für PowerPC? Oder für Alpha unter Linux oder eben umgekehrt usw.

Ich weiß nur daß Pavlov an seinem 7-zip vor einer schon längeren Zeit mind zweimal kleine Änderungen vorgenommen hat, weil die Linuxer seinen VB6-Kode mit dem gcc nur ganz dürftig übersetzt bekamen. Jetzt ist das kein Problem. 7-zip nutzt imho die FPU nicht.

Ok. Ich weiß nicht, ob das nicht doch am Thema vorbei ist :frown: aber hat man auch über einen Kompiler nicht doch gelegentlich etwas mit der jeweiligen Architektur zu tun?
Wenn ich Programmierer wäre, würde ich als Architektur außer der CPU schon noch den dazugehörenden Kompiler mitzählen. Und die unterscheiden sich trotz der Standards schon kelinwenig voneinander. Vor allem selbst auch auf der gleichen Platform im Ergebnis.

Coda

2007-08-28, 00:58:36

Theoretisch oder auch praktisch?
Auch praktisch. Außer an manchen Stellen ob die Architektur Big- oder Little-Endian ist.

Was das angeht was du ansprichst kommt es eher auf den Compiler an, nicht auf die Architektur.

Gast

2007-08-28, 01:11:43

Was das angeht was du ansprichst kommt es eher auf den Compiler an, nicht auf die Architektur.Kann man das praktisch wirklich so trennen?

Coda

2007-08-28, 01:15:21

Ich weiß nicht auf was du jetzt hinaus willst. Es ging um SH4 vs. Pentium 3 und die x86-Compiler waren auch damals schon die besten, weil einfach die Architektur am verbreitetsten ist.

Ganon

2007-08-28, 08:13:32

So,so. Du betreibst also deine 2 G4s mit genau der selben Software unter genau dem selben OS wie deine x86 CPUs?

Sicher nicht das selbe Betriebssystem, aber beides QuickTime. Und QuickTime ist unter Windows nicht mal sonderlich schnell, da gibt's besseres. Unter OS X ist QuickTime aber das Optimum. MPlayer und VLC brechen bei einem 720p Video direkt weg, während QuickTime wenigstens noch auf rund 12fps kommt.

Aber hey, dein Quake3-Benchmark zeigt auch nicht mehr als 2 Balken. Und wenn ich ein OS nehme, welche die eine CPU ausbremst und die andere CPU "beschleunigt", dann ist der Vergleich auch hinfällig.

Ich sag ja auch nicht ein Trabbi ist schneller als ein Porsche, wenn am Porsche ein LKW hinten dran gebunden ist...

Blinx123

2007-08-28, 12:03:10

Also ums nochmal deutlich zu erwähnen: Ich spreche nicht von der Rohleistung einer CPU sondern von der tatsächlichen Leistung einer Architektur. Dazu gehört neben einer guten Programmierbarkeit der Hardware auch die Software. Ein AthlonXP mit 1,5Ghz ist langsamer als ein G4 mit 1Ghz,eben weil ersteres unter einer WindowsPlattform werkelt,letzteres aber auf einen typischen RISC OS aufbaut (eben deswegen kann man auch die PPCs noch zu den RISCs zählen). Im Fall der Benchmark wäre das RISC OS dann also MorphOS. Für einen Vergleich der Rohleistung taugt sowas natürlich nichts. Aber man muss es auch so sehen: Sicher Rohleistung ist schön und gut,nützt aber rein garnichts,wenn die Rohleistung nicht ausgeschöpft werden kann,eben weil im Hintergrund vielerlei ressourcenverschwendende Tasks laufen.

@Coda

Auch auf einen PC ist es schön,direkten, interrupt freien Hardware Zugriff zu haben und auf einer Konsole war und ist es meist sogar noch unerlässlich (ok,MS beugt den ganzen mit ihren SDK ja vor,aber die PS3 benötigt wohl noch einige Hardwarezugriffe zur Optimierungsarbeit,da sie ähnlich komplex aufgebaut ist,wie die SH2 Architektur im Saturn,aus dem man auch schon nicht das Maximum rausholen konnte,eben durch die komplexe Programmierbarkeit).

Und ausserhalb von Assembler hat man immer noch SDKs und die sind nunmal auch nicht alle gleich. Das hat ebenso etwas mit der Programmierbarkeit einer HardwareBasis zu tun. Das SDK des SH4 ist wirklich spielend leicht zu beherrschen im Vergleich zu manch anderen Software Development Kits.

Ganon

2007-08-28, 12:25:32

Ein AthlonXP mit 1,5Ghz ist langsamer als ein G4 mit 1Ghz,eben weil ersteres unter einer WindowsPlattform werkelt

Und unter einem minimal Linux? ;)

Wie willst du die "Roh"leistung vergleichen und meinst die Rohleistung des G4 sei höher als die des AthlonXP, aber hast zum Vergleich nur eine Performance unter Windows? Das ist das was ich oben sagte -> es ist Käse.

MorphOS mag ressourcenschonend sein, aber das es bis vor kurzem (oder immer noch?) nicht mal einen TCP/IP Stack hatte, ist es ziemlich nutzlos.

Blinx123

2007-08-28, 12:32:39

Ich sag doch,dass ich eben nicht die Rohleistung vergleiche,sondern die tatsächliche Leistung. Die ist auch abhängig von den restlichen Ressourcen.

Und wozu brauchst du einen TCP/IP Stack unter MorphOS? Da gibt es genug Alternativen.

Gast

2007-08-28, 12:43:15

Welche Alternativen gibt es zu einem tcp/ip-stack?? :D

Blinx123

2007-08-28, 12:46:02

Müsste ich jetzt mal nachschauen,hab mich lange nichtmehr mit den eigenarten eines Amiga Betriebssystems beschäftigt. Ich weiss nur,dass es ziemlich brauchbare Alternativen geben muss,sonst hätte ich damals wohl kaum so über die Netzwerkfähigkeiten und die Geschwindigkeit gestaunt.

EDIT: Wollte Ganon mich jetzt testen? Wenn ja,dann hat er mich eiskalt erwischt:) MorphOS hat schon seit der ersten Version einen TCP/IP Stack,gerade nachgesehen. Heisst MosNET und basiert auf PPC Code.

Speicherschutz fehlt bei MorphOS aber. Was aber ziemlich unwichtig ist. Ich sag mal siehe: Windows:)
Was nützt MemoryProtection,wenn es nichts nützt? Oder anders,warum gibt es trotz MemoryProtection BlueScreens?

Gast

2007-08-28, 12:55:53

Blinx123

2007-08-28, 12:59:00

Sicherer? Sicher nicht.

Alternativ Systeme sind alle besser abgesichert und mal ernsthaft: Wer schickt Viren auf einen Amiga?:)

Die Microsoft Systeme sind immer hauptziel von Hackerangriffen,kaum jemand beschäftigt sich mit Sicherheitslücken bei Systemen wie Linux,MorphOS,AmigaOS usw.

Und naja. BlueScreens gibt es inzwischen tatsächlich weniger. Aber trotzdem seltsam,dass Microsoft soviele Jahre gebraucht hat,um die MemoryProtection ordentlich umzusetzen,denn ordentlich funktionieren tut sie erst seit XP SP2.

del_4901

2007-08-28, 13:03:51

Sagtmal geht das nur mir so, oder grenzt Blinx123 Inkompetenz doch stark an codinguser?

Ganon

2007-08-28, 13:09:40

Speicherschutz fehlt bei MorphOS aber. Was aber ziemlich unwichtig ist.

Ahja, gut das du das sagst. Damit braucht man auch mit dir nicht weiterdiskutieren...

Du scheinst ja noch nicht mal zu wissen was Speicherschutz überhaupt ist...

@AlphaTier

Scheint so. :D codinguser : The Return :D

Gast

2007-08-28, 13:14:04

Alternativ Systeme sind alle besser abgesichert und mal ernsthaft: Wer schickt Viren auf einen Amiga?:)
Ach und deswegen ist MorphOS sicherer?
Super!!! Werfen wir doch alle Windows in die Tonne und wechseln auf MorphOS, denn da ist man viel sicherer, weil einem niemand Viren schickt...
Idiot...

Blinx123

2007-08-28, 16:13:36

Selber Idiot:(

Ich versuche eine ordentliche Diskussion zu führen und bekomme dann solche Antworten.

Und nein,ich bin nicht CodingUser,weiss aber auf was oder wem ihr hinaus wollt.

Und ja,ich weiss was MemoryProtection bedeutet. Vielleicht sollten einige mal wieder WinME auspacken und dann mal staunen wie schlecht die MemoryProtection damit erscheint.

Kurze Erklärung über die MemoryProtection: In erster Linie soll die MemoryProtection Datenverlusten vorbeugen und das System trotz Abstürze einzellner Tasks stabil halten. Ersteres funktioniert auch schon immer ganz gut,nur mit letzteren hat es bis WinXP SP2 eben ordentlich gehappert. Der BlueScreen,der bis einschliesslich ME eigentlich bei jedem kleinen RessourcenEnde auftaucht ist schon ein Anzeichen dafür,dass die Memory Protection eben nicht alles erfüllt was sie verspricht. Unter XP tauchen inzwischen keine oder nur selten Blue-Screens auf,stattdessen wird ein abgestürztes Programm beendet (ohne Blue-Screen). Das sehe ich zum Beispiel öfters bei Herr Der Ringe Online,da die Engine etwas verbuggt ist und öfters einen Ressourcenüberlauf provoziert. WinXP zeigt mir daraufhin dann einfach eine kleine Fehlermeldung an und weiter gehts,kein Problem also (höchstens ab und an muss ich neustarten,weil die Ressourcenzuweisung nicht stimmt.)

Und zum Thema Sicherheit: Warum haben LinuxUser und MacUser wohl seltener Probleme mit Trojanern oder Viren? Eben weil die Sicherheit bei diesen OS' vorgeht und sich die Entwickler auch ordentlich darum kümmern sämtliche Sicherheitslücken zu schliessen.

Und beim Amiga ist es nunmal so: Der einzige Grund,warum jemand der gänzlich auf eine Firewall verzichtet keine Virenprobleme hat ist,dass es niemanden gibt,der sich die Mühe macht Viren für einen 20 jahre alten Homecomputer zu programmieren. Und wenn ich vom Amiga rede,dann meine ich eigentlich die Rote Seite. Also AmigaOS und das ist um einiges älter als MorphOS.

Achja

@Gast

Wer nichtmal fähig ist,sich anzumelden sollte lieber still sein. Vielleicht bist du ja auch CodingUser der sich gerade aufregt,weil jemand anderes deinen miesen Ruf versaut

del_4901

2007-08-28, 16:19:54

Da steht soviel Schwachsinn drin, das kann ich nichtmal als Halbwissen bezeichnen. Ich sage mal soviel dazu, wenn der BS kommt, dann hat die MemoryProtection hervorragend funktioniert, und somit verhindert das der Kernel korumpierten Code ausführt. Wie das nun genau funktioniert, und welche Arten des Schutzes es gibt, lohnt sich bei sowenig Grundwissen nicht zu erklärn. (dauert zu lange)

Blinx123

2007-08-28, 16:25:44

Ich sag doch auch,dass der erste Teil der Memory Protection funktioniert (bitte nicht den Mittelteil überfliegen,da stehts nämlich drin). Nur eben die 2te Aufgabe nicht,die für mich zu einer guten MemoryProtection dazu gehört. Nämlich die,dass die MemoryProtection für ein stabiles Weiterarbeiten sorgt,was sie seit WinXP ja auch tut.

del_4901

2007-08-28, 16:28:33

Blinx123

2007-08-28, 16:33:24

Warum gehts dann aber unter WinXP? Ich meine,ich hämmere täglich meine ganzen Ressourcen in Grund und Boden (durch einen Engine Fehler in Herr Der Ringe Online),verstelle damit die ganze Ressourcenzuteilung und trotzdem bekomme ich zumindest noch die Möglichkeit im Internet zu surfen. Achja,ich kann sogar einige System-Tasks schliessen,die ich unter früheren Win Versionen nie angefasst habe,weil ich dann 5Sek. später einen Blue-Screen hatte.

del_4901

2007-08-28, 16:37:03

Blinx123

2007-08-28, 16:44:18

Weil du heute weniger Viren auf dem Rechner hast, als damals.

Ehrlich gesagt habe ich eher mehr:D
Früher musste ich jedesmal Windows neu installieren,nachdem ich einen Virus hatte (blöder Bootvirus:) )

Hab früher mehr Wert auf einen sauberen PC gelegt. ZoneAlarm ist im Moment leider zu ressourcenverschwendend ( hab die komplette InternetSuite auf dem PC meines Vaters installiert,daher weiss ich wovon ich rede).

Übrigens hab ich gerade einen Bericht über Memory Protection in früheren Windows Versionen gelesen. Ein User bestätigt da sogar meine These,dass die MemoryProtection zwar schon in früheren WindowsVersionen physisch vorhanden war,aber technisch eben nicht richtig haftete. Erst mit dem
Windows2000er Kernel kam eine wirkliche MemoryProtection.

Coda

2007-08-28, 16:48:18

Ich spreche nicht von der Rohleistung einer CPU
Das hörte sich aber noch ganz anders an früher im Thread. Da war noch keinerlei Rede von irgendwelchen Konsolen oder Betriebssystemen blabla, du hast einfach gesagt:
SH4 hatte jedenfalls seinerzeit eine weitaus höhere ProTaktLeistung als eine vergleichbare reine CISC CPU oder sogar einer damaligen CISC/RISC Mixtur,da entsprachen die 222Mhz etwa einen Pentium3 600Mhz.
Das ist nachweislich immer noch völliger Bullshit. Sind wir jetzt schon am rausreden oder was?

Zudem geht's hier wenn dann um CISC vs. RISC und nicht um Konsolen- vs. Desktop-Systeme. Der x86 in der Xbox wird auch besser ausgenützt als im PC.

del_4901

2007-08-28, 16:48:40

Ehrlich gesagt habe ich eher mehr:D
Früher musste ich jedesmal Windows neu installieren,nachdem ich einen Virus hatte (blöder Bootvirus:) )

Hab früher mehr Wert auf einen sauberen PC gelegt. ZoneAlarm ist im Moment leider zu ressourcenverschwendend ( hab die komplette InternetSuite auf dem PC meines Vaters installiert,daher weiss ich wovon ich rede).
Die Viren sind auch besser geworden, die fallen nichtmehr so schnell auf.
Norton ist eh ein einziegr Virus, ich hab nur den AVK und Vista64 mit Automatischen Updates und der Firewall. (die übrigens auch mit XPSp2 kahm)

Jetzt solltest du dir mal Gedanken machen... Also ich für meien Teil schmeiß lieber MS das Geld in den Hals, als das ich meinen Rechner für die "Szene" arbeiten lasse.

del_4901

2007-08-28, 16:50:58

Das hörte sich aber noch ganz anders an früher im Thread. Sind wir jetzt schon am rausreden oder was?
Du hast gut von mir gelernt, junger Padawan. :love3:

StefanV

2007-08-28, 16:51:48

Also ums nochmal deutlich zu erwähnen: Ich spreche nicht von der Rohleistung einer CPU sondern von der tatsächlichen Leistung einer Architektur.
Falsch ist falsch und bleibt falsch, da ist egal, wovon du sprichst, ein G4 ist NICHT schneller, nur ev. mit Altivec PUNKT.

Dazu gehört neben einer guten Programmierbarkeit der Hardware auch die Software.

Ja, nee, is klar...
Und warum heißt CPU jetzt CPU, auch General Purpose Prozessor?! :uponder:
Ein AthlonXP mit 1,5Ghz ist langsamer als ein G4 mit 1Ghz,eben weil ersteres unter einer WindowsPlattform werkelt,letzteres aber auf einen typischen RISC OS aufbaut (eben deswegen kann man auch die PPCs noch zu den RISCs zählen).
ahja, was ist jetzt ein typisches 'RISC OS'??
Etwa etwas, bei dem alles entsorgt wurde, was man nicht braucht?!
Oder etwas, das einfach nur ein OS ist nach dem Thema 'nix dran aber geht' a la Windows 3?!
Im Fall der Benchmark wäre das RISC OS dann also MorphOS. Für einen Vergleich der Rohleistung taugt sowas natürlich nichts. Aber man muss es auch so sehen: Sicher Rohleistung ist schön und gut,nützt aber rein garnichts,wenn die Rohleistung nicht ausgeschöpft werden kann,eben weil im Hintergrund vielerlei ressourcenverschwendende Tasks laufen.
Ja, neee, is klar.
Schonmal dran gedacht, das die Tasks schlafen gelegt werden können?!

@Coda

Auch auf einen PC ist es schön,direkten, interrupt freien Hardware Zugriff zu haben und auf einer Konsole war und ist es meist sogar noch unerlässlich
Das ist falsch, beides!

Direkten Hardwarezugriff zu haben ist einfach scheiße -> hölle für den Programmierer, unendlich viele Fehlerquellen und so weiter.
Siehe z.B. Soundkarten unter DOS, DAS war ein Krampf!

Treiber gabs zwar auch (sog. TSR), nur haben die nix getrieben sondern einfach nur die Hardware konfiguriert, mangels einer einheitlichen Treiberschnittstelle war das auch nicht möglich (Ok, emulationen gabs trotzdem, funzten auch mehr oder minder gut)

Dazu kann man viel Scheiße bauen, mit direktem Hardwarezugriff, BIOS löschen und so weiter, sorry, aber du hast wirklich keine Ahnung, wenn du schon sowas behauptest...

PS: auch bei Konsolen ist der direkte Hardwarezugriff nicht unbedingt möglich, siehe PS3, da gibts auch 'nur' Treiberschnittstellen wie D3D (XBox) und OpenGL!!

(ok,MS beugt den ganzen mit ihren SDK ja vor,aber die PS3 benötigt wohl noch einige Hardwarezugriffe zur Optimierungsarbeit,da sie ähnlich komplex aufgebaut ist,wie die SH2 Architektur im Saturn,aus dem man auch schon nicht das Maximum rausholen konnte,eben durch die komplexe Programmierbarkeit).

Nur doof, das man auf die Hardware der PS3 GARNICHT zugreifen kann, aber hey, Hardwarezugriff roxx0rt, weil is ja direkt und nix dazwischen :ugly:

Merke: früher <-> heute

Und ausserhalb von Assembler hat man immer noch SDKs und die sind nunmal auch nicht alle gleich. Das hat ebenso etwas mit der Programmierbarkeit einer HardwareBasis zu tun. Das SDK des SH4 ist wirklich spielend leicht zu beherrschen im Vergleich zu manch anderen Software Development Kits.
1. wozu sollte man Assembler nutzen (wollen)?? Viel zu viel Sackstand, viel zu kompliziert, viel zu aufwendig, viel zu teuer!
2. Ist man solangsam weg vom 'direct Access', weils eben mehr Probleme bringt als das es nutzt!

Blinx123

2007-08-28, 16:53:28

Ich nutze doch auch Windows:)

So,hier noch ein etwas technischerer Bericht. Da stehts Schwarz auf Weiß inklusive Nachweismöglichkeit, Win 9x hatte keine richtige MemoryProtection.

http://everything2.com/index.pl?node_id=668981

@Coda

Die Architektur hat ja auch eine höhere Pro-Takt Leistung. Also für mich gehört zur RISC Architektur nicht nur die Hardware,sondern auch ein typisches RISC OS,daher der Speedgain.

@StefanV

Neidisch,dass manche Leute noch Assembler programmieren können? Klingt bald so.

Das PS3 SDK hat ausserdem einen Inline Assembler,insofern hat man direkten Zugriff und für die volle Ausnutzung einer komplexen ProzessorArchitektur mit mehreren Kernen wie der Cell Architektur kann sowas schon von Vorteil sein.

Coda

2007-08-28, 17:40:08

Die Architektur hat ja auch eine höhere Pro-Takt Leistung. Also für mich gehört zur RISC Architektur nicht nur die Hardware,sondern auch ein typisches RISC OS,daher der Speedgain.
Durch das andere OS ist das Ding auch nicht auf einmal 3x so schnell. Deine Argumente werden langsam wirklich blödsinnig. EOD.

Und hey, ich kann auch noch Assembler programmieren und bilde mir aber wenigstens nix drauf ein.

Gast

2007-08-28, 17:45:23

Übrigens hab ich gerade einen Bericht über Memory Protection in früheren Windows Versionen gelesen. Ein User bestätigt da sogar meine These,dass die MemoryProtection zwar schon in früheren WindowsVersionen physisch vorhanden war,aber technisch eben nicht richtig haftete. Erst mit dem
Windows2000er Kernel kam eine wirkliche MemoryProtection.
Und mit Windows 2000 hat sich die Stabilität von Windows STARK verbessert. Also kann deine Ursprüngliche Behauptung MemoryProtection wäre nutzlos ja nur falsch sein.

Und das Win9x keine MemProtection hatte, hatte übrigens verschiedene andere Gründe, nicht weil es generell zu schwer ist MemProtection anständig zu implementieren.

StefanV

2007-08-28, 17:53:47

Ja, wegen der Kompatiblität zum Win3 Kern und weil es noch stark auf dem Win3 Kern aufbaut :ugly:

Blinx123

2007-08-28, 18:24:56

Durch das andere OS ist das Ding auch nicht auf einmal 3x so schnell. Deine Argumente werden langsam wirklich blödsinnig. EOD.

Und hey, ich kann auch noch Assembler programmieren und bilde mir aber wenigstens nix drauf ein.

Ich bilde mir auch nichts aufs Assembler programmieren ein,nur regt es mich auf,wenn Leute meinen sie wären die Größten,nur weil sie die Grundzüge von C beherrschen.

Und 3mal so schnell sicherlich nicht,siehs eher anders. Die eine Architektur nimmt dank dem leichteren OS ordentlich an Speed zu,während die andere dank einen ressourcenlastigen OS nicht die volle Leistung erbringen kann (was eine leichtes OS auch nicht verhindern kann,aber zumindest sorgt es dafür,dass nicht zufällig Leistung verschwendet wird).

Und was MemoryProtection angeht: Unter Windows ist es vielleicht auch nicht nutzlos (ausser bei Win9x,von dem ihr ja alle behauptet habt,es hätte eine sauber implementierte MemoryProtection,was sich aber mit wenigen Zeilen leicht widerlegen lässt). Aber andere OS' laufen eben auch ohne MemoryProtection stabil. Nicht jeder Kernel ist gleich aufgebaut wie Windows und ein gutes Beispiel für ein stabil laufendes OS ohne MemoryProtection ist wohl AROS. Man könnte jetzt natürlich auch sagen,es würde mit MemoryProtection noch stabiler laufen,aber ohne läuft es eben schon stabiler als manch anderes OS ohne MemoryProtection.

Und Gast: Ich habe ja nicht behauptet,dass das MemoryProtection Verfahren völlig sinnfrei wäre,sondern nur,solange es starke Fehler aufweist oder nahezu nicht vorhanden ist (siehe Win9x/ME.)

Übrigens regt es mich enorm auf,dass einige ihre Sätze immer mit Worten wie "Du Trottel" einführen müssen. Da stelle ich mir doch die Frage: Wer ist das Individuum,der hinter einen Computer sitzt und die Leute am laufenden Band beleidigt und provoziert. Hat derjenige womöglich sonst keine Möglichkeiten sich in seinem Umfeld zu profilieren und sucht deswegen den Weg über das Internet,wo ihn Niemand etwas kann und er mal ganz Diktator sein darf? Mir kommt diese ganze Diskussion nämlich langsam vor wie im Dritten Reich. Niemand darf euch kritisieren,wenn das dann doch der Fall ist,dann packen wir eben das große Buch "Wie untergrabe ich die Integrität meiner Mitmenschen" aus und gehen ganz nach diesem vor.

Und was den Blue-Screen und MemoryProtection angeht: Schonmal etwas von den Gurus unter AmigaOS gehört? Ist ungefähr das Selbe,nur mit dem Unterschied,dass AmigaOS in keiner Version über MemoryProtection verfügt.

So und nun macht mich ruhig wieder nieder,wegen meiner anderen Meinung,dass hat Deutschland ja auch schon immer geprägt.

del_4901

2007-08-28, 18:38:03

Ey Blinx, jeh mehr du rumruderst, umso mehr wird mir klar, das du keine Ahnung hast, wovon du eigendlich sprichst. Und mir ist einfach meine Zeit zu schade um sie an einem lernresistenten Trollkind zu verschwenden.

Gast

2007-08-28, 18:38:34

Ich bilde mir auch nichts aufs Assembler programmieren ein,nur regt es mich auf,wenn Leute meinen sie wären die Größten,nur weil sie die Grundzüge von C beherrschen.
Woher weißt du was die Leute hier beherschen?

Unter Windows ist es vielleicht auch nicht nutzlos (ausser bei Win9x,von dem ihr ja alle behauptet habt,es hätte eine sauber implementierte MemoryProtection,was sich aber mit wenigen Zeilen leicht widerlegen lässt).
Wer hat das hier behauptet? Ich hab genau das Gegenteil gesagt.

Aber andere OS' laufen eben auch ohne MemoryProtection stabil. Nicht jeder Kernel ist gleich aufgebaut wie Windows und ein gutes Beispiel für ein stabil laufendes OS ohne MemoryProtection ist wohl AROS.
Wenn man auf einem Betriebssystem nur sehr wenige Programme, welche alle auch noch eine sehr kleine Codebasis haben, ausführt, dann tendieren diese Programme dazu auch recht stabil zu laufen, das sollte wohl jedem klar sein. Heutzutage ist man aber auf sehr komplexe Software (z.B. Webbrowser mit javascript + css + allem anderen Standardzeug) angwiesen, und da sind solche Betriebssysteme ohne Speicherschutz kaum noch tragbar.

Und Gast: Ich habe ja nicht behauptet,dass das MemoryProtection Verfahren völlig sinnfrei wäre,sondern nur,solange es starke Fehler aufweist oder nahezu nicht vorhanden ist (siehe Win9x/ME.)
Nein das hast du Ursprünglich definitiv anders gesagt.

Übrigens regt es mich enorm auf,dass einige ihre Sätze immer mit Worten wie "Du Trottel" einführen müssen. Da stelle ich mir doch die Frage: Wer ist das Individuum,der hinter einen Computer sitzt und die Leute am laufenden Band beleidigt und provoziert. Hat derjenige womöglich sonst keine Möglichkeiten sich in seinem Umfeld zu profilieren und sucht deswegen den Weg über das Internet,wo ihn Niemand etwas kann und er mal ganz Diktator sein darf? Mir kommt diese ganze Diskussion nämlich langsam vor wie im Dritten Reich. Niemand darf euch kritisieren,wenn das dann doch der Fall ist,dann packen wir eben das große Buch "Wie untergrabe ich die Integrität meiner Mitmenschen" aus und gehen ganz nach diesem vor.
War ja klar das so eine armseeligen Kreatur wie du Godwins Gesetz befolgen muss.

Gast

2007-08-28, 18:41:29

Mein Taschenrechner hat übrigens auch keinen Speicherschutz. Vielleicht sollten wir ja alle darauf umsteigen.

Blinx123

2007-08-28, 18:51:07

Ich habe garantiert Nichts anderes gesagt. Ich habe gesagt,dass XP eine saubere und ordentliche MemoryProtection hat,welche alle Systeme bis einschliesslich ME nicht aufweisen. Und es soll übrigens auch Leute geben,die ihren Computer vorallem zum Arbeiten nehmen (ohne große Javascript,Flash usw. Umgebung) und da bietet ein sauber programmiertes OS genug,auch wenn es nicht über MemoryProtection verfügt.

Ich kann mich nur wiederholen: Testet einfach mal AROS.

Fehlende MemoryProtection kommt übrigens meist auch der Performance erheblich zu Gute (Forschungssysteme sind minimalistisch,und das nicht ohne Grund).

Für vollwertige,voll ausgerüstete Spielecomputer macht MemoryProtection natürlich Sinn (aber auch nur,wenn sie ordentlich integriert wurde), aber deswegen würde ich trotzdem nicht auf ein OS gänzlich verzichten,nur weil dieses etwas minimalistischer ist.

Letzten Endes kommt es nicht nur auf ein volles 3 Seiten Featureset und moderne True-Color Grafik an,tut mir echt leid,dass das Einige hier wohl nicht verstehen können:(

Auf diese Art entgeht euch großartige Software,wie auch Hardware,nur weil die Werte auf dem Datenblatt nicht auf eine Killer Application schliessen lassen:frown:

Gast

2007-08-28, 19:13:44

Ich habe garantiert Nichts anderes gesagt. Ich habe gesagt,dass XP eine saubere und ordentliche MemoryProtection hat,welche alle Systeme bis einschliesslich ME nicht aufweisen. Und es soll übrigens auch Leute geben,die ihren Computer vorallem zum Arbeiten nehmen (ohne große Javascript,Flash usw. Umgebung) und da bietet ein sauber programmiertes OS genug,auch wenn es nicht über MemoryProtection verfügt.
Auch ohne Javascript und Flash bliebt ein Browser noch ein ziemlich Brocken, es sei denn du willst sowas wie links oder lynx benutzen, dann viel Spaß.

Fehlende MemoryProtection kommt übrigens meist auch der Performance erheblich zu Gute (Forschungssysteme sind minimalistisch,und das nicht ohne Grund).
Diese Systeme laufen dann aber in einer sehr kontrollierten Umgebung. Und das das abtrennen von Prozessen nicht soo viel Sinn macht, wenn es eh nur einen einzigen interessanten laufenden Prozess gibt, ist wohl klar.

Das Speicherschutz ein kleines bischen die Performanz drückt kann stimmen. Deswegen benutzen die Betriebssteme Inferno oder Singularity (von MS) auch keinen Speicherschutz, versuchen aber trotzdem die stabilität zu erhalten, indem nur "managed" Code geduldet wird.

Letzten Endes kommt es nicht nur auf ein volles 3 Seiten Featureset und moderne True-Color Grafik an,tut mir echt leid,dass das Einige hier wohl nicht verstehen können:(

Auf diese Art entgeht euch großartige Software,wie auch Hardware,nur weil die Werte auf dem Datenblatt nicht auf eine Killer Application schliessen lassen:frown:
So "Killer" ist Speicherschutz nicht, der nutzen jedoch groß. Selbst das Betriebssytem Plan 9 hat Speicherschutz integriert, obwohl es das Ziel des Projektes ist so minimal wie Möglich zu bleiben.

Blinx123

2007-08-28, 19:27:58

So schlecht ist Links oder Lynx ja nicht. Zumindest schnell ist es und für ein wenig Foren Surfen ist es super (vorallem stören dann auch keine übergroßen Bilder).

Die meisten Systeme die ich meine wenn es um ein alternatives minimalistisches OS ohne Speicherschutz geht sind übrigens research operating systems oder auch unix basierte Systeme. AROS ist auch nichts anderes (was man auch merkt,sobald man es von der Abkürzung in den vollen Namen übersetzt).

Die Ressourcenschonung ohne MemoryProtection ist natürlich auch schwankend,je nach OS,aber Systeme wie AmigaOS und MorphOS profitieren wahnsinnig davon (ausserdem auch von den frühen präemptive multi-tasking,welches selbst das multi-tasking des aktuellsten Microsoft OS irreal und irgendwie schlecht umgesetzt aussehen lässt.)

Früher war es für mich übrigens unvorstellbar,dass es Betriebssysteme geben soll,die nahezu ohne Wartezeit beim öffnen von mehreren Fenstern aufwarten.

Gast

2007-08-28, 19:42:15

Die meisten Systeme die ich meine wenn es um ein alternatives minimalistisches OS ohne Speicherschutz geht sind übrigens research operating systems oder auch unix basierte Systeme. AROS ist auch nichts anderes (was man auch merkt,sobald man es von der Abkürzung in den vollen Namen übersetzt).
Dann zeig doch mal in wie fern diese Forschungsprojekte darauf abzielen stabil und sicher zu sein.

Übrigens ist das eben von mir genannte Plan 9 eine Art inoffizieller Unix Nachfolger. Alle drei genannten Betriebssysteme sind ebenfalls Forschungsprojekte.

Die Ressourcenschonung ohne MemoryProtection ist natürlich auch schwankend,je nach OS,aber Systeme wie AmigaOS und MorphOS profitieren wahnsinnig davon
Beweise? Gerade bei Desktop Systemen seh ich die Ressourcenschonung eher verschwindend.

Ich krieg langsam das gefühl das du dir diese Betriebssysteme nur Oberflächlich anguckst, und zwanghaft versuchst deine Beobachtungen auf die gehörten technischen Features dieser abzubilden.

(ausserdem auch von den frühen präemptive multi-tasking,welches selbst das multi-tasking des aktuellsten Microsoft OS irreal und irgendwie schlecht umgesetzt aussehen lässt.)
Beweise?

Früher war es für mich übrigens unvorstellbar,dass es Betriebssysteme geben soll,die nahezu ohne Wartezeit beim öffnen von mehreren Fenstern aufwarten.
Diese Betriebssysteme gabs schon immer, und gibs auch heute noch. Sowohl mit als auch ohne Speicherschutz. Die Trägheit des Prozessstartens ist hier klar woanders zu suchen.

(del)

2007-08-28, 19:43:09

Leute, er kann das zwar nicht so richtig aufs Papier bringen, aber ich meine man kann einen erst als behämmert fertig machen, wenn man in der Lage ist zu peilen was er meint. Und er meint a) memory protection für den kernel space und b) jeweils für die Prozesse des user space.

Nur, blinx, das auch nur eines davon auf w95 bis Me wirklich funktioniert hat, das möchte ich sehr schwer anzweifeln. Ich bin bei Win seit w95 dabei und habe schon ALLES gesehen.
Wie und ob eines davon in diesen Versionen implementiert war, spielt absolut keine Geige. Es hatte zwar gelegentlich bisschen Glück und zog die Kiste doch aus dem Dreck, ABER es konnte schon rein prinzipbedingt nicht immer 100% funktionieren. Tat es auch nicht. Das war nicht mehr als zB. CyberGuard für AmigaOS. Ehrlich jetzt.
Egal welchen Tricks oder Techniken man sich bedient. Entweder hält memory protection 100% theoretisch wie praktisch, oder nicht. Tut es das nicht 100% wenigstens im kernel space, ist ein OS nicht erst seit 2007 nicht der Rede wert.
MorphOS hat bis jetzt das Glück, daß die wenigen Leute die dafür programmieren den vollen Durchblick haben und eben zum System hin gesehen einen sauberen Kode liefern. Dazu kommt noch eine sehr überschaubare Hardware deren Treiber von ebenfalls genau solche Leuten gebacken werden.
Was meinst du warum man sich mal die MMU und memory protection ausgedacht hat?
Wenn jedes Stückchen Kode auf diesem Planeten immer die Note 1+ verdienen würde, wäre nie jemand auf solche Klötze gekommen.

Wenn dir nicht wirklich klar ist was sich im user und was im kernel space breit macht und wie es zum Straucheln kommen kann - oder was das eben überhaupt heißt - dann solltest du vielleicht paar vorsichtige Fragen stellen, statt so zu tun, als wenn du darüber mit Coda oder Alpha diskutieren könntest. Die sind da schon soweit drin, daß sie nichtmal verstehen was du fragen willst. Zugegeben stellst du deine Fragen aber auch extrem kompliziert und meistens ohne "?" am Ende ;)

So oder so schweift das alles sehr weit weg vom Thread ab. Oder deinen SH4-Beiträgen hier. Du sprichst im Thread immer neue Themengebiete an, obwohl die alten noch komplett in der Luft hängen. Und auch von da gegriffen zu sein scheinen. Zappel nicht dauernd so hin und her. Die Obercracker hier sind das nicht gewohnt ;) Ist ja auch nichts an was man sich gewöhnen sollte.

Bist du hiermit dann auch endlich gelandet, Eagle?

Edit:
Nein. So wirklich multi tasked fürs Daheim war als erstes AmigaOS. Und das hat MacOS bis 9 und TOS sofort gezeigt wo der Hammer hängt. WinDOSen waren kein Stück besser als die erwähnten, konnten ab einem gewissen Zeitpunkt mit der rohen Leistung der x86 aber viel raushauen.
Jetzt aber auch noch von präemptiv zu quaseln und es über das was zB. XP leistet zu stellen, ist entweder Dummheit, die ja vor Unwissenheit nicht schützt, oder Rumgetrolle. Für beides werden die Leute hier die Zeit bestimmt nicht opfern. Ich auch nicht.
Das was du nicht weißt können dir auch Google und Wiki beibringen. Das sind Grundlagen der Grundlagen. Und empirisch bewiesen wurden sie schon allemal.

Gast

2007-08-28, 19:50:25

Noch ein Nachtrag:

Man könnte auch Linux komplett ohne Speicherschutz laufen lassen.
Warum tut man es nicht? Na?

Weil die Vorteile zu gering sind gegen die riesigen Nachteile.

Coda

2007-08-28, 20:34:14

del_4901

2007-08-28, 20:59:37

Um daraus Nutzen zu ziehen müsste man auch komplett auf virtuellen Speicher verzichten (sobald man den benützt ist der Speicherschutz gratis) und das wäre wirklich ziemlich plöt.

Dann müssten sich alle Programme und der Kernel einen Speicherraum mit insgesamt 4GiB teilen, außerdem wäre memory mapped IO usw. nicht möglich. Ich will gar nicht drüber nachdenken X-D

Du wolltest doch aufhören ... aber genau dieser Gedankengang schoss mir auch durch den Kopf. Ok ich hab noch im "Realmode" gedacht ... aber das nimmt sich nicht viel. Den Programmloader für diese Architektur möchte ich jedenfalls nicht schreiben, schon gar nicht wenn es dann auch noch Mutitaskingfähig sein soll.

Coda

2007-08-28, 21:04:35

Du wolltest doch aufhören
Ich diskuttier ja nicht, ich ergänze nur :biggrin:

Gast

2007-08-28, 21:05:01

Stimmt, ich habe vorhin immer Speicherschutz mit virtuellem Speicher gleichgesetzt.

Übrigens von der AROS Seite:
Several hundred Amiga experts (that's what they thought of themselves at least) tried for three years to find a way to implement memory protection (MP) for AmigaOS. They failed. You should take it as a fact that the normal AmigaOS will never have MP like Unix or Windows NT.
So viel dazu....

No.3

2007-08-28, 21:27:53

Ich sage mal soviel dazu, wenn der BS kommt, dann hat die MemoryProtection hervorragend funktioniert, und somit verhindert das der Kernel korumpierten Code ausführt.

na suuuuper - und ein Reboot ist trotzdem notwendig. Für ne Guru Meditation aka BS und anschliessendem Reboot braucht man nicht wirklich ne MemoryProtection ;)

Ja, wegen der Kompatiblität zum Win3 Kern und weil es noch stark auf dem Win3 Kern aufbaut :ugly:

laut meinen Windows 3.x Freunden von damals, hat(te) Win 3 Speicherschutz - wer hat nu recht? ;)

Durch das andere OS ist das Ding auch nicht auf einmal 3x so schnell. Deine Argumente werden langsam wirklich blödsinnig. EOD.

Coda, ein Windows braucht auf einer gegeben CPU im Idle z.B. 3% CPU. Gäbe es nun für diese CPU ne native Version von Morphos und Morphos würde im Idle nur 1% von derselben CPU brauchen, dann wäre Morphos 3* so schnell.

Um daraus Nutzen zu ziehen müsste man auch komplett auf virtuellen Speicher verzichten

muss man das?

Den Programmloader für diese Architektur möchte ich jedenfalls nicht schreiben, schon gar nicht wenn es dann auch noch Mutitaskingfähig sein soll.

nimm den vom AmigaOS, oder MorphOS, etc ;)

Coda

2007-08-28, 21:32:28

na suuuuper - und ein Reboot ist trotzdem notwendig. Für ne Guru Meditation aka BS und anschliessendem Reboot braucht man nicht wirklich ne MemoryProtection ;)
Doch die braucht's. Einfach im Kernelraum rumschreiben kann Datenkorruption nach sich ziehen bis dahin, dass dir das Dateisystem verreckt.

Coda, ein Windows braucht auf einer gegeben CPU im Idle z.B. 3% CPU. Gäbe es nun für diese CPU ne native Version von Morphos und Morphos würde im Idle nur 1% von derselben CPU brauchen, dann wäre Morphos 3* so schnell.
Is klar.

muss man das?
Ja. Mit virtuellen Speicher ist der Speicherschutz gratis. Ihn nur auszuschalten bringt für die Performance also nichts.

StefanV

2007-08-28, 21:34:57

@Blinx123

Ich sehe, wie sehr du auf mein Posting eingehst, anscheinend bist du nicht in der Lage, auf die Ausführungen der anderen zu antworten und versuchst nur 'irgendwie' deine Meinung durchzudrücken, sei sie auch noch so realitätsfern...

Wie dem auch sei, ein vernünftiger Speicherschutz ist enorm wichtig, direkter Hardwarezugriff ist hingegen ein Hirnfurz aus längst vergangenen Tagen, den man nur deshalb nutzte, weil man keine andere Wahl hatte...

Ansonsten laberst einfach nur irgendwie rum...

PS: mein G4/933 fühlt sich NICHT schneller an als der P3 meiner Mutter, eher das Gegenteil...

del_4901

2007-08-28, 21:39:08

na suuuuper - und ein Reboot ist trotzdem notwendig. Für ne Guru Meditation aka BS und anschliessendem Reboot braucht man nicht wirklich ne MemoryProtection ;)

Besser als ne Neuinstallation

laut meinen Windows 3.x Freunden von damals, hat(te) Win 3 Speicherschutz - wer hat nu recht? ;)

Tante Gerda

Coda, ein Windows braucht auf einer gegeben CPU im Idle z.B. 3% CPU. Gäbe es nun für diese CPU ne native Version von Morphos und Morphos würde im Idle nur 1% von derselben CPU brauchen, dann wäre Morphos 3* so schnell.

Wenn der Hund nicht geschissen hätte, hätte er nen Hasen gehabt.

nimm den vom AmigaOS, oder MorphOS, etc ;)

Geht ohne virtuellen Speicher nur mit Relativer Adressierung und das, dass Dreck ist, hat man ganz schnell einsehen müssen.

del_4901

2007-08-28, 21:40:37

Ja. Mit virtuellen Speicher ist der Speicherschutz gratis. Ihn nur auszuschalten bringt für die Performance also nichts.

Wenn die Entwickler genausoviel Ahnung haben wie Blinx und Codinguser zusammen, bringt das enorm Performance!

Gast2

2007-08-28, 21:49:38

Wahrscheinlich versteht er einfach nicht, dass das Abhandensein des Speicherschutzes beim Amiga System kein Feature, sondern eine Einschränkung in der AmigaOS Architektur ist....

Gast35

2007-08-28, 21:52:26

"It's no bug, it's a feature!" :D:D:D:D:D:D:D:D:D

Gast35

2007-08-28, 21:55:27

Sorry wegen Doppelpost aber,

Wenn du sooo scharf darauf bist direkten Hardwarezugriff zu haben...wenn du sooo scharf darauf bist minimalistisch zu arbeiten..und wenn du es soo verdammt geil findest mal was "anderes" zu machen was deiner Meinung nicht "Mainstream ist"...

Wieso..und ich frage dich wieso...benutzt du einen Computer und nicht Stift und Papier..?..Oder Fingernägel und Dreck am Boden? Oder merkst dir den ganzen Kram einfach so wie das früher alle gemacht haben und wie Platon das auch wollte -> IN DEINEM KOPF....

No.3

2007-08-28, 22:28:34

Ja. Mit virtuellen Speicher ist der Speicherschutz gratis. Ihn nur auszuschalten bringt für die Performance also nichts.

kay, hmmmm *nachdenk* wenn ich dann also wieder die Virtual Memory Software aufm Amiga installiere, dann habe ich automatisch auch Speicherschutz?

Gast

2007-08-28, 22:31:32

Coda, ein Windows braucht auf einer gegeben CPU im Idle z.B. 3% CPU. Gäbe es nun für diese CPU ne native Version von Morphos und Morphos würde im Idle nur 1% von derselben CPU brauchen, dann wäre Morphos 3* so schnell.

ja, 3% spitze vielleicht, durchschnitt dürfte eher 0,x% sein.

Coda

2007-08-28, 22:31:59

kay, hmmmm *nachdenk* wenn ich dann also wieder die Virtual Memory Software aufm Amiga installiere, dann habe ich automatisch auch Speicherschutz?
Was weiß ich was aufm Amiga war, ich red von heutigen CPUs mit MMU. Außerdem hatte ich nicht formuliert, dass man durch virtuellen Speicher automatisch Speicherschutz bekommt. Und ich glaube auch du verwechselst virtuellen Speicher mit einem Swapfile.

Gast

2007-08-28, 22:34:06

kay, hmmmm *nachdenk* wenn ich dann also wieder die Virtual Memory Software aufm Amiga installiere, dann habe ich automatisch auch Speicherschutz?
Nein, die Architektur des Amiga Betriebssystem ist darauf ausgelegt das Speicher nicht geschützt wird, deswegen geht es nicht.

http://olis.north.de/~indy/Speicherschutz-FAQ.html

del_4901

2007-08-28, 22:37:47

Gast

2007-08-28, 22:40:15

Virtueller Speicher (Swapfile) == Swapping != Virtueller Speicher .... aber das hatten wir schon über eine Million mal! Ich weiß nicht wer diese Bezeichung in Windows eingeführt hat, aber wenn es nach mir geht, sollte man ihn steinigen!
ehh weiß ich, warum zitierst du mich??

Falls du das auf den Link den ich gepostet hab beziehst: Den hab ich nur wegen des Abschnittes "Wo liegen die Probleme bei der Erg�nzung des Amiga-OS um Speicherschutz?" gepostet.

Gast

2007-08-28, 22:40:34

Ok jetzt haste ja das Zitat entfernt..

No.3

2007-08-28, 22:51:10

Was weiß ich was aufm Amiga war, ich red von heutigen CPUs mit MMU.

nun, ab dem 68030 ist die MMU integriert

Außerdem hatte ich nicht formuliert, dass man durch virtuellen Speicher automatisch Speicherschutz bekommt.

Ja. Mit virtuellen Speicher ist der Speicherschutz gratis. Ihn nur auszuschalten bringt für die Performance also nichts.

dann solltest Du "gratis" genauer spezifizieren

Coda

2007-08-28, 22:56:22

nun, ab dem 68030 ist die MMU integriert
Amiga OS benützt aber erst gar keinen virtuellen Speicher. Auch nicht mit deinem komischen Programm.

dann solltest Du "gratis" genauer spezifizieren
Gratis steht im Allgemeinen wenn IT-Leute reden für "keine Performanceverlust". Piss mich nicht blöd an.

Gast

2007-08-28, 23:21:14

Nein, die Architektur des Amiga Betriebssystem ist darauf ausgelegt das Speicher nicht geschützt wird, deswegen geht es nicht.

http://olis.north.de/~indy/Speicherschutz-FAQ.htmlDie Architektur des AmigaOS war auf einen 68000 ausgelegt. Das ist alles. Das Teil hatte keine MMU und noch so einige Sachen nicht. Hinterher hat man einfach nur die Kompatibilität bewahrt. Sonst müßte man einen kompletten Emulator in die BootROMS hauen und eine neue Version des Betriebssystems NULL Softwarebasis hätte. War halt nicht so einfach wie mit win95 und hinterher XP (-Programmen).

No.3

2007-08-28, 23:23:40

Amiga OS benützt aber erst gar keinen virtuellen Speicher.

hab' ich auch nie behauptet. (nebenbei, k.a. was Commodore geplant hatte, es gibt aber Fragmente in einigen Systemroutinen, die auf VM (ähnliche?) Pläne schliessen lassen)

Auch nicht mit deinem komischen Programm.

schlechte Laune?

hab' mir den Quelltext noch nicht angesehen, auf jeden Fall braucht die Software ne MMU und wenn nicht mehr genug RAM da ist, gehts auf die Festplatte

Gratis steht im Allgemeinen wenn IT-Leute reden für "keine Performanceverlust".

nun, okay, virtuellen Speicher ist sozusagen das Fundament auf das man Speicherschutz aufbauen kann. Was ein OS mitbringen muss, dass auf diesem Fundament ein Speicherschutz aufgebaut werden kann, ist eine andere Frage.

Piss mich nicht blöd an.

jaja, kotz dich aus oder fick dich ins Knie

meine Fresse, ich hatte zwei Varianten im Sinn, was mit "gratis" gemeint sein könnte (und es war dann eine 3. Variante) und wollte mich lediglich vergewissern (damit nicht noch mehr aneinandervorbei geredet wird) :rolleyes::rolleyes:

Blinx123

2007-08-29, 12:18:06

Übrigens von der AROS Seite:

Several hundred Amiga experts (that's what they thought of themselves at least) tried for three years to find a way to implement memory protection (MP) for AmigaOS. They failed. You should take it as a fact that the normal AmigaOS will never have MP like Unix or Windows NT.

So viel dazu....

Und was sagt das aus? Gut,die Amiga Experten habens nie hinbekommen MemoryProtection einzuprogrammieren,aber das zeigt ja schon die deutlichen Architekturunterschiede. Ich bezweifle jedenfalls stark,dass ein paar Hundert Amiga Programmierer es nicht schaffen einen Speicherschutz zu integrieren,wenn es einfach umsetzbar wäre.

Achja und

@Gast eine Seite weiter vorn.

Ich weiss natürlich,dass ein schnelleres Multi-Tasking nicht unbedingt etwas mit MemoryProtection zu tun hat,mir gings nur darum mal zu erwähnen,dass es im Multi-Tasking Bereich auch deutliche Geschwindigkeitsunterschiede gibt. Dass das Multi-Tasking unter AmigaOS deutlich schneller ist als das von Windows (selbst bei einem gut optimierten System) steht sowieso ausser Frage (zumindest für Jeden,der mal gemessen hat,wie lange es dauert ein Fenster mit zahlreichen Ordnern unter Windows und unter AmigaOS zu öffnen.)

SavageX

2007-08-29, 12:38:09

Gast

2007-08-29, 15:21:13

Und was sagt das aus? Gut,die Amiga Experten habens nie hinbekommen MemoryProtection einzuprogrammieren,aber das zeigt ja schon die deutlichen Architekturunterschiede. Ich bezweifle jedenfalls stark,dass ein paar Hundert Amiga Programmierer es nicht schaffen einen Speicherschutz zu integrieren,wenn es einfach umsetzbar wäre.
Es ist aber nun mal so das es einzig und allein an der Amiga Architektur liegt das Speicherschutz dort so schwer (oder gar nicht) umsetzbar ist. Das gilt nicht generell.

@Gast eine Seite weiter vorn.

Ich weiss natürlich,dass ein schnelleres Multi-Tasking nicht unbedingt etwas mit MemoryProtection zu tun hat,mir gings nur darum mal zu erwähnen,dass es im Multi-Tasking Bereich auch deutliche Geschwindigkeitsunterschiede gibt. Dass das Multi-Tasking unter AmigaOS deutlich schneller ist als das von Windows (selbst bei einem gut optimierten System) steht sowieso ausser Frage (zumindest für Jeden,der mal gemessen hat,wie lange es dauert ein Fenster mit zahlreichen Ordnern unter Windows und unter AmigaOS zu öffnen.)
Du lernst es einfach nicht, oder?
Bitte informier dich genauer über die technischen Hintergründe. Mit dem Multitasking kann dieser Geschwindigkeitunterschied kaum zusammenhängen.

Mal abgesehen davon das man sowieso nicht das Multitasking eines OS generell als schneller ansehen kann als das eines anderen. Man muss bedenken wen dieses Multitasking ansprechen soll.
Echtzeitbetriebssysteme brauchen ein anderes Multitasking als Server, welche idealerweise ein anderes Mutlitasking haben als Desktop Systeme.

Also nicht blöd rumquatschen, sondern erst informieren.

Blinx123

2007-08-29, 15:45:51

Das hat rein garnichts mit wenig informieren zu tun. Ich bin schon richtig informiert. Nur sollte man sich vielleicht mal den Windows Kernel genauer ansehen,dann merkt man auch ziemlich schnell,dass MS zwar auch (und das schon seit Win95) Präemptives Multitasking verspricht,die Umsetzung aber eher eine Misch-Art ist. Mal davon abgesehen kommt es beim Multitasking natürlich auch auf die Priorität der einzelnen Tasks und auf die Ressourcenzuteilung an.

Gast

2007-08-29, 15:49:46

del_4901

2007-08-29, 15:55:37

Das hat rein garnichts mit wenig informieren zu tun. Ich bin schon richtig informiert.
Einbildung ist bei manch Einem die einzige Bildung!

Blinx123

2007-08-29, 16:05:56

Einbildung ist bei manch Einem die einzige Bildung!

Hiermit gewinnst du den Award für den blödesten Spruch der vergangenen 2000 Jahre.

Was hat das bitteschön mit Einbildung zu tun? Ich bin nicht derjenige,der hier rumbasht und andere als bescheuert,gehirnamputiert,Vollidiot usw. beschimpft. Sowas ist nämlich nicht nur peinlich sondern auch enorm eingebildet. Aber irgendwie scheint das ja inzwischen auch der ultimative Nap Thread zu werden in dem sich jeder mit seiner ach so fundierten Meinung profilieren zu wollen. Und dabei wussten vor etwa 3 Seiten die meisten von euch noch nichtmal,dass Win9x keinen wirklichen Speicherschutz hat. Und auf diesen Blue-Screen Mist will ich mal garnicht weiter eingehen,denn da es etliche Systeme ohne Speicherschutz gibt,die sich auf ähnliche Art und Weise verabschieden (Beispiel: AmigaOS Guru Meditation) dürfte wohl jeden klar sein (ausser vielleicht AlphaTier.Also wer ist hier unbelehrbar?) dass das nicht unbedingt zum SpeicherSchutz gehört.

Und um jetzt nochmal endlich zum Thema bzw. der Themen Frage zurück zu kommen und es nochmal deutlich auszudrücken: Nein,ein Pentium ist kein vollwertiger und reiner RISC Prozessor,er besitzt nur eine integrierte RISC Decoder Ebene.

SavageX

2007-08-29, 16:11:43

Und um jetzt nochmal endlich zum Thema bzw. der Themen Frage zurück zu kommen und es nochmal deutlich auszudrücken: Nein,ein Pentium ist kein vollwertiger und reiner RISC Prozessor,er besitzt nur eine integrierte RISC Decoder Ebene.

Das ist so leider zumindest leicht misszuverstehen.

Der erste Pentium (P5, P54, P55C) war gaaanz normales "CISC".

Ab Pentium Pro (P6) steckt ein kompletter RISC-Kern drin - und davon natürlich nicht nur ein "RISC Decoder". Warum sollte man die Befehle nach RISC umsetzen, wenn der Kern die dann nicht verdauen kann ;)

Gast

2007-08-29, 16:15:43

Was hat das bitteschön mit Einbildung zu tun? Ich bin nicht derjenige,der hier rumbasht und andere als bescheuert,gehirnamputiert,Vollidiot usw. beschimpft. Sowas ist nämlich nicht nur peinlich sondern auch enorm eingebildet.
Du bist wohl so ziemlich der einzige hier der peinlich ist.

Aber irgendwie scheint das ja inzwischen auch der ultimative Nap Thread zu werden in dem sich jeder mit seiner ach so fundierten Meinung profilieren zu wollen.
Es geht hier nicht um Meinungen sondern um Fakten. Du ziehst den Thread mit solchem Bullshit doch in den Dreck.

Und dabei wussten vor etwa 3 Seiten die meisten von euch noch nichtmal,dass Win9x keinen wirklichen Speicherschutz hat.
Niemand hier hat behauptet das die Speicherschutzimplementierung von Win9X Ideal war, im Gegenteil. Win9X krankte nunmal an so vielen Sachen.

Und auf diesen Blue-Screen Mist will ich mal garnicht weiter eingehen,denn da es etliche Systeme ohne Speicherschutz gibt,die sich auf ähnliche Art und Weise verabschieden (Beispiel: AmigaOS Guru Meditation) dürfte wohl jeden klar sein (ausser vielleicht AlphaTier.Also wer ist hier unbelehrbar?) dass das nicht unbedingt zum SpeicherSchutz gehört.
Und das beweist jetzt was genau?

Und um jetzt nochmal endlich zum Thema bzw. der Themen Frage zurück zu kommen und es nochmal deutlich auszudrücken: Nein,ein Pentium ist kein vollwertiger und reiner RISC Prozessor,er besitzt nur eine integrierte RISC Decoder Ebene.
... No Comment.

Anscheinend doch einfach nur ein Troll. Soviel Mist kann ein einziger Mensch einfach nicht verzapfen.

Blinx123

2007-08-29, 16:21:23

Und warum ist das letzte nun wieder nach deiner Aussage "Bullshit"? Ich habe doch nun genau das gesagt,was viele anderen auch gesagt haben. Was ist deiner Meinung nach denn nun ein Pentium? Eine RISC CPU mit integrierten CISC Decoder und beigelegten Leibniz Rechenschieber?

(del)

2007-08-29, 16:22:05

Dass das Multi-Tasking unter AmigaOS deutlich schneller ist als das von Windows (selbst bei einem gut optimierten System) steht sowieso ausser Frage (zumindest für Jeden,der mal gemessen hat,wie lange es dauert ein Fenster mit zahlreichen Ordnern unter Windows und unter AmigaOS zu öffnen.)Für einen sinnvollen Vergleich müßte man das auf der identischen Hardware machen. Bei mir dauert sowas hier auch ohne RAID... garnicht. Die Fenster gehen auf, als wenn XP immer 1s vorher schon wüßte was ich anklicken will. Und nu?

Wenn du schon so informiert bist über den Kernel und die Verteilung der Resourcen, dann frag ich dich mal was. Es geht dabei nicht um die Mhz, sondern die Last an sich:
Unter AmigaOS3 selbst mit der alleraktuellsten 45er exec.library (oder der hochoptimierten 44er ASM von dem Finnen) und auf einem 060/66, ist es keine große Kunst bei ab ~90% CPU-Last das System extrem schwerfällig zu machen. Mauslaggs inbegriffen. Wogegen XPsp2 auf einem 450Mhz P2 unter 100% CPU-Last sich noch bequem bedienen läßt. WARUM?

Hast du AmigaOS nur gebootet und sich sonst nichts tut, kannst du mit paar Testproggis aus der Unixecke aus dem Kernel fast schon realtime-like ähnliche Reaktionszeiten rauskitzeln (Benchmarkzahlen) geht es aber mit dem Multitasking wirklich ans Eingemachte, stinkt es gegenüber w2k/XP ab.

Ergo: Wenn du schon den anderen nicht traust, traue mir -> Du hast nicht wirklich Plan von der Materie. Und auch bestimmt deine Gründe warum du meine Beiträge so hartnäckig ignorierst ;)

del_4901

2007-08-29, 16:23:08

Anscheinend doch einfach nur ein Troll. Soviel Mist kann ein einziger Mensch einfach nicht verzapfen.

Ich sag doch, das ist codinguser, und das kann er noch 100'000'000x abstreiten, das bestärkt mich nur noch mehr.

Blinx123

2007-08-29, 16:33:37

Ich sag doch, das ist codinguser, und das kann er noch 100'000'000x abstreiten, das bestärkt mich nur noch mehr.

Klar,irgendwie ist hier auch jeder CodingUser,der nicht genau eurer Meinung gerecht wird. Ich komme mir hier echt schon wie in der Sklaverei vor. Die "Freie Welt" scheint in diesen Bereichen des Internets noch nicht angekommen zu sein,wenn man anderen Leuten eine Meinung aufzwingen will und dann auch noch auf die beleidigende Schiene wechselt.

PS: Ich will garnicht wissen,wieviel User täglich als CodingUser betitelt werden. Sofern der gute CodingUser keine Clone Armee züchtet ist das wohl recht weit hergeholt. Und Multi-Accounts können wohl auch kaum funktionieren,oder wie sollte ein einzelner Mensch 10 oder mehr Account befeuern und diese alle bei mehreren 100 Posts halten?

Ihr benutzt CodingUser nur irgendwie als universelle Ausrede. Sobald mal jemand aufmuckt und nicht eurer Meinung ist,ist er gleich CodingUser,der Obertroll.

(del)

2007-08-29, 16:38:47

Was ist jetzt nochmal mit meinem Monolog? Bleibt es dabei? :ulol:

HOT

2007-08-29, 16:55:07

Die Sache ist einfach: Win9x unterstützt Multitasking. Sogar Win3.11 kann mehrere Programme gleichzeitig fahren, obwohl das ebenfalls nur ein DOS Aufsatz ist (es ist sogar wesentlich mehr als das). Win3.11 (vor allem mit Win32s) und Win9x arbeiten garnicht erst auf einem Prozessor < als 386DX, weil sie eben IA32 benötigen. Deshalb brauchen auch all diese Systeme eine andere Speicherverwaltung. Die ist ähnlich wie bei NT ausgelegt, allerdings mit Kompromissen versehen. Wenn man Win9x und WinNT vergleicht, fällt da auf, dass diese in vielen Belangen sehr ähnlich arbeiten. Win9x ist ein echtes 32Bit OS, das sollte man immer bedenken. Win3.11 ist ein Hybrid und mit Win32S 32Bit fähig. Alle Windows bis 3.10 lassen sich auf reinen 16Bit CPUs nutzen, Win3.11 nicht mehr.
WinNT geht da noch einen Schritt weiter und ersetzt den DOS Kernel gleich durch einen 32Bit Kernel. Dieser blieb aktuell bis zu Windows2003 x64, dort arbeitet ein AMD64/SSE2 Kernel. Das heisst aber nicht, dass man sich gewisse Routinen in Win3.11 und Win9x sparen konnte, nur weil ein DOS darunter liegt. Im Gegenteil, man hat einen Spagat gemacht und der ist ja z.T. auch misslungen ;).

Gast

2007-08-29, 16:59:03

Die Sache ist einfachHatten wir sowas nicht schon die Tage? :uup:

(...)
Zum Thread trägt die Information, daß Win3.1 mehrere Programme auf einmal ausführen kann, nicht wirklich etwas bei...

BH

del_4901

2007-08-29, 17:03:30

Gast

2007-08-29, 17:04:23

Ok. Der Edit war schon besser ;)

BH

(del)

2007-08-29, 17:58:33

Blinx123

2007-08-29, 18:20:45

Das beste fällt mir erst immer nach dem Auslogen ein :frown:

Hej Blinx, mein schnell Ausgelogter, was ist mit BeOS? Das hatte (hat) einen Multitasking welcher nicht nur AmigaOS, sondern auch XP in Grund und Boden fuhr. Aber sowas von überrundend...
Und jetzt kommt der Knaller. BeOS hatte 1A Speicherschutz für kernel space wie auch für user space.

Was willst du mir hier jetzt also erzählen und wie belegen?

Was ich dir jetzt erzählen will? BeOS rockt:) Die Entwickler davon waren nicht umsonst eine ganze Weile sehr erfolgreich und die große Fangemeinde existiert auch nicht umsonst. Ich habe auch nichts gegen Speicherschutz für Kernel- wie auch User Space,mir gings nur darum zu erwähnen,dass es auch Systeme gibt,die ohne Speicherschutz super auskommen. Es kommt natürlich auf die Programmierung des Kernels und der Ressourcenverteilung an.

Und mit dem Multi-Tasking ist es eben so eine Sache. Da hast du schon recht,ist wirklich sehr anwendungsabhängig. Ich zeichne unter AmigaOS meist nur,lasse nebenbei ein Adventure oder Jump'N'Run im Fenster laufen und spiele im Hintergrund eine MP3 ab,damit komme ich nicht wirklich an 100% Auslastung ran (die MP3 sorgt allerdings zum größten Teil für etwaiige Einbrüche)

Unter WinXP komme ich allerdings meist immer eher bei 100% an. Dabei läuft da eigentlich nur AOL, das HP Druckprogramm und ab und an eine MP3 (die MP3 Player unter Windows sind aber mal erfreulich ressourcenschonend im Vergleich zu den Amiga Pendants.) Wobei die 100% Auslastung da ein Bug der neuesten AOL Version sind. Ich werde zum Beispiel ständig aufgefordert zu updaten,sobald ich aus dem Internet raus will und muss dann AOL erstmal auf die schmerzhafte Art schliessen (AOL über den Taskmanager überladen,bis es abstürzt. Folge: Kurzzeitig bis zu 100% Auslastung)

Aber mir ging es ja eigentlich nicht um die ausgeführten Anwendungen,sondern auch mehr um den Speed,wenn man mehrere Fenster öffnet und da ist AmigaOS bei mir im Schnitt 5 Sek. eher mit den Laden fertig als WinXP (gleiche HDD,jeweils Standard Fenstermanager). Amiga OS ist übrigens 3.1 und verwendet die Startdock sowie Scalos.

WinXP ist die Home Edition mit SP2 und alles @standard.

Das zeigt,dass man auch ein schönes OS mit einigen Eye Candys releasen kann,ohne die Ressourcennutzung zu hoch zu treiben.

(del)

2007-08-29, 18:32:40

mir gings nur darum zu erwähnen,dass es auch Systeme gibt,die ohne Speicherschutz super auskommenNein. Tun sie nicht. nur die User arrangieren sich damit und/oder haben Glück mit ihrem "Nutzungsmuster" des Systems.

Ich zeichne unter AmigaOS meist nur,lasse nebenbei ein Adventure oder Jump'N'Run im Fenster laufen und spiele im Hintergrund eine MP3 ab,damit komme ich nicht wirklich an 100% Auslastung ranDann möchte ich hiermit aber mein Mitgefühl ausdrücken. Mit 6 Augen, 4 Händen und 3 Ohren sollte es wirklich nicht einfach sein einen Lebenspartner zu finden :|

Unter WinXP komme ich allerdings meist immer eher bei 100% an. Dabei läuft da eigentlich nur AOL, das HP Druckprogramm und ab und an eine MP3P1-50Mhz?

Wobei die 100% Auslastung da ein Bug der neuesten AOL Version sindAh so. Worüber reden wir dann also hier? Laß mal etwas genauso verbuggtes, was dir die Leistung dermassen zieht, auf dem Amiga laufen und dann vergleichen wir die Zuständen nochmal.

Aber mir ging es ja eigentlich nicht um die ausgeführten Anwendungen,sondern auch mehr um den Speed,wenn man mehrere Fenster öffnet und da ist AmigaOS bei mir im Schnitt 5 Sek. eher mit den Laden fertig als WinXPAlso doch Pentium1?

Das zeigt,dass man auch ein schönes OS mit einigen Eye Candys releasen kann,ohne die Ressourcennutzung zu hoch zu treiben.Das zeigt höhstens nur, daß du mit deiner Kiste mittlerweile schon den Server selbst für ein Botnetz am laufen hast.
Installier mal neu und formatier die Platte vorher am besten am Amiga oder an einem System was FAT/NTFS nicht lesen kann.

del_4901

2007-08-29, 18:41:04

Das zeigt höhstens nur, daß du mit deiner Kiste mittlerweile schon den Server selbst für ein Botnetz am laufen hast.

muhahahahaha, u made my day! Den muss ich mir merken!

Gast

2007-08-29, 19:33:33

Bannt den Kerl doch endlich mal, langsam nervts.

Gast

2007-08-29, 19:50:00

Was ich dir jetzt erzählen will? BeOS rockt:) Die Entwickler davon waren nicht umsonst eine ganze Weile sehr erfolgreich und die große Fangemeinde existiert auch nicht umsonst. Ich habe auch nichts gegen Speicherschutz für Kernel- wie auch User Space,mir gings nur darum zu erwähnen,dass es auch Systeme gibt,die ohne Speicherschutz super auskommen. Es kommt natürlich auf die Programmierung des Kernels und der Ressourcenverteilung an.

Und mit dem Multi-Tasking ist es eben so eine Sache. Da hast du schon recht,ist wirklich sehr anwendungsabhängig. Ich zeichne unter AmigaOS meist nur,lasse nebenbei ein Adventure oder Jump'N'Run im Fenster laufen und spiele im Hintergrund eine MP3 ab,damit komme ich nicht wirklich an 100% Auslastung ran (die MP3 sorgt allerdings zum größten Teil für etwaiige Einbrüche)

Unter WinXP komme ich allerdings meist immer eher bei 100% an. Dabei läuft da eigentlich nur AOL, das HP Druckprogramm und ab und an eine MP3 (die MP3 Player unter Windows sind aber mal erfreulich ressourcenschonend im Vergleich zu den Amiga Pendants.) Wobei die 100% Auslastung da ein Bug der neuesten AOL Version sind. Ich werde zum Beispiel ständig aufgefordert zu updaten,sobald ich aus dem Internet raus will und muss dann AOL erstmal auf die schmerzhafte Art schliessen (AOL über den Taskmanager überladen,bis es abstürzt. Folge: Kurzzeitig bis zu 100% Auslastung)

Aber mir ging es ja eigentlich nicht um die ausgeführten Anwendungen,sondern auch mehr um den Speed,wenn man mehrere Fenster öffnet und da ist AmigaOS bei mir im Schnitt 5 Sek. eher mit den Laden fertig als WinXP (gleiche HDD,jeweils Standard Fenstermanager). Amiga OS ist übrigens 3.1 und verwendet die Startdock sowie Scalos.

WinXP ist die Home Edition mit SP2 und alles @standard.

Das zeigt,dass man auch ein schönes OS mit einigen Eye Candys releasen kann,ohne die Ressourcennutzung zu hoch zu treiben.

Willst du zensiert einfach nicht verstehen das das NICHTS aber auch GAR NICHTS mit Multithreading oder Speicherschutz zu tun hat?

Thowe

2007-09-02, 00:00:07

Wieder offen ...

Auch wenn der Sprachstil mehr als nur Diskrepanzen aufweist, aber ich denke, der Thread hat stellenweise Potential und ihn deshalb geschlossen zu lassen wäre nicht wirklich perfekt.

Wie dem auch sei. Es gibt eine ganz einfache Regel, wenn jemand eben nicht versteht, auf was man hinaus will oder man aneinander vorbei redet oder eben sich annervt - Ruhe bewahren und die Person ignorieren und wenn man es per Willen nicht kann, gibt es eine Funktion dafür.

Ich bitte um sauberen Sprachstil! Danke!

Plissken

2007-09-02, 15:23:20

Wogegen XPsp2 auf einem 450Mhz P2 unter 100% CPU-Last sich noch bequem bedienen läßt. WARUM?

Stimmt absolut nicht. Ich kann bei 2K sogar 30sek Freezes erleben oder Mauslags. Ich spüre schon, wenn die CPU auf 60% ist.

Gast

2007-09-02, 15:58:44

Das hatten wir hier schon hier. Das liegt am Botnetz-Server.

BH

Gast

2007-09-04, 12:40:11

Es gibt auch praktisch keine reinen RISC-Prozessoren mehr, von daher ist die ganze Diskussion hinfällig.
klar gibt es die noch: ARM, SPARC, MIPS, PowerPC alles reine RISC cpus.
Außerdem haben auch diese heute Decoderstages, womit der Vorteil auch flöten gegangen ist.
jede RISC CPU hat eine decode-stage. decode ist die zweite stufe der klassischen RISC pipeline. http://en.wikipedia.org/wiki/Classic_RISC_pipeline
x86 hat dafür den Vorteil eine ziemlich effiziente Codekompression zu sein ohne dadurch große Nachteile zu haben bei heutigen Logikmengen.
du findest eine kompression von 2, 3, 4% effektiv?
und die 30, 40% logik, die für x86 translate verbraucht wird, sind für dich kein nachteil?

Coda

2007-09-04, 15:43:36

klar gibt es die noch: ARM, SPARC, MIPS, PowerPC alles reine RISC cpus.
Das ist kein reines RISC mehr. Das "Reduced" trifft einfach nichtmehr zu. PowerPC hat Altivec, ARM hat Thumb, usw.

jede RISC CPU hat eine decode-stage. decode ist die zweite stufe der klassischen RISC pipeline. http://en.wikipedia.org/wiki/Classic_RISC_pipeline
Dann versteh ich nicht, warum immer so darauf rumgeritten wird, dass der Befehlssatz eine schnellere Ausführung ermöglichen soll weil er einfacher zu interpretieren ist.

du findest eine kompression von 2, 3, 4% effektiv?
Das ist weitaus mehr. x86-Code hat höchstens 75% der Größe von 4-Byte-RISC.

und die 30, 40% logik, die für x86 translate verbraucht wird, sind für dich kein nachteil?
Und das ist weitaus weniger. Bei den heutigen Logikmengen spielt das kaum noch eine Rolle. Dass das nicht sein kann sieht man schon an Die-Shots. Ich vermute, dass das Decode eines PowerPC G5 nicht viel weniger Logik braucht.

Proof:
PowerPC 970 FX (58 Mio. Transistoren - 512KiB Cache): http://www.mujmac.cz/images/IBM_powerpc970fx_die.jpg
Athlon 64 (68,5 Mio. Transistoren für die 512KiB Cache-Version - auf dem Bild sind's 1MiB): http://www.chip-architect.com/news/Opteron_1600x1200.jpg

Da sehe ich bei dem PowerPC nicht weniger Logik, die für Instruction Sequencing, Dispatch und Fetch aufgewendet wird. Die IPC-Rate ist auch ähnlich bei beiden Architekturen.

Die Zeiten in denen das Decoding von x86 ein Problem war von der Logikmenge sind definitiv schon lange vorbei.

Gast

2007-09-05, 11:19:00

Das ist kein reines RISC mehr. Das "Reduced" trifft einfach nichtmehr zu. PowerPC hat Altivec, ARM hat Thumb, usw.
blödsinn. altivec ist genauso reduced, wie der rest vom befehlssatz.
oder was bringt dich zu glauben, dass das nicht reduced ist?

Dann versteh ich nicht, warum immer so darauf rumgeritten wird, dass der Befehlssatz eine schnellere Ausführung ermöglichen soll weil er einfacher zu interpretieren ist.
wie soll ein prozessor denn ohne decode functionieren?
oder verwechselst du decode mit x86-translate?

decode ist viel einfacher bei RICS.
alle befehle sind gleich lang. das ist ein gleichmässiger datenstrom.
alle befehle haben die gleiche struktur. in allen befehlen ist der opcode gleich lang. in allen befehlen sind die destinations-register an der gleichen stelle. etc.
befehle enthalten keine speicheradressen (nicht mal load und stores enthalten speicheradressen, die berechnen die nur).

beim x86 muss erst mal rausgefunden werden, wo der befehl aufhört und der nächste endet. es muss rausgefunden werden, wo der opcode endet. es muss rausgefunden werden, ob register oder speicheradressen gemeint sind. etc.
dann wird das ganze beim x86 translate in mehrere myops aufgeteilt.
die gehen dann in das interne fetch und decode. ab da ist das genauso, wie beim RISC prozessor. der muss aber nicht den ganzen hickhack vorher machen.

Das ist weitaus mehr. x86-Code hat höchstens 75% der Größe von 4-Byte-RISC.
vergleich doch einfach mal, bevor du solchen blödsinn erzählst.
z.b. ein identisches programm für x86 und ppc, iTunes für Mac OS X: ppc 12,6 mb, i386 12,4 mb (nur das binary, ohne gui). das sind keine 25%.
es kann sogar vorkommen, dass der x86 code größer ist, als der ppc code. z.b. TextEdit: ppc 132kb, i386 136kb.

Und das ist weitaus weniger. Bei den heutigen Logikmengen spielt das kaum noch eine Rolle.
glaubst du völlig falsch.
beim p6-core waren 40% der transistoren mit x86 translate beschäftigt. bei den nachfolgern ist zwar das backend aufwendiger geworden, aber auch die x86 translate einheit. daher dürfte das verhältnis geblieben sein.

Dass das nicht sein kann sieht man schon an Die-Shots. Ich vermute, dass das Decode eines PowerPC G5 nicht viel weniger Logik braucht.
Proof:
PowerPC 970 FX (58 Mio. Transistoren - 512KiB Cache): http://www.mujmac.cz/images/IBM_powerpc970fx_die.jpg
Athlon 64 (68,5 Mio. Transistoren für die 512KiB Cache-Version - auf dem Bild sind's 1MiB): http://www.chip-architect.com/news/Opteron_1600x1200.jpg

Da sehe ich bei dem PowerPC nicht weniger Logik, die für Instruction Sequencing, Dispatch und Fetch aufgewendet wird. Die IPC-Rate ist auch ähnlich bei beiden Architekturen.
man sieht, wie klein die decode/dispatch einheit beim g5 ist.
außerdem hat der athlon ein um 1/4 kleineres back end, als der g5. aber trotzdem 10,5 Mio transistoren mehr. das back end vom g5 ist in der weite vergleichbar mit dem core 2.

instruction sequencing hat nix mit decode zu tun. instruction sequencing hat was mit oooe zu tun. die logikmenge, die der g5 dafür braucht, ist wirklich sehr groß. ist ne eigenart des g5.

Die Zeiten in denen das Decoding von x86 ein Problem war von der Logikmenge sind definitiv schon lange vorbei.
das glaubst du. stimmt aber nicht.
in zeiten, wo auf mehr cores gesetzt wird, wird sich die logikmenge, die für x86 translate gebraucht wird auch nicht weiter verringern.

SavageX

2007-09-05, 12:02:30

blödsinn. altivec ist genauso reduced, wie der rest vom befehlssatz.
oder was bringt dich zu glauben, dass das nicht reduced ist?

Die Tatsache, dass für bestimmte Felder eigene Instruktionen eingeführt wurden, läuft eigentlich gegen den RISC-Gedanken.

vergleich doch einfach mal, bevor du solchen blödsinn erzählst.
z.b. ein identisches programm für x86 und ppc, iTunes für Mac OS X: ppc 12,6 mb, i386 12,4 mb (nur das binary, ohne gui). das sind keine 25%.
es kann sogar vorkommen, dass der x86 code größer ist, als der ppc code. z.b. TextEdit: ppc 132kb, i386 136kb.

Das kommt ganz auf den Compiler an, kann somit nicht als Vergleichsgrundlage dienen.

glaubst du völlig falsch.
beim p6-core waren 40% der transistoren mit x86 translate beschäftigt. bei den nachfolgern ist zwar das backend aufwendiger geworden, aber auch die x86 translate einheit. daher dürfte das verhältnis geblieben sein.

Ich hätte gerne mal eine Angabe, wo diese 40%-Zahl herkommt. Fakt ist, dass heutige Prozessoren keine 40% Die-Fläche auf die x86-Übersetzung verwenden.

Weiterhin hat man auch einen Vorteil, wenn man schon in die Verlegenheit kommt, Instruktionen zu übersetzen: Man kann sie in wirklich für den Kern mundgerechte Befehle umsetzen, ohne durch den externen Befehlssatz eingeschränkt zu sein.

man sieht, wie klein die decode/dispatch einheit beim g5 ist.
außerdem hat der athlon ein um 1/4 kleineres back end, als der g5. aber trotzdem 10,5 Mio transistoren mehr. das back end vom g5 ist in der weite vergleichbar mit dem core 2.

Du vergleichst hier leider unterschiedliche Sorten Obst, da jede Architektur einen unterschiedlichen Fokus in Bezug auf Transistorbudgets hat. Vergleich mal ein Design von Centaur mit einem Intel-Design.

Und Breite ist nicht alles, die Gestaltung und Anbindung der Ausführungseinheiten an sich zählt auch.

in zeiten, wo auf mehr cores gesetzt wird, wird sich die logikmenge, die für x86 translate gebraucht wird auch nicht weiter verringern.

Die Entwicklung zu Mehrkernen verschiebt aber selbstverständlich nicht das Verhältnis von Decode/Translation zu Execution.

Gast

2007-09-05, 13:00:24

Die Tatsache, dass für bestimmte Felder eigene Instruktionen eingeführt wurden, läuft eigentlich gegen den RISC-Gedanken.
nee. das hat mit RISC nix zu tun.
ganz im gegenteil entspricht das dem RISC gedanken. RISC hat für die felder load und store eigene befehle eingeführt. die hat CISC nicht.

Das kommt ganz auf den Compiler an, kann somit nicht als Vergleichsgrundlage dienen.
es ist der selbe compiler verwendet worden, gcc. sogar in einem schub durchkompiliert. die zahlen sind von extrahierten i386 und ppc binarys aus universal binarys.

Ich hätte gerne mal eine Angabe, wo diese 40%-Zahl herkommt. Jon Hannibal Stokes von arstechnica. der hat die zahl aus erster hand von intel ingenieuren.
Fakt ist, dass heutige Prozessoren keine 40% Die-Fläche auf die x86-Übersetzung verwenden.
davon war nicht die rede. nicht 40% der die fläche. 40% der logik.
cache zählt da nicht zu.

Weiterhin hat man auch einen Vorteil, wenn man schon in die Verlegenheit kommt, Instruktionen zu übersetzen: Man kann sie in wirklich für den Kern mundgerechte Befehle umsetzen, ohne durch den externen Befehlssatz eingeschränkt zu sein.
der gedanke von RISC ist, die externen ISA befehle so zu gestalten, dass sie mundgerecht für den kern sind.
das ist RISC. eine ISA, die direkt vom prozessor verarbeitet werden kann. ohne microprogramming, ohne translation etc.

Die Entwicklung zu Mehrkernen verschiebt aber selbstverständlich nicht das Verhältnis von Decode/Translation zu Execution.
sag ich ja. das verhältnis wird nicht besser.

Other Gast

2007-09-05, 13:06:20

SavageX

2007-09-05, 13:51:18

nee. das hat mit RISC nix zu tun.
ganz im gegenteil entspricht das dem RISC gedanken. RISC hat für die felder load und store eigene befehle eingeführt. die hat CISC nicht.

Was hat load und store damit zu tun, dass RISC traditionell dafür stand, den Instruktionssatz möglichst klein zu halten, um den direkt abarbeiten zu könnnen? CISC-Architekturen haben/hatten für viele Spezialfälle eigene Befehle, das Hinzufügen von Extrakram kann man als Schritt Richtung CISC verstehen. Muss man aber nicht.

es ist der selbe compiler verwendet worden, gcc. sogar in einem schub durchkompiliert. die zahlen sind von extrahierten i386 und ppc binarys aus universal binarys.

i386 und ppc haben selbstverständlich unterschiedliche Backends, bei denen auch Optimierungsoptionen anders einschlagen.

Aus theoretischer Sicht haben Befehlssätze mit fixer Befehlslänge jedenfalls einen Platznachteil gegenüber Befehlssätzen mit variabler Länge. Einfache Befehle sollten kürzer sein als "mächtige" Befehle, ansonsten hat man Verschnitt. Auf der Platte schert es keinen, aber Cache ist ja teuer...

edit: Hier mal ein salopper Artikel, der auch mal die Schattenseiten von RISC beleuchtet...
http://www.embedded.com/story/OEG20030205S0025

davon war nicht die rede. nicht 40% der die fläche. 40% der logik.
cache zählt da nicht zu.

Wenn 40% der Logik für x86-translate draufgehen, dann wird auch ungefähr 40% der Die-Size des Logikteils (wohlgemerkt, ohne Cache) dafür draufgehen. Oder es gibt einen einleuchtenden Grund, warum man ausgerechnet den Übersetzungsteil dichter packen kann. Dann kostet die x86-Übersetzung aber auch weniger, als eine "40%"-Angabe vermuten lässt.

So oder so: Aus wirtschaftlicher Sicht lohnt sich x86-Kompatibilität recht offensichtich.

der gedanke von RISC ist, die externen ISA befehle so zu gestalten, dass sie mundgerecht für den kern sind.
das ist RISC. eine ISA, die direkt vom prozessor verarbeitet werden kann. ohne microprogramming, ohne translation etc.

Vollkommen richtig, das ist der Grundgedanke.

Nur ist das bei einen Befehlssatz wie PPC, der schon recht groß und mächtig ist, sicherlich auch keine einfache Übung.

sag ich ja. das verhältnis wird nicht besser.

Aber eben auch nicht schlechter, so dass ich nicht verstehe, dass Multicore als Argument herangezogen wird.

Coda

2007-09-05, 14:40:20

vergleich doch einfach mal, bevor du solchen blödsinn erzählst.
z.b. ein identisches programm für x86 und ppc, iTunes für Mac OS X: ppc 12,6 mb, i386 12,4 mb (nur das binary, ohne gui). das sind keine 25%.
es kann sogar vorkommen, dass der x86 code größer ist, als der ppc code. z.b. TextEdit: ppc 132kb, i386 136kb.
Das siehst du nicht am Binary wegen Padding usw.
x86-Code ist im Prinzip ein Huffman-Coding. Die am meisten benützen Instructions brauchen nur 1 Byte wie RET, POP, PUSH usw.

glaubst du völlig falsch.
beim p6-core waren 40% der transistoren mit x86 translate beschäftigt. bei den nachfolgern ist zwar das backend aufwendiger geworden, aber auch die x86 translate einheit. daher dürfte das verhältnis geblieben sein.
Erstmal solltest du mal den Die-Shot nochmal genau anschauen. Da sind das beim Athlon 64 auf keinen Fall 40%. Maximal 20% mit Microcode. Das größte daran ist der massiv parallele Vordekodierer. Danach dürfte das meiste eh kein Problem mehr sein, weil man genau weiß wo und wieviele Befehle vorhanden sind.

Das Verhältnis sinkt auf jeden Fall, weil man mehr Transistoren in die Ausführungseinheiten und Out-Of-Order-Execution steckt als ins Decoding.

Core 2 hat z.B. eine sehr große intelligente Prefetch-Logik und eine dedizierte Stack-Engine. Das hat rein gar nichts mit x86 zu tun, braucht aber viel Logik. Zudem sind doch heute die Caches eh größer als der ganze Kern.

man sieht, wie klein die decode/dispatch einheit beim g5 ist.
außerdem hat der athlon ein um 1/4 kleineres back end, als der g5. aber trotzdem 10,5 Mio transistoren mehr. das back end vom g5 ist in der weite vergleichbar mit dem core 2.
Ich sehe da, dass für den gesamten Befehlskram nicht weniger aufgewendet werden muss wie bei einem Athlon um die gleiche IPC-Rate zu erreichen. Wo ist da also der Vorteil?
x86-Code hat auch den Vorteil mehr Informationen in sich zu tragen als RISC.

der gedanke von RISC ist, die externen ISA befehle so zu gestalten, dass sie mundgerecht für den kern sind.
Nur leider ist da nichts mehr Mundgerecht. Mundgerecht für heutige Kerne wäre sowas wie VLIW oder EPIC, das auch die Parallelität der Ausführungseinheiten beinhaltet. Aber eigentlich ist auch das nicht mundgerecht, weil es die Out-Of-Order-Ausführung nicht beinhaltet.

Aber wieso bleibt man dann nicht gleich vollständig bei CISC, auch in der CPU?
Kann man nicht effektiv ausführen, weil die Befehle zu lang sind für die Pipelinestages. Es gibt auch keinen ausgewachsenen RISC-Prozessor mehr der das täte.

Gast

2007-09-05, 16:10:53

Was hat load und store damit zu tun, dass RISC traditionell dafür stand, den Instruktionssatz möglichst klein zu halten, um den direkt abarbeiten zu könnnen?
da ist also das missverständnis. RISC steht nicht dafür, den instruktionssatz möglichst klein zu halten. RISC steht dafür die ISA so zu gestalten, dass der Prozessor sie direkt ohne microcode oder translation verarbeiten kann.

reduced heißt nicht reduziert auf wenig. reduced heißt reduziert auf das was der prozessor kann.
als anderes wort für RISC wird auch load/store architecture benutzt.

CISC-Architekturen haben/hatten für viele Spezialfälle eigene Befehle, das Hinzufügen von Extrakram kann man als Schritt Richtung CISC verstehen. Muss man aber nicht.
sollte man nicht, weils blödsinn wäre.
mehr befehle haben nix gegen RISC, solange alle befehle die RISC eigenschaften haben. und wenns tausende befehle wären.

Aus theoretischer Sicht haben Befehlssätze mit fixer Befehlslänge jedenfalls einen Platznachteil gegenüber Befehlssätzen mit variabler Länge. Einfache Befehle sollten kürzer sein als "mächtige" Befehle, ansonsten hat man Verschnitt. Auf der Platte schert es keinen, aber Cache ist ja teuer...
aus theoretischer sicht, kann sein. praktisch ist da aber nix mehr von zu sehen. auch, weil beim x86 nur 2 operaden gehen und schon mal geschoben und kopiert werden muss, wenn daten in registern erhalten bleiben sollen.

Wenn 40% der Logik für x86-translate draufgehen, dann wird auch ungefähr 40% der Die-Size des Logikteils (wohlgemerkt, ohne Cache) dafür draufgehen. Oder es gibt einen einleuchtenden Grund, warum man ausgerechnet den Übersetzungsteil dichter packen kann. Dann kostet die x86-Übersetzung aber auch weniger, als eine "40%"-Angabe vermuten lässt.auf dem bild vom athlon 64 ist der teil schon enorm groß.

ich glaube die 40% angabe. jon hannibal stokes ist einer, der sich wirklich auskennt. kein dummlaberer.
im P6 waren es 40% mit einer simple translate einheit und einer microcode engine. beim core 2 sind es 3 simple translate, dazu macro ops fusion, der buffer ist vier mal so groß etc. das backend ist in etwa um um das doppelte größer geworden. das verhältnis bleibt also.

Nur ist das bei einen Befehlssatz wie PPC, der schon recht groß und mächtig ist, sicherlich auch keine einfache Übung.die meisten ppc prozessoren haben da kein problem mit.
der g5 is ne ausnahme. der splittet ein oder zwei befehle in einfachere powerpc befehle auf um im backend zu sparen. hat was mit befehlsgruppierung zu tun, nicht mit der ppc ISA.

Aber eben auch nicht schlechter, so dass ich nicht verstehe, dass Multicore als Argument herangezogen wird.
es wird aber eben auch nicht besser, was immer als argument genommen wird, dass x86 kompatibilität immer weniger kostet.

Ganon

2007-09-05, 16:17:32

RISC steht nicht dafür, den instruktionssatz möglichst klein zu halten.

Ach deswegen heißt es Reduced Instruction Set Computing :|

Gast

2007-09-05, 16:23:25

Das siehst du nicht am Binary wegen Padding usw
im speicher sieht man das auch nicht. mac os x braucht auf intel mehr speicher, als auf ppc.
x86-Code ist im Prinzip ein Huffman-Coding. Die am meisten benützen Instructions brauchen nur 1 Byte wie RET, POP, PUSH usw.
die tatsächlich im code verwendeten instruktionen sind im schnitt 3,5 byte groß.

x86-Code hat auch den Vorteil mehr Informationen in sich zu tragen als RISC.
das ist kein vorteil, sondern ein nachteil. der prozessor muss die informationen erst aus dem befehl rausoperieren, bevor er anfangen kann zu arbeiten. ein prozessor kann nur mit registerinhalten und immidiates arbeiten. mit speicherinhalten kann kein prozessor arbeiten, auch wenn die in CISC befehlen speicheradressen eingebaut sind.

Nur leider ist da nichts mehr Mundgerecht. Mundgerecht für heutige Kerne wäre sowas wie VLIW oder EPIC, das auch die Parallelität der Ausführungseinheiten beinhaltet. Aber eigentlich ist auch das nicht mundgerecht, weil es die Out-Of-Order-Ausführung nicht beinhaltet.
das ist blödsinn. die befehle bei RISC sind mundgerecht, die müssen nur bei decode/dispatch auf die einheiten verteilt werden. superscalare prozessoren gibt es nur wegen RISC.

Kann man nicht effektiv ausführen, weil die Befehle zu lang sind für die Pipelinestages. Es gibt auch keinen ausgewachsenen RISC-Prozessor mehr der das täte.
die antwort ist auch blödsinn.

Coda

2007-09-05, 16:28:04

Die einzigen Teile die logischerweise wirklich mehr Platz brauchen als ein RISC-Fixed-Length-Encoder in K8 ist der massiv parallele Predecoder und der Microcode inkl. Ausführung desjenigen. Das sind aber ganz sicher keine "40% der Logik". Was man auch sehr gut sieht.

die tatsächlich im code verwendeten instruktionen sind im schnitt 3,5 byte groß.
Gibt's dafür auch eine Quelle? Und wenn das tatsächlich der Fall ist sind es definitiv mehr als "2, 3, 4%" weil eine x86-Instruction auch mehr Informationen beinhaltet als eine 4-Byte-RISC-Instruction, weil die Loads und Stores schon drin sind.

das ist kein vorteil, sondern ein nachteil. der prozessor muss die informationen erst aus dem befehl rausoperieren, bevor er anfangen kann zu arbeiten.
Nur hat ein K8 auch nicht mehr Decoding-Stages als ein G5. Einen zeitlichen Nachteil sehe ich da nicht mehr. Heute macht man einfach Brute-Force drauf und gut is.

das ist blödsinn. die befehle bei RISC sind mundgerecht, die müssen nur bei decode/dispatch auf die einheiten verteilt werden. superscalare prozessoren gibt es nur wegen RISC.
Die Micro-Ops von G5 und jedem anderen modernen PPC-Prozessor sind sicher nicht im PowerPC-Format.

Und um auf die Idee zu kommen mehrere Befehle parallel abzuarbeiten um die IPC-Rate zu erhöhen hat man ganz bestimmt kein RISC gebraucht. Der Pentium war auch noch CISC und schon "superskalar".

die antwort ist auch blödsinn.
Viele CISC-Befehle werden über Microcode in kleinere Befehle zerteilt damit CPU sie schnell genug in die Pipelinestages ausführen kann. Das ist kein "Blödsinn".

Auf die Punkte wo ich gute Argumente hab wird natürlich gar nicht mehr eingegangen. Warum sollte ich mich hier noch rumstreiten? Soll sich doch jeder sein eigenes Bild machen.

Gast

2007-09-05, 16:34:42

Mal 'ne dumme frage. Wieso nimmt man eine CISC-ISA, wenn die in etwas RISC-ähnliches zerlegt wird. Wieso nimmt man dann nicht direkt RISC? OK, historisch gewachsen...

Aber wieso bleibt man dann nicht gleich vollständig bei CISC, auch in der CPU?
weil cisc nicht dafür geeignet ist mehrere dinge gleichzeitig zu machen.
bei richtigem cisc muss für jeden befehl ein programm im inneren des prozessors gestartet werden. bei RISC können befehle in pipelines verarbeit werden. da wird der nächste befehl schon angenommen, wenn der vorherige noch gar nicht fertig ist.

Gast

2007-09-05, 16:36:45

Ach deswegen heißt es Reduced Instruction Set Computing :|
kleine leseschwäche, wie.
danach kommt noch ein satz: RISC steht dafür die ISA so zu gestalten, dass der Prozessor sie direkt ohne microcode oder translation verarbeiten kann.
ISA = Instruction Set.

Coda

2007-09-05, 16:40:04

weil cisc nicht dafür geeignet ist mehrere dinge gleichzeitig zu machen.
bei richtigem cisc muss für jeden befehl ein programm im inneren des prozessors gestartet werden. bei RISC können befehle in pipelines verarbeit werden. da wird der nächste befehl schon angenommen, wenn der vorherige noch gar nicht fertig ist.
Das hat überhaupt nichts mit RISC und CISC zu tun. Eine RISC-Instruction kann genauso abhängig von einer anderen sein wie eine CISC-Instruction. Da gibt es überhaupt keinen Unterschied. Moderne x86-Prozessoren haben auch ein Instruction-Window das weitaus größer ist als ein Befehl. Der Decoder von K8 wirft pro Takt mindestens 3 Befehle hinten raus, bei Core 2 Duo ist es noch mehr.

Und es muss nicht für jeden CISC-Befehl ein Microcode-Programm ausgeführt werden. So ein Unsinn. Ein Add ist auch bei x86 ein einfaches Pipeline-Add.

Natürlich würde sich CISC nicht als internes Pipeline-Format eignen. PowerPC tut das aber auch nicht. Moderne Prozessoren wie Core 2 versuchen ja sogar selbst bei x86 Befehle wieder zu verschmelzen, damit nur eine Op ausgeführt werden muss in der Pipeline. Das gestaltet sich bei RISC als noch schwieriger.

Es bleibt festzuhalten, dass es heute einfach keinen elementaren Vorteil mehr gibt für RISC. Ich würde sagen, dass es sich ziemlich die Waage hält. CISC hat Vorteile, weil die Instructions kürzer sind und mehr Informationen enthalten, bei RISC ist dafür das Decoding einfacher und man hat keinen Microcode.

Gast

2007-09-05, 16:44:24

Gibt's dafür auch eine Quelle?
auch jon hannibal stokes von arstechnica. deckt sich ja auch mit den binary größen.

Die Micro-Ops von G5 und jedem anderen modernen PPC-Prozessor sind sicher nicht im PowerPC-Format.
die ipos beim g5 sind powerpc format + metadaten für das group tracking. andere ppc prozessoren verwenden gar keine iops.

Viele CISC-Befehle werden über Microcode in kleinere Befehle zerteilt damit CPU sie schnell genug in die Pipelinestages ausführen kann. Das ist kein "Blödsinn".
das hat aber nix mit der länge zu tun, sondern mit der komplexität. weil sie viele informationen enthalten. weil es eigentlich mehrere befehle sind, zu einem zusammengefasst.

Auf die Punkte wo ich gute Argumente hab wird natürlich gar nicht mehr eingegangen. Warum sollte ich mich hier noch rumstreiten? Soll sich doch jeder sein eigenes Bild machen.
wo hast du gute argumente?

Coda

2007-09-05, 16:49:26

auch jon hannibal stokes von arstechnica. deckt sich ja auch mit den binary größen.
Dann braucht man bei PowerPC aber immer noch mehr Befehle, die alle 4 Bytes lang sind um das gleiche auszudrücken.

die ipos beim g5 sind powerpc format + metadaten für das group tracking. andere ppc prozessoren verwenden gar keine iops.
Dann will ich das mal glauben.

das hat aber nix mit der länge zu tun, sondern mit der komplexität. weil sie viele informationen enthalten. weil es eigentlich mehrere befehle sind, zu einem zusammengefasst.
Das habe ich gemeint. Mit "lang" meinte ich, dass sie viele Befehle vereinen.

wo hast du gute argumente?
Dito. Deine "40% Logikanteil" bei heutigen Prozessoren für x86-Kompatibilität sind einfach gelogen. Und schneller ist RISC auch nicht, wie Core 2 sehr eindrucksvoll beweist.

Gast

2007-09-05, 16:55:39

Das hat überhaupt nichts mit RISC und CISC zu tun. Eine RISC-Instruction kann genauso abhängig von einer anderen sein wie eine CISC-Instruction.
und was hat das mit dem thema zu tun?
dann gibt es einen pipeline stall, egal ob echtes risc oder in interne instruktionen übersetztes x86.
dagegen hilft branch prediction und oooe.
Da gibt es überhaupt keinen Unterschied. Moderne x86-Prozessoren haben auch ein Instruction-Window das weitaus größer ist als ein Befehl. Der Decoder von K8 wirft pro Takt mindestens 3 Befehle hinten raus, bei Core 2 Duo ist es noch mehr.
die verwenden intern auch kein CISC, sondern arbeiten intern so wie ein RISC prozessor. damit ein inststruction window größer, als ein befehl möglich ist, tun die das. das ist die antwort auf die frage von other gast.

Und es muss nicht für jeden CISC-Befehl ein Microcode-Programm ausgeführt werden. So ein Unsinn. Ein Add ist auch bei x86 ein einfaches Pipeline-Add. ausnahmen bestätigen die regel.

Natürlich würde sich CISC nicht als internes Pipeline-Format eignen. da gebe ich dir recht
PowerPC tut das aber auch nicht. aber sicher tut es das jeder ppc prozessor verwendet ppc als internes pipeline format
Moderne Prozessoren wie Core 2 versuchen ja sogar selbst bei x86 Befehle wieder zu verschmelzen, damit nur eine Op ausgeführt werden muss in der Pipeline. Das gestaltet sich bei RISC als noch schwieriger. macht der g5 auch. da werden 5 befehle zu einer gruppe verschmolzen.

Gast

2007-09-05, 17:02:45

Und schneller ist RISC auch nicht, wie Core 2 sehr eindrucksvoll beweist.
versuchst du vom thema abzulenken?

Coda

2007-09-05, 17:15:38

und was hat das mit dem thema zu tun?
dann gibt es einen pipeline stall, egal ob echtes risc oder in interne instruktionen übersetztes x86.
dagegen hilft branch prediction und oooe.
Natürlich. Aber wieso sollte man RISC besser parallel ausführen können? Das leuchtet mir nicht ein. Oder meinst du jetzt das "RISC" im Prozessor selber?

die verwenden intern auch kein CISC, sondern arbeiten intern so wie ein RISC prozessor. damit ein inststruction window größer, als ein befehl möglich ist, tun die das. das ist die antwort auf die frage von other gast.
Ack. Ich glaube wir reden ein wenig aneinander vorbei.

aber sicher tut es das jeder ppc prozessor verwendet ppc als internes pipeline format
Uuuh. Damit wäre ich vorsichtig, vor allem kann man das nicht belegen. Vor allem wenn man die Ausführungseinheiten mit einem VLIW ansteuert wird das wohl nicht mehr der Fall sein. Es ist es auch ziemlicher Unsinn die ALU mit einem 4-Byte-Instruction-Format anzusprechen.

Also ne, ich glaube dir da nicht. Ab einem bestimmten Teil der Pipeline ist das sicher kein PPC mehr.

ausnahmen bestätigen die regel.
Das sind aber ziemlich viele Ausnahmen. K8 führt die meisten Befehle im DirectPath aus und bei Core wird es nicht anders sein.

macht der g5 auch. da werden 5 befehle zu einer gruppe verschmolzen.
Jain. Das ist darauf bezogen, dass man z.B. aus Mul und Add ein MADD macht. Soweit ich weiß ist die Core-Architektur da ziemlich alleinstehend.

versuchst du vom thema abzulenken?
Nein, überhaupt nicht. Ich bezweifle nur, dass RISC in der heutigen Zeit noch Vorteile hat. Wenn Intel eine RISC-Architektur hätte und der Rest CISC wäre es wohl andersrum, weil sie einfach viel mehr in Forschung investieren können.

Gast

2007-09-05, 23:01:46

Aber wieso sollte man RISC besser parallel ausführen können? Das leuchtet mir nicht ein. Oder meinst du jetzt das "RISC" im Prozessor selber?
es gibt bei einem RISC prozessor keinen unterschied zwischen ISA und im prozessor selber.

Uuuh. Damit wäre ich vorsichtig, vor allem kann man das nicht belegen. Vor allem wenn man die Ausführungseinheiten mit einem VLIW ansteuert wird das wohl nicht mehr der Fall sein.
wer macht denn das? beim g5 werden die befehle zu gruppen zusammengefasst, damit die steuerlogik nur 1/5 so viele befehle in bearbeitung überwachen muss. ist aber kein vliw.

Es ist es auch ziemlicher Unsinn die ALU mit einem 4-Byte-Instruction-Format anzusprechen.warum nicht?
Also ne, ich glaube dir da nicht. Ab einem bestimmten Teil der Pipeline ist das sicher kein PPC mehr.wieso glaubst du das?

eine RISC ISA ist so aufgebaut, dass die ISA befehle vom kern ausgeführt werden können. befehle bei denen das nicht geht sind in der ISA nicht drin. darum nennt man das reduced.
eine CISC ISA ist so aufgebaut, dass die ISA befehle vom kern nicht direkt ausgeführt werden können. deshalb nennt man sie complex. die sollten einfach für den assembler programmierer sein und eigentlich über microprogramme ausgeführt werden.
heute werden die halt über translation oder microcode umgewandelt und das ergebnis davon dann vom kern so wie risc befehle ausgeführt. deshalb glauben manche leute, ein x86 wäre heute intern risc. das ist aber blödsinn.

Das sind aber ziemlich viele Ausnahmen. K8 führt die meisten Befehle im DirectPath aus und bei Core wird es nicht anders sein.
k8 und core führen keinen einzigen befehl direkt aus. jeder befehl wird erst umgewandelt. die meisten befehle müssen eine simple translation durchlaufen, manche auch die microcode engine. ganz wenige befehle werden dabei in nur einen befehl im internen instruktionsformat umgewandelt. add register plus immidiate ist so eine ausnahme, ist kein load oder store drin. die meisten in 2 oder mehr. einen load, eine berechnung, einen store.

Jain. Das ist darauf bezogen, dass man z.B. aus Mul und Add ein MADD macht. Soweit ich weiß ist die Core-Architektur da ziemlich alleinstehend. du meinstest macro ops fusion, nicht micro ops fusion.
multipy-add ist beim ppc sowieso schon im befehlssatz drin. mit vier operanden.

Coda

2007-09-05, 23:22:12

es gibt bei einem RISC prozessor keinen unterschied zwischen ISA und im prozessor selber.
Das sagst du. Ich glaube aber sehr wohl, dass die µOps auch bei einem PowerPC anders aussehen, weil die Technik fortschreitet und man immer mehr abstrahieren muss mit OOOE usw.

Dafür habe ich sogar eine schöne Quelle: www.maths.mq.edu.au/~steffen/talks/ppc970_print.pdf

Decode into internal operations
- most PPC instr translate into one IOP
- some rarer PPC instr are “cracked” into 2 IOP
- a few complex instr translate into several IOPs
So what?

wer macht denn das? beim g5 werden die befehle zu gruppen zusammengefasst, damit die steuerlogik nur 1/5 so viele befehle in bearbeitung überwachen muss. ist aber kein vliw.
Intel macht das. Core 2 fügt bevor er Befehle in die Pipeline übergibt diese schon zusammen. Also aus 2 mach 1. Nicht Gruppieren sondern wirklich Reduzieren.

k8 und core führen keinen einzigen befehl direkt aus. jeder befehl wird erst umgewandelt. die meisten befehle müssen eine simple translation durchlaufen, manche auch die microcode engine. ganz wenige befehle werden dabei in nur einen befehl im internen instruktionsformat umgewandelt. add register plus immidiate ist so eine ausnahme, ist kein load oder store drin. die meisten in 2 oder mehr. einen load, eine berechnung, einen store.
Natürlich. Aber "direkte Ausführung" gibt es auch bei PowerPC nicht mehr, deshalb ist ein Add auf einem G5 genauso "direkt" wie auf einem K8. Da kannst du mir erzählen was du willst.

du meinstest macro ops fusion, nicht micro ops fusion.
multipy-add ist beim ppc sowieso schon im befehlssatz drin. mit vier operanden.
Das war ein Beispiel.

RISC ist nicht das was es einmal war, genausowenig wie CISC das ist was es noch einmal war. Moderne Hochleistungs-Microprozessoren abstrahieren alle den Befehlssatz, deshalb ist der Streit um den Befehlssatz auf diesem Level völliger Unsinn.

Gast

2007-09-06, 01:28:53

hab mich übrigens vertan. nicht die instruktionslänge von durchschnittlichen code, sondern die durchschnittlichen instruktionslänge ist 3,5 byte. instruktionslänge von durchschnittlichen code ist größer, hier z.b. 4,5 byte http://smallcode.weblogs.us/2006/04/22/x86-machine-code-statistics/
wird bei neueren programmen mit sse befehlen wohl noch länger sein.

mov ist der am meisten gebrauchte befehl, 35%. liegt wohl daran, dass es beim x86 nur 2 operanden befehle gibt und die daten in einem register immer überschrieben werden. und ausserdem viel zu wenig register.
die notwendigkeit zwischen jeden zweiten befehl einen mov befehl dazwischenzuschieben wird bei RISC prozessoren idr wegfallen.

Dafür habe ich sogar eine schöne Quelle: www.maths.mq.edu.au/~steffen/talks/ppc970_print.pdf

So what?
translate ist das falsche wort. das ist ein missverständlich. die iops beim g5 sind ppc befehle + metadaten für das tracking.
jon hannibal stokes, von dem die grafiken und infos in dem pdf stammen, hat das inzwischen richtig gestellt.

Intel macht das. Core 2 fügt bevor er Befehle in die Pipeline übergibt diese schon zusammen. Also aus 2 mach 1. Nicht Gruppieren sondern wirklich Reduzieren.
ja. macro ops fusion. das passiert vor dem translate.
im backend wird gruppiert. micro ops fusion.

Natürlich. Aber "direkte Ausführung" gibt es auch bei PowerPC nicht mehr, deshalb ist ein Add auf einem G5 genauso "direkt" wie auf einem K8. Da kannst du mir erzählen was du willst. nein.
translate ist das falsche wort beim G5. aber das richtige wort beim k8. denn beim g5 werden die befehle nicht in etwas ganz anderes übersetzt, sondern nur mit zusätzlichen daten ergänzt.
ausserdem ist das kein muss. beim cisc x86 schon. ein x86 befehl kann nicht so verarbeitet werden, wie ein ppc befehl im g5.

RISC ist nicht das was es einmal war, genausowenig wie CISC das ist was es noch einmal war. Moderne Hochleistungs-Microprozessoren abstrahieren alle den Befehlssatz, deshalb ist der Streit um den Befehlssatz auf diesem Level völliger Unsinn.
nein tun sie nicht. das tun nur die x86 prozessoren weil x86 ist CISC.

Coda

2007-09-06, 01:39:27

Es ist eigentlich auch völlig egal, was das interne Format ist. Der Punkt ist doch, dass auch G5 Instructions decodiert und sie sogar bei komplexeren Formen in mehrere Befehle umwandelt wie ein x86 auch.

Ich sehe einfach keine so großen Unterschiede mehr wie du tust. Es sind weder 40% Logikanteil bei einem modernen x86 die für die Kompatibilität zuständig sind, noch gibt es länger eine ursprüngliche RISC-Pipeline.

Was willst du eigentlich ausdrücken?

Die Daten im Excel-File von deinem Link sagen übrigens, dass es genau 3,26 Bytes im Durchschnitt sind. Immer noch 20% besser als mit PPC. Weit weg von deinen angeblichen 1-4%. Allerdings ist der dabei verwendete Compiler auch grottenschlecht und uralt. Ich weiß nicht inwiefern sich das auf das Ergebnis auswirkt.

Coda

2007-09-06, 02:22:58

Ich habe jetzt mal selber einen Versuch gemacht hiermit: http://smallcode.weblogs.us/2006/05/18/corrections-in-the-cheat-sheet-and-source-code-for-machine-code-statistics/

Die Quake-Wars-Beta-Exe hat eine durchschnittliche Instructionlänge von 2,97 Bytes und davon sind nur 25% MOV. Bei einer eigenen kleine GUI komme ich sogar nur auf 2,8 Bytes. Lag ich mit meinen 75% wohl doch nicht so ganz falsch.

Aber jetzt ist auch gut hier, ich glaube nicht, dass wir noch eine gemeinsame Basis finden werden was dieses Thema angeht. Die Wahrheit liegt halt immer irgendwo dazwischen.

Gast

2007-09-06, 11:43:08

Es ist eigentlich auch völlig egal, was das interne Format ist.
da hast du recht. das interne format ist egal. was zählt ist die ISA. und die ist beim k8 oder core 2 die gleiche, wie beim 8086. eine CISC ISA. darum x86 auch kein echter RISC prozessor und auch kein halber RISC prozessor.

Der Punkt ist doch, dass auch G5 Instructions decodiert
du hast wohl immer noch nicht kapiert, dass decode nicht translate ist.
vielleicht hast du auch gar nicht verstanden, wie RISC befehle eigentlich aufgebaut sind.
ich erklärs dir mal mit powerpc befehlen. befehle von anderen RISC prozessoren sehen genauso aus. im vergleich mit x86 befehlen.

beim ppc befehl ist bit 0 bis 5 der opcode, da steht drin, was gemacht wird.
dann kommen 5 bit für das zielregister. 5 bit, macht 0-31 für 32 register, eindeutiger gehts nicht.
danach 5 bit für das erste quellregister etc.
wenn ein befehl ein immidiate enthält, ist es ein anderer befehl. z.b. addi statt add. ein immidiate ist immer ein doubble und in bit 16 - 31.
warum meinst du soll man das umwandeln? da stehen die informationen drin, die der prozessor kern braucht. nicht mehr und nicht weniger.

beim x86 sind die informationen nicht eindeutig, sie sind kodiert und voneinander abhängig. der opcode ist mal ein byte, mal zwei oder drei bytes. manchmal noch ein prefix vor dem opcode. d.h. alles, was dahinter steht verschiebt sich.
der gleiche befehl kann an der gleichen stelle registeradressen enthalten oder speicheradressen und/oder eine 8, 16 oder 32 bit immidiate. was da an der stelle steht, kann nur am r/m code erkannt werden.
damit der kern das verarbeiten kann, muss das in so ein format übersetzt werden, wie beim RISC prozessor. ein eindeutiges format, wo eindeutige informationen an eindeutigen stellen stehen. sonst kann die pipeline im kern nicht damit arbeiten.
darum heisst es, intern würden RISC befehle verwendet.

und sie sogar bei komplexeren Formen in mehrere Befehle umwandelt wie ein x86 auch.
die werden nicht umgewandelt, die werden aufgeteilt. z.b. ein fmadd, flot multiply-add mit vier operanden in zwei abhängige befehle. ein multiply und ein add mit jeweils drei operanden. zwei powerpc befehle. dann kann man die fpu einfacher aufbauen, weil man den einen befehl nicht implementieren muss.

beim internen format wird nur eine seriennnummer drangehängt und vielleicht eine rename register adresse, falls das architektonische zielregister gerade belegt ist. das sind aber trotzdem noch pwerpc-befehle. da wird nichts umgewandelt.

jeder prozessor decodiert instructions. decode heißt beim RISC nix weiter, als lesen des opcodes und weitergeben an die richtige einheit. nen branch befehl und ein laod oder store müssen halt anders bearbeitet werden.
beim CISC bedeutet decode herausfinden, wie lang der opcode ist, wie lang der ganze befehl. danach kommt das translate zu mehreren internen befehlen. wenn sie verarbeitet werden sollen, werden die auch noch mal decodiert.

Ich sehe einfach keine so großen Unterschiede mehr wie du tust. Es sind weder 40% Logikanteil bei einem modernen x86 die für die Kompatibilität zuständig sind, noch gibt es länger eine ursprüngliche RISC-Pipeline.du glaubst es sind keine 40% logikanteil. und natürlich gibt es noch ne klassische risc pipeline. die vier schritte sind nur zum teil in unterschritte aufgeteilt.
beim k8 und core gibt es so eine pipeline auch. aber nach dem translalte oder microcode programm.

Was willst du eigentlich ausdrücken?
was meinst du, was ich ausdrücken will? tatsachen. nix weiter.

Die Daten im Excel-File von deinem Link sagen übrigens, dass es genau 3,26 Bytes im Durchschnitt sind. Immer noch 20% besser als mit PPC. Weit weg von deinen angeblichen 1-4%. Allerdings ist der dabei verwendete Compiler auch grottenschlecht und uralt. Ich weiß nicht inwiefern sich das auf das Ergebnis auswirkt.
in der tabelle wird der durchschnitt aller befehle ausgerechnet. der ist 3,26. wenn du den durchschnitt der verwendeten befehle ausrechnest, kommst du auf 4,4.
mit neueren code und nem neueren compiler wird das noch mehr, weil sse befehle im durchschnitt länger sind. da sind auch welche dabei, die sind länger als 11 byte.

die 1-4% sind gemessen. aus programmen, die es für x86 und ppc gibt. sind auch welche dabei, bei denen es minus 1-2 % sind.
außerdem ist das bei heutigen festplatten und speicher größen sowieso egal.

Coda

2007-09-06, 16:56:50

Gast

2007-09-06, 19:46:18

Ich hab sehr gut verstanden was du meinst, nur sehe ich es eben etwas anders. Ob das ganze jetzt "translate" oder "decode" ist ist für mich ziemlich irrelevant. Zumal die Pipeline-Stage im G5 auch "decode" heißen und im Prinzip das gleiche machen, nur dabei etwas weniger Arbeit haben.
du hast es wirklich nicht kapiert.
nee, die machen nicht im prinzip das gleiche. decode ist was anderes als translate. beim x86 gibt es auch decode. zwei mal einmal vor dem translate und einmal nach dem translate.
decode ist nicht umwandeln, decode ist in der RISC pipeline erkennen um was es sich handelt.

Zudem habe ich nirgends behauptet dass ein x86-Prozessor RISC ist. Ich behaupte nur dass das heute scheiß egal ist.
du behauptest, das es kein richtiges RISC mehr gibt, das ist falsch.
ARM, SPARC, MIPS, PoewrPC, alles richtiges RISC.

dass es scheißegal ist ist auch falsch.

und dass der code komprimiert wird ist auch falsch.

ich habe gerade mal die binary von textedit durch einen dissassembler geschickt. selber code, selber compiler. die x86 binary ist 5% größer, als die ppc binary. die zahl der codezeilen, die der dissassambler ausgibt ist 3% größer. macht eine durchschnittliche code länge von 3,9 byte. einfacher dreisatz.

Es ist ja nicht so, dass ich mich nicht mit den Interna von Microprozessoren auskennen würde. Du brauchst mich nicht immer für blöd hinstellen.
dann benimm dich nicht so. womit du dich auskennst, kann ich nur daran erkennen, was du schreibst. und da ist von auskennen mit interna von microprozessoren nix zu sehen.

Und wo stehen die "verwendeten Befehle"? In dem Excel-File in dem alle Daten stehen ist davon nirgends die Rede.ne, steht da nirgens. es gibt eine spalte, wo die befehle zusammengefasst sind davon musst du selber den durchschnitt rechnen.

Man sieht doch eindeutig am K8-Die-Shot das es nicht so ist. Das sind nichtmal 20%. Wie oft noch? Oder willst du es dir einfach aus Prinzip nicht anschauen? Es wird dort maximal die doppelte Logikmenge eines G5 für Fetch/Decode/Dispatch verwendet. Fakten.und wenns nur 20% sind und wenns nur die doppelte logikmenge ist, die du da siehst, dann ist es immer noch doppelt so viel und nicht nichts.

x86 hat keinen nachteil ist also auch falsch.

Coda

2007-09-06, 21:10:50

du hast es wirklich nicht kapiert.
Ich hab es sehr gut kapiert. Ich weiß ganz genau was G5 da macht und was der x86 mehr macht. Der x86 braucht im Endeffekt dafür aber nur mehr Logik, aber nicht mehr Zeit. Und das bisschen mehr ist völlig wurscht bei Prozessoren die bald ~100 Mio. Logiktransistoren haben.

Ich weiß was Instruction Windows, Out-Of-Order-Exection, ein massiv paralleler Predecoder, Microcode, Registerfile usw. ist. Ich hab auch schon selber einen kleinen Prozessor mit Pipeline in VHDL auf einem FPGA implementiert für ein Uniprojekt. Mach dich doch nicht lächerlich.

du behauptest, das es kein richtiges RISC mehr gibt, das ist falsch. ARM, SPARC, MIPS, PoewrPC, alles richtiges RISC.
Das ist kein RISC mehr, weil der Befehlssatz nicht mehr wirklich reduced ist. Da gibt's doch schon für jeden Mist auch Spezialinstructions. Das ist nicht mehr die ursprüngliche Idee davon.

Was erhalten geblieben ist sind die vielen Register und die fixed length encoding der Instructions, aber kein reduzierter Befehlssatz mehr.

und dass der code komprimiert wird ist auch falsch.
Ist es nicht. Das hat übrigens auch Linus Torvalds mal gesagt.
http://www.ussg.iu.edu/hypermail/linux/kernel/0302.2/1909.html

And the baroque instruction encoding on the x86 is actually a _good_
thing: it's a rather dense encoding, which means that you win on icache.
It's a bit hard to decode, but who cares? Existing chips do well at
decoding, and thanks to the icache win they tend to perform better - and
they load faster too (which is important - you can make your CPU have
big caches, but _nothing_ saves you from the cold-cache costs).
Aber der hat ja sicher auch keine Ahnung.

ich habe gerade mal die binary von textedit durch einen dissassembler geschickt. selber code, selber compiler. die x86 binary ist 5% größer, als die ppc binary. die zahl der codezeilen, die der dissassambler ausgibt ist 3% größer. macht eine durchschnittliche code länge von 3,9 byte. einfacher dreisatz.
Das siehst du aber nicht am Binary, weil auch Padding usw. relevant ist. Eine Executable steigt immer um z.B. 32 KiB in der Größe wenn man es kompiliert, nicht um kleine Schritte. Wenn man da wirklich was rauslesen will muss man disassemblieren.

dann benimm dich nicht so. womit du dich auskennst, kann ich nur daran erkennen, was du schreibst. und da ist von auskennen mit interna von microprozessoren nix zu sehen.
Blafasel.

ne, steht da nirgens. es gibt eine spalte, wo die befehle zusammengefasst sind davon musst du selber den durchschnitt rechnen.
Welche Zusammenfassung? Ich hab den es doch selber ausprobiert. Das Programm nimmt alle Instructions eines Disassemblat und zählt die Längen der Befehle. Es wird nichts ausgeführt, also kann es auch überhaupt nicht bestimmen welche Befehle wirklich verwendet werden. Deshalb ist deine komische 4,5 einfach nur falsch.

Und z.B. im Quake-Wars-x86-Binary ist die durchschnittliche Länge der Instructions <3 Bytes. Fakten.

und wenns nur 20% sind und wenns nur die doppelte logikmenge ist, die du da siehst, dann ist es immer noch doppelt so viel und nicht nichts.
Und das ist verdammt wenig wenn man es auf die Logik umlegt, die heute für Ausführung, OOOE, Caches, usw. aufgewendet wird. Es spielt einfach keine Rolle mehr.

Gast

2007-09-06, 23:10:38

Lügner!!!

Gast

2007-09-06, 23:24:50

@Gast über mir

Ja das hat Coda schon versucht mehr oder weniger zu klären. Ich würd aber eher sagen, daß es eher die Unwissenheit des Gastes ist. Bzw. nun eher war. Brauchst dich nicht gleich so aufzuregen.
Der Gast hat es halt nur gut gemeint. Er wußte es bis jetzt nicht besser. Nun weiß er es.

Gast

2007-09-07, 19:02:49

Sorry Offtopic

Ich hab den Thread mal ein bisschen studiert. Naja ich kam zu dem Endschluß das ich Alpha Tier und Stevan V, mit ihrer unangenhemen Art, früher im Kindergarten mit Sand beworfen hätte.

Da mußte ich jetzt einfach mal loswerden. Wenn die im Rl so mit ihren Mitmenschen umgehen sind sie sehr schnell alleine.

Gruß

ANDERER Gast

2007-09-07, 19:05:48

Lügner!!!

So etwas muss ja wirklich nicht sein.

Gast

2007-09-07, 19:59:06

Gut,die Amiga Experten habens nie hinbekommen MemoryProtection einzuprogrammieren,aber das zeigt ja schon die deutlichen Architekturunterschiede. Ich bezweifle jedenfalls stark,dass ein paar Hundert Amiga Programmierer es nicht schaffen einen Speicherschutz zu integrieren,wenn es einfach umsetzbar wäre.

Was ist denn das für eine banale Argumentation? Dass ein OS aus den 80ern nicht den selben Funktionsumfang eines modernen OS hat, sollte doch wohl klar sein oder (wenn man mal von einigen Ausnahmen absieht)? MacOS bekam auch erst mit OSX Speicherschutz. Die 9xer Konsumerversionen von Windows haben auch kein Speicherschutz gehabt. Eben weil das im Konsumerbereich Anfangs nicht so wichtig war. Und der Amiga war ja auch hauptsächlich nur ein Heimcomputer. Und dass er besseres Scheduling hatte, ist ja mal der größte Rotz, den man überhaupt behaupten kann. Auf einem heutigen Rechner laufen schon mal um mind. den Faktor 500 mehr Hintergrundprozesse als auf ner Amiga Mühle.

Gast

2007-09-07, 20:10:47

Und dass er besseres Scheduling hatte, ist ja mal der größte Rotz, den man überhaupt behaupten kann. Auf einem heutigen Rechner laufen schon mal um mind. den Faktor 500 mehr Hintergrundprozesse als auf ner Amiga Mühle.Was is das denn für eine banale Argumentation? Heutige Rechner snd auch um Faktor 1000 schneller. Wie kann man dabei noch die Güte des Schedulings mit dem von AmigaOS vergleichen?

Ich meine wird schon stimmen daß Amiga ablost, aber dich nicht wegen den 500 mal ;) mehr Prozessen die unter Vista laufen. Kappes.

L.ED

2007-09-07, 20:48:24

^^
Guter Einwand, zudem wenn man schon (heute!) Vergleicht dann bitte Amiga OS in der Version 3.9 und unter Emulierten Bedingungen (z.b. WinUAE!), selbst wenn auch das noch leicht unfair gegenüber einem BS (wie Windows), was die voll native Power der jeweilig zu Verfügung stehenden Ressourcen Nutzen kann.

So kommen aber einer realistisch verwertbaren diesbezüglichen Vergleichbarkeit u.a. im Multitasking erheblich näher.

Und wer ein gut Aufgezogenes Amiga OS 3.9 unter Emulierten Bedingungen von heute Erlebt (was moderne CPU, GFX, RAM & Peripherie Power unterm Röckchen miteinschließt! ;) ), wird sehr erstaunt sein :eek: und womöglich hier und da eine neue Definition und Begrifflichkeit für Reaktionszeit in seinen Verständnis einfügen/Suchen wollen!

Es mag zwar an vielen Fronten unter AmigaOS Ermangeln (ganz sicher sogar/ist leider so :frown: ), aber in den Dingen die man damit noch machen kann, fegt das Ding unter Emulation ab wie …:smile: ... da sieht in jeden Fall ein jegliches Windows nur noch die Rücklichter.

Meine Amiga OS 3.9 Arbeitsumgebung läuft Beispielsweise in 1600x1200, recht schicken modernen Theme Style (wobei sowas ja auch Geschmackssache), zuzüglich PNG Icon System.

No.3

2007-09-07, 20:48:45

Auf einem heutigen Rechner laufen schon mal um mind. den Faktor 500 mehr Hintergrundprozesse als auf ner Amiga Mühle.

looooooooooooool - wenn man keine Ahnung hat...

hab grad mal UAE gebootet, unter meinem OS3.5 laufen 27 Prozesse nach dem Booten...

Edit: aufm XP zeigt der Taskmanager 28 an ;)

(del)

2007-09-07, 21:03:53

30 Prozesse hab ich unter XP gerade jetzt auch. Dafür aber 333 Threads und 5766 Handles :D

edit:
@L.ED
Du lernst halt nichts aus den Vista-Threads hier. Heutzutage ist nicht Schnelligkeit gefragt, sondern eine gelassene Geschmeidigkeit. Sonst verfällt der User ja womöglich in Bedienhektik, weil er mit den aufpoppenden Fenstern mithalten will. Und dann droht womöglich Herzinfarkt oder so :| Die Zeiten ändern sich. Die Gesellschaft altert und auch die Betriebssysteme werden seniorengerechter :uup: Man kann die Leute nicht jedesmal mit einem plötzlich auftauchendeb Fenster fast zu tode erschrecken. Man muß es geschmeidig aufgehen lassen.

Ich muß aber auch sagen, daß das hier ziemlich OT geworden ist...

del_4901

2007-09-07, 21:20:09

Es mag zwar an vielen Fronten unter AmigaOS Ermangeln (ganz sicher sogar/ist leider so :frown: ), aber in den Dingen die man damit noch machen kann, fegt das Ding unter Emulation ab wie …:smile: ... da sieht in jeden Fall ein jegliches Windows nur noch die Rücklichter.

[SUP]Meine Amiga OS 3.9 Arbeitsumgebung läuft Beispielsweise in 1600x1200, recht schicken modernen Theme Style (wobei sowas ja auch Geschmackssache), zuzüglich PNG Icon System.
"deinstallier" einfach deinen "Storm-Clienten"

PS: mein Windows Vista x64 arbeitet unter 1920x1200 ... und ich hab keinerlei Probleme mit Reaktionszeiten ... ok, ich hab ja "Storm" auch erst gar nicht installiert.

L.ED

2007-09-07, 21:23:56

Yo (sowohl als auch )Yo :ugly:
Unter nem schlanken OS mit schlanken Programmen, sind speziellere Caching maßnahmen (ala Vista :ucoffee:) gar nicht nötig.

Ein Amiga Art Effect 4.0, startet hier innerhalb von einer Sekunde, ebenso der Raytracer Maxon Cinema 4D (4.1), bei weniger ausladende Programmen da ist dann selbst die Begrifflichkeit Sekunde schon derbe übertrieben.

Ja ja moderne Applikationen können ja auch viel mehr, sind umfänglicher etc. pp. Aber zum einen, kann das Amiga OS (unter Emulation) nebst seiner Programme nur auf ein Bruchteil der jeweiligen Hardware mäßig vorhandenden nativ Power des Host Systems zurückgreifen (bedingt eben durch den nicht gerade minderen Emulations verschnitt/Overhead)! Und zum anderen sind oftmals diese ganzen Extras (Berge ^^), gar nicht nötig! Je nach Anwenderprofil dann nur überflüssiger Ballast, denn man besser Modular/Optional gelöst hätte, als sie jedem und bei jeden Programmstart einem ungefragt halt immer mit aufzuflanschen (da muss man sich auch nicht wundern wenn der Ram Verbrauch und Startzeiten jeweils über Proportional nach oben ballern)!

PS: @AlphaTier (:ulol: der war gut ;) )

del_4901

2007-09-07, 21:33:49

Das ist mein aktueller Ressourcenverbrauch.

http://img509.imageshack.us/img509/3841/tmzq0.jpg (http://imageshack.us)
http://img509.imageshack.us/img509/3841/tmzq0.efe6ccd7da.jpg (http://g.imageshack.us/g.php?h=509&i=tmzq0.jpg)

Visual Studio (hab grad kein dickeres Programm wie z.B: Maya hier) startet in 2-3 sek. Der Explorer ist sofort da. PowerDVD braucht knapp 2sek.

Was habt ihr nur für Probleme mit eurem Windows ... ich kann das echt nicht nachvollziehen.

Gast

2007-09-07, 21:38:35

Ja... Mal ne halbe Lanze für Windows. Die Möglichkeiten sind alle gegeben. Das Featureset mehr als ausreichend. Das "Problem" ist eher, daß die "durchschnittliche Programmierkultur" auf dem Amiga wesentlich höher war. Zum teil sehr schlecht, zum Teil noch besser als die durschschnittliche. Weil man eben für halbwegs ernstere Sachen eben nicht unendliche Resourcen hatte.

Unter Windows halte ich diese "durchschnittliche Programmierkultur" für sehr schlecht. Da kann Win nichts für. Man vergleicht wenn denn aber eben das gesamte System und nicht nur Teile davon. Eben.

BH

p.s.:Gut gemerkt Alpha. Das geht aber lustiger ;)

L.ED

2007-09-07, 21:45:36

Das ist (war von mir gar nicht mal so) damit gemeint, die Geschwindigkeit ist durchaus OK (akzeptabel = kann man mit leben, sich arrangieren), zumindest unter XP 32Bit & 64Bit. (meistens)

Es geht dabei vielmehr dann auch um die gefühlte Geschwindigkeit/Reaktionszeit, wenn ich auf die Schnellstartleiste klicke und kaum das man es tat ohne irgendwie Verzögerung auch nur zu Merken und das Programm ist (quasi sofort) schon da. :eek: Dann ist das schon so ein Woow Empfinden (vielleicht ein wenig Dekadent aber eben halt in dem Momenten ein leicht anderes Empfinden an gefühltem Workflow).

Vista64Bit musste unterdes schon einmal testen, zum damaligen Zeitpunkt hatte noch eine nivida GFX im System, aber die Treiber Situation + der Vista64Bit Zustand, war eben halt noch nicht soweit das ich es hätte Empfehlen wollen/können als Verkaufs OS für die Rechner (erheblicher Support aufwand wären vorprogrammiert und Inklusive gewesen). :cool:

Wie es sich Aktuell verhält weiß ich nicht und ehrlich gesagt Interessiert es mich (privat dann) auch nicht mehr (bis auf weiteres), habe noch die Kombination NForce 3, nen X2 und mittlerweile eine ATI Grafikkarte und da gibt es ja gewisse Unverträglichkeiten. ;) :|

PS: @Gast ... möchte ich dann gleich mal mit Unterschreiben wollen :wink:

No.3

2007-09-07, 21:55:01

Was habt ihr nur für Probleme mit eurem Windows ... ich kann das echt nicht nachvollziehen.

hehe, wenn man Deine Hardware so ansieht :biggrin:

Unter Windows halte ich diese "durchschnittliche Programmierkultur" für sehr schlecht. Da kann Win nichts für. Man vergleicht wenn denn aber eben das gesamte System und nicht nur Teile davon. Eben.

nun, insofern schon, weil man diese schlechte Kultur auch im Windows selbst findet.

Beim Amiga OS 1.x war das so gesehen auch so. Das OS an sich war nicht 100% "sauber" und die Programme auch nicht. Mit OS 2 kam der große Schnitt, das OS hat mit einigem Alten gebrochen und auch die Anwendungsentwickler merkten dann, dass sie "sauberer" entwickeln müssen.

(und unter Windows wirds immer mehr Pfusch anstatt weniger ;) )

Gast

2007-09-07, 21:56:29

30 Prozesse hab ich unter XP gerade jetzt auch. Dafür aber 333 Threads und 5766 Handles :D

Ja, genau. Da habe ich mich natürlich verschrieben. Ich meinte natürlich auch Threads.

del_4901

2007-09-07, 22:02:57

hehe, wenn man Deine Hardware so ansieht :biggrin:

An den 4 Kernen liegt es nicht, kauft euch halt Speicher, der war grad günstig, da muss man zuschlagen! Mit 1GB läuft auch XP nicht sonderlich schön, besonders wenn man von einem Groß-Verbraucher(z.B ein Spiel) zurück zu Win switched. Jetzt nachdem ich von 1 auf 4 GB gewechselt habe läuft alles butterweich.

Gast

2007-09-07, 22:04:07

(und unter Windows wirds immer mehr Pfusch anstatt weniger ;) )

Ahja, kannst du auch mal mit Fakten kommen oder immer nur mit so bildlichen Blafasel wie sauber oder unsauber? Du hast doch nicht mal Ahnung gehabt, was Speicherschutz ist, das hast du hier im Thread ja prima bewiesen. Und willst jetzt irgendwas von Architekturen blafaseln, zum totlachen.

No.3

2007-09-07, 22:05:23

Ja, genau. Da habe ich mich natürlich verschrieben. Ich meinte natürlich auch Threads.

hm, gut, ich frag mal so rum: definiere Prozesse, Threads und Handles

An den 4 Kernen liegt es nicht, kauft euch halt Speicher, der war grad günstig, da muss man zuschlagen!...

nun, die 4 Kerne helfen beim Multitasken dann schon

del_4901

2007-09-07, 22:06:54

(und unter Windows wirds immer mehr Pfusch anstatt weniger ;) )
BTW: Das muss ich korrigieren, das stimmt so nicht. Mit .net etc. wird die Programmwelt echt besser. MS macht auch bedeutend mehr Schulungen als vorher. Insgesammt wird sich das bessern.

No.3

2007-09-07, 22:06:58

Ahja, kannst du auch mal mit Fakten kommen oder immer nur mit so bildlichen Blafasel wie sauber oder unsauber? Du hast doch nicht mal Ahnung gehabt, was Speicherschutz ist, das hast du hier im Thread ja prima bewiesen. Und willst jetzt irgendwas von Architekturen blafaseln, zum totlachen.

lol, wer hat hier denn mit Programmkultur angefangen

ansonsten, weiss ich über die Windows Architektur gewiss mehr als der Rest hier über die Amiga Architektur ;)

No.3

2007-09-07, 22:10:15

BTW: Das muss ich korrigieren, das stimmt so nicht. Mit .net etc. wird die Programmwelt echt besser. MS macht auch bedeutend mehr Schulungen als vorher. Insgesammt wird sich das bessern.

nun, ich weiss ja nicht was Ihr unter Programmkultur versteht. Zumindest für mich gehört da z.B. eine schlüssige, einheitlich GUI dazu und z.B. wenn ich in Programm 1 cut-copy-paste mache, sollte man meinen, dass Programm 2 bei cut-copy-paste das Gleiche macht. Aber Microsoft brint das sogar hin, dass 1 und 2 das nicht gleich machen.

del_4901

2007-09-07, 22:12:09

hm, gut, ich frag mal so rum: definiere Prozesse, Threads und Handles
Omg, ein Handle ist ein Verweiß auf ein Objekt. (z.B ein Index oder eine Adresse)
Ein ein Prozess ist ein laufendes <Programm> mit eigenem Adressraum.
Ein Thread ist ein leichtgewichtiger Prozess, welcher sich seinen Adressraum mit anderen Threads teilen kann.
Jeder Thread hat genau einen Prozess, ein Prozess kann mehrere Threads haben.

nun, die 4 Kerne helfen beim Multitasken dann schon
Nee, das war mit 2 Kernen auch schon so. Die 4 kerne brauch ich für was Anderes.

Gast

2007-09-07, 22:12:17

hm, gut, ich frag mal so rum: definiere Prozesse, Threads und Handles

ganz vereinfacht ausgedrückt:

Handles = Referenzen auf Kernel Objekte
Prozess = Struktur mit seperaten Adressraum, wo alle DLL's zum Programm reingeladen werden
Thread = Struktur mit gespeicherten Prozessor-Registerwerten, greift auf den Adressraum vom Prozess zu (ein Prozess muss mind. ein Thread haben) und ist für die Ausführung von Code verantwortlich

Da unter Windows keine Prozesse gescheduled werden, sondern nur Threads, ist natürlich die Anzahl an Threads relevant.

del_4901

2007-09-07, 22:13:38

nun, ich weiss ja nicht was Ihr unter Programmkultur versteht. Zumindest für mich gehört da z.B. eine schlüssige, einheitlich GUI dazu und z.B. wenn ich in Programm 1 cut-copy-paste mache, sollte man meinen, dass Programm 2 bei cut-copy-paste das Gleiche macht. Aber Microsoft brint das sogar hin, dass 1 und 2 das nicht gleich machen.
Das liegt am Programm und nicht an Windows. ... dazu müsste man wissen wie das funktioniert, aber dazu habe ich grad keine Zeit das für nen Dau zu erläutern.

No.3

2007-09-07, 22:23:51

Omg, ein Handle ist ein Verweiß auf ein Objekt. (z.B ein Index oder eine Adresse)
Ein ein Prozess ist ein laufendes <Programm> mit eigenem Adressraum.
Ein Thread ist ein leichtgewichtiger Prozess, welcher sich seinen Adressraum mit anderen Threads teilen kann.
Jeder Thread hat genau einen Prozess, ein Prozess kann mehrere Threads haben.

eben, wenn man es so rechnet, kämen beim Amiga zu den 28 Prozessen auch noch Dutzende und Hunderte Handles und Threads hinzu (nennt sich halt anders). D.h. direkt betrachtet ist eine Vergleichbarkeit also schwer. Man müsste daher eher so unterscheiden mit der Fragestellung, wer braucht wann wie oft wieviel Leistung von der CPU.

Nee, das war mit 2 Kernen auch schon so. Die 4 kerne brauch ich für was Anderes.

ich hab ja net gesagt, dass es mit 2 Kernen nicht auch schon so war

Das liegt am Programm und nicht an Windows. ...

ist der Windows Explorer Windows oder ein Programm ?

dazu müsste man wissen wie das funktioniert,

wie was funktioniert? copy paste?

aber dazu habe ich grad keine Zeit das für nen Dau zu erläutern.

jou, also, DAU, ich machs Dir einfach: vergleich einfach mal die Funktionsweise von Copy-Cut-Paste in Word und Excel...

zum Glück macht es die Open Office anders d.h. immer einheitlich, einfach mal vergleichen

del_4901

2007-09-07, 22:25:47

eben, wenn man es so rechnet, kämen beim Amiga zu den 28 Prozessen auch noch Dutzende und Hunderte Handles und Threads hinzu (nennt sich halt anders).
Das nennt sich auch beim Amiga nicht anders, dafür lege ich die Hand ins Feuer.

No.3

2007-09-07, 22:35:55

Das nennt sich auch beim Amiga nicht anders, dafür lege ich die Hand ins Feuer.

wenn Du Dich da mal nicht verbrennst.

Bei den Prozessen müsste man die Tasks (quasi ein Prozess mit beschränkten Rechten) extra aufführen. Man müsste die Ports noch dazu rechnen, ggf auch die Libraries, auf jeden Fall die Resources und Semaphores und vielleicht auch die Devices. Die Interrupts kann man weglassen, die Residents gehören hingegen wieder dazu.

und was hat Dein copy-cut-paste Word-Excel-OOo Vergleich für nen Ergebnis?

del_4901

2007-09-07, 22:40:16

wenn Du Dich da mal nicht verbrennst.

Bei den Prozessen müsste man die Tasks (quasi ein Prozess mit beschränkten Rechten) extra aufführen. Man müsste die Ports noch dazu rechnen, ggf auch die Libraries, auf jeden Fall die Resources und Semaphores und vielleicht auch die Devices. Die Interrupts kann man weglassen, die Residents gehören hingegen wieder dazu.
Alter... jetzt hast du dich ganz disquallifiziert. Das ist ja weniger als Halbwissen. Du kannst dich da nur rausreiten indem du in eigenen, einfachen Worten klarstellst, was hinter den Buzzworten steht.

und was hat Dein copy-cut-paste Word-Excel-OOo Vergleich für nen Ergebnis?
Ich hab kein Word.

No.3

2007-09-07, 22:49:35

Alter... jetzt hast du dich ganz disquallifiziert. Das ist ja weniger als Halbwissen. Du kannst dich da nur rausreiten indem du in eigenen, einfachen Worten klarstellst, was hinter den Buzzworten steht.

LOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOL

Omg, ein Handle ist ein Verweiß auf ein Objekt. (z.B ein Index oder eine Adresse)....

ich bin also blöd und ein DAU weil ich Nachfrage was Du unter Handles etc verstehst

nun das ganze mal umgekehrt, dann bin ich wieder blöd, weil ich "Buzzworte" liefere - die nebenbei jedem Amiga Progger ein Begriff sind, also nix Buzzworte, einfach mal die ROM Kernel Reference Manuals = die Amiga Bibel lesen, da stehen all diese "Buzzworte" drin, also nix Erfindungen von mir

EditEdit: ich könnte die Buzzworte wohl kurz erklären, aber ich denke mal, da rede ich dann gegen eine Wand die nicht über ihren Windows-Tellerand hinausschaut

Edit: ich vergass

Das nennt sich auch beim Amiga nicht anders, dafür lege ich die Hand ins Feuer.

es nennt sich also definitiv anders, Du hast Dir die Hand verbrannt und ich soll nun der Depp sein ??

mann, wird echt Zeit nen anderes Computer Forum zu suchen...

Ich hab kein Word.

Word ist weniger das Problem, mehr das Excel

del_4901

2007-09-07, 22:59:08

nun das ganze mal umgekehrt, dann bin ich wieder blöd, weil ich "Buzzworte" liefere - die nebenbei jedem Amiga Progger ein Begriff sind, also nix Buzzworte, einfach mal die ROM Kernel Reference Manuals = die Amiga Bibel lesen, da stehen all diese "Buzzworte" drin, also nix Erfindungen von mir

Diese Begriffe sind jedem Programmierer ein Begriff, nur anscheinend dir nicht. Und es wird nur peinlicher für dich, jedesmal wenn du so ein Buzzwort verwendest.
Und damit beende ich für meinen Teil das Gespräch, es hat keinen Sinn sich mit einem Google-Copy-Paste, & ich hab keine Ahnung was ich da eigendlich Paste, zu reden.

Gast

2007-09-07, 23:10:08

nun das ganze mal umgekehrt, dann bin ich wieder blöd, weil ich "Buzzworte" lieferel

Die lieferst du aber ohne jedlichen Zusammenhang. Und Semaphores haben direkt gar nichts mit Handles zu tun. Das ist ein von vielen Kernel Objekten, auf die (wenn eins erstellt ist) Referenzen (Handles) existieren. Und die geladenen libs usw. spielen unter der Betrachtung auch keine Rolle. Da gibt es unter Windows viel mehr und viel mächtigere. Und heutige Programme sind auch deutlich mehr auf Multithreading ausgelegt als Programme aus den 80ern.

del_4901

2007-09-07, 23:14:36

EditEdit: ich könnte die Buzzworte wohl kurz erklären, aber ich denke mal, da rede ich dann gegen eine Wand die nicht über ihren Windows-Tellerand hinausschaut

Na dann mal los, wie gesagt das hat nichts mit Win, Linux und/oder AmigaOS im speziellen zu tun.

No.3

2007-09-07, 23:17:28

Diese Begriffe sind jedem Programmierer ein Begriff, nur anscheinend dir nicht. Und es wird nur peinlicher für ich, jedesmal wenn du so ein Buzzwort verwendest.

Problem, ein Prozess unter Windows ist nur teilweise das was ein Prozess auf dem Amiga ist bzw. umgekehrt

Und damit beende ich für meinen Teil das Gespräch, es hat keinen Sinn sich mit einem Google-Copy-Paste, & ich hab keine Ahnung was ich da eigendlich Paste, zu reden.

jaja, komm mal von Deinem hohen Ross, nur weil Du noch nie was mit dem Amiga OS zu tun hattest, muss das net alles copy und paste und somit falsch sein

es gibt da z.B. ein sehr altes, aber sehr mächtiges Programm, Xoper (http://aminet.net/package/util/moni/Xoper28) sie unten die ersten 3 Zeilen in der "Hilfe" - selbst ein DAU wie Du wird es schaffen einen Buchstaben auf der Tastatur zu drücken und Dir dann alle vorhandenen/geladenen/belegten Ports, Devices, Semaphores, etc anzeigen zu lassen

http://img405.imageshack.us/img405/5999/xoperso7.png

aber ja ne, is klar, das Bild hab ich schnell mit Paint gemalt und den Xoper Eintrag in dem Softwarearchiv gefaked

Dein Widerstreben z.B. dem Excel copy-paste Paradoxon nachzugehen spricht auch Bände aka Augen vor den Tatsachen verschliessen.

Gast

2007-09-07, 23:26:40

Problem, ein Prozess unter Windows ist nur teilweise das was ein Prozess auf dem Amiga ist bzw. umgekehrt

Dann erkläre mal, was deiner Meinung nach unter Amiga ein Prozess ist.

aber ja ne, is klar, das Bild hab ich schnell mit Paint gemalt und den Xoper Eintrag in dem Softwarearchiv gefaked

Und was soll das jetzt aussagen? Da kannst du eben bestimmte Ressourcen anzeigen lassen.

No.3

2007-09-07, 23:27:44

Die lieferst du aber ohne jedlichen Zusammenhang. Und Semaphores haben direkt gar nichts mit Handles zu tun. Das ist ein von vielen Kernel Objekten, auf die (wenn eins erstellt ist) Referenzen (Handles) existieren.

das ist ja mit das Problem, das "System" Windows und Amiga OS (und andere OSes) lässt sich da nicht so ganz einfach vergleichen. Angefangen bei den Begrifflichkeiten...

Und heutige Programme sind auch deutlich mehr auf Multithreading ausgelegt als Programme aus den 80ern.

nun, was heisst ausgelegt, es gibt mehr als genug (alte) Amiga Programm die nicht nur in einem Thread laufen. Das OS hat das schon in den 80ern sehr gut unterstützt, im Gegensatz zu anderen eher-weniger-als-mehr-multitasking OSes.

Gast

2007-09-07, 23:29:03

Dein Widerstreben z.B. dem Excel copy-paste Paradoxon nachzugehen spricht auch Bände aka Augen vor den Tatsachen verschliessen.

Was soll er denn da auch nachgehen? die Verwendung des Clipboard ist Applikationssache.

L.ED

2007-09-07, 23:33:35

@AlphaTier
Vielleicht noch Ergänzend Hinzuzufügen, ich denke es ist nötig um gewisse Unstimmigkeiten zu beseitigen.

Bin für mein Teil schon recht Lange anbei, obgleich es immer nur ein Hobby nebenher gewesen und Darstellt, so hat es mich bisher immer gut Abgelenken können (mal Abschalten etc. pp.). Und dann auch tiefergehend (Interna) Interessiert, wenn auch es nicht bis hin zum selber Programmieren gereicht.

Was Ram technisch belangt, das hatte schon zu Anfangszeiten win 95/98 recht unsanft Begriffen & als zu akzeptierendes (damals noch sehr viel teureres) Übel Registriert, betreffs Windows <=> RAM <=> Leben.

Zu der Zeit Demonstrierte sich Amiga OS3.9 letztmalig dann in seiner Mächtigkeit, in dem es halt auf einem P3 600 Mhz mit 256MB RAM, höchst Professionelles Arbeiten ermöglichte (Bereich Grafik).

Ohne auch nur in die Verlegenheit zu gelangen, VRAM (swap) anwerfen/nutzen zu müssen! Schaute darüber auch TV (ja TV Karten wurden u.a. unterstützt!), :eek: lief dann meistens als Hintergrundberieselung während im Vordergrund mit Art Effect 3.0 Werkelte oder mit Wildfire 7 oder, oder, oder + + +

Es war durchaus möglich diese ganzen Ausgewachsenen Programme auf einmal zu starten und hin und her zu springen. (mit selbigen Arbeiten (weil es halt so gewohnt) habe früher ein win98 und XP in den Anfangszeiten regelmäßig abgeschossen @Blue Screen)

Nun gut und Parallel dazu (deutete es schon an), auf den jeweils dann selben Rechnern insbesondere noch unter win98 SE & P3 600MHz Zeiten, war es weniger schön, es war lahmarschiger, Multitasking technisch (vergleichsweise) ne Krücke etc. pp. :| Hört bloß auf (!) an die Zeit mag ich gar nicht Denken und war wirklich froh das Pünktlich zum Ableben der (damals noch sehr teureren) A4000 Hardware der Emulator Amithlon (http://de.wikipedia.org/wiki/Amithlon#Amithlon) erhältlich gewesen.

Generell wer Amiga OS 3.5 (später 3.9) Arbeitstechnisch gewöhnt und kannte hätte nie geglaubt das dessen ma so in der Versenkung verschwindet wie es heute der Fall. Vor allem wenn man den direkten Vergleich hatte auf ein und derselben Hardware. Gewisse Tendenzen waren aber schon damals abzusehen, wenn es eben in paar Kernbereichen stagniert (was ja auch geschehen).

Aber zu der Zeit war es wirklich der Hammer und konnte und hätte durchaus locker in Konkurrenz mit dem damaligen Windows 98 noch treten können (an sich war alles offen). Aber die Geigen haben alles Versaut und weiter möchte darauf auch nicht weiter eingehen (ist ne üble intrigante Geschichte), hier wirklich fehl am platzte!

Fortan bis heute jeweils immer über dem gewesen was im Mainstream bis Normalo HighEnd Bereich angesagt gewesen (auch um jeweils nie auf Swap angewiesen sein zu müssen)

Zu Normalo Gamer HighEnd Zähle ich Ram Technisch Beispielsweise derzeit die Obligatorischen 2GB (solcherlei Ausbau hatte bereits zu P4 Blüte Zeiten).

Derzeit sind es bei mir 3GB (waren es auch schon zur besagten Vista64Bit Testzeiten) und bin noch schwer am Hadern ob auf die 4GB gehe, auch da DDR1 eine Art Sackgasse. Und eigentlich die 4GB Ausbau derzeit nicht direkt benötige. Brauchen täte sie wenn dann und wann mal die ausladenden Video Render Geschichten am laufen, gerade auch daheim und dann zufällig die Zeit und Lust auf Beispielsweise so Ressourcen-fresser wie eine ne Runde Gothic 3 bekomme. Dann wird es eng bzw. unmöglich (wenn Swap keine Option!).

Wie es dann und wann immer so ist wenn es kommt dann kommt alles aufeinmal. :mad: ;)

Gast

2007-09-07, 23:33:44

das ist ja mit das Problem, das "System" Windows und Amiga OS (und andere OSes) lässt sich da nicht so ganz einfach vergleichen. Angefangen bei den Begrifflichkeiten...

Doch lässt es sich. Du versuchst hier immer ein Mysterium aufzubauen, was nichts mit der Realität zu tun hat. Die Begrifflichkeiten wie Prozesse, Threads usw. ist übell gleich. Das sind keine Erfindungen aus der Windowswelt, sondern Begriffe aus der Betriebssystemarchitektur Lehre.

nun, was heisst ausgelegt, es gibt mehr als genug (alte) Amiga Programm die nicht nur in einem Thread laufen.

Ich dachte, deiner Meinung nach gibt es keine Threads unter Amiga?

Haarmann

2007-09-07, 23:34:23

RISC Prozessoren sind bekanntlich ausgestorben wie die Dinosaurier - Opfer der später möglichen Transistorzahlen. Auch ein PPC ist kein RISC mehr.

AlphaTier

Komm mal vom Ackergaul runter...

Frei nach Steve Jobs zu NEXT Zeiten... Objekte sind dazu da, dass auch Vollidioten "programmieren" (im Sinne von Zusammenstümpern) können!

Deine Buzzworter gabs ja vielleicht schon in der Zeit vor den Objekten und deren "Segnungen" - schon mal daran gedacht?

del_4901

2007-09-07, 23:35:58

Angefangen bei den Begrifflichkeiten...

Also die du da oben genannt hast, die gibs auch bei allen anderen Betriebssystemen.
Problem, ein Prozess unter Windows ist nur teilweise das was ein Prozess auf dem Amiga ist bzw. umgekehrt

Dann erkläre mir mal den Unterschied, wenn es einen geben sollte.

Dein Widerstreben z.B. dem Excel copy-paste Paradoxon nachzugehen spricht auch Bände aka Augen vor den Tatsachen verschliessen.
Ich hab auch kein Excel.

einfach mal die ROM Kernel Reference Manuals = die Amiga Bibel lesen, da stehen all diese "Buzzworte" drin, also nix Erfindungen von mir

Die solltest du vielleicht mal lesen! Um mal kompentente Aussagen treffen zu können.

del_4901

2007-09-07, 23:39:57

AlphaTier

Komm mal vom Ackergaul runter...

Frei nach Steve Jobs zu NEXT Zeiten... Objekte sind dazu da, dass auch Vollidioten "programmieren" (im Sinne von Zusammenstümpern) können!

Deine Buzzworter gabs ja vielleicht schon in der Zeit vor den Objekten und deren "Segnungen" - schon mal daran gedacht?
Ich hab mit den Buzzwörtern ned angefangen. Ich hab nur verhindern wollen, das andere auf die Idee kommen, den Misst von No3 zu glauben, und damit noch mehr halbes Halbwissen auf die Welt loszulassen.

Gast

2007-09-07, 23:41:22

Frei nach Steve Jobs zu NEXT Zeiten... Objekte sind dazu da, dass auch Vollidioten "programmieren" (im Sinne von Zusammenstümpern) können!

Handles sind Referenzen auf Betriebssystem Ressourcen, was vornehmlich C Strukturen sind. Das hat gar nichts mit Objekten im Sinne von Klassen Instanzen aus der OO Welt zu tun.

No.3

2007-09-07, 23:43:34

Dann erkläre mal, was deiner Meinung nach unter Amiga ein Prozess ist.

ich sags mal so, wenn Du auf dem Amiga eine .exe startest wird läuft das Programm als Prozess. Der Prozess wird gescheduled, bekommt die CPU Zeit zugewiesen und arbeitet den Programm Code ab.

Wenn das Programm sich nun "aufspalten" möchte, hat es zwei Möglichkeiten:

1) es startet einen weiteren Prozess, der unabhängig "von der Mutter" gescheduled etc wird
2) es startet einen Task, sozusagen ein Prozess der weniger "Rechte" hat, der aber unabängig "von der Mutter" gescheduled etc wird

den Begriff "Thread" gibt es im Amiga OS klassischerweise eigentlich nicht wirklich. Hat man irgendwann wohl irgendwie von anderen Systemen übernommen.

Und was soll das jetzt aussagen? Da kannst du eben bestimmte Ressourcen anzeigen lassen.

AlphaTier meint, dass das von mir erfundene aus google kopierte Begriffe sind.

Was soll er denn da auch nachgehen? die Verwendung des Clipboard ist Applikationssache.

Weil Excel das Clipboard völlig anders als alle anderen Programme verwendet. Die anderen Programme aus der MS Office benutzen das Clipboard gleich, nur Excel macht es anders.

del_4901

2007-09-07, 23:47:24

AlphaTier meint, dass das von mir erfundene aus google kopierte Begriffe sind.

Oh erfunden hast du die garantiert nicht, du weißt nur nicht was sie bedeuten. Und mehr habe ich auch nie behauptet. Also lege mir bitte nicht falsche Worte in den Mund.

BTW: ein laufendes Programm kann nur einen Adressraum und somit einen einzigen Prozess besitzen.

No.3

2007-09-07, 23:48:07

Die solltest du vielleicht mal lesen! Um mal kompentente Aussagen treffen zu können.

ich will sehen, wie Du ein Amiga Programm schreiben willst, ohne die RKRM gelesen zu haben

Ich hab mit den Buzzwörtern ned angefangen.

ich auch nicht - meine Buzzwörter kamen erst nach, Prozesse, Threads und Handles ;)

Ich hab nur verhindern wollen, das andere auf die Idee kommen, den Misst von No3 zu glauben, und damit noch mehr halbes Halbwissen auf die Welt loszulassen.

Retter der Menschheit :massa::massa::massa:

Haarmann

2007-09-07, 23:52:05

AlphaTier und Gast

Als ich mühseelig versuchte meinen Amiga zu würgen (anders kann man das nicht bezeichnen), war die Seuche, andere nennen dies C, nicht relevant - das tat ich gemütlich in Assembler (beim Umstieg auf x86 wiederum schüttelte ich erschrocken den Kopf als ich diesen intelschen Wirrwarr sah). Könnte ja sein, dass auch diese Leute solche Worte kannten und nutzten?

Leute aus der Zeit haben einen anderen Zugang und nutzen Worte entsprechend.

P.S Zu der Zeit war noch das 1.3 ROM aktuell, welches noch ohne "Seuche" auskam - das merkte man deutlich an der Patchzahl ;).

No.3

2007-09-07, 23:53:45

Oh erfunden hast du die garantiert nicht, du weißt nur nicht was sie bedeuten. Und mehr habe ich auch nie behauptet. Also lege mir bitte nicht falsche Worte in den Mund.

aha, aber behaupten, ich wüsste net was dahinter steckt

nur zur Info, ich hab die ROM Kernel Reference Manuals nicht raubkopiert, sondern gekauft ;) und fürs Proggen mit Devices, Ports und Tasks/Processes extensiv davon gebraucht gemacht. Hättest Du nen Amiga, könntest Du mal nen Amiga Programm von mir austesten, dass vor schon 10 Jahren - siehe Post weiter oben - einen Task öffnete und mit sich selbst Multitasking gemacht hat. ;)

Gast

2007-09-07, 23:55:50

den Begriff "Thread" gibt es im Amiga OS klassischerweise eigentlich nicht wirklich. Hat man irgendwann wohl irgendwie von anderen Systemen übernommen.

Das könnte durchaus ein Resultat des fehlendem Speicherschutz sein. D.h. beim Amiga ist dann alles ein leichtgewichtiger Prozess (Thread). Das ist aber kein Vorteil, sondern ein klarer Nachteil.

del_4901

2007-09-07, 23:55:51

del_4901

2007-09-07, 23:59:07

aha, aber behaupten, ich wüsste net was dahinter steckt

nur zur Info, ich hab die ROM Kernel Reference Manuals nicht raubkopiert, sondern gekauft ;) und fürs Proggen mit Devices, Ports und Tasks/Processes extensiv davon gebraucht gemacht. Hättest Du nen Amiga, könntest Du mal nen Amiga Programm von mir austesten, dass vor schon 10 Jahren - siehe Post weiter oben - einen Task öffnete und mit sich selbst Multitasking gemacht hat. ;)

Dafür brauch ich keinen Amiga ich komme auch mit Quelltext ... ASM C/C++ Basic etc. gut zurecht. (Ich sehe den die Ergebnisse vor dem virtuellem Auge) Poste den Quelltext doch einfach mal hier rein. Bevor ich's vergesse zu nem Quelltext gehört auch die eine oder andere Zeile Doku. Weil die ganzen Kerneleinsprungpunkte und Vektortabellen(int-listen) unter ASM habe ich natürlich nicht im Kopp.

No.3

2007-09-08, 00:06:38

Das könnte durchaus ein Resultat des fehlendem Speicherschutz sein. D.h. beim Amiga ist dann alles ein leichtgewichtiger Prozess (Thread). Das ist aber kein Vorteil, sondern ein klarer Nachteil.

ich sags mal so, der Begriff Thread "umgibt" mich erst seit jüngerer Zeit und dann eigentlich nur aus der Windows Welt kommend.

Wenn auf dem Amiga ein Programm sich auf mehrere Prozesse, Threads, Tasks, oder was auch immer aufspaltet spricht man von Multitasking. Einen Begriff wie "das Programm läuft Multithreaded" oder wie auch immer, gab es nicht.

Haarmann

2007-09-08, 00:15:10

Grestorn

2007-09-08, 00:15:55

wenn Du Dich da mal nicht verbrennst.

Es gibt keine Threads auf dem Amiga.

Genauer: Beim Amiga ist ein Thread immer gleichwertig mit einem Prozess.

Grund: Threads braucht man nur, wenn man virtuelle Adressräume hat (also auch Speicherschutz). Mehrere Threads arbeiten im selben Adressraum, während unterschiedliche Prozesse immer getrennte Adressräume haben. Hat man gar keine virtuellen Adressräume, gibt es auch keinerlei Unterschied mehr zwischen einem Thread und einem Prozess.

No.3, ich mag den Amiga auch. Er war ein tolles System. Absolut richtungsweisend in seiner Zeit.

Aber das System kann heute nicht mehr mithalten. Es hat sich leider überlebt. Man hätte das ganze AmigaOS Kernel austauschen müssen und eine Art Kompatibilitäts-Layer für Altprogramme einziehen müssen, um das OS auf einen modernen Stand zu bringen.

Und das ist exakt das, was MS mit WinNT/2k/XP bzw. Apple mit MacOS X gemacht haben.

(del)

2007-09-08, 00:20:46

Himmel... "Der Teufel hat es in sich" :up: Martin Gott sei dank bist du endlich aufgetaucht. Ich war nur ~2h weg und hier bricht schon die Hölle auf dem Ackergaul los :mad:

Ich kann nirgendwo sehen, daß No.3 hier das System über alles andere was es heute gibt stellt und grundsätzlich zur Verherrlichung des AmigaOS neigt. Daher...

Gast

2007-09-08, 00:23:13

Ganz bestimmt ist C kein Fortschritt zu einem 68k Makroassembler

Na toll, der läuft aber auch nur auf dem 68k. Merkst du was?

del_4901

2007-09-08, 00:32:08

AlphaTier

Ich weiss bis Heute nicht wozu die Seuche, also C, erfunden wurde - falls es wirklich um weniger Fehler gegangen sein sollte - das ging schief. Ganz bestimmt ist C kein Fortschritt zu einem 68k Makroassembler (Der Makroteil ist dabei sehr wichtig) egal welcher Syntax - dies gilt natürlich nur für den 68k. Beim intelschen Wirrwarr sieht das vielleicht anders aus - die Ursache ist jedoch wohl mehr beim Wirrwarr zu suchen.
Ob man da nun Makros oder (neuzeitlich) Templates bzw. Funktionen hat ist ja wohl Wurscht. Ok, ich spaare mir das Copy und pasten. Trotzdem finde ich einen Funktionsaufruf wesentlich schöner, nen Makro ist ja auch nicht mehr als ne ge-inline-te Funktion. Die Funktion kann ich aber einer Semantik-/Syntaxprüfung unterziehen. C selber ist nicht mehr als ein besseres ASM. Wenn es damals Probleme mit den Compilern gab ist das noch ein ganz anderes Problem.

Besser durchdacht war die Software wohl noch, weil man sparsam umgehen musste mit den Resourcen. Das ist aber ein ganz anderer Schuh.

Naja besser durchdacht auch wieder nicht, man hat nur früher gemerkt das da was schief läuft. (weil man sowenig Ressourcen hatte, und weil die Programme nur ein "paar" Zeilen hatten.)

Na toll, der läuft aber auch nur auf dem 68k. Merkst du was?
Und x86 ASM läuft nur auf nem x86er. Genau wie SSE / 3dnow in ASM nur auf AMD oder Intel lüppt.
C hat da natürlich noch den Vorteil der Plattformunabhänigkeit, wenn alle gelinkten Libs vorliegen.

(del)

2007-09-08, 00:43:48

Wenn es damals Probleme mit den Compilern gab ist das noch ein ganz anderes ProblemIch kann aber auch nicht sagen Kann man denn behaupten, daß es sie heute nicht mehr gibt? :|

Auch was die Effizienz 'des Ausgangsmaterials' angeht ist es eh mit jeder neueren Architektur und neuen Kompilern immer fast das gleiche Spiel aufs Neue. Momentan kriegt Intel die Bugs mit PGO im ICC10 nicht auf die Kette.
Es ist glaub ich schon der dritte Patch raus der gewisse Probleme beheben soll und es ist immernoch nicht 100% fixed.

Haarmann

2007-09-08, 00:48:07

AlphaTier

Ich bin mir nicht sicher, ob Du unter Makros das Gleiche verstehst wie ich - daher frage ich zur Sicherheit nach. Welche Eigenschaften würdest Du so einem Makro zukommen lassen?

Es gibt auch Heute natürlich noch Software, die kompakt ist. Allerdings gibts tonnenweise Software, welche nen Berg Zugemüse mitbringt und doch nur knapp mehr denn das übliche "Hallo Welt" darstellt.

Gast

Du kannst Assembler problemlos portieren, wenn die neue CPU mehr Resourcen bietet, denn die Alte. Damit fällt natürlich eine Portierung auf x86 flach...

del_4901

2007-09-08, 00:50:57

Ich kann aber auch nicht sagen Kann man denn behaupten, daß es sie heute nicht mehr gibt? :|

Auch was die Effizienz 'des Ausgangsmaterials' angeht ist eh mit jeder neueren Architektur und neuen Kompilern immer fast das gleiche Spiel aufs Neue. Momentan kriegt Intel die Bugs mit PGO im ICC10 nicht auf die Kette.
Es ist glaub ich schon der dritte Patch raus der gewisse Probleme behoben soll und es ist immernoch nicht 100% fixed.
Der ICC ist auch ohne "Profile Guided Optimization" schneller als jeder ASM-Steinzeit-Coder. Und das es Pobleme mit neuen Features gibt, ist wohl immer so. Man muss ja nicht immer die neusten Features verwenden.

del_4901

2007-09-08, 00:56:51

AlphaTier

Ich bin mir nicht sicher, ob Du unter Makros das Gleiche verstehst wie ich - daher frage ich zur Sicherheit nach. Welche Eigenschaften würdest Du so einem Makro zukommen lassen? Ein Makro ist eine Beschreibung um Programmcode zu erzeugen, das ganze läuft auf eine einfache Textersetzung hinaus, und ist nicht Typsicher. Makros werden vor der Compilezeit ausgewertet.
Makros sind die Seuche der Programmierung, nicht umsonst hat man Templates entwickelt.

Es gibt auch Heute natürlich noch Software, die kompakt ist. Allerdings gibts tonnenweise Software, welche nen Berg Zugemüse mitbringt und doch nur knapp mehr denn das übliche "Hallo Welt" darstellt.Weil es genug möchtegern Programmierer gibt..

Du kannst Assembler problemlos portieren, wenn die neue CPU mehr Resourcen bietet, denn die Alte. Damit fällt natürlich eine Portierung auf x86 flach... Totaler Quatsch! Ein PPC funktioniert ganz anders als ein x86. Und hat demzufolge auch anderen ASM-Syntax.

(del)

2007-09-08, 01:03:28

@AlphaTier
Jein. Ich kenn einen :uup: (nö, ehrlich jetzt) der hat sich doch mal hingesetzt und nur seine CRC-Routine vom Grund auf neu in Asm nachprogrammiert. Weil sich das für ihn eh nie ändert, immer wieder mitverwendet werden kann und leistungsrelevant ist. Und weil ihn das mal wirklich interessiert hat. Das war dann 1.5x schneller als der letzte ICC9. Und sein C-Kode für die Routine soll alles andere als schlecht sein. Für so ein Standardzeug gibt es schon im Netz genug sehr gute 'examples'.

Ein anderes rümliches Beispiel was neue wie aber auch alte Features angeht ist VC8 ohne den sp1. Da sind auf der MS-Blogseite zum VC Monate über Monate hunderte Entwickler zu jeder Gaga-News zum Thema VC8 in den Kommentaren fast schon ausgerastet. Es dürften sich ne lange Zeit manche aus dem Leitungsteam nichtmal mit einem vorsichtigen "Hello" blicken lassen. Ich nehme an du sitzt da aber eh genug im Stoff um mir jetzt keine Märchenstunde unterstellen zu müßen.

edit:
Das ist keine direkte pro-asm Stimme, aber das es "früher mal" größere Probleme mit Kompilern gab, deutet eben etwas falsches an ;)

No.3

2007-09-08, 01:09:35

Bevor ich's vergesse zu nem Quelltext gehört auch die eine oder andere Zeile Doku. Weil die ganzen Kerneleinsprungpunkte und Vektortabellen(int-listen) unter ASM habe ich natürlich nicht im Kopp.

lol, ne, so kompliziert isses dann auch wieder nicht

hmm, mal überlegen, hätte da ein kurzes Testprogramm, das sogar was sinnvolles macht, das hatte ich damals in 5 Minuten hingepfuscht. Vielleicht kein gutes Beispiel. Der grosse Brocken von dem erwähnten Programm ist etwas unübsichtlich. Daher ein triviales Beispiel, wie man einen Prozess startet (auch nicht zu 100% sauber, war für mich ja nur zu Testzwecken gedacht :biggrin:):

MODULE 'dos/dostags', 'other/ecode', 'dos/dosextens', 'exec/tasks' - die "include" files

DEF maintask=NIL
DEF mainsignum=-1
DEF mainsig
DEF code=NIL

PROC main() HANDLE
DEF process=NIL:PTR TO process

IF (mainsignum:=AllocSignal(-1))=-1 THEN Raise(1) - sozusagen Signale anforden für die Kommunikation zwischen Mutter und Tochter
mainsig :=Shl(1, mainsignum)
maintask :=FindTask(NIL) - die Adresse zum Mutter-Prozess, wird von Tochter benötigt, ist hier trivial über eine globale Variable gelöst

IF (code:=eCode({my_proc}))=NIL THEN Raise(2) - spezifisch für die verwendete Programmiersprache, z.B. bei C nicht notwendig

IF (process:=CreateNewProc([NP_ENTRY,code, NP_CLI,TRUE, NP_NAME,'slave', NIL]))=NIL THEN Raise(3) - der Tochter Prozess wird gestartet

process.task.userdata:=99 - eigentlich _der_ Weg der Tochter Daten zu übergeben

Wait(mainsig) - Warten bis Tochter fertig ist

EXCEPT DO
IF mainsignum<>-1 THEN FreeSignal(mainsignum)
ENDPROC

PROC my_proc()
DEF task:PTR TO tc

Delay(5) - "warten" bis "process.task.userdata:=99" ausgeführt ist, auf ein Signal der Mutter zu warten wäre besser

task:=FindTask(NIL) - meine Adresse finden

WriteF('zahl: \d\n',task.userdata) - = der Inhalt von process.task.userdata:=99 wird in die Console ausgegeben

Signal(maintask , mainsig) - der Mutter signalisieren, dass man fertig ist
ENDPROC - der Tochter Prozess beendet sich hier selbst! Ein Task hingegen müsste von der Mutter beendet werden!

es ist also sehr sehr einfach einen Prozess zu starten. Die Prozesse hier kommunizieren nicht wirklich miteinander. Je nachdem wieviel Kommunikation in einem anderem Programm nötig wäre, kann man je nach dem sehr einfach mit den Signalen "reden". Für komplexere Aufgaben gibt es dann noch die Message-Ports

Haarmann

2007-09-08, 01:10:36

AlphaTier

Ich bezeichne nach wie vor C für die Seuche, aber zum Glück sind hier andere Meinungen nicht nur erlaubt, sondern auch erwünscht. Aber in dem Punkt sind wir uns einig. Makros erhöhten bei 68k Assembler die Übersicht über den Code gewaltig imho.

Diese Möchtegernprogger scheinen aber bei grossen Firmen weit verbreitet zu sein...

Solange ich immer einen Befehl oder mehrere Befehle habe, der einem anderen Befehl entspricht oder diesen übertrifft, kann ich es leicht umsetzen.
Das Gleiche gilt natürlich für die Register - und da sind wir beim Punkt gegen x86 - Register sind "etwas" knapp bemessen. Und auch wenn ich einen "Registeremulator" machen kann, so wird die Performance dadurch unterirdisch werden.

BessereHälfte

Ist das sowas wie ne pro Inline ASM Stimme?

del_4901

2007-09-08, 01:13:46

@AlphaTier
Jein. Ich kenn einen :uup: (nö, ehrlich jetzt) der hat sich doch mal hingesetzt und nur seine CRC-Routine vom Grund auf neu in Asm nachprogrammiert. Weil sich das für ihn eh nie ändert, immer wieder mitverwendet werden kann und leistungsrelevant ist. Und weil ihn das mal wirklich interessiert hat. Das war dann 1.5x schneller als der letzte ICC9. Und sein C-Kode für die Routine soll alles andere als schlecht sein. Für so ein Standardzeug gibt es schon im Netz genug sehr gute 'examples'.
Das mach ich gelegendlich auch, aber schreib doch mal ein ganzes Programm in ASM. Da vergehts dir ganz schnell.

Das ist keine direkte pro-asm Stimme, aber das es "früher mal" größere Probleme mit Kompilern gab, deutet eben etwas falsches an ;)
Bugs gibt es in jeder Sofware, die Compiler sind aber inzwischen so gut, das man abwägen muss. Und da brauchst du hier nicht anfangen Haare zu spalten, früher gab es nämlich echte Probleme mit Compilern. (z.B. schlechter oder gar falscher Code) Letzteres kommt z.b nicht mehr vor. Die Compiler arbeiten dann einfach nicht weiter.

(del)

2007-09-08, 01:16:37

Die Prozesse hier kommunizieren nicht wirklich miteinander. Je nachdem wieviel Kommunikation in einem anderem Programm nötig wäre, kann man je nach dem sehr einfach mit den Signalen "reden". Für komplexere Aufgaben gibt es dann noch die Message-PortsA'propos. Mich hat immer fasziniert wie Grestorn das damals mit dem lesenden, packenden/entpackenden und dem schreibenden Task erledigt hat. Er war immer merklich schneller als alle anderen die es ihm nachmachen wollten =)
Und das lag garantiert nicht nur an der sehr guten Packroutine :|

Ja ok. das ist jetzt OT innerhalb des OTs... Mußte ich aber mal loswerden.

edit
@AlphaTier
Ok. Falschen Kode gibts nicht mehr. Schlechten Kode gibts aber immernoch. Erzähl mir jetzt nichts vom Ackergaul :mad: Sei es das Teil lahmt nur auf einmal unerwarteterweise extrem.
Und wenn ich aufhören sollte Haare zu spalten (kein Problem damit), dann fang du nicht an in einem Beitrag zu verallgemeinern, daß der ICC jeden asm-progger immer in Grund und Boden fährt um mir kurz danach zu erzählen, du machst sowas gelegentlich selber. Kratz dich mal kurz am Kopf bevor du dich immer auf die Tasta stürzt und hau hier nicht so Löcher in den Thread, durch welche man Universen saugen kann!

No.3

2007-09-08, 01:19:10

Aber das System kann heute nicht mehr mithalten. Es hat sich leider überlebt. Man hätte das ganze AmigaOS Kernel austauschen müssen und eine Art Kompatibilitäts-Layer für Altprogramme einziehen müssen, um das OS auf einen modernen Stand zu bringen.

die PPC OSes bzw. AOS 4 bringen ja nen sehr guten Emulator für die alten Programme mit

ansonsten ist WinUAE + OS 3.5 hier auf dem A64 rattenschnell und rock solid stable

Und das ist exakt das, was MS mit WinNT/2k/XP bzw. Apple mit MacOS X gemacht haben.

Commodore war pleite, die vielen vielen Firmen die den Amiga gekauft haben und auch pleite gingen, etc, usw, haben weder Hardware noch OS weiterentwickelt.

nun gibt es analog zu MS und Mac nun AOS 4, nur fehlt die Hardware und die Leute die es kaufen ;)

wie auch immer, auch wenns mir vielleicht nicht gefällt, Surfen, Chatten, aktuelle Spiele zocken, schreiben, rechnen, Video, MP3 werde ich auf dem PC. In meiner neuen Wohnung wird mein A1k2 trotzdem den Ehrenplatz _zwischen_ dem dicken A64 und dem Core Duo Laptop bekommen ;) und für ne Runde Sim City und Co herhalten und die .MOD klingen nur mit DeliTracker und Co wirklich gut - natürlich mit 14 Bit Sound ;)

No.3

2007-09-08, 01:21:56

(del)

2007-09-08, 01:32:10

@Haarmann
Ich denke, heutzutage, wenn man schon asm etwas abgewinnen kann, kann man das nur beim 'Inliner' machen. Oder siehst du das anders?

Ich wiederhol mal GERNE nochmal den Edit an AlphaTier bevor es auf "12" untergeht
@AlphaTier
Ok. Falschen Kode gibts nicht mehr. Schlechten Kode gibts aber immernoch. Erzähl mir jetzt nichts vom Ackergaul :mad: Sei es das Teil lahmt nur auf einmal unerwarteterweise extrem.
Und wenn ich aufhören sollte Haare zu spalten (kein Problem damit), dann fang du nicht an in einem Beitrag zu verallgemeinern, daß der ICC jeden asm-progger immer in Grund und Boden fährt, um mir kurz danach zu erzählen, du machst sowas gelegentlich selber. Kratz dich mal kurz am Kopf bevor du dich immer auf die Tasta stürzt und hau hier nicht so Löcher in den Thread, durch welche man Universen saugen kann!

del_4901

2007-09-08, 01:38:54

Ok. Falschen Kode gibts nicht mehr. Schlechten Kode gibts aber immernoch. Erzähl mir jetzt nichts vom Ackergaul :mad: Sei es das Teil lahmt nur auf einmal unerwarteterweise extrem.
Und wenn ich aufhören sollte Haare zu spalten (kein Problem damit), dann fang du nicht an in einem Beitrag zu verallgemeinern, daß der ICC jeden asm-progger immer in Grund und Boden fährt um mir kurz danach zu erzählen, du machst sowas gelegentlich selber. Kratz dich mal kurz am Kopf bevor du dich immer auf die Tasta stürzt und hau hier nicht so Löcher in den Thread, durch welche man Universen saugen kann!

Eine Funktion in ASM umzuschreiben ist kein komplettes Programm. Das kann ein Programmierer noch gut überschauen. Bei größeren Brocken ist das aber nicht mehr so, und spätestens da versagt der beste ASM Coder, weil ein Hochsprachenprogrammierer einfach viel schneller mit der Arbeit fertig ist, und auch viel mehr Zeit zum testen und optimieren hat.
Meißtens lass ich es aber den Compiler machen, weil der in 99% aller Fälle einfach besser als ich bin/war.
Ich hau hier auch keine Löcher in den Thread. Von inline ASM war vorher nie die Rede. Also pass mal schoen auf wie du dich benimmst, und denke mal nach was du mit deinen Aussagen eigendlich bezweckst.

Zumal ich dazu noch sagen muss, dass inline asm leider nicht Compilerunabhänig ist. Der MS gcc und Icc machen das alle unterschiedlich. Da darf ich dann jedesmal die Funktion mehrfach schreiben. -> Fehlerquelle, schlecht erweiterbar, für mich als SW-Archtiekten einfach inakzeptabel bei größeren Projekten, wo mehrere Leute dran arbeiten, und das wohlmöglich noch auf mehreren Plattformen laufen soll.

Haarmann

2007-09-08, 01:45:36

BessereHälfte

Ich hab das Thema reiner ASM begraben, als ich in die Intel Welt einstieg - das geht imho unter brotlose Kunst, auch wenn ein Kumpel von mir sogar SW verkaufen konnte, welche auf Windows läuft und in reinem ASM geschrieben wurde ursprünglich.
Ich kann Dir daher nur zustimmen. Vielleicht ändert sich das in der Zukunft wieder einmal.

(del)

2007-09-08, 01:49:46

@AlphaTier
Ich benehme mich wenigstens heute schon regelkonform. Überall im Forum. Auch direkte Unhöfflichkeiten blieben den anderen erspart. Ich kann es mir heute sogar erlauben, dabei auf einige hier herabzuschauen. Sollen wir das zum Threadthema machen? Nur zu.

Sei es drum.
Wovon war jetzt hier die Rede? Ich denke selbst Haarmann wird erkennen, daß es schon gute Gründe gibt warum zB. noch kein Schwein auf dieser Welt es noch nicht hinbekommen hat sowas wie zB. Firefox in asm nachzuprogrammieren.
Wolltest du diese Erkenntnis :| ansprechen, als du das mit dem ICC und den chancenlosen asm-proggern erwähnt hast?

Weißt du aber wovon es erstmal auf den vorherigen Seiten die Rede war und was noch im Raum steht? Daß No.3 ein copy&paste n00b ist und keinen Plan von nichts hat. Sollen wir den Thread also wieder bissl von hinten aufrollen und die vergangenen Seiten aufarbeiten? Die Bühne ist frei. Hau mal rein.

edit:
02:11. Die Spannung ist mittlerweile geradezu unerträglich...

Grestorn

2007-09-08, 09:00:10

A'propos. Mich hat immer fasziniert wie Grestorn das damals mit dem lesenden, packenden/entpackenden und dem schreibenden Task erledigt hat. Er war immer merklich schneller als alle anderen die es ihm nachmachen wollten =)
Und das lag garantiert nicht nur an der sehr guten Packroutine :|

Die meisten Verzögerungen in dem Ablauf einer Datensicherung entstehen, weil immer wieder auf ein Gerät oder Vorgang gewartet werden muss - auf die Platte, auf das Backupmedium und auch noch auf den Packer selbst.

Da hat man mal ein echtes Multitasking-System (was Ende der 80er noch ein echtes Novum war) und dann nutzt es keiner. Ich empfand das damals als Herausforderung.

Es ist nicht so schwer, das ganze auf mehrere Prozesse zu verteilen. Beim PC würde man "Multithreaded" sagen, nur gabs den Begriff damals noch nicht. Das AmigaOS bietet ja auch alle notwendigen Mittel, Interprozesskommunikation abzusichern (Semaphore, Monitore). Ein paar Ringpuffer, für jede Aufgabe einen Prozess (plus einen für die Anzeige) und schon läuft das.

Ich habe nie verstanden, warum das nicht alle so gemacht haben :)

Grestorn

2007-09-08, 09:04:58

die PPC OSes bzw. AOS 4 bringen ja nen sehr guten Emulator für die alten Programme mit

ansonsten ist WinUAE + OS 3.5 hier auf dem A64 rattenschnell und rock solid stable
Ja, ich habe WinUAE auch, inklusive der Cloanto "Amiga Forever" Distris. Man ist halt auch ein Nostalgiker.

Aber wirklich nutzen würde ich das nie. Dazu hat AmigaOS aus heutiger Sicht einfach zu viele Nachteile.

Commodore war pleite, die vielen vielen Firmen die den Amiga gekauft haben und auch pleite gingen, etc, usw, haben weder Hardware noch OS weiterentwickelt.Du musst mir wirklich nichts über den Niedergang des Amigas erzählen :)

Ich habe nur beschrieben, was der einzige Weg gewesen wäre, AmigaOS in die moderne Welt zu holen. Eine einfache Erweiterung des EXEC Kernels musste scheitern. Auch die Intuition ist nicht richtig geeignet für ein modernes OS mit virtuellen Adressräumen. Das hätte man alles neu machen müssen und Alt-SW in einem eigenen Adressraum laufen lassen, wie Windows das mit 16-bit Software oder Max-OS X mit PPC/OS 9 SW macht.

No.3

2007-09-08, 09:38:57

Da hat man mal ein echtes Multitasking-System (was Ende der 80er noch ein echtes Novum war) und dann nutzt es keiner. Ich empfand das damals als Herausforderung.

dito, leider ging mir dann die Zeit aus, das in der Praxis in meinem Programm umzusetzen

Es ist nicht so schwer, das ganze auf mehrere Prozesse zu verteilen. Beim PC würde man "Multithreaded" sagen, nur gabs den Begriff damals noch nicht.

sag ich doch, aber ich bin ja nur ein copy-paste Noob, der daumäßig keine Ahnung hat, aber vielleicht glauben die Leute Grestorn ja mehr ;)

Das AmigaOS bietet ja auch alle notwendigen Mittel, Interprozesskommunikation abzusichern (Semaphore, Monitore).

sag ich doch, aber ich bin ja nur ein copy-paste Noob, der daumäßig keine Ahnung hat, aber vielleicht glauben die Leute Grestorn ja mehr ;)

Ich habe nie verstanden, warum das nicht alle so gemacht haben :)

hätte sich zumindest bei vielen Programmen angeboten

Aber wirklich nutzen würde ich das nie. Dazu hat AmigaOS aus heutiger Sicht einfach zu viele Nachteile.

was meinst Du mit wirklich nutzen?

Sicher, ne Diplomarbeit würde ich damit auch net schreiben, wobei, mein Bruder hat seine Diplomarbeit mit TeX nem Amiga und VMM (ich hoffe mal, dass Du weisst, wer/was VMM ist ;) ) geschrieben.

Klar, für Internet, Musik, Video und was ich heutzutage sonst so am Computer mache, sind die 50 MHz einfach zu wenig, aber es kommt heute immer wieder vor, dass ich UAE starte um ein bestimmen Problem zu lösen, was ich mit dem PC nicht lösen kann, weil die PC Software nicht das macht was ich will bzw nicht in der Lage ist das Umzusetzen was ich machen will ;)