News Windows 10 on ARM: Qualcomm nennt Akkulaufzeit von bis zu 18 Stunden

yummycandy

Captain
Dabei seit
März 2005
Beiträge
4.089
Beide kann man perfekt vergleichen. Beide erledigen identische Aufgaben. Der Benchmark vergleicht ja nicht die Struktur, sondern das Ergebnis/Erlebnis.
Wie willst du den Benchmark programmieren? Um die volle Leistungsfähigkeit zu zeigen, müsste KBL zum Beispiel auch AVX2 benutzen, der ARM Core bietet das aber gar nicht. (imho) Mit SSE wirds ähnlich aussehen, also doch nur rein x86 gegen ARM?
 

chithanh

Captain
Dabei seit
Okt. 2013
Beiträge
3.519
SSE und AVX sind x86-spezifische Befehlssatzerweiterungen. Auf ARM machen sie keinen Sinn, dort erfüllt NEON den gleichen Zweck.
 

Eusterw

Lt. Commander
Dabei seit
Juni 2007
Beiträge
1.137
Ich bin kein Benchmark Programmierer. Ich hab auch keine Ahnung wie Geekbench das programmiert hat. Und es ist mir auch egal, ob der PC meines Rechners ein Video nun mit AVX, mit SSE oder mit den Grafikkernen, oder mit allem gemeinsam rendert.

Für mich ist wichtig, was dabei raus kommt. Solange ich da kein unterscheid feststelle, ist mir das System am liebsten, was das am schnellsten macht. Das vergleicht Geekbench. Wie Geekbench nun SSE mit den eigenentwickelten Apple Grafikkernen vergleicht. Keine Ahnung Aber die Punktzahl gibt sehr gut wieder, was man als Anwender auch spürt.
 

Bootinbull

Cadet 3rd Year
Dabei seit
März 2017
Beiträge
60
Welche Programme reizen meine CPU heutzutage noch richtig aus? Spiele, 50 Tabs im Browser und Video umwandeln. Wie sieht es da aus? Schafft das iPad Pro 10,5" auch schon bessere werte als ein i7-8xxx?
 

RedDeathKill

Lt. Commander
Dabei seit
Mai 2011
Beiträge
1.093
Schafft das iPad Pro 10,5" auch schon bessere werte als ein i7-8xxx?
Ein i7 ist en anderes Plaster, da kannst du noch lange warten.

@Eusterw, ARM ist ein kleines Rad und x86 ist ein großes Rad. Wenn man jetzt mit ARM richtige Programme testen würde, dann würde ein ARM Prozessor einbrechen. Du solltest lieber nicht immer den Benchmarks vertrauen, aber Zahlen sind immer schön.
 

Bootinbull

Cadet 3rd Year
Dabei seit
März 2017
Beiträge
60
Verdammt ich habe ein U vergessen. Ich meine die mobile 8. Generation. Reines dekodieren von h264 zu h265.
 

Sephiroth51

Lieutenant
Dabei seit
Mai 2009
Beiträge
686
Für die x86 Hersteller AMD und Intel sehe ich gehörige Probleme. Die x86 CPU's sind evtl. teurer als die ARM in der Produktion dadurch können die Billiger verkauft werden und Qualcomm hätte trotz alledem eine gute Marge.
Wenn sich viele Leute diese Notebooks oder Tablets kaufen für einen geringen Preis und für das was Sie stehen gute Arbeit verrichten erreichen Sie den Massenmarkt. Und das wird ein ganz schöner Umbruch werden. Ob das so gut ist. Der Gewinner wird definitiv Microsoft sein.
Der einfache Kunde braucht nicht viel um zufrieden zu sein. Ist jetzt nur ein Gedanke von mir ohne knallharte Fakten. Es wird jedenfalls sehr spannend.🤔
Vor allem wie Intel reagiert die haben mit Klagen gedroht so viel ich weiß.
 
Zuletzt bearbeitet:

Simpson474

