Intel skal friste med mer Sandy Bridge

[RBW]

Om du speider etter en rimelig Sandy Bridge-prosessor så skal utvalget utvides i mai.

 

Les mer

[lavizh]

Sikkert en fin løsning men blir nok evigheter til at jeg bytter ut min Intel Core i7 920. Den fungerer nok utmerket i 2-3 år til, hvertfall til mitt bruk.

[GullLars]

Om det kommer en T-utgave av 2105 blir det mye mulig en slik i HTPC #2 som sansynligvis skal bygges i mai, forutsatt HD 3000.

[Blazer]

er nok ingen vits å bytte fra i7/i5 til sandy bridge. er nok mer for de med core2 cpuer. sandy bridge er jo bare en opptimaliserte utgaver av "gammle" i5/i7

[Anders Jensen]

er nok ingen vits å bytte fra i7/i5 til sandy bridge. er nok mer for de med core2 cpuer. sandy bridge er jo bare en opptimaliserte utgaver av "gammle" i5/i7

Enig i at det er lite vits i å gå fra i7/i5 til Sandy Bridge, men det er ikke riktig at den bare er en optimalisert utgave av forrige generasjo. De har faktisk tatt seg bryet med å redesigne kjernen fra bunnen av. Resultatet ligger noe i mellom i7 og Pentium4. At de ikke har klart å fått så mye ut av et fullt redesign skyldes vel to ting; i7 var bra og x64 kan ikke bli så veldig mye bedre...

 

Ved neste generasjon, Ivy Bridge som bare er en optimalisering av Sandy bridge, kan en forvente et hopp i ytelsen siden vi får ny CMOS generasjon (22nm).

 

Så får vi se hvor kineserne vil med MIPS64 og hva Intel vil med ia64... x64 er tidenes blindspor inn i fremtiden.

Endret 26. april 2011 av Anders Jensen

[genesis]

Noen som vet når vi kan forvente ny revisjon av 2500K / 2600K ?

Endret 8. januar 2014 av Zeph

[N o r e n g]

Noen som vet når vi kan forvente ny revisjon av 2500K / 2600K ?

Når Intel krymper ned til Ivy Bridge vil jeg tro. Begge de to du har nevnt er jo fantastiske produkter, folk har overklokket stabilt opp til 4.5GHz med alt annet på auto.

Om du ser etter utgaver som kommer ferdig klokket kan det jo hende Intel lanserer en i7-2650 på 3.8 GHz for eksempel. Jeg tviler rimelig sterkt på at dette skjer før de får noe konkurranse da.

 

Et H67-oppsett med i3-2105 blir enda mer fristende.

[Loff1]

Så får vi se hvor kineserne vil med MIPS64 og hva Intel vil med ia64... x64 er tidenes blindspor inn i fremtiden.

Hva med x86-64 er det som gjør den til et «blindspor»? Har du eventuelt noen lenker for å utdype?

[Anders Jensen]

Så får vi se hvor kineserne vil med MIPS64 og hva Intel vil med ia64... x64 er tidenes blindspor inn i fremtiden.

Hva med x86-64 er det som gjør den til et «blindspor»? Har du eventuelt noen lenker for å utdype?

Blindspor som i utdatert teknologi. Det ville vært en fordel å bli kvitt x64 for å få bedre ytelse i fremtiden. ARM har lykkes greit med dette i segmenter med lav effekt, men ARM er mindre egnet til større systemer. Nettet er fullt av lenker om dette om en er interessert i å google, men noen enkel wiki artikkel som belyser alle sider nøytralt er vel lite sannsynlig at en finner.

[N o r e n g]

Så får vi se hvor kineserne vil med MIPS64 og hva Intel vil med ia64... x64 er tidenes blindspor inn i fremtiden.

Hva med x86-64 er det som gjør den til et «blindspor»? Har du eventuelt noen lenker for å utdype?

Blindspor som i utdatert teknologi. Det ville vært en fordel å bli kvitt x64 for å få bedre ytelse i fremtiden. ARM har lykkes greit med dette i segmenter med lav effekt, men ARM er mindre egnet til større systemer. Nettet er fullt av lenker om dette om en er interessert i å google, men noen enkel wiki artikkel som belyser alle sider nøytralt er vel lite sannsynlig at en finner.

"Problemet" blir vel taklet på forskjellige måter av prosessorprodusentene:

Intel forbedrer X86 til det uendelige, mens AMD har nå begynt å nærme seg en kombinasjon av CPU og GPU.

Det hadde ikke overrasket meg om et kom et eget instruksjonssett som benytter den enorme paralelle prosesseringskraften i en GPU.

[vidarsd]

Jaja, men dette er ikke noe for meg skal kjøpe meg 2500k, men kan jo håpe på at prisen synker litt da

[Anders Jensen]

Så får vi se hvor kineserne vil med MIPS64 og hva Intel vil med ia64... x64 er tidenes blindspor inn i fremtiden.

Hva med x86-64 er det som gjør den til et «blindspor»? Har du eventuelt noen lenker for å utdype?

Blindspor som i utdatert teknologi. Det ville vært en fordel å bli kvitt x64 for å få bedre ytelse i fremtiden. ARM har lykkes greit med dette i segmenter med lav effekt, men ARM er mindre egnet til større systemer. Nettet er fullt av lenker om dette om en er interessert i å google, men noen enkel wiki artikkel som belyser alle sider nøytralt er vel lite sannsynlig at en finner.

"Problemet" blir vel taklet på forskjellige måter av prosessorprodusentene:

Intel forbedrer X86 til det uendelige, mens AMD har nå begynt å nærme seg en kombinasjon av CPU og GPU.

Det hadde ikke overrasket meg om et kom et eget instruksjonssett som benytter den enorme paralelle prosesseringskraften i en GPU.

GPU kan i dag sammenlignes med en lang rekke CPU + intern RAM systemer med en felles koordinator som fordeler trådene utover hver (CPU) kjerne og et felles eksternt minne. Instruksjonssettet kjernene i dagens GPU kjører er kjent under samlebetegnelsen VLIW, som er en av hovedgruppene med instruksjonssett. Very Long Instruction Word er i praksis RISC instruksjoner bundlet sammen. Typisk 3 eller 4 stykk i hver bundle. Generelt er VLIW mer dynamisk enn SIMD, men mindre dynamisk enn RISC eller CISC. IA64, eller EPIC (Explicitly Parallel Instruction Computing) kalles ofte en avart av VLIW. Det er noe unøyaktig, men la gå. VLIW definerer strengt hvor mange instruksjoner det er i hver bundle og hvilken execution unit hver instruksjon skal sendes til. For IA64 er det definert et 5bits template felt i hver bundle som forteller hvor mange instruksjoner det er, hvilken type de har og om de kan kjøres i parallell eller ikke. IA64 prosessoren må selv finne ut hvilken execution unit den skal tilordne hver instruksjon. Fordelen er først og fremst at en nå kan endre mikroakitetkturen uten å måtte endre instruksjonssettet slik en må med VLIW. For flertrådede IA64 prosessorer kan en også unngå at execution units benyttes til å kjøre no-ops ("tom instruksjon") som utgjør ca 20% for VLIW.

Endret 27. april 2011 av Anders Jensen

[007CD]

De som sitter på ett LGA 1366 system kan bare glemme 1155 og 1156.

Arvtageren til 1366 er ikke lansert, og disse sokkelene er ikke entusiast versjonen.

Hva Intel slipper med sitt neste X brikkesett skal dog bli spennende å se.

Socket 2011 blir i allefall ett pinne helvete.

[GullLars]

Det hadde ikke overrasket meg om et kom et eget instruksjonssett som benytter den enorme paralelle prosesseringskraften i en GPU.

Som Anders sier, VLIW. På et høyere nivå har man også OpenCL som nye GPUer støtter, DirectCompute, og CUDA (for nvidia).

[N o r e n g]

Det hadde ikke overrasket meg om et kom et eget instruksjonssett som benytter den enorme paralelle prosesseringskraften i en GPU.

Som Anders sier, VLIW. På et høyere nivå har man også OpenCL som nye GPUer støtter, DirectCompute, og CUDA (for nvidia).

Nå skal ikke jeg si at jeg er noen ekspert på dette området, men jeg vil jo tro Intel Quicksync er et program der CPU samarbeider med GPU for å arbeide raskere enn det man tidligere trodde var mulig.

Jeg trodde at det burde være mulig å lage et eget instruksjonssett slik at det ble mulig å utnytte denne regnekraften en GPU har til spesifikke CPU-operasjoner. Anders forklarte ganske greit at dette ikke var mulig uten å låse seg inn på en spesifikk GPU-arkitektur.

 

Høynivå er jo greit det, men det er ikke feil om man kan gjøre dette på lavere nivåer. En fordel med CPU og GPU på en brikke er jo at kommunikasjonen går over kortere avstander.

[GullLars]

Nå skal ikke jeg si at jeg er noen ekspert på dette området, men jeg vil jo tro Intel Quicksync er et program der CPU samarbeider med GPU for å arbeide raskere enn det man tidligere trodde var mulig.

Jeg trodde at det burde være mulig å lage et eget instruksjonssett slik at det ble mulig å utnytte denne regnekraften en GPU har til spesifikke CPU-operasjoner. Anders forklarte ganske greit at dette ikke var mulig uten å låse seg inn på en spesifikk GPU-arkitektur.

 

Høynivå er jo greit det, men det er ikke feil om man kan gjøre dette på lavere nivåer. En fordel med CPU og GPU på en brikke er jo at kommunikasjonen går over kortere avstander.

Quicksync er en utvidelse av spesialisert hardware for medie en/de-koding, og tillater aksellerering av transkoding. Med spesialisert hardware er det mulig med ytelse på et høyere nivå enn CPU/GPU. F.eks. har noen intel prosessorer AES aksellerering som øker hastigheten langt over 10x.

 

Når alle nye GPUer støtter OpenCL er dette kjekt å bruke i diverse programmer i plug-in moduler for å aksellerere visse ting. Med OpenCL trenger ikke programmerere å tenke på hvilken GPU som brukes.

 

Det du tenker på høres ut som noe ala å la scheduler legge større SIMD operasjoner ment for CPU til GPU.