pskard Skrevet 8. januar 2004 Del Skrevet 8. januar 2004 5% ytelsesøkning og om den da klokker like bra som p4 så vil det si at en 3,4 prescott klokket til 4,0 vil tilsvare en P4 3,2 på 4,6 4.0 * 1.05 = 4.2 GHz. Om den blir kokket eller ikke ser jeg ikke på. På en 3.2 Prescott så vil (gitt 5%) bety at den yter like bra som en P4 NW på 3.36 GHz. Når det er sagt så er det vanskelig å si noen konkret før vi ser CPU-en. Jeg er 99.9% sikker på at forskjellen kommer til å være fra dårligere ytelse i noen oppgaver til 20% bedre i andre. Jevnt over vil jeg si 5%, men det kommer veldig an på hvilke oppgaver en bruker. Lenke til kommentar
pskard Skrevet 8. januar 2004 Del Skrevet 8. januar 2004 pgressum: Ikke sett deg helt på bakbena nå. Det er en million ting å optimalisere på i en prosessor. En syklus her og en der, litt tuning av logikken osv kan fort få store utslag. Intel har helt sikkert gjort mange forbedinger og et par 3 av de mest interessante for pressen er blitt kjent. Jeg synes det er vanskelig å spekulere i ting som ikke er kjent. Personlig føler jeg det blir veldig feil å anta at Intel eller AMD har lagt inn masse ekstra stuff i CPUene, men vi ikke vet om så nære lansering. Det er tross alt svært mange som vet nøyaktig hva som ligger i CPU-ene. At den informasjonen ikke skulle ha lekket ut er rart i så fall. Det eneste jeg er usikker på er om prescott har 64-bit støtte. Jeg tror ikke den har det, men at det kommer i Tejas i Q1 2005 (ja, med AMD64-kompatible instruksjonssett). Blir vel det samme her som når AMD tar i bruk SSE/SSE2: Når det har noe å si bruker de det. Samme gjør nok Intel med AMD64. I dag har det lite å si, men det vil ha stor betydning mot slutten av 2004 og 2005 (ettersom når MS lanserer OS-et..). Vi vet en god del om Prescott, og det bør vi ta utgangspunkt i når vi ser på estimerte tall for ytelse. Det vi vet tilsier at den ikke blir spesielt mye raskere enn NW pr MHz. Det meste av ytelsesøkningen kommer fra mer MHz. Selvsagt har du rett i at Intel har gjort andre forbedringer på Prescott. Bl.a. har de gått bort fra manuell plassering av transistorer og fått det automatisert (AMD har gjort dette i lang tid forøvrig). Det fører til bedre fordeling av varme (og dermed høyere klokkehastigheter). Det er også et par andre justering for å tillate høyere klikkehastigheter. Det har dog ikke noe med ytelsen pr MHz å gjøre. Videre har de lagt inn ekstra WC buffere og endret måten den sender data til AGP-porten på (burst og ikke streaming). Det vil hjelpe litt på FSB-bruk, men ettersom FSB ikke er en flaskehals for P4 har det liten effekt. Prescott har fått en egen integrer enhet, men igjen tror jeg ikke disse endringene vil ha så mye å si. Det viktigste er det jeg nevnte i posten over: Cache, SSE3 og forbedret branch prediction. Så har vi lengre pipelines som jobber mot dette, samt at SSE3 ikke har noen effekt før programmene støtter der (som tar tid). Da gjenstår vi med mer cache pg Branch prediction som det viktigste. I tillegg har Intel sagt at P4 EE vil være raskere pr MHz enn Prescott. Det underbygger videre at det foreløpig ikke er så mye annet som gir mer ytelse enn doblingen av cache (og forbedret branch prediction). Lenke til kommentar
Knick Knack Skrevet 8. januar 2004 Del Skrevet 8. januar 2004 (endret) - Endret 5. januar 2005 av Knick Knack Lenke til kommentar
pskard Skrevet 8. januar 2004 Del Skrevet 8. januar 2004 Selvsagt er det vanskelig å spekulere i ting som ikke er kjent. Alle endringer i Prescott er ikke kjent. Det er ikke engang rimelig å anta alle de viktige forandringene er kjent. En av årsaken er at den gjevne borger ikke har forutsettning for å avgjøre hva som faktisk er viktig. Hvorfor er det ikke rimelig å anta at det meste er kjent? Hvorfor vil du anta at det er mye mer nyheter i Prescott enn det som har blitt sagt så langt? Mulig at det er en rekke små endringer som på plasseringen av transistorer osv, men hvem bryr seg så lenge det ikke har noe med ytelsen å gjøre. Er du klar over hvor mange som sitter med det fulle bildet på hva Prescott inneholder? Mange tusen mennesker (hos Intel og deres partnere) vil jeg tro. Hvor trolig er det at ingen av de hadde lekket "vesentlige" endringer til pressen? Det ville i så fall vært første gangen det har skjedd (som jeg vet om). Hva folk flest bryr seg om er ikke relevant ettersom det faktisk ikke er snakk om folk flest som jobber med dette heller. IT pressen er også svært flinke til å grave opp hva som kommer på markedet før det lanseres (bare se på The Inquirer). Komklusjon: Noe er kjent, Lite er egentlig forstått. Og jeg regner heller ikke med at IPC for Prescott og NW blir særlig forskjellig, men noen overraskelser ligger nok på lur. Du sier også (ikke sitert) at den største forberingen på Prescott vil komme av mer cache og der er vi enige. Videre er vi enige i at IPC på Prescott vil være +- det samme som på NW. I så fall er vi vel da enige om det jeg sa at Prescott ikke kommer til å bli noe spesielt og at den blir mer eller mindre som NW + litt til. Jeg forstår derimot ikke hva du mener med "noen overraskelser ligger nok på lur". Kan du utdype det? Gjerne med noe mer konkret enn at "det kommer sikkert noe mer som ikke er kjent". Det eneste jeg kan tenke meg som kan være i Prescot som ikke er kjent kan være 64-bit støtte, men jeg tviler. BTW: Om du ser på det som _er_ kjent (jmf. ACE's) så er dette meget spesifikke opplysninger som typisk er lekket av noen "inside". Hvorfor skulle de holde tilbake "store" forbedringer? Lenke til kommentar
Knick Knack Skrevet 8. januar 2004 Del Skrevet 8. januar 2004 (endret) - Endret 5. januar 2005 av Knick Knack Lenke til kommentar
Dollar Skrevet 8. januar 2004 Del Skrevet 8. januar 2004 (endret) De 5-10%'ene [edit IKKE] det spennede her, Prescott blir (relativt sett) mer enn rask nok til alle oppgaver du hiver på'n. Det som i praktisk nytte skiller P4/Prescott fra Celly, AXP og A64 er ikke 3dmark eller hvor "mange hundre FPS" den klarer i spill (kunn noen prosent av oss bryr oss) men Hyper-Threading. ALLE som trenger masse kraft trenger det stort sett aller mest når det skal skje flere ting av gangen, i benchmarks sitter du kanskje å ser maskina gjør seg ferdig uten at du bruker den til noe paralellt men i det virkelige liv så er det upraktisk at maskina blir sluggish til alt annet hver gang den må jobbe og akkurat er Prescott overlegen alt annet. Med endel generelle forbedringer og dobbelt så mye cache (hjelper HT mye) som NW. Jeg tror dette blir en veldig behagelig CPU, at den også kommer til å knive om ytelsetronen gjør jo heller ikke noe Endret 8. januar 2004 av Dollar Lenke til kommentar
Simen1 Skrevet 8. januar 2004 Del Skrevet 8. januar 2004 (endret) Det eneste jeg er usikker på er om prescott har 64-bit støtte. Jeg tror ikke den har det, men at det kommer i Tejas i Q1 2005 (ja, med AMD64-kompatible instruksjonssett). Jeg tipper prescott har en eksperimentell x86-64 støtte, men at denne støtten disables i alle brikker som slippes på markedet. Dette gjør de nok for å kunne kjøre egne tester, optimaliseringer og debugging av x86-64 støtten inntil den fungerer så bra at den kan lanseres offisiellt. Denne taktikken er noe Intel har drevet tidliegere, bla da de testet HT (HyperThrading) i Willamette og NW. Etter lang tids testing mente de den var klar for markedet og lanserte den vel i B0-steppingen (?) med Xeon, og senere i C0-steppingen med P4 3,06GHz. Vi vet en god del om Prescott, og det bør vi ta utgangspunkt i når vi ser på estimerte tall for ytelse. Det vi vet tilsier at den ikke blir spesielt mye raskere enn NW pr MHz. Det meste av ytelsesøkningen kommer fra mer MHz. Det er inntrykket mitt også. Men i og med at de har hadd lit problemer med varmeutviklinga så ser jeg ikke bort fra at de ikke klokker særlig fantastisk i starten. (blir vel kanskje noe ala AMD's første 130nm: Tbred-A som bare klokket litt bedre enn palomino på 180nm). Men de kommer nok med bedre steppinger av prescott om en stund (sommeren?) slik at intel hele tiden vil være en god konkurrent til A64. Selvsagt har du rett i at Intel har gjort andre forbedringer på Prescott. Bl.a. har de gått bort fra manuell plassering av transistorer og fått det automatisert (AMD har gjort dette i lang tid forøvrig). Det fører til bedre fordeling av varme (og dermed høyere klokkehastigheter). Har AMD gjort dette lenge? Dette er helt nye info for meg. Fakta? Jeg trodde hovedulempen med dette var at det krever utrolig mye datakraft for å automatisere dette (tenk klynger til titalls millioner dollar). Resulatet er vel først og fremst at kritiske "datapaths" (på norsk =?) optimaliseres for mye bedre klokkesync og mye bedre timinger. Altså at den skal kunne skalere mye bedre med MHz. Varmefordelingen er nok underordnet prioroteten til timinger så det tror jeg ikke forbedres så mye. En av bieffektene av slik automatisk organisering av layouten er også at det ikke lengre blir mulig å identifisere forskjellige områder av kjernen på et "kart" over kjernen. (alt ser ut som "smurt utover"). [Edit] Det er noen bilder her av NW og Prescott men de ser ikke så veldig smurt utover. Endret 8. januar 2004 av Simen1 Lenke til kommentar
pskard Skrevet 8. januar 2004 Del Skrevet 8. januar 2004 Edit: det er alltid konsekvensene som er viktige ikke de faktiske endringene og tallene journalistene liker å gotte seg med. slik som Ah! det er hele 1MB L2 cache dette må jo gi 5% ytelsesøkning... hvor i granskogen kommer slikt fra? Det er håpløst å dømme en endret arkitektur ved å se på hver enkelt engring hver for seg. En må ta helheten i betraktning. Det tviler jeg på at det er mange IT journalister som klarer. Da hadde de heller jobbet med R&D! Nå er vel ikke dette et tall som er tall helt ut av løse luften. Vi har P4EE som med 2 MB L3 cache. En effektiv økning i cache på 1,5 MB (L3) er trolig bedre enn en økning på 0,5 MB på L2 cache. Videre sier Intel at P4EE yter bedre pr MHz. Ettersom P4EE ikke er SÅ mye raskere nn P4C (0-15% raskere jmf ACE's hardware - http://www.aceshardware.com/read.jsp?id=60000267) virker 5% som et forholdsvis logisk tall. Se også http://hardware.no/tester/cpu/p4_3200_ee/p4eevsp4.gif (se bort fra de nederste tallene ettersom det er syntetisk og ikke ytelse). Faktisk ser det ut som om P4EE ikke er så mye som 10% raskere enn P4C engang. Mer som om den er 5-6% raskere jevnt over. I tillegg har Anandtech testet Prescott for en stund siden og det har et par andre nettsteder også. Ingen av de kom frem til store forskjeller i ytelsen. Litt var det, men ikke mye. I noen tilfeller sank ytelsen krafitg, men det er nok BIOS, drivere og ikke Prescott. Du må gjerne legge frem tall/teorier om noe annet, men jeg tror 5% er forholdsvis logisk som en snitt (når en ser på reell ytelse). I noen tilfeller vil Prescott yte DÅRLIGERE enn P4C og i andre oppgaver muligens opp til 20% bedre. Snittet tror jeg ligger på 5%. Lenke til kommentar
Knick Knack Skrevet 8. januar 2004 Del Skrevet 8. januar 2004 (endret) - Endret 5. januar 2005 av Knick Knack Lenke til kommentar
Simen1 Skrevet 8. januar 2004 Del Skrevet 8. januar 2004 "Vi har P4EE som med 2 MB L3 cache. En effektiv økning i cache på 1,5 MB (L3) er trolig bedre enn en økning på 0,5 MB på L2 cache. "-Trolig ikke det nei. Doc? Jeg er litt usikker selv, men vil anta at disse yter ca likeverdig. (mer rask L2 vs. enda mer treg L3) Men det er jo en del flere faktorer som spiller inn på faktisk ytelse å vi får nå vente i spenning litt til før vi vet hva det betyr for ytelsen. "Videre sier Intel at P4EE yter bedre pr MHz." doc? pluss tror du egentlig på dette? Det gjør ikke jeg. Bedre enn standard NW: Ja, det tror jeg på. Bedre enn Prescott: Tjanei.. Det varierer nok mellom de ulike testene, men jevnt over tror jeg de blir ganske likeverdige. Jaja... 25 dager igjen til den ryktede lanseringen.. Lenke til kommentar
pskard Skrevet 8. januar 2004 Del Skrevet 8. januar 2004 Har AMD gjort dette lenge? Dette er helt nye info for meg. Fakta? Jeg trodde hovedulempen med dette var at det krever utrolig mye datakraft for å automatisere dette (tenk klynger til titalls millioner dollar). Resulatet er vel først og fremst at kritiske "datapaths" (på norsk =?) optimaliseres for mye bedre klokkesync og mye bedre timinger. Altså at den skal kunne skalere mye bedre med MHz. Varmefordelingen er nok underordnet prioroteten til timinger så det tror jeg ikke forbedres så mye. Lenge er et relativt begrep Om jeg husker rett så hadde AMD også automatisert dette på K7. I alle fall på de siste versjonene. At det krever masse prosessorkraft er helt klart. Det er vel en grunn for at K7 ble "taped out" på SUN-bokser. K8 på en kombinasjon av MP og SUN og K9 på Opteron. Du finner mer informasjon om du leser på APM 2.0 og 3.0 hos AMD. Jeg har fått en del info av AMD på APM 2.0 og 3.0, men de havnet i søplekassa... Lenke til kommentar
pskard Skrevet 8. januar 2004 Del Skrevet 8. januar 2004 "Vi har P4EE som med 2 MB L3 cache. En effektiv økning i cache på 1,5 MB (L3) er trolig bedre enn en økning på 0,5 MB på L2 cache. "-Trolig ikke det nei. Doc? "Videre sier Intel at P4EE yter bedre pr MHz." doc? pluss tror du egentlig på dette? Det gjør ikke jeg. Har ikke noen link som viser at det ER tilfelle, men det er ikke ulogisk å anta. Videre kan vi jo se på testene som er ute av Prescott. Vet at de er "gamle" (som jeg poengterer når jeg tok det opp), men uansett kan en se tendenser. Hovedproblemet er når en får cachemiss og må gå til hovedminnet. P4 har en latency på ca 100 nm eller noe sånt. Med 2 MB L3 cache får en plass til 2x så mye data som på Prescott. Selv om L3 cache (on die her) er noe tregere enn L2 så vil antall cachemiss bli redusert (logisk ettersom en har dobbelt så mye cache). Derfor vil 2 MB L3 trolig være bedre enn 1 MB L2. Eller at en får 1.5 MB mer L3 cache fremfor 0,5 MBekstra L2 cache. Merk at jeg snakker om jevnt over og en vil klart finne tilfeller hvor dette ikke vil stemme. Se også: http://rss.com.com/2100-1006_3-5121483.htm...=feed&subj=news http://www.theinquirer.net/?article=13383 http://www.theinquirer.net/?article=13475 Ser at det var en analyst på Insight 64 som skrev det og ikke en Intel-person. Har trolig lest det et annet sted som har missforstått. Prescott vil grunnet lengre pipeline kunne yte dårligere når CPU lasten er konsentrert på bare en tråd. Er CPU lasten fordelt på to eller flere tråder vil Prescott ha potensialet til å yte bedre enn både NW og EE. (Edit: trenden bør være uavhengig av SSE3 optimalisering) Om du leser det jeg skriver så er det nettopp det jeg skriver. Lenke til kommentar
Knick Knack Skrevet 8. januar 2004 Del Skrevet 8. januar 2004 (endret) - Endret 5. januar 2005 av Knick Knack Lenke til kommentar
pskard Skrevet 8. januar 2004 Del Skrevet 8. januar 2004 Klart vi er enige om det meste, men å bruke relasjonen til EE som et argument er det jeg er ute etter å komme til livs. Grunnen til at jeg sammenlikner Prescott med P4 EE har jeg vel sagt et par ganger før nå, men kan jo alltid si det igjen... 1. Vi vet at tidligere versjon av XEON for PII og PIII (som har vært mer cache) ikke har gitt mye ytelsesøkning (noe selvsagt, men ikke mye). 2. Vi vet at hovedforskjellen mellom NW og Prescott er mer cache (jada, en del annet også i positiv og negativ retning) 3. Vi vet at P4EE har høyere ytelse grunnet mer cache, men ikke så mye bedre ytelse. 4. Flere linker (se over) viser til at P4 EE vil ha høyere ytelse enn Prescott pr MHz. 5. De tidlige testene vi har sett av Prescott viser at den ikke er spesielt mye bedre enn NW. 6. Loven om "diminishing returns" - sleng på mer cache og få mer ytelse, sleng på dobbelt så mye og på litt mer ytelse osv. 7. Vi _kan_ også se litt på A64 3000+ vs 3200+ som har samme MHz, men ulik cache (512KB vs 1 MB). Forskjellen i ytelse var liten. Punkt 7 er trolig det dårligste argumentet, og du trenger ikke fortelle meg at det er forskjellige arkitekturer, eller at HT vil få en fordel av mer cache for jeg vet det allerede For å se hva andre har å si om P4EE vs Prescott se her: http://www.aceshardware.com/forum?read=105058217 Men nok om Prescott vs P4EE. Jeg har sagt mitt. Vi får se når den lanseres. Lenke til kommentar
Knick Knack Skrevet 8. januar 2004 Del Skrevet 8. januar 2004 (endret) - Endret 5. januar 2005 av Knick Knack Lenke til kommentar
Knick Knack Skrevet 9. januar 2004 Del Skrevet 9. januar 2004 (endret) - Endret 5. januar 2005 av Knick Knack Lenke til kommentar
Anbefalte innlegg
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 kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå