Non, c'est bien de prédication, mais en fait c'est un anglicisme désolé. "Prédicat" existe bien en français, mais en anglais il y a aussi le mot "Predication" pour désigner la fonctionnalité. Voir https://en.wikipedia.org/wiki/Predication_(computer_architecture) . En résumé, c'est le fait de pouvoir masquer certains éléments d'un vecteur lors des opérations. C'est notamment utilisé dans SVE pour masquer les éléments de la dernière itération, même si d'autres usages sont possibles.
SVE utilise la prédication pour faire des calculs sur une partie des élements d'un vecteur, notamment utile pour la dernière itération lorsque le nombre d'éléments d'un calcul n'est pas un multiple du nombre d'éléments d'un vecteur. Cela a pour conséquence que la taille d'un registre vectoriel a une limite finie, choisie à 2048 bits pour SVE.
RISC-V n'a pas cette limite, et on peut avoir des registres vectoriels beaucoup plus grands. Cela est avantageux notamment car RISC-V permet de ré-organiser l'espace mémoire de l'unité vectorielle et de réattribuer la mémoire des registres vectoriels inutilisés à d'autres. À noter qu'il n'y a pas forcément autant d'unité de calculs disponibles en hardware que la taille d'un vecteur, mais ces opérations se pipelinent très bien, et du coup il est possible d'utiliser un pipeline in-order tout en restant efficace.
Je suis tout à fait d'accord, il ne faut pas tout réduire à du calcul matriciel. Par exemple grâce aux instructions vectorielles "fault-only-first load", il est notamment possible de travailler sur des chaînes de caractères sans contrainte d'alignement et sans connaître leur longueur à priori.
Dans la vie réelle, il y a l'exemple de Cray qui avait un principe de fonctionnement similaire au niveau des vecteur de longueur variable et qui fonctionnait très bien.
Côté ARMv8 SVE, qui est tout de même un peu différent je l'admet, il y a quand même le supercalculateur Fugaku qui arrive premier au Top 500 sans utiliser de GPU.
Difficile ou impossible, il faudrait savoir. C'est très bien expliqué comment l'extension V de RISC-V implémente ça dans le livre "The RISC-V Reader: An Open Architecture Atlas" de David Patterson et Andrew Waterman.
Un cherchant un peu sur le net, j'ai également trouvé ce site qui explique pas trop mal le principe: https://gms.tf/riscv-vector.html
A noter que ARMv8 propose l'extension SVE qui fonctionne sur un principe similaire, mais avec moins de flexibilité.
Oui et non. On parle bien d'une extension vectorielle, dans le sens ou la taille des registres n'est pas définie par l'ISA, mais par l'implémentation. Le NOEL-V a bien des registres vectoriels de 128 bits, mais un code binaire identique est capable d'exploiter des vecteurs de taille différente sur un autre CPU.
RV32M1 de NXP (eh oui, j’en suis le premier étonné !), un microcontrôleur très spécial, puisqu’il contient un cœur RV32I mais également deux cœurs ARM Cortex-M0 et Cortex-M4.
Le RV32M1 a même deux cœurs RV32I. En fait les deux cœurs rapides (Cortex-M4 et RI5CY) et deux cœurs basse consommation (Cortex-M0 et ZERO-RISCY). J'imagine que côté logiciel doit être sympa pour faire tout fonctionner ensemble.
Enfin pour ceux qui ne veulent pas se prendre la tête, un 10 liner en shell me permet de renouveler sans me prendre la tête les certifs au bout de 60 jours, ajoutez-y un service reload de ce qu'il faut (genre nginx ou apache ou postfix …) et pouf, vous êtes bon pour du TLS partout !
En pratique le problème du redémarrage du serveur web (et les droits au script pour le faire) est un faux problème. La plupart du temps il y a un service de rotation des logs qui le fait régulièrement. Il faut donc juste être sûr de renouveler le certificat suffisamment à l'avance.
Sur le site il est possible de faire une donation via Paypal, qui prend une commission si je ne m'abuse. Est-il également possible de faire une donation par virement ou par chèque ?
De plus si ils veulent réellement échapper à tout risque de procès ils devront tout recoder sans regarder les sources des originaux, presque en clean room.
Ce qui est marrant c'est que Rob Landley apparaît dans la section "Contractor Candidates". Vu qu'il est l'auteur d'un peu plus de 800 commits dans busybox, je suis pas sûr que ce se soit le meilleur candidat...
Oui enfin le réseau qui ne tient pas la charge c'est vraiment une bonne excuse. Sur un réseau mobile la partie qui limite c'est entre le téléphone et le réseau de l'opérateur, pas le tuyau vers Internet.
Donc d'un côté il y a des limitations à 500 Mo par mois parce qu'autrement le réseau ne tiendrait pas, mais bizarrement le réseau tient très bien lorsqu'il s'agit d'avoir une option TV ou Deezer en illimité.
L'ennui, c'est que vos utilisateurs sont fainéants : dans la barre d'adresse de leur navigateur web, ils ne tapent pas « https://webmail.example.com/ » mais simplement « webmail.example.com ». Le comble, c'est qu'ils s'attendent à ce que cela fonctionne ainsi !
Enfin ça c'est les utilisateurs un peu avertis. La plupart tapent « webmail example » dans la barre de recherche ou même directement dans Google.
Que les gros comme Ubuntu répondent à Debian un truc du genre "démmerdrez-vous, le code est là z'avez quà venir le chercher" je le vois venir gros comme une maison et ça serait vraiment lamentable :/
Si c'était que ça... Parfois c'est du genre "on a tel bug dans Ubuntu, on le rapporte dans le BTS Debian, histoire qu'il puisse être remonté upstream", ou même "hé, regarde, <lien vers launchpad>, il y faudrait corriger tels et tels bugs".
Bref Ubuntu a fait du progrès pour remonter les patches vers Debian, mais n'assure pas toujours son rôle en terme de remontée de patches ou de participation dans les projets upstream. C'est maintenant, qu'on le veuille ou non une distribution importante, qui doit participer à la vie du logiciel libre, comme le font les autres distributions (à des niveaux différents il est vrai).
Comme cela a déjà été indiqué, la réintroduction du support KQEMU est tout à fait possible,
Il suffit de trouver quelqu'un qui veut bien s'en occuper et supprimer les limitations qui bloquaient le développement de KVM, comme par exemple la gestion des adresses sur 32 bits (même sur x86_64), limitant la taille des machines virtuelles à 4G. Il faudra aussi envisager de mettre à jour le module noyau pour qu'il puisse compiler avec un kernel récent.
Pour le moment il y a beaucoup de monde pour se plaindre, mais personne pour mettre les mains dans le cambouis. Les sources sont pourtant disponibles dans ce monde merveilleux qu'est le logiciel libre.
Je pense que la nouvelle va un peu fort avec un titre comme « Debian migre vers SHA-2 ». Une personne qui n'est pas (encore) Developeur Debian propose un mécanisme de migration, et on en conclu que Debian migre vers SHA-2. Oui, c'est quelque chose qui va se faire tôt ou tard, mais pour le moment rien n'a encore été décidé.
[^] # Re: Et RISC-V?
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 5.13. Évalué à 7.
Non, c'est bien de prédication, mais en fait c'est un anglicisme désolé. "Prédicat" existe bien en français, mais en anglais il y a aussi le mot "Predication" pour désigner la fonctionnalité. Voir https://en.wikipedia.org/wiki/Predication_(computer_architecture) . En résumé, c'est le fait de pouvoir masquer certains éléments d'un vecteur lors des opérations. C'est notamment utilisé dans SVE pour masquer les éléments de la dernière itération, même si d'autres usages sont possibles.
[^] # Re: Et RISC-V?
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 5.13. Évalué à 4.
SVE utilise la prédication pour faire des calculs sur une partie des élements d'un vecteur, notamment utile pour la dernière itération lorsque le nombre d'éléments d'un calcul n'est pas un multiple du nombre d'éléments d'un vecteur. Cela a pour conséquence que la taille d'un registre vectoriel a une limite finie, choisie à 2048 bits pour SVE.
RISC-V n'a pas cette limite, et on peut avoir des registres vectoriels beaucoup plus grands. Cela est avantageux notamment car RISC-V permet de ré-organiser l'espace mémoire de l'unité vectorielle et de réattribuer la mémoire des registres vectoriels inutilisés à d'autres. À noter qu'il n'y a pas forcément autant d'unité de calculs disponibles en hardware que la taille d'un vecteur, mais ces opérations se pipelinent très bien, et du coup il est possible d'utiliser un pipeline in-order tout en restant efficace.
[^] # Re: Et RISC-V?
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 5.13. Évalué à 7.
Je suis tout à fait d'accord, il ne faut pas tout réduire à du calcul matriciel. Par exemple grâce aux instructions vectorielles "fault-only-first load", il est notamment possible de travailler sur des chaînes de caractères sans contrainte d'alignement et sans connaître leur longueur à priori.
Ainsi une implémentation de strlen() vectorisée reste très simple:
https://github.com/gsauthof/riscv/blob/master/strlen.s
À comparer à une implémentation AVX2 pour x86:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/strlen-avx2.S
Sans compter que pour x86, il faut aussi la version AVX-512 pour les CPUs serveurs, et la version SSE2 pour l'entrée de gamme.
[^] # Re: Et RISC-V?
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 5.13. Évalué à 5.
Dans la vie réelle, il y a l'exemple de Cray qui avait un principe de fonctionnement similaire au niveau des vecteur de longueur variable et qui fonctionnait très bien.
Côté ARMv8 SVE, qui est tout de même un peu différent je l'admet, il y a quand même le supercalculateur Fugaku qui arrive premier au Top 500 sans utiliser de GPU.
[^] # Re: Et RISC-V?
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 5.13. Évalué à 10.
Difficile ou impossible, il faudrait savoir. C'est très bien expliqué comment l'extension V de RISC-V implémente ça dans le livre "The RISC-V Reader: An Open Architecture Atlas" de David Patterson et Andrew Waterman.
Un cherchant un peu sur le net, j'ai également trouvé ce site qui explique pas trop mal le principe: https://gms.tf/riscv-vector.html
A noter que ARMv8 propose l'extension SVE qui fonctionne sur un principe similaire, mais avec moins de flexibilité.
[^] # Re: Et RISC-V?
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 5.13. Évalué à 8.
Oui et non. On parle bien d'une extension vectorielle, dans le sens ou la taille des registres n'est pas définie par l'ISA, mais par l'implémentation. Le NOEL-V a bien des registres vectoriels de 128 bits, mais un code binaire identique est capable d'exploiter des vecteurs de taille différente sur un autre CPU.
# Le RV32M1 a même deux cœurs RV32I
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche 2018, l’année de la libération des processeurs ?. Évalué à 5.
Le RV32M1 a même deux cœurs RV32I. En fait les deux cœurs rapides (Cortex-M4 et RI5CY) et deux cœurs basse consommation (Cortex-M0 et ZERO-RISCY). J'imagine que côté logiciel doit être sympa pour faire tout fonctionner ensemble.
[^] # Re: Email ?
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche Authentifiez-vous sans mot de passe grâce à XMPP !. Évalué à 3.
Et par IRC ? Je vois souvent des gens qui rentrent leur mot de passe, mais je sais pas si ça marche bien…
[^] # Re: Automatisation mon amour
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche Reparlons de Let’s Encrypt. Évalué à 7.
En pratique le problème du redémarrage du serveur web (et les droits au script pour le faire) est un faux problème. La plupart du temps il y a un service de rotation des logs qui le fait régulièrement. Il faut donc juste être sûr de renouveler le certificat suffisamment à l'avance.
[^] # Re: meurt google ! meurt !
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche GCompris officiellement sur Android. Évalué à 0.
Sur le site il est possible de faire une donation via Paypal, qui prend une commission si je ne m'abuse. Est-il également possible de faire une donation par virement ou par chèque ?
[^] # Re: Hum...bon courage...
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche Sony : Ma propriété intellectuelle vaut plus que la vôtre. Évalué à 4.
Ce qui est marrant c'est que Rob Landley apparaît dans la section "Contractor Candidates". Vu qu'il est l'auteur d'un peu plus de 800 commits dans busybox, je suis pas sûr que ce se soit le meilleur candidat...
[^] # Re: Internet quoi
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche Free lance son offre mobile : ce que ça change. Évalué à 10.
Oui enfin le réseau qui ne tient pas la charge c'est vraiment une bonne excuse. Sur un réseau mobile la partie qui limite c'est entre le téléphone et le réseau de l'opérateur, pas le tuyau vers Internet.
Donc d'un côté il y a des limitations à 500 Mo par mois parce qu'autrement le réseau ne tiendrait pas, mais bizarrement le réseau tient très bien lorsqu'il s'agit d'avoir une option TV ou Deezer en illimité.
[^] # Re: Au pays du cassoulet ...
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche L'ESA lance son Summer of Code. Évalué à 1.
Sauf que l'ESA n'est pas à Toulouse. Le siège social est à Paris, mais les plus grand centres sont à Noordwijk (Pays-Bas) et Darmstadt (Allemagne).
# Et Google ?
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche HTTP Strict Transport Security. Évalué à 3.
L'ennui, c'est que vos utilisateurs sont fainéants : dans la barre d'adresse de leur navigateur web, ils ne tapent pas « https://webmail.example.com/ » mais simplement « webmail.example.com ». Le comble, c'est qu'ils s'attendent à ce que cela fonctionne ainsi !
Enfin ça c'est les utilisateurs un peu avertis. La plupart tapent « webmail example » dans la barre de recherche ou même directement dans Google.
[^] # Re: Sources ?
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche CAElinux 2010 et Salome-meca 2010. Évalué à 1.
# Apple ?
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche Motorola : une nouvelle étape dans l'ignominie ?. Évalué à 10.
[^] # Re: Excellent idée
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche Debian crée un Derivatives Front Desk. Évalué à 8.
Si c'était que ça... Parfois c'est du genre "on a tel bug dans Ubuntu, on le rapporte dans le BTS Debian, histoire qu'il puisse être remonté upstream", ou même "hé, regarde, <lien vers launchpad>, il y faudrait corriger tels et tels bugs".
Bref Ubuntu a fait du progrès pour remonter les patches vers Debian, mais n'assure pas toujours son rôle en terme de remontée de patches ou de participation dans les projets upstream. C'est maintenant, qu'on le veuille ou non une distribution importante, qui doit participer à la vie du logiciel libre, comme le font les autres distributions (à des niveaux différents il est vrai).
[^] # Re: Réintroduction possible de KQEMU
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche Qemu 0.12.1 mais sans kqemu. Évalué à 2.
# Réintroduction possible de KQEMU
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche Qemu 0.12.1 mais sans kqemu. Évalué à 10.
Il suffit de trouver quelqu'un qui veut bien s'en occuper et supprimer les limitations qui bloquaient le développement de KVM, comme par exemple la gestion des adresses sur 32 bits (même sur x86_64), limitant la taille des machines virtuelles à 4G. Il faudra aussi envisager de mettre à jour le module noyau pour qu'il puisse compiler avec un kernel récent.
Pour le moment il y a beaucoup de monde pour se plaindre, mais personne pour mettre les mains dans le cambouis. Les sources sont pourtant disponibles dans ce monde merveilleux qu'est le logiciel libre.
[^] # Re: AVX?
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche Sortie de la version 2.11 de la bibliothèque standard C GNU (glibc). Évalué à 6.
# Et la libc ?
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche X11R7.5 publié. Certes, mais encore ?. Évalué à 10.
On oublie très souvent la libc. C'est pas quelque chose de très visible, mais c'est pourtant indispensable...
# Annonce un peu hâtive ?
Posté par Aurélien Jarno (site web personnel) . En réponse à la dépêche Nouvelles attaques sur SHA-1 : Debian pourrait migrer vers SHA-2. Évalué à 10.
[^] # Re: C'est le retour du bâton
Posté par Aurélien Jarno (site web personnel) . En réponse au journal Debian migre de la GNU libc à EGLIBC. Évalué à 2.
[^] # Re: C'est le retour du bâton
Posté par Aurélien Jarno (site web personnel) . En réponse au journal Debian migre de la GNU libc à EGLIBC. Évalué à 4.
[^] # Re: cool
Posté par Aurélien Jarno (site web personnel) . En réponse au journal Debian migre de la GNU libc à EGLIBC. Évalué à 2.