khivapia a écrit 2562 commentaires

Et ? Tu crois que l'éditeur de logiciels chinois pour une vente purement chinoise se préoccupe de l'existence d'éditeurs de logiciels américains ?
Bien sûr que oui : de qui le vendeur de logiciels chinois pirate-t-il le logiciel original, sinon à un éditeur américain ?

-----------> []

En gros tu es en train de dire que le système serait anti-démocratique, parce que ceux qui sont contre une réforme seraient plus nombreux à voter que ceux qui sont pour ? (les autres s'en foutant, sinon ils iraient voter).

Tu veux dire que tous les plugins GIMP devront être réécrits pour GEGL ?? Pour la communauté GIMP, ce serait se tirer une balle dans le pied : l'idée des plugins, c'est justement qu'ils soient développés à l'extérieur… Du coup ça fera une grosse perte en fonctionnalités.

Et aussi, OCaml ne supporte pas le calcul parallèle (sur plusieurs processeurs en même temps).

un outil externe existe mais il utilise une base de données obsolète d'objectif et les données exif.
Il me semble qu'il est "relativement" facile d'intégrer un nouvel appareil / objectif à lensfun (si c'est bien de lui que tu parles) : il suffit de prendre 3 photos de la même chose à 3 focales différentes (avec le même objectif), et de pointer quelques endroits facilement repérable par un outil automatique (par exemple un coin de maison, un point d'une couleur qui ressort) et d'utiliser le bon outil.

Enfin un tuto explique ça mieux que moi http://www.vide.memoire.free.fr/photo/textes/lensfun/calibration-lensfun-hugin.php

Ça prend un peu de temps, mais le cas échéant c'est utile.

En général, les logs compressés sont uniquement les plus anciens, qu'on utilise pour audit.
Le cas d'usage présenté ci-dessus (lire les logs les plus récents pour comprendre un problème de démarrage) ne nécessite pas de les décompresser.

Pour une utilisation desktop, ne sont-ce pas les arrêts et redémarrages qui usent le plus les disques durs ?

Dans ce cas, ce serait surtout la cryptanalyse à la garde-à-vue de 48 heures avec menace d'enfermement à guantanamo / au laogai / dans les geôles secrètes iraniennes ou israéliennes.

rarement (pas pour une petite/moyenne boite) utilisée il me semble
C'est le problème avec la sécurité : d'un côté, il n'y a rien de pire que l'illusion de sécurité, de l'autre l'espionnage économique et les compromissions de firmware sont des réalités.

Je nuancerais un peu ton propos cela dit : une start-up encore petite (donc PME) mais sur des technologies de pointe est une cible royale pour l'espionnage économique (ce sont celles qui innovent le plus, et qui se protègent le moins). Les grosses boîtes sont cela dit importantes à cibler notamment pour viser leurs labos de recherche.

Par contre bon nombre de petites boîtes ne sont sans doutes pas visées, clairement. Surtout celles qui bossent dans l'open-source, vu que leurs produits sont publics :-)

Commençons par chiffrer les partitions
Oui, c'est la base, bien sûr. Et verrouiller le bios pour éviter le démarrage sur une clef USB et la compromission de /boot ou équivalent.

Ça n'est pas du tout une solution au problème que tu décris juste avant.
Dans le cas où on arrive dans une filiale, elle a déjà un accès sécurisé au réseau de l'entreprise, il suffit donc d'arriver avec sa carte à puce : pas besoin de transporter un PC avec des données confidentielles, on pourra les récupérer de l'intérieur.

Sinon effectivement, si on considère le PC comme compromis, son utilisation sur un réseau interne est à proscrire.

Ça ne change rien si le PC a été compromis à l'aéroport. Les virus de bios sont une réalité.
Il s'agit surtout de partir avec les données strictement nécessaires.

Chiffrer le disque n'est pas facile à mettre en place pour une "grosse" boîte surtout si ce n'est pas sa spécialité, et ça protègera assez peu de la rubberhose cryptanalysis (franchement, est-ce qu'à l'aéroport, fatigué avec un avion à prendre, dans un pays parfois peu connu, on a envie de vérifier que c'est bien un état de droit ? À moins d'utiliser un truc dans le genre des volumes cachés de TrueCrypt, qui ne sont vraiment pas démocratisés, et qui sont encore plus risqués si on se fait prendre).

Récupérer les données via un canal chiffré après coup est le mieux (après la valise diplomatique :-p), mais encore faut-il que le PC n'ai pas été compromis par le pays d'accueil (donc qu'on ne l'ait pas quitté des yeux à l'aéroport). Dès que le PC quitte nos yeux, il faut le considérer comme définitivement compromis (y compris avec un BIOS verrouillé : les malware dans les firmware de disque ne sont pas de la blague, cf les révélations de Snowden)

Enfin bref, le mieux pour partir à l'étranger est de n'emporter qu'un PC dédié à ça sur lequel on met le minimum de données nécessaire à l'accomplissement du voyage : si c'est une filiale de la boîte qu'on visite, il faut récupérer les données de l'intérieur via un VPN ou équivalent ; si on visite un partenaire potentiel, il ne faut mettre que les documents nécessaires à la négociation).

Je pertinente : j'ai déjà vu des personnes (pas contentes, du coup) se faire embarquer leur PC professionnel à l'aéroport, même en dehors des États-Unis, parfois pour 30 minutes, alors que des étudiants passaient leur PC sans soin particulier.

Et une autre belle perle : "Do not add rants or insults to this bug. (…) Thanks—GNOME Bugzilla Maintainers." en réponse à un mec qui dit simplement "you have no perspective of this issue at all."

C'est-à-dire, en français, "Pas d'insulte, sinon vos comptes seront suspendus" en réponse à quelqu'un qui dit (et développe avec des exemples) au développeur qui retire la fonctionnalité "je te donne des exemples d'utilisateurs, tu les trouves artificiels, tu n'as aucun recul sur ce sujet"

Ça résume bien l'état d'esprit des développeurs de GTK : leur démontrer qu'ils sont dans leur tour d'ivoire en donnant des cas d'utilisation réels et concrets est considéré comme une insulte.

Sauf si le compilateur utilise des algorithmes nondéterministes à résultat possiblement variable.
Il vaut mieux de toutes façons ne pas faire confiance à Amazon pour les binaires officiels.

ça a été testé (https://lwn.net/Articles/441018/ ), ça compile pas trop mal mais il y a des patches pour certains sous-systèmes, ça permet de profiter des "conseils" de LLVM/clang pour améliorer le code et d'une manière générale ça devrait permettre de profiter de tous les avantages d'utiliser deux compilateurs (amélioration de la qualité).

Cela dit, historiquement Linux n'est prévu pour être compilé que par GCC et utilise pour des questions de performances bon nombre d'extensions spécifiques à GCC, du coup c'est un boulot compliqué.

Il y avait eu des essais avec le compilateur d'Intel également.

C'est une extension firefox qui fait peu ou prou la même chose (envoyer des requêtes à Google), et qui mime une recherche "humaine" (relancer des recherches en changeant un mot ou deux, etc.).

S'il peut le prouver et que Mme Michu l'a accepté initialement, pourquoi pas ? Il est juste que dans le cas où elle est responsable, Mme Michu soit condamnée (d'ailleurs la pause toutes les deux heures ne soit pas obligatoire !), et pas le constructeur.

Pire, la génération automatique d'instructions vectorielles (…) reste extrêmement restreinte comparée à l'implémentation d'Intel dans ICC.

C'est de moins en moins vrai semble-t-il, pour la vectorisation au moins. Le compilateur d'Intel est toujours devant certes, mais gcc a bien remonté la pente.

http://slashdot.org/topic/bi/comparing-c-compilers-parallel-programming-performance/

Des processeurs cadancés à 1Mhz, c'était pas plutôt il y a 15 ans?
Le Pentium III date d'il y a 15 ans (1999). Il tournait à 450 MHz.

S'il n'a pas confondu MHz et GHz, il a dû se prendre un sacré coup de vieux !

Euh non je ne travaille pas dans le secteur des CPU, mes connaissances dans le domaine viennent surtout des manuels d'optimisation d'Ulrich Drepper et d'Agner Fog et du suivi de l'architecture des CPU x86 pour l'optimisation.

De ce que j'en vois, pour le HPC selon les calculs il y en a qui sont plutôt intensifs en calcul, d'autre en accès mémoire.

Pour ceux qui sont intensifs en calculs, il est raisonnable d'équilibrer les différentes étapes (schématiquement, récupération des instructions, décodage, exécution (dans différentes unités) et utilisation des résultats).

Pour ceux qui sont intensifs en mémoire, outre un peu de logique (comme le write-combining, éventuellement accessible par des instructions spécialisées pour les CPU) l'amélioration a essentiellement consisté à intégrer le contrôleur mémoire au sein du CPU, ce qui a occasionné une réduction des latences vers la mémoire (fréquence supérieure, proximité physique avec les cœurs) et une meilleure gestion des systèmes multi-sockets (plusieurs contrôleurs mémoire largement indépendants, chaque socket a son accès à sa mémoire).

Pour l'amélioration des débits mémoire, il n'y a pas de grande révolution : amélioration de la fréquence de la mémoire, ou des générations qui doublent la quantité de données transmises par cycle d'horloge (largeur de bus notamment), au prix d'une augmentation de la latence en cycles), améliorations sur les cache du CPU.
J'ai vu tourner certains codes pour CPU (pourtant bien chiadés) dont la performance était exactement proportionnelle à la fréquence mémoire, à CPU fixé, parce qu'ils dépendaient purement de la latence. Pour ces codes, la mémoire graphique serait mauvaise vu qu'elle a des timings assez élevés (bien qu'en débit mémoire elle puisse monter plus haut que la DDR). Dans une carte graphique, les latences mémoires sont moins importantes que pour un CPU vu que comme me l'a répondu Jérôme Glisse, on les masque avec du multithreading (ce qui est possible car un GPU fait beaucoup de calculs similaires)
https://linuxfr.org/news/kalray-un-processeur-massivement-parallele-tres-impressionnant-qu-il-est-loin-le-temps-de-mon-zx81#comment-1511777

Dans tous les cas, pour le code qui sera finalement exécuté et du point de vue du fondeur de CPU "généraliste", un déséquilibre entre les différentes unités d'exécution du CPU signifiera soit des performances moindres pour certains types de calculs purs, soit un investissement inutile dans l'optimisation d'une partie du CPU.

Donc la PS4 semble idéale pour des jeux (traitement des textures il me semble) ou d'autres applications gourmandes en bande passante mémoire, mais serait mauvais pour un code qui souffrirait d'une mauvaise latence mémoire (on trouve des benchmarks qui montrent que la GDDR5 a une latence 8 fois pire que la DDR3 par exemple).

Concernant ARM, j'imagine sans savoir qu'ils veulent rester aussi RISC que possible (en ajoutant des instructions SIMD cela dit) afin de diminuer les coûts de conception et le poids de l'histoire (support des vieilles instructions). Il me semble qu'ils tirent pas mal parti du fait que tout est intégré dans une seule puce. Mais de même que le CPU Jaguar de la PS4 est suffisant pour des applications de jeu mais n'est pas un processeur puissant pour le calcul pur, de même la cible de marché des ARM consiste en des applications où la capacité de calcul requise est faible (mais l'efficacité importante).
Toutefois, il est possible que la simplicité des cœurs ARM facilite le regroupement de plusieurs cœurs sur une puce pour produire des processeurs hautes performances. Enfin j'imagine (complètement :-) que le développement des CPU x86, essentiellement par Intel, s'est fait plus dans l'optique "j'ai une base de code existante (Windows & applications), que doit-on améliorer dans le CPU pour le faire tourner plus vite ?" et un peu "à l'avenir, utilisez ces instructions spécifiques pour ces cas particuliers" (genre la vectorisation). ARM, d'un autre côté, c'est plutôt "tenez, voici un nouveau processeur, recompilez vos OS pour".

Ou alors c'est utile parce que justement les GPU ont une grosse bande passante mémoire ?

La réalité est plus complexe : avec le flag adapté, le compilateur s'adapte au décodeur du processeur de sorte qu'il puisse réordonner les instructions au mieux. Réciproquement, la conception du CPU est faite de sorte à équilibrer les différentes parties (entre décodage et réordonnancement, unités d'exécution, gestion des cache et de la mémoire, etc.), du coup le décodage n'est pas nécessairement le plus gourmand en matériel.

Enfin réordonner les instructions au niveau hardware est de toutes façons nécessaire puisque les processeurs modernes ont maintenant plusieurs unités d'exécution au sein d'un même cœur.

le GPU va soit executer le group de thread A soit le group de thread B (il y a un scheduler qui décide)
En gros ça passe son temps à faire des context switch ? C'est pas pénalisant pour les performances justement ?

Dans le cas des CPU, avoir plus de threads que de cœurs n'est généralement utile que pour optimiser un code limité par la bande passante du bus mémoire en la saturant (plein de threads faisant plein d'accès mémoire pour maximiser la bande passante utilisée, avec changement de thread sur cache miss), sinon ça limite fortement l'utilisation des cache.

Ce chipset n'est que très mal supporté sous Linux, malheureusement (la faute à Intel).
Toutefois les versions "récentes" du noyau semblent en supporter le modesetting, du coup essaye peut-être la version 3.12 ?

Installe xserver-xorg-video-modesetting, regarde https://wiki.ubuntu.com/HardwareSupportComponentsVideoCardsPoulsbo/ si tu ne l'as pas déjà fait.