Google breidt team dat aan eigen chips werkt uit

Google heeft zijn team dat aan eigen chips werkt in de afgelopen periode flink uitgebreid, dat blijkt onder andere uit LinkedIn-profielen en vacatures. De zoekgigant heeft ten minste zestien chipontwerpers in India aangenomen.

Persbureau Reuters schrijft over de uitbreidingen naar aanleiding van de vacatures en profielen, maar ook haalt het persbureau een expert van een onderzoeksbureau aan die de chipindustrie volgt. Google zou in Bangalore verschillende chipontwerpers ingehuurd hebben. In die stad in India zijn traditionele chipfabrikanten al lange tijd actief.

Google heeft zestien ervaren ontwerpers aangenomen, die van andere bedrijven zoals Qualcomm, Broadcom en Nvidia afkomstig zijn. Ook staan er nog dertien vacatures open. Google wil tegenover Reuters niet ingaan op het aanstellen van de nieuwe mensen. Het is niet duidelijk waar de nieuwe werknemers zich precies op richten.

Google werkt al langer aan eigen chips, net als andere grote techgiganten. Onder meer Amazon, Microsoft, Apple en Facebook werken aan eigen hardware. Vooralsnog is Googles eigen hardware met name gebruikt in servers en voor deeplearning, maar in 2017 nam het bedrijf een chipontwerper van Apple in dienst en Google heeft eerder aangegeven zelf socs voor smartphones te willen maken.

Reacties (36)

[oef!]

Ik denk dat het hier los van staat. Google heeft momenteel een probleem met socs voor smartwatches omdat Qualcomm niets fatsoenlijks produceert. Daar komt bij dat het niet perse allemaal cpus hoeven te zijn, ook modemchips zijn interessant net als cpus voor apparaatjes als Google Home, etc.

[kidde]

Bij dit Google clubje komen ca 35 mensen te werken, bij Qualcomm zitten er 33800, ca 1000x zoveel.

En dan moet Google iets beters maken met 1000x zo weinig mensen?

[RJG-223]

En dan moet Google iets beters maken met 1000x zo weinig mensen?

Dat lijkt me niet zo moeilijk. Als je 33800 mensen hebt die zich met het ontwerp bemoeien dan wordt het een gedrocht, als het ooit afkomt.
[/s]

Ga geen appels met peren vergelijken. De vraag is dus hoeveel van die 33800 mensen er met het daarwerkelijk ontwerpen van een enkele chip bezig zijn. En dan moet je ook nog kijken in welk deel van het ontwerptraject die chip zich bevindt, want afhankelijk daarvan variëert het aantal mensen ook...

[fastedje]

De eerste ARM cpu is ook met een klein team van tientallen mensen ontwikkeld, waarbij er toch aardig wat innovatieve oplossingen zijn bedacht.

[Xom]

Met een klein team kun je juist veel innovatiever zijn. Al kan het dan wat langer duren. Maar je zit niet vast aan lopende band werk en de stukjes die andere teams gemaakt hebben die ze moeten implementeren.

[encryped]

Ik denk dat Google deze chip designers hebben aangenomen voor het maken van hun eigen AI chips. Binnenkort komt er ook een "consumenten" versie a la raspberry pi van hun AI chip uit. Dit board heet Edge TPU opzich wel interessant om in de gaten te houden https://aiyprojects.withgoogle.com/edge-tpu.

[mutley69]

Het is bangelijk dat iedereen terug naar eigen-chip eerst wil - weg met open, terug naar een hyperdure gouden kooi. Zijn we de begintijden van computing vergeten? Niks werkte samen, en alles om zaken samen te laten werken was peperduur.

[Daniel_Elessar]

Als ze vinden dat Qualcomm niet genoeg innoveert/ vernieuwd en ze denken dat ze dat beter kunnen waarom niet?
Ik deel je scepsis wel over het samenwerken. Maar de OS'en zijn tegenwoordig uniformer dan toen dus in die zin zal het wel loslopen.

[batjes]

Het lijkt er meer op dat we terug gaan naar de begindagen van ARM. Dat een OS elke verschillende ARM chip apart mag gaan ondersteunen, wat de algehele ontwikkeling absoluut niet ten goede komt. Of we daar nu zo blij mee moeten wezen?

[Daniel_Elessar]

Het is de vraag in hoeverre een OS veel verschillende ARM chips gaat ondersteunen. Samsung maakt van Tizen gebruik voor hun watch. Apple heeft hun eigen chips en OS en dan is het enkel android die de kans heeft verschillende chips te moeten ondersteunen. Of Google zegt daar, je zoekt het uit, dit is het en daarmee moet je het doen.

[N8w8]

Al die verschillende ARM chips waren in Linux (en dus Android) een grote puinzooi, en nog steeds is het niet helemaal in orde (wordt nog aan gewerkt).
Maar tegenwoordig is Linux iig zo ingericht dat een chip toevoegen met een bestaande architectuur niet zo'n big deal is. Als ze bijv de zoveelste(?) Cortex A72 ofzo chip maken, dat is niet zo'n probleem voor de software.
Maar goed, geen idee wat hun plannen zijn uiteraard.

@Daniel_Elessar Tizen en Android zijn allebei Linux. En die ondersteunt al enorm veel chips, zie hier.

[Daniel_Elessar]

Ja, daar heb je helemaal gelijk in. Dat had ik misschien beter moeten verwoorden. Ik splitste het op tussen wat de grote fabrikanten doen.

[Jackxl]

Wellicht juist RISC ? V5 is onlangs opensource geworden en chips kunnen gemaakt worden zonder dure licenties.

Lijkt me voor de performance ook beter om naar een compacte instructieset te gaan.

[t_o_c]

Maar wat is het alternatief? Moeten we willen dat alleen Intel x86 cpu's maakt en alleen Qualcomm ARM SoC's? Uiteraard lekker makkelijk voor de OS ontwikkelaars maar het komt de innovatie en prijs niet echt ten goede. Kijk maar naar de x86 markt, jaren lang paar procent performance increase per nieuwe cpu terwijl Intel vrolijk de hoofdprijs bleef vragen.

Is het nu trouwens zoveel anders? Elk OS ondersteund sowieso al een hele reeks verschillende x86 of ARM cpu's want zelfs de cpu's van een fabrikant verschillen per generatie.

[wootah]

Het zou goed kunnen dat het een RISC-V cpu is waar ze aan werken.
Google is een "founding platinum" member: https://riscv.org/members-at-a-glance/

Dus zoals vroeger zal het wel niet worden

[Idunno_WhyNoT]

Dit gaat Google zeker helpen om HW en SW nauwer op elkaar aan te laten sluiten, wat performance zeker ten goede komt.

[Verwijderd]

Precies. Dat mag dan ook wel. Ik zou heel graag een top smartphone van Google willen zien. Nee de Pixel hoef ik voorlopig niet.

[lasharor]

Ik voorspel dat Google met de overname van de smartwatch afdeling van Fossil ook gaat werken aan een nieuwe soc voor wearables. Zeker als je bedenkt dat de concurrentie (Samsung en Apple) erg ver voorlopen en de reguliere kanalen (Qualcomm) eigenlijk niet aan vernieuwing doen.

Ben benieuwd waneer we de eerste vruchten hiervan gaan zien. Ik meen mij te herinneren dat ook met de Pixel al vrij snel na het opzetten van het team nieuwe devices aangekondigd werden.

[Bem]

Jammer dat ze het waarschijnlijk closed-sourced blijven houden. Ik snap dat er geld verdiend moet worden, maar zijn we met zijn allen niet beter af als er een écht goede open source versie verschijnt? Zo heeft Google bijvoorbeeld ook al veel dingen ge-open-sourced wat betreft AI (TensorFlow)

[hooibergje]

het is wel eens goed als de decades-old x86 architectuur op de schop wordt genomen. Er is ruimte voor iets totaal nieuws.

[SinergyX]

Is nieuw per definitie dan beter? Ik verwacht echt geen x86 vervanger van Google, eerder een directere soc voor phones en wearables tegenover een Samsung, Apple of Qualcom met z'n ARM.

[robvanwijk]

Is nieuw per definitie dan beter?

Niet per definitie, maar bedenk je wat voor afzichtelijk gedrocht x86 is (of, beter gezegd, "in de loop der tijd, met uitbreiding op uitbreiding op uitbreiding... is geworden") en iets ontwerpen dat beter is dan dat, da's niet zo heel lastig.

Het probleem is dat x86 zo gigantisch belangrijk is, dat er in de loop der jaren talloze miljarden is geïnvesteerd in compilers, optimalisaties en een oneindige hoeveelheid library-code... Opnieuw beginnen is op de lange termijn een heel goed idee, maar op de korte termijn krijg je het vrijwel niet van de grond. Om ook maar enige kans van slagen te hebben, zal je nieuwe architectuur alsnog x86-code moeten kunnen uitvoeren (en minstens net zo goed als x86-processoren!) én een gigantisch, onomstootbaar voordeel ten opzichte van x86 moeten hebben. Om maar een voorbeeld te noemen: Itanium kon het eerste half (de x86-performance was erg matig) en het tweede zeker... maar is desondanks alsnog geflopt.

[Reactie gewijzigd door robvanwijk op 23 juli 2024 00:39]

[N8w8]

x86 is helemaal niet zo slecht, tuurlijk het heeft vanwege Wintel veel momentum maar dat is niet het enige waardoor het nog steeds zo populair is. Er zijn ook concurrenten als POWER/SPARC bijvoorbeeld, die doen bepaalde datacenter taken erg goed en worden dan ook graag ingezet als daarmee een boost te krijgen is.
Er zijn tegenwoordig ook ARM Chromebooks (= het "desktop" platform van Google). ChromeOS=Linux en die ondersteunt vanalles, dat is de beperking dus ook niet.

Maar x86 is vaak gewoon de betere keus (qua €/W/IPS/whatever). Dat het "onder de motorkap" mss geen meesterwerk is, ok, maar hoeveel merk je daar nou helemaal van als gebruiker?

Ik begrijp dat t probleem van Itanium was, dat ie zo ontworpen was dat de compiler een grote rol heeft in hoe ie lowlevel functioneert/presteert. En het bleek toen wel erg moeilijk een goeie compiler ervoor te schrijven die eruit haalt wat erin zit.
Ja, als ie geweldig x86 had gedraaid dan had ie t zeker overleefd want waarom niet.
Maar los daarvan deed ie t gewoon in t algemeen niet goed begrijp ik, ook niet op dat (jouw) tweede punt. Althans, in vergelijking met POWER enzo, die nota bene helemaal geen x86 kan draaien.

Maar inderdaad, voor de Windows desktop is x86 prestaties (nog) wel een must.

[_Thanatos_]

Niet per definitie, maar bedenk je wat voor afzichtelijk gedrocht x86 is (of, beter gezegd, "in de loop der tijd, met uitbreiding op uitbreiding op uitbreiding... is geworden") en iets ontwerpen dat beter is dan dat, da's niet zo heel lastig.

Niet? Doe maar dan

Alle software maakt wel gebruik van al die instructies en extra's. Het is niet alsof het allemaal overbodig is. Het is vooral een andere denkwijze dan die van de ARM architectuur.

[robvanwijk]

Het is niet alsof het allemaal overbodig is.

Dat zeg ik ook niet. De huidige versie van x68 heeft twee grote problemen: backwards compatibility en ontwerpers die niet in de toekomst konden kijken. Die twee samen zorgen ervoor dat de instructieset hopeloos complex is geworden.

Oude instructies (en hele subsystemen, zoals bijvoorbeeld addressing modes) die indertijd een goed idee leken maar intussen in onbruik zijn geraakt worden nog steeds ondersteund en zullen (voor zover ik Intel in kan schatten) ook nooit verwijderd worden. Backwards compatibility is een groot goed, maar komen we niet een keer op het punt waar we moeten zeggen "we ondersteunen voortaan alleen nog maar 32 bit en 64 bit modes; alle andere moet je maar in een emulator draaien (de snelste 16 bit x86-processor die ooit gemaakt is kunnen we immers met gemak in real-time emuleren)"...? Hetzelfde geldt voor segment addressing: ooit waren we dolblij met een address space van 20 bit op een 16 bit processor, maar vandaag de dag is één, platte 48 bit (??) address space oneindig veel handiger; afschaffen die hap.

