YBoy360 a écrit 713 commentaires

Le narratif du méchant vaccin?

Et ensuite quelle sera l'étape suivante ?

Il faudrait rédiger une dépêche ou un journal pour ce logiciel.

Moi ça me fait penser à ça (La Femme: Disconnexion) :
https://www.youtube.com/watch?v=JR2mZChrO2c

J'ai toujours confondu les Michou et les Michu… C'est vrai qu'il y a peu de madame et de petits chez les Michou.

En effet. Nous n'utilisons pas log4j pour les couches applicative et je n'arrive pas à mixer notre configuration avec celle de log4j…

Les tentatives ont commencé le 10. Et
ksh
% journalctl -u tomcat9 | grep jndi | wc -l
204


Après une première analyse, nous ne semblons pas impacté. C'est la première fois cela dit qu'une attaque cible nos sites avec précision et qui aurait potentiellement pu fonctionner.

Oui ça, et le mot cyber[qqc] qui apparait dans mes spams LinkedIn / Teams.

En plus avec Konsole tu peux la rendre transparente ta console verte pour te transformer en Cyberhacker version 2019. C'est comme cela que je code mes scripts shell (avec cat).

Parce que make, c'est simple ??? Ce que tu veux ressemble à vouloir utiliser les autotools à la place de CMake.

Ne pas vouloir utiliser gradle, c'est comme utiliser Debian sans apt-get et consort. On peut très bien faire un script shell qui va d/l les dépendances. Maven va aussi d/l les dépendances, ça n'est pas tellement plus simple que Gradle.

Tu as aussi la possibilité d'utiliser javac directement, un peu comme tu utiliserai gcc. Tu dois même pouvoir faire un makefile utilisant Javac. Pour gérer les dépendances, tu pourras utiliser Ivy, Maven ou Grape. Tu utiliseras 2 outils au lieu d'un.

Je ne sais pas si Kotlin supporte Grape/Yvi dans le code source comme Groovy…

Il y a plein de raisons de ne pas apprécier Gradle :
- il impose un formalisme qui parfois est irritant ;
- la syntaxe est parfois incohérente (ça c'est améliorer avec la version 7.2) ;
- Ils ont fait les DSL de sorte qu'il n'y a pas d'autocompletion vraiment efficace ;
- Les messages d'erreur sont parfois complexe, ou tombe à coté.

Malgré ces défauts, si tu te conforme au formalisme, c'est juste un outils incontournable, et finalement très efficace, surtout sur de gros projets modulaires. Si tu développes ton plugin pour ajouter un truc au build pour faire fonctionner ton code, tu pourras partager ce que tu fais bien plus aisément, puisqu'il y a de grande chance que les intéressés utilisent aussi Gradle.

En théorie, sans IDE, il suffit de faire un :
./gradlew build

Et le tour est joué non ? Ça dépendra juste de Java. Et il faudra au préalable avoir créé le projet (pour avoir le Wrapper Gradle).

Pour exécuter, créer le binaire ou autres, on peut lister les tâches Gradle avec la tâche 'tasks' : ./gradlew tasks

Édit : j'avais pas lu l'intégralité de ta question. Gradle télécharge automatiquement les dépendances car c'est exactement ce qu'on lui demande. Si tu ne veux pas télécharger de dépendances, tu peux soit ne pas les utiliser, soit les recoder. C'est un peu comme si tu reprochais à apt-get de télécharger des programmes… Bonne chance.

Ça reste encore un peu intéressant.

La presse scientifique du jour d'aujourd'hui n'a plus rien à voir avec celle des années 90…

Même pour Microsoft, c'est quand même pas très subtile.

Difficile de te répondre précisément, si tu regardes leur page tu peux avoir une petite idée. Te dire que c'est l'équivalent du PHP avec Drupal et autres Wordpress, non clairement, mais ce n'est pas le même usage : tu peux réutiliser l'écosystème Java, tu n'es pas limité aux frontaux Web (je sais que l'on est vendredi, rien n'empêche de faire un ERP en n'importe quel langage), donc tu n'es pas isolé.

