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

Jan

Chefredakteur
Teammitglied
Dabei seit
Apr. 2001
Beiträge
11.627

Krautmaster

Fleet Admiral
Dabei seit
Feb. 2007
Beiträge
21.669
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

Lt. Commander
Dabei seit
Nov. 2014
Beiträge
1.490
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

Lt. Commander
Dabei seit
Apr. 2017
Beiträge
1.798
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

Ensign
Dabei seit
März 2009
Beiträge
227
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

Captain
Dabei seit
Okt. 2011
Beiträge
3.331
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

Cadet 1st Year
Dabei seit
Juni 2018
Beiträge
14
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

Lt. Commander
Dabei seit
Jan. 2005
Beiträge
1.354
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

Lt. Commander
Dabei seit
Mai 2008
Beiträge
1.745
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.
 

Eusterw

Lt. Commander
Dabei seit
Juni 2007
Beiträge
1.079
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

Captain
Dabei seit
März 2015
Beiträge
3.609
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

Cadet 3rd Year
Dabei seit
Aug. 2006
Beiträge
51
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. :rolleyes: :D
 

HerrRossi

Vice Admiral
Dabei seit
Apr. 2014
Beiträge
6.909
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

Lieutenant
Dabei seit
Sep. 2011
Beiträge
712
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

Lt. Commander
Dabei seit
Juni 2007
Beiträge
1.416
@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

Vice Admiral
Dabei seit
Aug. 2006
Beiträge
6.163
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.
 

Bigfoot29

Lt. Commander
Dabei seit
Juni 2007
Beiträge
1.416
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
 
Top