Ezzel kb azt mondod, hogy semmilyen benchmarknak nincs semmi értelme.
Konkrétan a SPEC-et én sem szeretem, mert egy vagyont kérnek el hogy a teszthez egyáltalán hozzáférhess. Vannak bőven ingyenes alternatívák és kevésbé is vannak kitéve a gyártók "szűk-területű optimalizálásainak". Ráadásul a SPECCPU2017 már vén mint az országút és azóta nem frissítették. Ettől függetlenül érthető, hogy miért létezik és szerintem _anno_ volt ráció abban, ahogy össze lett állítva. Szempont volt, hogy valós használatban is releváns szoftverekből álljon össze.
Van itt: perlbench, gcc, x264, exchange, xz, povray, blender, imagemagick, ezek amiket kapásból felismerek név alapján. Van mégegyszer ennyi, aminek utána kell néznem, hogy melyik mire is jó.
Itt is ellentmondó dimenziók mentén kell optimalizálni. Minél hosszabb ideig változatlan (lerögzített verziókkal szereplő teszt-alkalmazások) annál szélesebb körben maradnak összehasonlíthatóak az eredmények. Viszont idővel annál kevésbé lesz releváns, a suite-ban lerögzített 2017 előtti szoftververziókat mára nyilván senki nem használja. És persze minél hosszabb ideje változatlan, annál könnyebb és vonzóbb célpont a gyártóknak, hogy valahogy forge-oljak az eredményt.
Ami sajnos nincs részletezve, hogy technikailag pontosan mi is volt az "optimization with very narrow applicability".
Ha csak úgy általában az Apache Xalan-ra ráreszelték a fordítót, akkor lehet lamentálni, hogy etikus-e, de végülis mindenkinek előnye származhat belőle, aki xalan könyvtárat használ valahol a szoftverében függőségként.
Ha viszont azt csinálták, hogy a Xalan-ra pont azokat (és csak azokat) a teszt-adatokat futtatták be, amik a SPEC CPU benchmarkban vannak, a futását rögzítették egy profilerrel és az ebből készült statisztikát kötötték vissza az ICC-be, akkor nagyobb genyóság van. Mert ez az optimalizálás nemcsak a szoftverre, hanem a tesztadatra is specifikus lesz.