Fleet Admiral
Dabei seit
Sep. 2006
Beiträge
12.695
Bei den Snapdragons heißen die z.B. Hexagon (siehe https://en.wikipedia.org/wiki/Qualcomm_Hexagon). Auch die sog. KI-Beschleuniger von Apple oder HiSilicon sind afaik DSPs.
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.

Die A57-Kernen sind nicht so die Überflieger, die Denver2-Kerne spielen aber in einer Liga mit Qualcomm und Apple.
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.
 

smalM

Captain
Dabei seit
Aug. 2007
Beiträge
3.682
64 Bit Apps sollten sie vielleicht dennoch in Angriff nehmen, gibt doch inzwischen schon sehr viele davon (Vielleicht auch später alles über 64 Bit)
Das wird auf absehbare Zeit nichts, da es viel zuviel Leistung kostet.

Warum sollte jetzt Windows 10 auf ARM plötzlich gut zu befingern sein? Warum sollten die Kacheln jetzt im Tablet Modus hübsch sein?
Was hat die Meinung hier vieler geändert? Der ARM SOC?
Man hofft mal wieder aufs neue auf die eierlegende Wollmilchsau, obwohl das letzte Mal nur ein Meerschweinchen durchs Dorf getrieben wurde...

Die Software hat damit wenig zu tun.
Apples SoCs sind nicht wegen der Software so schnell sondern wegen den Riesigen und schnellen Caches.
Apples SoCs sind so schnell, weil die Performance-Cores für ARM-Verhältnisse geradezu brutal schnell sind. Und die Cores sind so schnell, weil sie viel mehr Daten parallel abarbeiten können als andere ARM-Coredesigns.
Und natürlich hat die Software Einfluß auf die Performance, man sehe sich die miesen Ergebnisse für Apple-CPUs in den Subtests von 3DMark Physics an. Die sind auf die schmalen ARM-Coredesigns optimiert und lassen große Teile der Apple-CPUs Däumchen drehen.

Desktop-CPUs haben in der Regel nur Hardware-AES, während Mobil-SoCs häufig noch weitere Algorithmen in Hardware implementieren um Strom zu sparen.
Dadurch bei den Subtest ARM-SoCs zu begünstigen wurde GeekBench 3 ja immer vorgeworfen. Ab GeekBench 4 wird nur noch AES getestet. Dabei babiert Intel alle ARM-SoCs inklusive den A11 von Apple, auch wenn der doppelt so schnell wie die anderen aktuellen ARM-Designs ist.

Seltsam, wenn ich auf die einzelnen Einträge klicke steht bei denen Geekbench 4.1 dabei.
Ka, aber da sind auch so Nettigkeiten wie ein MacPro6,1 dabei, angeblich mit Core2 Duo Penryn, der dann weiter unten mit 8 CPUs mit zusammen 8 Cores angegeben ist. Die Tryout-Versionen für MacOS und Windows waren wohl nicht so doll...

Die A57-Kernen sind nicht so die Überflieger, die Denver2-Kerne spielen aber in einer Liga mit Qualcomm und Apple.
Denver2 ist ganz ordentlich performant, wenn er mit bereits vorab zu µOps decodierten Programmen gefüttert wird. Bei seinem Einsatzort Automotiv wird er genau das vorgesetzt bekommen. Dabei werden die µOps-Programme am schwachbrüstigen Deodierer vorbei aus dem RAM direkt eingelesen.
Das Konzept funktionierte auch sehr gut in Benchmarks (kleine Programmschliefen, großer Cache für µOps), nur nicht so gut in freier Wildbahn, wo die Performance unvermittelt einbricht (das schmale Frontend kann dann das breite Backend nicht schnell genug füttern).

SSE und AVX sind x86-spezifische Befehlssatzerweiterungen. Auf ARM machen sie keinen Sinn, dort erfüllt NEON den gleichen Zweck.
Geekbench 4 benutzt in verschieden Subtest SSE, AVX oder NEON, je nachdem, was vorhanden ist. Seit 4.1 kann es auch mit AVX512 umgehen.

ARM ist ein kleines Rad und x86 ist ein großes Rad.
Was für ein Käse.
 

Raucherdackel!

Commander
Dabei seit
Jan. 2014
Beiträge
2.336
Ich frage mich ja noch immer ob das mit den Updates dann auch alles Reibungslos läuft. Nicht das ARM dann 6 Monate später seine Treiber nicht mehr anpasst, weitere Funktionen aus nachkommenden Windows 10 Updates dann nicht funktionieren oder wieder ausgeklammert werden müssen usw.

Für Treiber und Co. mag sicher Microsoft viel machen können aber was ist bei Firmware Updates? Selbst heute beklagen ja einige OEM das man ja gerne würde aber es Seitens der CPU Hersteller keine angepassten Treiber gibt und das bei einer reinen Android Version, welche nichts emuliert.

Das wird sicher so wie bei Windows 10 mobile, Update kommt, Funktion X steht dem 835 dann aber nicht zur Verfügung und erst wieder ab dem 850 oder welchen auch immer.

Sollte ich richtig liegen, wird die Sache scheitern. Dann verkommt Windows auf diesem System und der Basis zum Wegwerfprodukt und das ist man bei Windows so nicht gewohnt und man wird sich dran stören.

ARM CPUs sind doch auf Langlebigkeit gar nicht ausgelegt, der Support ist dort doch gar nicht gewünscht und schon gar nicht beim Snapdragon. Ich sehe hier ein Windows RT.

Ich sehe die Sache skeptisch. Ein Surface 3 bekommt heute noch besseren Support als es so ein ARM Gerät nach dieser Zeit wohl noch bekommen würde. Das wäre ein No Go, ARM hin oder her und Emulation hin oder her.
Nein. komplett unsinnig. Windows RT auf dem Surface RT mit Tegra 2 bekommt auch noch regelmäßig Updates, in den letzten 4 Monaten waren das satte 0,92GB.

Und btw, Windows RT war damals schon Android und iOS überlegen, nur wurde es Mangels Akzeptanz - vor allem von den Testern! - überall zerrissen.Android Tablets mit Tegra 2 sind quasi unbenutzbar geworden, ebenso die Ipads aus dieser Epoche. Das Surface RT ist aber immer noch aktuell und schnell genug - auch für leichte Office Aufgaben, das ja vorinstalliert war.

Windows RT war super. Aber die Leute erwarteten ein Tablet OS, das ihre Workstation ersetzen kann. Android und iOS brauchten ja sowas nicht zu können, aber von Microsoft wurde das verlangt.

Es gab kein einziges Review, das dem Surface RT nicht vorwarf, keine Desktopprogramme nutzen zu können...

...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! ;)
 

Ravenstein

Lieutenant
Dabei seit
Sep. 2010
Beiträge
919
Das Konzept klingt gut, freue mich schon auf die ersten Hand on Tests, je nachdem wie dass ganze ausfällt wäre dass die perfekte Lösung für ein Tablett welches endlich auch regelmäßige Updates bekommt, bei Android ist das ja ne Katastrophe (und Appel mit iTunes Zwang kommt mir nicht in die Tüte)
 

Eusterw

Lt. Commander
Dabei seit
Juni 2007
Beiträge
1.137
@Eusterw, ARM ist ein kleines Rad und x86 ist ein großes Rad. Wenn man jetzt mit ARM richtige Programme testen würde, dann würde ein ARM Prozessor einbrechen. Du solltest lieber nicht immer den Benchmarks vertrauen, aber Zahlen sind immer schön.
Ich glaube es werden sich hier noch einige umgucken. Windows scheint auf den „langsamen“ Qualcomms schon ganz schön schnell zu sein.

Sobald Apple seine Laptops auf ARM umstellt (und vielleicht auf 4 große cores geht), wird man sehen, das ARM inzwischen vor x86 liegt. Auf macOS werden die Hersteller ihre Software sicherlich viel schneller neu kompilieren...
 

mgutt

Lt. Commander
Dabei seit
März 2009
Beiträge
1.122
Schön und gut. Doch wie soll sich ARM durchsetzen, wenn Intel alles verklagen wird, was auch nur im Ansatz x86 Emulation betreibt?

Und natürlich würde sich auch AMD sofort einer solchen Klage anschließen. Intel hat MS und QC bereits gewarnt und auf bereits gewonnene Prozesse verwiesen. Also was sagt MS dazu?

Ohne x86 Emulation ist es jedenfalls eine Totgeburt, denn sonst hätte QC bereits den Servermarkt und mit Windows RT den Consumermarkt revolutioniert.
 
Zuletzt bearbeitet:

VinnyD

Ensign
Dabei seit
Apr. 2013
Beiträge
165
Ihr denkt jetzt alle ihr bekommt kleine und leichte Laptops mit 30 Stunden Lauftzeit. lol

