Intel spår store gjennombrudd

[Anders Jensen]

Gleder meg til jeg kan kjøpe "4-sylindret" CPU til desktop, blir som å ha stor-sykkel: ytelse man sjelden bruker men jævlig kult at den er der når den (en sjelden gang) trenges!

Heller det enn å ha to stk som fyrer 30% bedre hele tida? 4-way desktop er som å kjøre på norske veier med trekkvogn. 600 HK til ingen nytte. En snerten Lotus er mye mer morro for mindre penger.

[th-3]

Skjønner at det er argument for mange, men jeg ser ikke helt behovet for høy enkeltkjerneytelse pr i dag til mitt bruk, dobbelkjerne passer perfekt for meg. Se bare hvor latterlig en FX55 yter i forhold til de billigste dobbelkjernene når det går tungt i motbakkene. Tror det blir temmelig likt når multicore kommer, har fortsatt NOK enkelttrådsytelse og enda mere i reserve og klart til bruk.

På den annen side merker jeg mer og mer at dual'n gjør flaskehalsene ellers i systemet veldig merkbare (har dårlig RAM i kassa), det problemet kan nok bli voldelig så merkbart med 4-sylindret, håper på tilsvarende store ytelsesøkninger også på minne-siden.

[Anders Jensen]

Jeg er ikke i mot 2-way desktop, jeg er i mot 4-way desktop når det går på bekostning av ytelse/tråd.

[TheIlluminated]

Jeg er for 16-veis desktop så lenge det er programvare til å utnytte det. Selv om 2 av CPUene ville vært knust av en annen 2-veis desktop så er bedre mer flere CPUer så lenge programvaren kan utnytte multitasking.

 

For min egen del er det HDD som er flaskehalsen i systemet mitt, noe jeg finner irriterende for at det er ikke veldig mange måter jeg kan få mye bedre ytelse utenom å gå til et dyrt og mest sannsynlig bråkete SCSI-system.

[lavizh]

lavizh: IDF har startet for lengst, AMD har utfordret Intel for lengst, Intel har takket nei for lengst

Det var synd, tør ikke Intel ta imot duellen ?

[kjaks]

lavizh: IDF har startet for lengst, AMD har utfordret Intel for lengst, Intel har takket nei for lengst

Det var synd, tør ikke Intel ta imot duellen ?

Det ville jo absolutt ikke være særlig smart av Intel å tørre det. Alle burde jo klare å tenke seg til at Intel gjør det best i ikke å lage mer mediaoppstyr rundt dette enn det allerede er blitt. Dessuten vil det gi AMD en meget god pekepinn på hva Intels prosessorer yter når alt er optimalisert, og mye raskere prosessorer de må lage for å følge opp neste generasjon fra Intel, siden disse offisielle testene må være 100% nøyaktige. AMD vil nok bare ha potensielle kunders oppmerksomhet før Intel lanserer sine nye 65nm prosessorer.

 

Selvfølgelig ville AMD gått av med "seieren" sammenlagt på dette tidspunktet. Det er jo akkurat derfor de vil utfordre Intel. De frykter helt klart Intels kommende prosessorer i den virkelige konkurransen om markedet..

Endret 25. august 2005 av kjaks

[Bofur]

Ja ja sier nå jeg Først så får Intel holde lansering datoene de viser til. Og når det skjer så får de som lever se hvor fristende det er å investere i ny hardware. Husker jeg gikk å venta på Presshot (aka prescott) men så ble den utsatt og atter utsatt. Da den endelig kom var den så sulten på strøm slik at de fleste HK var innkompatible.

 

Slik jeg ser det så duger min P4 [email protected] som kostet 1670kr våren 2003 duge til jeg får en får cpuer som har 3X ytelse til 2-3tusen

 

bortsett i fra AMD sin geniale cpu med integrert minnekontroller, så har det ikke skjedd stort de 2 siste årene innen cpu bransjen

 

Så det jeg sier er vel: Put your money where your mouth is

Endret 30. august 2005 av Bofur

[mar]

Jeg er ikke i mot 2-way desktop, jeg er i mot 4-way desktop når det går på bekostning av ytelse/tråd.

Det er nok den veien det går. Intel har jo et prosjekt gående (Mitosis) som tydeligvis har som mål å få flest mulig programmer til å bruke flere tråder. Virker ganske smart egentlig. Dersom det som står der er rett så skal kompilatoren gjøre deler av jobben. Noe som ikke er så dumt, siden den har litt bedre tid på seg, men samtidig betyr jo det at dette bare fungerer på kode kompilert med det rette kompilatoren.

 

Har selv jobbet litt med Open MP(automagisk paralellisering). Resultatene her ble ikke alltid like gode, men man fikk mye igjen i forhold til arbeidet som krevdes. Selv om feks bruk av MPI og god gammeldags manuell paralellisering ofte ga bedre resultater (tok mye lenger tid å programere/debuge).

 

