Gå til innhold

Nvidia følger strømmen


Anbefalte innlegg

Videoannonse
Annonse

Greit nok at ARM er den store hypen i mobil/nettbrett segmentet for tiden, men en skulle vel tro at MIPS var bedre egnet til datasett med krav til 64bit addressering. ARM sin støtte for adresseområde større enn 32bit er litt klattiklatt løsning for tiden.

 

Edit: MS sin støtte til ARM var antagelig viktig for valget. Vi får se om ikke MIPS kommer inn i varmen i større grad ettersom 64bit blir mer gjeldende i non-x86 consumer maskiner.

Endret av Anders Jensen
Lenke til kommentar

Veldig spennende! Akkurat det Nvidia trenger for å henge med de to andre CPU + GPU produsentene. ARM er sikkert noe hypet, men jeg tror det er et godt valg med tanke på programvarestøtte i mobile og håndholdte dingser og til dels markedet for bærbare og stasjonære PCer. I servermarkedet (Tesla) kan det også være nyttig som prosessor for kontroll og administrering av last og sikkerhet i maskinene.

Lenke til kommentar

Android, iOS (apple) og snart MS w8 for ARM gjør jo at enhver ARM plattform har et veldig rikt software miljø med høy frekvens på feilretting. Det er jo alle hardware produsenters drøm å ha noe slikt, og kun AMD/Intel som har hatt det i realiteten siste 20 år.

 

Jeg tror imidlertid server workloads hvor ytelse gjerne skalerer lineært med minnekapasitet blir en vanskelig nøtt å knekke for ARM.

Endret av Anders Jensen
Lenke til kommentar

At man kombinerer ARM kjerner og en GPU er da ikke den store nyheten her. Det er jo det som kalles en SoC, som alle mobiltelefoner har idag og har hatt lenge. Det som er nyheten er at Nvidia skal lage sin egen prosessor arkitektur rundt arm v7(slik som Qualcomm snapdragon(som ikke er cortex a8)). Og at den ikke designes for telefoner/routere/nettbrett, slik som cortex a15(?).

Lenke til kommentar

Joda, og utfordringen er at det innebærer å dra ARM inn i et segment ARM ikke har vært i før. Hvor krav til ytelse og minnekapasitet er høyt og krav til energieffektivitet er middels høyt, og ikke omvendt. Bortsett fra 64bit addressering er det ingenting i veien for at dette skal gå helt greit.

Endret av Anders Jensen
Lenke til kommentar

Bruker RISC generelt mer eller mindre minne enn CISC for å utføre samme typiske desktop-oppgave? Jeg har forstått såpass at RISC har enklere instruksjoner som dermed kan være mindre enn tilsvarende CISC-instruksjoner (med mindre de enkle CISC-instruksjonene kjører på med kortere adresseringsmodi), og jeg antar også at de tar mindre plass i minnet. Men siden RISC innimellom trenger flere instruksjoner for å utføre samme oppgave som en komplisert CISC regner jeg med at RISC i det tilfellet vil ta mer plass. Så hvordan utarter det seg egentlig i praksis? Tar ARM-programmer generelt større eller mindre plass i minnet enn x86-programmer?

Lenke til kommentar
Raptor' timestamp='1294996779' post='16768541']

AMD integrerer minnekontroller i CPU. Intel hermer. AMD integrerer GPU i CPU. Intel hermer. :roll:

Du er klar over at Intel var før AMD til å faktisk levere produkter med GPU integrert i CPU...?

De var før med å levere integrert minnekontroller også... bare litt i overkant sen med å gjeninnføre trikset. Og da snakker vi om det kunstig snevre området x86+IMC. Integret minnekontroller på andre brikker har vært vanlig hos mange.

 

Big deal. Det er uansett HTT og QPI med tilhørende cache coherence protokoll som er poenget her fordi det gjør det mulig å skalere uten multidropp (broadcast) bus til flere sokler, ikke at de fant plass til 1% flere transistorer på en brikke.

 

Det neste store nå er integrert minne, og etter det vil integrert SSD og I/O (NIC/HCA/PCIe/ligtpeak) komme. Man må ikke være rakkettforsker for å gjøre ekstrapolering over 40 år med konsekvent utvikling. Intel har forøvrig levert på PCIe her allerede.

Endret av Anders Jensen
  • Liker 1
Lenke til kommentar
Generelt vil kode størrelsen være som følger;

CISC (x86, x64, osv.) < RISC (ARM, Power, MIPS, osv.) < EPIC (Itanium) < VLIW (flere DSP og GPU design)

 

Dagens minneforbruk er domminert av datasettet, som er uavhengig av ISA, og ikke koden, så det kan diskuteres hvor viktig dette er.

Takk. :)

 

Men hvorfor har de fleste arkitekturer likevel samme størrelse på L1-data og L1-instruksjon? Har instruksjoner og data såpass forskjellig natur at optimal størrelse likevel blir like store, eller gjør de det bare fordi "de kan"? Kanskje det er noen layoutmessige fordeler med å lage dem like store? Hvis datastrømmen er langt større enn instruksjonsstrømmen ser jeg for meg at det ville vært en fordel å bruke litt av instruksjonsplassen til data i stedet.

Atom har faktisk mindre datacache enn instruksjonscache. :p

Lenke til kommentar

Anders Jensen: Du har vært veldig klar på at x86 ikke hører hjemme i de minste håndholdte enhetene.

 

Both Intel and ARM have been working hard to address their weaker areas and there will be a point in the next few years when the performance/power efficiency of these technologies will be equal

 

Er du uenig? Mangler analytikeren kunnskap?

 

http://www.xbitlabs.com/news/cpu/display/20110113124620_Performance_and_Power_Efficiency_of_ARM_and_x86_Will_Be_Equal_Analyst.html

Lenke til kommentar

Intel har (enn så lenge) overlegen CMOS for logikk-transistorer så de kan nok matche ARM på ytelse/watt så snart de får lagd SoC design med x86. Personlig tror jeg ARM vil lykkes bedre i netbooks enn x86 vil lykkes i mobiltelefoner. På sikt vil nok MIPS slå seg opp i det vakuumet som oppstår når ARM begynner å slite med >32bit minneaddr. Så kan det jo hende at Intel snart får til et fornuftig IA64 design som kanskje kan portes ned til mindre enheter. Ville selv mye heller hatt en single core ia64 med 4-way SMT enn en quad core ARM uten SMT i min netbook/laptop gitt at de hadde samme throughput/watt fordi førstnevnte nok ville hatt opptil 3-4x bedre responstid.

Endret av Anders Jensen
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...