Pinaraf a écrit 3671 commentaires

Petite typo, on ne dit pas le fond mais le fonds…
Et super pour blender, en espérant que le fonds ne touche pas le fond :)

C'est parce que numerama a maintenant ce type de «contenu» que je ne mets plus dans mes catégories importantes de flux RSS…
Donc désormais l'azerty issu de l'IBM PC est l'azerty de Windows, il n'existe plus d'ordinateurs non Apple visibles par les plus jeunes, à part «les vieux Compaq de la salle de technologies du collège» (Compaq, disparu en 2002)…
Leur but semble d'être juste de faire à peu de frais du contenu qui apportera assez de clics pour la pub.

Je n'ai pas encore vu un environnement de dév de la sorte sous Linux (environnement tout intégré, avec GUI, etc.), c'est chose faite, bravo. :)

Il y a également Lazarus (Freepascal) qui est pas mal du tout en tout intégré. J'attends que Gambas 3.12 soit dans ma debian pour jouer un peu avec, par contre l'absence de support de windows va m'empêcher de le mettre en avant auprès de connaissances qui n'ont pas accès à mieux aujourd'hui que Excel/Access et les macros :/

Raptor CS affirme que le microcode est ouvert. Et le POWER est développé par la fondation OpenPOWER, où tout le monde peut devenir membre. Donc ça semble plus ouvert que fermé…

Alors je ne connais pas la relation entre vejmarie et OVH/Octave, mais ayant travaillé un certain temps à OVH je peux donner des pistes d'interprétation.

OVH se vante d'innover notamment sur le matériel, d'embrasser l'open source, de contribuer… Du coup des projet comme coreboot ou linuxboot, qui peuvent apporter moultes avantages pour des grands opérateurs de réseau, devraient intéresser et pousser à contribuer le «n°1 européen du cloud».
Mais à moins d'un changement radical depuis mon départ il y a 3 ans, OVH n'est qu'un intégrateur, gros certes, mais un intégrateur, donc je les vois vraiment mal contribuer à linuxboot. D'autant plus que pour ce qui est du cloud, ils sont maqués depuis longtemps avec VMWare, et le private cloud à base de VMWare étant devenu une belle vache à lait (au sens économique), à moins que VMWare se mette à certifier des machines sous linuxboot pour ESXI… c'est vraiment pas près d'arriver.

Je suis très preneur d'un journal sur LLVM orienté JIT !

J'aurais mieux fait de fermer ma gueule :)

Ça viendra, mais faut d'abord que je fasse tout un gros dev avec une vraie bibliothèque de JIT pour comparer proprement. Du coup ça va être long. Le cœur du problème pour les cas que j'ai vu : le code est émis en une seule fois (lourdement), et jamais revu après. Et je suis tombé sur au moins un cas où une phase d'optimisation indispensable pour de bonnes perfs est dans l'étape de codegen, qui n'est pas configurable.
Dans le cas qui m'intéresse, PostgreSQL 11, je suis convaincu de l'utilité du JIT par LLVM pour les grosses requêtes où le gain CPU va exploser le temps de compilation requis, mais je suis certain que ça sera en dessous des performances d'un vrai compilateur à la volée, et même dans certains cas en dessous des performances de PG sans compilation (cf. http://www.postgresql-archive.org/PATCH-LLVM-tuple-deforming-improvements-td6029385.html par exemple). Par contre, une solution bien plus légère de compilation/optimisation progressive du bytecode… ça devrait couvrir cette deuxième partie du spectre.

Je pense que les cas de unladden swallow (interpréteur python utilisant LLVM - http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html) ou encore de webkit (abandon de LLVM pour le JIT - https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/) sont assez clairs. Il est des cas que LLVM couvre excellemment, mais il ne faut absolument pas croire qu'il s'agit là du marteau universel. Ce marteau n'existe pas :)
Les langages dynamiques, l'absence d'optimisation progressive avec retour arrière… ce sont des défis que LLVM ne peut pas relever aujourd'hui. LLVM est conçu avec un modèle complètement statique, parfait pour de nombreux langages. Pour Java, à voir, mais je pense que des choses comme invokeddynamic risquent d'y perdre des plumes.

Et si cette JVM de course augmentait tellement les performances des applications que son coût serait inférieure au temps nécessaire à optimiser le code ?

