Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 25 sur 26 PremièrePremière ... 1517181920212223242526 DernièreDernière
Affichage des résultats 721 à 750 sur 764
  1. #721
    Citation Envoyé par newbie06 Voir le message
    Oui bien sûr, et quand les dév en auront marre de devoir coder 10 variantes, ils arrêteront juste de supporter les nouveautés
    Genre tu crois vraiment que ce sont des devs hors d'Intel qui ont ecrit le code AES de tout ce qui est accelere par les nouvelles instructions ? La seule chose que le Dev a a faire est de prendre une librairie preecrite et creer (tester CPUID) un codepath pour. Si ils ne veulent pas maintenir ce codepath pas de problemes, mais leur competition le fera.

    PS: IP sur le cote ou instruction specialisee il te faut de differents codepath de toutes facons... et tu utilises une lib preecite dans tous les cas...
    fefe - Dillon Y'Bon

  2. #722
    Citation Envoyé par newbie06 Voir le message
    Oui bien sûr, et quand les dév en auront marre de devoir coder 10 variantes, ils arrêteront juste de supporter les nouveautés

    ---------- Post ajouté à 19h20 ----------


    Je partais du postulat que l'AES était utilisé en streaming et sur des blocs pas tout petits. Si ce n'est pas le cas, je renvoie à ma question initiale du pourquoi l'absence d'une mul 64-bit efficace qui accélèrerait RSA
    Pour arriver aux memes perfs (et dans la meme energie), quelle devrait etre la latence et la capacitance de ton mul ? Je penses que la reponse a ta question est la meme que celle a la mienne. Tu ne peux pas faire un mul 64 bits a un cycle de latence a 3.5GHz qui consomme moins qu'un mul actuel, donc tu utilises une inst specialisee qui est plus efficace energetiquement et a les memes proprietes d'integration a du code existant (la latence entre utiliser ces instructions et d'autres est negligeable compare a faire appel a un bloc IP).
    fefe - Dillon Y'Bon

  3. #723
    Une latence de 1 est en effet bien difficile à atteindre avec un coût raisonnable, mais de là à nécessiter 10 cycles pour la partie haute, ça fait beaucoup. AMD le fait en 5 cycles et cela explique pourquoi sur la plupart des algos utilisant des grands nombres, AMD est toujours devant (hors exception particulière de GIMPS qui utilise des flottants).

    Quant à la fragmentation, on doit donc penser que ce que dit Agner Fog est du BS ? Ou que je suis un idéaliste qui préfère éviter d'utiliser des libs dont le source n'est pas dispo ? Mais je suis d'accord avec toi, même une IP poserait des soucis, et bien plus pénibles que de devoir programmer avec quelques instructions supplémentaires.

  4. #724
    Agner Fog a plutot raison, parce que tous les ans tu dois ajouter une code branch et il y a un moment ou un autre ou ca devient trop lourd meme si c'est du code de librairie qui tourne dans ces branches. La ou il a completement raison est que tu multiplies ca par le nombre de constructeurs, et la ca n'a vraiment aucun interet, c'est du gachis stupide, alors que sinon c'est de la complexite mais souvent faible en regard des benefices.

    Avoir une code branch pour AMD, une pour intel pour faire la emem chose c'est complexite x2 pour 0 benefices. Je pense que c'est vraiment ce point ou Agner a raison et qu'il faut faire qq chose.
    fefe - Dillon Y'Bon

  5. #725
    Sous nux, les algos de chiffrement haute perf ne vont-ils pas à peu près tous taper openssl ? Dont les contributeurs majoritaires sont les dingues de l'équipe de Theo ... et Intel, me goure-je ?

    Sous windows, on va pas taper une lib' omniprésente du genre ?

    Edit : Merde, j'ai oublié GPG... Je sais pas qui sont les contributeurs de gpg.
    Mes propos n'engagent personne, même pas moi.

  6. #726
    Ha ? http://www.openssl.org/about/
    Theo (de Raadt je suppose) n'est qu'un contributeur mineur, non ? Les autres sont peut-être liés à lui remarque. En tout cas, Intel ne participe pas officiellement.

  7. #727
    Euh, si ma mémoire ne me joue pas de tours, on doit le correctif pour que les branches fassent le même temps (attaque chronomètre) à Intel. Et celui exploitant potentiellement la prédiction de branchement, à l'époque, Intel avait immédiatement dit "OK, je bosse dessus"
    Mes propos n'engagent personne, même pas moi.

  8. #728
    Tu admettras que c'est un peu different que d'etre un "contributeur majoritaire"

    Au fait OpenSSL support AES-NI. Quelqu'un a une machine compatible ?

  9. #729
    Citation Envoyé par newbie06 Voir le message
    Tu admettras que c'est un peu different que d'etre un "contributeur majoritaire"

    Au fait OpenSSL support AES-NI. Quelqu'un a une machine compatible ?
    Oui le contributeur quasi-inexistant.
    Mes propos n'engagent personne, même pas moi.

  10. #730
    T'es assez binaire toi

  11. #731
    Citation Envoyé par newbie06 Voir le message
    T'es assez binaire toi
    Ouais...

    Mais j'ai trouvé qu'une seule contribution (ok, ya pas mal de ligne, mais ça fait toujours que un), du coup j'en conclue qu'ils contribuent BEAUCOUP moins que je ne le pensais.
    Mes propos n'engagent personne, même pas moi.

  12. #732
    Non, y'a plus de contributions d'Intel que ca. Notamment l'AES-NI. Sauf que les mecs qui font les commit, des fois ils ne mettent que le nom et pas le mail, donc pas toujours facile de trouver qui fait quoi. Pour un truc dont le but est la securite, je trouve ca extremement limite.

  13. #733
    Ben après, si c'est une short team Intel, leur nom sont probablement connu de la core team.

    Et en principe, les droits de commit ne sont pas attribué à n'importe qui, si ?
    Mes propos n'engagent personne, même pas moi.

  14. #734
    Ben disons que pour que je comprenne qui etait un certain type, j'ai du chercher sur le Web. Aucune information sur le serveur Web d'OpenSSL, ni dans les logs CVS. Niveau tracabilite ca me parait un peu leger, parce qu'un tel soft doit etre evalue de l'exterieur, pas par la core team. Enfin c'est comme ca que je vois les choses

    EDIT : par exemple sur le kernel ou QEMU, les commits sont du genre:
    Signed-off-by: le vrai nom de newbie06 <newbie06@gmail.com>
    Acked-by: ...

  15. #735
    Euh... Le soft, oui, pas ses dev. Et les commits ne sont pas furtifs obfuscé, juste ils sont mal renseignés niveau origine.

    C'est comme sur un forum : pas besoin d'un cv pour que les propos soient pertinents.

    EDIT : ben ya leur vrai nom...
    Dernière modification par Neo_13 ; 09/02/2010 à 12h31.
    Mes propos n'engagent personne, même pas moi.

  16. #736
    Je trouve l'e-mail utile pour deux raisons :
    - on sait comment me contacter
    - ca me permet de distinguer ce que je fais pour mon employer de ce que je fais en tant qu'individu.

  17. #737
    Citation Envoyé par newbie06 Voir le message
    Je trouve l'e-mail utile pour deux raisons :
    - on sait comment me contacter
    - ca me permet de distinguer ce que je fais pour mon employer de ce que je fais en tant qu'individu.
    S'ils font pas ça de manière "officielle", ils mettront pas un e-mail intel, donc le résultat est le même...

  18. #738
    Oui mais s'ils font ca a titre perso, on ne peut pas considerer que c'est Intel qui le fait, ce qui etait le point initial

  19. #739
    Mouais, quand je vois comment fonctionnent certaines grosses boites US, j'ai l'impression qu'il y a une espèce de zone grise: c'est pas officiel dans le sens où la boite ne souhaite pas communiquer dessus, mais c'est fait avec les ressources de l'entreprise, au titre de leur taf', donc pas vraiment perso non plus.

  20. #740
    Je ne sais pas comment ça se passe ailleurs, mais chez nous c'est le contraire : si tu veux travailler sur de l'open source à titre perso chez toi, tu dois demander l'autorisation...

  21. #741
    Moi je fais tourner du Perl avec plein de regexp sur un Core i7. Est-ce que ça tire partie des instructions de string processing de SSE 4.2?
    Je soupsçonne que non.

    Pour la libc, google suggère que c'est le cas à partir de la 2.11...

  22. #742
    Citation Envoyé par Møgluglu Voir le message
    Pour la libc, google suggère que c'est le cas à partir de la 2.11...
    En effet :
    Code:
    002f7ba0 <__strstr_sse42>:
    ...
      2f7c2f:       66 0f 3a 63 ca 0c       pcmpistri $0xc,%xmm2,%xmm1
    Maintenant je suis bien incapable de dire comment la sélection de cette fonction se fait.

  23. #743
    Citation Envoyé par newbie06 Voir le message
    Maintenant je suis bien incapable de dire comment la sélection de cette fonction se fait.
    J'ai l'impression que c'est au chargement (de la libc? du process?) que la sélection se fait, et une redirection est faite en modifiant le pointeur vers la fonction strstr dans le stub associé.

    Mais bon, sur ma Debian j'ai la 2.10, et quand la 2.11 sera dans la testing j'aurai plus accès à cette machine.

  24. #744
    Et pour la version statique de la lib ? On se tape une indirection de plus ? Bon, ça vaut peut-être le coût

  25. #745
    Sur un processeur moderne ca te coute combien un branchement predit pris additionnel (bien predit)?
    fefe - Dillon Y'Bon

  26. #746
    La réponse est facile. L'autre question associée est : quelle est la probabilité que ce saut additionnel entre en collision avec un autre dans les tables de prédiction ? La réponse est plus dure, non ?

    Mais je suis d'accord avec toi, le sur-coût est faible

  27. #747
    Citation Envoyé par newbie06 Voir le message
    La réponse est facile. L'autre question associée est : quelle est la probabilité que ce saut additionnel entre en collision avec un autre dans les tables de prédiction ? La réponse est plus dure, non ?

    Mais je suis d'accord avec toi, le sur-coût est faible
    C'est un branchement indirect, beaucoup moins de chances de conflits qu'un branch classique ou elles sont deja bien faibles (des lors que tu as un predicteur pour les branchements indirects).
    fefe - Dillon Y'Bon

  28. #748
    Citation Envoyé par fefe Voir le message
    C'est un branchement indirect, beaucoup moins de chances de conflits qu'un branch classique ou elles sont deja bien faibles (des lors que tu as un predicteur pour les branchements indirects).
    Hum, je ne connais pas bien la prédiction de branchement, mais même si tu as un prédicteur de branchement pour les sauts indirects celui-ci a une taille finie, donc une fonction de hachage, donc un risque de collision qui augmente avec le nombre d'entrées à stocker, non ? Donc plus on ajoute d'indirections pour gérer les implémentations spécialisées pour un processeur spécialisé, plus ce risque croît.

    M'enfin, si tu dis que ces chances sont faibles je suis tout prêt à te croire

  29. #749
    Oui mais il ne stocke que des branchements indirects, nettement moins courants. Il y a des risques de remplacement de l'entree (ou collision) essentiellement si tu l'utilises infrequement. Donc j'ai de gros doute que les points d'entree de la libc que ton programme utilise frequement ne soient pas lockes dans le predicteur et n'en sortent quasiment jamais.

    Il ne faut pas croire que les algo de remplacement sont de betes fonctions de hashage et que tu peux te faire remplacer aleatoirement au prochain branchement indirect qui passe par la.
    fefe - Dillon Y'Bon

  30. #750
    Des sauts indirects il y en a un paquet dans la vraie vie : dispatch virtuel et switch/case notamment. D'un autre côté il est probable que leur densité dynamique soit faible ; mais je ne parierais pas sur leur densité statique (quand je dis que je ne parie pas, c'est que je n'ai tenté de mesure). Et comme tu dis heureusement que les algos de remplacement sont souvent une fonction dépendant d'un historique récent de branchements

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •