Diskussion:Vektorprozessor

Also so direkt gleichsetzen kann man Feld- und Vektorrechner allerdings nicht: Vektorrechner können eine Operation in mehreren Zyklen auf einen Vektor anwenden (sie besitzen mehrere Pipelines für Aufgaben auf einem Vektor, diese sind meist in recht viele Phasen unterteilt.) Feldrechner sind dagegen aus einem Feld von Prozessoren mit jeweils zugehörigem Speicher aufgebaut; sie führen in einem Takt jeweils die selbe Operation auf ihre eigenen Daten aus.

Der Unterschied ist also, dass Vektorrechner nach der "Einschwingzeit" (also der Zeit, nach der die Pipelines gefüllt sind), pro Zeiteinheit und Pipeline das Ergebnis einer Operation auf einen Vektor liefern; Feldrechner hingegen führen eine einzelne Operation auf den Daten in ihrem eigenen Speicher durch, liefern also pro Takt das Ergebnis einer einzelnen Operation auf mehrere Daten.

Es arbeiten also beide, sowohl Vektor- als auch Feldrechner nach dem SIMD-Prinzip (Single Instruction, Multiple Data); während aber beim Vektorrechner der Geschwindigkeitsgewinn aus den Pipelines resultiert, ergibt er sich beim Feldrechner aus der direkt parallelen Ausführung der genau selben Anweisung.

Um mehrere Vektoren auf einem Vektorrechner zu verarbeiten, würde man sie der Reihe nach in die selbe oder verschiedene Vektorpipelines einspeisen; Beim Feldrechner hingegen würde man sie auf die Speicher der einzelnen Prozessoren legen, und dann pro Takt eine Operation auf jedem einzelnen der Vektoren ausführen, allerdings in jedem Takt die selbe Operation auf alle Vektoren gleichzeitig.

--193.171.46.149 10:10, 4. Okt 2005 (CEST)

Das stimmt, Feldrechner sind etwas ganz anderes, ich bin so frei und lösche das mal. Willst du nicht einen Artikel über Feldrechner verfassen? Kleiner Hinweis: "Prozessoren" im Zusammenhang mit Feldrechnern ist etwas irreführend; er besteht aus "processing elements", die von einer zentralen Kontrolleinheit (wie bei SIMD üblich) gesteuert werden. --RubenH 12:08, 21. Okt 2005 (CEST)

COPYRIGHT INFRINGEMENT!!!

Die Beispiele sind ja wohl dreist aus Hennessy und Patterson abegeschrieben:

http://www.bhusa.com/companions/1558605967/appendices/1558605967-appendix-g.pdf

Naja, ohne Quellen Angabe! Schade! bitte demnächst drauf achten! -- Benutzer:Sadfub nachgetragen

dreist? na-ja. die paar zeilen assembler (17) dürften keine nenneswerte schöpfungshöhe aufweisen. urheberrechtlich sollte das also kein problem sein, ein copyright haben wir in D nicht. -- ∂ 11:32, 9 November 2005 (CET)

Ich finde es ohne Quellenangabe aber schon bedenklich, sich mit fremden Federn zu schmücken! Wenigstens der Link zum Orginal und ein Hinweis dazu wären nicht schlecht, oder? -- Benutzer:Sadfub

Dieses Beispiel zeigt...

"Dieses Beispiel zeigt, wie elegant der Vektorprozessor die Aufgabe löst."

Ich denke, es ist für die Darstellung der Leistungsfähigkeit unerheblich, wieviele Zeilen Code verwendet werden müssen. Es sieht nur "elegant" aus, das ist aber auch alles. Vielmehr müßte man erklären, was vor allen in den zusammenfassenden Codeteilen passiert gegenüber einer herkömmlichen C-Schleife...

--Peejay 15:09, 2. Jul. 2007 (CEST)

irrefuehrende analogie/beispiel?

"Erhebliche Performancegewinne ergeben sich auch durch vektorisierende Algorithmen: Man vergleiche beispielsweise den Performancegewinn bei vektorisierten numerischen Operationen gegenüber ‚herkömmlicher‘ Numerik in MATLAB." die vektorisierten operationen bei matlab sind zwar aus einem aehnlicen grund schneller wie die vektorisierten operationen auf dem prozessor, nur ist bei matlab die ebene der interpreter zur laufzeit und nicht die CPU! als hilfreiche analogie koennte es gelten wenn matlabn ohne weitere erklaerung einer breiteren masse bekannt waere? denke nicht... analogie weitergehend erklaeren oder besser rausnehmen. 95.114.221.127 20:09, 14. Okt. 2010 (CEST)

x86 sse beispiel

hab mal ein aktuelles x86 sse beispiel hinzugefuegt, als C code mit inline assembler anteilen, fuer den GCC. 95.114.221.127 21:46, 14. Okt. 2010 (CEST)

Optische Vektorbusse.

Ach ja, jeder der noch die guten alten bösen Tage, vor dem InzestExodus auf diesen verstrahlten Dreckslochplaneten im Hinterkopf hat, kennt die wahre Macht der paralleloptischen Braggbusse, und die Fähigkeiten der optischen LNC Architektur, die Tiefraumoperationen erlaubt, durch Quantenzustandsabgleich riesiger Zahlenkolonnen ohne seriellen Flaschenhals.

Aber ernsthaft die Architektur der Schalloptischen Logiken hier einfach offen auszulegen wäre dann doch leicht übertrieben, zumal die sowieso von gottgerechten Inzestrassisten geschwärzt würde... die nichtmal simpelste Kommunikationsprotokolle einhalten können durch Hierarchismus und seriellen Arschschnüffelköterloyalismus der von AltweiberArchitektur aus HIVard.

Oh, zu Limitlos?

Arme Würstchen.. (nicht signierter Beitrag von 2003:E1:E73C:9394:BCE5:15AB:94D:7826 (Diskussion) 22:39, 29. Apr. 2021 (CEST))

Ein kleiner Keyboard-Rambo bezeichnet andere als "Arme Würstchen". Nun denn ;) 62.198.142.15 14:59, 19. Jul. 2021 (CEST)