Nå får jo Mitosis også hardware støtte, noe som sikkert hjelper litt på, men det kan vell fort bli en av de funksjonene som gir mye ekstra til noen typer oppgaver og fint lite til andre. Det at prosjektet eksisterer tyder nok på at Intel har innsett at antall kjerner kommer til å øke raskere enn "programeringsferdighetene" og dermed velger bruker dette trikset for å øke ILP.

 

Blir spennende å se hva de får ut av dette prosjektet, selv om det fremdeles er en stund til teknologien er klar for salg.

 

 

Edit: kompilator som jobber med å øke paralelliseringen innenfor en tråd. Har vi sett dette i en annen løsning fra Intel kanskje?

Endret 26. august 2005 av mar

[Anders Jensen]

Mitosis er et fint prosjekt det, men selv om en har all verdens teknikker for å finne TLP så koker det ned til at en rekke (del)problemer er serielle av natur og selv om der er parallellitet så kan det være så mye overhead og synkronisering at den paralelle versjonen faktisk har lengre critical path enn den serielle. Da blir det litt som Seymour Cray sa det: "If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens?"

[snorreh]

Mitosis er et fint prosjekt det, men selv om en har all verdens teknikker for å finne TLP så koker det ned til at en rekke (del)problemer er serielle av natur og selv om der er parallellitet så kan det være så mye overhead og synkronisering at den paralelle versjonen faktisk har lengre critical path enn den serielle. Da blir det litt som Seymour Cray sa det: "If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens?"

Ja, vedrørende dette så se også dette glimrende innlegget hos Ace's:

http://www.aceshardware.com/forums/read_po...12415&forumid=1

A result of the small number that gets printed and the huge surface it eats, means the price of such a highend processor is way way bigger than a pc processor.

 

This combined with the fact that the new generation supercomputers have so many processors (way over 10000), that only embarassingly parallel software can run on such supercomputers.

 

So Seymour Cray's statement is outdated by now: "If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens?"

 

The only real big advantage highend processors used to have is that they were 64 bits. Nowadays that also isn't the case anymore. They're all 64 bits now. So any 64 bits pc processor that gets a decent number of gflops a dollar, can be put in such massive supercomputers in the future (of course given the constraints of that it needs to have a bit of ECC and such).

 

A 1024 processor chicken processor supercomputer simply is way cheaper than a 240 processor itanium2.

Endret 27. august 2005 av snorreh

[Anders Jensen]

Vincent og snorreh er jo kjent for å strekke fakta rimelig langt for å kunne disse IPF nok en gang. Dette er etter min mening nok et slikt tilfelle. At lille Vincent går midt imot storheter som Cray og Amdahl (som egentlig er loven Cray her legger til grunn) er i kategorien "søtt å se på". Et godt tips er å ikke lese tallene til Cray for eksakt, neste er å forsøke å skalere en applikasjon med lite parrallellitet på en stor masin eventuelt cluster og merke seg hvor skaleringen begynner å bli negativ. Dvs. legg til en ekstra CPU og få mindre ytelse enn du hadde. Ofte skjer slikt allerede ved 16 noder i et cluster, men et er umulig å si noe generelt i retning av at store kraftige prosessorer er det eneste riktige eller at mange små er det eneste riktige. Det eneste en med sikkerhet kan vite er at de som hevder en av delene ikke aner hva de snakker om.

 

Noen applikasjoner kjøre godt på all slags hardware. f.eks rendering av film. Da lønner det seg å benytte billige maskiner med billige prosessorer. Andre applikasjoner igjen kan kjøre på mange prosessorer men krever kanskje store mengder deltminne for å kjøre effektivt. Andre igjen er notorisk følsomme for kommunikasjons overhead i systemet og vil "trashe" ytelsen på et hvilket som helst cluster. Sånn er det bare. I fremtiden blir det enda mer viktig å finne riktig maskin til riktig oppgave enn det er nå og har vært før.

 

Derfor er jeg interessert i ytelse/tråd. Alle applikasjoner nyter godt av det, mens det å øke antall simultane tråder hw støtter bare hjelper noen applikasjoner.

Endret 27. august 2005 av Anders Jensen

[snorreh]

Vincent og snorreh er jo kjent for å strekke fakta rimelig langt for å kunne disse IPF nok en gang. Dette er etter min mening nok et slikt tilfelle. At lille Vincent går midt imot storheter som Cray og Amdahl (som egentlig er loven Cray her legger til grunn) er i kategorien "søtt å se på".

"Lille Vincent", er det et forsøk på å være morsom? Vincent har rimelig god erfaring og peiling på benchmarking, spesielt med SMP-systemer (IA32, AMD64 og IA64).

 

Et godt tips er å ikke lese tallene til Cray for eksakt, neste er å forsøke å skalere en applikasjon med lite parrallellitet på en stor masin eventuelt cluster og merke seg hvor skaleringen begynner å bli negativ. Dvs. legg til en ekstra CPU og få mindre ytelse enn du hadde. Ofte skjer slikt allerede ved 16 noder i et cluster.

Dette er ikke noe nytt, og noe som alle vet som har jobbet med SMP- og kluster-systemer en stund. Man snakker ofte om skaleringsfaktorer, der Open MP-basert programvare i beste fall har en skaleringsfaktor på opptil 1.4-1.5, mens MPI-basert programvare klarer opptil 1.8-1.9. Dette avhenger selvsagt av hvor raskt prosessorene kommuniserer med hverandre, og da blir I/O- og minne-båndbredde spesielt viktig. Det finnes mange løsninger som fungerer ganske bra, fra InfiniBand PCI-X, Pathscale InfiniBand HTX og Cray RapidArray til NUMA og Newisys HORUS. Det blir spennende å se hvilken løsning SUN har valgt i sin kommende Galaxy-serie.

[Anders Jensen]

Vincent og snorreh er jo kjent for å strekke fakta rimelig langt for å kunne disse IPF nok en gang. Dette er etter min mening nok et slikt tilfelle. At lille Vincent går midt imot storheter som Cray og Amdahl (som egentlig er loven Cray her legger til grunn) er i kategorien "søtt å se på".

"Lille Vincent", er det et forsøk på å være morsom? Vincent har rimelig god erfaring og peiling på benchmarking, spesielt med SMP-systemer (IA32, AMD64 og IA64).

Ja, poenget var å være litt morsom/spydig. Jeg kunne vært litt styggere og sagt "oppblåste Vincent" med referanse til at han som resultat av sin suksess med sjakk-programmering har begynnt å gå midt imot allmenakseptert vitenskap på et fagområde han ser ut til å ha lite peiling på. Du kan vel si suksessen har gått litt i fletta på han. (Det er jo "tilfeldigvis" en post på Ace's som omhandler dette akkurat nå. http://www.aceshardware.com/forums/read_po...39261&forumid=1 *ler seg skakk* Vinnie er som du sikkert forstår en annerkjent uarch ekspert. NOT :!: )

Et godt tips er å ikke lese tallene til Cray for eksakt, neste er å forsøke å skalere en applikasjon med lite parrallellitet på en stor masin eventuelt cluster og merke seg hvor skaleringen begynner å bli negativ. Dvs. legg til en ekstra CPU og få mindre ytelse enn du hadde. Ofte skjer slikt allerede ved 16 noder i et cluster.

Dette er ikke noe nytt, og noe som alle vet som har jobbet med SMP- og kluster-systemer en stund. Man snakker ofte om skaleringsfaktorer, der Open MP-basert programvare i beste fall har en skaleringsfaktor på opptil 1.4-1.5, mens MPI-basert programvare klarer opptil 1.8-1.9. Dette avhenger selvsagt av hvor raskt prosessorene kommuniserer med hverandre, og da blir I/O- og minne-båndbredde spesielt viktig. Det finnes mange løsninger som fungerer ganske bra, fra InfiniBand PCI-X, Pathscale InfiniBand HTX og Cray RapidArray til NUMA og Newisys HORUS. Det blir spennende å se hvilken løsning SUN har valgt i sin kommende Galaxy-serie.

 

Disse skaleringsfaktorene er bare forenklede antagelser (de er førsteordens og dermed umulige for større variasjoner av antall noder, en bør bruke andreordens som et minimum) med svært begrenset gyldighetsområde. Du trekker her frem en helt annen del av skalerings konseptet enn det jeg påpekte. Selv en skalering på 1.1 er gulle godt om skaleringen holder seg slik for et vilkårlig antall noder. Poenget er at så aldri er tilfellet. Skaleringsfaktoren avtar for hver node du legger til (grovt sett, ser bort fra memmory effects som kan gjøre seg gjeldende i begynnelsen av kurven) og det var poenget mitt. Det burde ikke være for vanskelig å se det; Skaleringsfaktoren avtar når en øker antall noder

 

Edit: Denne sliden viser Amdahl litt mer detaljert, men la meg forklare likevel...

 

Du ser at ved 10% seriell del av koden så vil skaleringen nærmest avta fullstendig ved 16prosessorer gitt den urealistiske (les umulige) forutsetningen at en har null kommunikasjonsoverhead. Ved introduksjon av en ukjent størrelse overhead (rimelig teit å ikke oppgi den...) så viser de et scenario hvor en får negativ skalering fra 16 prosessorer og utover, igjen ved 10% seriell komponent.

Endret 28. august 2005 av Anders Jensen