Hardware-Tutorial oder Was macht diese Kiste mit meinem Code

Übersicht

Sonstiges

Smalltalk

Gehe zu Seite Zurück 1, 2

	feider ehemals "Decelion"	Do, Jun 06, 2013 7:34 Antworten mit Zitat
Graphikkarten haben teilweise bis zu 1000 verschiedene Compute Units mit einer Taktung von 500-1000 MHz. Da nicht alles parallelisierbar ist, gibt es aber nach wie vor serielle Probleme - und dafür sind dann Prozessoren mit 2-4 GHz natürlich besser geeignet.

feider

ehemals "Decelion"

Do, Jun 06, 2013 7:34
Antworten mit Zitat

Graphikkarten haben teilweise bis zu 1000 verschiedene Compute Units mit einer Taktung von 500-1000 MHz. Da nicht alles parallelisierbar ist, gibt es aber nach wie vor serielle Probleme - und dafür sind dann Prozessoren mit 2-4 GHz natürlich besser geeignet.

	tft	Do, Jun 06, 2013 9:27 Antworten mit Zitat
Hallo DAK, ich finde es ebenfals toll das du dich mal an die Basics der PC Technik verständlich rannmachst. Ich kenne das zwar alles schon, aber die Sache mit den Treibern würde mich auch interesieren. Ich habe früher für den C64 und den Amiga welche in ASM gemacht. Hauptsächlich für Externe Hardware die sonst nirgends zu haben war. Aber das ging nur mit Guten bis sehr guten Hardware kenntnissen. Heutzutage gibt es zu fiele verschiedene Schnittstellen und die Technik ist was die Buss Systeme angeht ja schon lange anders konzipiert. Freu mich drauf falls da mal was in dieser Richtung kommt. Gruss TFT
TFT https://www.sourcemagic.ch Monkey,HTML5,CSS3,W 10 64 Bit, 32 GB Ram, GTX Titan, W8 ist Müll !!!!!!

tft

Do, Jun 06, 2013 9:27
Antworten mit Zitat

Hallo DAK,

ich finde es ebenfals toll das du dich mal an die Basics der PC Technik verständlich rannmachst. Ich kenne das zwar alles schon, aber die Sache mit den Treibern würde mich auch interesieren. Ich habe früher für den C64 und den Amiga welche in ASM gemacht. Hauptsächlich für Externe Hardware die sonst nirgends zu haben war. Aber das ging nur mit Guten bis sehr guten Hardware kenntnissen. Heutzutage gibt es zu fiele verschiedene Schnittstellen und die Technik ist was die Buss Systeme angeht ja schon lange anders konzipiert. Freu mich drauf falls da mal was in dieser Richtung kommt.

Gruss TFT

TFT
https://www.sourcemagic.ch
Monkey,HTML5,CSS3,W 10 64 Bit, 32 GB Ram, GTX Titan, W8 ist Müll !!!!!!

	DAK	Do, Jun 06, 2013 12:04 Antworten mit Zitat
Danke für das viele Lob, freut mich sehr. @Treiber: Werden noch kommen, sobald ich mit dem Tutorial an die passende Stelle komm. @CUDA: Das erklär ich besser hier direkt, weil es wohl den Ramen des Tutorials sprengen würde. Eine Grafikkarte besteht ja im Grunde aus sehr vielen sehr schwachen Prozessoren. Im Grunde sind sie das Muticore-Konzept auf die Spitze getrieben. Das bedeutet, dass sie, alle zusammen, sehr schnell sind, aber jeder Prozessor alleine echt schlecht ist. Das heißt, alles, was sie zusammen machen können geht gut, alles was nur allein gemacht werden kann ist aber langsam. Kleines Beispiel dazu. Aufgabe: Durchsuche einen riesigen Satz Daten nach einem Wert. Sind diese Daten in einem Array gespeichert, dann lässt sich das super in kleine, unabhängige Aufgaben zerteilen, da jeder Bereich des Arrays unabhängig von den Anderen angesprochen werden kann. Man sagt dann einfach Prozessor 1, durchsuche die Arrayfelder 0-99, Prozessor 2 durchsuche 100-199 und so weiter. Kann man perfekt in gleich große Teile zerlegen und es wird recht schnell fertig sein. Sind diese Dateien aber in einer LinkedList gespeichert, dann schaut das anders aus. Die LinkedList-Datenstruktur ist ja so aufgebaut, das jedes Element auf das Nächste in der Kette verweist. Man kann nicht einfach irgendwo in der Mitte oder bei Element 100 beginnen, sondern man muss sich vom Anfang durch die Kette hangeln, bis man an die passende Stelle kommt. Ohne Sonderkonstrukte ist so eine Suche durch eine LinkedList nicht parallelisierbar, man könnte also nur einen Prozessor verwenden und die Suche wäre extrem langsam. Jetzt könne man sagen, okay, machen wir doch einen oder zwei Prozessoren auf der Grafikkarte anders als alle anderen, bauen wir da einen extrem schnellen Prozessor ein, um mit solchen Aufgaben klar zu kommen, und den Rest der Prozessoren lassen wir klein, um mit den parallelisierbaren Aufgaben klar zu kommen. Und dann bist du im Endeffekt wieder genau bei dem, was man heutzutage hat: Einen bis vier echt schnelle Kerne (CPU) und ein Haufen schwacher Kerne in der GPU für alles parallelisierbare. Edit: Kapitel 6 über Grafikkarten ist drin. Das Nächste was kommt, sind Treiber, dann USB.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Do, Jun 06, 2013 12:04
Antworten mit Zitat

Danke für das viele Lob, freut mich sehr.

@Treiber: Werden noch kommen, sobald ich mit dem Tutorial an die passende Stelle komm.

@CUDA: Das erklär ich besser hier direkt, weil es wohl den Ramen des Tutorials sprengen würde.

Eine Grafikkarte besteht ja im Grunde aus sehr vielen sehr schwachen Prozessoren. Im Grunde sind sie das Muticore-Konzept auf die Spitze getrieben.
Das bedeutet, dass sie, alle zusammen, sehr schnell sind, aber jeder Prozessor alleine echt schlecht ist.
Das heißt, alles, was sie zusammen machen können geht gut, alles was nur allein gemacht werden kann ist aber langsam.

Kleines Beispiel dazu. Aufgabe: Durchsuche einen riesigen Satz Daten nach einem Wert.
Sind diese Daten in einem Array gespeichert, dann lässt sich das super in kleine, unabhängige Aufgaben zerteilen, da jeder Bereich des Arrays unabhängig von den Anderen angesprochen werden kann. Man sagt dann einfach Prozessor 1, durchsuche die Arrayfelder 0-99, Prozessor 2 durchsuche 100-199 und so weiter. Kann man perfekt in gleich große Teile zerlegen und es wird recht schnell fertig sein.

Sind diese Dateien aber in einer LinkedList gespeichert, dann schaut das anders aus. Die LinkedList-Datenstruktur ist ja so aufgebaut, das jedes Element auf das Nächste in der Kette verweist. Man kann nicht einfach irgendwo in der Mitte oder bei Element 100 beginnen, sondern man muss sich vom Anfang durch die Kette hangeln, bis man an die passende Stelle kommt. Ohne Sonderkonstrukte ist so eine Suche durch eine LinkedList nicht parallelisierbar, man könnte also nur einen Prozessor verwenden und die Suche wäre extrem langsam.

Jetzt könne man sagen, okay, machen wir doch einen oder zwei Prozessoren auf der Grafikkarte anders als alle anderen, bauen wir da einen extrem schnellen Prozessor ein, um mit solchen Aufgaben klar zu kommen, und den Rest der Prozessoren lassen wir klein, um mit den parallelisierbaren Aufgaben klar zu kommen. Und dann bist du im Endeffekt wieder genau bei dem, was man heutzutage hat: Einen bis vier echt schnelle Kerne (CPU) und ein Haufen schwacher Kerne in der GPU für alles parallelisierbare.

Edit: Kapitel 6 über Grafikkarten ist drin. Das Nächste was kommt, sind Treiber, dann USB.

Gewinner der 6. und der 68. BlitzCodeCompo

	DAK	Fr, Jun 07, 2013 19:32 Antworten mit Zitat
Sodale, hab wieder viel geschrieben. Diesmal über Treiber und USB. Hoffe es freut.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Fr, Jun 07, 2013 19:32
Antworten mit Zitat

Sodale, hab wieder viel geschrieben. Diesmal über Treiber und USB. Hoffe es freut.

Gewinner der 6. und der 68. BlitzCodeCompo

	Kruemelator	Fr, Jun 07, 2013 20:13 Antworten mit Zitat
Deine Ausführung fast das Grundverständnis, welches eigendlich jeder haben sollte, gut zusammen. Was mit aber ins Auegesprungen ist war das du geschreiben hast: "CPU [...] in ihrem Funktionsumfang beschränkt" Nach meinem Wissen ist die CPU mächtiger als eine GPU, z.B. könnte man mit der GPU nicht auf den Arbeitsspeicher zugreife, CPU aber umgekehrt auf Grafikkartenspeicher.

Kruemelator

Fr, Jun 07, 2013 20:13
Antworten mit Zitat

Deine Ausführung fast das Grundverständnis, welches eigendlich jeder haben sollte, gut zusammen.
Was mit aber ins Auegesprungen ist war das du geschreiben hast:

"CPU [...] in ihrem Funktionsumfang beschränkt"

Nach meinem Wissen ist die CPU mächtiger als eine GPU, z.B. könnte man mit der GPU nicht auf den Arbeitsspeicher zugreife, CPU aber umgekehrt auf Grafikkartenspeicher.

	DAK	Fr, Jun 07, 2013 20:21 Antworten mit Zitat
Generell gesehen wäre die CPU vielleicht mächtiger als die GPU, wenn es aber zu Grafikbefehlen kommt, dann nicht. So, ja, die Grafikkarte kann nur auf ihren eigenen Speicher zugreifen und könnte z.B. nicht auf USB zugreifen, aber dafür hat sie Hardwarebeschleunigung für die ganzen Grafikeffekte. Als Beispiel, das Dreiecksfüllen (das schafft eine moderne CPU auch ohne Probleme, aber ich nehm es nur mal als Beispiel). Um mit der CPU ein Dreieck zu füllen musst du erst mal eine Funktion schreiben, die das Dreiecksfüllen auf den Befehlssatz der CPU zurück führt (so im Grunde, du schreibst in deiner Programmiersprache einen Dreiecksfüll-Algorithmus). Der braucht dann ein paar hundert Prozessorzyklen (je nach der Größe des Dreiecks) und schafft dann, das Dreieck wie gewünscht zu füllen. Die Grafikkarte hat den Befehl in Hardware eingebaut. Ein Takt und fertig. Weißt du, was ich meine? Was Grafikbefehle an geht, ist die CPU auch deswegen beschränkt, weil sehr viele Effekte, die eine zeitgemäße Grafikkarte ohne Probleme packt, mit CPU-Rendering mehrere Sekunden statt ein paar Millisekunden brauchen, und somit für Echtzeitanwendungen nicht möglich sind. Edit: Ein Beispiel dazu findet sich hier. Da geht es um Video Rendering. Für das 2:30 Minuten lange Video braucht die CPU in dem Beispiel knapp unter 10 Minuten zum Rendern. Die GPU macht das in ziemlich genau 2 Minuten. Wenn die Aufgabe ist, dass das Video live gerendert werden muss (wie z.B. bei Internet-Videotelefonie), dann kann das nicht von der CPU gemacht werden. Somit ist die CPU im Vergleich zur GPU was live-Videorendering angeht, etwas beschränkter.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Fr, Jun 07, 2013 20:21
Antworten mit Zitat

Generell gesehen wäre die CPU vielleicht mächtiger als die GPU, wenn es aber zu Grafikbefehlen kommt, dann nicht.

So, ja, die Grafikkarte kann nur auf ihren eigenen Speicher zugreifen und könnte z.B. nicht auf USB zugreifen, aber dafür hat sie Hardwarebeschleunigung für die ganzen Grafikeffekte.

Als Beispiel, das Dreiecksfüllen (das schafft eine moderne CPU auch ohne Probleme, aber ich nehm es nur mal als Beispiel).
Um mit der CPU ein Dreieck zu füllen musst du erst mal eine Funktion schreiben, die das Dreiecksfüllen auf den Befehlssatz der CPU zurück führt (so im Grunde, du schreibst in deiner Programmiersprache einen Dreiecksfüll-Algorithmus). Der braucht dann ein paar hundert Prozessorzyklen (je nach der Größe des Dreiecks) und schafft dann, das Dreieck wie gewünscht zu füllen.

Die Grafikkarte hat den Befehl in Hardware eingebaut. Ein Takt und fertig.

Weißt du, was ich meine?

Was Grafikbefehle an geht, ist die CPU auch deswegen beschränkt, weil sehr viele Effekte, die eine zeitgemäße Grafikkarte ohne Probleme packt, mit CPU-Rendering mehrere Sekunden statt ein paar Millisekunden brauchen, und somit für Echtzeitanwendungen nicht möglich sind.

Edit: Ein Beispiel dazu findet sich hier. Da geht es um Video Rendering. Für das 2:30 Minuten lange Video braucht die CPU in dem Beispiel knapp unter 10 Minuten zum Rendern. Die GPU macht das in ziemlich genau 2 Minuten. Wenn die Aufgabe ist, dass das Video live gerendert werden muss (wie z.B. bei Internet-Videotelefonie), dann kann das nicht von der CPU gemacht werden. Somit ist die CPU im Vergleich zur GPU was live-Videorendering angeht, etwas beschränkter.

Gewinner der 6. und der 68. BlitzCodeCompo

	PhillipK	So, Jun 09, 2013 15:58 Antworten mit Zitat
Ist ja auch ein ziemlich bescheuerter vergleich. Wenn man einen Künstler nimmt und ihm sagt, er soll n haus bauen, dann kann ers wohl nicht. Wohl aber kann der bauarbeiter, der das haus bauen könnte, ein bisschen kritzeln. Die geschwindigkeit und qualität unterscheidet sich einfach extrem. Meiner meinung nach kann man nicht grundlegend behaupten, das eine CPU besser als eine GPU ist oder umgekehrt. Es ist nunmal so, das alles eine entwickelung durchmacht. Hätten sich damals ein paar schlaue typen überlegtt, die CPU mit grafikbeschleunigung auszustatten und ihre momentanen aufgaben nicht zu vernachlässigen, sähe das auch ganz anders aus. Oder ein anderes beispiel: Hat man einen arbeiter, der extrem schnell ne wand anmalen kann und dagegen 4 arbeiter, die pro wand doppelt so lange brauchen, aber jeder ne wand machen kann, sind die 4 arbeiter überlegen. Für die einzelne aufgabe brauchen sie länger, für alles zusammen teilen sie sich die arbeit. teilen sie sich allerdings einen farbtopf, weswegen nur einer gleichzeitig arbeiten kann, ist der einzelne arbeiter wieder im vorteil. Fakt ist: Die grafikkarte macht uns recht schnell schöne grafik, die CPU macht uns recht schnell den rest. Perfekte arbeitssimbiose und beides ist gleichwertig gut (Wer weiß wie es in 20 jahren aussieht? vielleicht haben wir dann CGPU's statt 2 getrennter einheiten?)

PhillipK

So, Jun 09, 2013 15:58
Antworten mit Zitat

Ist ja auch ein ziemlich bescheuerter vergleich.

Wenn man einen Künstler nimmt und ihm sagt, er soll n haus bauen, dann kann ers wohl nicht. Wohl aber kann der bauarbeiter, der das haus bauen könnte, ein bisschen kritzeln. Die geschwindigkeit und qualität unterscheidet sich einfach extrem.

Meiner meinung nach kann man nicht grundlegend behaupten, das eine CPU besser als eine GPU ist oder umgekehrt.
Es ist nunmal so, das alles eine entwickelung durchmacht. Hätten sich damals ein paar schlaue typen überlegtt, die CPU mit grafikbeschleunigung auszustatten und ihre momentanen aufgaben nicht zu vernachlässigen, sähe das auch ganz anders aus.

Oder ein anderes beispiel: Hat man einen arbeiter, der extrem schnell ne wand anmalen kann und dagegen 4 arbeiter, die pro wand doppelt so lange brauchen, aber jeder ne wand machen kann, sind die 4 arbeiter überlegen. Für die einzelne aufgabe brauchen sie länger, für alles zusammen teilen sie sich die arbeit.
teilen sie sich allerdings einen farbtopf, weswegen nur einer gleichzeitig arbeiten kann, ist der einzelne arbeiter wieder im vorteil.

Fakt ist: Die grafikkarte macht uns recht schnell schöne grafik, die CPU macht uns recht schnell den rest. Perfekte arbeitssimbiose und beides ist gleichwertig gut Wink

(Wer weiß wie es in 20 jahren aussieht? vielleicht haben wir dann CGPU's statt 2 getrennter einheiten?)

	DAK	So, Jun 09, 2013 16:37 Antworten mit Zitat
AMD und Intel bewegen sich tatsächlich beide in diese Richtung (CPU-GPU-Kombinationen). AMD nennt das Konzept APU, und da haben sie eine GPU und eine CPU auf einen Chip verbaut. Intel hat früher Onboard-Grafikkarten verwendet, die am Mainboard angebracht haben. Bei den i3, i5 und i7-Prozessoren ist jetzt eine Grafikkare (Intel 3000 bis Intel 4000) im Prozessor selbst verbaut. Die sind zwar bei weitem nicht so gut wie gute dedizierte Grafikkarten, eignen sich aber schon für weniger fordernde Spiele. AMD baut auch an sogenanntem Unified Memory, wo GPU und CPU den RAM gemeinsam benutzen. Das gab es zwar schon früher, allerdings wurde da der RAM vom Computer in zwei getrennte Teile aufgespalten worden, je einer für GPU und CPU. Das heißt, will man ein Modell laden, kommt das von der Festplatte in den CPU-RAM, und wird dann erst in den GPU-RAM geladen, wo's verwendet wird. Diese beiden Entwicklungen könnten gut dahin führen, dass es bald nur noch einen Baustein davon gibt. AMD geht da eher weiter, weil sie CPUs und GPUs selber machen. Intel macht zwar auch GPUs und Nvidia auch CPUs, aber beide nicht so gut wie der jeweils andere.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

So, Jun 09, 2013 16:37
Antworten mit Zitat

AMD und Intel bewegen sich tatsächlich beide in diese Richtung (CPU-GPU-Kombinationen).

AMD nennt das Konzept APU, und da haben sie eine GPU und eine CPU auf einen Chip verbaut.
Intel hat früher Onboard-Grafikkarten verwendet, die am Mainboard angebracht haben. Bei den i3, i5 und i7-Prozessoren ist jetzt eine Grafikkare (Intel 3000 bis Intel 4000) im Prozessor selbst verbaut. Die sind zwar bei weitem nicht so gut wie gute dedizierte Grafikkarten, eignen sich aber schon für weniger fordernde Spiele.

AMD baut auch an sogenanntem Unified Memory, wo GPU und CPU den RAM gemeinsam benutzen. Das gab es zwar schon früher, allerdings wurde da der RAM vom Computer in zwei getrennte Teile aufgespalten worden, je einer für GPU und CPU.
Das heißt, will man ein Modell laden, kommt das von der Festplatte in den CPU-RAM, und wird dann erst in den GPU-RAM geladen, wo's verwendet wird.

Diese beiden Entwicklungen könnten gut dahin führen, dass es bald nur noch einen Baustein davon gibt.

AMD geht da eher weiter, weil sie CPUs und GPUs selber machen. Intel macht zwar auch GPUs und Nvidia auch CPUs, aber beide nicht so gut wie der jeweils andere.

Gewinner der 6. und der 68. BlitzCodeCompo

Gehe zu Seite Zurück 1, 2

Übersicht

Sonstiges

Smalltalk

Nach Oben

BlitzBasic Portal

Hardware-Tutorial oder Was macht diese Kiste mit meinem Code