Daarnaast is de instructieset stapje voor stapje gegroeid. Als je de hele instructieset die we nu hebben opnieuw in zou mogen delen, dan kun je het hele verhaal gigantisch vereenvoudigen. Zijn die prefixes (en hun oneindige combinaties) echt nodig, kan dat niet handiger? Welke instructies worden nou echt het meest gebruikt (en hebben dus het meeste voordeel van een korte op code)? Welke groepen van instructies lijken enorm op elkaar en kunnen voordeel hebben van vergelijkbare op codes? En misschien wel het belangrijkst: kunnen we het dusdanig indelen dat je aan een paar bitjes in de eerste byte meteen kunt zien hoe lang de gehele opcode is?

[_Thanatos_]

Ik denk dat die backwards compatibility ook wel langzaamaan zal verdwijnen, maar door de enorme userbase en variëteit aan scenarios waar zon chip gebruikt wordt, gaat dat nou eenmaal wat langzamer.

Bij iets als ARM gaat dat veel sneller omdat die chips zo goed als exclusief worden geleverd in kant-en-klare systemen waar je de chip niet kunt verwisselen voor een andere. De chip kan dus gemaakt worden voor het platform, en de software, waarvoor het gebruikt wordt en hoeft niets anders te ondersteunen.

PowerPC en Itanium en andere niet-x86 general purpose CPU's zitten er feitelijk tussenin. Ontworpen voor een specifiek platform, maar moeten wel veel verschillende hardware en software kunnen draaien.

Ik ben het we met je eens dat het tijd is om de echt antieke onderlen van x86 maar es te ditchen. Ik probeer alleen te zeggen dat er ook wel een reden is dat al die dingen zo lang rond zijn blijven hangen.

[boner]

iets zals sparx, of itanium of powerpc? Denk nu niet dat dit de eerste keer is dat er iemand een chips heeft geprobeerd te maken die met de X86 of x64 kan concureren. En sommign doen het heel erg goed. De best presterende alternatieve processor naast de x-64 is de ARM. Ik denk dat er meer telefoons dan computers zijn,en dus is het marktaandeel van deze proc groter dan die van de X64.

[JaXter608]

Opvallende stap van Google. Lay’s en Pringles dekken al een groot marktaandeel, als mede ook de huismerken. Dan heb je nog de “gezonde” alternatieven die steeds populairder worden zoals Kettle. Nee dit wordt geen walk in the park voor Google. Wie weet dat ze de chips markt een nieuwe impuls kunnen geven.

[mkools24]

Haha zo jammer dat er nog steeds geen +grappig moderatie bestaat. Groot gemis hier op Tweakers. Wat is het leven zonder humor

Jammer van al die minners van mij een boost +3.

[Daniel_Elessar]

Het is natuurlijk als je de moderatie erbij pakt niet 'on-topic' maar er zou inderdaad een "grappig" moderatie mogen komen.
Want dit was gewoon een goede opmerking. Die ik in de tweeakters huiskamer zou tegenkomen in het topic ludiek antwoorden topic.

[MrMonkE]

Haha zo jammer dat er nog steeds geen +grappig moderatie bestaat.

Nee, want dan gaat iedereen schijtlollig lopen doen om die +grappig te scoren.

[_Thanatos_]

Dat zijn geen chips, dat zijn crisps

Chips eet je met mayonaise of satésaus met uitjes en een berenlul. Je kunt ze op iedere hoek van de straat bij de lokale vreetschuur kopen. In de UK eten ze ze met vis en wat azijn erover gesprenkeld.

[Reactie gewijzigd door _Thanatos_ op 23 juli 2024 00:39]

[Brummetje]

Het is hier geen Dumpert he

[BikkelZ]

Wel mooi, een beetje terug naar de jaren '80 waar iedereen zijn eigen platform ontwikkelt maar dan wel allemaal de zelfde instructieset gebruiken dus het blijft allemaal compatible. Intel en Qualcomm hebben veel te lang met hun luie reet op hun dikke patentenportfolio gezeten.