SSE Instruktionssatz auf NEON portieren?

[Michael H.W. Weber]

Wer kann es leisten? Hintergrund ist die Tatsache, dass die neue INFERNAL 1.1 Version SSE als Voraussetzung hat, um laufen zu können. ARM CPUs unterstützen SSE jedoch generell nicht, haben stattdessen aber NEON. Das ist insofern ein Dilemma als die aktuellen RNA World Standardberechnungen sich selbst bei umfangreicheren WUs nun auf Basis der energiesparenden ARM CPUs berechnen lassen müßten, wenn denn INFERNAL 1.1 darauf liefe. Wir reden von einem Beschleunigungsfaktor von 100.
Sieht hier jemand die Chance, dass sich jemand findet, der SSE auf NEON portiert? Geht das überhaupt? Ich selbst bin hier technisch leider überfragt.

Michael.

[Grodahn]

Prinzipiell kann man alles was SSE kann auch mit nativen 64Bit-funktionen abdecken.
Oder anders gesagt: die Menge der lösbaren Probleme mittels x64 ist größer als die Menge der lösbaren Probleme mit SSE.

Generell würde ich deswegen behaupten: Was auf x86 SSE berechnet wird kann auch auf 64Bit Arm berechnet werden. Wird bei dem SSE-Programm nur mit Singel-Data gerechnet ists auch auf 32Bit Arm darstellbar.

Hat man dann eine ARM-Implementierung kann man diese natürlich auch mit NEON würzen. Da könnte es aber auf dem ersten Blick (http://en.wikipedia.org/wiki/ARM_archit ... .28NEON.29 ) scheinbar ein paar Tücken geben.
-SSE in der aktuellen Version unterstützt Vektoren mit 256Bit. NEON nur 128Bit. Das ist aber nur makulatur, Was SSE in 1 x 256Bit macht kann man auch in 2 x 128Bit machen.
- SSE unterstützt Vektoren die aus Double-Werten bestehen (2 x Double bei 128 Bit, 4 x Double bei 256Bit...) NEON anscheinend jedoch nur Vektoren aus 32Bit - Single-Fließkommazahlen.
Reitet INFERNAL 1.1 jetzt mittels SSE massiv auf Double-Werten und nicht Singel-Werten rum könnte es also gut denkbar sein dass es günstiger ist dass ohne unterstützung von NEON nach ARM zu portieren.

Ist mit Infernal 1.1 das hier gemeint: http://selab.janelia.org/people/eddys/blog/?p=643 ?
Da steht als Schlussatz:

and don?t let anyone tell you that O(N^4) algorithms aren?t tractable

Weshalb ich vermute dass Infernal informatisch langsamme Algorithmen durch geschickte Implementierung beschleunigt. Ich möchte hier schwer vermuten dass, falls Infernal SSE3.x oder gar höheres verwendet und mit 64Bit-Doubles rechnet nicht allzu viel von dieser Performance auf einem ARM über bleibt.

Ich schätze es handelt sich bei Infernal um eine Funktionsbibliothek? Sowas von hott nach hüh zu konvertieren und dazu noch performanceorientiert zu optimieren (NEON) kann (oder eher IST), salopp ausgedrück, verdammt viel Arbeit.. Liegt natürlich auch immer daran wie gut das Original dokumentiert ist, ob es da Testszenarien gibt usw. Sollte Infernal als C / C++ - Code vorliegen der lediglich SSE-Intrinsics verwendet sollte es die Sache erleichtern. Handelt es sich jedoch direkt um Assembler-Funktionen wird das Ganze aufwendiger. Hat Infernal 1.1 irgendwelche externene Abhängigkeiten wie z.B. anderen Bibliotheken wird es eklig falls es entsprechende Bibliotheken nicht bereits für ARM gibt.
Muss man sich das auch noch alles selber konstruieren kann sowas schnell ausarten. Hast du mal die Entwickler von dem Ding selber gefragt?

Ich habe leider kein ARM-Gerät mit NEON-Support das ich als Entwicklungssystem nutzen könnte.

[Michael H.W. Weber]

Mal in aller Kürze: Die neue INFERNAL Version ist laut Tilman nur deshalb nicht auf ARM einsetzbar, weil eben der SSE-Befehlssatz Voraussetzung ist, den es für ARM nicht gibt.
Die Vorgängerversion lief problemlos auf ARM (getestet habe ich eine Cortex-A8 CPU im BeagleBoard xM unter Ubuntu), also kann da nichts unintegriertes an Funktionen zu Problemen führen.
Der freie Quellcode wird durch den hauseigenen Linux C Compiler übersetzt.
Weitere Details: http://infernal.janelia.org/
Und Ja, ich stehe mit den Entwicklern seit einiger Zeit in Kontakt, kann also alles an konkreten Anfragen vermitteln.
Es sollte auch möglich sein, ein ARM-Entwicklerboard zu beschaffen und einer versierten Person, die sich mit dem oben beschriebenen Problem wirklich befassen möchte, zur Verfügung zu stellen. Daran wäre ich übrigens überaus interessiert.

Michael.

[Dunuin]

Am besten noch gleich auf ARMv8-Kompatibilität achten. Die wurden ja Ende letzten Jahres angekündigt und bekommen einen erweiterten NEON-Befehlssatz. DP Floats kommen z.B. dazu und es wird eine 64bit CPU.
Nicht das man sich da die Arbeit doppelt machen muss.

[coturnix]

Soweit ich das beurteilen kann, setzt Infernal nur SSE2 oder höher voraus und arbeitet nur mit 128 Bit. Und nach dem Überfliegen des Source Codes sieht es danach aus, als ob nur 32 Bit floats verwendet werden und keine doubles. Von daher sehe ich grundsätzlich keine Hürden, dass auf NEON zu portieren. Es ist C Source Code, der SSE Intrinsics benutzt und relativ gut dokumentiert ist. Kein Assembler. Abhängigkeiten gibt es keine. Funktional ist es in meinen Augen also machbar, nur eben ein Stück Arbeit. Da ich bisher wenig mit SSE oder NEON gemacht habe, kann ich aber nicht abschätzen, über wie viel Arbeit wir hier reden.

[Grodahn]

ist laut Tilman nur deshalb nicht auf ARM einsetzbar, weil eben der SSE-Befehlssatz Voraussetzung ist, den es für ARM nicht gibt

Naja ich kann verstehen dass wenn die Krux bei Infernal die SSE-Optimierung ist die da nicht drauf verzichten wollen.

Prinzipiell kann man wie gesagt alles was SSE kann auch in x86 Assembler ohne SSE machen. Und alles was ich in x86-Assembler machen kann, kann ich auch in ARM-Assembler machen da beide Prozessoren ja nunmal Turing-Vollständig sind.

Der Knackpunkt liegt hier:
Beim x86er ist es so (salop gesagt) dass ich mit SSE Dinge ziemlich schnell erledigen kann sollange ich sie nur mit SSE mache. Sagen wir ich habe Operation A, B und C. Kann ich alle drei Operationen in SSE abbilden säh das als Pseudocode so aus:
-> Lade Operanden von x86 nach SSE -> mache A -> mache B -> mache C -> Lade ergebniss von SSE nach x86.

Kann ich jetzt aber als Beispiel B nicht in SSE erledigen sondern nur in x86 sieht das so aus:
-> Lade Operanden von x86 nach SSE -> mache A -> Lade Ergebnisse von SSE nach x86 -> mache B in x86 -> Lade Ergebniss von x86 nach SSE -> mache C -> Lade Ergebniss von SSE nach x86

Hierbei kommt es dann ziemlich oft vor, dass das dekonstruieren / konstruieren der SSE-Vektoren nach x86-Scalaren soviele Taktcyklen benötigt, dass der SSE-Gewinn dahin ist.

Münzt man das Ganze jetzt auf die Infernal-ARM-Sache:
Hat Infernal eine optimale SSE-Bearbeitung und man konvertiert es nach ARM/NEON, es gibt in NEON jedoch nicht alle Möglichkeiten wie in SSE kann man das dann zwar wohl auch ohne NEON-Instruktionen erschlagen, aber die Performance ist dahin. Wahrscheinlich währe es dann besser direkt auf NEON zu verzichten womit jegliche Optimierung hin ist womit, soweit ich das richtig verstanden habe, ich wieder auf dem Stand der vorherigen Infernal-Version bin.

Sich den Infernal-Code vorzuknöpfen und eine fixe Analyse durchzuführen welche SSE-Intrinsics verwendet werden und welche davon Equivalente in NEON haben sollte keine lange Sache sein. Die Frage ist ob die Infernal-Jungs nicht genau dass schon getan haben und zu dem Schluss gekommen sind dass NEON weniger bietet als Infernal an SSE braucht

[Grodahn]

Ich habe gestern Abend mal einen Blick in Infernal geworfen,
genauer gesagt auf den Ordner infernal-1.1rc2\src\impl_sse

Der dort liegende Code verwendet folgende sse-intrinsics (mit häufigkeit)

_mm_setzero_ps - 6
_mm_set1_ps - 130
_mm_setr_ps - 37
_mm_shuffle_ps - 27
_mm_move_ss - 10
_mm_movelh_ps - 14
_mm_max_ps - 115
_mm_add_ps - 185
_mm_cmpgt_ps - 59
_mm_or_si128 - 13
_mm_slli_si128 - 5
_mm_srli_si128 - 4
_mm_setr_epi32 - 3
_mm_set1_epi32 - 91
_mm_add_epi32 - 15
_mm_movehl_ps - 9
_mm_mul_ps - 19
_mm_set1_epi16 - 60
_mm_setr_epi16 - 3
_mm_mullo_epi16 - 10
_mm_adds_epi16 - 54
_mm_cmpgt_epi16 - 7
_mm_and_si128 - 15
_mm_andnot_si128 - 6
_mm_subs_epi16 - 1
_mm_max_epi16 - 28
_mm_extract_epi16 - 11
_mm_cmpeq_epi16 - 4
_mm_set1_epi8 - 32
_mm_xor_si128 - 3
_mm_cmpeq_epi8 - 4
_mm_adds_epu8 - 4
_mm_subs_epu8 - 8
_mm_add_epi8 - 1
_mm_setr_epi8 - 6
_mm_max_epu8 - 37
_mm_insert_epi16 - 2

Da dies das erste Mal ist dass ich mich mit NEON beschäftige sind Irrtümer höchst wahrscheinlich. Auf den ersten Blick von meiner Warte aus würde ich jedoch sagen dass die meisten dieser SSE-Intrinsics über ein NEON-Äquivalent verfügen.

bei _mm_slli_si128 und _mm_srli_si128 sehe ich ein problem da NEON scheinbar keine Operationen mit 128Bit-Scalaren durchführen kann.

Desweiteren habe ich auf Anhieb keine NEON-Konterparts zu _mm_shuffle_ps, _mm_movelh_ps und _mm_movehl_ps gefunden, würde aber behaupten dass diese SSE-Anweisungen sich durch eine Kombination aus mehreren NEON-Anweisungen ersetzen lassen.

Deshalb und da NEON über nicht weniger 128Bit-Register verfügt als SSE würde ich behaupten stände eine Portierung nichts im Wege.

Ob im übrigen Sourcecode noch SSE verwendet wird habe ich nicht überprüft!

Anbei eine CSV mit den vorkommenden SSE-Intrinsics und ihren (imho) NEON-Gegenstücken.

[Michael H.W. Weber]

Ich denke nicht, dass die Infernal-Entwickler je an die Option gedacht haben, diese Software auf ARM laufen zu lassen geschweige denn sich mit NEON zu befassen. Das sind Mathematiker mit HPC-Vollausstattung im Rücken.

Es macht für uns - bzw. generell - nur Sinn, einen Port anzudenken, wenn im Vorfeld klar ist, dass die Performance, die die neuste Infernal-Version im Vergleich zu ihrer Vorgängerversion bietet, durch das Umschreiben in NEON nicht verloren geht. Denn abgesehen von dem 100-fachen Geschwindigkeitszuwachs unter Defaultbedingungen (!), hat die neue Fassung nach meinem Kenntnisstand nichts für uns essentiell neues zu bieten.
Ich möchte übrigens anmerken, dass die Monster-WUs bei RNA World in der Regel eben NICHT Defaultbedingungen, sondern Spezialeinstellungen nutzen. Will heißen, für diese Einstellungen hat auch die neue Infernal-Version keine Performancevorteile. Das gros der Berechnungen allerdings nutzt auch bei RNA World immer erstmal die Defaultsituation.

So. Ich würde jetzt vorschlagen, dass ich mich an ARM wende und denen die offenen Fragen direkt stelle. Voraussetzung dafür wäre, dass die Profis hier mir die zu stellenden Fragen zusammenschreiben UND, dass sich einer tatsächlich bereit erklärt, das Projekt anzugehen. Letzteres immer vorausgesetzt natürlich, dass die Antworten von ARM so ausfallen, dass es Sinn macht, sich an das Projekt zu wagen.

Michael.

[yoyo]

Wir sollten eher nicht soviel Aufwand hineinstecken, da Infernal für ARM bereits existiert
yoyo

[Michael H.W. Weber]

Wir sollten eher nicht soviel Aufwand hineinstecken, da Infernal für ARM bereits existiert

Für die neuste Version? Hast Du Infos von dem Meeting am Wochenende, die ich nicht habe?

Michael.

[Grodahn]

Es macht für uns - bzw. generell - nur Sinn, einen Port anzudenken, wenn im Vorfeld klar ist, dass die Performance, die die neuste Infernal-Version im Vergleich zu ihrer Vorgängerversion bietet, durch das Umschreiben in NEON nicht verloren geht.

So. Ich würde jetzt vorschlagen, dass ich mich an ARM wende und denen die offenen Fragen direkt stelle. Voraussetzung dafür wäre, dass die Profis hier mir die zu stellenden Fragen zusammenschreiben UND, dass sich einer tatsächlich bereit erklärt, das Projekt anzugehen

Ich würde vermuten dass es weniger Zeit und Mühe kostet Infernal nach NEON zu portieren und zu gucken was rauskommt als dass Ergebniss vorab zu analysieren. Weil wenn der x86 / Arm - Infernalcode sich nur in den SSE-Intrinsics unterscheidet ist das portieren mehr oder weniger ein Copy&Think&Paste.

[Michael H.W. Weber]

Ich würde vermuten dass es weniger Zeit und Mühe kostet Infernal nach NEON zu portieren und zu gucken was rauskommt als dass Ergebniss vorab zu analysieren. Weil wenn der x86 / Arm - Infernalcode sich nur in den SSE-Intrinsics unterscheidet ist das portieren mehr oder weniger ein Copy&Think&Paste.

Ich hatte Deinen Text oben nun allerdings so verstanden, dass durchaus noch einige Fragen im Vorfeld zu klären wären:

Da dies das erste Mal ist dass ich mich mit NEON beschäftige sind Irrtümer höchst wahrscheinlich

bei _mm_slli_si128 und _mm_srli_si128 sehe ich ein problem da NEON scheinbar keine Operationen mit 128Bit-Scalaren durchführen kann.

Desweiteren habe ich auf Anhieb keine NEON-Konterparts zu _mm_shuffle_ps, _mm_movelh_ps und _mm_movehl_ps gefunden, würde aber behaupten dass diese SSE-Anweisungen sich durch eine Kombination aus mehreren NEON-Anweisungen ersetzen lassen.

Michael.