Diskussion:Duff’s Device/Archiv/1

aus Wikipedia, der freien Enzyklopädie

Duffapparat

Ist der Begriff Duffapparat gebräuchlich? Ich finde es auf jeden Fall sinnvoll auf die Übersetzung einzugehen, da ich mich auch schon gefragt habe, ob das mehr ein Eigenname ist. (nicht signierter Beitrag von 129.13.72.198 (Diskussion | Beiträge) 12:16, 14. Apr. 2010 (CEST))

"++" als eigene Operation

Die Codebeispiele sind leider fehlerhaft. Genauer gesagt hat der Ausdruck: 

       ziel[stelle] = quelle[stelle++];

undefiniertes Verhalten, weil stelle und stelle++ ohne einen sequence point dazwischen ausgewertet werden. Wenn die Array-Schreibweise beibehalten werden soll, müsste es daher in zwei Ausdrücke umgeschrieben werden, also etwa: 

       ziel[stelle] = quelle[stelle]; stelle++;

Alternativ wäre stattdessen der Einsatz von Zeigern ala *ziel++ = *quelle++; --Chestal 21:19, 24. Okt. 2007 (CEST)

Stimmt. Ich wäre allerdings schon für die Beibehaltung der Array-Schreibweise, da sie für die meisten Leser klarer sein dürfte. --RokerHRO 22:59, 24. Okt. 2007 (CEST)
Wird dann halt etwas länglicher, ich ändere es aber erstmal entsprechend. Immer noch besser, als was Falsches. --Chestal 23:17, 24. Okt. 2007 (CEST)
Dieser Abschnitt kann archiviert werden. arilou (Diskussion) 09:39, 25. Jun. 2012 (CEST)

Beispiel Nummer 1 immernoch fehlerhaft

Hallo,

Beispiel Nummer 1 ist immernoch fehlerhaft. Man sollte schon irgendwo "stelle" auf 0 setzen, sonst stimmt die darunter liegende Aussage nicht.

Ähm, ja. Vielleicht sollte zuerst das Ausgangsbeispiel als komplettes Programm genannt werden. --arilou (Diskussion) 09:39, 25. Jun. 2012 (CEST)
Dieser Abschnitt kann archiviert werden. arilou (Diskussion) 12:13, 25. Jun. 2012 (CEST)

Fehler Bspl. 3

Voraussetzungen sind nicht klar. Was ist wenn im 3. Bsp anzahl=0 . --129.13.72.198 13:08, 14. Apr. 2010 (CEST)

Siehe vor-voriger Beitrag. --arilou (Diskussion) 09:39, 25. Jun. 2012 (CEST)
Dieser Abschnitt kann archiviert werden. arilou (Diskussion) 12:13, 25. Jun. 2012 (CEST)

Ausbau des Artikels

Ich habe mir erlaubt, den Artikel auszubauen und neu zu strukturieren. Vor allem wurde in der Vorversion das echte Duff-Device und seine Entstehungsgeschichte nicht beschrieben (!) und bestimmte Vorraussetzungen bzw. Probleme (z.B. anzahl == 0, s.o.) nicht angesprochen. Beachte: das Lemma Loop unrolling ist eine Weiterleitung hierhin, verdient aber eigentlich eine gesonderte Behandlung. Quellen und Literaturangaben finden sich im Artikel. --IrrwahnGrausewitz blah 17:39, 3. Sep. 2010 (CEST)

Dieser Abschnitt kann archiviert werden. arilou (Diskussion) 09:39, 25. Jun. 2012 (CEST)

"Loop unrolling"

Ich bezweifle mal ganz stark, dass der allgemeine Begriff "Loop unrolling" (bzw. "Loop unwindig"), den es für beliebige Programmiersprachen gibt, gleichbedeutend sein soll mit einem Verfahren, dass ausschließlich bei C und C++ funktioniert.

Daher kill' ich jetzt die Weiterleitung von Loop unrolling auf hießigen Duff's Device, und leg' dafür einen eigenen Artikel an!

--arilou 15:27, 3. Jan. 2012 (CET)

Dieser Abschnitt kann archiviert werden. arilou (Diskussion) 09:39, 25. Jun. 2012 (CEST)

Überarbeitung des Artikels

