Gå til innhold

Intel-prosessorer kan bli inntil 30 prosent tregere


Anbefalte innlegg

Vet dere om det finnes en offentlig strategi for å håndtere risiko for lavere ytelse på systemer med Intel hardware. Dersom SQL-databasen krever en høy andel av tilgjengelig arbeidsminne RAM, skulle man tro at systemet fort kan knele.

Det er likegyldig for saken hvor mye ram programmene bruker. Fiksen bruker ikke mer ram enn den gamle koden.
  • Liker 1
Lenke til kommentar
Videoannonse
Annonse

 

Herregud, har akkurat kjøpt 5ghz 8700k fra Silicon Lottery. Håper ikke dette lager til noe tull som stuttering og lavere ytelse ved gaming.

Herregud, har akkurat kjøpt ny 73 fots yacht, og laptopen på akterdekket har jo Intel. Håper denne ikke blir tregere, så jeg slipper å ergre meg når jeg seiler forbi Mallorca.

Ellers har du det bra? :D

 

 
F!%#&!
Endret av Allostasis
Lenke til kommentar

Er du helt sikker på det? Jeg har sett databaseservere der SQL databasen krever mye av maskinressursene. Med bruk av mye RAM vil belastningen av CPU-ene også øke. Med redusert CPU-ytelse vil man ikke kompensere for høyt bruk av RAM? Det er jo en sammenheng der...eller? Dersom det er slik at bruk av RAM påvirker bruk av CPU blir spørsmålet om redusert CPU-ytelse også vil påvirke bruken av RAM. Er ikke dette relevant for problemstillingen med fiksen i forhold til reduksjon av totale maskinressurser? Dette kan jo være forskjellen mellom et tregt system og et system som bare stopper opp.Jeg regner med at et OS balanserer bruken av maskinressurser og at en endring av utnyttelse av et komponent kan føre til endringer i den totale dataflyten. Men håper du har rett, og at det ikke er grunn til bekymring.

Lenke til kommentar

SQL-servere blir potensielt hardt rammet av dette fordi de gjør mye IO (disk og nettverk). Det er grunn til bekymring, men det har ikke noe med ram å gjøre.

 

Med bruk av mye RAM vil belastningen av CPU-ene også øke.

Nei, egentlig ikke.

 

Med redusert CPU-ytelse

Det er ikke redusert CPU-ytelse. Det er kun oppgaver der programmet må få kjernen til å utføre funksjoner for seg som bruker mer CPU-tid. Endret av Emancipate
Lenke til kommentar

SQL-servere blir potensielt hardt rammet av dette fordi de gjør mye IO (disk og nettverk). Det er grunn til bekymring, men det har ikke noe med ram å gjøre.

 

 

Med bruk av mye RAM vil belastningen av CPU-ene også øke.

Nei, egentlig ikke.

 

Med redusert CPU-ytelse

Det er ikke redusert CPU-ytelse. Det er kun oppgaver der programmet må få kjernen til å utføre funksjoner for seg som bruker mer CPU-tid.

Takk for svar :-)

Lenke til kommentar

Er du helt sikker på det? Jeg har sett databaseservere der SQL databasen krever mye av maskinressursene. Med bruk av mye RAM vil belastningen av CPU-ene også øke. Med redusert CPU-ytelse vil man ikke kompensere for høyt bruk av RAM? Det er jo en sammenheng der...eller? Dersom det er slik at bruk av RAM påvirker bruk av CPU blir spørsmålet om redusert CPU-ytelse også vil påvirke bruken av RAM. Er ikke dette relevant for problemstillingen med fiksen i forhold til reduksjon av totale maskinressurser? Dette kan jo være forskjellen mellom et tregt system og et system som bare stopper opp.Jeg regner med at et OS balanserer bruken av maskinressurser og at en endring av utnyttelse av et komponent kan føre til endringer i den totale dataflyten. Men håper du har rett, og at det ikke er grunn til bekymring.

Tenkt deg at du regner mattestykker som er litt komplekse.

 

Du kan umulig ha alle tallene i hodet samtidig, så du bruker regneark og skriver ned mattestykkene og gjør en rekke enklere beregninger i hjernen din og skriver resultatet på arket og klarer å regne deg frem til endelig svar i slutten.

 

 

CPU er hjernen din. RAM er mattearket.

 

Om du bruker 10 ark eller 1 ark er likegyldig, så lenge du har plass på 1 ark. Flere ark gjør ikke hjernen raskere. Problemet er om du ikke har nok RAM. Da må CPUen dra til SSD eller HDD som er tregere og lengre vekke. Så da må CPU vente på å få tallene den spurte om.

 

Og det raskeste av alt er å ha best mulig hukommelse i selve hjernen, huske mer tall inne i hodet samtidig. 

 

Så RAM bruk er kun betinget av CPU bruk. Mest av alt derimot er det typen programmer. Hvor mye programmet vil ha lagret i RAM. Folk klager f.eks på at Chrome tar mye RAM. Grunnen til det er 2 ting. De har alle faner og slikt som egne prosseser, så alt ikke skal krasje om noe feiler. Den andre er at Chrome beholder mye greier i minne, så om du går tilbake på noe, eller går inn på noe Chrome tipper du vil er det allerede klart og det går raskere å laste. Ideelt sett for ytelse er det å ha alt i RAM det beste. Problemet er at det er dyrt, og alt data er vekke så fort strømmen ryker.

 

