Unterschied zwischen Hardware und Software Beschleunigung erklären

Hallo,

kann mir jemand den technischen Unterschied zwischen Hardware und Software Beschleunigung erklären?
Beispielsweise haben Intel Prozessoren ab einer bestimmten Generation sog. "AES Instruction sets" womit die AES Encryption schneller stattfindet.

Ich erinnere mich als blu-rays noch neu waren und Full HD Material auf damaligen X86 Prozessoren emuliert wiedergegeben werden musste, was ziemlich performance gekostet hat (hohe CPU Last). Wie ist es technisch umgesetzt worden, dass die Prozessoren eines jeden 100 Euro Bluray Players damals viel besser die Aufgaben bewerkstelligen konnten als die meisten x86 Prozessoren? Was war das entschieden spezielle an diesen Prozessoren? Dasselbe ist doch jetzt mit Skylake und HEVC passiert oder?

Soweit ich weiß gibt es auch keine Hardware Implementierung von OpenVPN, was dazu führt, dass die meisten Consumer-Router den OpenVPN Throughput bei 20-30 Mbit/s schaffen.
Was ist schwer an einer Hardware Implementierung? Jetzt nicht nur im Beispiel OpenVPN sondern generell?
(Klar - Kosten; aber mich interessieren die technischen Hürden die es zu überwinden gilt)

Vielen Dank

Edit: Meine Vorstellung des ganzen ist, dass ein Hardware-Beschleuniger bestimmte Befehlssätze zusammenfassen kann und dadurch Rechenzeit spart. So analog zur Analysis in der Mathematik wo es darum geht Terme zusammenzufassen und sich Arbeit zu sparen. Der Software Rechner, rechnet jeden einzelnen Term aus um das Endergebnis zu bekommen wohingegen der Hardware Beschleuniger sehr viele Terme aus der Gleichung "herausstreicht" und weniger rechnen muss.
Wenn diese Analogie von mir im Ansatz richtig ist - woher weiß der Hardware Beschleuniger welche Terme er herausfiltern muss? Ist das eine spezielle Art der Verdrahtung im Prozessor?

du hast es doch schon selbst gesagt: emulation. alles was per hardware beschleunigt werden kann ist nicht emuliert nativ sozusagen.

und wie immer hier zu lesen:
https://de.wikipedia.org/wiki/Hardwarebeschleunigung

Stell dir vor jemand kann nicht multiplizieren.

Der rechnet dann statt 5x5=25:
5+5=10
10+5=15
15+5=20
20+5=25
sind vier Rechnungen statt einer, also brauchst du 4 mal soviel Rechenleistung.

So läuft das mit CPUs und Grafikkarten halt auch ab. Eine neue Instruction ist in der Regel eine Vereinfachung einer Rechnung. Kann man die nicht, muß man den langen Weg gehen. Der geht mit einer CPU immer. Kann man aber die Vereinfachung geht das schneller.

GrumpyDude schrieb:

[...](Klar - Kosten; aber mich interessieren die technischen Hürden die es zu überwinden gilt)[...]
Ist das eine spezielle Art der Verdrahtung im Prozessor?

Zum Vergrößern anklicken....

Im Grunde ja. Für AES gibt es mit Hardwarebeschleunigung bestimmte Schaltkreise, die das übernehmen. Die müssen erstmal entwickelt und implementiert werden und nehmen dann auch Platz weg und machen den Chip so größer und teurer. Deshalb kann man ein Chip nicht beliebig mit Funktionen vollpacken. Im Gegenzug heißt das, dass ein Chip, der nur sehr wenig kann (wie der im Player) dann günstig gehalten werden kann.

Das sind alles sogenannte "fixed function" Einheiten. Bei Videodecoding hat man in die Grafikkarten die Decoder für MPEG2, MPEG4, h.264 und jetzt eben h.265 gepackt. Genauso beim BluRay Player: billiger kleiner 10€ MIPS oder ARM Kern und dessen Grafikkarte kann eben h.264 dekodieren.

Bei OpenVPN kann man AES einstellen, manche ARM CPUs haben sogar langsam Support für bestimmte Opcodes die AES schneller abarbeiten können. D.h. man muss die AES Runden nicht mehr in Software programmieren sondern die Instruktion macht eine ganze Runde alleine.

Die Algorithmen für AES oder h.264 müssen für das Gießen in Silikon geeignet sein. Z.B. dürfen sie nicht zuviele, zu weit auseinanderliegende Speicherzugriffe machen. Das muss man schon beim Design berücksichtigen.

Oder so ausgedrückt:

1) HW-Beschleunigung

Es gibt HW-Teile (Buffer, Busverbindungen, Umsetzung im Befehlsdecoder, ...) die speziell darauf ausgelegt sind,
eine bestimmte Funktionalität bereitzustellen. Ggf. sogar exklusiv nur dafür, diese HW-Ressourcen müssten dann sogar nicht mit den restlichen Systemaktivitäten geteilt werden.
Siehe die Bespiele von HominiLupus und Nilson.


2) SW-Beschleunigung

Nun kann man ja prinzipiell jede Logik bzw. jeden Algorithmus in Code ausdrücken.
Man (bzw. der Compiler) berücksichtigt dann eben die HW-Ressourcen der Zielhardware, die er kennt.
Wenn keine speziellen HW-Ressourcen bekannt sind, oder eben der Code nicht unter deren Berücksichtigung erstellt wurde (Verwendung optimierter Bibliotheken, Berücksichtigung entsprechender Befehlssätze wie SSE2, usw.), wird eben "genutzt was da ist".
Die Vorteile von HW-Beschleunigung sind dann nicht vorhanden.
Beispielsweise gab es in den Anfängen der Rechnertechnik keine spezielle Grafik-HW, das wurde alles von der normalen CPU miterledigt.


3)
Ich persönlich würde als SW-"Beschleunigung" im engeren Sinn nur bezeichnen, wenn es zumindest auf Treiberebene eine SW-Unterstützung gibt und nicht das Anwendungsprogramm selbst den Code enthält.
Beispielsweise hat DirectX in der Vergangenheit manche Grafikfeatures unterstützt, auch wenn die tatsächliche Grafikhardware diese nicht speziell hatte (=Emulation).

Diese feine Unterscheidung möge man mir aber korrigieren, wenn es eine allgemeingültige akzeptierte Definition dafür gibt.


4)
Man braucht also immer:
- Teile der HW, die spezialisiert sind (Flexibilität wurde gegen Performance getauscht)
- SW, die es ermöglicht die entsprechenden Programmteile/Daten an die spezialisierte HW weiterzureichen
(z.B. Schnittstellen wie DirectX/OpenGL, Grafiktreiber, optimierte Funktionsbibliotheken,...)
- Die entsprechende Berücksichtigung im Anwendungsprogramm.
Wie z.B. ein Renderingpfad, der auf eine bestimmte DirectX-Version angepasst wurde,
oder die besagte Software im Bluray-Player, die den eingebauten h264-HW-Decoder nutzt.