Intel fremviser Polaris
Diverse d. 21. juni. 2007, skrevet af Emillos 32 Kommentarer. Vist: 522 gange.
#1
hmmm
mig ha ? :)
Jaja Intel har styr på lortet... hvor i mod AMD har lort på styret
mig ha ? :)
Jaja Intel har styr på lortet... hvor i mod AMD har lort på styret
#2
#1
That must i nok say... thats a good wending Hansi! :yes:
That must i nok say... thats a good wending Hansi! :yes:
#3
# 1 Har altid haft en godt øje til AMD, men det virker sgu som om de bevidst har lagt i baghjulet af Intel...og har tænkt sig at blive dér.
2 Tflops....det kun da være sjovt at lege med. Så kan det nok være at man får sendt den email ud af døren i en ruf.
2 Tflops....det kun da være sjovt at lege med. Så kan det nok være at man får sendt den email ud af døren i en ruf.
#4
intel laver cpuer til folket - for folket..
amd laver cpuer for at tjene penge til at overleve - ren forretning - som fck - men de er sikkert også gode til det ... jeg ku ikk være mere ligeglad over at de vinder ind på OEM-markedet... det kommer da ikke os ved???
/shoot 😲
amd laver cpuer for at tjene penge til at overleve - ren forretning - som fck - men de er sikkert også gode til det ... jeg ku ikk være mere ligeglad over at de vinder ind på OEM-markedet... det kommer da ikke os ved???
/shoot 😲
#6
ja det er os der får det hele sat i flammer med glød og god stil
ta mit indlæg med et gran salt 🤡 jeg har i de 13 år jeg har haft PC kørt med AMD i 10 af årene... og været glad
AMD måtte da gerne lave noget for os --- altså det der OEM-halløj det er da noget fis bare for at tjene penge...men det er de jo også nød til... at man siger de har vundet ind på intel - jojo - men i alt den tid har intel samtidig tjent laaangt flere penge og kan dermed også være dem, som laver de bedste ting...
ta mit indlæg med et gran salt 🤡 jeg har i de 13 år jeg har haft PC kørt med AMD i 10 af årene... og været glad
AMD måtte da gerne lave noget for os --- altså det der OEM-halløj det er da noget fis bare for at tjene penge...men det er de jo også nød til... at man siger de har vundet ind på intel - jojo - men i alt den tid har intel samtidig tjent laaangt flere penge og kan dermed også være dem, som laver de bedste ting...
#7
ændre ikke at amd får beat down pt
#8
->#6
Og du tror simpelthen, at INTEL laver produkter for kundernes bedste, og ikke deres eget ?
Selvfølgelig tænker både INTEL og AMD i cool cash
Og du tror simpelthen, at INTEL laver produkter for kundernes bedste, og ikke deres eget ?
Selvfølgelig tænker både INTEL og AMD i cool cash
#9
#8 Tror han mener at Intel OGSÅ laver produkter til os, overclockere osv, og ikke KUN til OEM markedet.. Man tjener nok mest på OEM markedet, og mindre på os.. Og derfor er AMD en ¤U%((&)%&), når de slet ikke gider at lege med sammen med Intel, for vores skyld :yes:
Shake
Shake
#11
10 kommentarer og KUN 1 som har lidt med nyheden at gøre.... glæd jer nu bare over Intel er foran og lad vær med at flame AMD i hver eneste Intel nyhed der kommer på sitet.
#12
Rolig nu!.... Som jeg kan læse der, så er de ikke engang X86 cores, så de er nok relativ dumme og uden specielt mange instruktioner (endnu) Lidt ala. Cell, som med flere små hurtige cores, som ikke er specielt avancerede.
Jeg tror faktisk denne cpu er resultatet af det snak der var omkring Intel - Transmeta samarbejdet der var for nogle år siden, netop omkring mange cored cpu'er og instruktions emuleringer...
http://www.burn-it.dk/index.ph...
Jeg tror faktisk denne cpu er resultatet af det snak der var omkring Intel - Transmeta samarbejdet der var for nogle år siden, netop omkring mange cored cpu'er og instruktions emuleringer...
http://www.burn-it.dk/index.ph...
#13
okey.. og jeg er så den eneste som har læst, at Barcelona skulle OC ret najs? 😉
http://www.fudzilla.com/index....
http://www.fudzilla.com/index....
#14
#12
Øhh x86 er blot et over 20 år gammelt instruktionssæt som er blevet en standard. Bare fordi det oprindeligt var en CISC (Complex Instruction Set Computer) (nu en blanding af RISC OG CISC) arkitektur er den ikke stærkere end en RISC (Reduced ...) processor.
Og selvom den ikke understøtter x86 instruktionssættet tror jeg ikke ligefrem den er dummere end x86. Er alle computere ikke dumme når det kommer til stykket? 😛
Siden X86 er et af de eneste CISC instruktionssæt tilbage, så mener du heller ikke PowerPC eller SPARC processorer kan tages seriøst, da de også har et begrænset instruktionssæt? 😉
Når det kommer til stykket er RISC faktisk CISC overlegent, da RISC består af et begrænset antal små instruktioner, som kan udføres i en enkelt CPU cycle. Dette stiller større krav til compilere, da flere instruktioner skal kaldes for at udføre en handling. RISC kræver også lidt mere hukommelse, da der skal loades fra hukommelsen for hver instruktion, hvis det er nyt data der skal bearbejdes. Bl.a. derfor slog det aldrig igennem "dengang", da ram kostede mange tusinde kroner for bare 1 MiB.
CISC derimod består af en del flere komplekse instruktioner, som kræver flere CPU cycles. Fordelen med dette er, at compilere ikke skal lave ret meget arbejde for at oversætte sproget til instruktioner. Da længden af koden derfor bliver en del kortere skal der ikke bruges så meget hukommelse på at gemme instruktioner.
Men siden ram er blevet ekstremt billige nu om dage og compilere er blevet noget mere avancerede er RISC faktisk mindst lige så gode og brugbare som CISC nu om stunder.
Det blev pludselig noget af en smørre 😀 Der tages højde for fejl osv. osv. Det er bare lige som jeg husker det :)
Øhh x86 er blot et over 20 år gammelt instruktionssæt som er blevet en standard. Bare fordi det oprindeligt var en CISC (Complex Instruction Set Computer) (nu en blanding af RISC OG CISC) arkitektur er den ikke stærkere end en RISC (Reduced ...) processor.
Og selvom den ikke understøtter x86 instruktionssættet tror jeg ikke ligefrem den er dummere end x86. Er alle computere ikke dumme når det kommer til stykket? 😛
Siden X86 er et af de eneste CISC instruktionssæt tilbage, så mener du heller ikke PowerPC eller SPARC processorer kan tages seriøst, da de også har et begrænset instruktionssæt? 😉
Når det kommer til stykket er RISC faktisk CISC overlegent, da RISC består af et begrænset antal små instruktioner, som kan udføres i en enkelt CPU cycle. Dette stiller større krav til compilere, da flere instruktioner skal kaldes for at udføre en handling. RISC kræver også lidt mere hukommelse, da der skal loades fra hukommelsen for hver instruktion, hvis det er nyt data der skal bearbejdes. Bl.a. derfor slog det aldrig igennem "dengang", da ram kostede mange tusinde kroner for bare 1 MiB.
CISC derimod består af en del flere komplekse instruktioner, som kræver flere CPU cycles. Fordelen med dette er, at compilere ikke skal lave ret meget arbejde for at oversætte sproget til instruktioner. Da længden af koden derfor bliver en del kortere skal der ikke bruges så meget hukommelse på at gemme instruktioner.
Men siden ram er blevet ekstremt billige nu om dage og compilere er blevet noget mere avancerede er RISC faktisk mindst lige så gode og brugbare som CISC nu om stunder.
Det blev pludselig noget af en smørre 😀 Der tages højde for fejl osv. osv. Det er bare lige som jeg husker det :)
#15
#14 tjaa... nu er det jo sådan, at fx ARM har fået CISC lignede instruktioner, så alt i alt, er en kombineret løsning nok den bedste :) Bl.a. SWP instruktionen som afløser min. 20 instruktioner.. Men er enig med dig, at der er flere RISC arkitekturer som er ligeså gode som x86 CISC eller måske bedre ;)
#16
"RISC kræver også lidt mere hukommelse, da der skal loades fra hukommelsen for hver instruktion, hvis det er nyt data der skal bearbejdes." <- hhm hvad mener du bestemt? Ja, RISC bruger en anelse mere ram, da der skal bruges flere instruktioner som jo er gemt i ram. Men "hvis det er nyt data der skal bearbejdes." <- skal CISC også...
#17
#14 du er helt forkert på den mht RISC og CISC. RISC betyder at backend'en kun "forstår" få simple instruktioner, og man skal så benytte flere af dem for at gøre diverse ting (okay, det havde du skrevet korrekt). CISC derimod har langt flere instruktioner, og hvad der måske kræver 5-8 MicroOPs med en RISC, kan gøres med en i en CISC.
Nedturen ved CISC er at backend'en (altså selve det der "regner") er væsentlig mere kompleks og svær at få op i hastighed, hvor den meget simplere RISC backend bare kan skrues i vejet og dermed kompensere for at der skal bruges flere clock cykler.
Den historiske grund til CISC var at man i tidernes morgen i jagten på performance forsøgte sig med at "presse" de mest brugte instruktioner ned i "kombinationer" så man sparede clock cykler. CISC var mest dominerende i starten, nok mest fordi der ikke rigtig var nogen der havde forsøgt sig med RISC.
CISC's totale domination senere hen handlede udelukkende om at Intel tillod alle at kopiere deres første produkter (286-486 (der var bagudkombatible med deres 8080 CISC)) i kampen mod Apple. Og det lykkedes som vi alle ved jo ret godt :) og det til trods for at Apple havde langt det bedste produkt.
CPU'er i dag er alle RISC, men de emulerer bare de gamle CISC instruktioner :)
#16 den ene bruger ikke mere ram end den anden - hvis der absolut skal være en forskel, så må det være hvor mange registre man benytter - men det er nu min påstand at de bruger lige meget! Det fede ved RISC (set fra compiler-programmøren's synspunkt) er at det er langt nemmere at lave effektive programmer til RISC, end CISC. En computer er dum, og lære den hvornår og hvordan den skal udnytte CISC er ret så udmattende.
Nedturen ved CISC er at backend'en (altså selve det der "regner") er væsentlig mere kompleks og svær at få op i hastighed, hvor den meget simplere RISC backend bare kan skrues i vejet og dermed kompensere for at der skal bruges flere clock cykler.
Den historiske grund til CISC var at man i tidernes morgen i jagten på performance forsøgte sig med at "presse" de mest brugte instruktioner ned i "kombinationer" så man sparede clock cykler. CISC var mest dominerende i starten, nok mest fordi der ikke rigtig var nogen der havde forsøgt sig med RISC.
CISC's totale domination senere hen handlede udelukkende om at Intel tillod alle at kopiere deres første produkter (286-486 (der var bagudkombatible med deres 8080 CISC)) i kampen mod Apple. Og det lykkedes som vi alle ved jo ret godt :) og det til trods for at Apple havde langt det bedste produkt.
CPU'er i dag er alle RISC, men de emulerer bare de gamle CISC instruktioner :)
#16 den ene bruger ikke mere ram end den anden - hvis der absolut skal være en forskel, så må det være hvor mange registre man benytter - men det er nu min påstand at de bruger lige meget! Det fede ved RISC (set fra compiler-programmøren's synspunkt) er at det er langt nemmere at lave effektive programmer til RISC, end CISC. En computer er dum, og lære den hvornår og hvordan den skal udnytte CISC er ret så udmattende.
#18
Og når så AMD kommer med en CPU der river Intel, så er Intel noget lort.. Sjovt som folk hurtigt skifter mening.
#19
#18 hehe ja, kan godt huske hvad Intel blev kaldt da A64 kom frem :P
#ontopic
Gad altså godt have sådan er fætter at lege med - se hvad man kan få den til med fx video encoding :D
#ontopic
Gad altså godt have sådan er fætter at lege med - se hvad man kan få den til med fx video encoding :D
#20
jaja... her sidder jeg så med en 40benet PIC der køre med 40Mhz og syntes den er super sej... :P
#21
#18
sådan har det jo altid været. Man kan jo også altid regne med at Fanboys nok skal brokke sig når det ikke lige er deres mærke der er på toppen :)
#alle
Men nu må vi jo se om ikke AMD kan vende på deres tallerken når de får Barcelona ud af døren. Især håber jeg der kommer gang i den hvis de får deres outscoursing til IBM ( var det vist ) til at køre.
/ontopic
Hvis man gav mig en af dem der i hånden tror jeg sq at jeg ville føle mig som en der var blevet efterladt nøgen i en ørken med en tom vandpistol. Bare stå der og tænke "HVA FANDEN SKAL JEG STILLE OP MED DEN?"
sådan har det jo altid været. Man kan jo også altid regne med at Fanboys nok skal brokke sig når det ikke lige er deres mærke der er på toppen :)
#alle
Men nu må vi jo se om ikke AMD kan vende på deres tallerken når de får Barcelona ud af døren. Især håber jeg der kommer gang i den hvis de får deres outscoursing til IBM ( var det vist ) til at køre.
/ontopic
Hvis man gav mig en af dem der i hånden tror jeg sq at jeg ville føle mig som en der var blevet efterladt nøgen i en ørken med en tom vandpistol. Bare stå der og tænke "HVA FANDEN SKAL JEG STILLE OP MED DEN?"
#22
#21 🤣 kunne sgu ikke lade være med at smile, bare det billede man får i hovedet 🤣
Tror også jeg ville ha' det lidt som dig..
hvad fanden skal man stille op med den? 😀
kobbel den til en Gameboy Color, og se hva der sker 😎 🤡
Tror også jeg ville ha' det lidt som dig..
hvad fanden skal man stille op med den? 😀
kobbel den til en Gameboy Color, og se hva der sker 😎 🤡
#23
#17 jo den gør... Instruktioner fylder i hukommelsen, og jo flere instruktioner, jo mere ram bliver der brugt. Også derfor de er kommet op med Thumb instruktionssættet på ARM.
"RISC betyder at backend'en kun "forstår" få simple instruktioner, og man skal så benytte flere af dem for at gøre diverse ting (okay, det havde du skrevet korrekt)." <- Ved ikke præcist hvad du ville kommentere her (ikke på mit indlæg), men RISC design filosofien er at levere simple og samtidlig kraftfulde instruktioner som kan udføres med kun én cycle.
"CPU'er i dag er alle RISC, men de emulerer bare de gamle CISC instruktioner :)" <- Hhm... Intel fx, valgte da RISC var begyndt at komme frem, at gøre de mest brugte instruktioner kortere og dermed hurtigere mens de længere så måtte blive en anelse længere og dermed langsommere.
"Det fede ved RISC (set fra compiler-programmøren's synspunkt) er at det er langt nemmere at lave effektive programmer til RISC, end CISC. En computer er dum, og lære den hvornår og hvordan den skal udnytte CISC er ret så udmattende." <- Ja, altså man kan sige, at hvis du laver én specifik compiler til RISC og én specifik compiler til CISC, så vil RISC tit være bedre designet, da en CISC tit skal tage højde for fx MMX, SSE osv. osv. instruktioner, så en compiler til CISC skal for det meste tage højde for flere ting end RISC.
"RISC betyder at backend'en kun "forstår" få simple instruktioner, og man skal så benytte flere af dem for at gøre diverse ting (okay, det havde du skrevet korrekt)." <- Ved ikke præcist hvad du ville kommentere her (ikke på mit indlæg), men RISC design filosofien er at levere simple og samtidlig kraftfulde instruktioner som kan udføres med kun én cycle.
"CPU'er i dag er alle RISC, men de emulerer bare de gamle CISC instruktioner :)" <- Hhm... Intel fx, valgte da RISC var begyndt at komme frem, at gøre de mest brugte instruktioner kortere og dermed hurtigere mens de længere så måtte blive en anelse længere og dermed langsommere.
"Det fede ved RISC (set fra compiler-programmøren's synspunkt) er at det er langt nemmere at lave effektive programmer til RISC, end CISC. En computer er dum, og lære den hvornår og hvordan den skal udnytte CISC er ret så udmattende." <- Ja, altså man kan sige, at hvis du laver én specifik compiler til RISC og én specifik compiler til CISC, så vil RISC tit være bedre designet, da en CISC tit skal tage højde for fx MMX, SSE osv. osv. instruktioner, så en compiler til CISC skal for det meste tage højde for flere ting end RISC.
#24
Man kan også sige i dag at:
- RISC kun bruger fler-cycle instruktioner hvis de virkelig er vigtigt
- CISC bruger fler-cycle instruktioner mere løst (dvs. alt hvad de synes mangler :D * hint * intel)
- RISC kun bruger fler-cycle instruktioner hvis de virkelig er vigtigt
- CISC bruger fler-cycle instruktioner mere løst (dvs. alt hvad de synes mangler :D * hint * intel)
#25
#23 da CISC's overordnet mål er at man skal skrive så få linier assembler kode som muligt, må jeg vel give mig her. Men de behøver altså ikke bruge forskellig mængde ram, men det er størrelsen af den eksekverbare fil der variere.
x86 har stadig samtlige instruktioner der har eksisteret i deres produkt linie siden 8088'ern. Men internt er alle moderne cpu'er RISC. Når der kommer en CISC instruktion bliver den af cpu'ens decoder mapped ind i en række micro-ops med de tilsvarende RISC instruktioner. Alle x86 SIMD(MMX, SSE osv) kan man ikke kalde RISC. Det er egenlig bare et shortcut til fx at multiplicere 4 talpar i en instruktion. Men det er nu ikke noget kompileren skal tage højde for, da man skal skrive speciel kode for at benytte SIMD instuktionerne.
x86 har stadig samtlige instruktioner der har eksisteret i deres produkt linie siden 8088'ern. Men internt er alle moderne cpu'er RISC. Når der kommer en CISC instruktion bliver den af cpu'ens decoder mapped ind i en række micro-ops med de tilsvarende RISC instruktioner. Alle x86 SIMD(MMX, SSE osv) kan man ikke kalde RISC. Det er egenlig bare et shortcut til fx at multiplicere 4 talpar i en instruktion. Men det er nu ikke noget kompileren skal tage højde for, da man skal skrive speciel kode for at benytte SIMD instuktionerne.
#26
"men det er størrelsen af den eksekverbare fil der variere. " yup, som bliver loadet ind i ram
"Alle x86 SIMD(MMX, SSE osv) kan man ikke kalde RISC." har jeg heller ikke gjort, nok nærmere det modsatte
"Men det er nu ikke noget kompileren skal tage højde for" jo det er det da, den behøver ikke at gøre det, men får at være 100% effektiv, burde den gøre det
"Alle x86 SIMD(MMX, SSE osv) kan man ikke kalde RISC." har jeg heller ikke gjort, nok nærmere det modsatte
"Men det er nu ikke noget kompileren skal tage højde for" jo det er det da, den behøver ikke at gøre det, men får at være 100% effektiv, burde den gøre det
#27
#26 jeg er ikke enig med dig, men taget i betragtning hvor meget vi OT'er, så burde vi fortsætte en i maskine arkitektur tråd 😉
#28
Oooh ja skal nok blive nice når de kan regne 2GIGAFLOPS ved 48 watt :P fejer de lige alle konkurrenter væk!
#29
#19 ja computere blir nok så hurtige at vi som mennesker ikke kan følge med, og dermed ikk får tid til at gå ud og sætte kaffe over på arbejdet og andet sjov, mens den renderer...
#30
faktisk er det ikke imponerende med 2 Tflops ved 6.26 Ghz og 80 kerner, det giver ca 4 Flops pr kerne pr Hz :no: det er der mange andre cpuere der kan klare.
#31
#30 muligvis, men de kan ikke klare det ved samme watt forbrug :/
#32
Tjah uden 2 magtfaktorer på CPU markedet ville vi forbrugere skulle betale meget højere priser. Jeg synes det er værd at bemærke at Intel kun har haft førertrøjen i 1 år, altså siden C2D kom ud, før var det AMD´s Athlon 64 osv der skød frem...
Det er bestemt ikke umuligt at AMD pludselig kommer med et monster i fremtiden, og Intel så er fucket.
Jeg glæder mig bare over konkurrencen, da jeg får billigere varer, samt ikke mindst UDVIKLING... Ville strømforbruget være sat ned med kun 1 kæmper på markedet??? Dog ville jeg gerne have en 3. storproducent ind på markedet...
Det er bestemt ikke umuligt at AMD pludselig kommer med et monster i fremtiden, og Intel så er fucket.
Jeg glæder mig bare over konkurrencen, da jeg får billigere varer, samt ikke mindst UDVIKLING... Ville strømforbruget være sat ned med kun 1 kæmper på markedet??? Dog ville jeg gerne have en 3. storproducent ind på markedet...