mboost-dp1
unknown
netop her er Mac's største svaghed.. spillene er ikke udviklet til at udnytte processorene ordentligt... og understøttelsen for dual processor er ikke eksisterende..
(Mac bruger.. kunne ikke finde på at hoppe til x86 bare for at kunne spille)
(Mac bruger.. kunne ikke finde på at hoppe til x86 bare for at kunne spille)
Dét som Tim Sweeny beskriver er noget de fleste programmører kan skrive under på, multitrådet programmering er noget af det mest hårrejsende at skrive og debugge.
Derfor er det interesant at AMD's FX serie (deres hardcore gamer serie) ikke får multi-kerne, AMD regner med andre ord ikke med at effektiv skalérbar multitrådet spilkode vil se dagens lys lige med det samme.
Derfor er det interesant at AMD's FX serie (deres hardcore gamer serie) ikke får multi-kerne, AMD regner med andre ord ikke med at effektiv skalérbar multitrådet spilkode vil se dagens lys lige med det samme.
#4 På ét eller andet tidspunkt udgår alle CPU serier, men FX serien udgår bestemt ikke lige med det samme:
http://www.pcper.com/article.php?aid=122
Single 64bit Athlon FX skal kæmpe imod P4EE Dual segmentet.
http://www.pcper.com/article.php?aid=122
Single 64bit Athlon FX skal kæmpe imod P4EE Dual segmentet.
http://www.amd.com/us-en/Processors/ProductInforma...
^^ deres roadmap ser bare ud som om at FX og 64 bliver slået sammen til "san diego" og kører videre i "toledo" som dual core!
^^ deres roadmap ser bare ud som om at FX og 64 bliver slået sammen til "san diego" og kører videre i "toledo" som dual core!
Kan godt se der er en modstid, om ikke andet så i alt fald mht. timing.
Men skal jeg vælge imellem en "What's to come" præsentation ment som svar på tiltale til Intel's IDF konference, og så et statisk roadmap, er jeg nok tilbøjlig til at stole mere på den første (Begge er jo fra først i marts).
Så mon ikke producenter får Toledo samples ifølge deres roadmap men når først ud til forbrugerne en gang i 2006?!
Men skal jeg vælge imellem en "What's to come" præsentation ment som svar på tiltale til Intel's IDF konference, og så et statisk roadmap, er jeg nok tilbøjlig til at stole mere på den første (Begge er jo fra først i marts).
Så mon ikke producenter får Toledo samples ifølge deres roadmap men når først ud til forbrugerne en gang i 2006?!
#1
Ikke kun det, men største delen af alle Mac's er udstyret med enten et ATI Radeon 9200, ATI Radeon 9600 XT eller et NVIDIA GeForce FX 5200 Ultra. Disse kort er jo ikke lige frem stof til Hall of Fame over de bedste gaming grafikkort.
Og det er kun et fåtal som har et ATI Radeon 9800 Pro, ATI Radeon 9800 XT, NVIDIA GeForce 6800 GT DDL eller et NVIDIA GeForce 6800 Ultra DDL installeret. Og jeg er heller ikke engang sikker på at disse er specielt gode til spil hellere.
Ikke kun det, men største delen af alle Mac's er udstyret med enten et ATI Radeon 9200, ATI Radeon 9600 XT eller et NVIDIA GeForce FX 5200 Ultra. Disse kort er jo ikke lige frem stof til Hall of Fame over de bedste gaming grafikkort.
Og det er kun et fåtal som har et ATI Radeon 9800 Pro, ATI Radeon 9800 XT, NVIDIA GeForce 6800 GT DDL eller et NVIDIA GeForce 6800 Ultra DDL installeret. Og jeg er heller ikke engang sikker på at disse er specielt gode til spil hellere.
#8. Hvad er din pointe? 90% af alle PC'ere er også kun udstyret med enten et ATI Radeon 9200, ATI Radeon 9600 XT eller et NVIDIA GeForce FX 5200 Ultra. Nogle endda med onboard-intel graphics, som er endnu værre end Apples lowend, da OS X har nogle mindstekrav til grafikkortet for overhovedet at køre. Man får det grafikkort man man vælger, uanset om man køber Mac eller x86.
Den rigtige konklusion er at meget få, herunder både Mac og PC ejere, har over midrange. Og udover det har jeg ingen idé om hvordan du kan komme med den påstand at et mac nv6800u skulle være dårligere end et tilsvarende kort til x86. Der er nærmest ingen forskel hardwaremæssigt på de kort der sælges til hver arkitektur.
Den rigtige konklusion er at meget få, herunder både Mac og PC ejere, har over midrange. Og udover det har jeg ingen idé om hvordan du kan komme med den påstand at et mac nv6800u skulle være dårligere end et tilsvarende kort til x86. Der er nærmest ingen forskel hardwaremæssigt på de kort der sælges til hver arkitektur.
Ja, at skrive multithreaded kode i C++ er sværere end at skrive singlethreaded kode, men jeg har lidt svært ved at se hvorfor lige netop et spil skulle være så meget mere kompleks end andre programmer.
At påstå at koden bliver 2 til 3 gange så kompleks synes jeg er en overdrivelse. Det kan være det grunder i at han som spiludvikler ikke har erfaring med at arbejde med mere end en tråd ad gangen, men når først man har lært at kontrollere sine tråde så er det en ganske overkommelig opgave.
At påstå at koden bliver 2 til 3 gange så kompleks synes jeg er en overdrivelse. Det kan være det grunder i at han som spiludvikler ikke har erfaring med at arbejde med mere end en tråd ad gangen, men når først man har lært at kontrollere sine tråde så er det en ganske overkommelig opgave.
#2 "Mac er et niche produkt."
Ahahahahahahahahahaaaa...!!
Nej.
Ikke så udbredt som definitionen "PC", som vi kender den i dag, men absolut ikke et niche produkt. Du kan evt. checke forskellige arbejdspladser, så som Berlingske Tidende.
De bruger hovedsageligt macs, og giver kun nogle lov til at bruge andet, fordi det er ok besværligt at få de to typer til at samarbejde ved fil-udveksling...
Ahahahahahahahahahaaaa...!!
Nej.
Ikke så udbredt som definitionen "PC", som vi kender den i dag, men absolut ikke et niche produkt. Du kan evt. checke forskellige arbejdspladser, så som Berlingske Tidende.
De bruger hovedsageligt macs, og giver kun nogle lov til at bruge andet, fordi det er ok besværligt at få de to typer til at samarbejde ved fil-udveksling...
Nu betyder PC jo Personlig Computer, hvilket MAC også er. Ligesom en Commodore 64 var det i sin tid... Når folk siger PC mener de IBM PC som er en standard lavet for længe siden som der den dag i dag stadig bruges. Intel arbejder dog på en ny standard for "PC'er" som man kan finde masser af info om på nettet
#10 Det største problem er somregel ikke at forstå og debugge multithreaded kode men at parallelisere opgaverne.
Det kræver ret meget tænke arbejde at skabe et godt design som kan skaleres til flere tråde og dvs. flere cpu'er. Er de fleste spil i dag ikke kun til enkelt cpu systemer? Der er jo intet nyt i multikerne cpuer. Istedet for to cpu-enheder er de jo bare slået sammen til én. Fra en programmørs synspunkt er der ikke noget der har ændret sig siden dual-cpu er kommet frem. Den eneste forskel nu er at der er kommet mere pres på at der skal ske noget på den front.
Koden bliver mere kompleks fordi der skal ske mange flere ting parallelt som skal synkroniseres og koordineres. Den slags handler i bund og grund kun om penge til udvikling og et muligt afkast i sidste ende når brugere køber spillene.
Det kræver ret meget tænke arbejde at skabe et godt design som kan skaleres til flere tråde og dvs. flere cpu'er. Er de fleste spil i dag ikke kun til enkelt cpu systemer? Der er jo intet nyt i multikerne cpuer. Istedet for to cpu-enheder er de jo bare slået sammen til én. Fra en programmørs synspunkt er der ikke noget der har ændret sig siden dual-cpu er kommet frem. Den eneste forskel nu er at der er kommet mere pres på at der skal ske noget på den front.
Koden bliver mere kompleks fordi der skal ske mange flere ting parallelt som skal synkroniseres og koordineres. Den slags handler i bund og grund kun om penge til udvikling og et muligt afkast i sidste ende når brugere køber spillene.
#10 Jeg tror ikke du har ret i at spil programmører ikke har erfaring med mere end en tråd af gangen, men med AI, grafik, lyd, kommunikation osv. der alt sammen skal passe sammen bliver det jo et spørgsmål om at dispatche opgaver som er minimalt afhængig af hinanden... og dét er altså dyere imellem processer på flere kerner end imellem tråde der har hver deres timeslice på én kerne.
#13 Helt enig, det er en fejl at tro at kompilere og OS'er på nuværende tidspunkt er i stand til at fordele arbejde over flere kerner når det drejer sig om noget så komplekst som spil, der er dén type software pt. der presser PC'ens ressourcer mest.
Standard compiler tricks (loop-unrolling, minimering af page-faults, lazy evaluation, constant folding, branch prediction) vil stadig være pr. core. Selv om alle disse tricks kan optimere en proces en hel del når alle skal deles om én kerne, bliver det pludselig et problem hvis den ene kerne alligevel bare skal vente lidt på den anden hvorfor optimeringen lige pludselig ingen effekt har.
Derfor ser jeg også AMD's kortere pipeline som en klar fordel over Intel's, hvorfor jeg også tror Intel's dual-core pipeline og branch prediction måske vil ligne Centino'en mere end P4'eren.
#13 Helt enig, det er en fejl at tro at kompilere og OS'er på nuværende tidspunkt er i stand til at fordele arbejde over flere kerner når det drejer sig om noget så komplekst som spil, der er dén type software pt. der presser PC'ens ressourcer mest.
Standard compiler tricks (loop-unrolling, minimering af page-faults, lazy evaluation, constant folding, branch prediction) vil stadig være pr. core. Selv om alle disse tricks kan optimere en proces en hel del når alle skal deles om én kerne, bliver det pludselig et problem hvis den ene kerne alligevel bare skal vente lidt på den anden hvorfor optimeringen lige pludselig ingen effekt har.
Derfor ser jeg også AMD's kortere pipeline som en klar fordel over Intel's, hvorfor jeg også tror Intel's dual-core pipeline og branch prediction måske vil ligne Centino'en mere end P4'eren.
Det er vel åbentlyst at ikke alle opgaver egner sig bedre til dual-core setup's.
Men spil kan i den grad få fornøjelse af det. F.eks. en 1914-1918 dogfight simulator - den ene core får lov at køre AI'en og evt. lyd mens den anden får lov at køre resten.
Vil ihvertfald give et potentielt boost til intelligensen af modstandere i spil at få lov at bruge næsten en hel cpu på at finde ud af hvad den skal.
OS'er vil også kunne udnytte det på smarte måder - eks. kan linux smide alle processer under root over på cpu2 mens kernel og userspace kører på cpu1. Med dual-display kan man 'dedikere' en cpu til hvert display osv.
Servermæssigt giver det også mening at dedikere en eller flere cores til bestemte services og lade en core om resten, en Oracle DB server for danske bank ville sikkert glæde sig over det hvis man på OS niveau kunne definere sådant (ved jeg faktisk ikke om AIX ikke allerede kan.).
Nå må hellere stoppe med at rante inden jeg får sagt noget jeg ikke burde have :P
Men spil kan i den grad få fornøjelse af det. F.eks. en 1914-1918 dogfight simulator - den ene core får lov at køre AI'en og evt. lyd mens den anden får lov at køre resten.
Vil ihvertfald give et potentielt boost til intelligensen af modstandere i spil at få lov at bruge næsten en hel cpu på at finde ud af hvad den skal.
OS'er vil også kunne udnytte det på smarte måder - eks. kan linux smide alle processer under root over på cpu2 mens kernel og userspace kører på cpu1. Med dual-display kan man 'dedikere' en cpu til hvert display osv.
Servermæssigt giver det også mening at dedikere en eller flere cores til bestemte services og lade en core om resten, en Oracle DB server for danske bank ville sikkert glæde sig over det hvis man på OS niveau kunne definere sådant (ved jeg faktisk ikke om AIX ikke allerede kan.).
Nå må hellere stoppe med at rante inden jeg får sagt noget jeg ikke burde have :P
#17
Meget flot! ... men det er altså stadig ikke noget nyt fænomen.
Engang i 1995 mødte jeg en som pralede med at han havde en dual-cpu Pentium 100 MHz og han kørte Windows 95. Det han bare ikke vidste var at Win95 var så ekstrem ringe til det med multi cpu (hvis det overhovedet var i brug). Ikke destomindre har tiden ikke ændret sig særlig meget.
Alle de ting du har fortalt kunne man allerede gøre for 10 år siden HVIS man programmerede sig til det. Dual kerne ændre kun det fysiske design, ikke hvordan dine programmer virker.
Desuden er jeg ret sikker på at både Windows og Linux fungerer ens mht. til kernen. Alt i kernel bliver kørt på første cpu og kun nye tråde -kan- blive sendt hen på cpu#2. I praksis betyder det at du aldrig vil få samme udnyttelse af cpu#2 som den første. 2 kerner eller 2 cpuer betyder ikke 2 selvstændige computere.
Et af de systemer jeg har programmeret laver ca. 7 ting parallelt og hvis man kører koden på en multicpu... ja guess what... så bliver performance bedre. Men faktum var at systemet var nød til at være parallelt for at gøre det muligt at få det til at virke. Ikke med dual-cpu i tankerne. Sådan er der mange systemer som er i dag.
Meget flot! ... men det er altså stadig ikke noget nyt fænomen.
Engang i 1995 mødte jeg en som pralede med at han havde en dual-cpu Pentium 100 MHz og han kørte Windows 95. Det han bare ikke vidste var at Win95 var så ekstrem ringe til det med multi cpu (hvis det overhovedet var i brug). Ikke destomindre har tiden ikke ændret sig særlig meget.
Alle de ting du har fortalt kunne man allerede gøre for 10 år siden HVIS man programmerede sig til det. Dual kerne ændre kun det fysiske design, ikke hvordan dine programmer virker.
Desuden er jeg ret sikker på at både Windows og Linux fungerer ens mht. til kernen. Alt i kernel bliver kørt på første cpu og kun nye tråde -kan- blive sendt hen på cpu#2. I praksis betyder det at du aldrig vil få samme udnyttelse af cpu#2 som den første. 2 kerner eller 2 cpuer betyder ikke 2 selvstændige computere.
Et af de systemer jeg har programmeret laver ca. 7 ting parallelt og hvis man kører koden på en multicpu... ja guess what... så bliver performance bedre. Men faktum var at systemet var nød til at være parallelt for at gøre det muligt at få det til at virke. Ikke med dual-cpu i tankerne. Sådan er der mange systemer som er i dag.
Regner med du ikke prøver at provokere - er udemærket klar over at der i programmeringsmæssig forstand ingen forskel er på om der er 2 cores i 1 kerne eller i 2 kerner.
Win95 understøtter iøvrigt ikke flere cpu'er.
En kerne vil iøvrigt godt kunne off-loade nogle ting til en anden cpu hvis den er lavet til det - tvivler dog lidt på at linux kernen er lavet til det, da den i sin natur er monolithic.
Win95 understøtter iøvrigt ikke flere cpu'er.
En kerne vil iøvrigt godt kunne off-loade nogle ting til en anden cpu hvis den er lavet til det - tvivler dog lidt på at linux kernen er lavet til det, da den i sin natur er monolithic.
Ja ingen provokation fra min side :) Men tanken om at programmer skulle blive markant bedre til multitasking er slet ikke så dårlig. Jeg tror bare det kræver en del mere arbejde det der er gjort på området indtil nu. :)
#14:
Fordi Tim Sweeny udtaler at koden bliver 2 til 3 gange så kompleks hvis den skal køre i flere tråde. Den slags udtalelser ville jeg ikke forvente fra nogen som er vant til at arbejde med flere tråde.
Jeg tror det er 10-12 år siden jeg skrev mit første multiplayer spil, som ikke brugte flere tråde. Alle spil skrevet til DOS er skrevet til at køre i samme tråd. Det er absolut ikke nødvendigt at bruge mere end en enkelt tråd til af afvikle et spil.
Kigger du i nogen af de source koder som er blevet frigivet til nogen af de ældre spil (Doom, Quake, Descent, Wolfenstein, etc), tror jeg heller ikke du finder kode som bruger mere end en tråd.
Hmm... hvorfor tror du at spiludviklere ikke har erfarring med tråde?
Fordi Tim Sweeny udtaler at koden bliver 2 til 3 gange så kompleks hvis den skal køre i flere tråde. Den slags udtalelser ville jeg ikke forvente fra nogen som er vant til at arbejde med flere tråde.
Hvordan vil du kode et multiplayer spil uden brug af tråde. Det vil jeg gerne se.
Jeg tror det er 10-12 år siden jeg skrev mit første multiplayer spil, som ikke brugte flere tråde. Alle spil skrevet til DOS er skrevet til at køre i samme tråd. Det er absolut ikke nødvendigt at bruge mere end en enkelt tråd til af afvikle et spil.
Kigger du i nogen af de source koder som er blevet frigivet til nogen af de ældre spil (Doom, Quake, Descent, Wolfenstein, etc), tror jeg heller ikke du finder kode som bruger mere end en tråd.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund