AMDs Bulldozer 50 Prozent schneller als Core i7? (Update)

Status
Für weitere Antworten geschlossen.
Du kannst die Ausführungseinheiten nicht besser auslasten ohne gleichzeitig auch alle anderen Pipelinestufen besser auszulasten, es sei denn du hattest zuvor dort einen Flaschenhals, den du durch verbreitern umgangen hast.
Alle anderen Pipelinestufen ganz sicher nicht. Wie auch immer, wovon du sprichst, nennt sich nicht SMT, sondern OoO. ;)

Bei SMT ändert sich nur der effektive Durchsatz, aber nicht der max. Durchsatz. Also verbessert man nur die Auslastung/Effizienz. Bei CMT erhöht man in erster Linie den max. Durchsatz, mögliche Effizienz-Steigerungen kommen optional noch dazu.
Der maximale Durchsatz ändert sich bei beidem, SMT und CMT. Der Unterschied ist einfach, dass der maximale Durchsatz bei CMT wesentlich mehr gesteigert wird aufgrund der zusätzlichen Ausführungseinheiten.

Bei CMT erhöht man in erster Linie den max. Durchsatz, mögliche Effizienz-Steigerungen kommen optional noch dazu.
Das gleiche gilt für SMT.

K10 hat jeweils 3 ALU/AGU, BD nur je 2. Das verringert erst einmal den max. Durchsatz.
Nein. Du hast anscheinend meine Aussage überhaupt nicht verstanden. Bulldozer darf man sich nicht so vorstellen, als ob man die 3 ALU/AGU Pärchen des K10 genommen hätte und eines davon einfach weggestrichen hätte. Nicht nur das Design hat sich diesbezüglich geändert, sondern anscheinend die Ausführungseinheiten ebenfalls, wenn man sich einige Patente dazu mal näher anschaut.


Es ist kein Fakt, da es noch keine entsprechen öffentlichen unabhängigen Benchmarks gibt. Multithreading schneller zu sein mit 8 vs. 6 Int-Cores ist klar.
Wieso soll das klar sein? Es sind pro Modul nur 4 Issue Ports gegenüber 6 bei einem Intel Kern. Also mit weniger erreicht man mehr.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Also mit weniger erreicht man mehr.

Und das hast du bei welchem Test heraus gefunden?
Spekulationen, Marketingaussagen oder irgendwelche Blogs mal ausgenommen :d
Fakt ist du weißt es nicht, ich weiß es nicht.... ausser ein paar Leuten bei AMD und irgendwelchen Herstellern weiß noch keiner was von der Leistung.
 
Also mal ganz primitiv erklärt und vermutet vielleicht auch fehler drin aber nur vielleicht :)

die module von bulldozer basieren auf k8 es werden 2 ca. le-1660 kerne zusammengeschlossen mit grösserem cache und einer wird um seinen cache kastriert. hiermit möchte man staus in der datenverarbeitung umgehen.

Da man mehrere module in gewisser weise verknoten kann lassen sich die arbeitsschritte besser parralelisieren. einfacher zu konstuieren wie auch in oder für die fab computererstellte die`s entworfen werden. günstiger
Intel macht dies durch die nativen einzelnen kerne per hand entworfen.

so jetz interpretierte vermutung
Dazu kommt das die floating points durch implementierung grössere Datenmengen bearbeiten können wie seid kurzem sandy bridge auch.

bulldozer hat soweit ich weiss unbestätigt noch eine weitere implementierung die die parralelisierung der software für die kerne unterstützt was intel erst mit ivy unterstützen wird und nicht in selber form, dies spielt auch eine rolle für die erste implementierung
welche hier sinnvoller ist, ist unsicher, wobei diese sich nur bei der einfachheit der paralelisierung für die kerne bzw die komplexität der kerne? unterscheiden.
das sind so die grössten punkte die mir bei kurz oberflächlicher betrachtung aufgefallen sind:grrr:

eine genaue erklärung der architekturen spar ich euch ma :) wobei es echt noch viel zu erklären gäbe wovon ich mehr ahnung hab :-[

fakt ist beide haben das handwerk silizium drauf.:drool:
media markt - saturn?:motz:
beide bauen sehr gute prozessoren:love:
und ich kann mir im moment nicht vorstellen für was 99% der pc besitzer mit der power einer performance zum teil mainstream cpu in den nächsten jahren anfangen soll.:hail:

so und jetz bitte kritik ausüben :fresse2:
:wink:
 
nein, BD basiert eben _nicht_ auf dem K8.
 
ich sehe auf diesem Bild nur 4 Kerne, Core 1&2 ist ein Kern, der Rest ist marketing
dd008906377250d02d1457ab730611b1.jpg
 
ok :) hät ich mal vermutet wegen der die grösse und dacht das mal wo aufgeschnappt zu haben
modul 213mill
loma oder wie der kern heisst irgendwo um 115mio *2 -cache + grösserem cache :) und natürlich die implementierungen irgendwo aus k10, das meinste warscheinlich mit nich k8 oder?
ich denk das hab ich dann mit dem llano verwechselt da man mit 4 dieser module ja auch ned auf die 1,6mrd kommt...

das du die kerne nicht so gut erkennst liegt daran das die nicht handerstellt sondern computersimuliert wurden somit liegen die einzelnen bereiche nicht klar abgrenzbar und unterscheiden sich vermutlich etwas je nach anordnung des kerns...


und ob man heutzutage noch marketing machen würde mit einem 1,6mrd 4kerner :) da würde die tdp gegenüber einem oktacore bei gleicher leistung um das doppelte steigen ;)
 
Zuletzt bearbeitet:
Das Marketing bezeichnet den K8 in 45nm als K10, beide sind vom Design ähnlich.
 
Und bevor die Zählerei der Kerne jetzt wieder los geht, sollte man sich in einem separaten Thread erstmal ganz grundsätzlich darüber einig werden, was ein Kern denn überhaupt ist und was man demzufolge dann zählen muss. Rechtecke auf die shots, vom Windows angezeigte Kerne, integer cores...
 
Haltet euch ans Thema, dann müssen wir nicht dauernd eingreifen...
 
Alle anderen Pipelinestufen ganz sicher nicht. Wie auch immer, wovon du sprichst, nennt sich nicht SMT, sondern OoO. ;)

Öhmm, nein. Wie kommst du auf OoO? Wovon ich spreche ist Pipelining und davon, dass SMT nicht auf wundersame Weise die Ausführungseinheiten besser auslastet ohne die übrigen Pipelinestufen auch stärker auszulasten. Das SMT nur dazu gedacht ist die Auslastung der Pipeline zu erhöhen erkennt man daran, dass keine Pipelinestufe Durchsatz-mäßig erweitert wurde.

Der maximale Durchsatz ändert sich bei beidem, SMT und CMT.

Nein, bei SMT nicht.

Nein. Du hast anscheinend meine Aussage überhaupt nicht verstanden. Bulldozer darf man sich nicht so vorstellen, als ob man die 3 ALU/AGU Pärchen des K10 genommen hätte und eines davon einfach weggestrichen hätte. Nicht nur das Design hat sich diesbezüglich geändert, sondern anscheinend die Ausführungseinheiten ebenfalls, wenn man sich einige Patente dazu mal näher anschaut.

Sagt ja auch keiner, aber solange die neuen ALU/AGUs nicht plötzlich double-pumped sind oder sonst auf irgendeine wundersame Weise mehrere Ops/Takt ausführen können, ändert das nichts an meiner Aussage. Die von dir erwähnten Änderungen betreffen einzig und allein die Auslastung der Einheiten.
 
Wie kommst du auf OoO? Wovon ich spreche ist Pipelining
Und was glaubst du, ist die Basis für maximales Pipelining? :rolleyes: Genau, OoO.

und davon, dass SMT nicht auf wundersame Weise die Ausführungseinheiten besser auslastet ohne die übrigen Pipelinestufen auch stärker auszulasten.
Nicht anders als CMT auch.

Das SMT nur dazu gedacht ist die Auslastung der Pipeline zu erhöhen erkennt man daran, dass keine Pipelinestufe Durchsatz-mäßig erweitert wurde.
Falsch und falsch. SMT dient dazu, die Ausführungseinheien besser auszulasten, nicht die Pipeline generell. Und dabei wird auch der Durchsatz bei bestimmten Einheiten aufgebohrt.

Nein, bei SMT nicht.
Doch, auch bei SMT. Wobei das natürlich auch vom jeweiligen Design abhängt.

oder sonst auf irgendeine wundersame Weise mehrere Ops/Takt ausführen können
Entsprechend einiger Patente könnte genau das der Fall sein. Und wundersam ist daran gar nichts.
 
@mr.dude Ich geb's auf. Anfangs dachte ich, dass wir uns einfach nur falsch verstehen, aber mittlerweile bin ich mir sicher, dass du einige grundlegende Techniken und deren Zweck entweder nicht verstehst oder ein ziemlich verzehrtes Bild davon hast. Da das sowieso mittlerweile sehr Offtopic war, sollten wir es einfach gut sein lassen. Jeder geht davon aus, dass der andere kA hat und schweigt dazu :shot:
 
Anfangs dachte ich, dass wir uns einfach nur falsch verstehen, aber mittlerweile bin ich mir sicher, dass du einige grundlegende Techniken und deren Zweck entweder nicht verstehst oder ein ziemlich verzehrtes Bild davon hast.
Tut mir leid das zu sagen, aber da hast du ein grundlegend verzerrtes Bild von der Faktenlage. ;) Ansonsten, ja, guter Vorschlag, dass du es gut sein lässt.
 
Zitat von y33H@
Es ist kein Fakt, da es noch keine entsprechen öffentlichen unabhängigen Benchmarks gibt. Multithreading schneller zu sein mit 8 vs. 6 Int-Cores ist klar.
Wieso soll das klar sein? Es sind pro Modul nur 4 Issue Ports gegenüber 6 bei einem Intel Kern. Also mit weniger erreicht man mehr.
Hmm sicher ?

Falls Du Dich auf die RWT Aussage hier berufen solltest:
This article describes in detail the architecture and pipeline of the Bulldozer core a 64 bit, 4 issue super-scalar, out-of-order MPU with 48 bit virtual and physical addressing.
Das gilt nur für 1 Cluster des Moduls. Ist ne kleine Schwäche des Artikels, dass das Modul einfach um den 2ten INT Cluster amputiert wird und das einfach ignoriert wird. Aber immerhin steht auch mal drin:
While AMD did not disclose how the microcode works, they did imply that the microcode will at least maintain the same performance as in prior generations (i.e. emitting at least 3 macro-operations per cycle).
Given that it is shared between two four-issue cores
Von den Patenten her muss man fast mit 8issue pro Modul rechnen:
3mtarvan.png

4xINT, je 2 pro Cluster und 4xFP.
Die 2pro Cluster reichen, sind ja MacroOps, die AGU Ops sind also eingepackt.

Abschließende Frage, wo zählst Du bei Intel 6issue ? Der hat auch nur 3 bzw. 4, Zitat aus RWTs Sandy Artikel:
This article will explore the microarchitecture of Sandy Bridge – a 64-bit, quad-core, dual threaded, 4 issue, out-of-order microprocessor with the new 3 and 4 operand AVX instruction set extension, implemented in Intel’s 32nm process.
Edit:
Ah vielleicht das:
Once uops have been allocated and renamed, they can freely execute out-of-order. Sandy Bridge uses a unified scheduler that is dynamically shared between threads, like Nehalem, but nearly twice the capacity. This has the advantage of allowing a more flexible mix of instructions to execute efficiently compared to distributed schedulers. Renamed uops are entered into the 54 entry unified scheduler, where they wait until they are ready to execute. When a uop is ready, it will be issued to the appropriate execution units. Like Nehalem, Sandy Bridge can issue up to 6 uops to different ports and retire 4 uops per cycle.
Da muss man genau und fein lesen, bei AMD steht nur immer "4issue" dran, bei Intel steht "can issue up to 6 µOps."

Bei AMD unterschlägt man stillschweigend die SpeicherOps, die bei Intel getrennt laufen und mitgezählt werden. Genau gesagt hat BD hat ein 4 MacroOp issue, Intel ein 6 µOp issue. Eine MacroOp kann eine SpeicherOp dabei haben, ergo müßte man da für den Maximalfall wieder 4x2=8 gegen 6 aufrechnen.

ciao

Alex
 
Zuletzt bearbeitet:
Hmm sicher ?

Falls Du Dich auf die RWT Aussage hier berufen solltest ...
Nein, tue ich nicht. Keine Sorge, das war nur eine ironische Bemerkung zu y33H@s wieder mal stupider Integer Cluster Zählerei. Ich hätte wohl doch noch das Rolleys-Smilie hinmachen sollen.

Ich beziehe mich auf die Patente. Dort werden für einen Integer Cluster zwei Issue Slots angegeben. Und offenbar gibt es Leute, die das genau so sehen im Vergleich zu zB K10. Man sollte das aber nicht zu genau nehmen. Erstens kann die letztendliche Implementierung auch eine andere sein. Und zweitens sind die Ausführungseinheiten sowieso deutlich komplexer und letztendlich nur Ergebnis der Pipeline davor. Also ja, es müssen natürlich Ports für mindestens 4 µOps pro Integer Cluster vorhanden sein, also 8 pro Modul. ;) Alles andere ist Unfug. Womöglich sind es sogar mehr. Da war doch mal was, dass eine AGU auch Teile der Logik der ALU nutzen kann. Bin mir allerdings nicht mehr ganz sicher, wo ich das gelesen hatte. Vorstellbar wäre daher sogar, dass eine ALU einen Port besitzt und eine AGU zwei, also 6 Ports pro Integer Cluster, 12 Ports pro Modul.

Der Punkt war einfach, wer nur stupide irgendwelche funktionalen Einheiten zählt, hat keinen Plan. So einfach ist es eben nicht, ohne die genaue Funktionsweise zu kennen.

Abschließende Frage, wo zählst Du bei Intel 6issue ?
Alle zusammen natürlich, also ALU + Load/Store. Das Problem bei einigen Leuten ist anscheinend, dass sie das nicht auseinander halten können. Bei AMD ist praktisch eine AGU immer an eine ALU gekoppelt, was letztendlich trotzdem mindestens 2-issue bedeutet. Bei Intel sind ALU und Load/Store mehr entkoppelt. Wobei, wie schon erwähnt, ALU und AGU bei Bulldozer auch deutlich entkoppelter arbeiten als noch bei K10.
 
Nein, tue ich nicht. Keine Sorge, das war nur eine ironische Bemerkung zu y33H@s wieder mal stupider Integer Cluster Zählerei. Ich hätte wohl doch noch das Rolleys-Smilie hinmachen sollen.
Lol achso. Alles klar.

Ich beziehe mich auf die Patente. Dort werden für einen Integer Cluster zwei Issue Slots angegeben.
Hmm echt ? Verwechselst Du da nicht was mit der Dispacht Banbreite pro Cluster ?
Seit man das Bildchen hier hat:
amd_bulldozer_integerebmtt.png


Oder auch schon das zuvor, ist klar, dass es pro Cluster 4xissue gibt, insgesamt 12, wenn man die FPU auch noch mitzählt. Issue bezieht sich ja auf die Befehle, die der Scheduler pro Takt weiterleiten kann.
Rein gehen aber vermutlich nur je 2 Leitungen, das reicht, da es ja dicke MacroOps sind, die aus dem Dispatcher kommen.


Und offenbar gibt es Leute, die das genau so sehen im Vergleich zu zB K10. Man sollte das aber nicht zu genau nehmen. Erstens kann die letztendliche Implementierung auch eine andere sein. Und zweitens sind die Ausführungseinheiten sowieso deutlich komplexer und letztendlich nur Ergebnis der Pipeline davor. Also ja, es müssen natürlich Ports für mindestens 4 µOps pro Integer Cluster vorhanden sein, also 8 pro Modul.
Na wie schon gesagt, wenn man das gesamte Modul nimmt, dann hat man "dank" FPU 12 ;-)

Womöglich sind es sogar mehr. Da war doch mal was, dass eine AGU auch Teile der Logik der ALU nutzen kann. Bin mir allerdings nicht mehr ganz sicher, wo ich das gelesen hatte. Vorstellbar wäre daher sogar, dass eine ALU einen Port besitzt und eine AGU zwei, also 6 Ports pro Integer Cluster, 12 Ports pro Modul.
HMm, also da gabs die Hybrid Geschichte, und dann die Story, dass die AGU ein paar rudimentäre ALU Befehle kann, das war LEA. Die Hybridteile sind laut obigen Bildchen Geschichte, und das LEA Teil ist nicht neu, das kann K8/10 auch schon.
Der Punkt war einfach, wer nur stupide irgendwelche funktionalen Einheiten zählt, hat keinen Plan. So einfach ist es eben nicht, ohne die genaue Funktionsweise zu kennen.
Jo, aber irgendwas muss man halt machen. "Dank" der Modulbauweise wird das jetzt so oder so lustig, Vergleiche können da nur grob sein, da es eben ein Äpfel-Birnen Vergleich ist, den man nicht ändern kann.

Alle zusammen natürlich, also ALU + Load/Store. Das Problem bei einigen Leuten ist anscheinend, dass sie das nicht auseinander halten können. Bei AMD ist praktisch eine AGU immer an eine ALU gekoppelt, was letztendlich trotzdem mindestens 2-issue bedeutet. Bei Intel sind ALU und Load/Store mehr entkoppelt. Wobei, wie schon erwähnt, ALU und AGU bei Bulldozer auch deutlich entkoppelter arbeiten als noch bei K10.
Jo, passt dann schon, das hatte ich dann schon richtig verstanden.
Wobei ich jetzt nicht genau sicher bin, was Du mit dem "gekoppelt" meinst.
Da ändert sich doch nichts. Nach einem INT Scheduler kommen 4 µOps raus, 2ALU/2AGU, da passiert nicht viel, die Hybridteile gibts wie besagt nicht.

ciao

Alex
 
Zuletzt bearbeitet:
Na wie schon gesagt, wenn man das gesamte Modul nimmt, dann hat man "dank" FPU 12
Jup, mit FPU sind es natürlich mehr. Ich hatte mich jetzt nur auf die Integer Ressourcen bezogen.

Die Hybridteile sind laut obigen Bildchen Geschichte
Soweit würde ich noch nicht gehen. Das lässt sich aus dem Bild nicht ableiten.

Wobei ich jetzt nicht genau sicher bin, was Du mit dem "gekoppelt" meinst.
Da ändert sich doch nichts.
Doch. Das hatte ich schon zuvor geschrieben. Die AGUs sind in Bulldozer jetzt vollständig OoO. Dh, ALUs und AGUs können flexibler arbeiten.
 
Soweit würde ich noch nicht gehen. Das lässt sich aus dem Bild nicht ableiten.
Hmm, naja aus dem einzelnen vielleicht nicht, aber zuvor stand ja im ähnlichen,älteren Schema "pipeline, piepeline, pipl.pipl." drin. Im obigen Schema dann genauer spezifizert auf 2xALU & 2xAGU. MMn spricht das für den festen 2x2 Aufbau. 100% Sicherheit hat man erst am Ende, wenn BD kommt, aber das gezeigte hat für mich mind. 95% ;-)
Wo sollen auch die Daten für die Hybridteile herkommen ? Vorteil von den Teilen wäre, dass man 4xALUs oder 4xAGU rechnen könnte, aber um das sinnvoll nutzen zu können, bräuchte es nen besseren Dispatcher Anschluss.
Da kommen ja auch in den Patenten nur 2 Leitungen pro INT CLuster an, hatte ich ja oben schon geschrieben. Das reicht mit 2xMacroOps genau fürs 2x2 Setup, da eine MacroOp aus 1xALU und 1xAGU µOp bestehen kann. Aber 4x0, oder 0x4 bekommt man damit nicht gesättigt.
Also wozu der Aufwand ?
Doch. Das hatte ich schon zuvor geschrieben. Die AGUs sind in Bulldozer jetzt vollständig OoO. Dh, ALUs und AGUs können flexibler arbeiten.
Hmm meinst Du vielleicht den unified Scheduler ? Dann ok, ansonsten bitte Link aufs betreffende Posting, eure Flames las ich mir nicht durch ^^
 
Zuletzt bearbeitet:
Hmm meinst Du vielleicht den unified Scheduler ?
Nein, ich meine nicht nur den Scheduler. Ich rede vor allem von dem, was danach kommt, also den Integer Pipes und Ausführungseinheiten.

Beim K8/K10 sah das noch wie folgt aus:
The integer execution pipeline consists of three identical pipes (0, 1, and 2). Each integer pipe consists of an arithmetic-logic unit (ALU) and an address generation unit (AGU).
Also 3 Pipes und am Ende jeder hängen jeweils eine ALU und eine AGU. Dh, der Scheduler muss immer ein entsprechendes Paket aus 2 µOps schnüren, die vom ALU/AGU Pärchen verarbeitet werden. Das ist natürlich nicht immer optimal lösbar. Dann hast du dort im schlimmsten Fall nur 3 µOps pro Takt maximal.

Bei Bulldozer sind es nun 4 Integer Pipes. An zwei Pipes hängt jeweils eine ALU und an den anderen beiden jeweils eine AGU. Der Scheduler kann also flexibler die µOps verteilen.
 
Zuletzt bearbeitet:
Nein, ich meine nicht nur den Scheduler. Ich rede vor allem von dem, was danach kommt, also den Integer Pipes und Ausführungseinheiten.

Beim K8/K10 sah das noch wie folgt aus:

Also 3 Pipes und am Ende jeder hängen jeweils eine ALU und eine AGU. Dh, der Scheduler muss immer ein entsprechendes Paket aus 2 µOps schnüren, die vom ALU/AGU Pärchen verarbeitet werden. Das ist natürlich nicht immer optimal lösbar. Dann hast du dort im schlimmsten Fall nur 3 µOps pro Takt maximal.

Bei Bulldozer sind es nun 4 Integer Pipes. An zwei Pipes hängt jeweils eine ALU und an den anderen beiden jeweils eine AGU. Der Scheduler kann also flexibler die µOps verteilen.
Hmm, also ich seh da jetzt immer noch nicht den großen Unterschied. Die Pipes hängen ja eben genau da, da es den unified Sched. gibt.

Vorher beim K8/10 gabs 3 Scheduler (keine "Pipes"), für jedes ALGU Paar einen, jetzt nur einen für die 2 Paare, wobei es aber eben keine Paare mehr sind, sondern einfach 2 ALUs und 2 AGUs. Weils es nur noch einen einzigen Scheduler gibt, gibts keine Pärchen mehr. Das eine bedingt das andere. Und ja, das ist flexibler. Früher konnte es vorkommen, dass die ALGU besetzt war, und eine MacroOp warten mußte, obwohl auf den anderen 2 Pärchen was frei gewesen wäre, das passiert jetzt nicht mehr. Wahrscheinlich sind die 4 flexiblen Pipes manchmal schneller als die starren 3x2 zuvor ^^

ciao

Alex

P.S:
Dh, der Scheduler muss immer ein entsprechendes Paket aus 2 µOps schnüren, die vom ALU/AGU Pärchen verarbeitet werden
Pakete im Sinne, dass die ALU und AGU Op zusammge hören mußten, gabs da nicht, es konnten pro einfach Takt 1xAGU und 1x ALU µOp weitergeleitet werden, die beiden Ops haben aber oft nichts miteinander zu tun. Ist auch logisch, denn wenn ne ALU Op mit Speicherzugriff berechnet wird, sollte die Adresse bereits da sein ;-)
 
Zuletzt bearbeitet:
Vorher beim K8/10 gabs 3 Scheduler (keine "Pipes"), für jedes ALGU Paar einen, jetzt nur einen für die 2 Paare
Ja, das kommt noch hinzu, was ebenfalls die Flexibilität erhöhen sollte. Aber das war nicht das, was ich meinte.

Pakete im Sinne, dass die ALU und AGU Op zusammge hören mußten, gabs da nicht
Das hat auch keiner behauptet. Soweit ich weiss konnten aber nur die µOps der selben Operation OoO ausgeführt werden.
 
Zuletzt bearbeitet:
Ja, MacroOp wäre hier wohl unmissverständlicher gewesen.
 
Hmm irgendwie net, naja wollte nur freundlich sein..
 
Four AMD Bulldozer Chips Incoming: Details Revealed.

Das lese ich schon seit Monaten auf diversen Seiten. Nur ist weit und breit kein BD zu sehen.
 
Status
Für weitere Antworten geschlossen.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh