News Personalwechsel: Jim Keller verlässt Intel nach zwei Jahren wieder

WinnieW2 schrieb:
Vielleicht war er nirgendwo auf ein bestimmtes Gebiet festgelegt und war Berater für andere Entwickler.
Durchaus eine realistische Annahme. Im Endeffekt sammelt er die Ideen, fügt sie zusammen und gibt Denkanstöße.

WinnieW2 schrieb:
Erhöhung der IPC steht für zukünftige CPU-Archtekturen bei Intel allerdings definitiv auf der Agenda.
Steht es aktuell bei beiden Firmen. Die Frage ist nur, wann man auch hier gegen eine Wand rennt, denn die IPC lässt sich auch nicht beliebig steigern, man kann zwar ALUs und AGUs hinzufügen, am Ende kann man das alles dann aber nicht wirklich auslasten.

WinnieW2 schrieb:
Dazu müssen im Prinzip noch nicht mal die Ausführungseinheiten erweitert werden, meist hängt es am Speicherzugriff und den x86-64 Befehlsdekodern.
Aktuell arbeiten bei Intel - als auch AMD - 4 ALUs sowie 2 Vector-ALUs in den CPUs. Wenn ich mich nicht täusche, haben sie auch 3 AGUs, oder sind es schon 4 AGUs? Klar könnte man nun noch eine 5 normale ALU hinzufügen und eine dritte oder gar sogar vierte Vector-ALU, am Ende muss das alles jedoch ausgelastet werden und das fällt ja bereits heute schwer.

WinnieW2 schrieb:
Wenn mehr µOps/Taktzyklus generiert werden können dann können auch mehr Befehle parallel abgearbeitet werden, ...
Im Idealfall stimmt das, nur dann könnte man auch einfach mehr Kerne in die CPU klatschen, denn im Idealfall lässt sich alles unabhängig und auch flexibel parallelisieren, nur dass ist eben nicht der Fall.

Egal ob wir uns jetzt auf Softwareebene in Threads befinden oder innerhalb eines Kerns, es lässt sich nicht alles beliebig Parallelisieren und sobald Abhängigkeiten vorhanden sind, hat es sich mit der IPC-Steigerung. Da kannst du noch so viele x86-Befehle pro Taktzyklus decodieren und weiter reichen und da kannst du auch noch so viele ALUs und AGUs hinzufügen. Sobald eine Abhängigkeit drin ist, braucht man zwei Takte.

WinnieW2 schrieb:
... allerdings bedingt das einen noch höheren Out-of-Order Grad der CPU-Architektur.
Auch den kannst du beliebig vergrößern, am Ende beschleunigt das aber nichts, wenn die Befehle von einander abhängig sind.

WinnieW2 schrieb:
Und spekulative Befehlsausführung ist ein pot. Sicherheitsrisiko.
Klar ist es ein potenzielles Sicherheitsrisiko, aber elementare Bestandteil der heutigen Geschwindigkeit vieler CPUs, in dem man Befehle aus Verzweigungen, die unabhängig sind, bereits ausführt, während man auf Daten wartet, oder bestimmte ALUs als auch AGUs nicht ausgelastet sind.

WinnieW2 schrieb:
Das Hauptproblem ist die CPU schneller zu machen ohne weitere Sicherheitslücken in den Architektur zu reissen.
Am Ende wird es irgendwann wieder darauf hinauslaufen, dass man sich als Entwickler mit einer CPU-Architektur als auch den Möglichkeiten befassen muss. Alles was du hier nun vorschlägst - schnellere Decoder, niedrigere Latenzen, mehr ALUs/AGUs ... laufen am Ende genau in die gleiche Wand wie immer mehr CPU-Kerne es tun.

WinnieW2 schrieb:
Letzendlich schafft nur die Steigerung der IPC noch eine Mehrleistung von der die meiste Software profitiert.
Rennt man eben nur in die gleichen Hürden wie mit mehr Kernen. Sobald Abhängigkeiten da sind, ist es das. Viele richtige Aussagen von dir, am Ende fehlte ein kleines Puzzelteil.
 
Cruentatus schrieb:
Edit: Also was soll "Big Project of OR" bzw. in diesem Zusammenhang "OR" bedeuten?
OR.. Organization Administrator könnte das bedeuten. Bin auch nicht so der pro in Slang.
 
@pipip

OR=Oregon

Intel hat zwei Design Teams. Eines in Haifa und eines in Hillsboro, Oregon.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: pipip
Teralios schrieb:
Auch den kannst du beliebig vergrößern, am Ende beschleunigt das aber nichts, wenn die Befehle von einander abhängig sind.
Interessant. Das würde ja im Endeffekt heißen je weniger befehlsätze eine Anwendung nutzt, desto weniger Leistungssteigerung hätte ne neue CPU zur Folge. Ich habe ne anwedung die nur die Hälfte der befehlsätze der ganzen CPU nutzen kann. Es wird auch wohl langfristig nicht mehr weiter entwickelt.

Heißt das nun das es die Leistungssteigerungen dann bremsen tut und somit weniger mehrleistung am Ende zu stande kommt.
Und das ganze je mehr Einheiten, desto gefährlicher auch die Wahrscheinlichkeit daß sie nicht richtig ausgelastet werden. Heißt das das immer mehr nicht immer was bringt. Und wird dann dadurch die auslastung der CPU gemindert und was passiert denn dann wenn nicht alle Einheiten die du da so erwähnt hast nicht alle auslasten kann, mildert das die mehrleistung der CPU und langweilt sich dadurch die CPU dann mehrer als vorher?
 
pipip schrieb:
OR.. Organization Administrator könnte das bedeuten.

Ach so, das soll also für Jim Keller stehen?

Der Twitterer hat demnach ein paar Anrufe getätigt und erfahren dass Jim Kellers 'Großes Projekt' bei Intel in Frage gestellt wurde (und er deswegen gegangen ist).
 
  • Gefällt mir
Reaktionen: pipip
Cruentatus schrieb:
... dass Jim Kellers 'Großes Projekt' bei Intel in Frage gestellt wurde (und er deswegen gegangen ist).
Mir erscheint das so dass J. Keller eine von Grund auf neue x86-CPU-Architektur entwickeln wollte, aber die Intel Geschäftsleitung entschieden hat die CPU-Architekturen auf den bestehenden Architekturen weiter zu entwickeln.
Ergänzung ()

Teralios schrieb:
Egal ob wir uns jetzt auf Softwareebene in Threads befinden oder innerhalb eines Kerns, es lässt sich nicht alles beliebig Parallelisieren und sobald Abhängigkeiten vorhanden sind, hat es sich mit der IPC-Steigerung. Da kannst du noch so viele x86-Befehle pro Taktzyklus decodieren und weiter reichen und da kannst du auch noch so viele ALUs und AGUs hinzufügen. Sobald eine Abhängigkeit drin ist, braucht man zwei Takte.
Es sei denn Intel bringt Befehlssatzerweiterungen welche genügend Zukunftspotential haben, also auch gut mit mehr Recheneinheiten skalieren.

Im x86-Basisbefehlssatz dürfte kaum noch Potential zur IPC-Erhöhung vorhanden sein.
Aber da werden wir uns überraschen lassen.
Golden Cove soll jedenfalls eine 50% höhere IPC im Vergleich zu Skylake mitbringen. Ob das realistisch ist werden wir in ca. 2 Jahren erfahren.
 
Zuletzt bearbeitet:
In der News von Anandtech stand dazu noch Folgendes:
It should be noted that Jim Keller is still listed to give one of the keynote addresses at this year’s Hot Chips conference on behalf on Intel. We will update this story if that changes.
Bin gespannt, vllt. erfährt man da ja ein bisschen, was er gemacht hat.

Btw: Kommentare wie diesen
hoxi schrieb:
Ich denke, dass so jemand in einer Firma wie Intel viel weniger bewirken kann, als in viel kleineren Unternehmen. Zu viele Köche verderben bekanntlich den Brei. Und dann kommt noch Intels schreckliche, überhebliche Kultur hinzu. Für seinen Ruhestand wird er aber wohl gut vorgesorgt haben, obwohl ich glaube, dass er sicher noch gerne einige Herausforderungen annehmen würde. Wir werden es sehen.
habe ich jetzt schon öfters gesehen. Ist prinzipiell denkbar, große Unternehmen sind ja generell recht träge. Aber bei Kellers Ruf würde ich jetzt nicht pauschal davon ausgehen, dass Intel, die aktuell ja sowieso eine helfende Hand gebrauchen könnten, diese einfach ausschlägt. ^^
Vielleicht feiert Intel ja in zwei Jahren auch wieder ein Comeback. Wobei zwei Jahre vermutlich sogar zu wenig für AMD wären, um dem Riesen mal so richtig die Marktanteile abzufressen. Für ein ausgeglicheneres Verhältnis zwischen den beiden wäre es also vielleicht sogar besser, wenn Intel nichts aus Kellers Anwesenheit rausgezogen hätte. :evillol:
 
  • Gefällt mir
Reaktionen: Tanzmusikus
Schoen, wenn man sichs leisten kann:
Wenns langweilig wird, wechseln.

2 Jahre Intel... ;)
 
latiose88 schrieb:
Interessant. Das würde ja im Endeffekt heißen je weniger befehlsätze eine Anwendung nutzt, desto weniger Leistungssteigerung hätte ne neue CPU zur Folge. Ich habe ne anwedung die nur die Hälfte der befehlsätze der ganzen CPU nutzen kann. Es wird auch wohl langfristig nicht mehr weiter entwickelt.
Nicht ganz, zumindest hast du mich teilweise falsch verstanden.

In dem Fall hat es eher damit etwas zutun, wie gut sich Instructions/Operationen unabnhäniog von einander ausführen lassen.

Ein einfaches Beispiel: Eine CPU hat 2 ALUs, kann also 2 Opertationen zur gleichen Zeit ausführen, dann ergeben sich folgende Szenarien: (ADD steht für Addition, MUL für Multiplikation, die Buchstaben sind die Register, -> gibt das Zielregister an.)

Szenario 1:
ADD A, B -> A
ADD C, D -> C

Beide Befehle sind von einander Unabhängig und so wird auf ALU-1 ADD A,B und auf ALU-2 ADD C,D ausgeführt im selben Takt.

Szenario 2:
ADD A, B -> A
MUL A, C -> A

Hier hängt nun der MUL-Befehl von dem Ergebnis des ersten Befehls ab, entsprechend werden hier auf jeden Fall 2 Takte benötigt.

Im ersten Takt führt ALU-1 ADD A,B aus. ALU-2 liegt brach. Im zweiten Takt führt ALU-1 MUL A,B aus und ALU-2 liegt brach. Also hier 50% der Rechenleistung, bei beiden Takten. ;)

Erweitern wir es um 2 Befehle zu Szenario 3:

ADD A, B -> A
MUL A, C -> A
ADD D, C -> D
MUL D, B -> D

Wir haben zwei weitere Befehle drin. Befehl 2 ist von 1 abhängig und 4 von 3. Entsprechend benötigen wir, obwohl wir 2 ALUs haben, 4 Takte, da alle nacheinander ausgeführt werden.

Und hier setzt jetzt OoO an. Also Out-of-Order-Execution. Wir können hier die Befehle so sortieren, dass wir nur 2 Takte brauchen, und schon können die ALUs besser ausgelastet werden:

ADD A,B -> A
ADD D,C -> D
MUL A, C -> A
MUL D,B -> D

Takt 1: ALU-1 führt ADD A,B aus, ALU-2 ADD D,C. Takt 2: ALU-1 MUL A,C. ALU-2: MUL D,B. Statt also wie vorher 4 Takte zu benötigen, schaffen wir es in 2.

Nur um jetzt die Befehle zu sortieren um die ALUs möglichst effektiv auszulasten, braucht es genug BEfehle, die voneinander nicht abhängig sind. Würden wir jetzt zum Beispiel vier Befehle absetzen, die in ihrer Form Register A abhängig sind, dann braucht man wieder 4 Takte um alle Befehle auszuführen:

ADD A,B -> A
MUL A, C -> A
ADD A, D -> A
MUL A. E -> A

Egal was man macht, diese vier Befehle kannst du nicht sortieren und damit müssen alle 4 Befehle nach einander auf jeweils einer ALU ausgeführt werden.

Und darum geht es. Sorry, wenn ich es für Experten zu stark vereinfacht habe. Sorry für die anderen, denen es zui schwer ist.


latiose88 schrieb:
Heißt das nun das es die Leistungssteigerungen dann bremsen tut und somit weniger mehrleistung am Ende zu stande kommt.
Nein, es bremst nicht, nur liegt eben Leistung brach, wird also nicht genutzt.

latiose88 schrieb:
Und das ganze je mehr Einheiten, desto gefährlicher auch die Wahrscheinlichkeit daß sie nicht richtig ausgelastet werden.
Genau das ist die Gefahr und um dem zu begegenen gibt es heute Techniken wie SMT, Spekulative Ausführung usw.

WinnieW2 schrieb:
Es sei denn Intel bringt Befehlssatzerweiterungen welche genügend Zukunftspotential haben, also auch gut mit mehr Recheneinheiten skalieren.
Auch gute Befehlssatzerweiterungen kann es nicht verhindern, dass Befehle alleine durch den Programmablauf voneinander abhängig sind. Ein a + b + c + d kannst du eben nur in a + b und c + d aufsplitten um 2 ALUs auszulasten, die Dritte Operation wird immer erst im nächsten Takt ausgeführt, auch wenn du eine 3 oder gar 4 ALU hast. Und hier kannst du auch mit OoO nicht viel mehr erreichen.

Es gibt Probleme bei der Auslastung, die kannst nicht durch neue Befehlssätze lösen, oder in dem du mehr ALUs unter bringst.

WinnieW2 schrieb:
Golden Cove soll jedenfalls eine 50% höhere IPC im Vergleich zu Skylake mitbringen. Ob das realistisch ist werden wir in ca. 2 Jahren erfahren.
Man muss hier halt bedenken, dass es hier um Durchschnittssteigerungen geht. Klar werden im Mittel sicher bis zu 50% erreicht werden, gerade wenn man die Wartezeiten auf Daten usw. weiter verringert und Kontextwechsel beschleunigen kann.

Am Ende wird es aber ebenso genug Software geben, die hier nicht wirklich profitieren werden.
 
  • Gefällt mir
Reaktionen: Kat5, ComputerJunge und Tanzmusikus
Biedermeyer schrieb:
Schoen, wenn man sichs leisten kann:
Wenns langweilig wird, wechseln.

Ich denke eher er macht es so, um seinen Marktwert zu steigern.
 
Falls er nicht auf Anlagebetrüger hereingefallen sein sollte, hat der sein Schäfchen längst im Trockenen.

Der kann sich die nächste Stelle nach Lust und Laune aussuchen und nicht nach dem Motto: Wer zahlt am meisten !

PS: auf anandtech.com geht die Diskussion zu diesem Thema mit wilden Spekulationen einher
 
Teralios schrieb:
Genau das ist die Gefahr und um dem zu begegenen gibt es heute Techniken wie SMT, Spekulative Ausführung usw.
Ok das meiste von dir habe ich verstanden.Aber was wenn zu dem ersten Problem wo du ja geschildert hast auch noch das zweite Problem auftritt das diese SMT bzw HT nicht beschleunigt sondern statt dessen die Leistung sogar vermindert.Sagen wir mal so ab 24 und mehr Kerne,was ist denn dann?
Wenn man also kaum noch,noch mehr gleichzeitig machen kann.Dann liegt am ende noch mehr einheiten einfach brach. Kann sich somit also die CPU dann wirklich noch mehr langweilen als es sonst üblich ist.
Ich weis das ab einen gewissen grad der Aufwand der Kerne zu hoch ist,weshalb dann die Leistung wieder sinkt weil es ja um es zu packen leistung kostet.
Und es kann auch an der Software liegen.Wenn ich mir so deine Infos her zu herzen nehme,dann habe ich immer mehr die befürchtung das sich Ryzen 4950x sich nicht so wirklich vom Ryzen 3950x sich absetzen kann.
Denn vergleiche ich das auch noch mit den ganzen Threadripper CPUS die wo alle mehr Kerne haben(bis auf die erste Generation),dann komme ich zu der annahme das irgendwas die leistungssteigerung bremst oder nicht sich so richtig durchsetzt.
Der Unterschied von 3950x zu 3970x beträgt bei meinem Workflow nur noch 17 Prozent leistungssteigerung.

Ich dachte der 32 Kerner wäre zu weit mehr Leistungssteigerung in der Lage.Und der 3960 hat nur noch rund 10 % Leistungssteigerrung. Ist es also möglich das der 4950x gleichschnell wie der 3960x ist oder ist das eher wohl nur wunschdenken von mir?
 
Daniel1337 schrieb:
War es nicht so, dass der Einfluss Kellers auf Zen hier im Forum (und auch sonst wo) massiv überschätzt wurde?

Ich stelle mir Keller immer als "Consultant" vor. Er kann vielleicht einschätzen, wo ein Design noch etwas Arbeit braucht, ist gut vernetzt, schaut überall mal drüber und trägt an allen Ecken etwas bei. Den Löwenanteil der Arbeit - dafür braucht es sicher ein Zusammenspiel vieler fähiger Menschen.
 
Ned Flanders schrieb:
@pipip

OR=Oregon

Intel hat zwei Design Teams. Eines in Haifa und eines in Hillsboro, Oregon.

Würde es eher als Zentren bezeichnen, soweit ich weiß gibt es zumindest in Oregon mehrere Teams.

AMD macht das ja auch so, dass parallel mehrere Teams an Zen 1, Zen 2, usw. arbeiten und nach dem Ende von Zen 1 das Team sich dann komplett dem Zen 4 gewidmet hat.
 
  • Gefällt mir
Reaktionen: LamaTux, PPPP und Ned Flanders
latiose88 schrieb:
Aber was wenn zu dem ersten Problem wo du ja geschildert hast auch noch das zweite Problem auftritt das diese SMT bzw HT nicht beschleunigt sondern statt dessen die Leistung sogar vermindert.Sagen wir mal so ab 24 und mehr Kerne,was ist denn dann?
Das ist jetzt weitaus komplizierter, weil hier einige Sachen zusammen spielen, sowohl auf der Hardwareebenen, als auch auf der Softwareebene und wir uns da auch schnell im Bereich der guten Algorithmen bewegen. Da muss ich selbst erst mal aussteigen und mir mal wieder einige Sachen durchlesen um gute Beispiele und Erklärungen zu finden.

Eine Grundlage hier ist zum Beispiel das Amdahlsche Gesetz. Hier geht es darum, dass man ein fest definiertes Problem A hat, dass sich aus x % seriellen Codes hat und x% parallele Code. Hier bestimmt primär der serielle Codeteil, wie lange die Lösung des Problems dauert. Vereinfacht gesagt: Wenn der serielle Codeteil eines Programms 10 Sekunden braucht, dann kann man, egal wie viele Kerne man aufwendet, nicht unter diese 10 Sekunden kommen.

Als "Gegenentwurf" gibt es dann das Gesetzt von Gustafson. Hier geht es darum, dass man mit mehr Ressourcen das ursprüngliche Problem A vergrößert. Auch hier vereinfache ich nun. Wenn ein Problem A mit 5000 Bildern in einer Minute bei 4 Kernen gelöst werden kann, dann können 8 Kerne das Problem A mit 10000 Bildern auch in 4 Minuten lösen. Sprich, wir benötigen immer 4 Minuten, aber können mit mehr Kernen immer mehr Bilder berechnen. (Letzteres ist zum Beispiel der Grund, warum GPUs mit ihren SIMD-Einheiten so gut skalieren.)

Beide Gesetze bilden jeweils einen Limes, in dem wir uns Bewegen, Amdahl hat die untere Grenze definiert. Gustafson die obere Grenzte, in dem man ein Problem beliebig groß skalieren kann.

Wir bewegen uns in der Regel zwischen beiden Gesetzen und genau das passiert dir auch mit der CPU und deinem Workload. Du hast ein Problem A mit fester Größe, entsprechend rennst du früher oder später in das erste Gesetzt. Den Gustafson grätscht in der Regel meist dann der Verwaltungsaufwand zwischen die Beine und aus den theoretisch 10000 Bilder, wenn man denn nun 8 Kerne hat, werden nur noch 9000 und wenn man 16 Kerne hat, sind es nur noch 16000 und irgendwann steigt der Aufwand der Verwaltung so an, das Amdahl mit einem Balken einem Gustafon einen Scheitel zieht.

Aber wir bewegen uns jetzt etwas zu sehr in der theoretischen Informatik und die mag ich nicht so. ;)
 
  • Gefällt mir
Reaktionen: Cruentatus
Bulletchief schrieb:
Hier scheinen ja viele schon sehr lange bei Intel gearbeitet zu haben, um deren Arbeitsatmosphäre zu beurteilen...

Das habe ich mir auch direkt gedacht :lol: Nur hochrangige Intel Mitarbeiter die zu „Fanboys“ der Konkurrenz mutieren sobald sie das Forum betreten ...
 
Teralios schrieb:
Das ist jetzt weitaus komplizierter, weil hier einige Sachen zusammen spielen, sowohl auf der Hardwareebenen, als auch auf der Softwareebene und wir uns da auch schnell im Bereich der guten Algorithmen bewegen. Da muss ich selbst erst mal aussteigen und mir mal wieder einige Sachen durchlesen um gute Beispiele und Erklärungen zu finden.

Eine Grundlage hier ist zum Beispiel das Amdahlsche Gesetz. Hier geht es darum, dass man ein fest definiertes Problem A hat, dass sich aus x % seriellen Codes hat und x% parallele Code. Hier bestimmt primär der serielle Codeteil, wie lange die Lösung des Problems dauert. Vereinfacht gesagt: Wenn der serielle Codeteil eines Programms 10 Sekunden braucht, dann kann man, egal wie viele Kerne man aufwendet, nicht unter diese 10 Sekunden kommen.

Als "Gegenentwurf" gibt es dann das Gesetzt von Gustafson. Hier geht es darum, dass man mit mehr Ressourcen das ursprüngliche Problem A vergrößert. Auch hier vereinfache ich nun. Wenn ein Problem A mit 5000 Bildern in einer Minute bei 4 Kernen gelöst werden kann, dann können 8 Kerne das Problem A mit 10000 Bildern auch in 4 Minuten lösen. Sprich, wir benötigen immer 4 Minuten, aber können mit mehr Kernen immer mehr Bilder berechnen. (Letzteres ist zum Beispiel der Grund, warum GPUs mit ihren SIMD-Einheiten so gut skalieren.)

Beide Gesetze bilden jeweils einen Limes, in dem wir uns Bewegen, Amdahl hat die untere Grenze definiert. Gustafson die obere Grenzte, in dem man ein Problem beliebig groß skalieren kann.

