abene Skrevet 10. januar 2011 Rapporter Del Skrevet 10. januar 2011 Nvidia skal med prosjekt Denver kombinere CPU og GPU. Les mer Lenke til kommentar
cocopara Skrevet 10. januar 2011 Rapporter Del Skrevet 10. januar 2011 Nvidia vil tørke gulvet med alle andre som bevist med Nvidia Tegra, den beste mobile CPU + GPU løsningen Gleder meg til PC med CPU + GPU Lenke til kommentar
Anders Jensen Skrevet 10. januar 2011 Rapporter Del Skrevet 10. januar 2011 (endret) 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 10. januar 2011 av Anders Jensen Lenke til kommentar
Simen1 Skrevet 10. januar 2011 Rapporter Del Skrevet 10. januar 2011 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
Skinney Skrevet 10. januar 2011 Rapporter Del Skrevet 10. januar 2011 Synes det er flott at en såpass stor aktør som Nvidia satser skikkelig på ARM med en CPU+GPU løsning. Det kan bare love godt for fremtidige generasjoner av løsninger som Motorola Atrix (med laptop dock *sikle*) Lenke til kommentar
Anders Jensen Skrevet 10. januar 2011 Rapporter Del Skrevet 10. januar 2011 (endret) 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 10. januar 2011 av Anders Jensen Lenke til kommentar
Kirchhoff Skrevet 10. januar 2011 Rapporter Del Skrevet 10. januar 2011 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
Anders Jensen Skrevet 11. januar 2011 Rapporter Del Skrevet 11. januar 2011 (endret) 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 11. januar 2011 av Anders Jensen Lenke til kommentar
ATWindsor Skrevet 11. januar 2011 Rapporter Del Skrevet 11. januar 2011 Blir spennende å se hvordan dette utvikler seg i praksis. AtW Lenke til kommentar
endrebjo Skrevet 11. januar 2011 Rapporter Del Skrevet 11. januar 2011 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
Anders Jensen Skrevet 12. januar 2011 Rapporter Del Skrevet 12. januar 2011 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. Lenke til kommentar
mofopop Skrevet 14. januar 2011 Rapporter Del Skrevet 14. januar 2011 AMD integrerer minnekontroller i CPU. Intel hermer. AMD integrerer GPU i CPU. Intel hermer. Lenke til kommentar
HKS Skrevet 14. januar 2011 Rapporter Del Skrevet 14. januar 2011 (endret) AMD integrerer minnekontroller i CPU. Intel hermer. AMD integrerer GPU i CPU. Intel hermer. Du er klar over at Intel var før AMD til å faktisk levere produkter med GPU integrert i CPU...? Endret 14. januar 2011 av [GDI]Raptor Lenke til kommentar
Anders Jensen Skrevet 14. januar 2011 Rapporter Del Skrevet 14. januar 2011 (endret) Raptor' timestamp='1294996779' post='16768541'] AMD integrerer minnekontroller i CPU. Intel hermer. AMD integrerer GPU i CPU. Intel hermer. 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 14. januar 2011 av Anders Jensen 1 Lenke til kommentar
endrebjo Skrevet 14. januar 2011 Rapporter Del Skrevet 14. januar 2011 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. Lenke til kommentar
Anders Jensen Skrevet 14. januar 2011 Rapporter Del Skrevet 14. januar 2011 Det kan jeg knapt mer en gjette på og neppe veldig kvalifisert gjetting heller... men klart mer er bedre, så med gitte krav til effektforbruk, porter, forsinkelse, assosiativitet, osv. vil maksimal størrelse være nokså gitt. Da tar du det største mulige siden transistorer er nesten gratis i dag, kostnaden er å slå de på. Lenke til kommentar
Kirchhoff Skrevet 14. januar 2011 Rapporter Del Skrevet 14. januar 2011 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
Anders Jensen Skrevet 14. januar 2011 Rapporter Del Skrevet 14. januar 2011 (endret) 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 14. januar 2011 av Anders Jensen Lenke til kommentar
Anbefalte innlegg
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 kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå