SChauveau a écrit 389 commentaires

Du Fortran? Où cela?

Je n'aime pas trop le terme mais pour faire simple je suis un "expert" en compilation (doctorat en informatique + 20 ans à travailler dans le domaine). Quand je vois un article comme celui ci, je n'ai donc pas trop de difficultés à imaginer les implémentations possibles avec leur avantages et inconvénients.

Concernant l'indentation. Elle apparaît au milieu donc cela s'est probablement produit quand j'ai fait le gros copier-coller pour passer de 100 à 200 tableaux.

C'est possible mais cela pourrait coûter très cher car les fonctions constexpr peuvent contenir des boucles. Il n'y a donc pas de limite théorique au nombre d'appels de fonctions constexpr lors de l'évaluation d'une seule expression.

A ce propos, j'ai utilisé 800 dans mon code car g++ refusait de compiler avec 1000. Erreur 'too many recursive templates' ou quelque chose dans le genre.

La confusion est facile à faire. Certains langages utilisent effectivement .. ou … comme opérateurs d'intervalle. Par exemple en Bash

# echo {3..11}
3 4 5 6 7 8 9 10 11

On peut probablement avoir le beurre et l'argent du beurre en encapsulant la fonction constexpr dans une template. Et potentiellement avec une autre fonction constexpr par dessus pour garder une syntaxe lisible:

constexpr int count_impl(unsigned n)
{
  return (n == 0) ? 0 : 1 + count_impl(n - 1);
}

template<unsigned N>
struct count_t
{
  enum { value = count_impl(N)};
};

constexpr int count(unsigned n) { return count_t<N>::value }

Dans ce cas, la classe sert en quelque sorte de cache.

A mon avis les 2 premiers sont plutôt
(1) le Porno
(2) la NSA qui surveille pour savoir qui regarde (1)

Cela fait pas mal de temps que je n'ai pas utilisé les fold-expressions mais je ne pense pas que cela fonctionne comme tu le propose ici. C'est une sorte de vararg donc pour count2<24>, l'expression 0+...+N est en fait équivalent à 0+24. Pour obtenir la somme demandée il te faudrait explicitement indiquer tout les membres de la somme: count2<1,2,3,4,5,6, etc ,24>

Le formatage a fait sauter quelques caractères. Il fallait lire:

Mon explication est que, dans la version template, la quasi totalité du temps se passe lors de la 1ere instanciation (donc les 800 classes count_t<800>, count_t<799>, …). Pour les 99 tableaux restants, le coût est minimal car le compilateur possède déjà la classe count_t<800> dans sa table des symboles.

j'ai modifié ton code en changeant 24 en 800 et aussi en répétant la définition du tableau 100 fois (dans des scopes séparés).

Pour 100 compilations, la version constexpr prend 17.2s contre seulement 2.8s pour les template.

En doublant le nombre de définition des tableaux, le temps de compilation avec constexpr double quasiment (33.3s) alors que template ne change quasiment pas (3.0s).

Mon explication est que, dans la version template, la quasi totalité du temps se passe lors de la 1ere instanciation (donc les 800 classes count_t, count_t, …). Pour les 99 tableaux restants, le coût est minimal car le compilateur possède déjà la classe count_t dans sa table des symboles.

Au contraire la version constexpr doit réévaluer count(800) à chaque apparition.

#define P 800

#if 1

constexpr int count(unsigned n)
{
  return (n == 0) ? 0 : 1 + count(n - 1);
}

#define N count(P)
#else
template<unsigned N>
struct count_t;

// le cas d'arrêt
template<>
struct count_t<0>
{
  enum { value = 0 };
};

// le calcul récursif pour le cas général.
template<unsigned N>
struct count_t
{
  enum
    {
      value = 1 + count_t<N - 1>::value
    };
};
#define N count_t<P>::value 
#endif

void foo()
{
  // Pouf ! Ça marche.
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

   { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }

  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
  { int array[N]; }
}

C'est pas la mort. Cela ne changera rien pour 99% des utilisateurs qui n'utilisent jamais FTP (oui! je sais que, comme 83% des pourcentages donnés dans les commentaires, celui ci est inventé) et pour le 1% restant Firefox lancera un utilitaire externe comme pour un mailto:// ou un irc://

Et C++2000 ajoute également le support du caractère '·' (Codepoint 183, "MIDDLE DOT") dans les identifiants. On pourra donc améliorer la lisibilité du code avec des programmes inclusifs:

for (int compteur·se· = 0 ; compteur·se· < n ; ++compteur·se· ) {
if ( fsf_direct·eur·rice[compteur·se·] == richard_stallman )
throw sale_macho ;
}


Et dans tout les cas, on peut aussi faire un petit sudo apt changelog sudo pour s'assurer que CVE-2021-3156 est corrigé:

sudo (1.9.5p1-1.1) unstable; urgency=high

  * Non-maintainer upload.
  * Heap-based buffer overflow (CVE-2021-3156)
    - Reset valid_flags to MODE_NONINTERACTIVE for sudoedit
    - Add sudoedit flag checks in plugin that are consistent with front-end
    - Fix potential buffer overflow when unescaping backslashes in user_args
    - Fix the memset offset when converting a v1 timestamp to TS_LOCKEXCL
    - Don't assume that argv is allocated as a single flat buffer
...

Je suis sous Debian Testing et j'ai vu passer une mise à jour du CVE-2021-3156 il y a plusieurs jours dans la version 1.9.5p1-1.1 (le 20 janvier à en croire le Changelog). J'imagine que toutes les Debians ont effectivement patché leur version actuelle avant même que 1.9.5p2 ne soit disponible. Cela me semble assez logique.

Sauf erreur, dans le projet MontBlanc, les unités vectorielles sont plutôt standard. C'est de l'ARMv8 NEON probablement avec des vecteurs un peu plus grands que les 128bits habituels (256, 512, ou peut être 1024?). Les compilateurs seront probablement gcc et llvm. Ce n'est pas comme si il y avait beaucoup d'autres possibilités.

Il faut voir du coté du Projet MontBlanc dont le but est de créer un processeur Européen à base d'ARM pour le HPC (le calcul haute performance). Le HPC est un domaine stratégique mais ce n'est clairement pas grand public donc le projet reste assez confidentiel hors des «milieux autorisés».

Personnellement, je me demande à quel point le projet MB sera affecté par l'acquisition de ARM par NVIDIA

La page correspondant au lien «Conclusion» ne semble pas exister. Un volontaire pour un petit DOS facile?

Non, Non et encore Non!!!! Une ère moderne se doit de commencer avec l'an ZERO. Et puis aussi il devrait y avoir 256 jours dans une année.

Dans le même genre il y a cette vidéo assez amusante
https://www.youtube.com/watch?v=A8zWWp0akUU

Et aussi 'sort' ce qui est très pratique pour des trucs du genre

(shell) du -sh * | sort -h
4.0K    CODING_STYLE.md
4.0K    meson_options.txt
...
840K    tests
1.3M    build
2.1M    src
112M    subprojects

«les seules variables consistent donc dans les bibliothèques bas niveau (libc, pthread), des outils communs (tar, cp) et l'OS lui-même»

Et le compilateur? Je trouve étrange que rien ne soit mentionné au sujet du compilateur. GCC? LLVM? version?

Et même en supposant que les compilateurs soient identiques, il serait bien de s'assurer qu'ils étaient compilés de façons identiques. Plus généralement, il faudrait probablement recompiler tout les outils de compilations.

En effet, il n'y a pas de mémoire donc il ne faut oublier les cas ou le nombre d'essais est supérieur à 4096.
Et pour le fun, voici une petite commande bash simulant un tel tirage au sort. Chaque ligne indique le nombre d'essais pour trouver une valeur entre 0 et N-1 (donc avec une probabilité de 1/N) ainsi que la moyenne depuis le début.

N=4096;  s=0; for ((i=1;;i++)) ; do cpt=1 ; while true ; do let "A=(RANDOM+(RANDOM<<15))%N" ; [ $A == "0" ] && break ; let cpt=cpt+1 ; done ;  let s=s+cpt ; printf "essais = %6d  moy = %6d\n" "$cpt" "$((s/i))" ; done

et ISC n'est visible pas «2038 ready» si on en crois la fonction isc_time_set dans https://users.isc.org/~each/doxygen/bind9/isc_2unix_2include_2isc_2time_8h.html#806dda800c7f198aa373aab9d88e436f

En effet. Le problème se situe probablement dans le code ISC. Je pense en particulier à leur API time.h

https://users.isc.org/~each/doxygen/bind9/isc_2unix_2include_2isc_2time_8h.html#806dda800c7f198aa373aab9d88e436f

Je remarque en particulier que la fonction isc_time_set représente le temps en secondes depuis le 1er jan 1970 avec un entier 32bit (donc le temps UNIX classique). C'est le fameux bug de l'an 2038.

je ne veux pas être méchant mais les textes rouges surlignés en blanc sur fond blanc semi-transparent sur une image … comment dire … ça pique les yeux.

Si on réduit la durée d'une génération à 20 ans alors le nombre de génération passe à 60 et le nombre de segments d'ADN hérités de cette période devient 46+60*34 = 2086. Cela ne change pas grand chose au résultat final.