Gå til innhold

VIA lanserer C7


Anbefalte innlegg

Videoannonse
Annonse

16-way assosiativ L2 cache. Da blir den ikke så liten som den ser ut som. P4 har vel 8-way mens det faktisk ser ut som om A64 også har 16-way. Er vel den høye frekvensen til P4 som gjør at de må ha 8-way assosiativ cache tipper jeg.

Endret av Anders Jensen
Lenke til kommentar
Sokkelen er en 479-pinners variant, men den skal ikke være kompatibel med Intels sokkel 479-plattform.

Kunne de ikke bare ha lagt til en pinne (Vcc eller GND) for å unngå forvekslinger og missforståelser :yes:

 

Videre har prosessoren støtte for SSE2- og SSE3-instruksjoner og er utstyrt med 128 kB L2-cache.
128 KiB L2 kan vel bli litt lite selv om den skulle være veldig rask? A64-serien har jo f.eks 128 KiB L1 cache. Ellers: Støtter den ikke 64bit? Er ikke det på tide for en nylansert CPU nå i disse 64bit-tider? Endret av Simen1
Lenke til kommentar

Hadde det ikke vært en fordel å bruke intel sin 478 sokkel? Da hadde man fått gode og billige hk også. Tror det er veldig få som kommer til å kjøpe denne cpuen, og spesiellt når de må ha et nytt hk til den. Da er det jo like godt å kjøpe en dothan og et asus hk med 478 sokkel og en konverter. Og man har et system som bruker bortimot like lite strøm og som sikkert yter bedre.

Lenke til kommentar
16-way assosiativ L2 cache. Da blir den ikke så liten som den ser ut som. P4 har vel 8-way mens det faktisk ser ut som om A64 også har 16-way. Er vel den høye frekvensen til P4 som gjør at de må ha 8-way assosiativ cache tipper jeg.

Ikke vet jeg. Hva får deg til å koble dette sammen med klokkefrekvens?

 

Det jeg vet er at spørsmålet om n-way blir en avveining mellom søketid og cache miss. Altså hvor mange tags prosessoren må søke gjennom for å finne den/de rette blokken(e) i forhold til risikoen for at den må laste og tømme cache flere ganger hvis dataene okkuperer flere blokker i RAM enn det er blokker i hver "frame" i cache.

Søketiden på en 16-way blir doblet i forhold til 8-way, mens risikoen for cache miss blir mindre siden mer data er tilgjengelig innenfor samme "Block Frame". (avhenger selvsagt av programmet som kjøres)

 

Sånn sett skulle en tro at høyere klokkefrekvens betydde mulighet for høyere "n" (f.eks. 16 i stedet for 8). Men ikke spør, har ikke så mye peiling på dette.

 

Edit: omformulering

Endret av el-asso
Lenke til kommentar
16-way assosiativ L2 cache. Da blir den ikke så liten som den ser ut som. P4 har vel 8-way mens det faktisk ser ut som om A64 også har 16-way. Er vel den høye frekvensen til P4 som gjør at de må ha 8-way assosiativ cache tipper jeg.

Ikke vet jeg. Hva får deg til å koble dette sammen med klokkefrekvens?

 

Det jeg vet er at spørsmålet om n-way blir en avveining mellom søketid og cache miss. Altså hvor mange tags prosessoren må søke gjennom for å finne den/de rette blokken(e) i forhold til risikoen for at den må laste og tømme cache flere ganger hvis dataene okkuperer flere blokker i RAM enn det er blokker i hver "frame" i cache.

Søketiden på en 16-way blir doblet i forhold til 8-way, mens risikoen for cache miss blir mindre siden mer data er tilgjengelig innenfor samme "Block Frame". (avhenger selvsagt av programmet som kjøres)

 

Sånn sett skulle en tro at høyere klokkefrekvens betydde mulighet for høyere "n" (f.eks. 16 i stedet for 8). Men ikke spør, har ikke så mye peiling på dette.

 

