Virallinen: AMD vs Intel keskustelu- ja väittelyketju

  • Keskustelun aloittaja Keskustelun aloittaja Sampsa
  • Aloitettu Aloitettu
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.
 
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
 
Viimeksi muokattu:
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
 
[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]
 
Viimeksi muokattu:
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.
NPh6jzo.jpg


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.
 
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..
 
Viimeksi muokattu:
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?
 
Vielä kun toisi tuotteet markkinoille vanhan kunnon Cyrix brandin alla, niin johan alkaisi retrohousuja heiluttamaan. :rofl:

Olen liian nuori, piti googlettaa. :D

Pitäisi saavuttaa AMD tehoissa, mutta ei tietoa tarkoitetaankoo nykyistä Ryzenia vai tulevia malleja.
 
Ymmärsin noitten haastavan intelin gemini lake socit, eli on näyttis puolikin vielä auki.
 
Olen liian nuori, piti googlettaa. :D

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

"AMD" voi tarkoittaa vaikka jotain Jaguar pohjaisia konsoliprossuja :smoke:

Löysin aika suuresta summasta vetoa ettei Ryzen 4xxx:n tullessa VIA ole lähelläkään sen nopeutta.
 
"AMD" voi tarkoittaa vaikka jotain Jaguar pohjaisia konsoliprossuja :smoke:

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.
 
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.
 
^
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. :D

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.
 
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?
 
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?
 
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.
 
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.
 
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
 
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ä.
 
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.
 
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.

upload_2018-1-2_23-26-34.png

upload_2018-1-2_23-27-49.png
 
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.
 
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.
 
Kysymys kuuluu, että kuinka vanhoihin prossuihin tuo bugi oikeen vaikuttaa ja mitkä on vaikutukset normikäyttäjälle?
 
Vittu, eli käytännössä kaikkia Bloomfieldeistä eteenpäin?
Koskas se Ryzen+ tulikaan myyntiin? :beye:
 
Joo nyt kyllä haiskahtaa siltä että on tulossa melkoinen rytky. Olisi kiva olla kärpäsenä katossa madmaxin thunderdomessa. :D
 
No sepä. Jos tuo 5-30% hidastus kaikkeen pitää paikkaansa niin ei ole kyse mistään pikkujutusta. :D

Ei ole kaikkeen.

Kernel-kutsut hidastuvat moninkertaisesti, mutta suurin osa koodista on muuta kuin kernel-kutsuja, joten keskimäärin hidastus on tuo 5-30%.

Jos koodi vaan laskee jotain jo muistiin ladatulla datalla, eikä mitään IOta tehdä eikä muisti lopu kesken että tarvitsisi swapata mitään,
hidastus tuosta on silloin käytännössä täysin olematon, kun ei niitä kernel-kutsuja tule juuri yhtään. Mutta ainahan se data pitää jostain saada laskettavaksi ja laskennan tulokset lopussa dumpata johonkin, ja ne vaiheet hidastuvat ainakin.

Ja sitten kun sitä IOta tehdään paljon, erityisesti jos se tehdään pienissä paloissa, tuo alkaa sattumaan selvästi.


Eli siis on erittäin tapauskohtaista, että paljonko tuo sattuu. Palvelinkäytössä kuitenkin pahempi kuin työpöytäkäytössä.
 
Jaha, EPYCin kilpailukyky taisi juuri nousta ihan uudelle tasolle
Ainakin fileservereissä todella iso hitti...
Mites nuo pienet kotikäyttöön tehdyt nassit? Niissäkin nopeudet puolittuu (olettaen että joskus saavat päivityksen)? :D
 
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.
Taitaa eräillä AMD- fanaatikoilla nousta pystyyn.

Kyse on vain palvelimista ja pilvestä:

"There are ominous signs that Intel may be secretly fixing a major security vulnerability affecting its processors, which threatens to severely damage its brand equity among datacenter and cloud-computing customers".

Intel Secretly Firefighting a Major CPU Bug Affecting Datacenters?
Jaha, EPYCin kilpailukyky taisi juuri nousta ihan uudelle tasolle
Tarvittaessa Intel tarjoaa pari ilmaista prossua ensi hätään, ettei ole mitään syytä vaihtaa AMD Epyc: iin.:)
6CbQ7MM6AAnwsu9l_thm.jpg
 
Jahas, ensimmäinen intel fanaatikko heräsi. :D

Toivottavasti korjaus ei vaikuta turhaan amd prossuihin. Lähinnä se että tehdään todella isoja muutoksia -> vaara että jotain hajoaa.
Tämä on se mitä pelkäsinkin:
Update, 10:56 PM - 1/2/18 - As it turns out, apparently the Linux patch that is being rolled out is for ALL x86 processors including AMD, and the Linux mainline kernel will treat AMD processors as insecure as well. As a result, AMD CPUs will feel a performance hit as well, though the bug only technically affects Intel CPUs and AMD recommends specifically not to enable the patch for Linux. How Microsoft specifically will address the issue with the Windows operating system remains unclear until the company's formal Patch Tuesday update is made known, hopefully soon
Huge Intel CPU Bug Allegedly Causes Kernel Memory Vulnerability With Up To 30% Performance Hit In Windows And Linux | HotHardware

Edit:
Ilmeisesti pieni patch riittää ja amd prossut jää hidastuksen ulkopuolelle. :)
 
Viimeksi muokattu:
Eli juuri siitä tuoteryhmästä, missä isot rahat liikkuu. Ja onko intel joskus antanut prossuja ilmaiseksi tälläisistä syistä ennenkin?
Edellisen kerran kun amd oli lähellä/edellä tehoissa. Makso konevalmistajille siitä etteivät osta amdeetä tai inteliä pitää olla 90% tms.
 
Edellisen kerran kun amd oli lähellä/edellä tehoissa. Makso konevalmistajille siitä etteivät osta amdeetä tai inteliä pitää olla 90% tms.

Näin kuulema pena nelosen aikana, mutta siis jos suorituskyky laskee syystä X?
 
Näin kuulema pena nelosen aikana, mutta siis jos suorituskyky laskee syystä X?
Taitaa olla ensimmäinen kerta kun näin isoa droppia tulee näin laajalti kaikkeen. Viallisia prossujahan on kyllä vaihdeltu uusiin, mutta nyt vika on niin laaja, ettei varmasti tule uutta rautaa vanhan tilalle. Siinä olisi jopa intel konkassa. :D Siksihän tuo korjauskin tehdään nyt softatasolle. Rauta on rikki eikä varmasti tule korjautumaan.

Mielenkiinnolla kyllä odotan mitä tästä tulee. Miten Intel reagoi ja millaisia (mahdollisia) korvauksia aiheuttaa. Eiköhän tästä useampia oikeustapauksia tule. :)
 

Statistiikka

Viestiketjuista
295 812
Viestejä
5 052 383
Jäsenet
80 985
Uusin jäsen
davids

Hinta.fi

Back
Ylös Bottom