WebApps in OpenCL schreiben?

[carom]

Das von dir verlinkte Paper zeigt die Probleme schön auf.

Also dein DB-Server braucht einfach seine Daten, auf denen er Queries ausführen kann, und mit GPU on-the-fly auf Ram oder HDD zuzugreifen ist nicht drin, wenn man die durch die GPU gewonnenen Vorteile nicht wieder (mehr als) zunichte machen will. Also müssen alle Datensätze, die abgefragt werden sollen, komplett im GPU-Ram vorliegen. Da hast du das Problem, dass dieser bei aktuellen GPUs viel zu klein ist. Als Notlösung wird beschrieben, dass man immer nur die benötigten Teile der Datenbank vom System-RAM (von HDD wäre viel zu langsam) in den GPU-Ram schiebt, dann den teuren Query auf der GPU ausführt, und die Daten dann wieder zurückschiebt in die "richtige" DB. Das ist natürlich aufwendig und lohnt nur dann, wenn dieser gesamte Prozess schneller vonstatten geht, als den Query einfach direkt auf der CPU auszuführen. Und das ist bei 99,99% aller heutigen Anwendungen nicht der Fall, da bei normalen DB-Servern die CPU nur in seltenen Fällen der Flaschenhals ist.
Da stellt sich die Frage, wer eine GPU-DB möchte, auf welcher ein paar wenige Queries 20-40x schneller laufen, die DB in ihrer gesamten Anwendung aber zigfach langsamer ist als konventionelle DBs. Das ist was für die Wissenschaft oder einen kleinen Teil der Wirtschaft oder Finanzmärkte, Big Data und so, aber beispielsweise nichts fürs Web.

GPGPU-Sachen werden sicherlich immer wichtiger werden und da steckt großes Potential dahinter, aber GPUs werden dabei Satelliten (also Anhängsel) von CPUs bleiben und hier und da wohldefinierte Brocken zum verarbeiten bekommen... das komplette Programme auf der GPU laufen ist aber unwahrscheinlich, auch wenn es in deinem Paper so gemacht wurde (SQLlite nach Cuda portiert), da gibt es zu viele Restriktionen (nur mini-caches bei GPUs, verschiedene Ram-Level statt einem "Haupt-Ram" etc..).

Der Autor sagt selbst, dass es sehr komplex ist und viel Know-how benötigt, Dinge auf der GPU umzusetzen und diese auszureizen. Hardware kostet heute nichts mehr. Wenn bei einem DB-Server die CPU limitiert, dann kauft man sich lieber noch einen zweiten Server dazu, statt etwas teures entwickeln zu lassen.

 

[Zweipunktnull]

Bleiben wir bei dynamischen Inhalten mit rechenintensiven Skripten.

Das ist doch auch kein richtiges Beispiel, sondern nur allgemeines Geblubber. Keine normale Website, die mir einfallen würde, führt rechenintensive Dinge durch. Vielleicht mangelt es mir ja nur an Fantasie, aber deswegen frage ich dich ja. Im Moment steht deinerseits nur die Frage im Raum, ob sich GPUs für x eignen, wobei du uns nicht sagst, was x sein soll - außer dass es halt *irgendwas* mit Internet, Web und am besten noch NoSQL zu tun haben soll. Was soll man darauf antworten?

Selbst wenn ich an die großen Websites wie Twitter und Facebook denke, fallen mir keine *rechenintensiven* Aufgaben ein. Sowohl Facebook als auch Twitter stehen vor großen technischen Herausforderungen. Aber deren Problem ist doch nicht der Mangel an brachialer Rechenpower, sondern die Bewältigung riesiger Datenmengen. Und dabei ist - wie es hier auch schon öfter gesagt wurde - die Speicherbandbreite das Problem, und nicht eine zu schwache CPU.

Nimm mal SAP HANA als Beispiel. Dort geht es darum, riesige Datenmengen in Echtzeit zu analysieren. Was denkst du, ist bei herkömmlichen Datenbanken das Problem, wenn ich den Durchschnittswert einer numerischen Spalte mit 10 Mrd. Einträgen berechnen will? Die paar Additionen, die die CPU machen muss, sind es nicht. Das Problem ist, dass die Busse die Daten der CPU gar nicht so schnell zur Verfügung stellen können, wie die diese theoretisch verarbeiten könnte. In der Tat dreht die CPU während der Berechnung des Durchschnitts über 1 Mrd. Datensätze die meiste (!) Zeit Däumchen und wartet darauf, dass der Bus ihr die erforderlichen Daten liefert.

Der Gap zwischen Speicherbandbreite und CPU-Performance ist sogar so groß geworden in den letzten Jahren, dass Kompression von Daten zu Geschwindigkeitssteigerungen führt. Eigentlich paradox, da das Komprimieren und Dekomprimieren ja einen Overhead erzeugt. Durch die Kompression haben wir allerdings eine höhere logische Speicherbandbreite, da wir insgesamt weniger Daten über den Bus schicken müssen. Das spart Zeit bei der Datenübertragung. Und der (De-)Komprimierungsaufwand ist recht unproblematisch, da die CPU wie gesagt ohnehin in diesen Szenarien extrem unterfordert ist.

Was macht SAP HANA nun, damit es bei solchen Anfragen schneller ist, als herkömmliche Datenbanken? Zum einen liegen die Daten im Hauptspeicher, dadurch kann der lahme SATA-Bus vermieden werden. Ok, das ist jetzt noch nicht so revolutionär. Jede normale DB verfügt über einen Cache, kann also prinzipiell bei genügend RAM "quasi-in-memory" laufen. Als nächstes speichert HANA die Daten aber nicht zeilenorientiert, sondern spaltenorientiert. Dadurch können die Cache-Lines der CPU wesentlich effizienter befüllt werden und es werden viel weniger unnütze Daten in den Cache geladen. Als drittes verwendet HANA verschiedene Komprimierungstechniken, um eben die logische Speicherbandbreite zu erhöhen. Ich möchte nicht ganz verschweigen, dass man natürlich auch etwas an parallelen Algorithmen herumdoktert, aber die meisten Maßnahmen dienen der Optimierung der Speicherzugriffsmuster, weil das eben *der* Knackpunkt ist.

Also merke: Die Herausforderungen im Internet und in Unternehmensanwendungen liegen bei der Handhabung gigantischer Datenmengen, nicht bei intensive Berechnungen. Die Finden sich mehr in Wissenschaft und Technik. Daher ist GPU-Computing fürs Web auch ziemlich uninteressant, da es einfach an komplexen Berechnungen fehlt.

Weiter oben hast du etwas von 100.000 Set- und 80.000-Get-Operationen in Redis erzählt. Das ist ja geradezu ein perfektes Beispiel für Operationenen, deren arithmetischer Aufwand nahe bei null liegt. Die Kunst dabei ist der Datenzugriff: Man braucht passende Indexstrukturen, die Anfragen müssen möglichst geschickt auf verschiedene Nodes verteilt werden etc. Aber arithmetisch muss da nicht viel gemacht werden, genau das ist aber das Einsatzgebiet von GPUs.

Bedenke außerdem, dass GPU-Computing die Speicherbandbreitenproblematik noch verschärft. Bisher hab ich kurz erläutert, dass die Speicherbandbreite bereits die CPU ausbremst. Beim GPU-Computing müssen die Daten nun noch zusätzlich den "Umweg" über den PCI-Express-Bus in den Grafikspeicher nehmen (und natürlich auch wieder zurück in den RAM). In der Tat liegt IMO die größte Schwierigkeit beim GPU-Computing in der Optimierung der Speicherzugriffe. Zum einen müssen die Transfers zwischen RAM und globalem Grafikspeicher gering gehalten werden, zum anderen sollten aber selbst die Zugriffe der GPU-Kerne auf den globalen Grafikspeicher gering gehalten werden. Stattdessen lieber einmalig vom globalen Grafikspeicher in bestimmte lokale Speicherbereiche laden und die Kerne dann auf den lokalen Speicherbereichen operieren lassen. Dabei muss man dann wieder auf Bank-Conflicts achten, aber das ist jetzt wahrscheinlich ohnehin alles viel zu tiefgreifend.

Summa summarum (vereinfacht): GPU-Computing eignet sich, wenn relativ komplexe arithmetische Berechnungen auf relativ wenigen Daten ausgeführt werden. Im Web ist es meiner Erfahrung nach leider genau umgekehrt: Oft hat man sehr viele Daten, auf denen aber in der Regel nur triviale Operationen ausgeführt werden.

Wenn du Gegenbeispiele hast, würden die mich sehr interessieren. Wenn nicht, solltest du die Sache mit den Threads in nächster Zeit evtl. etwas überlegter angehen. Deine letzten beiden waren ja inhaltlich auch eher dünn.

 

[omaliesschen]

Der übliche Überheblichkeitswrapper eines Programmierers. Vll. diskutieren wir das Thema erneut wenn der Gedanke Energie einzusparen an Popularität zugelegt hat.

 

[Zweipunktnull]

Ja, so machen wir es am besten!

 

[Daaron]

Wenn du Energie sparen willst, dann schreib effizienteren Code, aber fang nicht mit solchen Experimenten an.

