Bus Datenkompression

[BUGFIX]

Hi!
Gibt es eigentlich Bemühungen seitens der Hardwarehersteller der Datenflut der Heutigen Busysteme durch hardwareseitige Kompression Herr zu werden?
Vieleicht ist es ja etwas blauäugig von mir, aber eigntlich dürfte es doch nicht so schwer sein einen Kompressionsalgorithmus in den Chipsatz zu 'verlöten'. Das sollte gerade bei hohen Datenmengen wie Texturen usw doch einigermaßen effizient sein, oder?

MfG

BUGFIX

[Aqualon]

Das Hauptproblem ist, dass bei einer Kompression der Daten durch das Bus-System eine Art Zwischenpuffer auf dem Board sein müsste, der die Daten zwischenspeichert und wenn dieser voll ist, könnten diese erst komprimiert werden. Auf der anderen Seite müsste dasselbe Verfahren zum dekomprimieren angewendet werden.

Dafür würde viel Zeit vergehen, ohne mit Sicherheit sagen zu können, dass ein eingebauter Kompressionsalgorithmus wirklich einen Vorteil bringt. Möglicherweise würden so effektiv mehr Daten übertragen werden können, aber die Latenz dürfte darunter leiden.

Wenn eine Software z.B. Texturen an die Grafikkarte schickt (bspw. der Treiber der Graka), weiß diese besser, wie die Texturen am besten zu komprimieren sind, um diese schnellstmöglich an die Grafikkarte zu schicken. Das Bussystem würde immer nur eine Folge von 0 und 1 haben, ohne zu wissen, ob eine Komprimierung Sinn macht oder nicht und falls ja, welches Verfahren am besten ist.

Aqua

[BUGFIX]

Also bei Zeitkritischen Buskomponenten wie Speicherbus und FSB kann ich mir gut vorstellen , dass es Probleme wegen der Verzögerung gibt.
Was AGP betrifft: eine Softwarkomprimierung benötigt aber sowohl Spiecher als auch Zeit insofern gewinnt/verliert sich da nix.
Aber wie sieht es bei busystemen wie PCI und USB Firewire usw aus?
Eine in Harware implementierte Datenkompression könnte durchaus gerade bei Streaming Daten einiges an Entlastung bringen.

MfG

BUGFIX

[Stone2001]

Datenkompression hat man früher mal für Befehle verwendet, die wurden gepackt im Speicher gehalten und beim Holen vom Prozessor dekomprimiert. Das hatte den Vorteil, das das Programm im Speicher weniger Platz gebraucht hat. Leitungen dadurch wurden z.b. nicht eingespart.

Daten, die über einen PCI-Bus (ö.ä.) gesendet werden solllen, vorher per Hardware zu komprimieren macht recht wenig Sinn. Zuerst müßte man festlegen, wieviel Daten und welches Verfahren man zur Kompression verwendet. Bei Bussen bietet sich die Busbreite an, wenn man mehr nimmt kommt man schon in den Bereich der Spekulationen und Annahmen. (Wir müssen dann z.b. annehmen, das wir min. n Datenwörter auf einmal übertragen, was man aber im Allgemeinen nicht garantieren kann) Aber einzelne 32 bit Wörter zu komprimieren macht in der Regel wenig Sinn, da kann es gut vorkommen, das unser 'komprimiertes' Wort größer ist. Und selbst wenn, hätte man nur den Vorteil, weniger Leitungen verlegen zu müssen.

Das Ganze müßte man sich nochmals überlegen, wenn man ein eigenes Bussystem entwirft, indem man z.b. gewisse Zyklen pro Transfer garantieren kann, etc. . Aber mit aktuellen Bussen in heutigen PCs dürfte die Hardwarekomprimierung nicht viel bringen.

Wenn man Bandbreite sparen will, ist es sowieso besser die Komprimierung in die Anwendungsschicht zu verlagern.

[Zool]

Bei IBM wurde mal mit einer Hardwarekompression für Speicherchips experimentiert. Sollte in einigen Servern eingesetzt werden. Aber seit 4 Jahren hört man da auch nichts Neues mehr. Hat sich wohl nicht gelohnt.

http://www.geek.com/news/geeknews/q22000/gee2000626001740.htm

[BUGFIX]

[...]
Das Ganze müßte man sich nochmals überlegen, wenn man ein eigenes Bussystem entwirft, indem man z.b. gewisse Zyklen pro Transfer garantieren kann, etc. . Aber mit aktuellen Bussen in heutigen PCs dürfte die Hardwarekomprimierung nicht viel bringen.


Bezieht sich das auch auf PCI-Express?


Wenn man Bandbreite sparen will, ist es sowieso besser die Komprimierung in die Anwendungsschicht zu verlagern.

Dann ist es aber wieder das selbe Problem:
Eine Daren-Kompression auf Anwendungsebene bringt keine Vorteiel gegenüber einer "HW-Kompression". Man braucht genau so zusätzlichen Speicher und möglicherweise ist das komp. Paket größer als das ursprüngliche Paket.
Vor allem hat eine Softwareseitige Implementierung den NAchteil mitunter Rechenaufwändig zu sein. Ein kleiner Chip bzw ein festverdrahteter Algorithmus brauch maximal 1 bit mehr zum übertragen "Compression 1 oder 0"
außerdem könnte eine solche festverdrahtete Logic immer synchron zum Bustakt laufen - und brächte die CPU nicht.

Naja - war ja nur so eine Idee
Denn bei der Texturkomp. der Graka muss auch einiges an logic in den Grakachip verbaut werden damit dieser die Daten nutzen kann.

MfG

BUGFIX

[Stone2001]

Bezieht sich das auch auf PCI-Express?
Nein, generell auf das Design von Bussen.

[micki]

das komprimieren von cpubefehlen, das hat man eigentlich in jeder CISC cpu. auf dem ARM kann man sich auch aussuchen ob man mit dem ARM- arbeitet oder dem THUMB-Befehlssatz.
der ARM hat immer 32bit pro befehl und der THUMB hat 16bit.
wenn man von einem 8bit oder 16bit speicher die befehle ließt, dann ist THUMB unter umständen doppelt so schnell.

zudem glaube ich nicht, dass das packen viel zwischenspeicher verbrauchen würde. wenn man sich überlegt, dass viele Daten die zwischen der cpu und ram hergeschoben werden eigentlich nur wenige bits gesetzt haben und die oberen bits meißtens alle 0 oder alle 1 sind, dann wäre es kein grosser aufwand eine cacheline von 32byte, ab und zu auf z.b. 8byte zu reduzieren und auf diese weise ein wenig schneller zu übertragen.
der nachteil wäre, wäre das die pipe länger werden würde, somit würde eventuell die latenz ein wenig steigen.

MfG
micki