Julia: Erwägen Sie, ein `VecTuple{N,T}` hinzuzufügen, um N `VecElements{T}`s zu halten
Ich bin mir der Existenz von SIMD.jl bewusst. Ich glaube jedoch, dass die grundlegende Codegenerierung von SIMD-Vektoren in der Julia-Basis selbst einfacher unterstützt und einige der Details im Wrapping-Tupel ausgeblendet werden sollte, anstatt einfach durch den zugrunde liegenden Typ.
Daher wäre mein Vorschlag, einen Typ VecTuple{N,T} zu definieren, der im Wesentlichen dem aktuellen NTuple{N, VecElement{T}} . Der Unterschied wäre, dass die VecElement Codegen-Eigenschaften bei Bedarf implizit angewendet würden, aber an das Tupel und nicht an das Element gebunden würden. Auf diese Weise müsste für den Zugriff auf einzelne Elemente des Tupels keine zusätzliche Konvertierung T <-> VecElement{T} durchlaufen werden. Der Zugriff auf ein einzelnes Element eines NTuple{N, VecElement{T}} erfordert derzeit x[i].value anstelle von einfach x[i] .
Auch Anforderungen an die Gesamttypgröße und -ausrichtung bzw. welche Grundtypen (Bitgrößen 8 bis 64) überhaupt zulässig sind, wären an das spezialisierte Tupel gebunden. Siehe auch #20961.
Ich schlage nicht vor, alle möglichen Operationen auf SIMD-Vektoren zur Julia-Basis hinzuzufügen. Es sind sicherlich zu viele (denken Sie an Mischen, Transponieren oder Invertieren). Dies könnte vorerst noch alles spezialisierten Paketen überlassen werden, nur um die Art zu ändern, wie die grundlegendste LLVM-Codegen-Eigenschaft mit dem Tupel verknüpft ist.
( VecTuple ist natürlich nur ein Platzhalter für einen passenden Namen zu diesem Thema.)
m-j-w
Alle 3 Kommentare
Nur zur Erinnerung für andere, wir haben VecTuple nicht, da Tuple nicht als eine Art abstrakter Vektor definiert ist, daher ist es eine teilweise Kollision von Begriffen, über ein vektorisiertes Tupel zu sprechen.
vtjnash
am 14. März 2017
Eine Idee für das weitere Vorgehen wäre, ein neues Paket zu erstellen, das beschreibt, was Ihrer Meinung nach in die Basis aufgenommen werden sollte. Nennen Sie es zB SIMDBase . Wir können dann SIMD auf dieses Paket umleiten, was – wenn Ihre Annahme richtig ist – SIMD vereinfachen würde. Sobald sich die Leute über die Funktionalität von SIMDBase einig sind, könnte sie in Base verschoben werden.
Zum Beispiel würde es mir nichts ausmachen, wenn einige der LLVM-Aufrufverrenkungen auf niedriger Ebene an anderer Stelle behandelt werden könnten.
eschnett
am 14. März 2017
Als Referenz werden die intrinsischen SIMD-Typen auch hier ausführlich diskutiert: #2299
Ich werde versuchen, ein machbares Konzept zu entwickeln... könnte ein bisschen dauern.
m-j-w
am 15. März 2017
Verwandte Themen
dpsanders
·
3Kommentare
thofma
·
3Kommentare
StefanKarpinski
·
3Kommentare
ararslan
·
3Kommentare
iamed2
·
3Kommentare
Hilfreichster Kommentar
Eine Idee für das weitere Vorgehen wäre, ein neues Paket zu erstellen, das beschreibt, was Ihrer Meinung nach in die Basis aufgenommen werden sollte. Nennen Sie es zB
SIMDBase. Wir können dannSIMDauf dieses Paket umleiten, was – wenn Ihre Annahme richtig ist –SIMDvereinfachen würde. Sobald sich die Leute über die Funktionalität vonSIMDBaseeinig sind, könnte sie in Base verschoben werden.Zum Beispiel würde es mir nichts ausmachen, wenn einige der LLVM-Aufrufverrenkungen auf niedriger Ebene an anderer Stelle behandelt werden könnten.