• [^] # Re: HT et performances...

    Posté par . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed. Évalué à 3.

    Comme souvent, les performances dépendent du cas envisagé pour la comparaison.

    Oui, mais lesquels sont à envisager ?

    Je l'ai désactivé sur la présente machine.
    Un iquelquechose avec 2*2 cœurs qui fait tourner un FreeBSD

    Je n'ai pas grand chose pour faire des mesures, mais, dans son usage classique (bureautique, web et Battle for wesnoth), je ne vois aucune différence, si ce n'est un temps de démarrage plus lent.

    Dans son autre usage, compilation et construction de paquets et de systèmes, j'ai pu mesurer les écarts sur un build complet:

    • Avec: 1h20
    • Sans: 1h30

    Rien de spectaculaire.

    Il reste à le voir lorsque que joue avec la virtualisation; mais ce n'est pas la machine idéale pour ça de toute façon.

    En ce qui concerne un usage serveur, je n'ai pas les moyens de faire ces tests.

    L'hyper threading est positif pour les performances sur de nombreux cas, c'est pour cela qu'il est activé par défaut, ils sont pas idiots à ce point.

    J'ai quand même l'impression que son bénéfice est surestimé.
    Le beau discours marketing a eu son rôle à jouer dans l'activation par défaut plus que les benchmarks, AMA.
    Ensuite, si le défaut sécurité et d'isolation entre processus est le prix à payer pour ces gains de performances, on peut aller encore plus loin.C'est le message de conclusion.

    Vivement les détails sur cette faille en tout cas.

    Oui, mais on en saura pas plus avant août et la conférence Black Hat, AMA.

    Impacte-t-elle uniquement Intel ? Est-ce corrigeable par le microcode ?

    Bonne question.Seul Intel emploie ce terme.

    Le même principe serait-il exploitable contre du SPARC ou du POWER ?

    Pourquoi pas après tout ? Ils sont sensibles à Spectre et proposent du SMT ...
    Et la technique utilisée semble être celle de Spectre si j'en crois les indices laissé par Colin Percival.