Marmotte + chocolat + aluminium…

Aucune JVM, aucun compilateur au monde ne saura lutter contre le bâclage du développement.

Je vais prendre un exemple tout simple où je ne vois pas comment un outil aurait pu corriger le soucis. C'était il y a quelques années, je travaillais sur un interpréteur (très) mal codé pour un langage basic-esque quelconque (j'insiste sur la deuxième syllabe). Un bytecode était généré en mémoire, puis exécuté dans plusieurs threads en même temps (avec des données différentes). Et le temps d'exécution était linéaire avec le nombre de threads. 1 thread − 10 secondes, 2 threads − 20 secondes, 3 threads − 30 secondes (véridique).
Après quelques heures d'analyse, j'ai trouvé qu'à chaque exécution d'une instruction du bytecode, un lock était pris sur un tableau partagé entre tous les threads. Il a suffit de s'assurer que le tableau soit en lecture seule pour tout le monde pour supprimer le lock et avoir un temps linéaire, mais dans le bon sens.

Je n'ai pas fait de Java depuis trop longtemps pour donner des exemples concrets de synchronized et cie, mais ce genre de situation est bien trop courante et surtout hors d'atteinte des VMs ou des compilateurs. Quand bien même tu prouvais que la variable est effectivement bien en lecture seule passé un certain point, c'est un prédicat trop fragile s'il n'est pas garanti par le code, sinon les performances seront aléatoires : un petit changement casse cette optimisation et c'en est fini.

Et quand bien même cette VM était magiquement rapide… la JVM de base est déjà hyper optimisée mine de rien, je serais vraiment surpris de voir une différence de perfs qui soit significative. Certes c'est beau de dire «on utilise LLVM ça poutre sa race», mais la JVM a eu des années d'optimisation que le mode JIT de LLVM n'a pas eu (et pour l'avoir utilisé, c'est vraiment pas dans l'esprit de LLVM le JIT, j'en ferai un journal à l'occasion). Donc où sont les chiffres ?

Et essayer de prendre la place de Windows, iOS c'est mort aussi. Remplacer les linux, FreeBSD…ce sera difficile aussi.

Mon but dans la vie ? conquérir le monde !

La mode du cloud et du tout dans le navigateur web a cet avantage qu'il est désormais moins pénalisant d'être sur une plateforme exotique : de plus en plus de choses passent, lourdement, mais passent avec un navigateur web.
Du coup, pourquoi faudrait-il avoir pour seul but d'être premier sur un marché ? Nous ne sommes pas sur un projet d'entreprise mais un projet d'individus qui s'amusent. Et ça fait un bien fou…

J'utilise mon lecteur de flux RSS pour chercher toutes les publications depuis 2008. C'est en général suffisant. :)

Le soucis du web c'est que ça t'ajoute des tas de concepts à apprendre en plus de l'apprentissage de la programmation en elle-même.
Alors sur un hello nom, tu as du HTML et du JavaScript, ça peut passer.
Mais prenons un exemple tout simple : je veux afficher à l'écran le contenu d'un fichier (c'est avec ce genre d'exemple que j'apprenais quand j'étais petit). Pour faire ça en web, soit tu passes en 100% client avec des APIs de manipulation de fichier en JS (et je suis pas sûr qu'elles soient simples à manipuler), soit tu passes en client/serveur avec un upload de fichier à gérer. T'as à prendre en compte plein de concepts rigolos pour faire ça proprement. En desktop, avec Lazarus, tu as besoin de glisser sur ta fenêtre 1 bouton, un champ texte, un dialogue d'ouverture de fichiers, et écrire, grosso merdo…

  if OpenDialog1.Execute then
  begin
    Memo1.Lines.Clear;
    Memo1.Lines.LoadFromFile(OpenDialog1.FileName);
  end;

Je ne dis pas que c'est la panacée. Mais ça permet d'apprendre un seul ensemble langage/bibliothèque, sans avoir en plus à y ajouter des notions de client/serveur.

Après quand j'étais vraiment petit, c'était le BASIC Thomson. Là c'était simple, et un casse briques tenait sur une page de code, donc pour apprendre c'était vraiment fun (enfin, je trouvais…)

D’une manière générale, le Web est probablement ce qui est le plus abordable en informatique.

Kof !

Après avoir dit qu'il faut connaître HTML, CSS, JavaScript côté client, plus un autre langage côté serveur… On partage pas le même principe pour «abordable». :)

J'aurais dit la programmation côté bureau avec un environnement comme Lazarus pour un truc abordable (mais la doc pêche, surtout en français). Tu apprends un langage, le Pascal, et tu ne fais du code que pour la logique de l'application. Rien à écrire pour la partie hyper pénible du dessin des interfaces graphiques. Le défaut par contre, c'est où on va après ça. Il me semble qu'on peut faire de l'Android et de l'iOS avec, mais n'ayant ni l'un ni l'autre je n'ai jamais tenté…

Odoo ; le code est toujours d'excellente facture et la maintenance est assurée

Encore heureux que le code d'un ERP soit d'excellente facture… :)

Chanceux, des itanium…

Plus sérieusement, étant donné l'architecture complètement différente des itanium par rapport aux x86, je ne suis pas certain que l'on puisse transposer le gain en performances entre les architectures… De plus, selon les logiciels utilisés et le niveau d'optimisation atteint (utiliser complètement le CPU d'un itanium semble être un art obscur) tu pourrais avoir un terrain bien plus favorable à l'HT.

Dans son autre usage, compilation et construction de paquets et de systèmes, j'ai pu mesurer les écarts sur un build complet:

Avec: 1h20
Sans: 1h30

Rien de spectaculaire.

Heu… 12,5% de pertes quand on désactive HT ça te suffit pas (Ou 11,11% de gain, on va pas chipoter) ? L'HT va pas faire un x2 en perfs, mais si l'HT était bien implémenté il serait idiot de ne pas l'activer.

Si encore une fois, la désactivation de l'Hyper-threading pourrait même avoir des effets positifs sur les performances, autant en finir une fois pour toute.

Comme souvent, les performances dépendent du cas envisagé pour la comparaison. L'hyper threading est positif pour les performances sur de nombreux cas, c'est pour cela qu'il est activé par défaut, ils sont pas idiots à ce point.

Vivement les détails sur cette faille en tout cas. Impacte-t-elle uniquement Intel ? Est-ce corrigeable par le microcode ? Le même principe serait-il exploitable contre du SPARC ou du POWER ?

J'ai eu un hardreset sur mon Jolla 1 également, mais depuis toutes les mises à jour sont passées sans soucis et je suis actuellement en 2.2.0…

L'intégration de la compilation à la volée avec LLVM des requêtes n'est pas assez mise en avant de manière générale.
Même sur des requêtes en dessous de la seconde, malgré les ~20 ms de compilation, on peut avoir une division par deux du temps d'exécution… C'est bluffant et «magique»…

Il s'appelle NotReleasedYet :)
J'ai prévu de faire un journal sur ça d'ici quelques semaines, le temps de stabiliser et d'implémenter assez de fonctionnalités pour que ça soit «montrable» sans honte…

Je pense que j'étais assez explicite précédemment : je bannis les applications web de ma machine, effectivement. Je préfère Marble à * Maps, mon client Slack en Qt au client Slack web, KMail à GMail, LibreOffice à Google Doc…

On se retrouve avec des "applications" terriblement lentes par rapport aux applications natives. Sur slack par exemple, il m'est arrivé d'attendre une seconde entre ma frappe au clavier et l'affichage dans le champ d'écriture de message. Je ne parle pas de l'envoi hein, juste l'affichage du message en cours de rédaction.
Et je ne vais pas parler de la consommation de RAM. Mon PC a 8GB de RAM, ce n'est pas pour la gâcher avec chaque application qui bouffe la RAM d'une instance de navigateur web.

On prend un afficheur de documents et on le transforme en plateforme d'exécution d'applications… Tout va bien ?

Les lobbys sont normaux et je dirais même nécessaires : ils ne sont fondamentalement que l'expression d'une partie des personnes morales impactées par les politiques. On ne peut avoir des députés et ministres fonctionnant en boucle fermée, sans retour possible de la part des administrés, ça serait catastrophique (et complètement impossible à mettre en place).
Nos parlementaires et nos ministres nationaux, et de fait nos députés européens, les membres du conseil et de la commission, sont tous influençable. Et si on élit des notaires qui se fichent des papiers qu'ils signent, alors on a donné plein pouvoir aux lobbys. Mais une constitution ou un traité ne saura bloquer les lobbys, c'est la nature humaine d'être influençable par ceux qui ont une grosse voix. Le but c'est justement de réussir à parler plus fort qu'eux.
Et c'est pas en pleurnichant sur le fait qu'en face ils sont méchants qu'on fera avancer les choses. Il faudrait qu'on propose des réponses concrètes à ce qui a poussé à ces idées (par ex. comment sauver la presse), et qu'on soit suffisamment nombreux et organisés pour l'exprimer, tous unis.

Mais en tout cas, l'Europe n'est pas plus victime de lobbys que les États qui en sont membres. En France, en Allemagne, en Belgique, dans chaque État, les lobbys sont là pour essayer de faire progresser leurs idées, leurs lois. Par contre il faut avoir un registre ouvert et librement consultable de ces lobbyistes.

Et d'ailleurs :
http://ec.europa.eu/transparencyregister/public/consultation/displaylobbyist.do?id=789158412311-88

T'as raison, faut bannir les lobbys, y'a des hippies à cheveux gras qui veulent contacter nos députés.

Alleluia, nous sommes sur la même longueur d'ongle !
Après je suis méfiant sur les concertations au plus proche des habitants («not in my backyard», facilité de corruption locale par des subventions (coucou EDF, Areva))
Nous avons besoin d'une Europe forte, non libérale, et je doute qu'une démocratie locale résolve change cette orientation. Peut-être une démocratie à la grecque antique, avec nomination aléatoire de représentants ?

Certes, mais répondre par de l'humour à une blague me semblait justifié.

Donc pour répondre de manière plus complète, prenons un exemple simple, les présidentielles de 2017. Au premier tour, François Fillon avait dans son programme des propositions comme alléger les cotisations sociales des entreprises de 25 milliards d'euros par an, baisser les cotisations patronales, baisser l'impôt sur les sociétés. Pour quasiment toute la population, ce type de proposition ne peut être que perdante, nous avons des années de dons aux entreprises qui n'ont pas abouti à la moindre contrepartie pour le prouver, ainsi que de nombreuses études indiquant que ces cotisations et les aides sociales qu'elles financent contribuent à diminuer massivement l'écart de niveau de vie entre les parties les plus pauvres et les plus riches de la population. Et pourtant, malgré en plus des affaires judiciaires, 20% de la population a voté pour lui, 7 millions de personnes.
Les élections ne se font pas sur des choix purement rationnels. Nous avons en France une vision très biaisée, en particulier avec l'élection présidentielle, où il faudrait choisir l'homme providentiel qui nous sauvera de tout et décidera tout pour nous. Un tel fonctionnement n'est pas démocratique, et revient à élire un budget communication.

Donc pour revenir aux attaques précédentes :

Ou bien nous sommes trop bêtes pour comprendre que c'est bien d'avoir du glyphosate dans nos légumes,

En France la FNSEA, et au niveau européen des personnes comme notre ministre de l'agriculture ainsi que les lobbys, s'évertuent à répéter qu'il n'y aurait aucune alternative et que l'on tuerait notre agriculture et devrait importer notre nourriture de pays moins contraignants.
Donc oui, nous sommes trop bêtes pour comprendre qu'en votant pour des idéologies libérales des choix libéraux sont réalisés.

que c'est cool les perturbateurs endocriniens dans nos plastiques,

Je n'ai pas de noms, mais la logique est similaire.

que c'est super de privatiser nos barrages hydrauliques,

Hé oui, nous avons choisi un modèle ultra libéral et refusons de nous y opposer… trop bêtes, trop bêtes…
Sainte concurrence, priez pour nous !

que c'est très utile de ne surtout pas mettre en place les systèmes de consignes pour les bouteilles en plastiques ?

Je préfèrerais un système de réutilisation volontaire des bouteilles à l'aide d'un système de vrac plutôt qu'une consigne… et surtout pas de bouteilles en plastiques !

Et tout le monde abandonne Electron ? Alors là je dis oui, oui oui et re-oui !

Du coup les citoyens votent pour des gens qui prennent des décisions contre les intérêts des citoyens ?

Oui.