Et taida omata juurikaan kokemusta ohjelmoinnista. Annatko jonkun koodiesimerkin, vaikka Intelin ringille ja AMD:n SDF:lle optimoiduista koodista? Ei tarvitse olla omaa koodia, voit käyttää vaikka Githubia yms. lähteenä. Kunhan eri "optimoinneilla" saadaan huomattavia tai merkityksellisiä eroja aikaan, silloin kun sitä suoritetaan epänatiivilla ja -natiivilla alustalla.
Se nimenomaan ei ole optimointia.
Sekoitat bugien korjaamisen (todennäköisesti scheduloinnissa), optimoimiseen.
Tuolla logiikalla puhjenneen autonrenkaan vaihtaminen ehjään olisi optimointia.
Lähtökohtana näissä väitteissäsi tuntuu olevan joku ajatus, että kaikki ohjelmisto ja pelikehittäjät olisi jotenkin AMD:ta vastaan.
Intelillä on älyttömästi rahaa ja vaikutusvaltaa, muttei läheskään niin paljon, että se pystyisi ostamaan tai edes vaikuttamaan jokaiseen ohjelmisto- ja pelikehittäjään saati koodia omaksi ja muiden iloksi tuottavaan koodariin. Lisäksi monella tuntuu olevan koodioptimoinnista vähän turhan ruusuinen kuva. AMD:n ja Intelin prosessorit suorittaa identtistä x86-64 koodia.
Jos kyseessä on joku laskentakriittinen pätkä koodia, niin se suurimmassa osassa tapauksia kirjoitetaan suoraan assemblylla. Ja ellei jossain koodia suorittavassa prosessorissa ole joku harvinainen käsky valtavasti hitaampi esim. mikrokoodisuorituksen takia, niin kukaan ei varmasti lähde kirjoittamaan vaihtoehtoisia koodipolkuja, samoja käskykantoja tukeville eri valmistajan prosessoreille. Puhtaasti siksi, että assemblyn kirjoittaminen on erittäin hidasta ja varsinkin siksi, ettei siitä ole mitään hyötyä.
Intelin viime vuosikymmenen alkuun ajoittunut porsastelu oman kääntäjänsä kanssa oli asia erikseen (Kaotikan viittaus).
Tässä tapauksessa Intelin kääntäjä rampautti kilpailijoiden (suoraan AMD ja Cyrix kohdennettu) prosessorien suorituskykyä valmistajatunnuksen lukemiseen perustuvalla "polunohjauksella". Ongelma ei ollut siinä, että kääntäjä olisi tehnyt näin jollain Intelin prosessoreja kohdentavalla käännös-optiolla, vaan sillä, että se teki niin kaikilla asetuksilla.
Eli jos yksityishenkilö tai ohjelmistokehittäjä käänsi kyseisellä kääntäjällä pätkän koodia, niin kääntäjä teki binääreihin kaksi vaihtoehtoista polkua: Käyttäjän määrittämällä yleisoptimointi (esim. Ox) ja käskykantatuella (esim. SSE4.1) / -tasolla annetun koodipolun, jota suoritettiin kun prosessorin CPUID palautti valmistajatunnuksen "GenuineIntel" ja toisen, pelkkää SSE2 tukeen rajatun koodipolun, jota suoritettiin silloin kun prosessori palautti joko "AuthenticAMD" tai "CentaurHauls" / "CyrixInstead" valmistajatunnuksen. Tämä kuvattu porsastelu päättyi oikeusjuttuun ja nykyisin Intelin kääntäjä optimoi koodin Intelille, tai luo vaihtoehtoiset koodipolut vain silloin kun käyttäjä niin erikseen määrittää. Esimerkiksi pelin binäärin optimoinen suoraan Intelin prosessoreille, käyttäen kyseistä kääntäjää ei nykyisin ole mahdollista, ellei pelikehittäjä halua vartavasten rajata asiakaskuntansa Intelin prosessorin omistaviin. Geneerisillä oletusasetuksilla tuotettu koodi on optimointien osalta linjassa Microsoftin kääntäjien kanssa, johon Intelin kääntäjä-suite onkin periaatteessa ainakin Windows-alustalla pelkkä laajennos.
Ja tuossa ylläolevassa tarinassa on huomioitavaa se, että noilla sikailu-kääntäjillä käännetty koodi ei ollut huomattavasti suorituskykyisempää Intelillä minkään maagisten (ja sinun jatkuvasti glorifioimien) optimointien vuoksi, vaan siksi että se "ei optimoitu" koodipolku jota muut, kuin Intelin valmistamat prosessorit suoritti oli tietoisesti rampautettu.
Suurinosa näistä "Intel optimoinneista", jota tietyt henkilöt täällä näkevät sänkyjensä alla öisin johtuvat ihan puhtaasti AMD:n tekemistä ratkaisuista.
Ratkaisuista, tai paremminkin kompromisseistä, jotka on jouduttu tekemään siksi, ettei AMD:lla ole ollut taloudellisien seikkojen takia samaa luksusta suunnitella useampaa arkkitehtuuria eri segmentteihin, kuin Intelillä.
Siksi AMD:n käyttämät ratkaisut on olleet se parhaaksi nähty kompromissi kaikissa segmenteissä. Ja se mikä antaa esim. serveripuolella hyvän tai ainakin tyydyttävän tuloksen, voi kuluttajapuolella ajettavissa kuormissa olla melko surullista katsottavaa.
Yksi kohtuullinen parannus tiettyyn käytökseen on väitetysti ilmestymässä seuraavan sukupolven Ryzen-prosessoreihin, CCX:n kohdennettujen muutosten muodossa. Tosin tässäkin tapauksessa kyse lienee puhtaasti siitä, että vanhatkin binäärit muuttuu yössä paremmin AMD:lle optimoiduksi,
eikä suinkaan siitä että AMD olisi korjannut, tai ainakin vähentänyt jonkun
itse arkkitehtuurissa olevan heikkouden aiheuttamaa vaikutusta
Jatkan mielelläni keskustelua aiheesta, mutta en tiedä onko tämä nimenomainen ketju oikea paikka tehdä niin.
