Virallinen: AMD vs Intel keskustelu- ja väittelyketju

[Tsih]

Tosin onko tuosta mitään apua AMD:lle.

Linuksia on yritetty potkia tuohon suuntaan vuosikausia, eikä se ole oikein mihinkään edennyt..

Jottei olisi taas kuolleen hevosen potkimista ja rahan kaivoon heittämistä.. Toisaalta taas eipä AMD:llä taida olla tällä hetkellä muutakaan GPU puolella.....

Itselläni on se käsitys että esteenä pelien tulemisessa Linuxille on ollut ainoastaan OpenGL-osaaminen pelifirmoissa. Jos/kun Vulkan otetaan yleiseen käyttöön, DX12 sijasta, niin ongelman pitäisi tavallaan kuin itsestään poistua. Valvehan on osoittanut että OpenGL on Direct3D:n kanssa samalla viivalla suorituskyvyssä, jos vaan löytyy tekijöiltä tarpeeksi osaamista kyseiseen rajapintaan. Auttaa varmasti paljon Linuxiin vaihtamisessa kun näyttiksen ajureiden asentaminen/päivittäminen on helppoudessa samalla tasolla Windowsin kanssa.

edit: Tälläkin hetkellä esimerkiksi Fedoran mukana tulevat avoimet ajurit ovat sen verran hyvällä tasolla että aiemmin mainittu CS:GO 2K resolla ja asetukset tapissa toimii pääasiallisesti yli 150 fps, ainoa mikä puuttuu on Freesyncci, sekin kaiketi tulossa alkuvuodesta. R290 näyttis alla eli ei puhuta nykypäivän standardeilla mistään pedosta.

 

[AvatarX]

Selkeästi linux pelamiseen pistetään paukkuja nytten AMD:n suunnalta Ensiksi ajurit natiivina kerneliin ja sitten tämä

Siis nimenomaan ei pistetä paukkuja vaan annetaan muiden viilata ajureita kun itse ei pystytä/viitsitä.

 

[copter]

Periaatteessa näin mutta aiemmin se koodi on voinut olla ihan millaista purkkaa tahansa, nyt sen pitää noudattaa tiettyjä stantardeja unohtamatta sitä faktaa että maailmalla on kuitenkin suuri määrä osaamista joka voi nyt auttaa noiden ajureiden kehityksessä eteenpäin.

Se mikä tuossa oleellista olikin, että AMD myös: "will support third-party contributions to their driver".

Itse ainakin tulkitsen tuon niin, että muiden kuin AMD devaajien committeja tullaan sallimaan ja niiden kehitystä tullaan tukemaan AMD toimesta.

 

[sushukka]

Siis nimenomaan ei pistetä paukkuja vaan annetaan muiden viilata ajureita kun itse ei pystytä/viitsitä.

Vähän niin kuin Linuxin kanssa yleensä; eihän siitä nyt mitään voi tulla kun joku partanörttiarmeija vaan koodailee pitkin maailmaa niitä näitä. Ei pidä aliarvioida yhteisön voimaa, itse uskon että tästä voi tulla vielä aika kovakin juttu.

Ja noin Linux-pelaamisesta yleensä, PC-pelaajat ovat yleensä hieman paremmin perillä miten asiat oikeasti toimii ja heidät voi hyvin laskea siihen peligenren "enthusiasts"-joukkoon. Veikkaan että aika harva tästä porukassa jättäisi windowsinsa päivittämättä Linuxiin jos pelit pyörisivät siellä samalla lailla. Kaiken uuden kanssa ja varsinkin connectivity-puolella tahtoo tuo winkkari jäädä pikkuhiljaa Linukan jalkoihin. Itse en näe enää mitään muuta käyttöä windowsille kuin pelit. Toki on joitakin erikoisempia/kalliimpia sovelluksia kuvankäsittelyn puolella, mutta muuten se paras all-round-kone on jo pitkän aikaa kotona ollut Linux-pohjainen mylly. Samoin Linukkaa on saanut asennella sukulaisten vanhoihin läppäreihin, eikä kukaan ole motkottanut perään että olisi vaikea käyttää ja yleensäkin olleet hyvin tyytyväisiä. Tuollaisessa normikotikäytössä on vaikea löytää enää syytä maksaa sitä winkkarilisenssiä.

 

[copter]

Linux pelialustana on ihan jees, mutta tosiaan tukea ei vain ole kovin monelle pelille. Porttaaminen Linuxiin ei yleensä ole vain valitettavasti kannattavaa kun kehityksen kustannuksia ei saada takaisin. Yhtenäisemmillä rajapinnoilla tämä voi kuitenkin muuttua, mutta aika näyttää. Muutoksen saaminen aikaan on tässä kyllä valitettavasti työn ja tuskan takana, mutta kaikki tämän kaltaiset pienet stepit tietysti siinä jo vievät asioita oikeaan suuntaan.

Sinänsä tietysti tämä GPU puoli on pelaamisen suhteen oleellinen, mutta ehkä suurempi hyöty tulee vielä integroitujen ohjaimien puolelta. Käsittääkseni Intelin integroitujen ohjaimien kiihdytys ei vieläkään toimi out-of-the-box Ubuntussa. Tämä AMD liike ainakin varmistaa sen, että kaikkien distrojen on mahdollista sisällyttää virallinen rautakiihdytetty tuki helposti jokaiseen releaseen, myös niihin joissa halutaan ainoastaan käyttää open source ajureita eikä binääri tai third party julkaisuja.

 

[JiiPee]

Siis nimenomaan ei pistetä paukkuja vaan annetaan muiden viilata ajureita kun itse ei pystytä/viitsitä.

En ymmärrä tätä kun aina vedetään tämä pystytä/viitsitä kortti pöytään kun joku firma julkaisee opensourcena jotain joka on aikaisemmin ollut tarkoin varjeltu salaisuus.
Entäs jos kyse ei olekkaan siitä ettei kyettäisi/viitsittäisi? Mitäs jos asiaa tarkastelisi jostain ihan toisesta näkökulmasta?

 

[Kapteeni_kuolio]

Oiskohan ollut 1999 tai 2000 kun hankin ensimmäisen linuxin. Muistaakseni Mikrobitistä sillon tuli luettua että ihan kohta breikkaa mainstreamiin. Ekana oli Best Linux, suomalainen distro ja sit sen jälkeen heti hyppy syvään päähän ja Redhattii alle . Sillon oli jo puhetta siitä miten linux on ihan hilkulla että kohta breikkaa pelipuolella!

Hyvä että kehitystä tapahtuu ja ollaan ihan hilkulla etteikö 2018 ole "Linux year of the Desktop!"

 

[svk]

Mitäs muuten AMD:n linux kehotykselle muuten kuuluu? Muistaakseni selkeästi ennen ensimmäistäkään zeniä AMD karsi kunnolla linux puolelta. Onki zenin myötä palautettu taloudellinen tuki?

 

[sushukka]

Oiskohan ollut 1999 tai 2000 kun hankin ensimmäisen linuxin. Muistaakseni Mikrobitistä sillon tuli luettua että ihan kohta breikkaa mainstreamiin. Ekana oli Best Linux, suomalainen distro ja sit sen jälkeen heti hyppy syvään päähän ja Redhattii alle . Sillon oli jo puhetta siitä miten linux on ihan hilkulla että kohta breikkaa pelipuolella!

Hyvä että kehitystä tapahtuu ja ollaan ihan hilkulla etteikö 2018 ole "Linux year of the Desktop!"

Kuten sanottu, niin työasemapuoli on varmaankin juuri noin. Linux ja IOS sitä kuitenkin nakertaa pikkuhiljaa. Tuskin nyt kuitenkaan mitään räjähdystä tapahtuu. Jos nyt ihan vain käyttiksen näkökulmasta katsoo, niin kysymys on enemmänkin siitä minkä os:n parissa sen käyttäjän aika yhä enenevissä määrin kuluu. Mobiilipuoli on tukevasti *nix-pohjainen, samoin jokseenkin kaikki tietotekniikka sen työaseman ympärillä jääkaapeista autoihin. Palvelinpuolella Linux on kasvanut merkittävää vauhtia ja alkaa olla pian se oletus kun jotain uutta palvelua laitetaan pystyyn. Sitten on tietty supertietokoneet, tieteellinen laskenta, mikkihiiritietokoneet yms. Toisin sanoen se dominoiva käyttis markkinoilla on jo nyt Linux ja sen sijaan että ennen piti kissojen ja koirien etsiä niitä Linux-binäärejä, niin nykyään ne löytyy listan kärkipäästä ja Windows sen jälkeen jos löytyy.

 

[JiiPee]

Mitäs muuten AMD:n linux kehotykselle muuten kuuluu? Muistaakseni selkeästi ennen ensimmäistäkään zeniä AMD karsi kunnolla linux puolelta. Onki zenin myötä palautettu taloudellinen tuki?

Kyllä käsittääkseni väkeä on palkattu ainakin tuonne ROCm kehityksen puolelle.

 

[Jooga]

SemiWiki.com - IEDM 2017 - Intel Versus GLOBALFOUNDRIES at the Leading Edge

Ihan mielenkiintoinen yleisvertailu Intelin 10nm ja AMD:n 7nm prosesseista. Yhteenveto lupaa ihan hyvää AMD:lle viime vuosiin verrattuna


"3.0 Conclusion
Comparing Intel's 10nm process to GF's 7nm process they are more similar than they are different. Since both companies are solving the same difficult physics problems this is in some ways not surprising.

The surprising part in my opinion is that GF at 14nm stumbled so badly they had to license it from Samsung. Now they have an internally developed 7nm process that matches up well with Intel's latest 10nm process.

It is also surprising to me to see how far Intel has fallen from the process lead they had. First with HKMG by several years, first with FinFet by several year, I suppose they are still first to do cobalt interconnect but in terms of process density the foundries have caught them and appear poised to take a substantial lead over the next several years.

With Intel offering foundry processes and GF, Samung and TSMC all offering leading edge processes the industry now has four viable leading edge process options."

 

[Threadripper]

SemiWiki.com - IEDM 2017 - Intel Versus GLOBALFOUNDRIES at the Leading Edge

Ihan mielenkiintoinen yleisvertailu Intelin 10nm ja AMD:n 7nm prosesseista. Yhteenveto lupaa ihan hyvää AMD:lle viime vuosiin verrattuna

Ja näin. 32nm SOI oli erinomainen prosessi, mutta valitettavasti sillä piti pärjätä lähes 6 vuotta joka on aivan liian pitkä aika. 14nm LPP taas oli puhdas hätäratkaisu ja edelleen voi ihmetellä miten Ryzen kellottuu edes 4 GHz:n niin maltillisella lämmöntuotolla.

Muutenkin Intelin ylivoima valmistuspuolella alkaa olla mennyttä. Painetta tulee niskaan TSMC:lta, Samsungilta ja GlobalFoundriesilta siihen tahtiin etten ihmettelisi vaikka kaikki kolme menisivät ohi jo tällä vuosikymmenellä.

 

[hkultala]

Ja näin. 32nm SOI oli erinomainen prosessi

En nyt sitäkään erinomaiseksi menisi sanomaan, vaikka se olikin viimeinen "kunnolla CPU-optimoitu prosessi" AMD/GF-leirissä. Pikemminkin sanoisin sitä CPU-käyttöön "kelvolliseksi" prosessiksi kuin erinomaiseksi.
Llano kellottui huonompiin lukemiin kuin Phenom 2, vaikka perustui samaan mikroarkkiarkkitehtuuriin vain hyvin pienillä viilauksilla.

Jos 32nm SOI olisi ollut erinomainen prosessi, Llano olisi kellottunut jonkin verran Phenom 2sta korkeammalle, ja bulldozer pitkän liukuhihnansa kanssa olisi ollut helposti heittämällä viidessä gigahertsissä. Nyt 5 GHz saavutettiin vasta piledriverilla järkyttävällä jännitteellä ja sähkönkulutuksella.

mutta valitettavasti sillä piti pärjätä lähes 6 vuotta joka on aivan liian pitkä aika. 14nm LPP taas oli puhdas hätäratkaisu ja edelleen voi ihmetellä miten Ryzen kellottuu edes 4 GHz:n niin maltillisella lämmöntuotolla.

Ei se "14nm LPP" niin huono ole, vaikka onkin hiukan huonompi kuin TSMCn "16nm" ja intelin "14nm". Se on esim. joka suhteessa paljon parempi kuin välissä ollut "28nm" bulk-prosessi.

Mutta surullista tosiaan oli, että ekasta "32nm SOI"lla valmistetusta tuotteesta meni n. 5 vuotta, ennen kuin AMDllä/GFllä oli seuraava tuota "32nm SOI"-prosessia nopeampi valmistusprosessi valmiina (ja sitten valitettavasti sen jälkeen meni vielä n. 9kk että sillä saatiin CPU ulos), kun "28nm" bulk-prosessi oli hitaampi ja "20nm" prosessi kuopattiin kokonaan.

Ja nuo prosessit skaalautuvat aivan eri tavalla. Nuo vanhat CPU-optimoidut prosessit olivat sellaisia, että maksimikelloa irtosi paljon, mutta virrankulutus pienelläkin kellolla oli suuri. Nykyiset pienet ei-CPU-optimoidut prosessit eivät oikeastaan juurikaan maksimikelloltaan kellotu niitä korkeammalle, mutta virrankulutus pienillä kelloilla on monta kertaa pienempi.

 

[Threadripper]

En nyt sitäkään erinomaiseksi menisi sanomaan, vaikka se olikin viimeinen "kunnolla CPU-optimoitu prosessi" AMD/GF-leirissä. Pikemminkin sanoisin sitä CPU-käyttöön "kelvolliseksi" prosessiksi kuin erinomaiseksi.
Llano kellottui huonompiin lukemiin kuin Phenom 2, vaikka perustui samaan mikroarkkiarkkitehtuuriin vain hyvin pienillä viilauksilla.

Jos 32nm SOI olisi ollut erinomainen prosessi, Llano olisi kellottunut jonkin verran Phenom 2sta korkeammalle, ja bulldozer pitkän liukuhihnansa kanssa olisi ollut helposti heittämällä viidessä gigahertsissä. Nyt 5 GHz saavutettiin vasta piledriverilla järkyttävällä jännitteellä ja sähkönkulutuksella.

Llanossa ei panostettu korkeisiin kelloihin vaan lämmöntuottoon. Näytönohjain syö virtabudjetista niin paljon ettei ole tarvetta korkeille kellotaajuuksille. Llano oli tavallaan Phenom II arkkitehtuurin Steamroller. Pelkästään integroidun näytönohjaimen kanssa myyty, matalammat kellot ja vähemmän lämpöä.

AMD ei koskaan korjannut Bulldozeria kunnolla joka rajoittu pahasti kellotaajuutta ilman nestetyppeä. Nyt on helppo jälkiviisastella: lähes kaikki panostus laitettiin Piledriverin jälkeen Zeniin ja Bulldozer arkkitehtuuriin tyydyttiin tekemään pientä viilausta. Näin jäi näkemättä mihin Bulldozer arkkitehtuuri todella olisi pystynyt.

Ei se "14nm LPP" niin huono ole, vaikka onkin hiukan huonompi kuin TSMCn "16nm" ja intelin "14nm". Se on esim. joka suhteessa paljon parempi kuin välissä ollut "28nm" bulk-prosessi.

Mutta surullista tosiaan oli, että ekasta "32nm SOI"lla valmistetusta tuotteesta meni n. 5 vuotta, ennen kuin AMDllä/GFllä oli seuraava tuota "32nm SOI"-prosessia nopeampi valmistusprosessi valmiina (ja sitten valitettavasti sen jälkeen meni vielä n. 9kk että sillä saatiin CPU ulos), kun "28nm" bulk-prosessi oli hitaampi ja "20nm" prosessi kuopattiin kokonaan.

Ja nuo prosessit skaalautuvat aivan eri tavalla. Nuo vanhat CPU-optimoidut prosessit olivat sellaisia, että maksimikelloa irtosi paljon, mutta virrankulutus pienelläkin kellolla oli suuri. Nykyiset pienet ei-CPU-optimoidut prosessit eivät oikeastaan juurikaan maksimikelloltaan kellotu niitä korkeammalle, mutta virrankulutus pienillä kelloilla on monta kertaa pienempi.

Ei hirveän huono mutta Ryzenissä tulee hyvin tiukka raja vastaan ilmajäähyllä noin 4 GHz:n kohdalla vaikkei lämmöntuotto siinä vaiheessa rajoita juuri ollenkaan. Raja tuskin johtuu arkkitehtuurista. Intelin prosessilla ei ole vastaavaa yhtä tiukkaa rajaa.

28nm bulkiin verrattuna 14/16nm prosessit ovat tietenkin ylivoimaisia kuten oli helppo ennustaa. Tuo 20nm skippaus tuntui kannettavien ja näytönohjaimien puolella pahasti. Kai sillä piti jotain työpöydällekin saada (Steamroller/Excavator?).

Niinpä, tuskin enää koskaan nähdäänkään prosesseja joilla haetaan hirveitä kellotaajuuksia lämmöntuoton kustannuksella kun prosessoritkin on optimoitu pienemmille kellotaajuuksille eikä olla tekemässäkään Netbursteja.

 

[hkultala]

Llanossa ei panostettu korkeisiin kelloihin vaan lämmöntuottoon. Näytönohjain syö virtabudjetista niin paljon ettei ole tarvetta korkeille kellotaajuuksille. Llano oli tavallaan Bulldozer arkkitehtuurin Steamroller

Llano perustui Phenom-/K10-arkkitehtuuriin, ei bulldozeriin.

Trinity (jossa oli piledriver-ytimet) oli ensimmäinen bulldozer-johdannainen fuusio-piiri/APU.

 

[Threadripper]

Llano perustui Phenom-/K10-arkkitehtuuriin, ei bulldozeriin.

Trinity (jossa oli piledriver-ytimet) oli ensimmäinen bulldozer-johdannainen fuusio-piiri/APU.

Sitä tarkoitikin, mutta lipsahti väärä vertailu. Korjattu.

 

[sushukka]

Ja nuo prosessit skaalautuvat aivan eri tavalla. Nuo vanhat CPU-optimoidut prosessit olivat sellaisia, että maksimikelloa irtosi paljon, mutta virrankulutus pienelläkin kellolla oli suuri. Nykyiset pienet ei-CPU-optimoidut prosessit eivät oikeastaan juurikaan maksimikelloltaan kellotu niitä korkeammalle, mutta virrankulutus pienillä kelloilla on monta kertaa pienempi.

Näyttäisi tosiaan nuo jatkossa watit merkkaavan enemmän kuin gigahertsit:
An end to scaling: Intel's next-generation chips will sacrifice speed to reduce power - ExtremeTech
Netti on nyt näitä artikkeleita väärällään, mutta kyllä se enenevissä määrin alkaa näyttää siltä, että tähän suuntaan mennään jo nyt. Kovilla kelloilla tyydytetään joku porukka, pienellä virrankulutuksella lähes kaikki. Pelipuolella tämä tarkoittanee että haaste utilisoida mahdollisimman tehokkaasti hajautuva laskentateho siirtyy enemmän korkeammille tasoille (kääntäjät, pelimoottorit, grafiikka-API:t yms). Toisaalta ei kai tämä nyt kovin mahdotonta ole kun noissa konsoleissa on aina ollut paljon hitaita ruppaytimiä, mutta silti ne pelit näyttää hyviltä. Joku voi sanoa ettämutku PC:llä näyttää paremmalta, niin sitten menee joku hetki ja tulee uus konsoli, jolla ne graffat jokseenkin yhtä hyvät kuin sillä vähän vanhemmalla PC:llä...ja silti se prossun maksimikello on edelleen sikahidas, paljon hitaampi kuin siinä PC:ssä. Toisekseen tuo uusin ääsboks ei ole yhtään hassumpi kapistus, ei mitään jakoa päästä lähellekään samaa kyvyvkkyyttä PC-puolella samalla budjetilla, hyvä jos samantehoisen näytönohjaimen edes saa.

 

[hkultala]

Näyttäisi tosiaan nuo jatkossa watit merkkaavan enemmän kuin gigahertsit:
An end to scaling: Intel's next-generation chips will sacrifice speed to reduce power - ExtremeTech
Netti on nyt näitä artikkeleita väärällään, mutta kyllä se enenevissä määrin alkaa näyttää siltä, että tähän suuntaan mennään jo nyt.

Tuo artikkeli vaikuttaa vähän siltä, että sen kirjoittaja on pahasti väärinymmärtänyt jonkun alkuperäisen esityksen pontin.

Mikä tilanne lienee oikeasti:

Joku intelillä on sanonut, että IoT tulee olemaan intelille tärkeä markkinasegmentti tulevaisuudessa, ja SIINÄ tarvitaan erittäin vähävirtaisia piirejä. Ja sitten on vähän löpinää valmistusprosesseista yms. jotka mahdollistavat sen todella pienen virrankulutusken sille IoT:lle(jopa suorituskyvyn kustannuksella).

Intel ei kuitenkaan ole "isoissa PC-prosessoreissaan" ottamassa (ainakaan kaikkia) näitä tekniikoita käyttöön

Kovilla kelloilla tyydytetään joku porukka, pienellä virrankulutuksella lähes kaikki.

Ei nyt sotketa kellotaajuutta ja yhden ytimen suorituskykyä keskenään. Kellotaajuudella ei suoraan pitäisi koskaan olla kuluttajalle/käyttäjälle mitään väliä, vaan käyttäjälle pitäisi olla väliä vain suorituskyvylle tietyissä tilanteissa, ja kellotaajuus on vain yksi keino saavutta se suorituskyky.

Ja intel tajusi jo >10 vuotta sitten P4sta luopuessaan, että sähkönkulutuksella on väliä, ja jo silloin tehtiin siirtymä maksimisuorituskyvyn tavoittelusta järkevään kompromissiin suorituskyvyn ja sähkönkulutuksen välillä.

Pelipuolella tämä tarkoittanee että haaste utilisoida mahdollisimman tehokkaasti hajautuva laskentateho siirtyy enemmän korkeammille tasoille (kääntäjät, pelimoottorit, grafiikka-API:t yms).

öö, ei tässä NYT ole mitään muutosta nyt tulossa. Intelillä on jo todella monen vuoden ajan ollut kuluttajille myynnissä prosessoreita, jotka ajaa kahdeksaa säiettä. Softatuki vaan aina laahaa perässä.

Ja käytännössä noiden ohjelmointirajapintojen suhteen tilanne on se, että ne voi olla monisäikeistyksen suhteen joko neutraaleita (koodaaja joutuu itse nysväämään asioita ja miettimään synkronointia, mutta asiat on mahdollisia: normaali vanha C/C++), sitä rampauttavia (kielletty tai estetty asioiden tekeminen monesta säikeestä: python(*)/javascript), tai sitä mahdollistavia ja helpottavia: OpenMP, OpenCL, C++17n parallel algorithms.

Kääntäjien tukea asioiden rinnakkaistukselle parannetaan jatkuvasti, mutta overhead uusien säikeiden luomisessa ja niiden synronoinnissa on niin suuri, että mitään täysin automaattista uusia säikeitä luovaa rinnakkaistajaa ei kääntäjään kannata tehdä, vaikutus olisi aivan liian usein negatiivinen. Kääntäjien automaattisessa rinnakaistustuessa keskitytään enemmän siihen, että SIMD-käskykannat (SSE, AVX, AVX-512) saadaan käyttöön tehokkaasti. Ja koodaaja sitten kirjoittaa ne pari OpenMP-pragmaa niihin todella pitkiin isoihin looppeihin, jotka halutaan rinnakkaistaa myös useammille säikeille, tai luo itse ne säikeet niille rinnakkaisille korkean tason taskeille.

Ja tosiaan javascriptin ja pythonin (jotka on monisäie-vihamielisiä kieliä) käyttö on vaan jatkuvasti lisääntymässä

Toisaalta ei kai tämä nyt kovin mahdotonta ole kun noissa konsoleissa on aina ollut paljon hitaita ruppaytimiä, mutta silti ne pelit näyttää hyviltä.

Hyvältä näyttäminen on enemmän kiinni näyttiksen väännöstä, ei CPUn. CPU-tehoa tarvii enemmän siihen, että se pelimaailma toimii järkevästi. Ja siinä konsolipelit on keskimäärin olleet selvästi PC-pelejä jäljessä, konsolipelit on paljon yksinkertaisempia sisällöltään ja pienempiä maailmaltaan yms.

Ja intelillä on jo nyt kuluttajille markkinoilla piirejä, jotka ajaa suurempaa määrää rautäsäikeitä kuin mikään konsoli.

Joku voi sanoa ettämutku PC:llä näyttää paremmalta, niin sitten menee joku hetki ja tulee uus konsoli, jolla ne graffat jokseenkin yhtä hyvät kuin sillä vähän vanhemmalla PC:llä...ja silti se prossun maksimikello on edelleen sikahidas, paljon hitaampi kuin siinä PC:ssä. Toisekseen tuo uusin ääsboks ei ole yhtään hassumpi kapistus, ei mitään jakoa päästä lähellekään samaa kyvyvkkyyttä PC-puolella samalla budjetilla, hyvä jos samantehoisen näytönohjaimen edes saa.

Konsoleilla framerate on tyypillisesti rajoitettu 60 FPSään. Tarkoittaa sitä, että vääntöä samannäköisen grafiikan piirtämiseen tarvii vähemmän kuin että PCllä haluttaisiin sama kama pyörimään selvästi suuremmalla FPSllä.

Lisäksi konsoleilla kun tiedettiin tasan tarkkaan, mikä kohdekonsolin suorituskyky on, voitiin tehdä todella paljon sellaisia optimointeja, että jos vaikka jossain tietyssä kohdassa kenttää framea ei ehdittäisikään piirtää 16.666 millisekunnissa, sitten siitä kohtaa kenttää poistetaan hiukan yksityiskohtia, tai tilapäisesti jätetään kauempana olevia kohteita piirtämättä tms. jolla saadaan se piirtäminen mahtumaan yhteen ruudunvirkistykseen.

Tai jos tiedetään, että vaikka jonkun tietyn aseen suuliekki saisi aikaan efektin jonka piirtäminen on liian hidasta, sitten yksinkertaistetaan sitä efektiä tai rendataan muuta kamaa pienemällä laadulla, kun se efekti on ruudulla.

Nyt uusien molempiin suuntiin yhteensopivien mutta erisuorituskykyisten konsolien kanssa tällaisten optimointien tekeminen menee sitten hankalammaksi.



(*) pythonissa monen säikeen käyttöä ei ole täysin estetty, mutta säikeitä ei voi vaan tehdä ja ajaa rinnakkain eikä mikä tahansa python-koodi voi ajautua rinnakkain. Yksittäisiä kohtia koodista saa rinnakkaistettua jollain mekanismilla, mutta tämä soveltuu vain siihen että joku yksittäinen loppi rinnakkaistetaan monelle säikeelle, ei siihen että koodissa on monta korkean tason taskia joita ajetaan rinnakkain

 

[branch]

Ja käytännössä noiden ohjelmointirajapintojen suhteen tilanne on se, että ne voi olla monisäikeistyksen suhteen joko neutraaleita (koodaaja joutuu itse nysväämään asioita ja miettimään synkronointia, mutta asiat on mahdollisia: normaali vanha C/C++), sitä rampauttavia (kielletty tai estetty asioiden tekeminen monesta säikeestä: python(*)/javascript), tai sitä mahdollistavia ja helpottavia: OpenMP, OpenCL, C++17n parallel algorithms.

Säikeistyvät web workerit on ollut javascriptissä jo pitkään.
Using Web Workers

 

[hkultala]

[offtopic]

Säikeistyvät web workerit on ollut javascriptissä jo pitkään.
Using Web Workers

.. mutta niillä ei voi käpistellä DOMia. Domia saa käpistellä vain se "pääsäie". Ja kommunikaatio web workereille on hidasta viestinvälitystä.
Eli käytännössä web workerit eivät ole saman prosessin säikeitä vaan erillisiä prosesseja.

Ja niiden kautta monisäkeistämisestä saatavista hyödyistä suuri osa hukkuu helposti kommunikaatio-overheadeihin, ellei niissä tehdä jotain hyvin erillistä jonka tarvii kommunikoida vain hyvin vähän muun ohjelman kanssa.

[/offtopic]

 

[sushukka]

Tuo artikkeli vaikuttaa vähän siltä, että sen kirjoittaja on pahasti väärinymmärtänyt jonkun alkuperäisen esityksen pontin.

Mikä tilanne lienee oikeasti:

Joku intelillä on sanonut, että IoT tulee olemaan intelille tärkeä markkinasegmentti tulevaisuudessa, ja SIINÄ tarvitaan erittäin vähävirtaisia piirejä. Ja sitten on vähän löpinää valmistusprosesseista yms. jotka mahdollistavat sen todella pienen virrankulutusken sille IoT:lle(jopa suorituskyvyn kustannuksella).

Intel ei kuitenkaan ole "isoissa PC-prosessoreissaan" ottamassa (ainakaan kaikkia) näitä tekniikoita käyttöön

Ei nyt sotketa kellotaajuutta ja yhden ytimen suorituskykyä keskenään. Kellotaajuudella ei suoraan pitäisi koskaan olla kuluttajalle/käyttäjälle mitään väliä, vaan käyttäjälle pitäisi olla väliä vain suorituskyvylle tietyissä tilanteissa, ja kellotaajuus on vain yksi keino saavutta se suorituskyky.

Ja intel tajusi jo >10 vuotta sitten P4sta luopuessaan, että sähkönkulutuksella on väliä, ja jo silloin tehtiin siirtymä maksimisuorituskyvyn tavoittelusta järkevään kompromissiin suorituskyvyn ja sähkönkulutuksen välillä.

IBM's 5nm chip could quadruple battery life
Intel pursues Moore's Law with plan to make first 7-nm chips this year
Samsung and TSMC Roadmaps: 8 and 6 nm Added, Looking at 22ULP and 12FFC

Onhan näitä. Pointtini oli se, että vähävirtaisuus on enenvissä määrin se ykkösprioriteetti nykyään ja kasvaa siirryttäessä pienempiin viivanleveyksiin.

Toki tehoakin pitää olla, mutta sen eteen ei nähdä enää niin paljon vaivaa, tai sitten samanlaisia kasvulukuja on vain yhä vaikeampi saavuttaa. Oma ymmärrykseni on, mitä olen nyt joitakin seppoja käynyt aiheen tiimoilta kuuntelemassa, niin kellotaajuuksien kasvattaminen on yhä vaikeampaa joka on edelleen merkittävä tapa kasvattaa sitä yhden säikeen suorituskykyä. Tämän takia jotta Mooren-"laissa" pysytään, niin sitä absoluuttista laskentatehoa pitää kasvattaa lisäämällä rinnakkaisuutta ja tämä, kuten mainitsit, ei ole aivan triviaali juttu koko laskentaketjua käyttäjän sovellukselle asti tarkastellessa.

IoT:ssa virrankulutuksella on iso merkitys, mutta sen käyttötapauksissa ei nyt muutenkaan tarvita sitä laskentatehoa kuin aivan minimaalisesti ja virransäästö hoidetaan useimmiten eri boardeihin rakennetuilla virransäästötekniikoilla (deep sleep yms). Se että meneekö siihen anturan tai säätiedon lukemiseen muutama mikroamppeeri on vielä toistaiseksi yksi lysti varsinkin kun vastaan alkaa tulla jo nykyään usein paristojen elinikä. Business-mielessä IoT-kilpailu on kovaa ja de facto on Arduino/LUA, niin ostetaan sitä mikropiiriroskaa sieltä mistä sitä halvimmalla saa. Vaikea nähdä että Intelille olisi mitään järkeä lähteä tälle segmentille. Onhan heillä tuo Quark, mutta sille ei ole tapahtunut mitään pitkään aikaan. Samoin hetki sitten ajoivat kaikessa hiljaisuudessa alas nuo Galileo,- Joule- ja Edison-kehityslankut. Samaan aikaan AtMegat, ESPit, Raspit/ARMit yms. ovat jo tukevasti vallanneet markkinat.

öö, ei tässä NYT ole mitään muutosta nyt tulossa. Intelillä on jo todella monen vuoden ajan ollut kuluttajille myynnissä prosessoreita, jotka ajaa kahdeksaa säiettä. Softatuki vaan aina laahaa perässä.

Ja käytännössä noiden ohjelmointirajapintojen suhteen tilanne on se, että ne voi olla monisäikeistyksen suhteen joko neutraaleita (koodaaja joutuu itse nysväämään asioita ja miettimään synkronointia, mutta asiat on mahdollisia: normaali vanha C/C++), sitä rampauttavia (kielletty tai estetty asioiden tekeminen monesta säikeestä: python(*)/javascript), tai sitä mahdollistavia ja helpottavia: OpenMP, OpenCL, C++17n parallel algorithms.

Kääntäjien tukea asioiden rinnakkaistukselle parannetaan jatkuvasti, mutta overhead uusien säikeiden luomisessa ja niiden synronoinnissa on niin suuri, että mitään täysin automaattista uusia säikeitä luovaa rinnakkaistajaa ei kääntäjään kannata tehdä, vaikutus olisi aivan liian usein negatiivinen. Kääntäjien automaattisessa rinnakaistustuessa keskitytään enemmän siihen, että SIMD-käskykannat (SSE, AVX, AVX-512) saadaan käyttöön tehokkaasti. Ja koodaaja sitten kirjoittaa ne pari OpenMP-pragmaa niihin todella pitkiin isoihin looppeihin, jotka halutaan rinnakkaistaa myös useammille säikeille, tai luo itse ne säikeet niille rinnakkaisille korkean tason taskeille.

Ja tosiaan javascriptin ja pythonin (jotka on monisäie-vihamielisiä kieliä) käyttö on vaan jatkuvasti lisääntymässä

Jeps, eli pyritään rinnakaistukseen mahdollisimman matalalla tasolla. Ja totta myös se että noita rinnakkaistamiselle vihamielisiä tekniikoita on käytössä enemmän (lisään NodeJS:n listaan), mutta useimmiten ne oikeasti laskentatehoa tarvitsevat tarpeet koodataan sitten sille sopivalla kielellä. Javascript on joo internetin takia yleinen, mutta en sanoisi että sen takia tarvittaisiin nopeampia yhden säikeen prosessoreita.

Hyvältä näyttäminen on enemmän kiinni näyttiksen väännöstä, ei CPUn. CPU-tehoa tarvii enemmän siihen, että se pelimaailma toimii järkevästi. Ja siinä konsolipelit on keskimäärin olleet selvästi PC-pelejä jäljessä, konsolipelit on paljon yksinkertaisempia sisällöltään ja pienempiä maailmaltaan yms.

Ja intelillä on jo nyt kuluttajille markkinoilla piirejä, jotka ajaa suurempaa määrää rautäsäikeitä kuin mikään konsoli.

Konsoleilla framerate on tyypillisesti rajoitettu 60 FPSään. Tarkoittaa sitä, että vääntöä samannäköisen grafiikan piirtämiseen tarvii vähemmän kuin että PCllä haluttaisiin sama kama pyörimään selvästi suuremmalla FPSllä.

Lisäksi konsoleilla kun tiedettiin tasan tarkkaan, mikä kohdekonsolin suorituskyky on, voitiin tehdä todella paljon sellaisia optimointeja, että jos vaikka jossain tietyssä kohdassa kenttää framea ei ehdittäisikään piirtää 16.666 millisekunnissa, sitten siitä kohtaa kenttää poistetaan hiukan yksityiskohtia, tai tilapäisesti jätetään kauempana olevia kohteita piirtämättä tms. jolla saadaan se piirtäminen mahtumaan yhteen ruudunvirkistykseen.

Tai jos tiedetään, että vaikka jonkun tietyn aseen suuliekki saisi aikaan efektin jonka piirtäminen on liian hidasta, sitten yksinkertaistetaan sitä efektiä tai rendataan muuta kamaa pienemällä laadulla, kun se efekti on ruudulla.

Nyt uusien molempiin suuntiin yhteensopivien mutta erisuorituskykyisten konsolien kanssa tällaisten optimointien tekeminen menee sitten hankalammaksi.

Tämä oli se mitä hainkin eli ei käyttäjää kiinnosta onko siinä mitä optimointeja takana. Se riittää että se näyttää hyvältä ja on helppokäyttöinen. FPS-keskustelu on muutenkin välillä jopa naurettavaa. Myönnän että voin erottaa sen 30FPS/60FPS-eron, mutta tiedän kuuluvani siihen vähemmistöön jota voi ehkä kiinnostaa. Ainoat jotka jaksaa tuosta FPS-luvusta meuhkata on ne PC-master race-jannut. Laittamalla tiskiin hyvällä säkällä tiskiin viisi kertaa enemmän pennosia ostamalla hyvän peli-PC:n vs. konsoli, on lisäarvo mielestäni turhan huono. Leffat, tv ja suurin osa muu näytöllä katselemastamme liikkuvasta kuvasta on 24-30FPS-luokkaa, niin ihmisen pää saa siihen jatkuvaa siedätyshoitoa joka tapauksessa. Ja vaikka Steamin tilastot voivat johtaa harhaan, niin uskon että se ainakin pitää paikkansa että suurin osa porukasta ajelee hyvinkin keskivertokoneilla, joilla on turha unelmoida isoja FPS:iä missään uudessa pelissä.

Mutta ettei pointti nyt karkaisi kokonaan, niin mites mahdollisena näet sellaisen kehityksen jatkossa, että jotain prosessoriarkkitehtuuria suunniteltaisiin alusta lähtien niin, että saataisiin lämpö- ja väyläteknisesti laskentayksikköön yksi supernopea ydin ja sen ympärille sitten useampia vähävirtaisia apuytimiä. Vähän tyyliin Cell-, ARM-kombot ja nykyiset turbo-tekniikat, mutta vielä pidemmälle jalostettuna. Todennäköisesti sen tuhat muttaa matkalla, mutta tuli noin vain epämääräisenä ideanpoikasena mieleen.

 

[Griffin]

Jos CPU:hun halutaan lisää LASKENTA tehoa, niin säikeiden määrän kasvatus täydellisillä ytimillä on älytöntä. joko joku AVX:n tyylinen vektoriviritys /rinnakkaislaskenta tai heterogenous ytimet, jolloin "laskentaytimet" ovat paljon erikoistuneimpia ja niistä on karsittu kaikki turha pois, optimoiden samalla suorituskyky juurikin siihen laskentaan..

 

[Nerkoon]

Tästä kunnon spekulaatiot pystyyn:

Intelin prosessoreissa on kuulema massiivinen bugi, joka vaikuttaa virtualisointiin ja sitä kautta datakeskuksiin. Bugin korjaamisen (tai kiertämisen) väitetään vievän 30-35% prosessorin tehoista


Aika ostaa AMD:n osakkeita?

 

[svk]

Kyllä, jos tuo on totta

 

[svk]

amd stock value - Google-haku
Tainnut huhu jo kohottaakin osakkeitten arvoa

 

[Andy]

VIA plans their x86 comeback with AMD in their sights for 2019

Saas nähdä, pitääkö otsikkoon lisätä kolmas nimi ensi vuonna. Toivottavasti Kiinalaiset saa jotakin aikaiseksi.

 

[copter]

VIA plans their x86 comeback with AMD in their sights for 2019

Saas nähdä, pitääkö otsikkoon lisätä kolmas nimi ensi vuonna. Toivottavasti Kiinalaiset saa jotakin aikaiseksi.

Vielä kun toisi tuotteet markkinoille vanhan kunnon Cyrix brandin alla, niin johan alkaisi retrohousuja heiluttamaan.

 

[Andy]

Vielä kun toisi tuotteet markkinoille vanhan kunnon Cyrix brandin alla, niin johan alkaisi retrohousuja heiluttamaan.

Olen liian nuori, piti googlettaa.

Pitäisi saavuttaa AMD tehoissa, mutta ei tietoa tarkoitetaankoo nykyistä Ryzenia vai tulevia malleja.

 

[svk]

Ymmärsin noitten haastavan intelin gemini lake socit, eli on näyttis puolikin vielä auki.

 

[Nerkoon]

VIA plans their x86 comeback with AMD in their sights for 2019

Saas nähdä, pitääkö otsikkoon lisätä kolmas nimi ensi vuonna. Toivottavasti Kiinalaiset saa jotakin aikaiseksi.

Count me skeptical. Cyrix / VIA eivät koskaan olleet tunnettuja nopeudestaan, joten en jaksa uskoa, että se korjaantuisi maagisesti parissa vuodessa.

 

[Threadripper]

Olen liian nuori, piti googlettaa.

Pitäisi saavuttaa AMD tehoissa, mutta ei tietoa tarkoitetaankoo nykyistä Ryzenia vai tulevia malleja.

"AMD" voi tarkoittaa vaikka jotain Jaguar pohjaisia konsoliprossuja

Löysin aika suuresta summasta vetoa ettei Ryzen 4xxx:n tullessa VIA ole lähelläkään sen nopeutta.

 

[Andy]

"AMD" voi tarkoittaa vaikka jotain Jaguar pohjaisia konsoliprossuja

Löysin aika suuresta summasta vetoa ettei Ryzen 4xxx:n tullessa VIA ole lähelläkään sen nopeutta.

Onhan tuo vähän ympäripyöreää. Veikkaan, että aloittelee halvalla ja matalan kulutuksen prossulla. Niitä on sit hyvä myydä tuolla Aasiassa ja ehkä muutama tännekin eksyy.

 

[mdms]

Ei nyt niinkään riipu suoranaisesti consumer-tason tuotteisiin / käyttöön, mutta voipi olla seurauksia:

Lisähuomiona Intel's CEO Just Sold a Lot of Stock

 

[BOT]

Rehellisesti veikkaan että joku kikkailu löytyy tuon korjaamiseen ihan muuta kautta kuin prosessoritehoja kuluttamalla. Intel pitää tästä huolen, jos tällainen uhka on olemassa. Voihan se olla että rahaa kuitenkin palaa.

 

[lpto]

Ei nyt niinkään riipu suoranaisesti consumer-tason tuotteisiin / käyttöön, mutta voipi olla seurauksia:

Lisähuomiona Intel's CEO Just Sold a Lot of Stock

Ottaen huomioon että kaikki työpöytäsovellukset Linuxilla ja Windowsilla pyörii virtuaalimuistin voimin, on kaikissa niissä käyttöjärjestelmissä myös sama tietoturvaongelma. Täten patchi tulee Linuxiin ja Windowsiin myös, varmasti vaikuttaen samalla prosessoreiden tehoihin. Saanemme kohta kuulla tarkempia lukemia siitä että kuinka suuresta vaikutuksesta on kyse. Samalla hinnoittelulla AMD-prosessoreista taitaa tulla paljon kustannustehokkaampia!

Vaikka ostin juuri 8600k:n, niin omasta puolesta sen hinta saa tippua käytettyjen markkinoilla vaikka 150 euroon, jos AMD:sta tulee parempi vaihtoehto.

 

[antero]

^
Joo, täällä porukka on aivan autuaan kujalla yleisesti markkinataloudesta ja yrityksen insentiiveistä hintaa, katetta sekä liikevoittoa kohtaan. Eivät nämä Intelin tehonlisäykset ole hyvää hyvyyttään tapahtuneet vaan pakon edessä. Monopolit ovat aina umpisurkea asia ja onneksi AMD ei ole mennyt konkurssiin, joka tuntuu olevan vaikea ymmärtää tämän trollailun keskellä. En toki preferoi tuotetta sen perusteella, että mitä merkkiä tuote on, vaan tottakai käyttötarkoitus ja hinta-tehosuhde yhdessä aina asian ratkaisevat. Toivottavasti AMD pakottaa Intelin lopettamaan myös tuon piirisarjaperseilyn, josta on nyt tullut se "ihan ok juttu" -normi ja kaikki ostavat kitisemättä aina uuden emon. Maailma on pullollaan esimerkkejä, jossa määräävä markkina-asema aiheuttaa kuluttajille suurta haittaa ja siinä vaiheessa ei enää auta trollailla vaan maksaa pyydetty hinta tai ostaa kuten instagram-missit silarinsa: osamaksulla.

Eikä olla kaukana tilanteesta, että emolevyn ei tarvitse olla yhtä kestävä kuin nykyisin. Emolevyvalmistajat varmaan jo kaipaa kiinalaisia kondensaattoreita (nekin nykyään liian hyviä)

Olen liian nuori, piti googlettaa.

Pitäisi saavuttaa AMD tehoissa, mutta ei tietoa tarkoitetaankoo nykyistä Ryzenia vai tulevia malleja.

Veikkaan että sillä tarkoitetaan vastaavalla nopeudella, nuo on nyt 2GHz prossuja, eli aika paljon heikompia nykyisiin huippumalleihin verrattuna.
Tärkein asia tuossa on kiinalaisille USA:n vakoilun puuttuminen prosessoreista.

 

[hupiukko]

'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign

 

[TheMeII]

'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign

"The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers."

 

[copter]

Lukaistuani tuon artikkelin, niin onhan tuo ihan oleellinen bugi. Mitä tuon korjaaminen sitten suorituskyvyssä maksaa loppupelissä, niin sitä on vaikea sanoa. Hieman vaikuttaisi siltä että Intel on oikonut kulmia suorituskyvyn nimissä.

Jos jostain syystä myös desktop puolelle tulisi performance impactia, niin jättääkö porukka tuon päivityksen ajamatta korkeamman FPS luvun takia?

 

[antero]

Aika paha kolaus Intelille tuo vika, tosin normaali kuluttaja ei sitä huomaa kun korjaus/hidastus tulee ohjelmistoon.
Mutta missä vaiheessa alkaa Inteliltä tulla korjattuja prossuja?

 

[Threadripper]

Mutta missä vaiheessa alkaa Inteliltä tulla korjattuja prossuja?

Riippuu siitä kuinka syvälle prosessorissa joudutaan menemään korjauksen kanssa. Noin 5 kuukautta menee vaikka korjaus saataisiin tehtyä tänään. Kuulostaa siltä ettei ihan pikkufiksaus auta jolloin realistinen arvio on luokkaa vuosi.

 

[antero]

Ajattelinki että taitaa tulla vasta seuraavassa sukupolvessa.

 

[Griffin]

Aika paha kolaus Intelille tuo vika, tosin normaali kuluttaja ei sitä huomaa kun korjaus/hidastus tulee ohjelmistoon.
Mutta missä vaiheessa alkaa Inteliltä tulla korjattuja prossuja?

Yleinen 30%:n suorituskyvyn lasku Intelille olisi kilpailun kannalta hyvä asia. Se muuttaisi AMD:n prossut vähän hitaammasta vähän intelin prossuja nopeammiksi, eli ryzenin suorituskyky olisi VS kilpailija sitä, mitä sen olisi pitänyt alunperin olla, että kyseessä olisi ollut "välttävän" julkaisun sijasta "hyvä" julkaisu.

Toivottavasti I/O techissä ajetaan kunnon testit, kun tuo pätsi saadaan joskus ulos.

 

[Nerkoon]

Lukaistuani tuon artikkelin, niin onhan tuo ihan oleellinen bugi. Mitä tuon korjaaminen sitten suorituskyvyssä maksaa loppupelissä, niin sitä on vaikea sanoa. Hieman vaikuttaisi siltä että Intel on oikonut kulmia suorituskyvyn nimissä.

Jos jostain syystä myös desktop puolelle tulisi performance impactia, niin jättääkö porukka tuon päivityksen ajamatta korkeamman FPS luvun takia?

Windows päivitykset ovat nykyään kaikki tai ei mitään, joten siinä ei paljon valikoida

 

[copter]

Windows päivitykset ovat nykyään kaikki tai ei mitään, joten siinä ei paljon valikoida

Kyllähän noita yksittäisiä updateja pystyy poistamaan ja myös blokkaamaan, ettei tule sama poistettu update seuraavan päivityksen yhteydessä.

 

[Nerkoon]

Jos tuo Intel bugi ja sen korjauksen tuoma nopeushaitta pitää paikkansa, niin voi täälläkin kovimpien Intel fanaatikkojen e-penis lerpahtaa kun jopa 30% vauhdista katoaa alta.

Netissä oli spekulaatiota, että Intel olisi nopeusedun toivossa oikonut suunnittelussa ja että prosessori ei tekisi kaikkia tarkistuksia mitä oikeasti pitäisi.

 

[antero]

Kyllähän noita yksittäisiä updateja pystyy poistamaan ja myös blokkaamaan, ettei tule sama poistettu update seuraavan päivityksen yhteydessä.

tarkoitti varmaan että jos tulee näiden 100-200MB pakettien mukana, niin silloin on kaikki kuukauden päivitykset jätettävä laittamatta.

 

[Threadripper]

Netissä oli spekulaatiota, että Intel olisi nopeusedun toivossa oikonut suunnittelussa ja että prosessori ei tekisi kaikkia tarkistuksia mitä oikeasti pitäisi.

Tuossahan se: LKML: Tom Lendacky: [PATCH] x86/cpu, x86/pti: Do not enable PTI on AMD processors

AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.

 

[mRkukov]

'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign

Ei kyllä todellakaan kuulosta hyvältä. Toivottavasti korjaus ei vaikuta turhaan amd prossuihin. Lähinnä se että tehdään todella isoja muutoksia -> vaara että jotain hajoaa.

Tuo 5-30% on kyllä aika iso droppi. Saas nähdä miten tämän intel vs amd kisan oikein käy. Voisi kuvitella että epyc prossut olisi entistä kovemmalla kysynnällä palvelinkeskuksiin.

 

[mRkukov]

@Sampsa / @Kaotik uutista etusivulle?