Besitzt der Apple A8-Prozessor auch weiterhin nur zwei Kerne?

2 Kerne kann ich mir ja noch gut erklären. Ein Kern versorgt das OS, der andere das verwendete Programm. Aber es muss ja einen erklärbaren Grund geben warum man auf 4 Kerner setzten will.... oder sind einfach alle nur blöde und fallen auf das Marketing herein ;-)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
wie will man sonst den erfolg von samsung erklären?

Ohne Apple schützen zu wollen, viele fallen darauf rein. In der Verwandtschaft ist 2 Tage vor Garantie-Ende das äußerst gepflegte Galaxy S3 einfach ausgestiegen. Akku noch vollkommen in Ordnung. Gab einfach keine Reaktion mehr. Als Ersatz gabs mit Aufpreis (+VVL) ein S5. Ich sollte als Software-Entwickler gucken, ob ich die Daten von dem S3 auf das S5 bekommen kann. Ich habe ein paar Spitzen gegen Samsung raus gehauen und den Rest für mich behalten.

BTT: Ich muss aus eigener Erfahrung sagen, dass Apple sehr gut mit den Resourcen des SoCs umgeht und dafür auch seine Richtlinien versucht durchzudrücken. Das rechne ich ihnen hoch an und es rechtfertig ein wenig den Preis, den mittlerweile auch die Mitbewerber versuchen aufzurufen. Wenn sie diese Optimierungen beibehalten, dann wird der Wettbewerb irgendwann mit 8 (16, usw.) Kernen gegen die 2 von Apple stehen und behaupten, dass sie damit so viel besser seien. Aus der Sicht eines Softwareentwickler ist es für bestimmte Vorgänge sehr schwer, eine richtige Multithreading-Anwendung (nicht Mehrkernunterstützung) zu programmieren, die auch noch flüssig läuft. Schlimm wird es nur, wenn sehr viele Abhängigkeiten bestehen und man viele Synchronisierungen benötigt. Wenn die Anwendung dann läuft und auch noch eine Mehrkern-Unterstützung benötigt wird es noch komplizierter, falls die Entwicklungsumgebung das überhaupt hergibt. Den Rest übernimmt sowieso das OS und ein ordentlich programmierter Task-Scheduler.
 
Samsung betreibt hervorragendes Marketing das fast schon so gut wie von Apple ist. Das ist eigentlich alles. Die Geräte sind natürlich auch sehr gut und hin und wieder gibts noch ein nettes Feature hinzu. Das man da noch dicke Vierkerner rein packt, passt natürlich zum gesammten Samsung hype.

Ich persönlich finde die Samsung Geräte allerdings kein deut besser als viele andere Geräte/Marken auch.
 
1. os 2. Programm 3. Musik 4. Mails :d

Das scheitert am Task-Scheduler, der dir die Sachen auf 1, wenn überhaupt 2, Kernen verteilt. Das es vom OS so gemacht wird, ist reines Wunschdenken und das wichtigste, es widerspricht den Stromsparregeln. Ein Kern der läuft, verbraucht Strom, egal ob er wenig, mittel oder viel zu tun hat. Wenn der Task-Scheduler nun die Aufgaben ordentlich an den Kern durchreicht, taktet er mal einen Kern etwas höher, lässt das zügig abarbeiten und geht dann wieder in einen Stromsparmodus. Immerhin besser als 2 oder mehr Kerne am Laufen zu haben. Abgesehen davon musst du mit diesen 4 "Anwendungen" erstmal eine Last erzeugen, die das OS dazu zwingen würden, einen weiteren Kern aufzuwecken. Zumal dann immer noch die systematischen Flaschenhälse in jedem System dazu kommen, die wären externe Caches, RAM, Festspeicher (HDD/SSD/eMMC oder ähnliches). Mit jeder Stufe wird die Bandbreite immer geringer und irgendwann schickt man die CPU zwangsweise in Wartephasen, dann reicht auch nur ein Kern.

Hohe Bandbreiten haben bisher eh nur spezielle Systeme z.B. Server. Da braucht man natürlich kein Smartphone mit vergleichen und solange man dem Nutzer glauben machen kann, dass ein 4-Kern-SoC äußerst flüssig läuft, glaubt er die Marketingphrasen wie das Amen in der Kirche.
 
Manche glauben das und das nutzen alle Hersteller von Smartphones/IT-Hardware gnadenlos aus. Da sollte man nicht mit Ironie daherkommen, wenn sie nicht richtig hervorgehoben wird. Denn für einen Normal-Nutzer eines Smartphones sind deine Aufführungen mit die häufigsten.

Ich würde im Rahmen der Nutzbarkeit eines mobilen Gerätes auch eine Nutzung von 4 Kernen für die 4 genannten Aufgaben nicht haben wollen, weil es die wichtigste Resource frisst: den Strom und der ist gewissermaßen endlich.
 
Einigen wir uns mal darauf: Die zusätzlichen Kerne sind eben für Power-On-Demand.
Das heisst ja noch nicht dass sie überflüssig oder nur wegen Marketting da sind.
 
Darauf könnte ich mich nicht einigen. 4 Kerne sind auch auf längere Sicht hin für Handys/Tablets nutzlos, sofern die das OS nicht anpassen und Multithreading tauglich machen. Und das ist etwas, was sicherlich noch lange auf sich warten lässt. Was soll man auch auf den Mini Displays groß Multithreading mäßiges tun?
 
Also das Betriebssystem unterstützt Multithreading. Hab selbst schon multiple Threads unetr Java auf Android in der Hochschule benutzt.
Multithreading muss ja nicht zwingend heissen dass man unterschiedliche Programme gleichzeitig offen haben muss (was bei manchen Samsung Tablets übrigens auch geht), sondern dass sich ein einziges Programm aufspaltet um mehr Leistung abzurufen. Das ist ja z.B. bei PC-Games schon gang und gebe (darum braucht man für die meisten games ja Vierkerner) und auch z.B. Browser sind ind er Lage Tabs auf mehrere Kerne zu verlagern.
Bei Smartphones fehlen uns, oder zumindest mir, aber die Informationen ob tatsächlich Gebrauch von Multithreading gemacht wird, oder nicht.

Auf jeden Falls stimmt aber ja: Mehr Kerne = mehr Leistung - sofern man von ganz ähnliche Architekturen redet und da sind die meisten ARM Prozessoren ziemlich ähnlich.
Nur die SoCs von Apple sowie die vorraussichtlichen Atom und Quarks (wurde das Projekt eigentlich nicht eingestellt?) von Intel sind da anders da sie mehr IPC bieten.
 
Mehr Kerne = mehr theoretische Leistung
Man muss natürlich erst mal ein Programm haben, dass die vielen Kerne auch effektiv nutzt. Multithreading Unterstützung alleine bringts nicht, wenn man die rechenintensiven Aufgaben nicht parallel abarbeiten kann.
 
Mehr Kerne = mehr theoretische Leistung
Man muss natürlich erst mal ein Programm haben, dass die vielen Kerne auch effektiv nutzt. Multithreading Unterstützung alleine bringts nicht, wenn man die rechenintensiven Aufgaben nicht parallel abarbeiten kann.
Soweit vollkommen Richtig!
Jetzt überleg mal wie viel "Kerne" ein GPU hat? Das sind wir aber ganz fix bei mindestens 8 Kerne.
Jetzt überleg mal was in den letzten Jahren, alles an Berechnungen auf die GPU ausgelagert wurde und mit welchem SpeedUp Faktor.
Im Schnitt das doppelte, im ideal Fall 10x Beschleunigung!

Jetzt erzähl mir doch keiner, es lässt sich nichts parallelisieren, Hallo!?
 
@Phantomias
Auf GPUS kannst du nur sehr simple Aufgaben parallel berechnen lassen. Mit normalen Anwendungen oder Spielen kannst du das völlig knicken. Da braucht es etwas komplexeres als ein GPU Kern. Ansonsten müssten die AMD APUs ja rennen wie blöde.... tun sie aber nicht, weil man die GPU für so gut wie nichts verwenden kann.
 
Soweit vollkommen Richtig!
Jetzt überleg mal wie viel "Kerne" ein GPU hat? Das sind wir aber ganz fix bei mindestens 8 Kerne.
Jetzt überleg mal was in den letzten Jahren, alles an Berechnungen auf die GPU ausgelagert wurde und mit welchem SpeedUp Faktor.
Im Schnitt das doppelte, im ideal Fall 10x Beschleunigung!

Jetzt erzähl mir doch keiner, es lässt sich nichts parallelisieren, Hallo!?
Das geht mit einigen Sachen sehr gut.
z.B. realistische Physik Simulationen mit tausenden einzelnen Partikeln, die alle einzeln berechnet werden wollen. Um so weniger Partikel sich einen Kern "teilen" müssen, um so besser fluppts.
Was aber, wenn Berechnung 2 mit dem Ergebnis von Berechnung 1 arbeiten muss? Dann kannst du noch so viele Kerne haben. Es wird nicht schneller.
 
@Phantomias
Auf GPUS kannst du nur sehr simple Aufgaben parallel berechnen lassen. Mit normalen Anwendungen oder Spielen kannst du das völlig knicken. Da braucht es etwas komplexeres als ein GPU Kern. Ansonsten müssten die AMD APUs ja rennen wie blöde.... tun sie aber nicht, weil man die GPU für so gut wie nichts verwenden kann.
Das ist ein etwas altmodisches Argument, als Einwurf würde ich mal das hier in die Runde schmeißen: GCN working as x86(_64) | AMD Developer Forums
 
Altmodisch? Na dann nenne mir doch mal ganze Programme die man "effektiv" und im Alltag nutzt die Berechnungen über die GPU nutzen. Mal ein paar Videorenderer außen vor deren optische Qualität immer noch der CPU Berechnung hinter her hinkt.
Was irgendwelche Leute schreiben... die Menschen schreiben/reden viel wenn der Tag lang ist. Mich interessieren aktuelle Fakten. Wenn du mich eines besseren belehren kannst... mit Fakten... dann her damit :-)
 
Zuletzt bearbeitet:
Leider hat Stechpalme da Recht. Bei "gewöhnlichen" Anwendungen gestaltet sich paralelisierung alles andere als Einfach - bzw: Wenn der Programmierer das vermeiden kann, dann wird er es meist auch nicht tun.
Anders ist es bei Grafiksystemen, da ist eine Paralelisierung gewisssermaßen schon im Treiber vorgesehen (auf PCs wird sich das mit DX sogar noch verbessern).
 
Zuletzt bearbeitet:
Das GPU-Processing hat eine Grundvorraussetzung, damit die massive Parallelisierung überhaupt funktionieren kann: sehr, sehr viele gleichartige Befehle. Bei einem Spiel ist es die Zusammensetzung der Polygone, Füllen mit Texturen und dann das Post-Processing. Der Vorteil der GPU ist dahingehend der, dass die Daten, die sie verarbeiten muss, quasi von der CPU "vorgerechnet" wurden. Die CPU weiß in einem Spiel, wie das kommende Bild aussehen muss, gibt das weiter und die Grafikkarte macht dann den Rest.

Bei den anderen Aufgaben, die eine GPU übernehmen kann ist es recht ähnlich. Zum Beispiel die Konvertierung eines FHD-Films in ein transportables Format. Die Anweisung ist immer die gleiche, wandle Bild x nach Bild x' mit andere Auflösung um, mache ein paar Anpassungen, damit das Bild nicht wie dahingekotzt aussieht, fertig. Das macht es dann für die gesamte Laufzeit und seitens CUDA ist bei solchen Sachen für mich jetzt keine besondere Leistungssteigerung mehr ersichtlich. Konnte das mit einer Geforce GTX 660 Ti und einer Geforce 780 feststellen, die Unterschiede sind mit ein und dem selben Programm marginal.
 
Altmodisch? Na dann nenne mir doch mal ganze Programme die man "effektiv" und im Alltag nutzt die Berechnungen über die GPU nutzen. Mal ein paar Videorenderer außen vor deren optische Qualität immer noch der CPU Berechnung hinter her hinkt.
Was irgendwelche Leute schreiben... die Menschen schreiben/reden viel wenn der Tag lang ist. Mich interessieren aktuelle Fakten. Wenn du mich eines besseren belehren kannst... mit Fakten... dann her damit :-)
Hier gibt es eine Liste der Programme die über CUDA laufen: GPU Applications | High Performance Computing | NVIDIA
Da steht auch der SpeeUp Faktor mit dabei.

