Abo
  1. Foren
  2. Kommentare
  3. PC-Hardware
  4. Alle Kommentare zum Artikel
  5. › Power9: IBMs 24-Kern-Chip kann 8…

Hat sich eigentlich die Compression beim Transfer durchgesetzt?

  1. Thema

Neues Thema Ansicht wechseln


  1. Hat sich eigentlich die Compression beim Transfer durchgesetzt?

    Autor: Kleine Schildkröte 26.08.16 - 07:41

    Vor 20 Jahren im Studium war ein Thema, die Übertragung beim Speicher zu steigern, indem man eine einfache Kompression vorschaltet. Diese würde nur wenig zusätzliche Gatterlaufzeit im Chip benötigen. Man hatte zurecht argumentiert, das besonds in Codesegmenten und bei einigen Anwendungen bestimmte datenwörter überproportional häufig vorkommen.

    Gibts das in Chip gegossen oder ist das alles niesche bzw. tot?

  2. Re: Hat sich eigentlich die Compression beim Transfer durchgesetzt?

    Autor: Graveangel 26.08.16 - 08:24

    Kleine Schildkröte schrieb:
    --------------------------------------------------------------------------------
    > Vor 20 Jahren im Studium war ein Thema, die Übertragung beim Speicher zu
    > steigern, indem man eine einfache Kompression vorschaltet. Diese würde nur
    > wenig zusätzliche Gatterlaufzeit im Chip benötigen. Man hatte zurecht
    > argumentiert, das besonds in Codesegmenten und bei einigen Anwendungen
    > bestimmte datenwörter überproportional häufig vorkommen.
    >
    > Gibts das in Chip gegossen oder ist das alles niesche bzw. tot?


    Ich kann nicht von Fakten bezüglich CPU und Co sprechen, aber bei Grafikkarten wird das gemacht.
    Dort sind es aber wenig Code Segmente, sondern Bild Daten.

    Wie das bei CPU aussieht? Schwer zu sagen, aber vorstellbar.
    Es wird auf der CPU aber kein klassischer Code ausgeführt, sondern Bitcode (eigentlich Assembler).
    Aber klar, auch hier ist der Befehlssatz stark begrenzt, was Raum für Kompression lassen würde.

    Die frage, die ich mir stelle, wäre aber: wäre die Zeit zum komprimieren und dekomprimieren kürzer als die gewonnene Zeit beim Transport?
    Vor allem muss das ganze ja irgendwo zwischen, was die Anbindung wieder verlängern würde.

    Keine Ahnung, mal schauen, was der Rest sagt.
    Zumindest steht am Post jetzt eine 2,wodurch die Chance steigt ,mehr antworten zu erhalten ;)

  3. Re: Hat sich eigentlich die Compression beim Transfer durchgesetzt?

    Autor: zork0815 26.08.16 - 09:13

    Meint ihr vielleicht RISC Prozessoren?. 😃 Prinzip gab es schon in den 80er

  4. Re: Hat sich eigentlich die Compression beim Transfer durchgesetzt?

    Autor: EhNickma 26.08.16 - 11:00

    Das gibt es verschiedenen Feldern schon lange:
    - Spaltenorientierte Datenbank
    https://de.wikipedia.org/wiki/Spaltenorientierte_Datenbank
    - Ram
    https://en.wikipedia.org/wiki/Virtual_memory_compression

    Das Problem ist die gestiege Transfergeschwindigeit gegenüber dem Prozessualen Verlusten.
    Zum Beispiel ist vieles momentan Überflüssig durch Techniken wie Flash-Ram, SSD, PCI-4 und so weiter.
    Je weiter etwas in der Speicher Hierarchie etwas hinabsteigt, um so eher lohnt es sich zu kompimieren wenn es eigene Ressouren dafür hat. Also einen Kompressionsprozessor.

  5. Re: Hat sich eigentlich die Compression beim Transfer durchgesetzt?

    Autor: sogos 26.08.16 - 12:11

    Bei den modernen Prozessorarchitekturen sind die MMUs (Northbridge) in der CPU eingebaut , von daher ist die RAM<->Northbridge Geschwindigkeit eher abhaengig wie schnell die RAMs sind. QPI & HT beide unterstuetzen immerhin 300-400GBits/s und das auch von remote NUMA nodes. Im Vergleich ein DDR4-3200 schafft gerade 200GBit/s und QPI/HT skalieren pro Core/Socket (je nach Architektur). Jedes Gatter dazwischen erhoeht die Latenzzeit dermassen, dass man netto verliert. Dazu kostet RAM so wenig, dass man eher da nachlegen kann.
    Auch die Grafikkarten Speicher Kompression oben angesprochen ist sehr speziell - nur die Objektspeicher, Texturen und aehnliches, wo das Entpacken schon mal ein paar Micro Sekunden dauern darf. Gerne auch mit lossy Compression, geht ja nicht um Genauigkeit. Hier geht es auch darum, dass die GPU dann weniger Daten zu bearbeiten hat und die Textur noch in den "kleinen" Speicher passt und nicht so sehr, dass die Transferraten erhoeht werden.



    1 mal bearbeitet, zuletzt am 26.08.16 12:18 durch sogos.

  6. Re: Hat sich eigentlich die Compression beim Transfer durchgesetzt?

    Autor: HubertHans 26.08.16 - 14:43

    Kleine Schildkröte schrieb:
    --------------------------------------------------------------------------------
    > Vor 20 Jahren im Studium war ein Thema, die Übertragung beim Speicher zu
    > steigern, indem man eine einfache Kompression vorschaltet. Diese würde nur
    > wenig zusätzliche Gatterlaufzeit im Chip benötigen. Man hatte zurecht
    > argumentiert, das besonds in Codesegmenten und bei einigen Anwendungen
    > bestimmte datenwörter überproportional häufig vorkommen.
    >
    > Gibts das in Chip gegossen oder ist das alles niesche bzw. tot?

    Das ist scheibe...

    Die Daten muessten bereits beim Schreiben in denRAM komprimiert werden. Das kostet Zeit. Dann muesste der Speichercontroller es holen und dekomprimieren. Kostet Zeit. Dann muss der Speichecontroller es auf die Backplane der CPU (FSB/ QPI/ DMI/ Hypertransport) kippen. Und just in dem Moment war die Datenkompression sinnlos.

    Hinzu kommen noch andere Probleme: Der Speichercontroller begrenzt auf Grund der notwendigen Straps/ Teiler und dessen fertigungsqualitaet die MAximal erreichbare Datenrate. Der Prefetch wird auch nicht in voller Laenge verwertet. CPUs taetigen viele zufaellige Zugriffe. Das macht Speicher ab DDR2 schon mal steigend ineffizienter. GPUs dagegen moegen das.

    Was die CPU je nach Workload wirklich will sind niedrige Latenzen. Mit Datenkompression on the fly leider auf Grund des Aufbaus nicht ohne Kompromisse bei der Zugriffslatenz moeglich. Und alles im System muesste Daten komprimieren, um einen Effekt zu erzielen.

    Bei Grafikkarten dagegen war Datenkompression schon immer eine feine Sache und leistungssteigernd. Der Speicher/ Speichercontroller ist direkt an die GPU verknuepft und sehr latenzarm angebunden. Im Normalfall existiert hier nur eine GPU und nur diese greift auf den RAM zu. Es muss nicht dafuer gesorgt werden, das ein Bussystem, welches nach außen kommunizieren muss, auch Speicherzugriffe erlaubt. Und GPUs lieben Burst Zugriffe. Hier lohnt sich die Kompression, weil sie on the fly und fast ohne Latenzschwund realisiert werden kann. Keine zig Ebenen die komprimieren und dekomprimieren muessen.



    3 mal bearbeitet, zuletzt am 26.08.16 14:47 durch HubertHans.

  7. Re: Hat sich eigentlich die Compression beim Transfer durchgesetzt?

    Autor: Kleine Schildkröte 26.08.16 - 15:04

    EhNickma schrieb:
    --------------------------------------------------------------------------------
    > Das gibt es verschiedenen Feldern schon lange:
    > - Spaltenorientierte Datenbank
    > de.wikipedia.org
    > - Ram
    > en.wikipedia.org
    >
    > Das Problem ist die gestiege Transfergeschwindigeit gegenüber dem
    > Prozessualen Verlusten.
    > Zum Beispiel ist vieles momentan Überflüssig durch Techniken wie Flash-Ram,
    > SSD, PCI-4 und so weiter.
    > Je weiter etwas in der Speicher Hierarchie etwas hinabsteigt, um so eher
    > lohnt es sich zu kompimieren wenn es eigene Ressouren dafür hat. Also einen
    > Kompressionsprozessor.

    Da hast du völlig recht. Mir geht es um den Transfer zwischen CPU und Speicher bzw. innerhalb der CPU. Ich sitze gerade vor einer Aufgabe mit ner Menge Daten und bei Tests gab es dann das Ergebnis, dass selbst ein einfaches Komprimierungsschema sehr gute Verbesserungen gab, da L1 Cache dadurch 'gefühlt' um etwa 50% größer wurde. Daher kam ich wieder drauf.

  8. Re: Hat sich eigentlich die Compression beim Transfer durchgesetzt?

    Autor: Kleine Schildkröte 26.08.16 - 15:16

    HubertHans schrieb:
    --------------------------------------------------------------------------------
    > Kleine Schildkröte schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Vor 20 Jahren im Studium war ein Thema, die Übertragung beim Speicher zu
    > > steigern, indem man eine einfache Kompression vorschaltet. Diese würde
    > nur
    > > wenig zusätzliche Gatterlaufzeit im Chip benötigen. Man hatte zurecht
    > > argumentiert, das besonds in Codesegmenten und bei einigen Anwendungen
    > > bestimmte datenwörter überproportional häufig vorkommen.
    > >
    > > Gibts das in Chip gegossen oder ist das alles niesche bzw. tot?
    >
    > Das ist scheibe...
    >
    > Die Daten muessten bereits beim Schreiben in denRAM komprimiert werden. Das
    > kostet Zeit. Dann muesste der Speichercontroller es holen und
    > dekomprimieren. Kostet Zeit. Dann muss der Speichecontroller es auf die
    > Backplane der CPU (FSB/ QPI/ DMI/ Hypertransport) kippen. Und just in dem
    > Moment war die Datenkompression sinnlos.
    >
    > Hinzu kommen noch andere Probleme: Der Speichercontroller begrenzt auf
    > Grund der notwendigen Straps/ Teiler und dessen fertigungsqualitaet die
    > MAximal erreichbare Datenrate. Der Prefetch wird auch nicht in voller
    > Laenge verwertet. CPUs taetigen viele zufaellige Zugriffe. Das macht
    > Speicher ab DDR2 schon mal steigend ineffizienter. GPUs dagegen moegen
    > das.
    >
    > Was die CPU je nach Workload wirklich will sind niedrige Latenzen. Mit
    > Datenkompression on the fly leider auf Grund des Aufbaus nicht ohne
    > Kompromisse bei der Zugriffslatenz moeglich. Und alles im System muesste
    > Daten komprimieren, um einen Effekt zu erzielen.
    >
    > Bei Grafikkarten dagegen war Datenkompression schon immer eine feine Sache
    > und leistungssteigernd. Der Speicher/ Speichercontroller ist direkt an die
    > GPU verknuepft und sehr latenzarm angebunden. Im Normalfall existiert hier
    > nur eine GPU und nur diese greift auf den RAM zu. Es muss nicht dafuer
    > gesorgt werden, das ein Bussystem, welches nach außen kommunizieren muss,
    > auch Speicherzugriffe erlaubt. Und GPUs lieben Burst Zugriffe. Hier lohnt
    > sich die Kompression, weil sie on the fly und fast ohne Latenzschwund
    > realisiert werden kann. Keine zig Ebenen die komprimieren und
    > dekomprimieren muessen.

    Ich sprach ehr weniger von Zip und Konsorten, wo man große Mengen komprimiert. Mir ging es darum, dass in der Regel bei Programmen viele Speicherstellen einen signifikanten 0 Überschuss haben (hervorgerufen durch führende Nullen). Es gab vor 20 Jahren (und davor) einfache Gatterlogiken. Da kein Speicherzugriff nur einfach ein lokaler Speicherzugriff ist (Stichwort CacheLine, bzw. Seite (3rd level)). würde es sich Lohnen, wenn man sagen wir 100 Bytes bei 128bit Breite auf durchaus 80 Bytes reduzieren kann.

    Die Latenz ist nicht so weiter wichtig, da wir eh über outoforder reden und jeder weiss, dass man durchaus auch mal 4 bis 8 takte auf Speicher warten muss.

    Ich wollte nur mal wissen, ob diese einfache Kompression noch gemacht wird. Bei komplizierten Kompressionsverfahren mit Blockgrößen von 1k und höher würde es nicht viel Sinn machen, da die Dekompressionseinheit viel lesen und schreiben machen müsste und daher 1024 byte Registerraum bräuchte und sicherlich von der Chipfläche auch mehr. Sowas wird aber in den Interconnects bei Mehrprozessoren im Highperformancesegment gemacht. Da ist Kompression durchaus Standard und eine Funktion der Spezialprozessoren.

  9. Re: Hat sich eigentlich die Compression beim Transfer durchgesetzt?

    Autor: HubertHans 26.08.16 - 15:33

    Kleine Schildkröte schrieb:
    --------------------------------------------------------------------------------
    > HubertHans schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Kleine Schildkröte schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Vor 20 Jahren im Studium war ein Thema, die Übertragung beim Speicher
    > zu
    > > > steigern, indem man eine einfache Kompression vorschaltet. Diese würde
    > > nur
    > > > wenig zusätzliche Gatterlaufzeit im Chip benötigen. Man hatte zurecht
    > > > argumentiert, das besonds in Codesegmenten und bei einigen Anwendungen
    > > > bestimmte datenwörter überproportional häufig vorkommen.
    > > >
    > > > Gibts das in Chip gegossen oder ist das alles niesche bzw. tot?
    > >
    > > Das ist scheibe...
    > >
    > > Die Daten muessten bereits beim Schreiben in denRAM komprimiert werden.
    > Das
    > > kostet Zeit. Dann muesste der Speichercontroller es holen und
    > > dekomprimieren. Kostet Zeit. Dann muss der Speichecontroller es auf die
    > > Backplane der CPU (FSB/ QPI/ DMI/ Hypertransport) kippen. Und just in
    > dem
    > > Moment war die Datenkompression sinnlos.
    > >
    > > Hinzu kommen noch andere Probleme: Der Speichercontroller begrenzt auf
    > > Grund der notwendigen Straps/ Teiler und dessen fertigungsqualitaet die
    > > MAximal erreichbare Datenrate. Der Prefetch wird auch nicht in voller
    > > Laenge verwertet. CPUs taetigen viele zufaellige Zugriffe. Das macht
    > > Speicher ab DDR2 schon mal steigend ineffizienter. GPUs dagegen moegen
    > > das.
    > >
    > > Was die CPU je nach Workload wirklich will sind niedrige Latenzen. Mit
    > > Datenkompression on the fly leider auf Grund des Aufbaus nicht ohne
    > > Kompromisse bei der Zugriffslatenz moeglich. Und alles im System muesste
    > > Daten komprimieren, um einen Effekt zu erzielen.
    > >
    > > Bei Grafikkarten dagegen war Datenkompression schon immer eine feine
    > Sache
    > > und leistungssteigernd. Der Speicher/ Speichercontroller ist direkt an
    > die
    > > GPU verknuepft und sehr latenzarm angebunden. Im Normalfall existiert
    > hier
    > > nur eine GPU und nur diese greift auf den RAM zu. Es muss nicht dafuer
    > > gesorgt werden, das ein Bussystem, welches nach außen kommunizieren
    > muss,
    > > auch Speicherzugriffe erlaubt. Und GPUs lieben Burst Zugriffe. Hier
    > lohnt
    > > sich die Kompression, weil sie on the fly und fast ohne Latenzschwund
    > > realisiert werden kann. Keine zig Ebenen die komprimieren und
    > > dekomprimieren muessen.
    >
    > Ich sprach ehr weniger von Zip und Konsorten, wo man große Mengen
    > komprimiert. Mir ging es darum, dass in der Regel bei Programmen viele
    > Speicherstellen einen signifikanten 0 Überschuss haben (hervorgerufen durch
    > führende Nullen). Es gab vor 20 Jahren (und davor) einfache Gatterlogiken.
    > Da kein Speicherzugriff nur einfach ein lokaler Speicherzugriff ist
    > (Stichwort CacheLine, bzw. Seite (3rd level)). würde es sich Lohnen, wenn
    > man sagen wir 100 Bytes bei 128bit Breite auf durchaus 80 Bytes reduzieren
    > kann.
    >
    > Die Latenz ist nicht so weiter wichtig, da wir eh über outoforder reden und
    > jeder weiss, dass man durchaus auch mal 4 bis 8 takte auf Speicher warten
    > muss.
    >
    > Ich wollte nur mal wissen, ob diese einfache Kompression noch gemacht wird.
    > Bei komplizierten Kompressionsverfahren mit Blockgrößen von 1k und höher
    > würde es nicht viel Sinn machen, da die Dekompressionseinheit viel lesen
    > und schreiben machen müsste und daher 1024 byte Registerraum bräuchte und
    > sicherlich von der Chipfläche auch mehr. Sowas wird aber in den
    > Interconnects bei Mehrprozessoren im Highperformancesegment gemacht. Da ist
    > Kompression durchaus Standard und eine Funktion der Spezialprozessoren.

    Das Problem sind die Flaschenhaelse dazwischen, die ich angesprochen habe. Das betrifft nicht nur den Cache der CPU

  10. Re: Hat sich eigentlich die Compression beim Transfer durchgesetzt?

    Autor: chipfire 26.08.16 - 17:06

    Ich muss doch auch mal meinen Senf dazu geben. Da es sehr viel Senf geworden ist:
    TL;DR: Nein, technisch ist es auch nicht sinnvoll, wenn die Daten nicht strukturiert sind. Texturen sind das, der Inhalt des RAM ist es (aus Sicht des Speichercontrollers) nicht.

    Für alle, die es genauer wissen wollen, hier die lange Fassung:

    Ich weiss von keinem Speichercontroller, der eine Kompression verwenden würde. Das ist auch nicht sinnvoll, weil es den Aufbau des Controllers erheblich verkomplizieren würde. Dazu später mehr.
    Erst kurz zum Konzept der Datenkompression: man spricht dabei auch von sogenannter Entropiecodierung. Das bedeutet, dass man versucht, Muster, die häufig vorkommen, durch eine geringere Informationsmenge (also weniger Bits) zu repräsentieren. Das einfachste Verfahren ist das sogenannte Run Length Encoding, bei dem man einfach eine aufeinanderfolgende Reihe gleicher Werte nicht komplett speichert, sondern nur ein Mal den Wert und dann wie häufig er auftritt. Das Verfahren ist nicht sehr effizient. Wenn beispielsweise nur zwei Werte vorliegen, die immer abwechselnd auftreten, ist es nicht anwendbar.
    Komplexere Verfahren sind daher immer blockbasiert.

    Und damit fangen die Probleme an:
    - wie groß soll ein Block sein? Blockorientierte Verfahren werden tendenziell effizienter, je größer der Block ist, da sie Verwaltungsinformationen benötigen. Ist die Entropie hoch, können die komprimierten Daten daher sogar größer sein als die unkomprimierten!
    - man kann nicht beliebig in einen Block hineingreifen. Um auf einen Wert in einem Block zuzugreifen muss der komplette Block erst geladen und dann dekomprimiert werden.
    - die lineare Abbildbarkeit der Adressen zwischen Prozessor und Speichermodulen geht verloren. Dadurch wird eine zusätzliche Adressumrechnung erforderlich, da für jeden Block bekannt sein muss, wo seine komprimierte Variante im physischen Speicher liegt. Das erfordert wieder zusätzlichen Speicher und dementsprechend auch zusätzliche Speicherzugriffe.

    Der letzte Punkt führt zu weiteren technischen Schwierigkeiten. DRAM-Module sind für sogenannte Burst-Zugriffe optimiert. Das bedeutet, dass ich ein Mal eine Adresse angebe und der Speicherbaustein eine Menge Bytes liefert (üblicherweise eine Cache Line, also 64 Byte). Für andere Zugriffe muss mehrmals eine Adresse angelegt werden, was mehrere Speichertakte dauert, weil die Adresse in Zeilen- (Row) und Spaltenadresse (Column) aufgeteilt ist, die nacheinander auf den selben Leitungen angelegt werden und der Speicherbaustein auch eine Verarbeitungszeit hat. Der Grund dafür ist der interne Aufbau des Speichers als Speicherarray. Das wiederum macht überhaupt erst schnellen Speicher möglich, da viele Speicherzellen (Bits) parallel gelesen werden können.

    Trotzdem kann Speicherkompression für manche Anwendungsfälle sinnvoll sein, beispielsweise die bereits genannten Texturen. Das kommt daher, dass Texturen keine beliebige Größe haben können und diese auch bekannt ist. Traditionell haben Texturen eine Kantenlänge von 2^x Pixeln (z.B. 512x512 oder 1024x1024). Außerdem besteht hier eine andere Sicht auf den Speicher: bei einer Textur ist eine Menge von Bytes eine Einheit, auf die grundsätzlich komplett zugegriffen wird. Für einen Speichercontroller ist der Speicher "random", er hat kein Wissen, welche Strukturen dort abgelegt sind.
    Die Rastereinheit einer GPU (die die Texturen verarbeitet) kann darüber hinaus absehen, welche Texturen sie in nächster Zeit benötigt (über die eingehenden Primitive). Die entsprechenden Texturen können also schon angefordert und dekomprimiert werden. Hier unterscheidet sich also das grundsätzliche Zugriffsmuster: bei einer Textur ist es regelmäßig, bei einem Programm grundsätzlich erst einmal zufällig.

    Deshalb sind die üblichen Herangehensweisen an den memory bottleneck:
    - Parallelisierung: verteilen der Daten über mehrere Speicherelemente, also dual, triple und quad channel controller. (Auch die Module bestehen ja bereits aus mehreren Chips)
    - Zwischenspeichern häufig benötigter Daten, also Caching.
    - Zugriffsmustererkennung bzw. -annotierung durch den Programmierer, um Prefetching auszuführen.

    Noch ein Wort zur Latenz und Out of Order Execution (OOE): Ein Hauptspeicherzugriff dauert nicht 4 bis 8 Prozessortakte, sondern mehrere hundert. Und OOE kann man auch nicht beliebig weit treiben, so dass eine Vergrößerung der Latenz hiermit nicht zwangsweise abgefangen werden kann. Einerseits sind die Reservation Stations und die Größe des out of order windows (OOW) begrenzt (es können also nicht beliebig viele Befehle zurückgestellt werden), andererseits steigt mit steigender Größe des OOW auch die Wahrscheinlichkeit von Abhängigkeiten. Das ist also eine Kosten-Nutzen-Abwägung.

    Und damit ein schönes Wochenende und danke für eure Geduld :)

  11. Re: Hat sich eigentlich die Compression beim Transfer durchgesetzt?

    Autor: Kleine Schildkröte 26.08.16 - 21:32

    > Noch ein Wort zur Latenz und Out of Order Execution (OOE): Ein
    > Hauptspeicherzugriff dauert nicht 4 bis 8 Prozessortakte, sondern mehrere
    > hundert. Und OOE kann man auch nicht beliebig weit treiben, so dass eine
    > Vergrößerung der Latenz hiermit nicht zwangsweise abgefangen werden kann.
    > Einerseits sind die Reservation Stations und die Größe des out of order
    > windows (OOW) begrenzt (es können also nicht beliebig viele Befehle
    > zurückgestellt werden), andererseits steigt mit steigender Größe des OOW
    > auch die Wahrscheinlichkeit von Abhängigkeiten. Das ist also eine
    > Kosten-Nutzen-Abwägung.

    Wenn ich es noch im Kopf hab sind das 60 bis 90ns gewesen (was glaub ich 40 Takte wären), da gibts bei Tomshardware nen gutes Diagramm. Die Takte beziehen sich auf alles was nicht aus dem Register kommt. Denke das ist L1 (4 Takte) und L2(8 Takte) oder war L3 oder ich bin zu dumm. Ich mach zwar immer wieder mit Assembler und C auf Java rum, aber das macht man eh nur, wenn man schon alles im L1/L2/L3 drin liegen hat. Jedenfalls sind die 4 bis 8 Takte, die ich immer nutze, um die verschiedenen Varianten zu bewerten. Und diese mov Befehle platziere ich immer so, dass sie die nächsten Takte nicht gebraucht werden, was sie in der Regel so gut wie kostenfrei machen.

    Deine Zusammenfassung in Kompression in allen Ehren. :) Ich meine die Grunlegende Wertekompression für Bitmuster. Das gabs damals im Studium. Das hat nichts mit Huffman oder Zip oder was zu tun. Das Hautpeinsatzgebiet sind alle unsigned integers wie addressen, indexes, small values etc. Nimm zum Beispiel die chars, 16bit aber in der Regel oberste Byte ist zero. Und so geht das weiter. Diese Kompression läßt sich mit wenigen gattern umsetzen und verlängern eine pipline nur um einen Bruchteil eines Taktes. Ich kenne die NOP Gatter zur Signalverzögerung in modernen Chips nicht, aber sicherlich ist es weder ein Komplexitätsproblem noch eine Latenzgeschichte.

    Der Spass war einfach, dass dies umsonst kommt. Wie du schon beim Boost festgestellt hast, ein einfaches 64Byte register, ein bischen logik und du kommst vielleicht auf 40 zu übertragende Bytes, was dir sicherlich einige Takte spart.

    Die Frage ist nunmal einfach, läßt es sich parallelisieren und könntest du für die ganzen Gatter nicht etwas anderes machen. Vielleicht setzen die sowas auch einfach ein. Ich glaube der CodeCache (L1) hat auch eine gewisse compression für dieses leading zero Bits Problem.

    >
    > Und damit ein schönes Wochenende und danke für eure Geduld :)

  12. Re: Hat sich eigentlich die Compression beim Transfer durchgesetzt?

    Autor: HubertHans 28.08.16 - 07:43

    Kleine Schildkröte schrieb:
    --------------------------------------------------------------------------------
    > > Noch ein Wort zur Latenz und Out of Order Execution (OOE): Ein
    > > Hauptspeicherzugriff dauert nicht 4 bis 8 Prozessortakte, sondern
    > mehrere
    > > hundert. Und OOE kann man auch nicht beliebig weit treiben, so dass eine
    > > Vergrößerung der Latenz hiermit nicht zwangsweise abgefangen werden
    > kann.
    > > Einerseits sind die Reservation Stations und die Größe des out of order
    > > windows (OOW) begrenzt (es können also nicht beliebig viele Befehle
    > > zurückgestellt werden), andererseits steigt mit steigender Größe des OOW
    > > auch die Wahrscheinlichkeit von Abhängigkeiten. Das ist also eine
    > > Kosten-Nutzen-Abwägung.
    >
    > Wenn ich es noch im Kopf hab sind das 60 bis 90ns gewesen (was glaub ich 40
    > Takte wären), da gibts bei Tomshardware nen gutes Diagramm. Die Takte
    > beziehen sich auf alles was nicht aus dem Register kommt. Denke das ist L1
    > (4 Takte) und L2(8 Takte) oder war L3 oder ich bin zu dumm. Ich mach zwar
    > immer wieder mit Assembler und C auf Java rum, aber das macht man eh nur,
    > wenn man schon alles im L1/L2/L3 drin liegen hat. Jedenfalls sind die 4 bis
    > 8 Takte, die ich immer nutze, um die verschiedenen Varianten zu bewerten.
    > Und diese mov Befehle platziere ich immer so, dass sie die nächsten Takte
    > nicht gebraucht werden, was sie in der Regel so gut wie kostenfrei machen.
    >
    > Deine Zusammenfassung in Kompression in allen Ehren. :) Ich meine die
    > Grunlegende Wertekompression für Bitmuster. Das gabs damals im Studium. Das
    > hat nichts mit Huffman oder Zip oder was zu tun. Das Hautpeinsatzgebiet
    > sind alle unsigned integers wie addressen, indexes, small values etc. Nimm
    > zum Beispiel die chars, 16bit aber in der Regel oberste Byte ist zero. Und
    > so geht das weiter. Diese Kompression läßt sich mit wenigen gattern
    > umsetzen und verlängern eine pipline nur um einen Bruchteil eines Taktes.
    > Ich kenne die NOP Gatter zur Signalverzögerung in modernen Chips nicht,
    > aber sicherlich ist es weder ein Komplexitätsproblem noch eine
    > Latenzgeschichte.
    >
    > Der Spass war einfach, dass dies umsonst kommt. Wie du schon beim Boost
    > festgestellt hast, ein einfaches 64Byte register, ein bischen logik und du
    > kommst vielleicht auf 40 zu übertragende Bytes, was dir sicherlich einige
    > Takte spart.
    >
    > Die Frage ist nunmal einfach, läßt es sich parallelisieren und könntest du
    > für die ganzen Gatter nicht etwas anderes machen. Vielleicht setzen die
    > sowas auch einfach ein. Ich glaube der CodeCache (L1) hat auch eine gewisse
    > compression für dieses leading zero Bits Problem.
    >
    > >
    > > Und damit ein schönes Wochenende und danke für eure Geduld :)

    Du meinst Kodierungen.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Conergos, München
  2. Netze BW GmbH, Karlsruhe
  3. SEW-EURODRIVE GmbH & Co KG, Bruchsal
  4. EUROIMMUN AG, Dassow

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. täglich neue Deals bei Alternate.de
  2. 245,90€
  3. 294€


Haben wir etwas übersehen?

E-Mail an news@golem.de


5G-Report: Nicht jedes Land braucht zur Frequenzvergabe Auktionen
5G-Report
Nicht jedes Land braucht zur Frequenzvergabe Auktionen

Die umstrittene Versteigerung von 5G-Frequenzen durch die Bundesnetzagentur ist zu Ende. Die Debatte darüber, wie Funkspektrum verteilt werden soll, geht weiter. Wir haben uns die Praxis in anderen Ländern angeschaut.
Ein Bericht von Stefan Krempl

  1. Testlabor-Leiter 5G bringt durch "mehr Antennen weniger Strahlung"
  2. Sindelfingen Mercedes und Telefónica Deutschland errichten 5G-Netz
  3. iPhone-Modem Apple will Intels deutsches 5G-Team übernehmen

Doom Eternal angespielt: Die nächste Ballerorgie von id macht uns fix und fertig
Doom Eternal angespielt
Die nächste Ballerorgie von id macht uns fix und fertig

E3 2019 Extrem schnelle Action plus taktische Entscheidungen, dazu geniale Grafik und eine düstere Atmosphäre: Doom Eternal hat gegenüber dem erstklassigen Vorgänger zumindest beim Anspielen noch deutlich zugelegt.

  1. Sigil John Romero setzt Doom fort

Ocean Discovery X Prize: Autonome Fraunhofer-Roboter erforschen die Tiefsee
Ocean Discovery X Prize
Autonome Fraunhofer-Roboter erforschen die Tiefsee

Öffentliche Vergaberichtlinien und agile Arbeitsweise: Die Teilnahme am Ocean Discovery X Prize war nicht einfach für die Forscher des Fraunhofer Instituts IOSB. Deren autonome Tauchroboter zur Tiefseekartierung schafften es unter die besten fünf weltweit.
Ein Bericht von Werner Pluta

  1. JAB Code Bunter Barcode gegen Fälschungen