Edit: omformulering

errr? Med høy assosiativitet og høy frekvens vil en få uakseptabelt høy latency målt i klokkesykler. Du sier jo egentlig det selv, men konkluderer motsatt. Merkelig. :dontgetit:

 

Søketiden er jo selvfølgelig i bunn og grunn relatert til tid og ikke klokkesykler. Hadde søketiden for 1MB 16-way cache vært et konstant antall klokkesykler uansett frekvens så hadde alle CPU produsenter lagd speedracere som parkerer P4 for lengst eller kjørt cache på dobbel klokkefrekvens eller.no...

Endret av Anders Jensen
Lenke til kommentar
errr? Med høy assosiativitet og høy frekvens vil en få uakseptabelt høy latency målt i klokkesykler. Du sier jo egentlig det selv, men konkluderer motsatt. Merkelig. :dontgetit:

 

Søketiden er jo selvfølgelig i bunn og grunn relatert til tid og ikke klokkesykler.

Tanken var at hvis forsinkelsen ved henting av ett bestemt sett med data fra minnet er ett visst antall klokkesykluser (som øker dersom en f.eks. går fra fra 8 til 16-way ass.) så vil den økte forsinkelse målt i antall klokkesykluser kompenseres (målt i tid) gjennom økt klokkefrekvens.

 

Jeg trakk da den konklusjonen (fredagskveld med øl og reker er ikke alltid det beste tidspunktet å forklare hva man mener eller konkludere på) at høyere klokkefrekvens gir mindre forsinkelse i tid en lavere frekvens og derfor er bedre egnet til many-way associative cache.

Nuvel :p

Lenke til kommentar
  • 2 måneder senere...

ZDNet har et interessant intervju med VIAs Keith Kowal vedrørende C7-M som ble lansert 1. juni:

 

If AMD is David and Intel is Goliath, What is VIA? Cinderella?

Kowal, a native of Canada now living in Taiwan where VIA is headquartered, is touring the US to talk about the latest addition to VIA's processor lineup — the C7-M.  The "M" stands for mobile and, according to VIA, this processor is, watt-for-watt, the most powerful processor on the market (although it could be true, I can't verify this since no systems are shipping yet). What's so special about the C7-M? It's a 2 GHz x86-compatible processor that, according to Kowal, not only takes only 20 watts of power (Intel's latest Pentium M takes 27 and AMD's most advanced Turion, which is 64-bit capable, takes 25) but also has a built-in security co-processor that can perform AES encryption on data being transmitted across the network or stored locally on the hard drive in real time.

 

During the interview, Kowal and I covered a lot of ground.

[...]

Here are some highlights from the interview:

 

Kowal on why VIA can find its way in the battle between Intel and AMD when Transmeta couldn't:

 

    There is a big battle going on – always between Intel and AMD. But our previous processor – the C3 – was very successful in some areas of the market. We’re very strong in the embedded space. We developed the mini-ITX form factor which did very well and is based on our C3 processor.  Our core design values around the C7 and the previous C3 are all about low power and low thermals that can enable a lot of very cool designs.  Much like Transmeta.  Via also has the strong backing behind it of the platform base of chipsets and the strong partnerships with the foundries.  So we come from a much stronger base level and that’s why we’ll be able to succeed.

 

Kowal on why VIA's technology means we'll see fanless (ultra quiet) notebook computers:

 

    I think with C7-M and later we’ll have some ultra low voltage parts, yes, fanless is very possible.  In fact, we expect most of the early design wins will have a minimal of cooling…. It depends on the manufacturer.  If there is a fan, it’s going to be pretty small and not making much noise. They’re using our ultra cool processors [that have] a tiny die size and a tiny transistor count.  So, therefore, they put out very little heat.

 

Kowal on whether or not capacity or yield will be a problem for the new mobile processors:

 

    Manufacturing is done in IBM’s Fishkill fab in New York.  We're happy with how things are looking right now and don’t see any capacity problems.

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...