Harvoin pelkkä kääntäjäflagi tuottaa halutun lopputuloksen.
Ei pelkästään. Kääntäjävipu on kuitenkin tärkeä sen takia, että järjestelmässä voi olla kymmeniä tai satoja tuhansia binäärejä, joiden käskysisällöstä ei pysty sanomaan paljon mitään enää varmuudella kääntämisen jälkeen. Siellä todennäköisesti voi olla kaikkia niitä käskyjä, joita joku optimointi voi tuottaa. Tämän lisäksi on sitten valikoitu joukko niitä ohjelmia, joihin on käsin koodattu optimoinnit. Katoin esim. omasta systeemistäni läpi ja popcnt näkyy erityisesti kielten runtime-kirjastossa (esim. python, wasm, qt), konenäköjutuissa ja video-, audio- ja grafiikkafilttereissä. Kyllähän se koneen käyttö menee aika vaikeaksi jos nuo alkavat vaatia niitä käskyjä, mutta setti on vielä ihan hallittavissa, jos haluaa itse säätää ja kääntää. Ja vaikkei säätäisi vaan ajaa sitten vaikka vanhaa Pythonia, sen käyttiksen päivitykset voivat auttaa osaltaan tietoturvan kanssa. -- Mutta tosiaan, sen jälkeen kun loppukäyttäjän sovellusohjelmat alkavat ottaa jotain uusia käskyjä käyttöön, aletaan olla aika jumissa vanhan kanssa.
Mitä tulee tuohon ylläpidettävyyteen, tiukasti optimoitavissa ohjelmissakin on hyvä pitää käsin optimoimaton koodipolku sen takia, että voi helpommin testata, toimiiko jokin uusi optimointi oikein (kääntäjissäkin on bugeja). Vanhoja assyversioita voikin pudottaa tai arkistoida jonnekin päin nettiä harrastajille, mutta "selkokielinen versio" on hyvä jättää aina. Se selkokielinen on juuri se versio, jonka voi käännösvivuilla optimoida laajemmin (ainakin jos arkkitehtuuri ja bittisyys säilyy) tai optimoimattomana ajaa tosi vanhallakin laitteistolla. Se myös toimii ekana versiona jos porttaa uudelle alustalle jotain (esim. Apple silicon).
Luulen että myös aliarvioit ylläpidon kustannukset, etenkin suhteessa siihen rahavirtaan mitä core2 prossujen käyttäjät microsoftille tuo
Epäilen, tuottavatko vähän uudemmatkaan enää Microsoftille juuri tuloja. Noita vanhoja laitteita ja ohjelmistoja tuetaan viimeiset ajat luultavasti tappiollisesti ja pr-syistä. 10 vuottakin on muualla kuin teollisuudessa pitkä aika jos miettii myytäviä tukisopimuksia ja ohjelmakytkyjä.
Red Hat harkitsee seuraavaan RHEL:iin vaatimukseksi x86-64-v3:
Exploring x86-64-v3 for Red Hat Enterprise Linux 10 | Red Hat Developer
(A) ylläpito kustantaa, (B) muillekin kuin Microsoftille (esim. pelistudiot) ja (C) peruskäyttäjä ei osaa valikoida.
Näinhän se on. Kyllä nuo käskykantojen vaatimukset monesti ovat ihan hyviä optimointien kannalta. Niissä on lähinnä se, että ne eivät ole mitenkään pakollisia. Esim. 64-bittisyyteen siirtyminen oli tavallaan pakko, kun ison muistiavaruuden emulointi 32-bittisellä menee hankalaksi. Myös Y2038K on aika paha. Uusilla käskyillä taas tärkein vaikutus on suorituskyky ja jos käyttäjällä on halua odottaa, niin se on ihan tehtävissä. Monesti ne optimoinnit on juuri sellaisia, että vaikka 10 petatavun raid-pakkoja säätävät haluavat jotkin crc32-tarkistukset ja aes-kryptaukset nopeammiksi. Sitten jos core2quad-käyttäjällä on 10 teratavun pakkoja vain, niin ne hitaatkaan käskyt eivät tunnu paljon missään. TPM-jutut on vähän samanlainen, että viihdeteollisuus tai joku organisaatio voi haluta niitä, mutta ei välttämättä loppukäyttäjä. Voi olla mukavampi jos päätös tehdään lähempänä sitä loppukäyttäjää. fTPM-toteutuksissa on esim. AMD:llä ollut firmware-ongelmiakin.