O
omaliesschen
Gast
Hi,
wäre es sinnvoll webapps in OCL zu schreiben? Vor- Nachteile?
wäre es sinnvoll webapps in OCL zu schreiben? Vor- Nachteile?
- Status
O
omaliesschen
Gast
Das übliche. Die Vorteile von GPUs nutzen. Viele Parallele Aufgaben abarbeiten.
Mir schwebt der Gedanke hin und wieder mal durchs Bewustsein seit ich ein paar Benchmarks von hashcat gesehen hatte.
xx Millionen md5/s mit CPU
10 Milliarden md5/s mit einer guten Radeon.
Vll. käme ein Speedbenchmark a la "PHP vs "OCL-PHP"" auf ähnliche Ergebnisse wie "MySQL vs Redis"?
Mir schwebt der Gedanke hin und wieder mal durchs Bewustsein seit ich ein paar Benchmarks von hashcat gesehen hatte.
xx Millionen md5/s mit CPU
10 Milliarden md5/s mit einer guten Radeon.
Vll. käme ein Speedbenchmark a la "PHP vs "OCL-PHP"" auf ähnliche Ergebnisse wie "MySQL vs Redis"?
...und auch MySQL vs. Redis (oder MongoDB) ist fürn Eimer. Wenn deine Daten wunderschön relational strukturiert sind, und wenn du auf ACID angewiesen bist, dann geht NICHTS über ein RDBMS wie MySQL, PostgreSQL, MSSQL.
Tja, und deine Web-App? Ist sie parallelisierbar oder nicht? Da gehört schon mehr dazu, als einfach nur mit Buzz-Words wie OpenCL um sich zu werfen.
Tja, und deine Web-App? Ist sie parallelisierbar oder nicht? Da gehört schon mehr dazu, als einfach nur mit Buzz-Words wie OpenCL um sich zu werfen.
O
omaliesschen
Gast
Du solltest doch mittlerweile wissen dass ich nicht "nur" mit Schlagworten um mich werf. Ich kann auch schlagen.
Es geht nicht um die Frage "wann MySQL - wann Redis". Die Frage gilt bei dem Beispiel als schon geklärt.
Man möchte einen Server der parallel Anfragen annimmt und an eine in OCL geschriebene Applikation weiterleitet.
Als Anwendungsgebiet käme mir das ausliefern von statischem Content und z.B. Redis- optimierten Inhalten in den Sinn. Mit MySQL hätte das keinen Sinn.
Es wäre nur ein Teil eines Projekts.
Es geht nicht um die Frage "wann MySQL - wann Redis". Die Frage gilt bei dem Beispiel als schon geklärt.
Gehen wir davon aus dass keine App existiert und man die Wahl hat selbst entscheiden zu können.
Man möchte einen Server der parallel Anfragen annimmt und an eine in OCL geschriebene Applikation weiterleitet.
Als Anwendungsgebiet käme mir das ausliefern von statischem Content und z.B. Redis- optimierten Inhalten in den Sinn. Mit MySQL hätte das keinen Sinn.
Es wäre nur ein Teil eines Projekts.
Zuletzt bearbeitet:
O
omaliesschen
Gast
http://stackoverflow.com/questions/14600908/why-is-redis-set-performance-better-than-get
Ist die Anzahl an simultanen Berechnungen als Entscheidungshilfe nicht wichtiger als die Komplexität?
Um irgendwas zum Spaß zu machen ist mir das Leben leider zu kurz.
Ist die Anzahl an simultanen Berechnungen als Entscheidungshilfe nicht wichtiger als die Komplexität?
Um irgendwas zum Spaß zu machen ist mir das Leben leider zu kurz.
Denk ich auch. Klar wäre für hochgradig parallelisierbare Aufgaben eine GPU-Lösung nicht verkehrt, aber am Ende hast du wirklich andere Sorgen....
Du könntest z.B. keinen der bestehenden Webserver nutzen. Du müsstest einen kompletten HTTPD von 0 auf schreiben und müsstest dabei natürlich auch auf all die Feinheiten der Sicherheit eingehen.
Die Frage ist immer, in Konkurrenz zu welchem Produkt du treten willst und ob die Arbeit somit gerechtfertigt wäre. Es wäre technisch sogar möglich, eine flugfähige Version der Enterprise zu bauen (mit Ionen-Antrieb, ohne Schilde,... aber raumflugtauglich). Bloß: Wozu? Was rechnet den Aufwand?
Du könntest z.B. keinen der bestehenden Webserver nutzen. Du müsstest einen kompletten HTTPD von 0 auf schreiben und müsstest dabei natürlich auch auf all die Feinheiten der Sicherheit eingehen.
Die Frage ist immer, in Konkurrenz zu welchem Produkt du treten willst und ob die Arbeit somit gerechtfertigt wäre. Es wäre technisch sogar möglich, eine flugfähige Version der Enterprise zu bauen (mit Ionen-Antrieb, ohne Schilde,... aber raumflugtauglich). Bloß: Wozu? Was rechnet den Aufwand?
O
omaliesschen
Gast
Die Frage wäre eher ob es zeitgemäß ist die Möglichkeit nicht zu nutzen.
"In meiner Garage steht eine DIY Enterprise die mehr Anfragen synchron verarbeiten kann als die Leitung zu lässt."
Deine Kriterien sind keine plausiblen Argumente dagegen. Irgendwer wird es in Zukunft sicherlich umsetzen und wir werden es mit Freude nutzen.
Ja, es IST zeitgemäß, Web-Apps ohne GPGPU zu schreiben. Die wenigsten Probleme sind in einer Art parallelisierbar, für die GPGPU sinnvoll ist. Ein gutes Beispiel ist z.B. Raytracing. Ein grafisches Problem, hochgradig parallelisierbar... und trotzdem für GPGPU einfach nix (sonst hätte Intel nicht so viel Mühe in Larrabee gesteckt)
O
omaliesschen
Gast
Dein Beispiel, sofern es überhaupt stimmt, hat keine Relevanz in der frage wie es sich mit Webapps/Servern verhalten würde.
C
carom
Gast
Du kannst keine "Webapps" für die GPU schreiben, du kannst höchstens bestimmte Teile deiner Anwendung darauf auslagern. Speziell bei Datenbankservern macht das aber am wenigsten Sinn überhaupt, dort ist die CPU weniger häufig der Flaschenhals als Speicher und Durchsatz, und dieses Problem würde durch die GPU noch dramatisch verschlimmert werden. Deine GPU kann nicht direkt auf Ram und Festplatte zugreifen, der Zugriff müsste immer über die CPU durchgeschleift werden. GPUs sind Spezialisten, die in sehr spezifischen, stark parallelisierbaren Aufgaben CPUs haushoch überlegen sind, in allem anderen sind sie gegenüber CPUs unbrauchbar.
iks-deh
Lt. Commander
- Registriert
- Jan. 2011
- Beiträge
- 1.333
Ich würde die Sache so angehen:
Hast du ein derart schwerwiegendes Performance-Problem, dass sich der Aufwand der Entwicklung lohnt (falls es überhaupt was bringen sollte)?
- Ja: Dann mach es.
- Nein: Dann lass es.
Aber erwarte dir nichts davon
.
Hast du ein derart schwerwiegendes Performance-Problem, dass sich der Aufwand der Entwicklung lohnt (falls es überhaupt was bringen sollte)?
- Ja: Dann mach es.
- Nein: Dann lass es.
Aber erwarte dir nichts davon
.
O
omaliesschen
Gast
Man müsste halt sein gesamtes Konzept selbst entwickeln.
Es geht um die Theorie.
Mit RAM basierten DBs wären wie oben erwähnt ja genug Anfragen pro/s möglich. Wenn ein Programm 10 Abfragen abschickt und der Rest Rechenarbeit ist ist genug Spielraum vorhanden.
Logisch kann man keines der gängigen Konzepte einfach übernehmen was nicht bedeutet dass es kein sinnvolles Konzept gibt.
Ergänzung ()
Argumentativer Overkill[...]
C
carom
Gast
Schau dir mal diese Folien hier an, die Idee ist zumindest nicht ganz neu:
http://de.scribd.com/doc/69392464/G...Up-Database-Time-Series-Analysis-Using-OpenCL
Gehe hierbei mal weiter hinten auf die Folie mit dem Titel "Challenges", wo die problematischen Aspekte aufgelistet sind. Die Sachen, für die es noch keine Lösung gibt, hängen mit Hardware und Rechnerachitektur zusammen und sind eben nicht so einfach lösbar ("data transfer gpu <-> cpu", "DBMS Table Size >> GPU RAM").
http://de.scribd.com/doc/69392464/G...Up-Database-Time-Series-Analysis-Using-OpenCL
Gehe hierbei mal weiter hinten auf die Folie mit dem Titel "Challenges", wo die problematischen Aspekte aufgelistet sind. Die Sachen, für die es noch keine Lösung gibt, hängen mit Hardware und Rechnerachitektur zusammen und sind eben nicht so einfach lösbar ("data transfer gpu <-> cpu", "DBMS Table Size >> GPU RAM").
O
omaliesschen
Gast
Endlich mal ein Link.
Accelerating SQL Database Operations on a GPU with GUDA
http://www.scribd.com/doc/27499829/Accelerating-SQL-Database-Operations-on-a-GPU-with-GUDA
OpenCL for Database Query Processing
http://www.inf.ed.ac.uk/publications/thesis/online/IM110974.pdf
Fassen wir zusammen: Eine Radeon mit eigener CPU und ausbaubarem RAM wäre ideal für das Problem?
[...]globigen Lötkolben aus dem Keller holen[...]
Accelerating SQL Database Operations on a GPU with GUDA
http://www.scribd.com/doc/27499829/Accelerating-SQL-Database-Operations-on-a-GPU-with-GUDA
OpenCL for Database Query Processing
http://www.inf.ed.ac.uk/publications/thesis/online/IM110974.pdf
Fassen wir zusammen: Eine Radeon mit eigener CPU und ausbaubarem RAM wäre ideal für das Problem?
[...]globigen Lötkolben aus dem Keller holen[...]
Zuletzt bearbeitet:
O
omaliesschen
Gast
Immerhin schneller als Du es könntest.^-^
Zuletzt bearbeitet:
C
carom
Gast
Jetzt erst gelesen (du editierst sehr gerne )
Das ist aber doch exakt das, was wofür du eine GPU überhaupt mal gar nicht gebrauchen kannst. Da steckt rein gar nichts zum berechnen dahinter, das einzige, was da limitert, ist deine Festplatte und deren Anbindung. Und gerade deswegen wären hochgradig parallelisierte Zugriffe doppelt schlecht. Das ist eine Sache, die das OS mittels CPU und HDD direkt regelt, warum einen Umweg über die GPU machen, die eh nichts sinnvolles beisteuern kann?
)Das ist aber doch exakt das, was wofür du eine GPU überhaupt mal gar nicht gebrauchen kannst. Da steckt rein gar nichts zum berechnen dahinter, das einzige, was da limitert, ist deine Festplatte und deren Anbindung. Und gerade deswegen wären hochgradig parallelisierte Zugriffe doppelt schlecht. Das ist eine Sache, die das OS mittels CPU und HDD direkt regelt, warum einen Umweg über die GPU machen, die eh nichts sinnvolles beisteuern kann?
O
omaliesschen
Gast
War ein schlechtes Beispiel. Bleiben wir bei dynamischen Inhalten mit rechenintensiven Skripten.
- Status
Ähnliche Themen
