Nicht mein Problem, wenn du nicht in der Lage bist zu abstrahieren.
Keine Sorge, ich denke ich kann sehr gut abstrahieren. Da wo ich keinen Sinn entdecke, kann ich aber auch nicht einfach welchen dazudichten.
Bei der mobile APP Entwicklung ist es wichtig, dass eine App ein gutes Look and Feel hat, also ist es ganz schlecht, wenn die UI dauernd blockiert, wenn irgendein Task etwas länger braucht, z.B. irgendwelche Zugriffe aufs Internet. Ja auch bei Desktopanwendungen ist dies wichtig und auch hier wird immer mehr asynchrone Programmierung genutzt, bei Tasks wo man nicht CPU-gebunden ist. Nur ist es so, dass bei mobilen APPs kaum CPU-gebundene Tasks abgearbeitet werden müssen. Bei mobilen Apps ist man meistens I/O-gebunden. Die meisten Apps, eigentlich fast alle, greifen aufs Internet zu und genau hier eignet sich asynchrone Programmierung. Klar kann man auch durch Multithreading verhindern, dass die UI blockiert, aber Multithreading ist komplex, sehr fehleranfällig und Threads zu initialisieren kostet teilweise mehr Leistung als der Task, der abgearbeitet werden muss. Daher sollte man bei I/O-gebundenen Tasks immer Asynchronität verwenden und bei CPU-gebundenen Tasks Multithreading. Bedenken muss man, dass mobile Verbindungen oft langsam und instabil sind, sodass ein Internetzugriff auch mal etwas länger dauern kann. Ob jetzt z.B. dein Login sofort abgeschlossen wird, 5 Sekunden oder längert dauert ist relativ egal, aber klar all zulange sollte er nicht dauern.
Und was hat das jetzt konkret mit GPUs und AC zu tun? Darum geht's doch. Was du hier schreibst, brauchst du mir nicht extra zu erläutern. Die Thematik kenne ich gut genug. Nochmal unmissverständlich, das Thema war GPUs und AC.
Und noch einiges als Ergänzung aufgrund meiner persönlichen Erfahrung, ist also nur meine Meinung, macht deine Aussagen für mich aber nicht plausibler. Gutes "Look and Feel" ist bei Desktop Apps auch nicht verboten. Daher, wie du schon andeutest, ist auch bei Desktop Apps die Entkopplung blockierender Aufgaben wichtig. Wie diese Entkopplung geschieht, ob über Asynchronität oder über Multithreading, ist erstmal zweitrangig. Oft bietet es sich aber an, simple Aufgaben über Asynchronität und komplexere Aufgaben über Multithreading zu lösen.
Dass Multithreading komplex und sehr fehleranfällig sein soll, kann ich zumindest für Windows auch nicht bestätigen. Mittlerweile bieten auch diverse populäre Sprachen wie C++ (ab C++11) offiziellen Support, der es Programmierern plattformübergreifend erleichtert und leider lange Zeit vernachlässigt wurde.
Man kann auch nicht pauschal sagen, für CPU gebundene Tasks sollte man Multithreading nutzen, für I/O gebundene Tasks Asynchronität. Was am besten passt, hängt von der verwendeten Entwicklungsumgebung und wie gesagt von der Komplexität der Aufgaben ab. Der Programmierer kann eh nicht immer abschätzen, was letztendlich CPU und was I/O gebunden ist. Erst recht wenn die App auf allen möglichen Geräten mit unterschiedlichsten Hardwarekonfigurationen laufen soll. Oder im Falle von Spielen, welche Qualitätseinstellungen genutzt werden können.
Dass mobile Apps besser für asynchrone Programmierung geeignet sein sollen, erschliesst sich mir nach wie vor nicht. ZB Message Queues unter Windows sind von Haus aus asynchron aufgebaut. Das bedeutet nicht, dass Windows Desktops Apps für asynchrone Programmierung weniger geeignet sind. Es bedeutet lediglich, dass man als Programmierer nicht so viel beisteuern muss. Oft unterscheidet synchrone und asynchrone Verarbeitung nur zB ein
SendMessage oder
PostMessage Aufruf. Der einzige Unterschied ist vielleicht, dass mobile Apps mehr auf Zugriffe aufs Internet angewiesen sind. Das ist schon richtig. Nur hat das keine Bedeutung fürs Thema. Ich sehe da weiterhin keinen direkten Zusammenhang zu GPUs und AC. Deine Aussagen ändern daran auch nichts. AC ist ein ganz konkretes Konzept für GPUs, das auf Asynchronität aufbaut. Du hingegen sprichst hier völlig allgemein über Asynchronität. Ich muss also nochmal fragen, was willst du uns damit in Bezug auf Vega sagen?
