News Intel kündigt „Quark“-Prozessoren für Wearables an

Volker

Ost 1
Teammitglied
Registriert
Juni 2001
Beiträge
18.286
wazzup schrieb:
Toller Name für einen Prozessor. Fail³
Englisch <> Deutsch
Mist <> Nebel

Englisch <> Deutsch
Quark <> Quark

Quark (Physik) Die Bestandteile eines Elementarteilchen oder eines Milchprodukts :p
So oder so ;)

Nur weil es für uns komisch klingt, ist das kein failiger Name, vor allem da solche Prozessoren nicht vom Consumer gekauft werden wo Media-Markt fett QUARK in ihre Prospekte schreibt.
 
Naja, zumindest hat Intel noch Platz für eine Leistungsklasse dazwischen gelassen.

Atom (gibt es als CPU) — Proton / Neutron (gibt es nicht als CPU) – Quark (wird es als CPU geben)

Die Frage die mich interessiert. x86-Befehlssatz, ja oder nein? Geht aus der Nachricht nicht hervor.
 
Ein einfacherer Befehlssatz ermöglicht gerade bei CPUs der unteren Leistungsklasse einen einfacheren u. energiesparerenden Befehldekoder.

Erst wenn es daraum geht möglichst viel Leistung aus dem Chip zu kitzeln u. (sehr) komplexe Software zu nutzen bringen komplexere Befehlssätze einen Vorteil.
So gibt es Low-Cost-RISC-CPUs die haben gerade mal 10 verschiedene Befehle u. nicht den Umfang den x86-CPUs bieten.
Der komplette Basis-x86-Befehlssatz besteht aus gut 150 versch. Befehlen! Und dann kommt noch der (heutiger Software selten genutzte) x87-Befehlssatz dazu + MMX + SSEx + AVX
 
Zuletzt bearbeitet:
luluthemonkey schrieb:
Wie erfolgreich war eigentlich das Razer I? Das war doch Intel powered...
Wohl ähnlich erfolgreich wie die anderen Motorola Modelle - was jedoch nichts gutes heißt ;)

Ich kann mir hier eigentlich nur x86 vorstellen - eine eigene Architektur hochzuziehen macht keinen Sinn, allein der Softwareaufwand hierfür würde einen Erfolg verhindern. Außerdem kann ich mir nicht vorstellen, dass Intel noch einmal ARM CPUs anbietet: der Konkurrent ist zu groß geworden, eine Unterstützung von Intel ist daher sehr unwahrscheinlich.
 
Simpson474 schrieb:
Ich kann mir hier eigentlich nur x86 vorstellen - eine eigene Architektur hochzuziehen macht keinen Sinn, allein der Softwareaufwand hierfür würde einen Erfolg verhindern.
Im Prinzip hätte Intel wohl die Marktmacht eine komplett neue CPU-Architektur auf dem Markt zu etablieren. Die Frage wäre dann eher. Lohnt sich das für Intel finanziell oder ist das ein Verlustgeschäft bzw. müsste Intel diesen Geschäftszweig durch den Gewinn von anderern Geschäftszweigen quersubventionieren?

Low-Cost Low-Power x86-Architekturen komplett neu entwickeln. Ob sich das lohnt? Im Prinzip könnte Intel auch die Pentium MMX Architektur wieder zum Leben erwecken. Mit neuen Energiesparmodi und neuen Schnittstellen ausgestattet wäre das ebenfalls eine Option für eine CPU der untersten Leistungsklasse, welche sparsam ist.
 
:D interessanterweise habe ich bis zum Aufruf der Posts hier nicht einmal an ein Milchprodukt gedacht. Für mich war gleich klar worauf abgezielt wird.
Halte die Bezeichnung für gelungen und bin sehr auf die Rechenleistung der CPU's gespannt.

Mfg.
JeverPils
 
WinnieW2 schrieb:
Ein einfacherer Befehlssatz ermöglicht gerade bei CPUs der unteren Leistungsklasse einen einfacheren u. energiesparerenden Befehldekoder.
Intel hat schon mit den neuen Atoms bewiesen, dass das nicht notwendig ist…

WinnieW2 schrieb:
So gibt es Low-Cost-RISC-CPUs die haben gerade mal 10 verschiedene Befehle u. nicht den Umfang den x86-CPUs bieten.
JMP, ADD, SUB, MUL, DIV, … klar geht das, aber es macht einfach keinen Sinn wenn wir uns den Fortschritt sowohl in Architekturdesign als auch Fertigungstechnik ansehen.

WinnieW2 schrieb:
Der komplette Basis-x86-Befehlssatz besteht aus gut 150 versch. Befehlen! Und dann kommt noch der (heutiger Software selten genutzte) x87-Befehlssatz dazu + MMX + SSEx + AVX
Eher mehr, aber gerade bei den Zusatzbefehlen kann Intel gut einsparen für spezielle Einsatzzwecke…
 
WinnieW2 schrieb:
Im Prinzip hätte Intel wohl die Marktmacht eine komplett neue CPU-Architektur auf dem Markt zu etablieren.

Das dachte sich Intel auch und schuf den Itanic. Der ist abgesoffen, die Kundschaft hat Intel einen saftigen Tritt in die Eier verpaßt und AMD64 gekauft.
 
QDOS schrieb:
Intel hat schon mit den neuen Atoms bewiesen, dass das nicht notwendig ist
Der Quark ist für den Bereich von 1 bis 500 Milliwatt el. Leistungsaufnahme gedacht. So tief kommt der Atom vermutlich nur wenn dieser deutlich unterhalb 1 GHz getaktet wird. Für den Embedded-Bereich reicht vermutlich ein SoC mit einem Kern. Ein Atom hat min. zwei devon. L2-Cache wird im angestrebten Nutzungsgebiet nicht benötigt.


Kenneth Coldy schrieb:
Das dachte sich Intel auch und schuf den Itanic. Der ist abgesoffen, die Kundschaft hat Intel einen saftigen Tritt in die Eier verpaßt und AMD64 gekauft.
Der Itanuim war durchaus in gewissen Marktnischen erfolgreich. Sonst hätte Intel diese Architektur deutlich früher beerdigt.


Ralf555 schrieb:
Danke. Heise hat mittlerweile eine Meldung gebracht u. bestätigt dass der Quark den x86-Befehlssatz nutzt.
Das Besondere an der CPU ist dass diese wie die CPUs von ARM nach Kundenwünschen flexibel angepasst werden können. Zusätzliche für best. Nutzungszwecke angepasste Spezial-Recheneinheiten können an den eigentlichen Quark-Rechenkern angekoppelt werden.
Intel hatte hier wohl ARM und MIPS als Vorbild.
 
Kenneth Coldy schrieb:
Das dachte sich Intel auch und schuf den Itanic. Der ist abgesoffen, die Kundschaft hat Intel einen saftigen Tritt in die Eier verpaßt und AMD64 gekauft.
Der Itanium war halt eine VLIW-Architektur: mit dieser lassen sich zwar einige wenige Aufgaben sehr effektiv lösen (Texas Instruments verwendet eine ähnliche Architektur in DSPs für Audio/Video-Verarbeitung), für generelle Aufgaben ist die Architektur jedoch vollkommen ungeeignet. Während bei x86 maximal 2 Recheneinheiten pro Rechenkern (Intels HT oder AMDs Modulanzsatz) verwendet werden, so sind bei VLIW z.T. über 8 parallele und teilweise noch spezialisierte Einheiten pro Rechenkern vorhanden: diese effizient anzusteuern, ist wirklich nur bei sehr wenigen Einsatzgebieten möglich und dadurch sind diese meist ungenutzt und verschwenden Energie. Häufig muss bei solchen Architekturen sogar das Einhalten der Ausführungszyklen eines Befehls in Software realisiert werden: dies macht Compiler für diese Plattformen extrem komplex und handgeschriebenen Assembler-Code bei vielen Ausführungseinheiten mit unterschiedlichen Einschränkungen auf Befehlsebene zu einem Ding der Unmöglichkeit.
 
Nette Idee mit den Milchprodukten. Aber ich hab eher auf den großen Durchbruch in Sachen neuer Computertechnologie gehofft. Schade, wär auch zu schön gewesen.
 
WinnieW2 schrieb:
Das Besondere an der CPU ist dass diese wie die CPUs von ARM nach Kundenwünschen flexibel angepasst werden können. Zusätzliche für best. Nutzungszwecke angepasste Spezial-Recheneinheiten können an den eigentlichen Quark-Rechenkern angekoppelt werden.
Intel hatte hier wohl ARM und MIPS als Vorbild.

Wobei der Nachteil bleibt, dass Intel x86 nicht an andere lizensieren wird.

Wer sich für ein ARM- oder MIPS-SoC entscheidet, der bezahlt einfach die Lizenzkosten und kann dann selbst nach Herzenslust entsprechende CPU-Cores mit allen möglichen anderen Komponenten kombinieren und fertigen lassen wo es ihm gefällt.
Bei "Quark" muss zwangsläufig alles über Intel laufen. Das wird einiges komplizierter machen. Z.B. wenn auch lizenzpflichtige Technologie anderer Anbieter integriert werden soll. Dann muss sich erstmal Intel diese Lizenzen besorgen usw.

"Quark" wird somit wohl eher für kleinere Kunden interessant, die keine oder wenig eigene Entwicklungskapazität haben. Und wenn nicht allzuviele Extrawünsche im Spiel sind und optimalerweise alles mit Intel-Technologie erschlagen werden kann.
 
1.) Es kommt nicht darauf an, wie komplex der x86 Befehlssatz ist. Chipfläche ist ja mehr als genug da, genauso wie die Anzahl an Transistoren, die verbaut werden. Die Herausforderung ist möglichst wenige Transistoren aktiv schalten zu lassen. Viele Befehle schließen hier nicht unbedingt eine höhere Effizienz aus. Ich würde sagen, dass diese sogar eher bevorzugen. Besser einen gut passenden komplexen Befehl optimiert abarbeiten als auf viele nicht ganz passende Befehle aufzuteilen.
Gutes Beispiel hierfür ist z.B. die AES Beschleunigung. Diese kostet zwar Transistoren, jedoch kann diese Aufgabe dann nicht nur schneller, sondern auch deutlich effizienter abgearbeitet werden.

2.) Die noch viel größere Frage ist jedoch, wie viel Strom die Dinger bei sehr leichter Belastung (gerade so viel, dass sie nicht in den Standby wechseln kann) bis leichter Belastung (mp3s abspielen, bisschen surfen etc.). Das ist für Smartphones der reale Anwendungsfall. Bei einer Smartwatch wird das erste Kriterium sein, wie lange das Teil mit dem Akku auskommt, wenn es nur als Uhr genutzt wird und vielleicht noch die typischen Hintergrundaufgaben ausführt (per Bluetooth vom Handy die neuen SMS austauschen, auf Wecker überprüfen etc.) Wenn da eine Woche drin ist, werden sich das sicher einige Leute holen. Bei einem Tag eher weniger.

3.) x86 in seiner Grundform ist alles andere als aufgebläht. Man braucht sich hier ja nur die Anzahl an Transistoren der ersten x86 CPUs ansehen. Würde man diese einfach nur auf heutige Strukturen shrinken und entsprechend auf den GHz Bereich hochtakten, würden diese deutlich sparsamer sein als die heutigen ARM Kerne, aber eben auch deutlich langsamer.

4.) Die Frage bei einem Chipdesign ist immer, ob wie viel aktive Transistoren bzw. welche Verlustleistung man für wie viel Performancezuwachs opfert. Im Desktopbereich hat Intel immer auf Performance optimiert, während ARM mehr auf mobile Geräte optimiert hat. Das hat jedoch nicht unbedingt mit dem Befehlssatz zu tun. Am Anfang war ich auch der Meinung, dass Intel keine effizienten kleinen Chips liefern kann, aber dann nun glaube ich, dass das auch nie der Plan war, da Intel schon vorhergesehen hat, dass die Performance der Smartphones wachsen wird und jetzt ist ein Atom für High End Smartphones ideal, während für Tablets/Ultrabooks schon die stromsparenden Haswells notwendig sind.

5.) Die CPU sieht zumindest optisch schon nicht schlecht aus, das Board jedoch weniger. Ich glaube kaum, dass sich das jemand aufs Handgelenk schnallen wird ;)
 
Zurück
Oben