Reverse HyperThreading

[sannheten_666]

Løgn er vel litt vel hardt å kalle det. Conroe er faktisk basert på arkitekturen til Pentium Pro. Er bare naivt og tro den er ny, men kraftig forbedret er den. K8 er jo samme kjernen som K7 med fobedringer der også.

6368064[/snapback]

 

 

øøøøøh.... da kan du like gjerne si at A64 er basert på 286 eller no sånt. det er visse likehtstrekk i alle prosesorer ja, men å snakke om at conroe er "basert på arkitekturen til P pro", som at de har tatt utganspunkt i Pentium Pro og forbedra den er nok bare piss.

du sier også at K8 er samma kjernen som K7 med forbedringer. hva forventer du? at hjulet finnes opp på nytt hver gang?

det du beskriver i innlegget ditt kalles evolusjon.

[mad_arab]

Nettopp det jeg reagerte på tidligere i tråden.. Når noen av en eller annen grunn bare måååå nevne at en cpu er basert på en eldre... Så er det vanskelig å tolke det på en annen måte enn at de forsøker å argumentere negativt om den de nevner, og da er veien kort til videre krangling. Så da er det best å si fra med en gang, og oppfordre folk til å holde seg for gode for denslags svake argumenter...

[Stigma]

Nettopp det jeg reagerte på tidligere i tråden.. Når noen av en eller annen grunn bare måååå nevne at en cpu er basert på en eldre... Så er det vanskelig å tolke det på en annen måte enn at de forsøker å argumentere negativt om den de nevner, og da er veien kort til videre krangling. Så da er det best å si fra med en gang, og oppfordre folk til å holde seg for gode for denslags svake argumenter...

6373189[/snapback]

 

Det er jo helt irrelevant hva en prosessor er bygget på. Det eneste som betyr noe er selvfølgleig ytelsen den presterer og evt. funksonaliteten den har. Om AMDs neste CPU slår conroe, men er basert på design tilbake til K6, så er vel jeg likegyldig til det... For min del er det forøvrig også revnende likegyldig hvilken produsent som har designet chippen også. Nå har AMD vært overlegen i lang tid, så da kjøpte jeg meg en AMD64. Nå ser det ut som Conroe vil ta helt av, så neste blir en conroe. Enkelt og greit. Hvis AMD kommer sterkt tilbake og tar over tronen for neste generasjon, så hopper over på andre siden av gjerdet igjen...

 

De som sitter og heier på et spesiellt merke er jo heller passelig dum i mine øyne. Produsenten gir jo ikke deg noe fordeler av å være die-hard fan framfor å kjøpe det produktet som faktisk er best. Det eneste som kan forsvare det måtte vært om du syntes èn av produsentene var spesiellt uhederlig, og ikke vill kjøpe på moralsk grunnlag, men nå er det vel ikke mellom Intel og AMD at det er mest skittkasting. Det er heller fansene på hver av sidene som tar seg av den flamewaren.

 

-Stigma

Endret 24. juni 2006 av Stigma

[Theo343]

Helt enig meg Stigma her. Irrelevant hva prossesoren er basert på av tidligere arkitekturer så lenge de viser fremskritt på ytelse, strømforbruk, funksjon, størrelse osv. Interresant å vite, men der stopper det.

 

Prosessorer ville jo blitt uhorvelig dyre om man ikke skulle basere seg på tidligere erfaringer? Om D945 som kommer nå er basert på netburst gjør meg ingenting så lenge de yter bra og ikke tømmer lommeboka.

 

At Conroe delvis bygger på den gamle Pentium Pro arkitekturen. So what? Utvikling går ut på å prøve seg frem i forskjellige retninger.

 

AMD64 er også basert på tidligere nyvinninger og erfaringer. Jeg gleder meg som en guttunge til høsten og for første gang i mitt liv kan jeg ikke vente på at sommeren skal gå fort nok. Det er et dårlig tegn for meg hehe, men viser at det skjer mye bra nå. Dog burde de gjøre slike lanseringer før sommeren asså? hehe.

 

Jeg er også skuffet over at det skrives slik artikler når kildene er såpass vage som i dette tilfellet. Er det for lite nyheter i IT bildet om dagen?

Endret 24. juni 2006 av Theo343

[Stigma]

Jeg er også skuffet over at det skrives slik artikler når kildene er såpass vage som i dette tilfellet. Er det for lite nyheter i IT bildet om dagen?

6373473[/snapback]

 

Vel.. det er lett å gå i fellen. mange andre ahrdware sites har publisert samme nyheten tidligere, og det er lett og tro at "hvis det står på alle disse sidene så må det jo være riktig". Dessuten så hadde det jo vært tiårests største sensasjon innen hardware om det faktisk fungerte som: antall kjerner x Ghz på hver kjerne = total prosessorhastighet. Da hadde plutselig AMD sin nye entusiastplattform med kapasitetfor 8+ kjerner sett veldig spennende ut, lol! =) Bare tenk deg en 8x3Ghz = 24Ghz CPU *droool*. Synd det bare er en drøm =/

 