Du willst hier unbedingt von uns hören: "Oh, ja! Geile Idee! Noch nie dagewesen, total revolutionär, damit wirst du Milliardär!" Sobald du aber etwas Gegenwind aus der Realität erhälst greifst du nach Strohhalmen wie der Energieeffizienz.

Sagen wir einfach so: Wenn es dir gelingt, ein einfach zu programmierendes, energetisch effizientes und hochgradig skalierendes Webframework für GPGPU und Datenbank-Zugriffe zu schreiben, das KEINE exotische, nicht-existente Hardware benötigt, dann wirst du damit wohl tatsächlich unglaublich reich und berühmt.
Leider ist es aber so, dass bereits große Forscher-Teams, von denen jedes Mitglied mehr Hirnschmalz vorweisen kann als das halbe Forum hier zusammen, an genau so etwas arbeiten und festgestellt haben: Es bringt nix.

Und noch ein Geheimnis aus der Großen Bösen Welt: Energie-Effizienz ist etwas, das bei Serverzentren gar keine Rolle spielt. Der Energieverbrauch der Server ist absolut vorhersagbar und hat im Zweifel fast keine Schwankungen. Wenn es dir also um Green-Tech geht, dann baust du neben der Serverfarm eine Wind- oder Solarfarm. Oder du verpflanzt deine Server nach Island und lebst von Geothermie wie Gott in Frankreich. Du könntest deine Server auch mit einem Blockheizkraftwerk versorgen, welches du mit Bio-Abfällen aus der umliegenden Landwirtschaft fütterst. Das ist alles wunderbare Green-Tech.
Anders sieht es beim privaten Stromverbrauch von Lieschen Müller aus. Deren Last schwankt extrem. Ist sie gerade auf Arbeit? Sitzt sie abends vorm Fernseher, während die Waschmaschine ihren Dienst verrichtet und im Ofen das Abendbrot gart? Ackern gleichzeitig Geschirrspüler und Staubsauger, während im extra-laut gedrehten Radio "I Want To Break Free" läuft? DAS sind Lastschwankungen, mit denen regenerative Energien noch nicht klar kommen. Für die braucht man dreckige Grundlast-Kraftwerke.


Aber hey, wenn du unbedingt auf "Grafikkarten" deine Berechnungen für ne Web-App machen willst: für 4-5000$ gehört ne Xeon Phi dir.

 

[Kanibal]

Um die Sache nochmal auf den Punkt zu bringen:
Jede WebApp braucht RAM, RAM-Zugriff hat nur die CPU,
WebApp mit GPU => langsamer.

 

[master2k]

du kannst WebGL für 3d Darstellung im browser verwenden,

aber OpenCL macht in keinster weise sinn es sei denn du lässt "per click" Millarden von Operationen berechnen.
(PHP ruft OpenCL Applikation auf, opencl Applikation returnt die results zu PHP).
alles anderes ist selbstverständlich bullshit.

m2k

 

[Daaron]

Das wäre ein Ansatz, wie man bestehende Webserver (Apache & Co) trotzdem nutzen könnte... aber immer noch kein Ansatz, wozu das alles gut sein soll. Da wäre es sogar sinnvoller, einen Bugatti Veyron als Innenstadt-Auto zu nutzen. Hey, 1000PS... egal, ob ich 80-90% der Zeit im Ampelstau stehe, 1000 PS...

 

[omaliesschen]

Du willst hier unbedingt von uns hören: "Oh, ja! Geile Idee! Noch nie dagewesen, total revolutionär, damit wirst du Milliardär!"

Deine Kristallkugel scheint fehlerhaft zu sein. Vll. bist Du allerdings auch nur nicht fähig Sie sachgerecht zu nutzen.

Ich wollte Fakten hören. Es wurden einige geliefert, ein Paper nachgereicht und nichts davon kam von Dir. Von dir kamen ein paar Oberflächenkratzer. Es zeichnet sich ein gewisses Bild von Dir. Wenn es eng wird bist Du ganz schnell weg aus Diskussion zu deren Teilnahme dein Wissenstand nicht reicht. Soll ich sie zusammentragen?

Sobald du aber etwas Gegenwind aus der Realität erhälst greifst du nach Strohhalmen wie der Energieeffizienz.

Den hab ich in den Raum geworfen weils mir einfach zu blöd wurd. Wenn Beiträge von Beleidigungen ummantelt werden verliert man manchmal die Lust.

Das Du dich hier auf den Argumenten der anderen Teilnehmer ausruhst und auch noch die Posaune ausholst find ich lustig da Deine eigenen Beiträge eben inhaltlich viel zu Oberflächlich waren als das Sie hier ein Fundament bilden könnten. Wie ist es so wenn man auf das Glück und den Rückenwind hofft?

Paradebeispiel obfuskiertes JS. Keine Ahnung haben aber auf der Posaune spielen wollen als die Übersetzung von dritten geliefert wurde.

Leider ist es aber so, dass bereits große Forscher-Teams, von denen jedes Mitglied mehr Hirnschmalz vorweisen kann als das halbe Forum hier zusammen, an genau so etwas arbeiten und festgestellt haben: Es bringt nix.

Quellen bitte. Ansonsten ein typischer Daaron (Synonym für aufgeblasene Beiträge (und/oder Teile eines Beitrags) ohne inhaltlichen Nährwert)

PS: Wir können in zukünftigen Kommunikationen gerne auf Höflichkeit verzichten. Ein paar Platzhirschkopfpräparate mehr oder weniger an der Wand... Wenn stört das schon.

 

[daniel_m]

Es zeichnet sich ein gewisses Bild von Dir.

Is ja witzig, denn genau das gleiche habe ich gerade über dich gedacht. Denn jede Diskussion in die du involviert bist verläuft nämlich nach dem gleichen Muster:

1. Die (zumeist) belanglose Frage / Diskussionsgrundlage
2. Diverse Einwände, Zustimmungen, Gegenfragen, sonstwas von anderen
3. Du bist entweder beleidigt, überliest alles oder wechselst ganz abrupt das Thema (hier isses auf einmal die Energieeffizienz)
4. Du beleidigst andere mit unglaublicher Arroganz

Dabei glaube ich nicht einmal dass du dumm bist, ganz im Gegenteil sogar, aber ich frage mich dennoch was das immer soll.

PS: Wir können in zukünftigen Kommunikationen gerne auf Höflichkeit verzichten. Ein paar Platzhirschkopfpräparate mehr oder weniger an der Wand... Wenn stört das schon.

Pass nur auf dass es nicht irgendwann dein Kopf sein wird, der an die Wand genagelt wird.

Und jetzt schwirr' ab, eine Antwort deinerseits auf diesen meinen Beitrag ist völlig nutzlos.

 

[Daaron]

Weil ich nicht für dich nach "Datenbank + OpenCL" oder "Database + GPGPU" gesucht habe ruh ich mich also aus? Ich hab vor Anfang an gefragt, welchen Zweck das ganze denn haben soll und woher dein hochgradig parallelisierbares Problem stammt. Du hast von Anfang an hingegen nicht begriffen, wozu GPGPU nun eigentlich taugt und wozu absolut nicht. Du hast ein total nutzloses Problem in den Raum gestellt und von vielen Leuten die Antwort bekommen, die du gerade NICHT wolltest: Es macht keinen Sinn. Es macht weder Sinn, Datenbanken auf existierenden Grafikkarten laufen zu lassen noch macht es Sinn, Web Apps hochgradig parallel berechnen zu lassen. Und selbst WENN man parallelisiert, dann doch sicher nicht mit OpenCL, denn GPGPU-Chips sind schlichtweg nicht so "G", wie man gern vermutet.
Wenn man wirklich ein extrem gut parallelisierbares Problem berechnen will und dabei auf Manycore-Prozessoren zurückgreifen kann, dann wäre OpenCL die falsche Sprache. Die beste und leistungsfähigste aktuell verfügbare Manycore-Hardware "spricht" x86. Da könntest du auch direkt eine Datenbank drauf laufen lassen, wenn es nur was bringen würde.

 

[omaliesschen]

Is ja witzig, denn genau das gleiche habe ich gerade über dich gedacht.

Denken - mein Freund- darfst Du vieles. Ob das Produkt der Phantasterei, von der Du annimmst es handele sich um "denken", auch der Realität entspricht wäre Stoff für die Lehrbücher. Damit meine ich den analytischen Teil. Nicht jedoch den zu analysierenden Teil. Den deinigen.

aber ich frage mich dennoch was das immer soll.

Frag nicht mich. Der Versuch eine gewisse Grundhöflichkeit walten zu lassen scheiterte wie so oft am Mitwirkungswillen anderer.

Wie das hier eindrücklich aufzeigt:

Und jetzt schwirr' ab, eine Antwort deinerseits auf diesen meinen Beitrag ist völlig nutzlos.

reicht dein Kaliber hierfür ganz sicher nicht aus:

Pass nur auf dass es nicht irgendwann dein Kopf sein wird, der an die Wand genagelt wird.

Darüber hinaus taugen laienhafte Zusammenfassungen meines Diskussionsstils schon aufgrund des ihm innewohnenden polymorphen Charakters maximal dem allgemeinen Amüsement.

Ergänzung (1. Juni 2013)

@Daaron
Deine bisherigen Beiträge hier lassen die Annahme du würdest dich mit dem Thema auskennen leider nicht zu. Deine harschen Kritiken beruhen auf Beiträgen dritter.

Du kamst doch schon ins Wanken als WebGL genannt wurde.

Glaubst Du ernsthaft mir wäre das Thema in irgendeiner Form wichtig?

Wenn Argumente nicht in einen Wrapper aus Überheblichkeit/Arroganz und Beleidigung gepackt werden hab ich kein Problem damit.

 

[Tumbleweed]

Schön zusammengefasst daniel_m. Ich bin leider auch schon einmal drauf reingefallen. "Don't feed the trolls" war selten so passend. Habe ich in dem Forum hier auch noch nie erlebt. Normalerweise wird solcher Schwachsinn am laufenden Band über mehrere Threads hinweg direkt wegoptimiert, aber hier im Board liest die Moderation wohl nicht so oft.
Er macht es ja auch geschickt, muss man ihm ja lassen. Man erkennt das Muster erst, wenn man sich wirklich mal durch die ganzen Threads liest. Er sucht jedenfalls hier ganz sicher keinen Konsens oder fruchtbare Konversation, daher kann ich jedem nur raten seine Threads zu ignorieren, wenn man vor hat seine Ansichten in Frage zu stellen.

 

[omaliesschen]

Die Grenzen meiner Toleranz enden hier:

Eine empfindliche Schwelle aber vorhanden.

<Beleidigung><Content></Beleidigung>

https://www.computerbase.de/forum/threads/webapps-in-opencl-schreiben.1214216/page-2#post-14021578

Meine Reaktion war der Versuch, höflich, aus der Diskussion aufzusteigen.

Worauf sich Daaron mit folgenden "Argumenten (nach der Daaron'schen Methodik)" meldete:

"Oh, ja! Geile Idee! Noch nie dagewesen, total revolutionär, damit wirst du Milliardär!" Sobald du aber etwas Gegenwind aus der Realität erhälst greifst du nach Strohhalmen wie der Energieeffizienz.

Und noch ein Geheimnis aus der Großen Bösen Welt:

Aber hey, wenn du unbedingt auf "Grafikkarten" deine Berechnungen für ne Web-App machen willst: für 4-5000$ gehört ne Xeon Phi dir.

Muss ich mir nicht geben.

 

[Zweipunktnull]

Da du nun doch nochmals explizit auf meinen Post zurückgekommen bist, möchte ich noch einen kurzen Kommentar dazu abgeben. Du siehst also sowohl zu Beginn als auch am Ende meines Posts Beleidigungen meinerseits.

Die einzige Wortfolge im ersten Abschnitt, die man mit ganz, ganz viel bösem Willen als Beleidigung auffassen könnte, ist wohl das allgemeine Geblubber. Aber mal im Ernst, du wirst mehrfach nach einem konkreten Beispiel gefragt und wirfst dann einfach nicht näher erläuterte rechenintensive Skripte in den Raum. Das ist halt weder ein konkretes Beispiel, noch lässt es den Schluss zu, dass du dich ernsthaft mit dem Thema beschäftigen würdest, noch liefert es eine vernünftige Diskussionsgrundlage, noch... und so weiter. Sorry, aber das ist einfach keine Beleidigung.

Die einzige potenzielle Beleidigung im letzten Abschnitt ist wohl die Feststellung, dass deine beiden letzten Threads inhaltlich auch eher dünn waren. Das mag dich vielleicht angreifen, war aber halt auch nur eine Tatsachenbehauptung. Die Bemerkung wäre nicht unbedingt notwendig gewesen und war somit in der Tat ein klitzekleiner Nachtritt von mir. Aber vielleicht provoziert dein Verhalten genau solche Bemerkungen ja auch? Mangelhafte Threads, Halbwissen, Unüberlegtheit gepaart mit Beratungsresistenz, Uneinsichtigkeit etc. Das kann natürlich andere Leute durchaus dazu reizen, eine Nebenbemerkung fallen zu lassen.

 

[Daaron]

Du kamst doch schon ins Wanken als WebGL genannt wurde.

Warum hätte ich auf WebGL auch eingehen sollen? Was soll eine clientseitige Technologie hier mit dem Thread auch zu tun haben?

Glaubst Du ernsthaft mir wäre das Thema in irgendeiner Form wichtig?

Warum erstellst du den Thread dann?

 

[jodd]

Das Thema hat sich wohl erledigt.