Mängel:

  • Der Artikel soll nicht bei Adam und Eva anfangen, sondern zügig zum Thema kommen. Wikipedia ist kein Lehrbuch. Was eine Schleife ist, muss man einfach voraussetzen können.
  • Formulierungen wie "was natürlich auch Tom Duff bewusst war" sind POV. Niemand weiß, was Tom Duff bewusst war oder nicht. Siehe auch WSIGA.
  • Stil: "ein Viertel so oft" klingt ja grausam.
  • Die Formulierung "umstrittene Eleganz" ist POV. Eleganz lässt sich nicht messen.

--Sunks (Diskussion) 16:34, 24. Jun. 2012 (CEST)

Das mag ja alles sein, mir ist das aber etwas zu sehr zusammengekürzt - und Wikipedia ist auch mehr als zwei Sätze, die dann durch ein paar Zeilen Code unterbrochen werden. Deine "Straffung" entledigt den Artikel doch auch einiger Informationen die m. E. erhalten werden sollten.
Den Ausdruck "Programmierschleife" gibt es übrigens nicht.
Und "unwinding" oder "unrolling" heißt nicht auf- sondern ab- oder aus"unwinding" oder "unrolling" heißt nicht auf- sondern ab- oder ausrollen.rollen.
Insofern schlage ich vor, hier erstmal zu diskutieren, was angeblich "gestrafft" werden soll. Deinen Punkten 2-4 stimme ich zu. -- Plankton314 (Diskussion) 16:52, 24. Jun. 2012 (CEST)
  • Nach meinen Kürzungen steht immer noch alles Wesentliche im Artikel. Die Verständlichkeit steigt. Welche Informationen sollen deiner Meinung nach erhalten bleiben?
  • "unwinding" oder "unrolling" heißt nicht auf- sondern ab- oder ausrollen. - einverstanden.
  • Den Ausdruck "Programmierschleife" gibt es nicht - einverstanden.
--Sunks (Diskussion) 17:19, 24. Jun. 2012 (CEST)
Zugegebener Maßen enthält die vorherige Version schon ziemlich viel Blabla, darum jetzt lieber die gekürzte Version stehen lassen. Ich schau es mir heut abend nochmal im Detail an und füge dann entweder das was ich für erhaltenswert halte ein oder schreib die Punkte kurz hierher. -- Plankton314 (Diskussion) 17:31, 24. Jun. 2012 (CEST)
Ok. --Sunks (Diskussion) 17:34, 24. Jun. 2012 (CEST)

Hab' mal einiges überarbeitet. --arilou (Diskussion) 12:15, 25. Jun. 2012 (CEST)

Gut, langsam wird es.
Ich hätte folgende Punkte um kurz aber beim wesentlichen zu bleiben:
  • es ist nicht unbedingt nötig das einführende Beispiel in einen Funktionsrumpf zu packen, dafür ist es simpel genug
  • Der ganze Abschnitt "Es kann die Ausführung beschleunigen ..." stimmt prinzipiell, aber der eigentliche Grund ist doch, dass ein linearer Programmablauf von CPUs bevorzugt wird (Prefetching)
  • "unwinding" heißt "ab-/ausrollen"
  • Kleinigkeit: die Überschrift "Probleme des Verfahrens" finde ich etwas umständlich, es ist doch eher üblich das einfach als "Kritik" zu überschreiben
  • "Bei heute übliche Prozessoren kann ..." - m. E. ist das andersherum: aktuelle Compiler können hierfür effiziente(re)n Code für diverse CPUs generieren
  • ich fände es nicht schlecht, wenn wir Duffs Zitat drin lassen
  • die Erwähnung, dass es eine Mikro-Optimierung ist, die heutige Compiler eher behindert, könnte ebenfalls hilfreich sein.
-- Plankton314 (Diskussion) 14:13, 25. Jun. 2012 (CEST)
  1. "kein Funktionsrumpf weil simpel" - siehe oben, da kommen Fragen à la "und warum wird stelle nicht zuerst =0 gesetzt?" u.ä. Besser, es gibt erst mal eine definierte Ausgangssituation.
  2. Prefetching ist indirekt erwähnt via "der Sprung muss seltener durchgeführt werden"; hab's jetzt zusätzlich erwähnt. Dass ein linearer Ablauf bevorzugt wird, ist nur bedingt richtig; soweit ich mich erinnere, wird bei manchen (bedingten) Sprüngen angenommen, DASS sie ausgeführt werden. Außerdem wird's übel, wenn die Schleife zuvor in den L1-Cache gepasst hat, nach dem Ausrollen aber nicht mehr. Das macht jeden Beschleunigungseffekt zunichte.
  3. Das "aus-/ab-"rollen anstatt aufrollen hättest' auch selbst ändern können...
  4. Auch die Überschrift hättest ruhig selbst auf "Kritik" ändern dürfen X-]
  5. "Prozessoren/Compiler": Diesen Kritikpunkt deinerseits verstehe ich nicht. Sagst du nicht dasselbe, wie schon im Artikel steht?!?
  6. "Duffs Zitat": Hilf' mir auf die Sprünge: Ich find' im ganzen Artikel nicht, was daran "Duffs Zitat" sein könnte.
  7. "Mikro-Optimierung": Wie gesagt, das ist ein Wiki. Schreib's rein wie du's für sinnvoll hällst.
--arilou (Diskussion) 15:52, 25. Jun. 2012 (CEST)
Danke fürs Erledigen der Kleinigkeiten, ich hatte wenig Zeit und wollte wenigstens kurz hinschreiben, was mir auf die Schnelle aufgefallen ist. Den Rest schreib ich dann selber rein.
Mit Duffs Zitat meinte ich:
Many people (even bwk?) have said that the worst feature of C is that switches don't break automatically before each case label. This code forms some sort of argument in that debate, but I'm not sure whether it's for or against. -- Tom Duff
-- Plankton314 (Diskussion) 16:03, 25. Jun. 2012 (CEST)
Ich bin dagegen, das Zitat aufzunehmen. Für die Erklärung des Lemmas bringt es nichts. --Sunks (Diskussion) 19:46, 25. Jun. 2012 (CEST)
Ich habe jetzt auch mal Kahlschlag betrieben und z. B. das Beispiel darüber entfernt. M. E. ist das überflüssig, da der Code unten ja auch noch erklärt wird.
Weiterhin habe ich gerade beim Anfang radikal gekürzt, da es für dieses (einleitende) Thema einen eigenen Artikel gibt: Loop unrolling
Den habe ich in gleichem Zuge ausgebaut. Bitte gerne noch um Mithilfe.
Ansonsten ist die Formulierung durchaus noch bearbeitungswürdig, aber ich hoffe, das hat dazu beigetragen den Artikel etwas zu "entschlacken" und auf eine informativere Version zuzusteuern. -- Plankton314 (Diskussion) 23:52, 25. Jun. 2012 (CEST)
Der Artikel liest sich jetzt viel besser. --Sunks (Diskussion) 07:33, 26. Jun. 2012 (CEST)

Löschung Abschnitt "Einsatzzweck Speicher kopieren"

Bzgl. diesen Edits durch Benutzer:Arilou hatte Benutzer:Shaddim einige Fragen/Anmerkungen, die er auf Arilous Disku-Seite dort: Disku-Abschnitt "Einsatzzweck Duff's Device" gestellt hat. Hier nochmals zum Nachlesen verlinkt.

--arilou (Diskussion) 09:34, 26. Sep. 2012 (CEST) // Jetzt irrelevant, da hierher verschoben.

Hallo Arilou,
Danke für den Hinweis. Als ich deinen Edit gesehen habe, habe ich mich auch gefragt, was nun richtig ist. Ich bin aber letzten Endes zu dem selben Schluss gekommen wie du, Duffs Device sollte ursprünglich einen Speicherblock auf ein gemapptes Ausgaberegister kopieren.
Es war nicht Aufgabe in einen weiteren Speicherblock zu kopieren. Wäre dies der Fall, müsste auch das Alignment im Zielblock berücksichtigt werden.
Ich stimme zu, dass der entfernte Abschnitt durchaus erwähnenswert ist, aber dieser Artikel ist m. E. nicht ganz der richtige Ort. In Loop unrolling würde ich ihn jedoch auch nicht gern sehen, aus den gleichen Gründen.
Mithin bin ich auch nicht der Ansicht, dass man in der WP alle erdenklichen Zusammenhänge knüpfen sollte (WP ist kein Tutorial). Wer sich mit DD beschäftigt hat wohl genug Kenntnisse dies auch auf andere Anwendungen zu übertragen. Gerade solche Mikro-Optimierungen sind sehr maschinenspezifisch und dazu gibt es im Web weiterführende Informationen.
Letztenendes ersetzt WP nunmal kein Lehrbuch.--Plankton314 (Diskussion) 11:21, 26. Sep. 2012 (CEST)
Ob Duff's Device für memcopy oder mem-to-register Transfers verwendet wird oder ersonnen wurde, spielt keine Rolle. Die Funtkion, Aufbau und und Motivation bleiben gleich, der Wunsch nach effektiveren Datentranfers. Typische Mittel dazu sind Hardware-aware Blockgrössen und Alignment, was Duff's Device ermöglicht bzw. berücksichtigt (siehe AMD paper). Und zu Verknüpfungen, WP SOLL weitergehende Wissenverknüpfungen ermöglichen. Shaddim (Diskussion) 10:41, 27. Sep. 2012 (CEST)
Ich denke, genau hier scheiden sich die Geister.
DD ist eine teilweise abgerollte Schleife - jedoch kein optimierter Datentransfer, der Alignment oder Blockgrößen speziell berücksichtigen würde.
Im englischen Wiki ist in einem kurzen Abschnitt erwähnt, dass man es zu einem memcpy umbauen kann, wenn man daraus ein *to++ macht. Vllt. wäre das ein gangbarer Kompromiss.
Was ich außerdem im en-wiki gesehen habe - und wir hier leider rausgeschmissen haben - ist die Erklärung zum switch/case-fall-through. Das sollte m. E. in den Erklärungabschnitt (oder sonstwo) noch mithinein. -- Plankton314 (Diskussion) 11:38, 27. Sep. 2012 (CEST)
  1. Ich habe etwas den Eindruck, dass sich Benutzer:Shaddim in die memcpy-Ecke verrannt hat. Eine entsprechende Diskussion (mittlerweile recht umfangreich) ist zu Beginn dieses Themas verlinkt.
  2. Wenn das jetzt hier auch mitdiskutiert wird, wird's mir langsam zu blöde, an zwei Stellen zu schreiben. *denk*
Ich kopier' das jetzt hier rein. --arilou (Diskussion) 11:52, 27. Sep. 2012 (CEST)

Einsatzzweck Duff's Device

[1] Lieber Arilou, will hier keinen Streit vom Zaun brechen aber denke deine Einordnung zur Kapitelentfernung steht auf schwachen Beinen. Würde im Gegenteil sogar sagen Memcopy und memfill sind sehr typische Einsatzgebiete von duff's device und sogar das Ursprungsszenario ("[...] Ausgabe von Bilddaten auf spezieller Hardware" -> Datentransfer aka memcopy). Zusätzliche stammt diese Einordnung aus der engl. WP und ist dort seit Jahren akzeptiertes Wissen. gruss Shaddim (Diskussion) 22:44, 25. Sep. 2012 (CEST)

Dann ist's dort auch ein Irrtum: Siehe Quelle http://www.lysator.liu.se/c/duffs-device.html , in der Tom Duff selbst schreibt "which copies an array of shorts into the Programmed IO data register", d.h. hier wird eben nicht von einem Ram-Bereich in einen anderen kopiert (deswegen auch kein *to++, der Pointer *to wird nicht inkrementiert! Alle Daten landen auf der selben Adresse! (Ein eingeblendetes Hardware-Register.)
Soweit ich weis, kann man memcpy auf keine Weise dazu überreden, einen n-Worte-Bereich auf nur eine Zieladresse zu schreiben.
Daher mag memcpy der Haupt-Einsatzzweck für Duff's Device sein, es war aber nicht der ursprüngliche Zweck (sondern eine andere, ähnliche Kopier-/Ausgabe-Aktion).
--arilou (Diskussion) 00:02, 26. Sep. 2012 (CEST)
PS: Im engl. Artikel zu Duff's Device steht im Gegenteil sogar ganz genau meine Erklärung! Bitte genauer lesen, ja? --arilou (Diskussion) 00:06, 26. Sep. 2012 (CEST)
Ähm, sorry entweder verstehe ich hier den Witz wirklich nicht oder... OK, aus meiner Sicht ist es für Duff's device (und loop unrolling allgemein) völlig irrelevant ob es um eine memcopy oder einen transfer von speicher zu register (mit wieder hinterlegtem speicher) geht. Die Technik bleibt extakt die selbe. Und auch die Motivation bleibt die selbe, der effektive Transfer von Daten von A nach B im Computer, auch beim Fall das alignment am ende nicht passt. gruesse Shaddim (Diskussion) 01:22, 26. Sep. 2012 (CEST)

PS: ah, du bestätigst aber das memcopy zumindest ein üblicher anwendungsfall ist, gut. Shaddim (Diskussion) 01:24, 26. Sep. 2012 (CEST)

1. Ein Hardware-Register muss nicht unbedingt "wieder hinterlegten Speicher" besitzen, abgesehen von der Handvoll Flipflops, die das Register selbst darstellen.
2. Soll ich den engl. WP-Artikel auch noch zitieren?!? Na gut:


Straightforward code to copy items from an array to a memory-mapped output register might look like this: 

do {                          /* count > 0 assumed */
    *to = *from++;            /* Note that the 'to' pointer is NOT incremented */
} while(--count > 0);

Note that this is not a memory-to-memory copy, in which you would see *to++.


Das Wörtchen "not" taucht 2* auf, man lese die dortigen Anmerkungen.
3. Bzgl. Motivation: "der effektive Transfer von Daten von A nach B im Computer, auch beim Fall das alignment am ende nicht passt."
Das kann eine Motivation sein, und es war die ursprüngliche.
Ob diese Lösung in der heutigen memcopy-Implementierung vorkommt, hängt stark vom Prozessortyp ab. Bei den weitverbreiteten 80x86-kompatiblen bin ich sehr sicher, dass die Antwort nein lautet - da wird ziemlich sicher keine Implementierung von à la Duff's Device drin stecken, da es einen extra Assemblerbefehl gibt: "Kopiere ab Adresse Register1 nach Adresse Register2 soviele Bytes wie in Register3 als Anzahl drinsteht". Das Inkrementieren von Register1 und Register2, sowie das Dekrement von Register3 und die Prüfung auf ==0 geschieht alles Prozessorintern (im Mikrocode). Afaik lastet der Prozessor dann seinen FSB voll aus (auch bei einem Copy L1-Cache -> L1-Cache fließen die Daten mit Fullspeed), sodass eine Optimierung nichts mehr herausholen kann.
Ob im Mikrocode eine "Duff's Device"-Variante vergraben ist, weis ich nicht, da musst du Intel/AMD fragen.
Habe ich deswegen hatte ich ja das AMD optimierungsmanual als Referenz eingebunden, die du so leichtfertig entferntz hast. :/
4. Duff's Device ist gänzlich unabhängig davon, ob irgendwas irgendwohin kopiert werden soll. Es ist einfach eine Spezialversion des Loop Unrolling, die in Assembler gang-und-gäbe ist, und (durch Herrn Duff erdacht) auch in C funktioniert. Egal, was im Schleifenkörper geschieht. Dass "memcopy zumindest ein üblicher anwendungsfall ist", kann sein, muss aber nicht. Viele Prozessoren bieten Spezialbefehle für schnelles Kopieren von A nach B, analog dem 80x86.
Sorry Shaddim, aber da sind viel mehr "kann" drin, als du gerne "ist" hättest.
--arilou (Diskussion) 09:27, 26. Sep. 2012 (CEST)
Ok, ich glaub wir haben hier von anfang an aneinander vorbei geredet. Wenn ich mal versuchen darf zusammenzufassen: deine Motivation für die Entfernugn dieses Anwendungskapitels war, das dort von memcopy gerdet wurde obwohl das ursprungsbeispiel nen memory zu register tranfer ist. Meine Motivation zum erhalt diese Abschnitts ist nicht das ich das wichtig halte das es ein memcopy ist sondern das überhaupt eine Einordnung im Artikel existiert wofuer das überhaupt gut ist. Ob das nun für memcopy oder register-serialsierten transfer ist aus meiner sicht völlig irrleevant, funktioniert genua gleich für beide, wichtig ist mir nur das überhaupt irgednwo erwähnt wird wofür und in welchem kontext das verwendet wird. Wäre für dich ein reintegration OK falls scharf zwischen echten mem-to-mem transfers und anderen varianten unterschieden wird? gruesse Shaddim (Diskussion) 11:38, 26. Sep. 2012 (CEST)
Ich sehe keine Notwendigkeit für solch einen Abschnitt. Es ist eine spezielle, trickreiche Variante des Loop Unrolling. Ein Beispiel ist bereits angegeben (die "Original-Version"). Innerhalb des Schleifenkörpers kann beliebiger Code stecken, es ist nicht ersichtlich, warum gerade ein Datentransfer-Beispiel angegeben werden soll. Imo ist das genannte "Original"-Beispiel genug an Beispielen. --arilou (Diskussion) 12:33, 26. Sep. 2012 (CEST)
Es geht nicht um Beispiele es geht um Motivation. Die wirkliche Motivation eines optimierten Datentransfers kommt hier kaum raus. Das man in einer Verarbeitungsschleife ein paar zyklen spart ist nicht wirklich der use-case. Use-case ist ein optimierter Datentransfer der durch das unrolling möglich wird (cache-aware, block sizes) ohne dabei bei misalignment am ende ein problem zu bekommen. Die Gesamteinordnung, warum dieser Trick relevant ist, fehlt. Dies kam auch in der von mir eingebrachtne Quelle zur Sprache. Prinzipiell sehe ich jetzt kann starkes Gegenargument von dir so ein Kapitel nicht zu haben. D.h. ich werde scharf zwischen memcopy und mem-to-register tranfer differenzieren und damit ein Einordnungskapitel erstellen. Gruesse Shaddim (Diskussion) 16:36, 26. Sep. 2012 (CEST)
Für den "optimierter Datentransfer" hat Tom Duff damals ein Loop Unrolling verwendet. Bitte das nicht übersehen! Duff's Device ist lediglich eine geschickte Variante, bei teilweisem Loop Unrolling das Problem der Nicht-Teilbarkeit der Anzahl Schleifendurchläufe mit dem n-fachen Entrollen der Schleife zu lösen. Einsetzen lässt sich Duff's Device für jegliches Loop Unrolling.
Dass auch heute noch die "wirkliche Motivation" (du meist vmtl. "wesentlicher/überwiegender Einsatz") ein optimierter Datentransfer sei, ist zunächst mal eine Behauptung von dir. Imo sorgt im Original-Beispiel v.a. das Loop Unrolling für einen "optimierten Transfer", Duffs Idee zu einem geschickten Schleifeneinsprung mittels switch optimiert nur noch wenig (insbesondere bei großen Werten für count).
Wenn du belegen kannst, dass Duff's Device heute v.a. bei Datentransfers verwendet wird, dann gerne in den Artikel damit. Evtl. könnte man z.B. die Linux-Kernel-Sourcen nach "Duff's Device" scannen, und prüfen, ob die Mehrzahl der Verwendungsfälle Datentransfers darstellen.
Ansonsten ist das nur ein Anwendungsfall unter beliebig vielen, und ich sehe nicht, warum speziell dieser ein eigenes Kapitel in Duff's Device erhalten sollte. Im Schleifenkörper kann alles mögliche drinstehen.
In http://web.mit.edu/ehliu/Public/ProjectX/Meetings/AMD_block_prefetch_paper.pdf , wird nirgends Duff's Device verwendet, im Großteil der Implementierungen werden Speicherzugriffe "am Stück" gefordert, die mit Duff's Device gänzlich unvereinbar wären. Ich sehe nicht, wie hier Duff's Device irgendwie helfen könnte.
Ausserdem - verliere bitte nicht den Blick dafür, dass Duff's Device eine Hochsprachen-Lösung ist (C, C++, evtl. weitere), ein entsprechendes Vorgehen in Assembler war schon zuvor bekannt und keine Leistung von Tom Duff. Die entsprechende Assembler-Vorgehensweise kann von mir aus im hießigen Artikel miterklärt werden, dann aber bitte sauber getrennt, dass das eine analoge Methodik in Assembler ist, die aber schon vor Duff's Device bekannt und gebräuchlich war.
--arilou (Diskussion) 10:13, 27. Sep. 2012 (CEST)
Im AMD Paper werden optimierungen diskutiert, darunter loop unrooling. Das Loop unrooling an sich ist sogar dort ineffektiv, ermöglicht aber weitergehende optimierungen ganz speziell für den Datentransfer ("Memorywall"). Das zeigt die Bedeutung, in einem normalen verabeitungsloop ist duff's device relative witzlos. Mein Punkt ist, dem Leser wird nicht klar gemacht warum das relevant ist, er könnte zu dem schluss kommen "Jo, ein paar taktzyklen checks gespart, langweilig, CPUs sind heutzutage eh nicht ausgelastet... " das ist aber nicth der Punkt bei Duff's device, der Punkt ist das ganz speziell beim datentransfer blockgrössen und alignment eine entscheidende Rolle spielen und berücksicht gehören für maximal performance. Die Aspekte Blockgrösse (unrolling) und alignment (am ende) werden duff's device berücksichtigt und erlaubt damit weitergehende signifikante optimierungen, was immer relevanter wird aufgrund der Leistungslimitierung durch das begrenze wachsen der Speicherbandbreite bei weiter wachsender Computingleistung. PS: Das Loopunrolling durch Duff's Device ermöglicht definierte Blockgrössen ("am Stück"). Shaddim (Diskussion) 10:29, 27. Sep. 2012 (CEST)

Lieber Shaddim, du verrennst dich da in was. Der Großteil deiner Argumente ist nicht Duff's Device spezifisch.

  1. In Fällen, in denen es derart auf Performance ankommt, wird Assembler verwendet. Und damit sind wir aus "Duff's Device" draußen.
  2. Ich kann in Tom Duffs Äußerungen auch nirgends etwas über "Blockgrösse (unrolling) und Alignment" finden. Er hat seine Schleife 8-fach entrollt. Es kann sein, dass er die Zahl 8 rein willkürlich gewählt hat.
  3. Ich steck' jetzt nicht sooo in C drin, aber dein vielgelobtes Alignment in C anzugeben, geht das überhaupt? Duff schreibt darüber gar nichts. Und Duff's Device beinhaltet nirgends eine Formel o.ä., ein wievielfaches Loop-Unrolling am sinnvollsten wäre, oder ähnliche Erkenntnisse. Deine "Blockgrösse (unrolling) und Alignment" sind bestimmt wichtig - haben nur nichts (zumindest nicht direkt) mit Duff's Device zu tun.
  4. Du schreibst "in einem normalen verabeitungsloop ist duff's device relative witzlos."
Tja, dazu sage ich: Duff's Device ist eben relativ witzlos.
Und du versuchst, einen tieferen Sinn reinzuinterpretieren, der einfach nicht drinsteckt.
5. Ach ja, ein Paper, das sich ausschließlich mit Datentransfer beschäftigt, zeigt natürlich nicht, dass dieses Thema besonders wichtig wäre.
Dazu müsste dieses Thema mit anderen Themen verglichen werden - die in selbigem Paper aber gerade nicht vorkommen. Es wird zu Beginn behauptet, dass heutzutage die Speicherbandbreite ein Flaschenhals wäre. Andere behaupten anderes. ("Festplatten sind der Flaschenhals heutiger PCs", "Internetanschluss-Bandbreite ist der Flaschenhals", ...) Und alles ist richtig - unter jeweiligen Randbedingungen.

--arilou (Diskussion) 11:15, 27. Sep. 2012 (CEST)

Ich bin mal so frei, und verlinke auf hießige Diskussion aus der Disku von Duff's Device. --arilou (Diskussion) 09:29, 26. Sep. 2012 (CEST)

Nun ja, das gebe ich gern zu ;) Meine Argumentation ist weder Duff's Device spezifisch noch C-spezifisch sondern eher meinem "Inklusionistischen" Bauchgefühl geschuldet das bei der Entfernung von kompletten Kapiteln(!) ein Problem hat und erstmal denkt das geht nicht. Und 2., ganz speziell von Kapiteln welche eine erklärende Einordnung für den Leser versuchen, dies ist meiner Meinung nach eine der Hauptaufgabe eines Artikels aber leider auch eine der Hauptschwäche der meisten Artikel: formal korrekt und alle technische Details korrekt aufgezählt, der unbedarfte Laie bleibt trotzdem irritiert zurück und fragt sich "Wofür? Warum so?". Auch deine jetzige Argumentation ist sehr detaillastig, du zerlegst sehr spitzfindig wieso Duff's device nichts aussschlieslich mit memorytransfer zu tun hat, formal kannst du so argumentieren, praktisch hast du unterminierst du aber die real-existierende Bedeutung. Die wirkliche motivation hinter alledem sind hardwarespezifische constraints und spezifisch die memorywall, siehe die motivation: Duff stellte fest das die transferierung von bilddaten zu lahm war. gruesse PS: nein das interpreteire ich nicht herein, das sagte Duff selsbt. Shaddim (Diskussion) 15:40, 29. Sep. 2012 (CEST)
Hallo Shaddim,
Ich würdige in jedem Fall dein Engagement für diesen Aspekt und finde es auch gut, dass du ihn sachlich vertrittst.
Außerdem bin ich ebenso der Meinung, dass die von dir angesprochenen Dinge (bzgl. Speicherzugriffen) wichtig sind.
Wie Duff selber feststellte, war das Problem die Schleife und nicht das Speicheralignment o. ä. DD ist und bleibt jedoch "nur" eine Art Loop Unrolling.
Wie Benutzer:Arilou richtig feststellte, hast du dich ein bißchen in die memcpy()-Ecke verrannt.
Vllt. wäre die wichtigere Frage, wo (in welchem Artikel) die von dir angesprochenen Punkte unterzubringen sind.
Nichtsdesto trotz, bin ich immer noch der Meinung, das eine Enzyklopädie kein Lehrbuch ersetzt in dem jede Mikro-Optimierung erwähnt werden muss. Einen zwingenden Zusammenhang zu dem Thema Duffs Device, Loop unrolling oder sogar memcpy() sehe ich auch nicht. -- Plankton314 (Diskussion) 16:48, 29. Sep. 2012 (CEST)

Meinungen aus dem Kollegenkreis

  • Duffs Dings ist eine programmtechnische Lösung für ein Problem, das er grad hatte.
  • Es ist eine Lösung für Hochsprachen, die kein GOTO kennen oder wünschen und switch kennen; also damals C und heute auch Java.
  • Mit Assembler und niederen Sprachen (freies GOTO) braucht es das nicht; da kann man das anders und effizienter machen.
  • Dokumentieren kann man die Motivation und sein damaliges Problem. Nicht belegen kann man eine Aussage, zu welchem Einsatzzweck der Algorithmus „überwiegend“, „meistens“, „hauptsächlich“ danach eingesetzt würde; dazu müsste man auch in den privaten Code aller non-open-source-Implementierungen gucken können. Es ist für Leser und damit enzyklopädisch auch völlig irrelevant. Duff’s ist ein Angebot; wer es für sein Problem als brauchbar erachtet, mag es einsetzen.
  • 8, 16 oder 32 als fest verdrahteten Block zu wählen ist schon sinnvoll; Duff fand für seine Anwendung halt grad 8 passend. Das alignment in C ist was anderes; aber bei bekannten Hardware-Eigenschaften wie einer Anzahl von Kanälen, Blockgrößen, Registeranzahl oder was immer kann man dies geeignet auswählen.
  • Im Abschnitt „Nachteile“ kann man als Alternative die Möglichkeit des memcpy anführen, und zwar praktisch den identischen Satz (mit anderem Beginn) und allen angegebenen Einzelnachweisen wie in dem gelöschten Abschnitt. Mehr als ein Satz ist es dann nicht.
  • Nebenbei meckern Compiler über unerwartete Verschachtelung von Kontrollstrukturen.

Schönen Abend --PerfektesChaos 18:51, 27. Sep. 2012 (CEST)

Der Interpretation das ein weitergehnde Einordung der Verwendung/motivation irrelavant wäre widersprecht ich heftigst, denke ganz im Gegenteil das wäre die wichtigste Aufgabe des Artikels. Die Idee Memcopy als Alternative einzubauen halte ich für eine gute und konsensfähige Idee (Arilou?). Der Hinweis bzgl der Kompilerwarnung sollte auch noch rein, stimmt. greusse Shaddim (Diskussion) 15:47, 29. Sep. 2012 (CEST)
Abgerufen von „https://de.wikiup.org/index.php?title=Diskussion:Duff’s_Device/Archiv/1&oldid=198977997“