[Løst] Ny dyr pc med mye støy

[LonelyMan]

Strømforbruk har en indirekte forbindelse til ytelse ja, jo varmere hardware er jo dårligere yter den, dette er vitenskap, og det er jo helt klart at du ikke forstår det av hva jeg leser. For hver 10 grader celsius økning, dobler også failraten, dette gjelder all hardware. Hver 10 grader.

[N o r e n g]

Strømforbruk har en indirekte forbindelse til ytelse ja, jo varmere hardware er jo dårligere yter den, dette er vitenskap, og det er jo helt klart at du ikke forstår det av hva jeg leser. For hver 10 grader celsius økning, dobler også failraten, dette gjelder all hardware. Hver 10 grader.

Ja, jeg vet at ytelsen faller noen promille med høyere temperaturer, men du prøver fortsatt å sammenligne 6 kjerner med 12MB Cache på en 256-bit minnekontroller mot 4 kjerner med 8MB Cache på en 128-bit minnekontroller, Sandy Bridge-E er helt klart kraftigere enn Ivy Bridge og å si noe annet er 100% feil.

 

Igjen, 6 kjerner mot 4 kjerner på nesten identisk arkitektur med identiske klokkefrekvenser kommer selvfølgelig til å resultere i 6 kjerners favør når du klarer å belaste alle 6 kjernene.

 

EDIT:

For å gjøre det enda mer svart på hvitt:

i7-3930k mot i7-3770k

Endret 13. juli 2012 av arni90

[LonelyMan]

Nei, du sammenligner prosessorer mot andre prosessorer. Jeg sammenligner chipset mot chipset. Du tenker opp-ned. Ivy bridge kommer med tilsvarende -E variant også, så det er liten grunn til å velge sandy bridge her.

 

På tross av disse to tingene, så sammenligner du bare hastigheter, men ikke features av chipsettet, det er features som definerer et godt chipset, ikke bare cache størrelsen og antall kjerner i prosessorer den støtter og vil støtte.

 

Jeg bryr meg ikke om hva du sier nå i ettertid at varmeutvikling ikke har noe med hastighet å gjøre, den har veldig mye med hastighet å gjøre. Om du endrer din mening rundt dette, så burde du heller si deg enig med meg, istedet for å si deg enig med din nye mening.

 

Om du har et sandy bridge oppsett som kjører på 40 grader celsius, og mitt ivy bridge chipset som kjører på 27 grader celsius, så er mitt oppsett 130 prosent mer stabilt.

Endret 13. juli 2012 av LonelyMan

[N o r e n g]

Nei, du sammenligner prosessorer mot andre prosessorer. Jeg sammenligner chipset mot chipset. Du tenker opp-ned. Ivy bridge kommer med tilsvarende -E variant også, så det er liten grunn til å velge sandy bridge her.

Ivy Bridge-E != Ivy Bridge

"Cougar Point" mot "Panther Point" er 4x USB3.0 og støtte for å dedikere 25% av PCIe-båndbredden fra CPU til en Thunderbolt.port i "Lynx Point"s favør, Z68 er faktisk spesifisert til 0.6W mindre enn Z77.

 

Sikker på at det er chipset du sammenligner her?

 

EDIT:

Stabilitet er avhengig av ECC, det får du ikke med i7-prosessorer.

Endret 13. juli 2012 av arni90

[LonelyMan]

Arkitekturen definerer mulighetene for chipsettet, så vi diskuterer chipset her, iallefall jeg, men det innebærer også arkitekturen naturligvis.

[N o r e n g]

Arkitekturen definerer mulighetene for chipsettet, så vi diskuterer chipset her, iallefall jeg, men det innebærer også arkitekturen naturligvis.

Chipset er noe du finner på hovedkortet utenfor CPUen, et chipset kan støtte flere forskjellige arkitekturer.

Arkitekturen er det du finner på kjernene på CPUen.

[LonelyMan]

Ja nettopp, hvorfor du diskuterer prosessorer er underlig. North og south bridge har ingenting med prosessorer å gjøre. Med unntak av at prosessorer er avhengige av dem he-he.

Endret 13. juli 2012 av LonelyMan

[N o r e n g]

Ja nettopp, hvorfor du diskuterer prosessorer er underlig. North og south bridge har ingenting med prosessorer å gjøre. Med unntak av at prosessorer er avhengige av dem he-he.

 

Nei, du sammenligner prosessorer mot andre prosessorer. Jeg sammenligner chipset mot chipset.

Diskuterer vi ytelse eller noe annet her?

[LonelyMan]

Ivy bridge ER bedre som jeg sa, og det kommer du ikke utenom. Du har rett og slett bare sett på ytelses-tester ang overklokking, hvilket har lite å gjøre med chipset og hvor bra et chipset er.

 

Om vi skal gjøre som du gjør, sammenligne hastigheter ved hjelp av overklokking, så kunne vi tatt en vanlig intel 4 prosessor inn i bildet som har vært overklokket til 6 GHz. Det hjelper veldig lite mot et nytt chipset.

Endret 13. juli 2012 av LonelyMan

[N o r e n g]

Ivy bridge ER bedre i visse tilfeller som jeg sa, og det kommer du ikke utenom.

Da er vi enige.

Om tid = penger for deg og du kjører programmer som skalerer over flere kjerner er Sandy Bridge-E et klart bedre kjøp enn Ivy Bridge.

[LonelyMan]

Flere kjerner har ikke noe å gjøre med chipset. Flere kjerner skalerer alltid bedre uansett hvilket chipset det er snakk om, man velger ikke Sandy bridge-E av den grunnen, dette gjelder alle chipset.

[LonelyMan]

ECC har ingenting med stabiliteten til elektrovarer å gjøre, det handler bare om error deteksjon i minnet (det er en hardware algoritme, det er ikke en elektrovitenskapelig funksjon), men om hovedkortet ditt har en temperatur på 40 grader og mitt ivy bridge har på 27 grader, så er mitt hovedkort teknisk sett 130% mer stabilt. Failraten dobler hver 10 grader celsius, det er ikke teoretisk, dette er målt vitenskap. Den dobler faktisk, det betyr ikke nødvendigvis at det vil krasje om den dobler, men muligheten for krasj VIL øke og den ØKER.

 

Om elektronikken i hovedkortet dobler failraten, så vil en eller annen komponent på det hovedkortet få en feil også, og det vil bidra til at OS'et har 130% større sjanse for systemkræsj.

 

Jeg kan legge til at ECC hjelper bare å finne feil, ikke å korrigere dem. Det gir ikke bedre stabilitet med ECC.

Endret 13. juli 2012 av LonelyMan

[N o r e n g]

Jeg har ikke nevnt overklokking, og jeg er lei av å krangle om definisjonen av chipset.

 

Hvorfor skal man velge Sandy Bridge-E om ikke for å få flere kjerner?

Mener du TS bør gå for Ivy Bridge eller Sandy Bridge-E?

[LonelyMan]

Om ekstrem ytelse er av preferanse og features, stabilitet, energiforbruk, varmeutvikling ikke er prioritert, så gå for Sandy Brige E

 

Men man sparer ikke penger ved å velge Sandy Bridge E. Det blir utklassert raskere enn ivy bridge, og du må bruke penger på et nytt kort raskere enn om du velger en nyere arkitektur.

 

Den største feilen folk gjør er å velge det nest beste fordi det er raskere, men 5-6 måneder etterpå når noe nytt slår rekorder (som det alldit gjør) så angrer de samme folkene. Man må være smart når man velger.

Endret 13. juli 2012 av LonelyMan

[Lovegame]

Folkens, ta det over PM!

[N o r e n g]

Om ekstrem ytelse er av preferanse og features, stabilitet, energiforbruk, varmeutvikling ikke er prioritert, så gå for Sandy Brige E

 

Men man sparer ikke penger ved å velge Sandy Bridge E. Det blir utklassert raskere enn ivy bridge, og du må bruke penger på et nytt kort raskere enn om du velger en nyere arkitektur.

Men Sandy Bridge-E gir deg ca 50% mer ytelse enn Ivy Bridge, vi er enige her?

 

Hva om en må ha en serie bilder ferdig rendret i løpet av dagen, med en Ivy Bridge tar det 3 timer å rendre disse og en person må være 2 timer på jobb overtid som koster bedriften 1000 kr, mens med Sandy Bridge-E vil det ta bare 2 timer som resulterer i bare 500 kr overtid. For å forsvare prisdifferansen mellom Ivy Bridge og Sandy Bridge-E kreves det 4 slike dager med overtid før det har lønt seg å gå for SB-E. Og da er ikke den økte produktiviteten i løpet av en arbeidsdag tatt med i betraktning en gang.

 

Intel har 3 år garanti på alle sine Xeon- og i7-prosessorer og alle systemer skal dermed være stabile i den perioden, innen 3 år vil kostnadene for kjøpet av et slikt system være inntjent.

 

Din påstand om at en Ivy Bridge-prosessor vil vare betydelig lengre enn en Sandy Bridge-prosessor våger jeg å påstå er rent sprøyt som du må forklare bedre med kilder.

 

Hvilken funksjonalitet utenom quicksync er det Ivy Bridge har over Sandy Bridge-E?

 

Energiforbruk er omlag 70W i Ivy Bridge sin fordel ved last og 10W ved idle, spørsmålet er om denne forskjellen ved full last kan forsvare det økte tidsforbruket.

Endret 13. juli 2012 av arni90

[LonelyMan]

Hva om en må ha en serie bilder ferdig rendret i løpet av dagen, med en Ivy Bridge tar det 3 timer å rendre disse og en person må være 2 timer på jobb overtid som koster bedriften 1000 kr, mens med Sandy Bridge-E vil det ta bare 2 timer som resulterer i bare 500 kr overtid. For å forsvare prisdifferansen mellom Ivy Bridge og Sandy Bridge-E kreves det 4 slike dager med overtid før det har lønt seg å gå for SB-E. Og da er ikke den økte produktiviteten i løpet av en arbeidsdag tatt med i betraktning en gang.

 

Jeg har programmert assembler nå i 17 år, og jeg kan det meste om software optimalisering. Grunnen til at software er tregt er fordi de fleste programmer er skrevet i c++. Når programmer kompileres av en c++ kompilator, så aksesserer den RAM hele tiden, programmet får aldri kjørt seg til det fulle potensialet i prosessoren, fordi den hele tiden må kopiere RAM til L3, til L2 og til data eller kode cache i L1 pga kompilatorer ikke er smarte nok til å lage buffere som holder seg i L1.

F.eks, en optimalisert c++ rutine for å rotere strenger (ROT13) gjorde dette med en hastighet på 20 MB i sekundet med optimalisert c++ kode. Jeg laget en tilsvarende variant i ren assembler, den roterte strenger med en hastighet på over 2 GB i sekundet, fordi jeg visste hvordan hardwaren fungerte (dette på en treg core 2 duo appåtil) og jeg kunne utnytte den til fulle.

altså, mitt assembler program kjører med en hastighet på 100 ganger faktor c++ programmet. For et firma å få mest ut av noe, kommer ned til hvor kompetent utviklerne er, i mye mye større grad enn hvilken hardware de velger, og dette sier jeg ikke for å være vrang, det er det som er faktisk. Et program kan kjøre absolutt helt forskjellig fra et annet, og det absolutt mest lønsomme et firma kan gjøre, noensinne, er å velge et annet program som kjører raskere. Ikke tull det jeg sier.

 

C++ kompilatorer kan aldri bli smarte nok til å forstå oppdeling av minne lesing og minne skriving, de kan til en viss grad optimalisere det, men de kan aldri bli gode nok til å utklassere god gammel assembler kode. Her er et diagram jeg har laget som forsøker å beskrive hvorfor c++ programmer holder prosessoren tilbake fra det fulle potensialet det kunne gitt. Det har minne lesinger og skrivinger i ukontrollerte former, hver gang de "treffer" en av de sorte søylene, mister prosessoren kraft, parallell kjøring blir nøytralisert, det er som å gå gjennom gjørme, føttene sitter fast i gjørma og du får aldri løpt fortere enn hva gjørma tillater. Mens i assembler diagrammet nederst, der har man mulighet til (i hvert enkelt tilfelle) laste data fra RAM i chunker, og så la prosessoren "flyte fritt" i et gitt spillerom, før den fortsetter til neste chunk.

 

Endret 13. juli 2012 av LonelyMan

[LonelyMan]

Noen tenker kanskje, "Ja, men begge programmene aksesserer jo samme mengde minne, så det burde jo gå like fort uansett". Her er et nytt diagram for å forstå hvorfor det ikke er slik:

 

La oss si en eller annen plass midt i programmet, så går vi inn i en loop. I c++ loopen så treffer den en av disse berømte søylene igjen, og looper gjennom den 1 million ganger, så får den dette enorme tapet av kraft 1 millioner ganger, mens i assembler programmet laster den data før den går i loopen, og så kjører den fullstendig fritt.

 

I c++ kan du kontrollere data tilgang noenlunde, men det vil ALLTID være en sort søyle der i minimal form eller enorm form, den vil aldri vært helt borte, i assembler kan du fjerne den fullstendig.

 

[LonelyMan]

Om det bare så er snakk om en simpel variabel i loopen, så får c++ programmet en sort søyle, og kjører ved maks hastighet av L1 cache hvor assembler programmet kjører med maks hastighet av de interne registrene, som kjører over dobbelt så raskt. Mange sier at kompilatorer er meget gode i dag, det er både sant og usant, kompilatorer er gode på å skalere koden HELHETLIG, men ikke spesialisert. Og denne mangelen på spesialitet gjør at c++ programmer alltid må være treg og tregere, og noen ganger ekstremt trege.

 

For å si det slik, jeg har aldri sett en eneste c++ funksjon som var fri for disse sorte søylene, det skjer aldri, så c++ programmer kaster prosessoren i en gjørmekamp hver eneste gang, man får ikke utnyttet maskinen ved å bruke c++ programmer, aldri, ikke en eneste gang. Jeg vet at du aldri har sett din datamaskin kjøre på full hastighet.

Endret 13. juli 2012 av LonelyMan

[N o r e n g]

Har du hørt om stråmannsargumenter?