-Stigma

[Theo343]

Hehe vel, lov å drømme litt. Forstår at hw.no har gått på limpinnen her, selv om de skrev at dette ikke var bekreftede opplysninger.

 

Da hadde jo AM2 sin 4x4 vært et desktop monster uten like om dette var sant

Endret 24. juni 2006 av Theo343

[Revox]

Nettopp det jeg reagerte på tidligere i tråden.. Når noen av en eller annen grunn bare måååå nevne at en cpu er basert på en eldre... Så er det vanskelig å tolke det på en annen måte enn at de forsøker å argumentere negativt om den de nevner, og da er veien kort til videre krangling. Så da er det best å si fra med en gang, og oppfordre folk til å holde seg for gode for denslags svake argumenter...

6373189[/snapback]

 

Poenget var vel at det ble nevnt i sammenheng med at conroe var omtalt som en ny design/arkitektur. Noe som ikke helt stemmer. Jeg bare utdypet det tidligere innlegget om at de baserer seg på eldre arkitekturer.

 

Dessuten K7 og P4 (og ikke minst Itanium) var nye arkitekturer fra scratch så at de finner opp hjulet til tider er ganske tydelig.

Det at conroe kom til å se dagens lys var ganske tydelig når intel lanserte banias og dothan for laptop. De fleste så at intel hadde en mye bedre prosessor her enn i P4. Så de gikk tilbake til sin eldre design og utviklet den videre istedet. Noe som var smart.

[Theo343]

scratch og scratch.

[haalo]

Tror ikke at dette blir så veldig kortlivet; folk kommer vel til å kjøre gamle programmer i en god stund framover .

[Shell]

Det er ikke noen magisk metode som kan slå sammen flere CPUer for å kjøre en enkelt tråd, selv om det er slik det er blitt misforstått som (og deretter kjørt store oppslag om, uten kildekritikk tydeligvis).

Jo det er mulig, kjør samme tråd på alle kjerner, velg en av de

 

Ok det er ikke mye vits, hvordan i huleste skal man klare å få en ytelses forbedring, det er problemet!

 

Og nå idéen:

Det hadde vært veldig moro om AMD sin Reverse Hyper Threading er noe i disse baner, for det vil bekrefte at denne ideen er effektiv nok til å gi ytelses forbedringer, som jo er problemet:

1. Kjør tråden på alle kjerner, synkroniser kjøringen ved spesifikke punkter i koden basert på hvilke instruksjoner som skal kjøres.

2. Kjernene kjører samme kode parallellt, men ved predictions velger de alltid forskjellig fra hverandre.

3. Når første kjerne blir ferdig med en del av koden kommer den til neste synkroniserings punkt. Alle kjerner som ikke er ved synkroniserings punktet flushes (blir samme som en mis-prediction omtrent).

4. Gå til 1 og repeter for neste sekvens av kode.

 

Positivt:

For to kjerner vil det halvere antall mis-predictions, for fire kjerner gir det 1/4 så mange mis-predictions (så vidt jeg kan se). Poenget er ihvertfall at det blir færre mis-predictions, og mis-predictions er dyrt.

Negativt:

CPUen trenger sentral logikk som synkroniserer prosessorene, gjør kjøringen av tråden tregere.

 

Hvem vet, kanskje AM2 CPUene har slik sentral logikk, en software oppdatering gjør susen.

Endret 24. juni 2006 av Shell

[CAT-scan]

Slik rent instinktivt tror jeg en slik metode ikke vil ha mye for seg.

[stoffix]

jeg tror at begge kjernene vil være enten i serie, eller paralell, men med direkte kontakt seg imellom, dette funker visst bare på nyere prosessorer til AM2, så det er jo åpenbart at de har vært nødt til å legge til noe.

 

nå sier kanskje noen at det visstnok har vært tester av gamlere AMD prosessorer som har slått conroe. Vel, AMD lager jo sine egen prosessorer, så det er sikkert ikke noe problem for dem å lage et par bare for å teste dem.

 

jeg vil vente å se, (hvem av oss vil ikke det?) men jeg tror personlig at det skjer noe. AMD har jo lanser dette systemet for å bruke to prosessorer for vanlige folk, og ikke bare for servere, så det kommer garanert noe, og det skulle ikke forundre meg om det hang sammen med dette.

 

Tenk deg hvis du fikk 100% ytelsesøkning ved å bruke dette på en prosessor, og siden du har dette på to prosessorer, så blir det som en quadkjerne prosessor med dett aktivert slik at OS ser to prosessor kjerner, mens det egentlig er 4, litt vanskelig å forklare, men jeg håper dere forstår hva jeg mener...

[fossie]

Liknende fra Intel - vil tro de bygger på samme prinsipper...

[mar]

Det at AMD fremdeles kjører delt L2 cache taler vel for at denne teknologien er et stykke unna (dersom den i det heletatt dukker opp). Er ikke så lenge mange mente at det var tull av Intel å øke bredden (fra 3 issue wide til 4). Begrunnelsen var vell at det ville være svært vanskelig å utnytte dette.

 

Hvordan man skal klare å realtime paralellisere en enkelt tråd over på 2 kjerner som skriver og leser til hver sin del av L2 cache kan jeg rett og slett ikke se for meg. Er vell egentlig vanskelig nok med delt L2.

 

Det jeg ser for meg er at det er snakk om funksjoner som kjenner igjen kodesnutter som kan paralelliseres. Litt som en realtime utgave av det en OpenMP kompilator gjør, men dette er jo noe helt annet enn denne artikkelen beskriver. Dette betyr vell i praksis at kode som "enkelt" kunne vært paralellisert fra utviklerens side kan paralelliseres i realtime. Dette vil jo selvfølgelig ikke løse det egentlig problemet som er å øke enkelttrådsytelsen (blir mer en kamuflering av slapt utviklingsarbeid).

 

Det er seint og det har vært en lang arbeidsuke, ca 50 timer, så det er sikkert mye feil her

[Anders Jensen]

Liknende fra Intel - vil tro de bygger på samme prinsipper...

6376714[/snapback]

Dette er parallellisering ved compile time. Det er vesentlig mye lettere enn ved runtime fordi en har mer informasjon og ikke minst mye mer tid til å lete.

[Jarmo]

scratch og scratch.

6374417[/snapback]

 

 

...og med dette geniale innlegget ang. CPU-arkitektur var doktoravhandlinger til jarmo ferdige

[Del]

Dette er et misforstått rykte på lang lang videvanke, og jeg er egentlig litt skuffet over at hardware ikke researchet bedre før de la ut nyheten. Vanligvis pleier vi å unngå slike jalla nyheter her.

6371192[/snapback]

Jeg er stort sett enig i alle dine konklusjoner. Når det gjelder research, så påstår Charlie å ha dette på det rene fra flere kilder (med dette mener jeg rht, ikke faktiske ytelsestall for teknologien). Kanskje AMD rett og slett forsøker å hype AM2 ved å sette ut et uoffisielt rykte.

 

Stigma: Har du sett noe arbeid på run time autoparallellisering på trådnivå? OOO er jo run time parallellisering på instruksjonsnivå. Jeg har imidlertid bare sett compile time autoparallellisering på trådnivå...

6372264[/snapback]

Godt spørsmål. Med arkitekturen til AMD, må essensielt en en-trådet applikasjon bli delt i to tråder hvis begge kjernene skal brukes, stort sett ingenting er delt mellom kjernene. Jeg har store problemer med å se hvordan de skal dele opp instruksjonsstrømmen mellom to kjerner effektivt uten en hel masse nye kretser, og nye steg i pipe-linen.

[fossie]

Liknende fra Intel - vil tro de bygger på samme prinsipper...

6376714[/snapback]

Dette er parallellisering ved compile time. Det er vesentlig mye lettere enn ved runtime fordi en har mer informasjon og ikke minst mye mer tid til å lete.

6378357[/snapback]

 

Mjo, både og. Compileren må åpne for muligheten, men hardwaren gjør de faktiske sjekkene når programmet kjøres:

 

Mitosis relies on both hardware and software (compiler) support to work. On the software side, the Mitosis compiler is responsible for analyzing the program, and locating the sections of it that can efficiently be executed in parallel. A key component of this analysis is the identification of sections of code whose corresponding precomputation slices have a very low computation overhead. Other conventional aspects such as workload balance also need to be considered.

 

On the hardware side, Mitosis is built on top of a multi-core and/or multithreaded processor. The main extension required is support for buffering and multiversioning in the memory hierarchy. Buffering is needed to keep the speculative state until the thread is verified and can be committed. Multiversioning is required to allow each variable to have a different value for each of the threads that are running in parallel. This is needed because every thread is executing a piece of code that started out with sequential semantics, but now, parallelized in threads, is being worked on simultaneously with values that were previously supplied in different points in time in the program.

 

Men det vil ikke fungere på gamle programmer uten å rekompilere først, slik mange håper (men ikke vet) om AMDs løsning.

[GGsyreb]

Du tar nok feil når det gjelder cpu hastighets beregningen din Stigma. faktisk cpu hastighet\beregningsevne måles i flops. en typisk cpu regner ca. 10 Gflops. 1 flop er en (1) floating point operation aka ett regnestykke. og en hz (i cpu sammenheng) tilsvarer at transistorene i cpuen kan gå fra 1 til 0 eller 0 til 1 i løpet av en hertz. så du vil ikke få fler hertz hvis man har flere cpuer (tenk dualcore). håper du forstår det slik jeg har forklart (siden jeg nesten ikke gjør det selv ). og sikkert ikke bare deg som ikke har forstått det, har møtt fler som jeg har måttet "konvertert".

[Del]

Hva tror du s'en i flops står for?

Hint:wikipedia.