J'ai travaillé pour Drouot, tous les sites des commissaires priseurs par exemple étaient réalisés avec Grails. C'était un FW populaire il y a une dizaine d'années. Nos sites sont réalisés avec ce FW, des applications externes que nous utilisons aussi, comme Rundeck.

Aujourd'hui, ce Framework essai de se mettre à jour, la proximité avec Micronaut est un plus (du même auteur). Attention cela dit, pas mal de plugins qui spécialisent l'utilisation de librairies Java communes ne sont pas bien maintenus, et apportent peu de plus values par rapport à l'usage de Java directement. Les choses semblent cependant s'améliorer au niveau contributions, et comme dit plus haut, tu n'es pas isolé, tu as accès à tout l'écosystème Java.

En terme de pérennité, une chose rassurante pour ce framework est l'usage de briques de bases très communes, comme Gradle, Spring, Micronaut… Avant la version 3, tout était intégré directement dans grails (hormis Spring), ce qui était inquiétant. Je dirais que c'est le moment de l'utiliser si tu à besoin de réaliser des logiciels intégrés pour l'entreprise (donc pas purement Web), que tu maîtrise Groovy et que tu utilises/apprécies les DSL (c'est un facteur déterminant pour nous) ou que les Microservices ne te satisfont pas.

Les performances ont aussi progressé dans le sens ou c'est proche de Java (nos vieux sites n'ont pas de cache activé, mais s'affichent rapidement, comme sur ma page perso, nous allons bientôt les renouveler intégralement).

Bref, nous l'utilisons pour tout hors ERP (nous utilisons Axelor, 400 salariés) : Ged, CRM, CMS, Gestion de projets, génération documentaire, gestion des stocks de certaines filiales, Scheduler, BI… avec environ 150 utilisateurs, sur 4 continent, pas de problème (je n'en parlerai pas sinon :). On se trouve rapidement efficace avec ce FW, et ça donne envie de faire plus avec.

Voilà l'intérêt d'avoir des lignes de code courtes, c'est qu'en cas de copier/coller, on évite les sauts de ligne (puisque l'on peut rendre la fenêtre de l'éditeur étroite sans avoir de retour à la ligne automatique)…

En quoi le typage de Typescript est plus "expressif" que Kotlin ? Est-ce l'héritage du JAvascript ?

Kotlin est un langage typé statiquement. Selon moi, il a pour lui de ne pas supporter le JSON (pour beaucoup c'est un inconvénient), et le support des DSLs. Et nous l'utilisons dans pas mal de domaine (applications Android ou avec Micronaut).

Concernant la gestion des assets, nous avions des assets en AngularJS, Angular 2 ou 4, à certains moment nous avions du reactJs, et même du Dart avec des WebComponents, en plus du Kotlin. Aujourd'hui nous sommes entrain de supprimer tous ces composants, la seule entorse au JS, c'est le Kotlin transpilé. Notre application est modulaire au sens Gradle, les modules ont leurs propres Assets (qui n'ont pas d'espace de nommage, en production, mais en ont en mode dev). La gestion des assets est vraiment très complexes dans notre cas : le Gantt, le BI, sont des composants Gradle, les applications que l'on distribue aussi. Comme la même instance est utilisée en Chine, au US et en Europe, on se doit de ne pas avoir plusieurs fichiers Js ou Css à charger, de les compresser, d'utiliser HTTP/2 (si tu regarde ma page ça charge plutôt rapidement, même si tout cela reste classique).

Perso, je n'ai jamais réussi à débuguer un fichier js issue d'une transpilation en utilisant le mapping associé sur notre version de dev (donc sans compression )… Mais je ne dis pas que c'est impossible, ni que Typescript est un mauvais choix (juste que je préfère Kotlin).

Tu veux dire que des projets essaie de compiler / compresser les assets et sont emmerder par TypeScript (qui apporte très peu, je suis d'accord avec l'auteur du journal, quitte à perdre du temps, autant utiliser Kotlin, qui pose les mêmes problème mais apporte un vrai gain.).

Ça alors !

On pourrait aussi ajouter que certains projets ne se compile pas via l'IDE, mais que l'IDE supporte le système de build du projet.

La version utilisant des long corrigée présente un gains de 10 % sur ARM, mais grand chose sur Intel, par rapport à la version entière… Il y a peut-être encore de marge en regardant le code généré, mais l'épilogue de la fonction est déjà compliqué à écrire (ou les cas non aligné, pour des tableaux de n'importe quelle taille).

Donc sur cette tablette / Chromebook, le meilleur résultat est pour la boucle suivante (sans optimisation du prefetch) :

size_t find_int_c4l(const int k, const int* v, const size_t n) {
    size_t i = 0;
    size_t n2 = n >> 1;
    const unsigned long* vl  = (const unsigned long*)v;
    const unsigned long klow = (unsigned long)k;
    const unsigned long khi  = (unsigned long)k << 32;
    const unsigned long maskLow = 0xffffffff;
    const unsigned long maskHi  = maskLow << 32;
    unsigned int index = 0;

    for (; i <= n2; i += 8, vl += 8) {
        index = 0;
        __builtin_prefetch(vl + 256, 0, 1);

        index = ((vl[0] & maskLow) != klow && (vl[0] & maskHi) != khi) ? index : 1;
        index = ((vl[1] & maskLow) != klow && (vl[1] & maskHi) != khi) ? index : 1;
        index = ((vl[2] & maskLow) != klow && (vl[2] & maskHi) != khi) ? index : 1;
        index = ((vl[3] & maskLow) != klow && (vl[3] & maskHi) != khi) ? index : 1;
        index = ((vl[4] & maskLow) != klow && (vl[4] & maskHi) != khi) ? index : 1;
        index = ((vl[5] & maskLow) != klow && (vl[5] & maskHi) != khi) ? index : 1;
        index = ((vl[6] & maskLow) != klow && (vl[6] & maskHi) != khi) ? index : 1;
        index = ((vl[7] & maskLow) != klow && (vl[7] & maskHi) != khi) ? index : 1;
        if (index == 1) {
            break;
        }
    }
    return i; // i n/2 -8 si ok dans mon cas...
}

Résultat :
bash
C1 = 2850253 (499999984), C2 = 1233600 (499999984), C3 = 575797 (499999984), C4 = 547523 (499999984), C4l = 494092 (249999992), C5 = 556564 (499999984)


Par rapport à la version originale, dans mon test sur ARM, la boucle C4l est 5,77 fois plus rapide.

Je me suis emballé, il faut 2 comparaisons et appliquer 2 masks. Par contre, autant on perd sur de l'AMD sur cette boucle par rapport à la version non long, mais on divise par 2 sur mon ARM (Mediatek je crois…).

Si après correction j'obtiens des gains, je te les communiquerai.

Pour info, la version utilisant des long est presque encore 2 fois plus rapide sur ARM que la version int …

Par contre ça impose des contraintes d'alignement.

size_t find_int_c4l(const int k, const int* v, const size_t n) {
    size_t i = 0;
    size_t n2 = n >> 1;
    const long* vl = (const long*)v;
    const long kl = (long)(((long)k>>32) + k);
    unsigned int index = 0;

    for (; i <= n2; i += 8, vl += 8) {
        index = 0;
        __builtin_prefetch(vl + 256, 0, 1);
        index = vl[0] != kl ? index : 1;
        index = vl[1] != kl ? index : 1;
        index = vl[2] != kl ? index : 1;
        index = vl[3] != kl ? index : 1;
        index = vl[4] != kl ? index : 1;
        index = vl[5] != kl ? index : 1;
        index = vl[6] != kl ? index : 1;
        index = vl[7] != kl ? index : 1;
        if (index == 1) {
            break;
        }
    }
    if (index == 0) return i;
    else
        for (int j = 0; i < 8; j++) {
            if (vl[j] == kl) return i + j; 
                        //Attention, il == 2 * i...
        }
}

Sur ARM (un chromebook avec Debian dessus), j'obtiens de meilleurs score pour la version "CMOV" sur le main que j'ai mis au-dessus, les valeurs sont loader bien avant le CMOV, donc pas besoin de prédiction de valeur, elles sont dispo lors du cmov (il faudrait faire du profiling, j'ai la flème).

$ ./test.x
C1 = 928197 (499999984), C2 = 605687 (499999984), C3 = 538721 (499999984), C4 = 539927 (499999984), C5 = 545717 (499999984)

C3 et C4 sont 2 versions CMOV, les autres utilisent les branchements. C5, c'est le code que tu as mis dans l'autre commentaire.

$ cat /proc/cpuinfo 
processor       : 0
BogoMIPS        : 26.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4
[ . . . 8 cores qui semblent identiques ]

size_t find_int_c3(const int k, const int* v, const size_t n) {
    unsigned int mask = 0;
    size_t i = 0;
    for (; i < n - 8;) {
        mask = v[i] != k ? mask : 1;
        mask = v[i+1] != k ? mask : 2;
        mask = v[i+2] != k ? mask : 4;
        mask = v[i+3] != k ? mask : 8;
        mask = v[i+4] != k ? mask : 16;
        mask = v[i+5] != k ? mask : 32;
        mask = v[i+6] != k ? mask : 64;
        mask = v[i+7] != k ? mask : 128;
        i += 8;
        if (mask != 0) i += n;
        __builtin_prefetch(v + i + 512, 0, 1);
    }

    i -= n + 8;
    if (mask == 0) return n;
    if (mask == 1) return i;
    if (mask == 2) return i + 1;
    if (mask == 4) return i + 2;
    if (mask == 8) return i + 3;
    if (mask == 16) return i + 4;
    if (mask == 32) return i + 5;
    if (mask == 64) return i + 6;
    if (mask == 128) return i + 7;
}

size_t find_int_c4(const int k, const int* v, const size_t n) {
    size_t i = 0;
//  size_t n2 = n >> 1;
//  const long* vl = (const long*)v;
//  const long kl = (long)(((long)k>>32) + k);
    unsigned int index = 0;

    for (; i <= n; i += 8, v += 8) {
        index = 0;
        __builtin_prefetch(v + 256);
        index = v[0] != k ? index : 1;
        index = v[1] != k ? index : 1;
        index = v[2] != k ? index : 1;
        index = v[3] != k ? index : 1;
        index = v[4] != k ? index : 1;
        index = v[5] != k ? index : 1;
        index = v[6] != k ? index : 1;
        index = v[7] != k ? index : 1;
        if (index == 1) {
            break;
        }
    }
    if (index == 0) return i;
    else
        for (int j = 0; i < 8; j++) {
            if (v[j] == k) return i + j;
        }
}

size_t find_int_c5(const int k, const int* v, const size_t n) {
      size_t i = 0;
       for (; n - i >= 8; i += 8,v+=8)
         {
          __builtin_prefetch(v+256); //54/148
          if (v[0] == k) return i;
          if (v[1] == k) return i + 1;
          if (v[2] == k) return i + 2;
          if (v[3] == k) return i + 3;
          if (v[4] == k) return i + 4;
          if (v[5] == k) return i + 5;
          if (v[6] == k) return i + 6;
          if (v[7] == k) return i + 7;
        }

       for (; i != n; i++,v++)
        if (v[0] == k)
          return i;
       return n;
}

Le fait que C3 soit plus rapide que C4 est contre-intuitif, mais le prefetch n'est pas placé aux mêmes endroits. Je m'attendais à de plus de différences…

Perso j'adore ce Chromebook, pour 250 EUR t'as un Linux sur ARM (certes, ça ne vaut pas un RPi). Mais il y a un très bon écran.

C'est ce que j'ai constaté (l'efficacité de la prédiction de branchement, dans le cas ou k n'est présent qu'une fois en fin de tableau), ça doit être lié aux architectures cependant.

Mais, même dans ce cas très favorable à la prédiction, le temps mis est pratiquement égal à la version cmov. Donc prédiction OK == cmov en temps dans ce cas. La version cmov est constante en temps, alors que si pour un algo la prédiction n'est pas bonne 1 fois de temps en temps, tu es très pénalisé.

Il faudrait faire un autre journal ou on compte les occurrences de k…

Oui, il faut ajouter le code pour les n non multiple de 8, j'aurais dû le préciser. Dans le main, n >> 8, n % 8 == 0, et k est positionné en fin de tableau. Normalement, on regarde d'abord les données, ensuite on fait un profile sur des benchmarks typiques, puis on envisage quoi optimiser. L'avantage de ces hypothèses, c'est que l'on sait ce que l'on test.

Si k a de forte chance d'être présent dans le tableau (par exemple plus de 1/8 des valeurs sont k) ou que les tableaux sont très petits, il faut considérer d'autres méthodes, évidement.

J'essaierai de comparer les résultats de ce main sur un M1 ou un Raspberry PI. Sur Intel, le remplacement des jumps par les cmov (conditional mov) ne semble pas si interesante que cela, car dans l'hypothèse "k a peu de chance d'être rencontré" rend la prédiction de branchement efficace (par rapport au cmov), puisque c'est toujour le même chemin qui est emprunté par le code.

Je n'ai pas fait le cas n < 8, j'ai considéré que la recherche se faisait sur un grand tableau.

As-tu essayé avec le prefetch placé à la main ? même si ce n'est pas "conseillé", car lié au HW, pour les grands tableaux, même pour des accès contiguë, on y gagne.. Pour les accès aléatoire un peu complexe, calculer l'adresse à précharger peut être coûteux.

Le combo SSE + prefetch doit être intéressant dans ton cas, puisque plus on optimise, plus le prefetch devrait agir, car son effet est constant.

Je viens de corriger la boucle, il est difficile d'éviter les jumps (dans le code ci-dessus, il aurait fallu utiliser "|" au lieu de "&").

J'ai également ajouté les options de compilation suggérées au-dessus, et le prefetch sur le premier algo :

$ gcc -march=native -funroll-all-loops -O3 -g test.c -o test.x
$ ./test.x 
C1 = 138643 (499999984), C2 = 89029 (499999984)

size_t find_int_c(int k, const int* v, size_t n)
{
  for (size_t i = 0; i != n; ++i) {
    if (v[i] == k) {
      return i;
    }
    __builtin_prefetch(v + i + 512, 0, 1);
  }
  return n;
}

size_t find_int_c2(const int k, const int* v, const size_t n) {
      int index = 0;
      size_t i = 0;
      for (; i < n - 8;) {
        index = 0;
        if (v[i] == k) index = 1;
        else if (v[i + 1] == k) index = 2;
        else if (v[i + 2] == k) index = 3;
        else if (v[i + 3] == k) index = 4;
        else if (v[i + 4] == k) index = 5;
        else if (v[i + 5] == k) index = 6;
        else if (v[i + 6] == k) index = 7;
        else if (v[i + 7] == k) index = 8;
        if (index != 0) i += n;
        i += 8;
        __builtin_prefetch(v + i + 512, 0, 1);
    }

    i -= n + 8;
    if (index == 0) return n;
    if (index == 1) return i;
    if (index == 2) return i + 1;
    if (index == 4) return i + 2;
    if (index == 8) return i + 3;
    if (index == 16) return i + 4;
    if (index == 32) return i + 5;
    if (index == 64) return i + 6;
    if (index == 128) return i + 7;
}

Les gains sont bien moins importants dans ce cas. On peut cela dit avoir envie d'éviter de dérouler toutes les boucles.. Puisque cela fait grossir la section code. Bref. On gagne quand même 40 % avec le déroulage manuel.

Il faut utiliser objdump pour observer le code compilé, ensuite, il faut fournir la commande de compilation.

Sans forcer, je divise par 2.6 le temps de la boucle original (j'ai eu la flemme de calculer le résultat exacte).

size_t find_int_c2(const int k, const int* v, const size_t n)
{
      int index = 0;
      size_t i = 0;
      for (; i < n - 8;) {
        int r0 = v[i++] - k;
        index = r0 == 0 ? 1 : index;
        int r1 = v[i++] - k;
        index = r1 == 0 ? 2 & index : index;
        int r2 = v[i++] - k;
        index = r2 == 0 ? 4 & index : index;
        int r3 = v[i++] - k;
        index = r3 == 0 ? 8 & index : index;
        int r4 = v[i++] - k;
        index = r4 == 0 ? 16 & index : index;
        int r5 = v[i++] - k;
        index = r5 == 0 ? 32 & index : index;
        int r6 = v[i++] - k;
        index = r6 == 0 ? 64 & index : index;
        int r7 = v[i++] - k;
        index = r7 == 0 ? 128 & index : index;
        if (index != 0) i += n;
        __builtin_prefetch(v + i + 512, 0, 1);
    }

  return index != -1 ? i + index : n;
}

Voila l'idée, supprimer les Jumps. Je pense que ça peut s'améliorer d'un facteur 2 ou 3.

$ gcc -march=native -O3 -g test.c -o test.x
$ objdump -dS test.x
$ ./test.x 
C1 = 228117 (499999984), C2 = 85911 (999999993)

Le main:

int main() {
    int* tab = malloc(SIZE * 4);
    for (int i = 0; i < SIZE; i++) {
        tab[i] = i;
    }
    clock_t c1 = clock();
    size_t r1 = find_int_c(SIZE - 16, tab, SIZE);
    clock_t c1end = clock();

    clock_t c2 = clock();
    size_t r2 = find_int_c2(SIZE - 16, tab, SIZE);
    clock_t c2end = clock();

    printf("C1 = %ld (%ld), C2 = %ld (%ld)\n", c1end - c1, r1, c2end - c2, r2);
}

C'est Google Workspace plus ou moins ce que tu décris. Tu peux aussi développer des applications interagissant avec drive, avoir de la visio intégrée dans ton agenda, le tableau blanc, le tout fullweb, ou depuis le mobile.

Par exemple, l'intégration d'OnShape avec Drive : en 1 click (et pas mal de sous) tu as un SolidWorks, hébergé sur AWS. Tu as un workflow d'édition, l'historique des modifications directement accessible. L'intérêt est de ne pas héberger la solution sur GApps. Je ne pense pas que Sharepoint autorise l’interaction avec d'autres plateformes de la sorte (ou alors avec une intégration limité). Cela dit, je ne connais pas bien Sharepoint.

Pas tout à fait d'accord, si le mail a très mal évolué le responsable n'est autre qu'Outlook. La mise en forme des clients Outlook des mails est désastreuse. GMail et quelques autres sont plus respectueux des interlocuteurs. Il m'arrive même de ne pas répondre en format "text-only".

Je suis curieux de savoir ce que M365 propose de si intéressant par rapport à la concurrence (au hasard Drive). Rien ne me semble "plié". Au contraire. Peut-être que la solution n'est pas celle que l'on pense, mais un ensemble de solutions hétérogènes, à coup de R et Jupyter Lab pour remplacer Excel, reveal.js pour remplacer PP (ou arrêter ces bêtises de présentation inutile la plupart du temps). Pour Word, il y a des solutions basée sur Git qui permettent de générer du PDF… Je ne voyais pas le bout du tunnel avec les applications Access, en 2 ans, elles ont totalement disparu de mon entourage.

C'est sûr que de vouloir remplacer Exchange / Office par une solution identique sera un sacré challenge. De même, choisir OnlyOffice, dont 95 % du code vient de MS, c'est prendre un risque. En terme de pérennité, je suis pas sûr que le compte y soit.