Wir bewegen uns in der Regel zwischen beiden Gesetzen und genau das passiert dir auch mit der CPU und deinem Workload. Du hast ein Problem A mit fester Größe, entsprechend rennst du früher oder später in das erste Gesetzt. Den Gustafson grätscht in der Regel meist dann der Verwaltungsaufwand zwischen die Beine und aus den theoretisch 10000 Bilder, wenn man denn nun 8 Kerne hat, werden nur noch 9000 und wenn man 16 Kerne hat, sind es nur noch 16000 und irgendwann steigt der Aufwand der Verwaltung so an, das Amdahl mit einem Balken einem Gustafon einen Scheitel zieht.

Aber wir bewegen uns jetzt etwas zu sehr in der theoretischen Informatik und die mag ich nicht so. ;)


Ok verstehe.Wenn nun die Software nun die ist ja schon seid fast 1 Jahr sich nicht mehr ändert,weil x264 schon bis zu geht nicht mehr beim umwandeln nicht mehr Optimiert wird.Dann müssen sich halt die Hardware Hersteller sich mehr ansträngen bzw mehr mühe geben.Kann also so einer wie Jim Keller diese Grenze brechen und nur alleine durch Hardware seite das Limit etwas ausweiten oder geht das nicht?
 
pipin schrieb:
Würde es eher als Zentren bezeichnen, soweit ich weiß gibt es zumindest in Oregon mehrere Teams.

Völlig korrekt, was ich meinte bezog sich auf den Tweet von unserem französischen Freund, und was der meinte war das das große CPU Projekt in Oregon angeblich auf erheblichen Widerstand gestoßen sei und dass das IDC (Israel Developer Center - Haifa) besser weg gekommen ist, was natürlich suggeriert, dass Keller deswegen gegangen ist.

Nur würde ich halt auf Francois Tweets nicht unbedingt viel geben (genau genommen garnichts). Der lebt in seiner eigenen Welt.... schon lange...
 
  • Gefällt mir
Reaktionen: SVΞN
Schon spannend. Ich spekuliere mal noch ein bisschen (auch wenn man ja eigentlich nichts weiß):

Jim Keller ist zu Intel gegangen um irgend etwas vergleichweise revolutionär anders zu machen, ein ganz neues Produkt/Konzept zu entwickeln (vllt. sogar x86 ersetzen oder etwas in der Größenordnung). Darauf hat er 2 Jahre hin gearbeitet und mit einem/mehreren Team/s ein Konzept und einen Fahrplan entwickelt (Big Project of Oregon). Das Management hat das Projekt und die Ideen eine Weile mitgetragen und nun aber doch kalte Füße bekommen/das Potential nicht gesehen und die Sache gekippt und beendet. Darauf hin verlässt Keller Intel nun wieder.

Das ganze passt ziemlich gut zusammen... Wenn man das Interview gesehen hat. Da sagt er so etwa: man müsste in der Entwicklung häufiger einen neuen Ansatz wählen, etwas komplett anders machen. Der normale Ansatz ist Produkt A jährlich weiter zu entwickeln und besser zu machen. Er meint man müsste häufiger ein neues Produkt B 'from scratch' entwerfen, auch wenn dies zunächst bedeutet dass Produkt B teilweise langsamer ist als Produkt A. Sein Produkt B hätte aber das größere Entwicklungspotential, wäre also nach z.B. 3 Jahren dann deutlich schneller als Produkt A.
Er sagt selber dass dies problematisch ist für das Marketing. Das Marketing will möglichst jedes Jahr, in möglichst allen Bereichen leichte Steigerungen. Das lässt sich einfach besser verkaufen.

Da das Interview wurde vor etwa 4 Monaten aufgezeichnet und da war das Ganze sicher schon absehbar. Viele der Aussagen im Interview lassen sich also direkt auf Intel beziehen.
Er wollte also wohl etwas ziemlich Neues entwickeln in dem er großes Potential gesehen hat, aber Intel hat sich für kontinuierliche Weiterentwicklung entschieden.

Bedeutet für mich auch: Bei Intel ist in den nächsten Jahren nicht unbedingt mit der großen Keule/der großen Überraschung zu rechnen.

Grüße
 
  • Gefällt mir
Reaktionen: Tanzmusikus und Smartbomb
Zurück
Oben