Så mer RAM kan gi økt ytelse om programmet du kjører har nytte av det, og er programmert til å ta det i bruk. Men det skjer aldri at økt RAM forbruk øker CPU bruk. Og ja som sagt over er problematikken her ikke egentlig relatert til dette i det hele tatt.

 

 

Det som er mest påvirker er når du må inn i kernel space for IO operasjoner, altså aksessere data fra SSD/HDD eksempelvis. 

Lenke til kommentar

Etter å ha testet før og etter på 4 forskjellige pcer, to laptops og desktop virker det som raskere disker som NVMe får større knekk enn "old school" ssd...

Ytelsestapet går jo utpå at context switching blir dyrere, altså bytte mellom kernel og user space.

 

Så hvor mye ytelse taper du? Det er avhengig av:

Hvor mange slike context switches programmet ditt gjør per tidsenhet.

Hvor rask er arkitekturen din på å bytte.

 

Nå hvis du går inn i kernel for å utføre en IO operasjon til din SSD så har du en fast tid x fastsatt av arkitektur og CPU som avgjør hvor lang tid det tar å bytte. Så har du en tid y som er tiden det tar å utføre IO operasjonen(e). X + Y avgjør da ytelsen du måler. Dermed vil SSDer i større grad bli rammet dess raskere de er. Fordi da blir context switchingen en større del av det som avgjør hvor lang tid det tar.

 

Litt det samme som at ingen brydde seg om NVMe for SSDer i starten, men når de begynte å bli raskere så vil en protokoll som utnytter flash lagring bedre virkelig begynne å gi merkbar forskjell og benyttes i dag for virkelig raske SSDer. For tregere SSDer derimot så gir det ikke nok utslag at det er så mye poeng i å gå over til NVMe.

  • Liker 1
Lenke til kommentar

90% av alle disse tallene er jo totalt meningsløse når de fleste tester uten mikrokodeoppateringen til CPU. Uten denne så er du jo ikke patchet/beskyttet mot Spectre i det hele tatt om jeg forstår det riktig? Alle tall på nett tilsier jo at det er kombinasjon av OS hotfix + mikrokode som er det som går hardest utover ytelsen.


 


Hva gjelder spillytelse så uttaler jo også NVIDIA at de må integrere noen hotfixer i GeForce og Quadro-driverne sine som de lover at skal komme i løpet av 1-2 uker. Så vi vet jo ikke om det også kan påvirke ytelsen i negativ grad.


 


 


Så her er det nok bare å avvente og ikke ta noen ting på forskudd. Det blir jo også veldig spennende å se hvem som faktisk vil motta mikrokodeoppdateringen. Intel lover at de skal slippe oppdatering til alle prosessorer sluppet de siste fem årene, så det betyr vel at de setter grensa et sted mellom SandyBridge og Haswell. Problemet er jo at det hjelper jo ingenting om Intel slipper oppdateringen, du er jo fremdeles helt avhengig av at systemprodusenten/hovedkortprodusenten slipper en ny BIOS/UEFI Firmware oppdatering.


 


Gudene vet hvor lang tilbake i tid Asus, Asrock, Gigabyte, MSI osv gidder å gå. Har mine tvil om at de gidder å gå så langt som fem år tilbake i tid og tilby oppdateringer til såpass gamle systemer og hovedkort. Ser vi hvor trege og ineffektive de forskjellige har vært med tanke på å tilby ny BIOS/UEFI Firmware med den kritiske Intel MEI firmware oppdateringen så virker det jo ikke spesielt lovende....


 


 


Må ærlig innrømme at jeg tviler sterkt på at madammen sin maskin med Asus Rampage IV Extreme og Intel Core i7-3960X kommer til å få noen oppdatering, det samme gjelder serveren som kjører Asus P8B-E/4L og Intel Xeon E3-1275v2 men Asus kan jo overraske positivt.


Lenke til kommentar
Gjest Slettet+6132

Det er ekstremt lettvinte "forklaringer" på både "Spectre" og "Meltdown" på nett for øyeblikket. :(

 

Uansett manglende teknisk forklaring:

Det er en skikkelig blemme av de som har laget arkitektur/"microcode" i CPU'er kombinert med tilsvarende glipper i de som har laget "core/kernel" kode i OS'er.

 

Men for å utnytte dette så må jo en "hacker" for det første få tilgang til maskinen/installert sin "kode" på maskin. Uavhengig av OS/CPU.

 

Artikkelen har kun rett i (skal vi tro) at fix'en (omgåelse av arkitetur-tabbene) at fix rammer Intel CPU mest.

 

Det får tiden vise.

 

Vi ser allrede at debattanter velger ulik stilling til dette foreløpige teoretiske problem.
 

Noen fornekter at det vil han noe si for deres favoritt-produsent (og de har trolig rett).

 

Andre velger den andre varianten og returnerer bestilt hw basert på Intel for å "sikre" seg med en AMD-basert rigg.

 

Jeg avventer, og forventer at sålenge det finnes noen der ute som koder mtp performance vil sikkerhet garantert bli glemt/utelatt = potensielt mulig for en hacker å utnytte.

 

Men igjen:

De som kan utnytte det må være særdeles "dyktige" (kunne arkitektur/lavnivå-kode) og de må få tilgang til en maskin (og det er forsåvidt lett mtp "vanlige" brukere koblet til Internett).

:)

Lenke til kommentar

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 konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...