News Analyse zum Snapdragon X Elite: Alles andere als ein voller Erfolg wäre totales Scheitern

Die integrierte GPU eines Core i7-13800H schlage die eigene, mit 4,6 TFLOPS beworbene Adreno-GPU mit der doppelten Leistung bei demselben Verbrauch oder 74 Prozent weniger Verbrauch bei derselben Leistung.
Hadert hier mein Leseverständnis oder steht hier, dass das Intel Pedant die eigene Adreno GPU schlägt?
 
  • Gefällt mir
Reaktionen: M11E
Smeany schrieb:
Hadert hier mein Leseverständnis oder steht hier, dass das Intel Pedant die eigene Adreno GPU schlägt?

das ist eine recht coole passive/konjunktiv-Konstruktion.
"schlage".
Also schlägt passiv. Die Intel GPU wird durch die eigene (Adreno-) GPU (welche mit 4.6 Tflops theoretisch antritt) geschlagen,

Was allerdigns tatsächlich nicht im Satz steht (das würde ihn noch komplizierter machen), in der Grafik aber schon drin ist, ist das magische Wörtchen "Up to", also BIS ZU.
BIS ZU Angaben heißen halt alles mögliche. Eine Geforce 4090 produziert halt auch bis zu 3x so viele FPS wie eine 3090, wenn letzterer die RT Power ausgeht und in Spielen wo FG funktioniert (und dann auch nur in bestimmten Szenarien).
 
  • Gefällt mir
Reaktionen: Smeany
BAR86 schrieb:
Einerseits sagst du x86 ist am Ende, andererseits siehst du im Laptop/PC Markt kein ARM weil Microsoft es nicht hinkriegt...
Doch ich plädiere ja dafür, nur sehe halt noch immer den desolaten Zustand.
Loopman schrieb:
Was soll man daran verbessern? Es ist Windows 11.
Nur läuft unter Arm halt nicht jede x86 Software.
Nein, das ist so nicht der Fall…

  • x86-Anwendungen fühlen sich extrem zäh an und werden unzureichend emuliert
  • Noch immer gibt es kaum ARM-kompatible Windows-Treiber für Peripheriegeräte.
  • Die x86-Emulationsschicht frist jeden Leistungsvorteil der Arm-SoCs auf

Aktuell scheint die Strategie „lahm und teuer“ zu sein. Damit lässt sich kein Blumentopf gewinnen.
 
  • Gefällt mir
Reaktionen: Fallout667, KlaasKersting, cruscz und eine weitere Person
Hätte das Teil ordentlichen Linux-Support, ich wäre sofort dabei.

Aber Qualcomm hat keinen Bock auf Linux, Microsoft hat keinen Bock auf ARM und ich als Kunde habe keinen Bock mich mit denen herum zu ärgern.
 
  • Gefällt mir
Reaktionen: ace-drink, M11E, mae und 7 andere
ghecko schrieb:
Hätte das Teil ordentlichen Linux-Support, ich wäre sofort dabei.

Aber Qualcomm hat keinen Bock auf Linux, Microsoft hat keinen Bock auf ARM und die Kunden haben keinen Bock auf das Drama.

Aber ich hab Bock, so ganz generell halt.
Meine Frau halt nicht
 
  • Gefällt mir
Reaktionen: ZeusTheGod
FX-Multimedia schrieb:
Ich kann mich nur wiederholen:
Bringt sowas wie "Rosetta 2" in Windows, also das quasi alle x86 Programme in Windows on ARM laufen und das ganze wird ein riesen Erfolg. So lange das nicht gegeben ist, ist das Projekt bereits jetzt schon zum scheitern verurteilt.
Gibt es das nicht in Windows ARM? Ich habe mir auf meinem MacBook eine Windows 11 ARM Installation in Parallels aufgesetzt. Darin lasse ich ein Programm laufen, dass in x86_64 vorliegt. Funktioniert wunderbar.
 
  • Gefällt mir
Reaktionen: dualcore_nooby
sikarr schrieb:
Warum in Hardware, das wäre vergeudetes Silizium?
Link - Ich glaube ihm da einfach mal, weil ich selbst viel weniger Ahnung von der Materie habe.
Ich bin aber glücklicher Besitzer eines Macbook Pro (2020 - M1) und habe mit Windows on ARM auf einem Windows Dev Kit 2023 (Project Volterra) mit Snapdragon 8cx Gen 3 rumgespielt:
Browser, Office und paar native Anwendungen sind ganz gut. Creative Cloud ist zäh und gönnt sich Nachdenkpausen. Steam und kleinere Spielchen kann man komplett vergessen.
 
  • Gefällt mir
Reaktionen: KlaasKersting
FX-Multimedia schrieb:
Selbst bei Adobe liefen viele Programme lange über Rosetta (AfterEffects, MediaEncoder etc.). Aber sie liefen, und das sogar erstaunlich performant.
Ich bin mir sicher, dass Adobe im Hintergrund Himmel und Hölle bewegt hat, um seine Programme ebenfalls lauffähig zu machen, dass wird nur nicht so einfach zu wuppen gewesen sein. Rosetta war sicher ein hilfreiches Übergangstool, das - soweit ich mich erinnere - von Apple auch als solches dargestellt wurde. Support für Rosetta sollte es ebenfalls nicht ewig geben.
Dennoch bleibt es dabei. Bei Apple gibt es für Developer keine Alternative. Es gibt halt keine kompatiblen Geräte von HP, Dell und Co., die weiterhin mit MacOs auf x86 laufen würden. Entweder es läuft nativ auf aktueller Apple Hardware oder man hat - Rosetta hin- oder her - auf Dauer ein Riesenproblem.

MS kann sowas wie Rosetta sicher auch anbieten, ist ja schließlich ein riesen Software-Konzern. Und trotzdem wäre die Motivation, etwas für Windows on Arm zu entwicklen, seeehr viel geringer, solange die x86 Plattform so breit aufgestellt ist.
MS müsste meiner Meinung nach mit einem OEM kooperieren, ein entsprechendes Gerät rausbringen, das voll und ganz auf Windows on Arm zugeschnitten ist. Und dieses Gerät müsste in Sachen Leistung/Effizienz/Preis so viel besser als Intel und AMD mit ihren Mobilprozessoren sein, dass man das im Alltag auch wirklich spürt. Genau das sehe ich nicht.
 
  • Gefällt mir
Reaktionen: Fallout667
Ich hab ein Windows on ARM Tablett mit einem Snapdragon 850.
Das laeuft, und seit dem Upgrade auf Windows 11 laeuft grundsaetzlich auch 32bit x86 Software (Unter Windows 10 ging nur 64bit x86 Software)

Aber das Ding ist einfach grottenlangsam. Und da laeuft schon eine ziemlich bloatfreie Education Edition.
 
Lenovo mit an Board würde mich freuen wenn sie ein oder generell Linux kompatible Systeme raus hauen würden zum regulären Preis ohne dafür Aufpreise zu nehmen, so sie Zertifiziert sind wie sie es die letzten Jahre getan haben. Ebenso gehört Dell dazu und bin wirklich gespannt ob sich da etwas ändern wird.
 
EdgarTheFace schrieb:
Ich glaube ihm da einfach mal, weil ich selbst viel weniger Ahnung von der Materie habe.
Mein Gedankengang ging jetzt eher in die Richtung das man in Software einfach flexibler ist was Anpassungen bedarf.
1. ist es ja wenn dann eh nur eine temporäre Lösung, also bis die Umstellung erfolgt ist
2. lassen sich so Optimierungen, Sicherheitsupdates usw. besser umsetzten.

Wenn man das in Hardware gießt wird sich am Ende nichts ändern und man lebt mit dem Mist bis in alle Ewigkeit, so wie es ja unter Windows schon jetzt ist.
EdgarTheFace schrieb:
Browser, Office und paar native Anwendungen sind ganz gut.
Ja kann ich bestätigen, ist halt die Frage liegts an der Hard oder Software?
 
@sikarr @EdgarTheFace Ich schalte mich mal ein: In dem X-Beitrag steht, dass das unterschiedliche Speicherlayout bei x86 und ARM Probleme für die Emulation auf Windows sind. Da ist nichts von "hardwarebeschleunigter x86-Emulation" gemeint. Die Emulation läuft genau wie bei Apple in Software.

Das Speicher- und Cachelayout hat Apple aber anscheinend sehr geschickt gelöst, was sowohl Rosetta begünstigt als auch die grundsätzliche Leistung verbessert.
 
  • Gefällt mir
Reaktionen: sikarr
cruscz schrieb:
Bei 70% weniger Energiebedarf (der sehr geschönt ist aufgrund des Vergleichsprozessors, die HX-Serie verbrennt in Relation wesentlich mehr Energie als z.B. ein U-Modell)
Klassisch Qualcomm, wie ich ja schon schrieb, 70% whatever in einer Marketingfolie schafft man nur wenn man nicht die selben Maßstäbe anlegt. Intel bsp. ist schon lange kein Maßstab für x86 mehr. Erst recht nicht bei Effizienz unter Last. Und im APU/Notebook-Monolith Bereich sollte AMD im Idle auch "mithalten" können.
Ein ARM wird nicht die selbe Leistung haben, da wie du schreibst:
cruscz schrieb:
Problem bleibt eher die Kompatibilität von Windowsanwendungen, da sehe ich keine hohe Chance ohne das Microsoft den Spagat macht eine unscheinbare Virtualisierung einzubauen oder zumindest eine zusätzliche Kompatibilitätsschicht einzubauen.
Also wenn man etwas mit ARM nicht darstellen kann ist die Leistung dann "Null" im Vergleich.
Und genau daher existiert ja x86 auch.
ARM kann nicht gegenhalten wenn es das selbe können soll.
Außer natürlich man entwickelt vorher die gesamte Software der x86 Welt neu oder erschafft den "magischen" Compiler der keine Rechenleistung / Effizienz zieht.

Und ja wie du und ich schon schrieben wird das ohne 100% Microsoft Engagement absolut gar nichts.
Eher noch vermute ich erreicht bsp. Valve per Steam eine 100% Spielekompatibilität unter Linux als andersherum Microsoft mit Windows alle Apps in ARM unterstützt.

cruscz schrieb:
onst sind es eher hochpreisige Geräte für Linuxenthusiasten die wie üblich notgedrungen ein Windows mitkaufen.
Also nichts neues^^
 
  • Gefällt mir
Reaktionen: Aquilid
Linux!

Wieso Windows? Qualcomm wurde von Microsoft schon gründlich verarscht mit dem Exklusivvertrag. Nochmal ins Knie schiessen?!

Qualcomm hat extra die Benchmarks mit Linux präsentiert. Wenn sie jetzt nochmal mit Windows und den quellgeschlossenen Anwendungen kommen - wird es wieder nichts. Windows kann man vielleicht portieren, aber die Anwendungen eben nicht. Die sind bei Windows alle quellgeschlossenen und laufen entweder nicht oder wegen Emulation.

Lenovo liefert die ThinkPads mit Linux aus. Da muss man nur noch die Quellen liefern. Dem berüchtigten X13 mit “s” mit Qualcomm fehlt was, Linux. Ich habe hier ein X13 ohne s mit AMD und Qualcomm WiFi, fertig ausgeliefert mit Linux. Läuft! Und ich kann Steam verwenden, mit nativen Spielen wie CS2. Wenn Qualcomm jetzt nicht lernt das man einen Markt anschieben muss und mit kleinem Volumen und gutem Produkt anfängt - kann man ihnen auch nicht helfen.
Valve hat das verinnerlicht. Mit viel Anlauf zum Erfolg.

Den einen kleinen Geniestreich gibt es nicht. Außer man greift zu illegalen Mittel (Microsoft weiß ja wie das geht, Vertriebsvertrag mit Windows-Zwangsbundle im Stil der 90er…) und davor hat Microsoft erstmal IBM mit einem Abklatsch von CP/M verarscht und dann gleich nochmal mit OS/2. Und Qualcomm hat sich schon reinlegen lassen. Wie oft den noch?

Der Snapdragon X Elite scheint tatsächlich der große Wurf zu sein, auf den man seit Jahren bei Qualcomm und bei der Windows-Kundschaft gewartet hat.

Falsch. Wer Windows nutzt will das alles genau so bleibt wie bei Win95. Und da wird der Rechner mit Intel bestellt. Nie mit AMD - auch wenn sie deutlich besser sind. Auf Linux wird nicht umgestellt, da müsste man lernen.

Die Windows-Kundschaft wird einen Teufel tun. Der Rest hat sich ein Steamdeck bestellt ;)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Aquilid
@flaphoschi: Dann muesste Qualcomm aber die Geraetehersteller dazu bewegen entweder einheitliche Peripherie zu verbauen, oder sich stark machen etwas zu entwickeln das fuer ARM das sein kann was fuer x68 das BIOS/UEFI sind.
Denn sonst brauchst du fuer jede Variante Anpassungen am Linux, weil es eben keine einheitliche Hardwarebasis gibt.

Ich haette auf meinem Hyrican Tablett gerne ein Linux installiert, aber es geht trotz offenem Bootloader einfach nicht, und um ein Linux selber entsprechend anzupassen fehlt mir das KnowHow.
 
  • Gefällt mir
Reaktionen: flaphoschi
Rage schrieb:
Ich schalte mich mal ein: In dem X-Beitrag steht, dass das unterschiedliche Speicherlayout bei x86 und ARM Probleme für die Emulation auf Windows sind.
Da muss ich mich noch mal einklinken:

Hier muss man aufpassen, was man am Ende genau meint mit dem Speicherlayout. Es geht in diesem Fall nur bedingt um das Speicherlayout, als viel mehr um die Unterschiede in der ISA und wie sich das auf das Datensubsystem auswirkt.

x86 kennt im 32 Bit-Modus 8 Register, im 64 Bit Modus 16 Register. ARMv8/v9 31 Register. Ich lass mal die SIMD weg, der Einfachheit. Das Problem bei x86 ist, dass ein Compiler relativ früh auf das Speichersystem zugreifen muss, um Daten im Cache als auch RAM zwischenzuspeichern, während bei Arm der Compiler so etwas länger herauszögern kann.

Und genau hier liegt die Krux für die Emulation von x86-Code auf Arm-basis und warum hier auch richtig Leistung liegen bleiben kann. Intel beschreibt bei der neuen APX-Erweiterung das Problem sehr gut, hier wird auf 32 Register erweitert: "... as a result, APX-compiled code contains 10% fewer loads and more than 20% fewer stores than the same code compiled for an Intel® 64 baseline ..."

Arm kann ein schmaleres Speichersubsystem im Kern haben und benötigt nicht so viele Load- und Store-Einheiten, wie x86. Und hier liegt auch das Problem. Sofern das Speichersubsystem nicht auf ein x86-Workload ausgelegt ist, geht Leistung verloren, weil hier bei den Load- und Store-Anweisungen ein Flaschenhals entsteht und der Kern sich in der Regel "langweilt" und nicht ausgelastet werden kann, man wartet auf Daten.
 
  • Gefällt mir
Reaktionen: Fallout667
derin schrieb:
Ohne ein angepasstes OS bringt das alles nichts.
mit linux wäre das teil echt sehr sehr nice.
in der windows welt kommt es doch nicht nur auf das os oder die treiberverfügbarkeit, sondern auch auf die anwendungen der user und hier liegt häufig der hund begraben.
wenn es um ein bisschen office geht ist das alles kein problem, aber wehe die gebrauchte anwendung ist eine nischen-software die es für arm garnicht gibt oder die aufgrund niedriger arm verbreitung garnicht portiert wird...
 
Zuletzt bearbeitet: (typos...)
  • Gefällt mir
Reaktionen: flaphoschi
DevPandi schrieb:
Dazu muss auch hier Qualcom bereit sein, entsprechende Treiber und Co für Linux bereit zustellen, das ist aber bei der Firma eher utopisch!

Da hast Du wahrscheinlich Recht, das hatte ich nicht bedacht. :)
 
cypeak schrieb:
wenn es um ein bisschen office geht ist das alles kein problem, aber wehe die gebrauchte anwendung ist eine nischen-software die es für arm garnicht gibt oder die aufgrund niedriger arm verbreitung garnicht portiert wird...
Und deswegen muss man ein Ultimatum setzen und den x86 Ast konsequent abschneiden.
Nur dann bewegt sich was.
 
  • Gefällt mir
Reaktionen: Saint81
Ranayna schrieb:
@flaphoschi: Dann muesste Qualcomm aber die Geraetehersteller dazu bewegen entweder einheitliche Peripherie zu verbauen, oder sich stark machen etwas zu entwickeln das fuer ARM das sein kann was fuer x68 das BIOS/UEFI sind.
Denn sonst brauchst du fuer jede Variante Anpassungen am Linux, weil es eben keine einheitliche Hardwarebasis gibt.

Ich haette auf meinem Hyrican Tablett gerne ein Linux installiert, aber es geht trotz offenem Bootloader einfach nicht, und um ein Linux selber entsprechend anzupassen fehlt mir das KnowHow.
Deswegen erwähne ich Lenovo :)
Da wäre die Hilfe vor der Nase. Und Valve. Und Purism. Und System 76. Und die RasPi-Truppe.

Qualcomm selbst ist bisher das Problem. Atheros ist Teil von Qualcomm, deren quelloffene Kernelmodule laufen seit bald 20 Jahren mit Linux. Und mit einem sehr guten Ruf. Qualcomm hat ist bisher nur quellgeschlossenen Kernelmodule geliefert. Eine der Gründe warum Android selten Updates bekommt, neuer Kernel passt nicht zum quellgeschlossenen Frickeltreiber in Windowsmanier. Bei Allzweckcomputern nicht hinnehmest, es funktioniert jetzt auch nicht mehr im Embeddedbereich.

Wenn Qualcomm Erfolg will, müsse sie Arbeit investieren und Kollabieren. Gute Chips reichen nicht, dass muss alles passen.
 
Zuletzt bearbeitet:
Zurück
Oben