|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > AROS und Amiga-Emulatoren > UAE *Multi Threadet* Wann? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- | [ - Beitrag schreiben - ] |
|
11.08.2007, 05:07 Uhr L-ED Posts: 391 Nutzer |
Wollte mal hier in die Runde Fragen ob in nächster Zeit nun damit zu rechnen das WinUAE (intern) Multi Threadet wird? In jüngerer Zeit kann man ja nun u.a. neben der 030 und dem 060ziger sich auch einen der beiden externen FPU’s Emulieren lassen. Währe das nicht ein Ansatzpunkt, z.b. die FPU Emulation nun in einem 2then Thread zu legen und somit eventuell Vorhandene Dual Core CPUs Beispielsweise besser auszunutzen, im Sinne von einem weiteren Emulations-Geschwindigkeits-Plus? Etwa bei Anwendungen wie Cinema 4D, sollte sich doch dann eine solche Power FPU doch ordentlich bemerkbar machen können!? Oder ist da das Timing zu kritisch bzw. UAE Intern so komplex verwoben das ohne radikalerer Änderungen am gesamten Grundkonzept nix zu machen und von daher bis auf weiteres auch nichts diesbezüglich zu Erwarten? Und mal etwas weiter in Richtung Sony PSP geschielt wäre das doch auch ganz sicher ein Ansatz, dort dann Beispielsweise die Custom Emu auf den 2then Kern legen zu können!? [ - Antworten - Zitieren - Direktlink - ] |
|
11.08.2007, 09:19 Uhr Andreas_Wolf Posts: 2980 Nutzer |
> Sony PSP [...] 2then Kern Welchen 2. Kern? [ - Antworten - Zitieren - Direktlink - ] |
|
11.08.2007, 09:55 Uhr thomas Posts: 7718 Nutzer |
Zitat: Ja, damit würdest du beide Kerne kräftig beschäftigen. Zitat: Oh ja, das würde sich sehr deutlich bemerkbar machen. Zitat: Ganz im Gegenteil. Programme, die die FPU benutzen, bestehen aus CPU- und FPU-Befehlen. Wenn für jeden FPU-Befehl ein Thread-Switch und anschließend noch einer gemacht werden müßte, wäre das ganze absolut lahm. Das ist ungefär so, wie eine GUI auf einem PPC-Amiga zu programmieren. Da kannst du zusehen, wie einzelne Linien gezeichnet werden. Genauso wäre das auch bei der FPU-"Auslagerung". Was in eigene Threads ausgelagert werden kann, ist das meines Wissens bereits. Z.B. die HDD-Emulation. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomasrapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
12.08.2007, 02:25 Uhr L-ED Posts: 391 Nutzer |
THx für die Aufklährung  Zum anderen, ja die PSP soll einen mit max. 333Mhz Takt laufenden RISC Dual Core besitzen, in der Wiki steht das auch so (oder habe da nur ne Bezeichnung falsch Interpretiert)? [ - Antworten - Zitieren - Direktlink - ] |
|
12.08.2007, 03:47 Uhr Der_Wanderer Posts: 1229 Nutzer |
Ich könnte mir vorstellen, dass Multicore support gar nicht so schwer wäre in AmigaOS einzubetten. Eigentlich benötigt man nur einen Mechanismus, der die Threads sinnvoll aufteilt, den Adressraum teilen sich die Prozessoren ja, soweit ich weiss. Die Anwendung muss davon ja gar nichts wissen. Wenn man es bewusst ausnutzen will. braucht man dann lediglich zwei Threads parallel starten, z.B. beim Rendern einen für die geraden, und einen für die ungeraden Zeilen. Für WinUAE würde das bedeuten, zwei JITs laufen zu lassen, und z.B. mittels AFA den Multicore support einzupatchen. Bisher kann man nur bei Diskzugriffen und speziellen anwendungen multicore ausnutzen, z.B. bei WinUAELame,aber nicht bei Anwendungen die innerhalb der 68k emu laufen. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
12.08.2007, 08:30 Uhr thomas Posts: 7718 Nutzer |
@Der_Wanderer: Bei jedem Forbid() mußt du den zweiten Thread stopppen und warten, bis er wirklich nicht mehr läuft. Und beim Permit() dann wieder starten. Das dürfte ein megamäßiger Overhead sein. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomasrapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
12.08.2007, 12:21 Uhr akl Posts: 265 Nutzer |
@L-ED: Eine singuläre FPU selbst in einen eigenen Thread auszulagern, könnte die beschriebenen Synchronisationsprobleme bringen, die dann wieder Overhead erzeugen. Einen geringfügig anderen Ansatz fände ich vielversprechender: - für jeden 68k-Task/Prozess Bedarf einen eigenen nativen FPU-Emulationsthread erzeugen (d.h. X-fache FPU-Simulation) - diese Threads zusammen laufen ggf. auf einem eigenen Core - das passt auch gut zu dem Ansatz der mathieee-Libaries unter AOS, wo ohnehin jeder Task/Prozess seine eigene Library-Base erhält (direktes Mapping auf einen der o.g. Threads) - bei Libraries wie mathffp wäre zu analysieren, ob ein eigener singulärer Server-Thread Sinn macht Natürlich müsste weiterhin eine Synchronisation stattfinden, allerdings könnte währenddessen ein anderer 68k-Prozess (und/oder sein FPU-Thread) ungestört weiterrechnen - d.h. kein Forbid/Permit. Die Effizienzfrage stellt sich natürlich weiterhin, die Antwort könnte aber deutlich günstiger ausfallen. [ - Antworten - Zitieren - Direktlink - ] |
|
12.08.2007, 12:30 Uhr akl Posts: 265 Nutzer |
@thomas: >Ganz im Gegenteil. Programme, die die FPU benutzen, bestehen aus CPU- >und FPU-Befehlen. Wenn für jeden FPU-Befehl ein Thread-Switch und >anschließend noch einer gemacht werden müßte, wäre das ganze absolut >lahm. Das ist ungefär so, wie eine GUI auf einem PPC-Amiga zu >programmieren. Da kannst du zusehen, wie einzelne Linien gezeichnet >werden. Genauso wäre das auch bei der FPU-"Auslagerung". Das trifft sicher auf Binaries zu, in denen FPU-Befehle direkt vorkommen. Eine mathieee-Library sichert jedoch z.B. vor Ausführung von IEEEDPDiv() eigentlich auch erst einmal alle 68k-Register und dann gibt es noch für jeden Task/Prozess einen eigenen FPU-Kontext, der zu sichern ist. Allerdings wurde in der Richtung ja bereits optimiert: http://aminet.net/package/util/libs/MathLibsUAE [ - Antworten - Zitieren - Direktlink - ] |
|
12.08.2007, 13:13 Uhr Andreas_Wolf Posts: 2980 Nutzer |
> ja die PSP soll einen mit max. 333Mhz Takt laufenden RISC Dual Core > besitzen, in der Wiki steht das auch so Okay, an den Media-Prozessor hatte ich nicht gedacht. Und der hat tatsächlich auch den gleichen MIPS-Kern wie die CPU. Dennoch ist das kein Dual-Core, denn es sind lediglich zwei Prozessoren im selben Gehäuse. Die CPU selbst hat nur einen Kern. [ Dieser Beitrag wurde von Andreas_Wolf am 12.08.2007 um 14:00 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
12.08.2007, 17:59 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ich kann mir dagegen vorstellen, dass es unmöglich ist. Dazu benötigt es einen Standard für die Steuerung, und davon erhalten wir derzeit im Zweifelsfall immer gleich zwei, und dann sowieso nur für ppc. Ein Multicore-Standard, der 68k mit unterstützt, würde ja sowieso auf eine UAE-spezifische Software hinauslaufen... Zitat:Genau das ist das Problem. Anwendungen teilen sich einen Adressraum und gehen davon aus, dass alles, was sie darin finden, konsistent im Sinne einer Single-CPU Ausführung ist. Zitat:Wird sie auch nicht. 99% aller Amiga-Anwendungen sind single-threaded. Und der Rest würde mit so einer transparenten Verteilung auf verschiedene cores nicht klar kommen. Zitat:Hä? Seit wann besitzt Aros Multi-CPU/Core Support? Bzw. ist AfA neuerdings Synonym für alles, was es im original-AmigaOS nicht gibt? Zitat:Richtig, und so wird es noch sehr lange bleiben. Zitat:Ja, ja, die Mythen, die sich um die Math-Libs ranken. Nur noch mal als kleinen Denkanstoß: Programme, die die FPU benutzen, bekommen eine FPU-Registersicherung beim Task-Switch frei Haus. Ohne die Math-Libraries benutzen zu müssen. Sonst würden solche Programme im AmigaOS nicht funktionieren. Und die Programme, die die FPU tatsächlich nur via Math-Libraries benutzen und nicht die Performance anderweitig verbraten, sind sehr selten. Und während echte FPU-Anwendungen tatsächlich damit klar kommen müssen, dass die FPU parallel zur Integer-Einheit des 68k arbeitet, kehren die Library-Funktionen erst zurück, wenn die Berechnung vollständig beendet ist. Weil das Ergebnis im Register D0 resp. D0/D1 zurückgegeben wird. Da ist überhaupt nichts parallelisierbar. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
13.08.2007, 07:57 Uhr L-ED Posts: 391 Nutzer |
@mal etwas leicht allgemeiner in den Raum gehalten ... mag zwar alles richtig sein, aber was hindert daran mal wieder nach vorne zu blicken, vielleicht mal was ganz neues zu machen!? Eben auf Software Basis und Virtualisierung, die zukünftig ohnehin mehr und mehr Interessanter wird. Im gewissen Sine stellt UAE das ja für u.a. Amiga schon seit langem dar nur eben halt alles noch ein Tick ausgefeilter bzw. aufwendiger. Da eben aus Kompatibilitätsgründen es erforderlich das die ganzen Hardwarekategorien Künstlich nachgebildet werden müssen, sonst täte das Amiga OS in seiner ursprünglichen (derzeitigen) Form überhaupt nicht laufen können. Aber erlauben wir uns doch mal wieder Schritte weiter zu denken, wenn ich hier ins Amiga Forum komme habe ich mittlerweile immer das beklemmende Gefühl in ne Art Totentempel einer längst vergangen Ära gerade hinein geschritten zu sein . (neee Moment! .. geht noch weiter) In derer einer Königin gehuldigt deren Geist aber, ja niemals zu Ruhe gefunden und deshalb eben es ihn noch gibt, diesen Tempel und Kult, mit den Leuten die ihn besuchen. Die Frage dabei ist die sich stellt, wann wir uns dran gewöhnen das sie nie wirklich Tot gewesen und gleichsam dereinst wieder Auferstanden!? Ihr einstiger Körper ist Vergangen (der modert da im Sarkophag), das war‘s auch schon! AMIGA selbst ist aufgestiegen in eine höhere Form der (Technischen) ExitenZ! Jetzt mal abgesehen von der eben leicht Theatralischen Formulierung (man hätte es anders schreiben können). Was hindert daran auf Basis des bereits erreicht an was Neuartiges zu denken, eine erweiterte Form von Virtual (Emu) Maschine Amiga!? Programmierer sind doch in gewisser weise Götter, sie können in dieser Form auch Dinge Erschaffen und Schöpfen die heut zu tage so in Hardware (real gegossen) nicht existieren müssen (die schiere erreichte Rohleistung ermöglicht dieses und noch ganz anderes). Das eröffnet gänzlich neue Perspektiven, gesetzt dem Fall der Wille und das Können dazu ist vorhanden! Salopp, Schöpft man eben halt eine neue next Gen 68k, (eine die es real nie gegeben) und oder passt ggf. zukünftige Amiga Software auf solcherlei an, das eben ein Art Effect der Zukunft mit solch einer Multi 68k umzugehen wüsste, schafft die Basis im System (Standards für sowas in Librarys gegossen)! Und das ist das was ich meine oder wo mal konkreter hinaus, hier herrscht vornehmlich ne Totenkult Stimmung bezüglich Amiga die ich in meiner Realität nicht Teilen kann, als wenn man unter Amiga OS (im zusammen hang mit Emulation unter Aktueller Hardware), nix mehr reißen könnte, auch auf Professionellerer Ebene (ne Art von Ruhestörung nur noch Darstellend), oder keine Sau mehr Interessiert, das ist doch Quatsch!? ^^( Gerade die Tage wieder was Schönes in Art Effect 4 zusammen gezaubert habe) Wir (alle) müssen von dieser ,,die Königin ist Tot es lebe der König‘‘, Stimmung weg, das ist das was am meisten Lähmt. [ Dieser Beitrag wurde von L-ED am 13.08.2007 um 08:10 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
14.08.2007, 11:06 Uhr Holger Posts: 8116 Nutzer |
Zitat:Nun, in dem Moment, wo Du etwas völlig neues schaffen willst, wirst Du ziemlich schnell feststellen, dass der gemeinsame Nenner, der die Amiga-Community verbindet, dort nicht mehr existiert. Für die einen ist der Amiga nur noch Retro (und somit eh alles neue ausgeschlossen), für die anderen muss es den offiziellen Namen tragen, für wiederum andere muss mindestens eine PowerPC-CPU involviert sein, und von denen, die dann noch übrigbleiben, scharen sich die einen um Aros, während die anderen denken, dass noch-ein-weiteres-Betriebssystem überhaupt nicht dem entspricht, was die Amiga-Welt braucht. Und z.B. selbst bei dem, was Aros am Ende eigentlich werden soll, bestehen völlig unterschiedliche, teilweise unvereinbare Vorstellungen. Um Deine Frage also zu beantworten, abgesehen davon, dass Wille und Können selten wirklich zusammentreffen, müsste ein Programmierer, der wirklich etwas Neuartiges im Sinne Deiner Frage schaffen will, damit rechnen, keinen zweiten zu finden, der die Vision in der gleichen Form teilt. Und dann müsste er im Alleingang etwas schaffen, dass möglichst auf Anhieb in Sachen Nutzen für den Anwender in der ersten Version überzeugt, um akzeptiert zu werden. Das war, glaube ich, bislang nur bei Amithlon der Fall. Und selbst das hatte Gegner... mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
21.08.2007, 14:11 Uhr gunatm Posts: 1432 Nutzer |
Das ist unfair! Die Anfrage ist halt sinnlos, wie oben schon ausführlich erklärt wurde. Es geht bestimmt nicht um bösen Willen! Ansonsten ist der Sourcecode von WinUAE frei, und der Ersteller bzw. Angesprochene dieses Threads können das Produkt ja selber durch den Compiler jagen. -- g.a.c. - german amiga community - A500,A600,A1000,CDTV,A2000,A3000,A4000,A1200PPC,CD32,WinUAE [ - Antworten - Zitieren - Direktlink - ] |
|
21.08.2007, 17:11 Uhr DrNOP Posts: 4118 Nutzer |
Zitat:Wäre das dann YAOS?  -- Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker [ - Antworten - Zitieren - Direktlink - ] |
|
22.08.2007, 11:26 Uhr Holger Posts: 8116 Nutzer |
Zitat: YAOS wird auch so alle paar Tage ein neues entwickelt. Hier geht es um YAALOS. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
| -1- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > AROS und Amiga-Emulatoren > UAE *Multi Threadet* Wann? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|