Das einzige was das hier bedeutet, ist das Hersteller jetzt 50-80% Akkukosten bei der Herstellung einsparen können um euch das dann für den gleichen Preis wie bisher zu verkaufen.
 

mgutt

Lt. Commander
Dabei seit
März 2009
Beiträge
1.122
@VinnyD
Korrekt, denn sonst würden die Akkus die Haltbarkeit des Notebooks zu stark verlängern und damit würden langfristig weniger verkauft.
 

Mister79

Captain
Dabei seit
Apr. 2008
Beiträge
3.962
...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! ;)
Nein, von Microsoft in Bezug auf Windows erwarte ICH mehr. Android 64 Bit, IOs 64 Bit, Windows mobile 64 bit...

Jetzt fange ich wieder an, die Anwendungen auf 64 Bit als 32 Bit zu suchen oder zu Downloaden? Nö...

Selbst Firefox ist den Weg dann doch mal gegangen. Ich sehe da keinen Grund drin jetzt wieder auf 32 Bit zu gehen.

Wir haben das Produkt noch nicht in freier Wildbahn gesehen aber was ARM betrifft, ich bin so skeptisch, da verliere ich von Anfang an schon das Interesse, gerade wenn vor Veröffentlichung schon wieder Einschränkungen bekannt sind.

Zusätzlich und da können wir dann drüber reden, so bald es veröffentlicht wurde, sehe ich das Gerät in der 500-700 Euro Klasse. In dieser Preisklasse nehme ich keine Einschränkungen hin und selbst wenn es nur 32 Bit ist.

Windows RT war der letzte Schrott, nicht weil das System schlecht gewesen ist, sondern weil es keine Apps gegeben hat.

Bei den Apps gehen wir auch den Weg der 64 Bit und gerade mit den Brücken von MS und jetzt kommt ein ARM mit 32 welches jetzt schon als Player für Media gefeiert wird? Dafür brauch ich kein Windwos. Jedes Ipad ist ein besserer Media Player als ein Gerät mit X86 mit geringer Power und ARM CPU.

Dazu spielt das MS in letzter Zeit schnell wieder einstellt und so tut als hätte es nie gegeben. Puhh ne, da warte ich erst mal auf viele Test, 4 oder 5 Generation und wie die Power wirklich ist.

ARM ist für mich ein Spielzeug und ich kann den Gedanken einfach nicht verwerfen, mehr wird dieses Tablet auch nicht sein.

Zusätzlich hätte ich mehr Vertrauen in einen Mac, in dem eine ARM läuft und Apple von Intel auf ARM umstellen würde. Da würde ich Vertrauen in die Entwickler haben, dass die Software einfach läuft. Bei MS kommt sofort das Gefühlt, ist wieder nichts halbes und ganzes. Wieder Einschränkungen, wieder selektieren der Software nach 64 oder 32 usw.

Selbst die MS Apps sind aus meiner Sicht nicht gut. Outlook ist so übel, wer möchte Outlook als App nutzen? Dann doch lieber Office 365 und dafür brauch ich den Browser. Also x86 nicht notwendig. Der Rest meiner Software läuft auf 64. Was soll ich jetzt damit machen? Läuft ja nicht auf dem Gerät. Ist ein schönes Spielzeug in der vermutlichen 500-700 Euro Klasse.

In weiter Zukunft wird ARM sicher der Sieger werden und X86 einstampfen aber dann laufen die IOS Apps auf einen ARM Mac besser als die X86 auf ARM und bei Apple ganz ohne Einschränkungen. Selbst die Droiden Apps laufen dann besser und ohne das wieder auf irgendwas geachtet werden muss.

Ich sage, floppt.

Auch gehört Qualcomm bei mir nicht zu den Herstellern, welche die CPUs lange Supporten. Da wird wieder irgendwas kommen, warum Gerät mit dem jetzigen Prozessor beim nächsten Update von Windows eine Erweiterung nicht kann oder nicht genutzt werden kann und dann wieder ein neues Gerät nötig ist. Wir reden hier von MS und Qualcomm, da wird es wieder einen Haken geben, warum man sich ein neues Gerät kaufen muss und wenn die OEMs dafür schon sorgen werden.