Bei GCN von AMD gibt es ein Unified Adress Space: Graphics Core Next - Wikipedia, the free encyclopedia
Das spart das kopieren der Daten vom RAM in den VRAM.
GPGPU agiert nicht nach der klassischen Fütterung, hier füttert die GPU sich selbst.

Ich geh mal davon aus, das Apple das nicht anders Handhabt.
 
Das ist ein etwas altmodisches Argument, als Einwurf würde ich mal das hier in die Runde schmeißen: GCN working as x86(_64) | AMD Developer Forums

Du sprichst schon wieder über Sachen, wovon du leider keine Ahnung hast...
Bitte arbeite dich wenigstens ansatzweise in Softwareentwicklung ein. Dann stellst du ganz schnell fest, das da mal so gar nix altmodisch daran ist. Sondern einfach Grundsatz... Programmcode wird idR sequenziell abgearbeitet und nix anderes.
Um das Streckeweise zu umgehen nutzt man Multithreading. Nur lässt sich selbst mit x-hundert Threads eine einzige Berechnung oder Berechnungen mit Abhängigkeiten gegeneinander nicht auftrennen. Das ist einfach mal so... Simples Beispiel, wenn du A + B rechnest und das Ergebnis durch C teilen willst, muss freilich erst A + B errechnet werden. Es sind also zwei Schritte notwendig. Mit MT sind es aber immernoch zwei und es wird mal gar nix beschleunigt. Eher sogar im Gegenteil, denn das Nutzen von Threads kostet ebenso Zeit. Für zwei derart simple Operationen idR sogar so viel mehr Zeit, das es in Summe gar langsamer ist.

Die GPU hat je nach Ausbau tausende eher simple Rechenwerke. Und diese Recheneinheiten performen genau dort gut, wo es Aufgaben zu beweltigen gilt, die extrem häufig viele kleine Minischritte aufführen. Komplexe, voneinander abhängige Berechnungen benötigt dort viel Logik um diese Berechnungen so zu teilen, das möglichst viel davon gleichzeitig läuft. Ab einem gewissen Punkt ist das Aufteilen aber schlicht nicht mehr machbar...
Dazu kommt, das heutige CPUs viel mehr Onboard haben, als nur ne simple ALU. Heutige Standardsoftware auf ne GPU zu bringen ist äußerst schwer. Das sieht man auch an überwiegenden Teil der Software, die heute schon GPGPU nutzen. Denn idR sind das alles nur "Erweiterungen", eben Berechnungen, die der GPU schmecken... Das ganze vollständig auf die GPU zu bringen, ist aktuell nicht drin. Und selbst wenn, dann nur äußerst lahm! Runtergebrochen auf einzelne Ausführungseinheiten der GPUs sind diese nämlich deutlich langsamer als die der CPUs (und können dazu eben auch weniger) -> bei der GPU machsts die Masse. Aber eben nur dort, wo Masse auch wirkt...
 
Wie sind wir hier überhaupt auf GPU-Computuing gekommen?...
Das ist doch wohl kaum für Smartphones relevant und auf jeden Fall nochmals etwas anderes als Multithreading auf der CPU.
 
@fdsonne
GPUs sind nicht "dumm" kann man Z.B. auch hier Nachlesen: http://www.cs.utah.edu/~wbsun/kgpu.pdf

Used for more than just graphics processing, modern GPUs have proved themselves versatile enough to be adapted to other applications as well.

Das es Aufagben gibt die sich nur Serial abarbeiten lassen habe ich ja nicht bestritten, das ist mir auch klar.
Aber eine CPU führt nicht nur eine Berechnung pro Takt aus, sondern bis zu 4 Stück (bei AMD).
 
@fdsonne

Danke, genau so und nicht anders ist das und man muss immer anführen, dass wenn man Multi-Threading verwenden kann, irgendwann die systematischen Flaschenhälse zum Tragen kommen. Und Multi-Threading muss nicht automatisch Mehrkern-Unterstützung heißen. Ein modernes OS ist immer in der Lage mehrere Threads (jetzt bitte auch nicht mit HT in einen Topf werfen) scheinbar gleichzeitig abzuarbeiten, denn sonst würde heutzutage nicht mal ein Windows 95 auf einem Single-Core-Prozessor laufen. Eine Mehrkern-Unterstützung als i-Tüpfelchen muss der Compiler bzw. die Sprace dahinter auch unterstützen.

Habe ich bereits stellenweise auch so angeführt.

edit:

@Phantomias

Der Einwurf ist berechtigt, aber nicht massentauglich. Erstens benötigt man immer ein OS, was auf einer GPU laufen kann. Da die meisten PC-Betriebssysteme auf einem x86-Kern laufen, wird es schon schwierig. Da eine GPU sowas nicht kennt und versteht, muss man ein natives OS entwickeln, was mit den Eigenheiten klar kommt. Wenn dann noch Architektur-Wechsel dazu kommen, wird es nicht einfacher. Trotz dessen, dass eine schiere Arbeitsleistung dahinter steht, glaube ich jedoch nicht, dass ein "GPU-Windows" so läuft wie ein "x86-Windows". Jetzt kommt das Aber aus deinem Link, sie lassen das OS weiterhin auf einer Intel-CPU laufen und lassen bestimmte Sachen auf der nVidia-GPU laufen z.B AES-Verschlüsselung oder Netzwerk-Paket-Behandlung. Das hat man jetzt auch schon, wenn man angepasste Software wie Video-Converter oder Add-Ins für Photoshop nimmt.
 
Zuletzt bearbeitet:
Aber eine CPU führt nicht nur eine Berechnung pro Takt aus, sondern bis zu 4 Stück (bei AMD).

Kommt drauf an was du als "Berechnung" bezeichest. Intel erreicht nämlich eine IPC (Instruction per Cycle) von fast 2 und das ist beeindruckend gut. AMD liegt da weit zurück.

@dannyl2912
Klar hat ein OS ein Sheduling, aber "gleichzeitig" abgearbeitet wird da exakt garnichts. Es scheint nur so da so schnell hin und her gesprungen wird.
 
Zuletzt bearbeitet:
Wie sind wir hier überhaupt auf GPU-Computuing gekommen?...
Das ist doch wohl kaum für Smartphones relevant und auf jeden Fall nochmals etwas anderes als Multithreading auf der CPU.

Liegt wohl daran, das Phantomias88 oben mit GPUs um die Ecke kam um uns hier zu erklären, das es ja eben heute schon Technik gibt, die noch viel mehr "Einheiten" hat als CPUs und das es dort ebenso in die Breite skaliert...
Nur hinkt der Vergleich eben extrem gewaltig, weil zwei mehr oder weniger völlig verschiedene paar Schuhe.

PS: gerade im Smartphone/Tablet Bereich könnte GPU Computing für die Zukunft den/einen Druchbruch flächendeckend erreichen... Warum? Es gibt kein mehr oder weniger starres Architekturkonstrukt unten drunter, wie im PC/Notebookmarkt mit x86 ;)

@fdsonne
GPUs sind nicht "dumm" kann man Z.B. auch hier Nachlesen: http://www.cs.utah.edu/~wbsun/kgpu.pdf

Das es Aufagben gibt die sich nur Serial abarbeiten lassen habe ich ja nicht bestritten, das ist mir auch klar.

Wie gesagt, arbeite dich in Softwareentwicklung ein, dann weist du auch, was da geht und was nicht.
Das GPUs "dumm" währen, habe ich im übrigen nie gesagt. Ich sagte: "Die GPU hat je nach Ausbau tausende eher simple Rechenwerke." Was ein kleiner aber feiner Unterschied ist.

Was die Aufgaben angeht, der Knackpunkt ist, das im Grunde alles Sequenziell ist. Schau dir nen Texteditor an. Im Zweifel das minimal benötigte Mittel um zu Programmieren. Nicht mehr und nicht weniger benötigt man um Programmcode zu schreiben.
Und was macht ein Texteditor? -> sequenziell Text darstellen bzw. die Eingabe zulassen.
Das Ganze lässt sich im Grunde recht einfach pauschal erschlagen. Alles, was statisch ist, lässt sich idR ohne weiteres bis ins kleinste Detail mit MT auch beschleunigen. Alles was dynamisch wärend der Laufzeit geschieht, ist idR nur mit großer Mühe, ggf. auch gar nicht aufteilbar.
Das als Beispiele immer irgendwelche Video/Bildbearbeitungssoftware als Garant für Multithreading kommt zeigt ziemlich klar, das die Masse der Leute den Background nicht wirklich verstanden hat ;)
Dynamisch agierende Software massiv auf MT Performance hin zu optimieren ist da ein ganz anderes paar Schuhe. Denn dort benötigt man oftmals "Tricks" -> wie das erhöhen der Last um mehr Ressourcen auch gleichzeitig belegen zu können. Mit Games lässt sich das sehr einfach beschreiben. KI Berechnung lässt sich bis der Arzt kommt aufteilen und via MT abbilden. Physikberechnung ebenso. Zwei Sachen, die fast jedes Spiel auch mitbringt. Und zwei Sachen, die eben Leistung kosten bzw. zwingend benötigen. Der Trick dabei ist ganz einfach erklärt, berechne einfach die KI/Physik für mehrere Gegenstände unabhängig von einander gleichzeitig und nutze so auch gleichzeitig die vorhandenen Ressourcen. -> ergo eine Win:Win Situation. Der Spieler hat mehr BQ und die CPU hat mehr zu tun bzw. weniger ungenutzte Ressourcen. Es ist und bleibt aber ein himmelweiter Unterschied zur Version A mit dem statischen Kontent. Wo man explizit eine einzige Aufgabe derart zerhackstückelt, dass diese über MT schneller zum Ziel kommt.
 
@Phantomias

Der Einwurf ist berechtigt, aber nicht massentauglich. Erstens benötigt man immer ein OS, was auf einer GPU laufen kann. Da die meisten PC-Betriebssysteme auf einem x86-Kern laufen, wird es schon schwierig. Da eine GPU sowas nicht kennt und versteht, muss man ein natives OS entwickeln, was mit den Eigenheiten klar kommt. Wenn dann noch Architektur-Wechsel dazu kommen, wird es nicht einfacher. Trotz dessen, dass eine schiere Arbeitsleistung dahinter steht, glaube ich jedoch nicht, dass ein "GPU-Windows" so läuft wie ein "x86-Windows". Jetzt kommt das Aber aus deinem Link, sie lassen das OS weiterhin auf einer Intel-CPU laufen und lassen bestimmte Sachen auf der nVidia-GPU laufen z.B AES-Verschlüsselung oder Netzwerk-Paket-Behandlung. Das hat man jetzt auch schon, wenn man angepasste Software wie Video-Converter oder Add-Ins für Photoshop nimmt.
Das Dokument ist ja nun schon ein paar Tage alt, ich glaube nicht das hier schon das Ende der Fahnenstange erreicht ist.
Es ging mit nicht darum, das die GPU ein eigenes OS erhält, sondern um die Einsatzmöglichkeiten bei der Programmierung.
Trotzdem Danke für dein Einwurf!
Kommt drauf an was du als "Berechnung" bezeichest. Intel erreicht nämlich eine IPC (Instruction per Cycle) von fast 2 und das ist beeindruckend gut. AMD liegt da weit zurück.
Na wenn das mal kein Mythos wird, mehr IPC ist immer so schwammig. Theoretisch sind maximal nur 1 möglich.
Kannst ja mal mit dem PerfMonitor2 von CPUID nachschauen wie hoch deine "Instructions Per Cycle" sind. Das ist auch von Programm zu Programm unterschiedlich.

Liegt wohl daran, das Phantomias88 oben mit GPUs um die Ecke kam um uns hier zu erklären, das es ja eben heute schon Technik gibt, die noch viel mehr "Einheiten" hat als CPUs und das es dort ebenso in die Breite skaliert...
Nur hinkt der Vergleich eben extrem gewaltig, weil zwei mehr oder weniger völlig verschiedene paar Schuhe.

PS: gerade im Smartphone/Tablet Bereich könnte GPU Computing für die Zukunft den/einen Druchbruch flächendeckend erreichen... Warum? Es gibt kein mehr oder weniger starres Architekturkonstrukt unten drunter, wie im PC/Notebookmarkt mit x86 ;)



Wie gesagt, arbeite dich in Softwareentwicklung ein, dann weist du auch, was da geht und was nicht.
Das GPUs "dumm" währen, habe ich im übrigen nie gesagt. Ich sagte: "Die GPU hat je nach Ausbau tausende eher simple Rechenwerke." Was ein kleiner aber feiner Unterschied ist.

Was die Aufgaben angeht, der Knackpunkt ist, das im Grunde alles Sequenziell ist. Schau dir nen Texteditor an. Im Zweifel das minimal benötigte Mittel um zu Programmieren. Nicht mehr und nicht weniger benötigt man um Programmcode zu schreiben.
Und was macht ein Texteditor? -> sequenziell Text darstellen bzw. die Eingabe zulassen.
Das Ganze lässt sich im Grunde recht einfach pauschal erschlagen. Alles, was statisch ist, lässt sich idR ohne weiteres bis ins kleinste Detail mit MT auch beschleunigen. Alles was dynamisch wärend der Laufzeit geschieht, ist idR nur mit großer Mühe, ggf. auch gar nicht aufteilbar.
Das als Beispiele immer irgendwelche Video/Bildbearbeitungssoftware als Garant für Multithreading kommt zeigt ziemlich klar, das die Masse der Leute den Background nicht wirklich verstanden hat ;)
Dynamisch agierende Software massiv auf MT Performance hin zu optimieren ist da ein ganz anderes paar Schuhe. Denn dort benötigt man oftmals "Tricks" -> wie das erhöhen der Last um mehr Ressourcen auch gleichzeitig belegen zu können. Mit Games lässt sich das sehr einfach beschreiben. KI Berechnung lässt sich bis der Arzt kommt aufteilen und via MT abbilden. Physikberechnung ebenso. Zwei Sachen, die fast jedes Spiel auch mitbringt. Und zwei Sachen, die eben Leistung kosten bzw. zwingend benötigen. Der Trick dabei ist ganz einfach erklärt, berechne einfach die KI/Physik für mehrere Gegenstände unabhängig von einander gleichzeitig und nutze so auch gleichzeitig die vorhandenen Ressourcen. -> ergo eine Win:Win Situation. Der Spieler hat mehr BQ und die CPU hat mehr zu tun bzw. weniger ungenutzte Ressourcen. Es ist und bleibt aber ein himmelweiter Unterschied zur Version A mit dem statischen Kontent. Wo man explizit eine einzige Aufgabe derart zerhackstückelt, dass diese über MT schneller zum Ziel kommt.
z.B.FMA4 ist auch x86: FMA x86

Gut das es die GPUs schon lange haben. ;)
 
PS: gerade im Smartphone/Tablet Bereich könnte GPU Computing für die Zukunft den/einen Druchbruch flächendeckend erreichen... Warum? Es gibt kein mehr oder weniger starres Architekturkonstrukt unten drunter, wie im PC/Notebookmarkt mit x86 ;)
Wie meinst du das? Das "Architekturkonstrukt" der heutigen Smartphones ist doch ARM, oder?

EDIT:
Na wenn das mal kein Mythos wird, mehr IPC ist immer so schwammig. Theoretisch sind maximal nur 1 möglich.
Kannst ja mal mit dem PerfMonitor2 von CPUID nachschauen wie hoch deine "Instructions Per Cycle" sind. Das ist auch von Programm zu Programm unterschiedlich.

Wie jetzt? Du hast doch behauptet AMD Prozessoren könnten bis zu 4 Operationen auf einmal ausführen pro Takt.
Oder meintest du damit 4 Kerne und einfach eine Operation pro Kern? :confused:
 
Zuletzt bearbeitet:
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