Quad-kjerne, AMD eller Intel?

[int20h]

Tradisjonelt har antall MHz bestemt ytelsen til en prosessor. I fremtiden vil antall kjerner og arkitektur bestemme mer og mer.

Les mer

[ATWindsor]

Hmm, quad-kjerne for server i 2007, noen som vet noe om når de har tenkt å innføre det på desktop?

 

AtW

[ketle]

EDIT: Snakker her om PC til hjemmebruk og ikke servere:

 

Per i dag er det vel ingen spill og svært få applikasjoner som støtter flerkjerner. Sånn sett så vil det vel lønne seg å kjøpe en singel-kjerne CPU med høyere frekvens også heller kjøpe en med flere kjerner når det kommer spill og programvare som støtter dette. Det virker som om software-bransjen henger litt etter her og da har vel den jevne PC bruker svært lite å tjene på dette? Eller tar jeg feil.

[ATWindsor]

EDIT: Snakker her om PC til hjemmebruk og ikke servere:

 

Per i dag er det vel ingen spill og svært få applikasjoner som støtter flerkjerner. Sånn sett så vil det vel lønne seg å kjøpe en singel-kjerne CPU med høyere frekvens også heller kjøpe en med flere kjerner når det kommer spill og programvare som støtter dette. Det virker som om software-bransjen henger litt etter her og da har vel den jevne PC bruker svært lite å tjene på dette? Eller tar jeg feil.

5284199[/snapback]

 

Sprøs hva du skal bruke det til, personlig synes jeg at jeg merker en større oppgang i "opplevd ytelse" hva å bruke dual-core enn å gå opp endel i frekvens. Multitasking går feks mye bedre.

 

AtW

[el-asso]

Tradisjonelt har antall MHz bestemt ytelsen til en prosessor. I fremtiden vil antall kjerner og arkitektur bestemme mer og mer.

... av ytelsen når man kjører flere programmer samtidig.

 

Den enkleste måten å lage en quad-CPU er trolig å sette to dobbelkjernebrikker på én sokkel. Strategisk er dette en fordel ettersom man vinner tid, men teknisk er ikke dette den beste måten siden man ikke får "ekte" quad-kjerne-CPU

Skal la det med ”ekte” eller ikke ligge, men vet vi med sikkerhet hva som er den beste løsningen? Vet vi om produsentene vil fortsette å bruke de løsningene de har i dag? Og hva menes med best? Best med tanke på skalering? Med tanke på kommunikasjon mellom kjernene? I forhold til båndbredde mot andre enheter på hovedkortet?

 

AMD rapporteres å bytte til en fullstendig ny, skalerbar prosessorarkitektur i 2008/2009

Det høres i hvertfall bra ut, men hva betyr det for levetiden til socket M2?

 

Liker artikler som gjør at en sitter i gjenn med flere spørsmål enn før

Endret 12. desember 2005 av el-asso

[ketle]

EDIT: Snakker her om PC til hjemmebruk og ikke servere:

 

Per i dag er det vel ingen spill og svært få applikasjoner som støtter flerkjerner. Sånn sett så vil det vel lønne seg å kjøpe en singel-kjerne CPU med høyere frekvens også heller kjøpe en med flere kjerner når det kommer spill og programvare som støtter dette. Det virker som om software-bransjen henger litt etter her og da har vel den jevne PC bruker svært lite å tjene på dette? Eller tar jeg feil.

5284199[/snapback]

 

Sprøs hva du skal bruke det til, personlig synes jeg at jeg merker en større oppgang i "opplevd ytelse" hva å bruke dual-core enn å gå opp endel i frekvens. Multitasking går feks mye bedre.

 

AtW

5284211[/snapback]

 

Så hvis jeg f.eks kjører masse programmer i bakgrunnen i XP home edit.og samtidig har oppe Opera, bruker Teamspeak og kjører Battlefield 2, så vil alle disse oppgavene bruke en av to prosessorer istedet for at alle kjører på en? Eller? Hvordan fungerer dette egentlig i praksis? Eller fordeler den "bare" regneoperasjonene på annenhver kjerne ettersom de kommer?

[Ko_deZ]

De kjører på hver sin prosessor.

 

Det at multikjerne kun hjelper for multitasking er en stor haug med kumøkk. Det er knapt vanskelig engang, å lage programmer som distribuerer seg over flere prosessorer. Problemet er bare at de som har laget spill frem til nå ikke har hatt noe nytte av det, og de derfor ikke er veldig gode til slikt.

 

Eksempel: HDTV video. Bruke en prosessor til å dekode video, bruke den andre til post-prosessering av bildet (de-interlace, sharpen, noise reduction osv). Dette er enkelt.

Eksempel2: Bruke ene prosessoren til grafikken og lyden, bruke den andre til å beregne AI for bots og andre motstandere.

 

Disse forandringene er ikke fryktelig vanskelige å få til, det må bare gjøres. Det tar nok neppe lang tid før man begynner å få spill som utnytter dobbelkjerne prosessorer. Spesielt nå, som alle spillprodusenter blir nødt til å tenke multi-core på de nye spill-konsollene.

 

-Ko_deZ-

[Simen1]

Duellen mellom AMD og Intel ser desverre ikke ut til å bli avholdt, men de to prosessorgigantene vil fortsette å kjempe om prosessorkundene.

Er det noen som seriøst hadde forhåpninger om og tro på at duellen skulle bli gjennomført?

 

Den enkleste måten å lage en quad-CPU er trolig å sette to dobbelkjernebrikker på én sokkel. Strategisk er dette en fordel ettersom man vinner tid, men teknisk er ikke dette den beste måten siden man ikke får "ekte" quad-kjerne-CPU

Skal la det med ”ekte” eller ikke ligge, men vet vi med sikkerhet hva som er den beste løsningen? Vet vi om produsentene vil fortsette å bruke de løsningene de har i dag? Og hva menes med best? Best med tanke på skalering? Med tanke på kommunikasjon mellom kjernene? I forhold til båndbredde mot andre enheter på hovedkortet?

5284217[/snapback]

Eller hva som er best med tanke på yield og binning?

 

AMD rapporteres å bytte til en fullstendig ny, skalerbar prosessorarkitektur i 2008/2009, men detaljene er ikke kjent.

Er det noen som har noe mer informasjon om dette? Hva menes med "fullstendig ny"? Er dette noe annet enn en ny modifikasjon av den aldrende K7-kjernen?

[el-asso]

Det er knapt vanskelig engang, å lage programmer som distribuerer seg over flere prosessorer. Problemet er bare at de som har laget spill frem til nå ikke har hatt noe nytte av det, og de derfor ikke er veldig gode til slikt.

 

Eksempel: HDTV video. Bruke en prosessor til å dekode video, bruke den andre til post-prosessering av bildet (de-interlace, sharpen, noise reduction osv). Dette er enkelt.

Eksempel2: Bruke ene prosessoren til grafikken og lyden, bruke den andre til å beregne AI for bots og andre motstandere.

 

Disse forandringene er ikke fryktelig vanskelige å få til, det må bare gjøres. Det tar nok neppe lang tid før man begynner å få spill som utnytter dobbelkjerne prosessorer. Spesielt nå, som alle spillprodusenter blir nødt til å tenke multi-core på de nye spill-konsollene.

 

-Ko_deZ-

5284316[/snapback]

 

Du mener det ja. Fant noen som mener noe annet:

 

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2377&p=3

Implementing a multithreaded system requires two to three times the development and testing effort of implementing a comparable non-multithreaded system, so it's vital that developers focus on self-contained systems that offer the highest effort-to-reward ratio.

[..)

Writing multithreaded software is very hard; it's about as unnatural to support multithreading in C++ as it was to write object-oriented software in assembly language. The whole industry is starting to do it now, but it's pretty clear that a new programming model is needed if we're going to scale to ever more parallel architectures. I have been doing a lot of R&D along these lines, but it's going slowly."

 

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2377&p=1

Even some workstation applications that are supposed to be prime examples of multi-threaded applications are not as multi-core friendly as they appear to be. I ran a lot of Adobe Premier benchmarking with different video formats, and I found out that the second CPU offered a meagre 10% to 40% speed increase in video editing (rendering).

 

NVIDIA Calls For Work On Parallelism

Kirk grounded his pessimism in the experiences of game developers trying to exploit new multicore CPU chips. "We are already seeing some games limited by CPU throughput. We can render images faster than the CPU can send us the data," Kirk said. "But when game developers try to use dual-core CPUs to help, we have seen virtually no benefit to the second CPU core. And if the developer doesn't clearly understand the interactions of the cores with the caches, we have seen the application actually run slower on a dual-core machine."

 

"Your Existing Code? Throw it Away"

"Technologically, I think every game developer should be terrified of the next generation of processors. Your existing code, you can just throw it away. It's not going to be helpful in creating next generation game titles," said Newell.

 

"Most of the problems of getting these systems running on these multicore processors are not solved. They are doctoral theses, not known implementation problems. So it's not even clear that over the lifespan of these next generation systems that they will be solved problems. The amount of time it takes to get a good multicore engine running, the Xbox 360 might not even be on the market any longer.

[balleklorin]

Må bare si meg enig i sitatene til el-asso, det er no herk å programmere multithreaded, det har jeg gjort en del på serversoftware, og der er det relativt "trivielt"..

Jeg kan tenkte meg hvor morsomt det er på en client som krever fullstendig synkronisering mellom threadene som i et dataspill, det blir vel årets spagettiopplevelse med dagens api'er.

[efikkan]

Nå er det vel sånn at det er programmet som må benytte seg av flere kjerner? Dette skjer da ikke automatisk i dagens windows. Ideellt sett hadde vært om windowsen hadde fordelt prosessene, komme det i Vista?

[invariant]

Må bare si meg enig i sitatene til el-asso, det er no herk å programmere multithreaded, det har jeg gjort en del på serversoftware, og der er det relativt "trivielt"..

Jeg kan tenkte meg hvor morsomt det er på en client som krever fullstendig synkronisering mellom threadene som i et dataspill, det blir vel årets spagettiopplevelse med dagens api'er.

5284927[/snapback]

 

Slutter meg til el-asso og balleklorin. Vi står overfor et lite paradigmeskifte i programmeringen - som ikke på noen måte vil gjøre det lettere for utviklerne. Når man skal begynne å kjøre samme program på 100 kjerner (i år 2015 ifølge Intel), så vil begrepet "årets spagettiopplevelse" være meget treffende. Vi får håpe det blir utdannet en ny generasjon utviklere som har "concurrency" og "parallelism" i blodet lenge før den tid.

 

Invariant.

Endret 12. desember 2005 av invariant

[gp500]

Det var sutring fra utviklerne når 3d-kortene kom også. Alt ville bli så mye dyrere og ta lengre tid. Men nå er det en selvfølge å programmere enten i OpenGL eller DirectX. Hvis jeg ikke husker helt feil så var Carmack en av de som startet showet med en OpenGL patch til Quake. Så vi kan jo håpe på at det er et lite studio som kommer med en 3D motor som utnytter 2 eller flere tråder maksimalt, slik at det blir et trykk for å utnytte dette best mulig.

[Toddy]

Som sagt må man ha en haug med låser, synkroniserte funksjoner(bare en tråd om gangen), barrier wait, semaphorer, spinnlocks, og busy wait for å kunne lage flertrådsapplikasjoner i c og c++. Å da få utnyttet flere prosessorer 100% samtidig er ekstremt vanskelig. Samt at ved flere tråder er debugging av kode mye vanskeligere.

[Olaaaaa]

Vi får håpe det blir utdannet en ny generasjon utviklere som har "concurrency" og "parallelism" i blodet lenge før den tid. 

Invariant.

5285317[/snapback]

Joda, de jobber med saken med å innprente det. Problemet er at abstraksjonsnivået er såvidt høyt, selv om teorier og algoritmer både fra SMP-systemer og distribuerte systemer finnes er det tungt å forstå. Tror det er lenge før man klarer å utnytte potensialet i multikjerneprosessorer.

[Brusfantomet]

Mener og huske at Doom 3 motoren fordler lasten over to prosessorer.

[Anders Jensen]

Parallellisering er noe herk og det er ikke noe nytt. Det har vært gjort på alle nesten områder som har noe å tjene på det med unntak av spill hvor hardware ikke har vært billig nok ennå til at det har vært noe marked for flertrådede løsninger. Det er ikke noe vill gjetting bak påstandene om at dette blir vanskelig. Vi VET at det ER vanskelig. Et spesielt problem for spill er at de fleste av disse er sanntidsapplikasjoner og det gjør synkroniseringen mye værre en om en bare har en HPC/workstation applikasjon som skal knuse noen tall med det mål å bli ferdig fortest mulig. Med sanntidsapplikasjoner er det ikke lengre viktigst å bli fortest mulig ferdig men å ha alle de riktige resultatene klar i til riktig tid. Om 1 av 100 tråder ligger litt etter, kanskje fordi den ble utsultet eller utkonkurrert på en ressurs så hjelper det lite at en har 99 tråder som er i rute. Du får hakking i det spillet uansett og det behøver ikke nødvendigvis å være et problem som kommer til syne på utviklerne sine systemer.

Endret 12. desember 2005 av Anders Jensen

[invariant]

Vi får håpe det blir utdannet en ny generasjon utviklere som har "concurrency" og "parallelism" i blodet lenge før den tid.  

Invariant.

5285317[/snapback]

Joda, de jobber med saken med å innprente det. Problemet er at abstraksjonsnivået er såvidt høyt, selv om teorier og algoritmer både fra SMP-systemer og distribuerte systemer finnes er det tungt å forstå. Tror det er lenge før man klarer å utnytte potensialet i multikjerneprosessorer.

5286362[/snapback]

 

Selv er jeg vel bare ekspert i Fortran 77 (hvem er ikke det? :!: ), så derfor følgende spørsmål:

 

Stemmer det at Java har begrepene "concurrency" og "parallelism" som en del av språket? Vil det da være enklere å bruke Java enn C/C++ til slike ting? Eller skal vi lage en ny versjon av Fortran 77 som egner seg godt for "concurrency" og "parallelism"?

 

Invariant.

[invariant]

Fant dette på nettet et sted. Er det sant?

(en annen mulighet er jo å bruke openmp i Intel Fortran).

 

Invariant.

 

Improvements : Java vs C++

“Java is better than C++, more because of

what it does not have, than for what it has.”

– No global vars.

– Typos detected, not misinterpreted.

– No gotos.

– Disciplined uses abstracted (exceptions, labeled breaks).

– No pointers.

– Array-index out-of-bounds detected.

– In Java, pointers cannot be manipulated explicitly.

However, they serve as object handles.

– No explicit memory management.

– No memory leaks and no illegal access of freed storage.

– Improves readability.

Concurrent Programming

Threads can share address space. In Java,

threads are modeled after Hoare’s monitors.

• Java is a multi-threaded system, which is

very convenient for coding interactive,

multi-media applications.

– Doing I/O concurrently with reading a

document. (downloading via browser)

– Periodic updating of the screen with data

acquired in real-time. (sports/stocks ticker)

[Olaaaaa]

Vi får håpe det blir utdannet en ny generasjon utviklere som har "concurrency" og "parallelism" i blodet lenge før den tid.  

Invariant.

5285317[/snapback]

Joda, de jobber med saken med å innprente det. Problemet er at abstraksjonsnivået er såvidt høyt, selv om teorier og algoritmer både fra SMP-systemer og distribuerte systemer finnes er det tungt å forstå. Tror det er lenge før man klarer å utnytte potensialet i multikjerneprosessorer.

5286362[/snapback]

 

Selv er jeg vel bare ekspert i Fortran 77 (hvem er ikke det? :!: ), så derfor følgende spørsmål:

 

Stemmer det at Java har begrepene "concurrency" og "parallelism" som en del av språket? Vil det da være enklere å bruke Java enn C/C++ til slike ting? Eller skal vi lage en ny versjon av Fortran 77 som egner seg godt for "concurrency" og "parallelism"?

 

Invariant.

5286981[/snapback]

Nå er det jo i utgangspunktet slik at det ikke er spesielt effektivt å bruke java til spill eller andre prosesser med høye krav til responstid, IO osv pga. at det rett og slett er for tregt. Men, for å svare på spørsmålet ditt, det finnes allerede metoder i java som er behjelpelige med samtidige operasjoner. Har ingen erfaring med disse, men tviler på at de kan være nyttige for multikjerneprosessorer. Skulle tro at de hadde mer for seg inenfor enkle distribuerte systemer.

 

Edit: Java har selvfølgelig godt implementert metoder for samtidighet mtp multithreadede prosesser mot én enkelt kjerne. Kan ikke si at jeg kjenner godt til Fortran, men skulle tro at de fleste moderne språk har dette godt innarbeidet.

Endret 12. desember 2005 av Olaaaaa