Új hozzászólás Aktív témák

• #16 Meteorhead aktív tag joghurt #4

  Új Válasz 2019-03-18 14:18:41 #16

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Meteorhead

  aktív tag

  válasz joghurt #4 üzenetére

  A mihez tartás végett, igen, lehetne ezekre speciálisan fordított rendszer binárisokat használni, de ezt annyira macerás lekezelni, hogy egyetlen épeszű OS/disztribúció sem teszi meg. (Igen, a Gentoo Linux ami a kernelt és minden vackot a /march:native-vel fordít nem számít fenntartható/épeszű megoldásnak.) A kernelben a Spectre és társaihoz tartozó egyedi kódok futásidőben vannak ki/be-kapcsolva, de ezek nem lassítják le szignifikánsan a gépet.

  Egy x86 elágazás becslője 10-14 egymásba ágyazott elágazáson még triviálisan átlát, ha az nem változik. Egy szénné tuningolt binárisban egy sima for ciklusra is 3-4-5 változat generálódik: egy ha rövid a ciklus, egy ha pont 3 hosszú, egy ha néggyel osztható, egy AVX-es, egy több szálú... és futásidőben választódik ki, ami épp a legmegfelelőbb az adott ciklushosszhoz. PGO (Profile Guided Optimization) ezeket a tippeléseket tüntetni el.

  A kernelben is van egy csomó architektúra specifikus választás egyes megoldások között, de ezek sosem változnak és az elágazás becslő baromi gyorsan megtanulja ezeket és utána nincs látható hatása. Akkor van baj, ha ezek futásidőben (gyakran) változnak, de a CPUID nemigen szokott változni (ha nem valami skizoid procit használtok).

• #5 Cythyel senior tag joghurt #4

  Új Válasz 2019-03-18 12:53:01 #5

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Cythyel

  senior tag

  válasz joghurt #4 üzenetére

  pedig patch telepítésekor egy cpu_id ellenőrzéssel simán meg lehetne oldani hogy amd-re ne másszon fel...

Új hozzászólás Aktív témák