Arbeiten Intel und AMD ebenfalls an big.LITTLE-Architektur-Konzepten? [Apple M1]

[Thomas.Lebers]

Apples M1 macht einen sehr potenten und energieeffizienten Eindruck.

Frage: Sind INTEL und AMD auch im Prozess der Entwicklung solcher big.LITTLE Architekturen für ihre zukünftigen CPU/APU Generationen?

Falls NEIN: Warum nicht?

Was sind die Vor- und Nachteile solcher Architekturen?

 

[Garmor]

Alder Lake ist doch seit nem Jahr draußen.

 

[Drewkev]

@Thomas.Lebers
Intel Alder/Raptor Lake?

 

[bart0rn]

Frage: Hast Du gegoogelt ?

Falls NEIN: Warum nicht?

Falls JA: Was an den Antworten gefällt Dir nicht ?


Intel:
https://www.computerbase.de/2020-03/cpu-intel-alder-lake-s-16-kerne-big.little-prinzip/

AMD:
https://www.planet3dnow.de/cms/6292...ren-untermauert-big-little-prinzip-bei-zen-5/

 

[DriveByFM]

Intel hat sowas doch schon.

 

[madmax2010]

Apple war da ehrlichgesagt recht spaet dran..
Sowas gab es von so ziemlich allen ARm herstellern seit bald 10 jahren.
AMD und Intel haben sowas auch schon seit vielen Jahren gemacht. Auch vor Alder Lake.

Der M1 ist so effizient, weil es sich hier um eine ARM und nicht x86 architektur handelt. Gibts von hunderten herstellern.

 

[Jasmin83]

Apples M1 macht einen sehr potenten und energieeffizienten Eindruck.

Das hat eher weniger mit big little zu tun, sondern eher mit einer anderen, auf die Software spezialisierte Architektur, die auch effizient gilt, weil die für die Aufgaben zugeschnitten ist und nicht wie bei x86 die eierlegende Wollmilchsau sein muss, die möglich viel abdecken muss.

Apple hat den großen Vorteil, das Hardware und Software aus einem Haus kommt, da kann man schon eine ganze Menge mehr potential rausholen, als wenn man sich selber jede Komponente selber zusammenschustert.

 

[M.Ing]

Apple hat den großen Vorteil, das Hardware und Software aus einem Haus kommt, da kann man schon eine ganze Menge mehr potential rausholen, als wenn man sich selber jede Komponente selber zusammenschustert.

Apple fährt auch die radikalere Schiene bei Produktsupport. Während Windows 11 noch immer Code von Windows 95 (und vermutlich noch älter) in der Codebasis mitschleppt, gibts bei Apple alle paar Jahre Schnipp-Schnapp und auf Nimmerwiedersehen mit alten Technologien - anders wäre so ein Architekturwechsel, wie er gerade vollzogen wurde auch ziemlich schwer...

 

[madmax2010]

in der Codebasis mitschleppt, gibts bei Apple alle paar Jahre Schnipp-Schnapp und auf Nimmerwiedersehen mit alten Technologien

das ist so nicht richtig.
1. Der Darwin teil der bis heute dabei sit, enthaelt code der teils aelter als 1993 ist

2. Die ganzen basis Tools haben richtig viel Cdoe aus den 70ern und 80ern. Da ist Software am Werk, die es laenger gibt, als es Apple gibt.

3. Hat apple eine Historie die basistools sehr schlampig zu updaten , versucht immer wieder sie zu forken und sicherheitspatches in veralteten Tools selbst einzubauen. Shellshock waere unter OSX kein problem gewesen, wenn Apple das 2014 aktuelle Bash 4.3 genutzt haette. Stattdessen haben ein selber gepatches Bash 3.2 aus 2006 versucht am leben zu halten. 10 jahre nachdem die version wirklich tot war haben sie das dann mal verbessert.
Goto fail war auch extra uebel - hier haette man sehr viel Stress fuer sehr viele menschen vermeiden koennen, wenn man seinen OpenSSl Fork besser gepflegt haette. oder einfach die offizielle aktuelle version genutzt haette (Ok, Crypto selber bauen / pflegen ist so oder so ein running gag)

Apple ist radikal ja, aber software altlasten der letzten 50 Jahre schleppen sie weiterhin mit und haben da auch immer wieder Schwierigkeiten mit

 

[Jasmin83]

gibts bei Apple alle paar Jahre Schnipp-Schnapp und auf Nimmerwiedersehen mit alten Technologien - anders wäre so ein Architekturwechsel, wie er gerade vollzogen wurde auch ziemlich schwer...

und Apple zeigt, das es gut und wichtig ist, solche Linien zu ziehen und nicht wie bei Windows jeden Schrott bis in alle Ewigkeit mitzuschleppen, weil man der Meinung ist, das es anders nicht gehen würde. Man sieht bei Apple, das die Softwareanbieter dennoch mitziehen, weil sie sonst obsolet werden. Man nimmt noch 2-3 Jahre einen Emu für das alte Zeugs mit und dann fliegt der auch raus, wie bei Rosetta 1 und wie bei Rosetta 2 es auch geschehen wird, sobald x86 Code nicht mehr gebraucht wird.