Da war doch irgendwas bei einer Android Version, warum Geräte erst ab Proxi X ein Update auf Andorid 7(?) bekommt. Irgendwas ist da gewesen. So was sehe ich auch dort kommen.

Entweder weil wieder irgendeine Leistung nicht ausreicht, Änderungen am Kernel vollzogen wurden und dann ein kommendes 6 Monats Update nicht funktioniert. Irgendwas wird man sich dort einfallen lassen. Im Grunde sehe ich ARM mit X86 Emulation, verkommen zum fragmentierten Android. Ja die Fragmentierung kommt bei Android mehr durch die Hersteller spezifischen Änderungen aber ich persönlich befürchte ich, kommt dann dort auch.

Das wird der feuchte Traum für die, ein Windows Gerät mit x86 und maximal 2 Jahre Support und wenn du mehr willst, kauf das nächste Gerät und wir können ja nichts dafür, Qualcomm stellt die Treiber ein
 
Zuletzt bearbeitet:

Limit

Lieutenant
Dabei seit
Mai 2003
Beiträge
815
Wenn sich viele Leute diese Notebooks oder Tablets kaufen für einen geringen Preis und für das was Sie stehen gute Arbeit verrichten erreichen Sie den Massenmarkt.
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.

Ob das so gut ist. Der Gewinner wird definitiv Microsoft sein.
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.

Die DSPs sind für die Benchmarks unerheblich, denn diese sind nur von speziell optimierter Software nutzbar.
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.

Die Hexagon DSPs wurden von Qualcomm hauptsächlich integriert, um die Baseband-Datenverarbeitung zu übernehmen.
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.

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.
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.

Die DSPs unterscheiden sich zwar von der Architektur (meist VLIW) von AVX (SIMD)
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.

aber beim Ergebnis sind AVX und DSP doch sehr ähnlich.
Ihr Einsatzzweck ist ähnlich und auch bei den Strukturen gibt es Ähnlichkeiten, allerdings sind DSPs doch um einiges flexibler, eben wegen SIMD vs MIMD.

Auch der Mischbetrieb ist möglich, bei den VLIW DSPs von Texas Instruments können einige Einheiten SIMD-Befehle verarbeiten.
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.

Es gab kein einziges Review, das dem Surface RT nicht vorwarf, keine Desktopprogramme nutzen zu können...
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.

...und aktuell passiert es wohl schon wieder, da hat Microsoft ein Tablet OS, das doppelte Laufzeit im Vergleich zur Konkurrenz bietet
Du vergleichst ein Notebook mit entsprechend großem Akku mit Tablets, die deutlich kleinere Akkus besitzen. Nicht gerade ein fairer Vergleich.

und dazu noch x86 Code ausführen kann, was die Konkurenz eben nicht kann
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.


Sobald Apple seine Laptops auf ARM umstellt (und vielleicht auf 4 große cores geht), wird man sehen, das ARM inzwischen vor x86 liegt. Auf macOS werden die Hersteller ihre Software sicherlich viel schneller neu kompilieren...
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.
 

Simpson474

Fleet Admiral
Dabei seit
Sep. 2006
Beiträge
12.695
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.
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

Lieutenant
Dabei seit
Mai 2003
Beiträge
815
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 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.

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.
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.
 

Raucherdackel!

Commander
Dabei seit
Jan. 2014
Beiträge
2.336
@Mister79: Deine Meinung setzt sehr anschaulich das voraus, was ich schon geschrieben habe.
Du hängst dich hier zu sehr an den 32bit auf, sieh es mal ganz nüchtern:

iOS kann kein x86 und kein AMD64
Android kann kein x86 und kein AMD64
Windows on ARM kann x86

Und du jammerst weil es kein AMD64 kann...

Nur zur Info: Windows 10 kann Linux unter bash
Windows 10 Mobile kann nativ Android Apps emulieren, wenn man sie per SDK installiert.
https://www.go2android.de/nerd-nische-windows-10-mobile-android-apps-installieren-leicht-gemacht-157917
iOS kann Apps ausm eigenen Store.
Android kann nur .ipk Apps.

Also da sehe ich jetzt mal ganz nüchtern einen Vorsprung für Microsoft...
Und die Legende des leeren App Stores von Microsoft ist seit Jahren überholt. UWP FTW!
 
Top