Clément V a écrit 110 commentaires

Il a une drôle de tête, ce Jason. Il ressemble beaucoup à Tom.

Par exemple, il est écrit que "les implémentations de Mesa dans Wayland sont à des années de retard de celles de Xorg", mais il me semble que Mesa sert surtout aux jeux, et pour autant que je sache Wayland est la solution préférée de SteamOS et des gamers ? Bref, je m'en remets à votre avis.

Mesa sert à toute sorte d'affichage, c'est loin d'être limité aux jeux.

Quant à SteamOS, X.org est utilisé pour la session Bureau (KDE) et gamescope pour la session Steam. Gamescope est un compositeur Wayland très particulier puisqu'il ne supporte que des clients X11. Ce n'est pas la meilleure vitrine Wayland.

GNOME et KDE ont chacun leur propre compositeur Wayland. La plupart des autres compositeurs se basent sur wlroots (principalement développé pour sway).

J'étais tombé sur cet article il y a quelque temps et j'avais regardé rapidement l'histoire de la climatologie pour le remettre dans son contexte. De mémoire (je peux me tromper), l'idée que le climat peut changer date du 19^ème siècle en étudiant les couches géologique. La cause des changements climatiques n'est pas connue, on considère plusieurs hypothèses : activité solaire, activité volcanique, gaz à effet de serre (eau, CO2), pendant la fin du 19^ème. À l'époque de l'article, les gaz à effet de serre sont bien connus mais leur importance par rapport au changements climatiques n'est pas consensuelle. Au même moment, tu dois sûrement trouver des articles qui parlent de refroidissement climatique causé par les particules émises par les usines (refroidissement réel mais plus faible que le réchauffement par les gaz à effet de serre). Le réchauffement climatique causé par les gaz à effet de serre n'est sérieusement étudié qu'à partir de la seconde moitié du 20^ème siècle.

Linux n'a pas non plus un respect de sa propre API ni ABI (pas pour rien qu'on a mis en place dkms) du coup les modules doivent être recompilés tout le temps aussi.

L'API/ABI interne du noyau est instable, mais entre le noyau et l'utilisateur c'est au contraire très très stable. Tu recompiles seulement les modules quand tu changes de noyau, jamais les applications.

Ou peut-être que c'est surtout parce que le reconditionné est maintenant suffisamment bon dans la tête de ces gens et que la raison principale est que c'est moins cher, et dans ce cas… les implications sont un peu différentes.

Honnêtement, ça me parait être la première raison. Pourquoi acheter un neuf qui ne révolutionne rien quand tu peux avoir un très bon téléphone plus vieux mais beaucoup moins cher. Les autres arguments font plus classe quand on doit se justifier, mais sans ce dernier argument beaucoup ne le feraient pas, ou ne pourraient pas le faire.

J'espère que les fabricants vont s'adapter et tourner leur business model et leur comm' vers la réparation et la durabilité et, rêvons un peu, tenir plus compte de l'aspect environnemental dans la production des appareils puisque le signal est : "l'environnement n'est plus un bonus / une option".

Ou alors ils vont ajouter une puce qui bloque le téléphone après quelques années. On dira que c'est pour la sécurité : tous ces téléphones avec un système pas à jour, c'est une catastrophe, il faut empêcher ça.

Qurls applis auraient besoin de lancer des requêtes sur le gestionnaire de paquets ?

Les mises à jour en arrière-plan et l'utilisateur qui veut installer des applications.

• du 128 kbps HE-AACv2 ça commence à être moins artificiel

Pas sûr d'entendre la différence déjà à ce niveau là.

Mais en fait je suis pas sûr que l'étude en question parle de ce genre de compression. Une autre source définit la compression autrement :

Un ”son compressé" est un son numérique qui a été "tassé" électroniquement pour faire remonter les niveaux sonores les plus faibles, afin que ce soit plus audible.
Le son de franceinfo est légèrement compressé. Tout comme la grande majorité des musiques et des sons que l’on écoute sur internet, en DVD ou en visioconférence quand on télétravaille.

Évidemment personne ne cite correctement l'article scientifique en question qui certainement bien plus précis sur ce qui est étudié.

Soit environ un millième de l'amende initiale. Il faudra plusieurs années pour doubler l'amende. Pas besoin de se presser pour la correction.

On est bientôt 7 milliards sur terre (mais tous ne parlent pas français, heureusement).

Je vois que IPoT est toujours aussi utilisé dans le passé.

Ça semble bien mieux en effet. La plupart des problèmes que j'avais remarqués ont disparu. L'intersection dangereuse du premier point est toujours là, mais l'alternative est également proposée.

Parfois il y a un feu spécial cyclistes qui demande d'appuyer sur un bouton puis d'attendre au moins un cycle complet avant de passer au vert. J'ai pas trouvé la technique pour passez celui-là sans m'arrêter.

les itinéraires proposés et la classification sont pertinents

Pas chez moi. Je suis plus piéton que cycliste mais j'ai testé un itinéraire qui passe autour de chez moi sur des chemins que je connais bien. Les problèmes que je relève :

• préfère un (léger) détour par une route à faible trafic plutôt que de suivre la départementale, mais la départementale n'est pas si dangereuse sur cette section alors que le détour fait traverser cette même départementale sur une intersection très dangereuse (sens interdit + peu de visibilité + plus grande vitesse que sur la section évitée).
• prend un sentier non-cyclable (en haut d'un talus avec plein de branches). J'imagine qu'il faudra que je complète OSM pour celui-ci.
• prend un bon détour par un sentier pour éviter un chemin carrossable au trafic extrêmement faible (chemin d'exploitation en forêt + accès résidentiel).
• va faire un circuit absurde sur un parking+promenade au lieu de suivre une route de centre ville (dont un bout au bord d'un quai qui doit bien emmerder les piétons).
• fait traverser une grande route pour suivre un piste cyclable (double sens, partagée avec les piétons) le long du mauvais coté de la route puis re-traverser après une courte distance.

J'imagine qu'une grosse partie de ces problèmes vient d'un manque d'informations (et de l'absurdité de certaines pistes cyclables). Mais je me demande si cet algo ne donne pas trop d'importance à la densité du trafic et à la distance parcourue pour être pertinent. Est-il plus dangereux de traverser une route ou de rouler quelques centaines de mètres le long de celle-ci ? Selon tes critères une intersection c'est zéro mètres donc zéro dangers. Est-il plus dangereux de rouler sur une route de centre ville avec beaucoup de trafic mais très lent ou sur une route de campagne sur laquelle un bolide passe de temps en temps ? (la dernière fois que j'ai fait du vélo autour de chez moi, j'ai eu un quasi-accident avec une moto sur une route très faiblement fréquentée, mais j'en fait pas en ville, donc c'est biaisé). Il faudrait peut-être aussi prendre en compte que tourner à droite à une intersection, ce n'est pas comme tourner à gauche. Il faudra aussi laisser quelques chemins pour que les piétons puissent circuler eux aussi en sécurité.

je ne vois pas en quoi la/le légende/libellé influe sur les quicktime events

Les QTE te demandent souvent d'appuyer rapidement sur le bouton représenté par son symbole sans que ça ait un rapport avec l'utilisation habituel du bouton en question. Si tu ne connais pas bien les symboles de ta manette, il faut que tu la regardes pour trouver le bouton… et c'est trop tard.

Si le symbole donne clairement la position du bouton (par exemple ◁△▽▷), on peut trouver le bouton sans regarder la manette et sans devoir la connaître par cœur.

◄▲▼► (◁△▽▷)

La manette de Nintendo 64 avait 4 boutons supplémentaires (en plus de A et B) avec des flèches, mais ils se sont fait remplacés par le second joystick, donc les flèches ne sont pas restées.

♠♥♦♣ (♤♡♢♧)

C'est le même problème que la notation Sony : la position de chaque symbole n'est pas évidente.

Utiliser execute_process c'est un peu triché même s'il n'y a pas le choix. Mais utiliser un interpréteur de script c'est pire. On pourrait remplacer l'appel de bash par un simple commande équivalente comme head -n1 (ça reste un programme externe mais au moins ce n'est pas un langage de programmation).

Il me semble que par défaut GCC cible la plateforme hôte, comme si on passait -march=native.

Chez moi la valeur par défaut est x86-64 (amd64 avec extensions jusqu'à sse2 si j'ai bien compris).

Mes résultats plus détaillés sont :

            c       c_unr   cpp     sse2
default     8.56    5.49    4.39    3.91
core2       5.42    5.16    4.38    3.89
sandybridge 5.45    5.51    4.34    3.93
haswell     5.42    5.47    4.35    3.89
broadwell   5.42    5.47    4.35    3.86
skylake     5.39    5.47    4.31    4.70

Je regarde le code désassemblé avec objdump et je n'y comprends rien. Pour find_int_c le code machine est exactement le même entre default et core2, à partir de haswell add $0x1,%rcx est remplacé par inc %rcx mais ce n'est pas ce qui fait la différence. Pareil pour find_int_sse2, à partir de sandybridge les instructions SSE2 sont remplacées par leurs équivalents AVX, mais il n'y a aucune différence entre broadwell et skylake. Des idées sur ce qui peut se passer ?

Pour la boucle déroulée sur core2, au moins je vois des différences : des instructions sont réordonnées par rapports aux autres architectures.

Je me demandais quelle était l'influence de -march=... pour ce genre d'algo. J'ai testé ton benchmark chez moi (i5-9600k) avec g++ seulement (la flemme d'installer d'autres compilateurs). Sans changer les options, je trouve des résultats similaires aux tiens sauf que benchmark_cpp est plus rapide que benchmark_c_unrolled.

Avec -march=native ou -march=skylake, benchmark_c devient aussi bon que benchmark_c_unrolled. benchmark_c_unrolled et benchmark_cpp ne bougent pas. benchmark_sse2 devient plus lent ! (plus lent que benchmark_cpp mais toujours plus rapide que benchmark_c_unrolled)

Avec -march=core2, benchmark_c est tout autant accéléré, benchmark_c_unrolled va encore un peu plus vite, benchmark_cpp et benchmark_sse2 sont aussi rapide que sans l'option.

Donc -march est bien important, mais g++ ne semble pas très bon pour les architectures récentes et sabote même l'algo sse2.

Le protocole est partiellement documenté : https://drive.google.com/folderview?id=0BxbRzx7vEV7eWmgwazJ3NUFfQ28

Ça devrait aider pour généraliser, je vois que le code utilise des rapports HID hardcodés avec des index qui peuvent changer pour chaque appareil (mais qu'il te donne si tu lui demandes poliment).

Google et Facebook ne sont pas devenus riches parce que la publicité est efficace, mais parce que ceux qui paient pour l'espace publicitaire pensent qu'elle est efficace. Le meilleur vendeur dans cette histoire c'est celui qui te vend de la publicité, pas celui qui te vend ce que présente la publicité.

si la mobilisation aux centres de vaccination n'avait pas faibli

Elle a faibli ? Sur VaccinTracker, je vois un plateau depuis début juin. Au rythme actuel, on aura vacciné tout le monde cet automne, ce qui me semble assez bon en fait.

Tu peux t'attendre au même genre de problème avec std::shared_ptr puisque s'il est créé avec std::make_shared ou std::allocate_shared, la mémoire pour les données propres au pointeur partagé et celle pour l'objet lui-même sont généralement allouées en un seul bloc. C'est en fait un fonctionnement assez proches des std::string copy-on-write puisque la mémoire était aussi partagée (jusqu'à la première écriture).

Tu installe quoi pour l'un comme pour l'autre ? Je n'ai pas ed

Étrange, c'est souvent dans le système de base. Sur Fedora, c'est le paquet ed.

ex chez moi pointe sur vim et c'est juste vim lancé en mode ex par défaut

Normal, ex c'est vi et, de nos jours, vi c'est vim.

Je ne me souviens plus de ed, mais quel est l'intérêt de ex ?

À éditer des textes sans s'encombrer de fonctionnalités inutiles comme voir le texte qu'on est en train d'éditer.

Je tente un petit benchmark vite fait, et au passage je compare aussi variable template vs. fonction.

#include <utility>

#ifdef USE_TEMPLATE
template <int N>
constexpr int count = [](){
    int s = 0;
    for (int i = 1; i <= N; ++i)
        s += i;
    return s;
}();
#define COUNT(n) count<n>
#elif USE_FUNCTION
constexpr int count(int n) {
    int s = 0;
    for (int i = 1; i <= n; ++i)
        s += i;
    return s;
}
#define COUNT(n) count(n)
#elif USE_FOLD
template <typename T>
struct count_impl;

template <int... Ints>
struct count_impl<std::integer_sequence<int, Ints...>>
{
    static constexpr int value = (0 + ... + Ints);
};

template <int N>
constexpr int count = count_impl<std::make_integer_sequence<int, N+1>>::value;

#define COUNT(n) count<n>
#endif

int main() {
    { int array[COUNT(1)]; }
    // ...
}

Je crée des tableaux de taille COUNT(1) jusqu'à COUNT(800), puis 1000 de plus avec COUNT(100). J'utilise g++ 11.0.1 et clang++ 12.0.0. Les temps sont des moyennes pifométriques calculées après quelques essais.

• g++: TEMPLATE → 530ms, FUNCTION → 450ms, FOLD → 15s
• clang++: TEMPLATE → 540ms, FUNCTION → 600ms, FOLD → instantiating fold expression with 257 arguments exceeded expression nesting limit of 256

Ce genre d'utilisations de fold expressions est clairement une mauvaise idée. Entre variable et fonction, la différence est moins nette et dépend du compilateur, donc pas de vainqueur.

Comme l'a fait remarquer SChauveau, les fold-expressions utilisent des packs. Il faut donc en créer un, par exemple avec make_integer_sequence :

template <typename T>
struct count_impl;

template <int... Ints>
struct count_impl<std::integer_sequence<int, Ints...>>
{
    static constexpr int value = (0 + ... + Ints); 
};

template <int N>
constexpr int count = count_impl<std::make_integer_sequence<int, N+1>>::value;

Mais ça utilise des templates avec plein de paramètres, sûrement très lourds. Alors qu'on pourrait simplement utiliser une boucle for.

template <int N>
constexpr int count = [](){
    int s = 0;
    for (int i = 1; i <= N; i++)
        s += i;
    return s;
}();

Mais je n'ai pas fait de benchmarks pour comparer, peut-être que je me trompe.

Donc sur PC, seulement Windows 10. Je veux dire que c'est très relatifs, selon quelles plateformes comptent le plus pour toi. Et, personnellement, pour un jeu comme Minecraft, je n'imagine pas y jouer sur autre chose que PC (clavier/souris).