News Project Limitless: Qualcomm zeigt Snapdragon- vor Intel-Notebook

[Jan]

Qualcomm und Lenovo geben zur Computex erstmals einen Ausblick auf die 3. Generation der immer mit dem Internet verbundenen Windows-10-Notebooks mit Snapdragon-SoC. Das „Project Limitless“ nutzt die zum MWC angekündigte Kombination aus Snapdragon 8cx und X55 und schlägt damit in Benchmarks die Konkurrenz mit Whiskey Lake.

Zur News: Project Limitless: Qualcomm zeigt Snapdragon- vor Intel-Notebook

 

[Krautmaster]

Ne Alternative zu X86 wäre wirklich was. Aber auch nur dann wenn man als Anwender keine Unterschied merkt auf welcher Hw man zuwerke ist.

 

[SlaterTh90]

Wie sieht’s eigentlich bei Linux aus - so ein Gerät finde ich schon ganz interessant. Windows will ich aber auf keinen Fall benutzen, wenn es sich irgendwie vermeiden lässt.

 

[CastorTransport]

Ne Alternative zu X86 wäre wirklich was. Aber auch nur dann wenn man als Anwender keine Unterschied merkt auf welcher Hw man zuwerke ist.

Ja das alte Thema. Ich hatte auch mal ein Windows RT Tablet und da müssen halt auch alle Apps für umgebaut/umgeschrieben werden. Ich weiß nicht mehr genau - damals zu Windows Phone 10 Zeiten arbeitete MS ja an so nem "Interpreter" (Unified/Universal Apps?!), damit das einfach wird... Aber wir wissen ja, wo WPhone nun steht.

 

[BiGfReAk]

Der Chip kann h265 en- und decodieren.
Wie ist denn die Leistung mit Handbrake ne Bluray in h265 (bzw x265) zu codieren? Theoretisch müsste die Leistung weit über die von Intel liegen, da die Chips ja auch den Videostream in den Handys beim Aufnehmen eines Videos direkt in h265 codieren können. Würde mich nicht wundern wenn der kleine Chip die großen Intel und AMD Modelle in der Hinsicht schlagen könnte. Und Nvidia mit NVENC zumindest in Sachen Qualität ebenso.

 

[Steini1990]

Mir kann ARM auf Notebooks oder Desktopsystemen gestohlen bleiben. Solange ich bei ARM nicht auch so wie bei x86 einfach jedes Betriebssystem meiner Wahl aufspielen kann habe ich kein Interesse. Die Treiberprobleme der Smartphones will ich bei solchen Geräten auf keinen Fall haben.

 

[Schtefanz]

Ich würde ein Notebook interessant finden was beide Architekturen verbaut hat x86 und Arm da könnte man im Desktop den sparsamen ARM Prozessor benutzen und in den anderen Programmen welche nicht nativ auf ARM Chip laufen den x86 Chip. Das würde sicher auch viele Entwickler interessieren da sie nicht ihren Code auf einer anderen Maschine kompilieren müssen

 

[incurable]

Tests gegen bald 2 Jahre alte CPUs sind immer überzeugend, besonders wenn die eigenen Produkte noch ein Jahr von der Marktreife entfernt sind.

Aber so ist Qualcomm hat, langsam und ungeniert.

 

[WinnieW2]

Das Konzept finde ich schon interessant, aber die Sache steht und fällt mit dem Gerätepreis u. der Verfügbarkeit von nativen Win-ARM64-Programmen.
x86-Programme per Emulation auf solcher Hardware laufen zu lassen halte ich nur für eine Notlösung.

 

[andi_sco]

Für mich war die erste Generation mit Snapdragon 808/810, denn da ging es los, mit einem ARM SoC als Windows CPU

Ergänzung (29. Mai 2019)

...damals zu Windows Phone 10 Zeiten arbeitete ...

UWP Universal Windows Plattform

 

[Eusterw]

Sobald Apple (und ich glaube das kommt bald), in den eigenen Rechnern auf ARM wechselt, kommt ganz gehörig Druck auf der PC-Seite auf.

Die ARM-Konstellation ist oft günstiger, ab dann vermutlich schneller und eine Menge Desktop-Software (MS Office, Photoshop, Browser, ...) wird dann schon für den Mac sehr optimal auf ARM angepasst werden. Da wird es ein kleiner Schritt, das für Windows zu dublizieren.

Auf Intel könnten "interessante" Zeiten zukommen...

 

[Ozmog]

Mehr Konkurrenz auf dem CPU-Markt ist zu begrüßen. Meine Bedingung bleibt aber eine volle Unterstützung von Windows und der darauf laufenden Programme. Sollten da mit Notlösungen a la Emulation oder auch nur performancetechnisch unzufrieden laufen, reicht es allerdings nicht zu eine ernstzunehmende Konkurrenz zu X86.

 

[Keizo]

Der Chip kann h265 en- und decodieren.
Wie ist denn die Leistung mit Handbrake ne Bluray in h265 (bzw x265) zu codieren? Theoretisch müsste die Leistung weit über die von Intel liegen, da die Chips ja auch den Videostream in den Handys beim Aufnehmen eines Videos direkt in h265 codieren können. Würde mich nicht wundern wenn der kleine Chip die großen Intel und AMD Modelle in der Hinsicht schlagen könnte. Und Nvidia mit NVENC zumindest in Sachen Qualität ebenso.

Intel kann seit Sky Lake HEVC in 8bit de- und encodieren, seit Kaby Lake auch in 10bit. Von daher sehe ich da Hardwareseitig keine Vorteile auf Seiten Qualcomms. Wäre aber generell schon schön, Hardware mit ner besseren HEVC-Enkodierleistung zu bekommen. Aber ich fürchte, bevor die kommt, steht mit AV1 wieder ein neuer Codec ins Haus, auf den die Hardware optimiert werden darf. And the wheel keeps spinning.

 

[HerrRossi]

Von Debian gibt es ja eine Version mit XFCE für arm64, das wäre schon interessant, je nachdem wie die Gerätepreise ausfallen.

 

[sdo]

Das Problem ist doch nicht mal die Leistung, Software oder sonstiges was ihr hier nennt, sondern die völlig überteuerten Preise. Wer gibt denn über 1000€ für halbbackenes System aus?

Früher hatte Qualcomm noch riesig Werbung damit gemacht wie günstig die Systeme sein werden. Damit haben die nun aufgehört. Bei Preisen jenseits der 600€ sind die Notebooks wieder DoA.

 

[Bigfoot29]

@HerrRossi: Das Problem ist weniger die Architektur der CPU. "aarch64" (ARM 64Bit) gibt es schon seit Jahren. Das Problem ist, dass die ARM-Systeme, anders als X86, bei weitem nicht so standardisiert sind, wie x86-HW. Jeder Hersteller kann bei ARM eigene Busse implementieren, um mit verbauter Technik zu interagieren und Hardware einklinken, für die nichtmal Beschreibungen bereitstehen, geschweige denn Schnittstellen-Specs bereitstehen.

So muss für jedes Gerät derzeit ein eigener Gerätebaum ("Device Tree") im Kernel hinterlegt werden. Weicht die Nachfolge-Revision auch nur geringfügig davon ab, gehen Teile der Hardware schon nicht mehr, weil der Gerätebaum wieder angepasst werden muss. Ein "Plug and Play" Dank standardisierter Hardware-Schnittstellen (ACPI-Tabellen) und festgelegter Busse (USB, PCI(e)) mit selbstmeldenden Geräten, die dann nur noch mit dem richtigen Treiber verbunden werden müssen, sind bei ARM-Geräten noch weit, weit weg.

Selbst Linus Torwalds wünscht sich zwar entsprechende Geräte, sieht sie aber in aktuellen ARM-Geräten noch nicht.

Regards, Bigfoot29

 

[Dr. MaRV]

Ja das alte Thema. Ich hatte auch mal ein Windows RT Tablet und da müssen halt auch alle Apps für umgebaut/umgeschrieben werden. Ich weiß nicht mehr genau - damals zu Windows Phone 10 Zeiten arbeitete MS ja an so nem "Interpreter" (Unified/Universal Apps?!), damit das einfach wird... Aber wir wissen ja, wo WPhone nun steht.

Ich bin der Meinung das Projekt war nicht für Windows Phone, sondern Windows on ARM und wurde damals eingestellt, weil sie keine Erlaubnis bekamen, die x86 Befehlssätze auf ARM zu nutzen. Das war einfach ein Emulator.

 

[HerrRossi]

Danke für die Erläuterung @Bigfoot29

 

[Bigfoot29]

Bitte werft mit Windows on ARM, den Unified/Universal Apps und Befehlssätzen nicht so viel durcheinander.

Windows on Arm ist ein Windows, welches die ganz normalen Schnittstellen (DirectX, Whatever) nach außen hin bereitstellt und für eine andere Architektur (eben ARM anstatt X86) kompiliert wurde. (Vereinfacht ausgedrückt.)
Nach außen hin ist es ein ganz normales Windows. Man kann lediglich nicht einfach ProgrammX.exe installieren und aufrufen, da der Unterbau (Prozessor und einige Kern-Elemente) das nicht erlauben.

Unified/Universal Apps arbeiten nicht mehr direkt mit dem Prozessor-Befehlssatz wie ein .exe-Programm sondern sind, ähnlich wie (theoretisch) Java- oder Python-Sourcecode unabhängig vom eingesetzten Prozessor. Wer eine "Universal App" startet, merkt nicht, dass da nicht mehr eine klassische ".exe" dahinter steht. Das geht aber ebenfalls nur, wenn das Betriebssystem für solche Programme gerüstet ist. Genau wie bei Java oder Python bedeutet das, dass - auch wieder vereinfacht ausgedrückt - ein entsprechender Interpreter installiert ist und die API-Calls (DirectX, Media, ...) zwischen den Betriebssystemen und Hardware-Architekturen nicht abweichen.

Die X86-Emulation auf ARM wurde von Intel verhindert, weil man für die Nutzung von x86 eine Lizenz von Intel braucht. Und die geben sie halt ungern für "lau" raus. nVidia hat übrigens gar keine bekommen. Die meisten (alle?) noch aktiven Lizenzen stammen noch als alten Verträgen, als IBM festlegte, dass mehr als ein Hersteller die Prozessoren liefern können muss, die in seine IBM-PCs sollten. Offensichtlich hat man das rechtliche Problem für x86_32 mittlerweile lösen können.

Ziel der Emulation ist es auch nicht, die Universal-Binaries laufen zu lassen. Das geht mit dem im OS eingebauten Interpreter via ARM-Prozessor deutlich schneller, da man den Code schlicht für ARM "just in time" fertig übersetzt. Ziel ist es, die alten Exe-Programme, die tatsächlich X86-Register brauchen, laufen zu lassen. MS kommt hier aber auch wieder entgegen, dass man die API-Aufrufe der x86-Programme des Emulators in nativem ARM-Code aufrufen kann.
Wer die Programme kennt: Im Prinzip ist die Emulation eine (umgekehrte) Kombination aus "Wine" und "qemu". Ein virtueller x86-Windows-Kern liefert dem Programm genug Funktionen, um selbst arbeiten zu können und dann nach "außen" in das ARM-Windows mit dort nativen ARM-Befehlen arbeiten zu können.

Regards, Bigfoot29

 

[andi_sco]

Offensichtlich hat man das rechtliche Problem für x86_32 mittlerweile lösen können

Sind da nicht Patente ausgelaufen?

Wer hat denn überhaupt noch eine gültige Lizenz, ausser AMD?
Die Chinesen dürfen auch nur durch ein Joint Venture mit AMD diese nutzen, weil AMD xx % Anteile hält.

x86 CPU aus China