Eusterw schrieb:
Ein i7 ist en anderes Plaster, da kannst du noch lange warten.Bootinbull schrieb:
Die DSPs sind für die Benchmarks unerheblich, denn diese sind nur von speziell optimierter Software nutzbar. Die Hexagon DSPs wurden von Qualcomm hauptsächlich integriert, um die Baseband-Datenverarbeitung zu übernehmen. Mittlerweile gibt es aber auch ein SDK und Entwickler können die DSP Kerne verwenden: bis auf TensorFlow (Machine Learning) kenne ich jedoch keine Software, welche die Hexagon-DSPs benutzt. Du sprichst ständig von den vielen Fixed-Function Einheiten, welche bei den ARM SoCs vorhanden sind, bei x86 aber nicht. Um welche Einheiten soll es sich dabei handeln? Die Hardwareeinheiten für Crypto existieren auch bei allen x86 CPUs und die Hardwareeinheiten für Video-Decoding bzw. Encoding sind bei Intel CPUs mit Quick-Sync ebenfalls Standard. Die DSPs unterscheiden sich zwar von der Architektur (meist VLIW) von AVX (SIMD), aber beim Ergebnis sind AVX und DSP doch sehr ähnlich. Wie ähnlich, sieht man vor allem bei den Grafikkarten von AMD: vor GCN verwendete man VLIW, seit GCN SIMD. Auch der Mischbetrieb ist möglich, bei den VLIW DSPs von Texas Instruments können einige Einheiten SIMD-Befehle verarbeiten.Limit schrieb:
Denver ist aufgrund der VLIW Architektur ein sehr spezieller Fall und eher mit einem DSP als mit einer "echten" ARM-CPU zu vergleichen. Der Grundgedanke von VLIW ist es, die Komplexität einer CPU so weit wie möglich zu reduzieren (in-order statt out-of-order Execution, keine Branch-Prediction), die ungenutzte Chipfläche dann aber mit ALUs aufzufüllen. VLIW ist aufgrund der vielen ALUs bei einigen Szenarien unglaublich schnell, benötigt dazu aber hohe Parallelisierbarkeit und sehr gute Compiler. VLIW kann aber auch sehr langsam sein, da die CPU bei schlecht optimierten Code zu großen Teilen ungenutzt bleibt. Denver ist sehr ähnlich zu den (gescheiterten) Transmeta CPUs mit x86 Kompatibilität: nativ ist die CPU eine VLIW Architektur, es ist aber eine Zwischenschicht vorhanden, welche ARMv8 Befehle per Binary Translation übersetzt und optimiert. Der Vergleich VLIW mit x86 ist auf jedem Fall viel schwieriger als der Vergleich einer "echten" ARM-CPU mit x86.Limit schrieb:
DerKonfigurator schrieb:
Mister79 schrieb:
Atent123 schrieb:
Limit schrieb:
Limit schrieb:
Limit schrieb:
chithanh schrieb:
RedDeathKill schrieb:
Mister79 schrieb:
Ich glaube es werden sich hier noch einige umgucken. Windows scheint auf den „langsamen“ Qualcomms schon ganz schön schnell zu sein.RedDeathKill schrieb:
Raucherdackel! schrieb:...und aktuell passiert es wohl schon wieder, da hat Microsoft ein Tablet OS, das doppelte Laufzeit im Vergleich zur Konkurrenz bietet, und dazu noch x86 Code ausführen kann, was die Konkurenz eben nicht kann, und trotzdem ist die breite Meinung hier in diesem Thread negativ.
Warum? Freut euch doch, Android als Tablet OS ist doch grauslig!
Wenn man sich anschaut, dass man billiger ein x86 Notebook als ein SD835 Smartphone bekommt habe ich so meine Zweifel was den Preis angeht. Aber evtl. subventionieren Qualcomm und MS das Projekt eine Zeit lang. Das wäre dann eine Art Netbook 2.0.Sephiroth51 schrieb:
Wenn x86-Windows-Notebooks durch ARM-Windows-Notebooks ersetzt werden, was gewinnt MS dabei außer dass sie nun zwei Plattformen pflegen müssen? Im Vergleich zu den Tablets mit iOS / Android fällt ihnen das Hauptzugpferd (längere Laufzeit) weg, weil die die gleiche Hardware verwenden und Windows nicht den Ruf hat besonders resourcenschonend zu sein.Sephiroth51 schrieb:
Afaik werden die Hexagon DSPs durch die gängigen Compiler (LLVM, GCC) unterstützt, d.h. prinzipiell braucht man nur die richtigen Flags setzen und sie werden mitbenutzt. Aufgrund der Architektur ist da handoptimierter Code natürlich deutlich besser, aber das ist bei SSE, AVX, Neon usw. auch nicht anders.Simpson474 schrieb:
Die in aktuellen SoCs verwendeten DSPs haben mehrere Kerne (afaik 3), wovon min. einer für allgemeine Aufgaben zur Verfügung steht. Mit vier Instr./Takt, vierfach Multithreading und gleichem Takt wie die Kyros hat er für DSP-Verhältnisse schon ordentlich Leistung.Simpson474 schrieb:
Laut Qualcomm werden die DSPs u.A. für die Verarbeitung von Audio-, Kamera-, GPS- und anderen Sensordaten, sowie für die Bioemetrie verwendet. Da Qualcomm das aber ohne Hinweis auf bestimmte Software/Betriebssysteme angibt, vermute ich, dass diese Funktionen auf einem der beiden nicht frei verfügbaren DSP-Kernen läuft.Simpson474 schrieb:
Nur als kurze Anmerkung: SIMD beschreibt keine Architektur, sondern ist eher eine Klassifizierung für Architekturen. VLIW ist z.B. MIMD (Multiple Instructions, Multiple Data), während ein typischer Vertreter für SIMD z.B. Vektorrechner sind.Simpson474 schrieb:
Ihr Einsatzzweck ist ähnlich und auch bei den Strukturen gibt es Ähnlichkeiten, allerdings sind DSPs doch um einiges flexibler, eben wegen SIMD vs MIMD.Simpson474 schrieb:
Wenn man bei VLIW in jedem Taktzyklus für alle Daten die gleiche Instruktion mitgibt hat man im Prinzip eine Vektoreinheit. Ich vermute, dass es bei dem TI-DSP wohl hauptsächlich darum ein wenig Speicher-/Cache zu sparen, denn im "SIMD-Modus" braucht man die Instruktion dann nur ein einnziges mal.Simpson474 schrieb:
Naja, das ist eben, was die Leute von einem Windows erwarten. Lässt man das weg, ist es nur ein Mobil-OS wie viele andere auch. Mmn lag das Problem darin, dass sie zu spät kamen. iOS und Android hatten sich schon etabliert und damit eine entsprechend größere Auswahl an Apps und Hardware. Widnwos RT hätte ein starkes Alleinstellungsmerkmal gebraucht.Raucherdackel! schrieb:
Du vergleichst ein Notebook mit entsprechend großem Akku mit Tablets, die deutlich kleinere Akkus besitzen. Nicht gerade ein fairer Vergleich.Raucherdackel! schrieb:
Die entscheidende Frage hier ist wieviel diese x86-Unterstützung im Endeffekt Wert ist, denn ohne Unterstützung der Befehlssatzerweiterungen (SSE, AVX), die, genau wie AMD64, noch unter Patentschutz stehen wird einige Software überhaupt nicht darauf laufen und andere deutlich ausgebremst und dabei ist ein möglicher Overhead der Emulation noch garnicht mit berücksichtigt. Natürlich wird das für einfache Programme reichen, aber andererseits kann man Internetsurfen, ein bisschen Office und Videos schauen auch mit jedem Android Tablet mit Ansteck-Tastatur.Raucherdackel! schrieb:
Die Prophezeiung eines Umstiegs von x86 auf eigene ARM-SoCs bei den Macs ist so alt wie die eigene ARM-SoCs selbst. Sicherlich könnte das irgendwann geschehen. Für das normale MacBook würde das vermutlich schon heute gehen. Aber schon beim MacBook Pro und erst Recht bei iMac und Mac Pro ziehen die Intel-CPUs auf und davon. Weiterhin dürften Drittanbieter wenig begeistert davon sein zwei verschiedene MacOS-Varianten parallel zu unterstützten, was aber notwendig wäre, wenn man nicht alle Macs gleichzeitig umstellt.Eusterw schrieb:
Das ist so schlichtweg falsch. Es mag GCC und LLVM für die Hexagon DSPs geben um spezielle Programme für den DSP zu schreiben: in den ARM-Code werden aber garantiert keine Befehle für die Hexagon DSPs eingefügt. Das ist einer der Unterschiede zu AVX: AVX Befehle können von GCC und Co. für Performanceoptimiertungen durchaus automatisch eingefügt werden (falls entsprechende Flags gesetzt sind), damit läuft das Programm anschließend aber auch nur noch auf unterstützten CPUs.Limit schrieb:
Das ist richtig, aber das habe ich ja auch überhaupt nicht behauptet. Das ginge allein schon wegen der unterschiedlichen Befehlssätze nicht. Was allerdings geht ist sog. offloading. Dabei kann der Entwickler Codeabschnitte annotieren. Diese werden dann nicht nur für die eigentlich ISA (hier ARM), sondern auch für einen Beschleuniger (hier DSP) compiliert. Zusätzlich wird Code generiert, der die Übergabe von Code und Daten an den DSP erledigt und die Ergebnisse an das Hauptprogramm zurückgibt. Das selbe Prinzip nutzt man z.B. bei OpenACC um bei normalen x86-Programmen Teile an einen Beschleuniger (z.B. GPUs) auszulagern, die ja bekanntlich auch keine einheitliche ISA haben.Simpson474 schrieb:
Häufig werden entsprechende Funktionen auch einfach in einer AVX und in einer non-AVX Version miteincompiliert und erst zur Laufzeit entschieden welche Variante ausgeführt wird.Simpson474 schrieb:
