Durant toutes ces années, j'ai nourri l'idée que si un PC ralentissait, c'était parce que Windows installait plein de trucs infâmes.
Pourtant, force est de constater à présent que mes PCs Linux deviennent de plus en plus lents et nécessitent un reformatage annuel, quelque chose que je pensais réservé au Windowsiens.
Pire : malgré reformatage, les PCs restent beaucoup plus lents qu'avant et je ne l'explique pas vraiment.
Alors, selon vous, qui est responsable de la lenteur ?
Usure mécanique (notamment pour les HDD qui tournent moins bien et les ventilations qui s'encrassent)
Structure du disque dur qui se corrompt (bad sector) et également, au fil des années sans reformatage, un fragmentage important ? (pour l'anecdote, j'ai un SSD qui ne supporte pas TRIM et, au bout de 3 ans, c'est presqu'inutilisable).
Encombrement logiciel (fichiers de conf et formats de cache qui se transmettent par delà les upgrade et génèrent des bugs)
Évolution du logiciel (les logiciels ne sont plus testés avec d'anciens matériels et buttent sur des petites incompatibilités)
Évolution de notre perception (cela a toujours été lent mais on s'habitue à plus rapide)
Un mix de tout ça ?
Enfin, bref, tout ça parce que je jette l'éponge sur un de mes desktops qui est passé depuis 7 ans par toutes les versions d'Ubuntu et qui, à présent, se vautre sans raison (le menu Unity ne trouve pas la moitié des applications genre le terminal, Chromium crashe lorsqu'il y a plus de 2 tabs ouvertes, Firefox ne détecte aucun plugin et refuse de les installer). Ce n'est pas venu d'un coup mais ça a vraiment été progressif au cours des 3 dernières années, malgré des ré-installations et un check du disque dur. Mais je constate le même genre de soucis sur d'autres ordinateurs de la même génération.
Donc je cherche un mini PC de bureau qui soit le plus silencieux, le moins cher possible, avec minimum 4Go de RAM et un connecteur VGA (ou alors, un bon connecteur HDMI -> VGA mais toutes les critiques sur Amazon pour ce genre de produit sont affolantes).
Merci :-)
# Bonne section ?
Posté par Prosper . Évalué à 10.
Bonjour
Tu dois être sûrement nouveau ici, mais ce genre de demande est à faire dans la partie forum du site et non pas dans les journaux.
Merci,
Cordialement Réfa.
[^] # Re: Bonne section ?
Posté par Bastien Mourgues . Évalué à -10.
"ploum a écrit 609 contenus" … pas mal pour un "nouveau" :)
Au vu des crash aléatoires, tu devrais peut être aussi envisager de faire tourner memtest (ou équivalent) pour contrôler la bonne santé de ta RAM, peut être …
[^] # Re: Bonne section ?
Posté par Marotte ⛧ . Évalué à 10.
Tu dois certainement être nouveau ici ;)
[^] # Re: Bonne section ?
Posté par dyno partouzeur du centre . Évalué à 0.
C'est triste ton avis sur l'humour
[^] # Re: Bonne section ?
Posté par Egide Dey . Évalué à -8.
avant de dire n'importe quoi : http://linuxfr.org/news/installation-de-debian-facile--2
avec plus de 600 contributions, ce n'est pas un nouveaux…
Bonne journée à tous (^_^)
[^] # Re: Bonne section ?
Posté par claudex . Évalué à 10.
Tu dois certainement être nouveau ici.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Salut
Posté par Marotte ⛧ . Évalué à 7. Dernière modification le 01 juillet 2014 à 17:17.
Annuel ?! Mon record c'est 7 ans sans réinstaller en Debian unstable… J'ai fini par réinstaller, pas parce que s'était lent mais parce que c'était un beau bordel et que c'est toujours un plaisir d'installer une Debian toute fraîche, puis ses logiciels favoris, repartir sur une base propre en quelque sorte. Là j'ai une nouvelle machine qui a environ 4 ans, j'ai jamais eu à réinstaller…
J'ai un doute, le DD il tourne ou il tourne pas non ? Est-ce qu'une usure mécanique peut faire que le DD fasse plus d'erreurs (erreurs « invisibles » car corrigées par le firmware) ?
Effectivement le pourcentage de fragmentation augmente avec le temps. D'ailleurs pour défragmenter un EXT4, il faut formater et remettre les données dessus ? Pas d'autre moyen ?
Oui c'est rare que ça ne devienne pas un beau bordel, en particulier si on bidouille un peu…
À voir. Est-ce que l'on a des exemples de machines qui tourneraient mieux avec un noyau ancien qu'avec un récent ?
Probable, mais là encore, sur un ans ça me semble court.
T'as testé la RAM de ta radouille ? Est-ce que ça ne fonctionnerait pas mieux avec une distrib' adaptée aux petites configurations ?
[^] # Re: Salut
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
La config était très bonne pour l'époque et reste tout à fait honnête (Intel 2GHz, 2Go de Ram). Mais faudrait en effet peut-être que je vérifie la RAM, je me rends compte que c'est le seul test que je n'ai pas fait !
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Salut
Posté par Marotte ⛧ . Évalué à 5.
Oui, car que l'ordi rame avec des logiciels trop récent pour le matériel je veux bien, mais qu'il plante c'est quand même étonnant. Donc oui, la RAM à vérifier. Pense aussi à regarder l'état des condensateurs sur ta CM, s'ils seraient pas gonflés sur le dessus…
[^] # Re: Salut
Posté par Big Pete . Évalué à 10.
Regarde si ça en vaut la peine au niveau finance, mais doubler la ram et remplacer le disque par un SSD, ça permet de prolonger un peu la vie des vieux bouzins. J'ai fait ça (3Go de ram et 128 Go de SSD) à un X60 qui a 9 ans et qui me dépanne bien. Mais bon, sur un thinkpad de cette génération, vu la qualité de fabrication, ça vaut le coup.
Hé, c'est pas non plus une bête de course, mais ça rame quand même moins que le machin tactile android tout récent que j'ai eu le malheur d'acheter dans un moment de faiblesse.
On m'y reprendra plus.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: Salut
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Un cas typique, c'est une barrette débranchée, et tu tournes avec 1Go de ram, en swapant à fond.
Aujourd'hui, même 4Go, c'est pas beaucoup. Le passage 32 à 64 bits a ralenti la progression moyenne. 4 Go est fournis depuis au moins 5 ans, mais les programmes continuent de demander toujours plus (surtout firefox ou chrome : 1 Go minimum)
"La première sécurité est la liberté"
[^] # Re: Salut
Posté par gnx . Évalué à 5.
Ça m'est arrivé durant la dernière année, en effet !
Ça fait plusieurs fois que lis que « 4Go, c'est pas beaucoup » ces derniers jours. Il ne faut pas exagérer non plus. J'ai depuis peu 2 Go et c'est Byzance.
Et pour le coup de la barrette débranchée, quand je l'ai renclenchée, ça m'a fait passer à… 1 Go ! Donc avec 512 Mo, j'avais en permanence une dizaine de terminaux, un butineur avec une dizaine d'onglets, un client mail graphique, un client IRC, un lecteur RSS, deux éditeurs de texte graphiques avec plusieurs onglets, une dizaine de PDF ouverts, un éditeur de schémas électroniques/PCB, un lecteur de MP3 et j'en oublie, ainsi que temporairement un lecteur de vidéo, une compilation ou une synthèse de VHDL. Par contre, je n'utilisais pas d'environnement de bureau à la KDE ou Gnome… Alors 4 Go, franchement…
Le seul problème arrivait avec le butineur, pas pour les sites «nbsp;normaux », mais lorsque je tombais soit sur une page avec beaucoup de Javascript, soit sur une page de forum avec énormément de grosses photos (dans ce dernier cas, le pilote graphique X plantait carrément et X se suicidait).
[^] # Re: Salut
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Tu ne devais pas avoir grand chose en nombre de porte pour ta synthèse VHDL. Sur mon PC de bureau 8 Go avec Seven, j'ai du remettre le swap car cela pouvait figer avec 2 ou 3 eclipses, firefox et chrome.
"La première sécurité est la liberté"
[^] # Re: Salut
Posté par freem . Évalué à 4.
C'est de l'humour?
8Go avec seven, eclipse et des navigateurs internet mainstream, ça ne me surprend pas que ce soit insuffisant…
[^] # Re: Salut
Posté par gnx . Évalué à 3.
En effet, c'était juste de petits bricolages.
Cependant, je me rappelle synthétiser des projets complets pour des FPGA remplis à mort (certes les FPGA étaient plus petits que de nos jours) sur une petite station de travail et un PC de bureau vers… 1998 (?). Bon, sur le PC sous Windows, ça swappait à mort, ça prenait la moitié de la nuit et en général Windows avait planté quand tu revenais :-) Mais je te laisse imaginer (car je ne m'en rappelle plus) la quantité (standard) de RAM de l'époque. 32 Mo ? Autant dire qu'on était loiiiiiin de 8 Go :-)
Et dans la première moitié des années 2000, sur des configs standards (128 Mo ? 256 Mo ?) ça passait tranquille.
C'est juste quelques témoignages, je veux bien imaginer qu'un FPGA de génération récente, de haut de gamme et bien rempli (ou bien un ASIC) puisse demander énormément de RAM si la gestion de la RAM au cours de la synthèse n'a pas trop été améliorée.
[^] # Re: Salut
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 02 juillet 2014 à 15:02.
Whoa. Il faut que j'examine ce qui cliche avec mon netbook alors (un EeePC 1015T). Malgré son 1 Go de RAM, sous la dernière Xubuntu, il est à la limite de l'inutilisable (si j'ouvre plus d'un onglet et que l'un d'entre eux est Gmail, ça va presque plus vite de le redémarrer de force que de faire Ctrl+Alt+F1 et "killall firefox").
[^] # Re: Salut
Posté par Sytoka Modon (site web personnel) . Évalué à 9.
Le mien a 7 ans et demi et marche super ! Il faut dire que je tourne sous XFCE dessus.
Recette -> mise à jour régulière + ménage
apt-get dist-upgrade
apt-get --purge autoremove $(deborphan)
deborphan -a
apt-show-version
dpkg --get-selections | grep deinstall
du -sm $HOME/.[a-Z]* | sort -n
[^] # Re: Salut
Posté par ZeroHeure . Évalué à 4.
Le mien (celui sur lequel je tape) a 12 ans je pense. Un céléron mono coeur (un P4 quoi) à 2,28 GHz et 768 Mo de Ram. Deux disques d'époques en raid 10 et rien d'autre sur les ports IDE. Tourne très bien avec le dernier KDE et Debian. Ah oui, j'utilise Qupzilla plutôt que Firefox.
Evidemment, il y a 12 ans avec KDE 3.5, Firefox 1 ou 3 et Konqueror, c'était un foudre de guerre. Le web était plus simple, j'avais moins de courriels, pas d'IMAP et 2 comptes email au lieu de 4.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Salut
Posté par Prosper . Évalué à 3.
Ta grappe raid est constamment dégradée ?
[^] # Re: Salut
Posté par ZeroHeure . Évalué à 0. Dernière modification le 02 juillet 2014 à 17:43.
RTFM ! Linux Raid Wiki. Faudrait se mettre à jour quand même… Le Raid 10 est possible et très performant sur des configurations à 2, 3, 5 disques, etc. Très grossièrement, ça marche par répartition et duplication des données sur l'ensemble des disques plutôt que disque par disque.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Salut
Posté par Prosper . Évalué à 1. Dernière modification le 02 juillet 2014 à 17:45.
Donc si tu perds un disque tu perds tout ? quel interet par rapport a du raid0 par exemple ?
[^] # Re: Salut
Posté par ZeroHeure . Évalué à 1.
Mais vas-tu au moins lire les docs qu'on te met en lien, avant de sauter sur ton clavier?
C'est du Raid 10, tu perds un disque tu ne perds rien. Et c'est aussi rapide que du Raid-0. Avec 3 disques durs (et une bonne carte) en Raid-10 et une config n2 f3 (ou l'inverse peut-être je ne sais plus) les perfs sont meilleures que du Raid-0.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Salut
Posté par Prosper . Évalué à 3. Dernière modification le 02 juillet 2014 à 18:06.
Oui la prochaine fois balance moi carrément la page https://wiki.kernel.org/ histoire que ca soit encore plus simple !
Et non c est pas du raid10 au sens classique , c est du raid10 sauce linux ( ce que tu n'as abolument pas precisé avant que je te pose la question ) , sur wikipedia c'est considéré comme non standard RAID ( cf Non-standard_RAID)
Fin.
[^] # Re: Salut
Posté par ZeroHeure . Évalué à -1.
Et pourquoi j'aurais du préciser ? c'est toi qui est intervenu.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Salut
Posté par claudex . Évalué à 6.
C'est toi qui parle de raid10 à la base.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Salut
Posté par ZeroHeure . Évalué à -4.
Non à la base c'est Ploum qui parle de PC Linux ralentis. On est quelques-uns à lui répondre que nos vieux coucous passent encore assez bien. Je mentionne les disques en Raid-10 de ma config parce que c'est pertinent.
Depuis 20 ans que je hante les forums Linux je ne me sens pas obligé de préciser chaque fois les détails anecdotiques de ma config. Et je suppose que les lecteurs qui m'interpellent savent de quoi ils parlent.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Salut
Posté par Prosper . Évalué à 10.
Sauf que pour 99.999% des gens, le raid10 c'est 4 disques, et de parler d'un raid10 avec 2 disques ça fait forcément tiquer. Ce que tu utilises est très loin d'être commun ou trivial, d'ou les questions qui en découlent. Et répondre RTFM en balançant l'index d'un site qui pointe vers 40000 docs (où d'ailleurs cette config est à peine mentionnée) c'est pas vraiment le plus plaisant dans un commentaire. Bref restons en là.
[^] # Re: Salut
Posté par Prosper . Évalué à 2.
J'aime ce ton méprisant et hautain enfin bon.. mettre cette page directement ça t'aurait arraché la g*** ? Ca n'explique d'ailleurs pas vraiment pourquoi j'ai compris en allant sur http://serverfault.com/questions/139022/explain-mds-raid10-f2.
[^] # Re: Salut
Posté par ZeroHeure . Évalué à 4.
Non mais ça va pas ?
J'ai passé 15 minutes à rechercher les références pour ne pas balancer RTFM tout seul. Ne les retrouvant pas, j'ai ajouté 3 lignes d'explications. Faut pas prendre la mouche comme ça.
Allez bisou et rejoins moi en terrasse pour une grenadine!
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Salut
Posté par NeoX . Évalué à 5.
pour moi, ca c'est un raid dégradé
reste à savoir si c'est le 1 ou le 0 du raid10 qui ne fonctionne pas.
[^] # Re: Salut
Posté par ZeroHeure . Évalué à 0. Dernière modification le 03 juillet 2014 à 19:03.
Bon y'en a un qui suis. Un disque était accidentellement débranché.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Salut
Posté par KiKouN . Évalué à 2.
Oui, pas mal. Mais c'est dommage, il ne lui manque qu'une fonctionnalité pour mon utilisation : le "Tree Style Tabs".
Mais je le garde sous le coude.
[^] # Re: Salut
Posté par Renault (site web personnel) . Évalué à 4.
Il est possible aussi que l'usure des composants comme la RAM, le processeurs et autres (par dilatation thermique et usure électrique) augmentent le nombre d'erreurs matériels qui doivent être corriger ce qui prend du temps.
[^] # Re: Salut
Posté par galactikboulay . Évalué à 4.
Sauf erreur de ma part, à moins de disposer de RAM ECC pour la mémoire (ce qui n'est généralement pas le cas sur des machines grand public), il n'y a pas de rattrapage possible dans ce genre de cas. Après l'erreur peut passer relativement inaperçue si la zone mémoire n'est pas utilisée.
Pour les CPU, s'il y a un défaut permanent sur un transistor ou sur une piste, il va être bon à jeter aussi.
[^] # Re: Salut
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il y a de l'ECC dans les caches internes des cpu, mais si le cpu ralenti, je penche plus sur une mauvaise diffusion de la chaleur qui le force à descendre plus souvent en fréquence. J'imagine que nettoyer les ventilateurs peut aider.
"La première sécurité est la liberté"
[^] # Re: Salut
Posté par ploum (site web personnel, Mastodon) . Évalué à 0.
Très intéressant, je ne connaissais pas ce type d'usure !
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Salut
Posté par galactikboulay . Évalué à 6.
Je pense qu'il veut parler d'électromigration
[^] # Re: Salut
Posté par deasy . Évalué à 2. Dernière modification le 02 juillet 2014 à 00:35.
Et amd donnait 15ans pour un cpu avant que l'électromigration se fasse sentir.
Il y a de ça qqs années.
[^] # Re: Salut
Posté par romain11 . Évalué à -2.
Les circuits qui génèrent les fréquences s'usent avec le temps (et surtout la chaleur), ce qui a pour effet de ralentir le processeur. Désolé je n'ai pas de source
[^] # Re: Salut
Posté par dyno partouzeur du centre . Évalué à 3.
Sinon c'est probablement le réservoir de poudre verte qui est vide.
# Psycho
Posté par Anonyme . Évalué à 5. Dernière modification le 01 juillet 2014 à 17:26.
En un an je ne pense pas que les logiciels soient à mettre en cause.
Pour ma part j’ai remarqué une légère amélioration en ne mettant pas tous les œufs dans le même panier :
/, /usr, /var, /var/cache/ et /home sur des partitions différentes.
Enfin, je crois que le psycho joue un peu. On s’habitue. Et quand je réinstalle, je ne peux m’empêcher de me dire « chouette ça va être plus rapide » pendant une demi seconde, alors que c’est faux.
Je ne crois pas que ton PC soit plus lent, en fait.
Ceci dit, un peu de nettoyage (souflette) sur les composants électriques ne pourra pas leur faire de mal.
[^] # Re: Psycho
Posté par GG (site web personnel) . Évalué à 8.
Température du CPU?
Si le CPU est trop chaud, l'ordinateur peut passer dans une fréquence plus basse.
Et, est ce qu'il n'y aurait pas des démons qui tourneraientt en arrière plan? installés un jour, puis oubliés?
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Psycho
Posté par Marotte ⛧ . Évalué à 3. Dernière modification le 02 juillet 2014 à 01:33.
et /var/lock, /var/run, /run et autres du même acabit sur un tmpfs
la désactivation de la mise à jour du atime (access time) sur les fs pour lesquels on s'en fout ça joue aussi me semble-t-il.
[^] # Re: Psycho
Posté par ckyl . Évalué à 3.
relatime est par l'option par défaut depuis 5 ans. Ca limite fortement les cas où noatime change quelque chose.
[^] # Re: Psycho
Posté par fridim . Évalué à 3.
Puisqu'on est sur ce genre d'astuces, j'ai aussi mis ça en tmpfs :
plop:~$ grep tmpfs /etc/fstab
tmpfs /tmp tmpfs nodev,nosuid 0 0
tmpfs /home/fridim/.cache tmpfs nodev,nosuid,uid=1000,gid=1000,mode=1700,size=2G 0 0
.cache qui est (pas mal) utilisé par les applications (firefox, chrome, …)
[^] # Re: Psycho
Posté par KiKouN . Évalué à 10.
Je pense aussi que plus un PC devient vieux plus on a l'occasion de le comparer à des PC plus puissants. Si bien que l'on trouve qu'il devient lent alors que c'est juste les autres qui sont plus rapides.
[^] # Re: Psycho
Posté par Dr BG . Évalué à 8.
Tout à fait, mais dans ce cas, on ne le trouve pas magiquement plus rapide en réinstallant tout.
# logiciels de plus en plus gourmands ?
Posté par Zorro (site web personnel) . Évalué à 7. Dernière modification le 01 juillet 2014 à 17:37.
Change de distribution et passe à ArchLinux, tu verras tout est mieux et plus beau !
Bon, sérieusement : j'ai aussi cette impression, quand je mets à jour les logiciels. Je pense que les logiciels demandent, à chaque nouvelle version, un peu plus de puissance. C'est flagrant pour Google Chrome, par exemple, qui commence à ramer sérieusement sur mon portable (un Celeron, ok, mais y a encore 1 an, il ramait pas du tout, c'est même pour ça que je l'avais choisi comme navigateur principal sur ce PC). Et comme sous Arch, les mises à jour se font en permanence, ben mon PC rame de plus en plus. C'est ballot.
Maintenant, si ton PC rame de plus en plus alors que tu n'y fait pas de mise à jour, alors oui, c'est bizarre.
[^] # Re: logiciels de plus en plus gourmands ?
Posté par gnx . Évalué à 10.
Bloatisation des logiciels et windowisation des environnements sont les deux mamelles du ralentissement :-)
[^] # Re: logiciels de plus en plus gourmands ?
Posté par Renault (site web personnel) . Évalué à 10.
En général les logiciels augmentent la quantité de fonctionnalités, gèrent des formats de plus en plus volumineux (multimédia bonjour), ont des interfaces plus sophistiqués pour que ce soit plus simple ou agréable mais nécessitent du calcul supplémentaire, etc.
Tout ceci a un coût incompressible et ce n'est clairement pas un recul. Il n'y a pas que la malfaçon pour expliquer l'alourdissement logiciel.
# Même constats
Posté par Olivier (site web personnel) . Évalué à 10.
1: Fragmentation
J'ai une partition EXT4 sur lequel j'ai plusieurs flux de logs qui s'enregistrent en permanence et en parallèle (=> mauvais pour la fragmentation). Les fichiers les plus vieux (plusieurs Go par fichiers) sont purgés automatiquement lorsque il ne reste plus assez de place (=> encore plus mauvais pour la fragmentation).
Sur cette partition j'ai observé au fil du temps des baisses progressives de vitesse de lecture des fichiers (de 60Mo/s à 15Mo/s). A partir de ce moment là, le taux de fragmentation (indiqué par fsck.ext4) était supérieur à 50%.
En reformatant la partition et en remettant les derniers logs, la vitesse de lecture est revenu à 60M/s.
Conclusion : La fragmentation a vraiment un méchant impact sur les perfs d'un disque dur, spécialement lorsque 1) on y fait des écritures en parallèle (ex: les logs, qui allouent de petits blocs à chaque fois) ou 2) lorsque le disque est maintenu plein en permanence (ajout et suppression régulière de données).
2: Vieillissement du disque dur
Avec les temps, la mécanique du bras des têtes de lecture est moins précises. En cause, la graisse de l'axe de rotation du bras qui freine aléatoirement le déplacement du bras. Celui-ci a alors un déplacement de type "serpent" lorsqu'il doit se repositionner pour lire/écrire un nouveau bloc. Ces "hésitations" du bras coûte cher en milli-secondes, d'où une baisse de vitesse dans la lecture/écriture aléatoire de données.
3: Mise à jour:
Certaines distributions plus que d'autre ont tendance à laisser plein de vieux soft ou de veilles configurations après des mises à jour. Un grand nettoyage est parfois nécessaire.
Personnellement, je trouve qu'Ubuntu est assez pénalisée par ce phénomène, spécialement lorsque l'on fait les mises à jours tous les 6 mois.
A titre personnelle, j'avais une Debian Testing i686 qui a durée plus de 6 ans. Elle marchait encore bien, même après cette durée, mais je voulais un peu plus de réactivité. J'ai profité du passage au SSD pour la réinstaller en AMD64, les performances ont bien entendu été bluffantes.
[^] # Re: Même constats
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Super intéressant, merci !
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Même constats
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Ceci dis, j'ai personnellement tous mes homes sous XFS. Je n'ai jamais eu l'impression que XFS se dégradait. D'ailleurs, la dernière RHEL bascule en XFS même sur le slash. En général, Red-Hat est assez sévère quand au système de fichier qu'il accepte.
[^] # Re: Même constats
Posté par xcomcmdr . Évalué à 4.
Tout système de fichiers se fragmente.
La seule vraie solution, c'est un SSD.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Même constats
Posté par mornik . Évalué à 1.
Tu n'as pas les même pbs ? Si la zone entre 2 deviens pourrie, tu as aussi une forme de fragmentation non ?
[^] # Re: Même constats
Posté par Prosper . Évalué à 7.
La fragmentation sur un SSD n'a aucun impact ou presque sur les performances .
[^] # Re: Même constats
Posté par Boa Treize (site web personnel) . Évalué à 5.
Par contre, sur de nombreux modèles, le taux de remplissage du disque a de l'importance. Au delà de 75%, les performances peuvent sérieusement se dégrader. Et par ailleurs, également sur de nombreux modèles, les performances en sortie d'usine, sur de la flash quasi vierge, vont rapidement baisser pour atteindre leur régime de croisière. Les mesures trop tôt dans le cycle de vie du SSD peuvent donc être trompeuses.
Cf. les graphes de cet articles, par exemple : http://www.anandtech.com/show/7006/sandisk-extreme-ii-review-480gb/2 (jouez avec les boutons pour afficher différents modèles).
[^] # Re: Même constats
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
C'est l'histoire de la write amplification, quand il n'y a plus de bloc vierge.
La command TRIM limite le problème.
"La première sécurité est la liberté"
[^] # Re: Même constats
Posté par ckyl . Évalué à 10.
Tu as effectivement le même au problème au niveau du fs. Mais la fragmentation est uniquement un problème liés aux propriétés mécaniques d'un disque dur. Déplacer la tête prend une éternité, ~5ms, alors qu'une lecture aléatoire sur un SSD c'est ~15μs.
Donc oui tu as de la fragmentation, mais non ce n'est pas un problème.
[^] # Re: Même constats
Posté par mornik . Évalué à 2.
Merci.
[^] # Re: Même constats
Posté par mornik . Évalué à 4. Dernière modification le 02 juillet 2014 à 00:16.
Selon la docd'ubuntu :
Ext4 a une option : extents qui permet de limiter grandement et automatiquement la fragmentation du système de fichiers
Selon la doc d'ArchLinux :
pour mesurer le taux de fragmentation d'une partition xfs (avec un exemple de mon /home tout pourrit et j'ai pas de ralentissement sur une debian stable, de stable en stable depuis quelques années) :
$ xfs_db -c frag -r /dev/sdb1 │
actual 563293, ideal 548197, fragmentation factor 2,68%
Avec sur la fragmentation d'un disque en xfs :
http://archive09.linux.com/articles/141404
Un lien pour nous dire que la defrag sur ext[234] c'est possible mais moins nécessaire que sur d'autre fs :
http://en.wikipedia.org/wiki/Ext3#Defragmentation
Mythe ou réalité ? A priori on est encore loin d'un autre fs : qui defragmente tous les mercredi
Il est possible qu'il te faille choisir un autre fs plus adapté à tes fichiers (petits/gros ?) Je rappel que pendant longtemps Mysql préconisait d'utiliser xfs pour le fs hébergeant ses tables MyIsam. Reiser4 était aussi intéressant pour ceux qui avaient beaucoup de petit fichiers sources (gentoo :p )
[^] # Re: Même constats
Posté par Laurent Cligny (site web personnel) . Évalué à 9.
Hélas, ce FS est mort et enterré.
[^] # Re: Même constats
Posté par Obsidian . Évalué à 10.
Mais personne ne sait où… /o\
→[]
[^] # Re: Même constats
Posté par Frank-N-Furter . Évalué à 4.
Calomnies, il est parti rendre visite à sa mère et n'est jamais arrivé.
Depending on the time of day, the French go either way.
[^] # Re: Même constats
Posté par téthis . Évalué à 3.
It's not dead, it's resting
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: Même constats
Posté par freem . Évalué à 2.
A ce sujet, et au sujet des logs, j'imagine que choisir un "usage" pertinent (taille de blocs) peut aider? par exemple, dans le cas des logs, utiliser des blocs les plus grands possibles pour /var/log (/var tout court pour ma part, sachant qu'avec les caches de paquets et autres joyeusetés les fichiers ne sont pas super petits) permets de réduire la fragmentation ce me semble.
Je crois (pas sûr du tout) que extfs ou je ne sais quoi, le truc qui se lance automatiquement tous les N montages, défragmente les partitions de type EXT.
Donc, oui, du ext ça fragmente et ce n'est pas nouveau. Juste moins que NTFS et sans commune mesure avec FAT, mais comme pour ces deux concurrents, il est possible de défragmenter, j'en suis presque sûr.
[^] # Re: Même constats
Posté par claudex . Évalué à 4.
Il ne fait pas ça du tout. ext4 est en théorie défragmentable mais il n'y a aucun outil fiable pour ça.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Même constats
Posté par ckyl . Évalué à 7.
Tu as quelque chose de spécifique à reprocher à e4defrag ?
Après si tu n'as pas besoin de le faire online, un bête cp ou tar/untar fait le job. C'est l'outil du pauvre mais ca a marché pendant toutes les années ou des benêts ont essayé de nous expliquer qu'il n'y avait pas besoin de défragmenter sous Linux…
[^] # Re: Même constats
Posté par claudex . Évalué à 3.
J'en était resté au fait qu'il n'était pas encore conseillé de l'utiliser sur des vraies données. Mes informations n'étaient pas à jour.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# on a connu ploum plus rigoureux. :)
Posté par Le Gab . Évalué à 6.
Comment arrives-tu à lier ce genre de problème à une hypothétique usure matérielle?
As-tu la même distro sur tes autres desktops?
La différence en perf du matériel est de quel ordre? Si même Distro, rencontres-tu les même instabilités?
As-tu simplement tenté une installation fraîche? Reste sur Ubuntu ou passe à Debian, ne te disperse.
Finalement, un passage à 4 Go ou plus vu le coût dérisoire pour de la DDR2 (machine >= 7ans) ne peut pas faire de mal.
Après, il peut y avoir d'autres raisons à vouloir changer: conso électrique pour le rendement, encombrement, bruit ;)
```
[^] # Re: on a connu ploum plus rigoureux. :)
Posté par Chris K. . Évalué à 2. Dernière modification le 02 juillet 2014 à 15:21.
J'aurai aussi tendance à lier cela au matériel. A part la fragmentation du disque ou un problème important d'interface chaise clavier - ce dont je doute avec Ploum - je ne vois pas comment une installation de linux pourrait se dégrader en un an par le logiciel.
J'ai, sur une de mes machines, une debian qui a passé les 13 ans (installation début 2001) et elle se porte comme un charme, aucun soucis de performance.
Au vu des crashs des applications ça pourrait bien être un problème de RAM.
Sinon un vieux disque système, des composants qui chauffent trop ou encore qui on trop chauffé et pris une claque peuvent causer toute sorte de problèmes bizarres.
J'ai le souvenir de la carte mère DFI pour Athlon XP d'un ami sur laquelle l'installation de windows s'était révélée impossible et cela quelque soit le cd ou la RAM utilisée. Le pc se figeait. J'ai pu installer et démarrer une netinstall debian qui était effroyablement lente avant de remarquer l'état lamentable de certains condensateurs sur la carte qui avaient chauffé et coulés à proximité du radiateur du processeur.
[^] # Re: on a connu ploum plus rigoureux. :)
Posté par jolitorax . Évalué à 2.
Si tenté que la carte mère la supporte. Mon PC fixe de 7 ans a 2 Go de mémoire et c'est le maximum supporté par la carte.
[^] # Re: on a connu ploum plus rigoureux. :)
Posté par Frank-N-Furter . Évalué à 6.
Si tant est que
Depending on the time of day, the French go either way.
[^] # Re: on a connu ploum plus rigoureux. :)
Posté par Le Gab . Évalué à -1.
ok ok, encore faut-il acheter autre chose que du matériel bas de gamme.
Les cartes mères (DFI, ASROCK et autres) qui font même le café à 60€, devraient mettre la puce à l'oreille.
[^] # Re: on a connu ploum plus rigoureux. :)
Posté par jolitorax . Évalué à 1.
C'était un moyen de gamme à l'époque et le seul 64 bits dans mon budget. Dans ces années là, les processeurs 32 bits étaient les rois de l'entrée et du moyen de gamme. Le 64 bits étaient le haut de gamme et coûtaient logiquement le double.
J'ai choisi un 64 bits à la maison car l'on commençait à recevoir des serveurs qui le supportait, ce qui m'a permis de tester les premières distributions Linux en 64 bits.
# Pourquoi un PC ralentit-il ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Pour qu'il puisse être dépassé ?
Jérôme Legal, humoriste, ->[]
# Nouvelles versions de logiciels, toujours + lourds
Posté par marzoul . Évalué à 2. Dernière modification le 01 juillet 2014 à 23:53.
Il fut un temps où mon pentium III 450MHz avec ses 512ko de cache, et 768Mo de sdram, ça tournait du feu de dieu. clic sur l'icône firefox, lancé en une seconde. Les versions d'avant la 3.5…
Maintenant, Core2 Duo 1.8GHz 2Mo de cache et de la mémoire hachement plus rapide, firefox met plusieus secondes.
Ça part bien entendu d'un bon sentiment de rejouter de fonctionnalités de tueur, du truc d'introspection partout en cliquodrome et de tonnes de choses pour développeurs, mais quel est le pourcentage de gens concernés ? Kédal. Certaines choses devraient être séparées et optionnelles.
Je remarque aussi que plus le temps passe, plus certaines libs sont forkées (ffmpeg/libav…), plus il existe de libs pour faire des choses de même finalité telle que vue par le quidam (json-c/jansson/glib-json, clang-llvm/gcc…), plus on doit faire cohabiter plusieurs versions d'une même lib parce que tout n'est pas mis à jour (gtk2/gtk3, les versions de python…), et ça participe au fait que l'installe système grossit très vite quand on installe des applis. Les développeurs choisissent selon leurs propres affinités/spiritualités de quelle lib et version leur logiciel va dépendre. Une fois qu'on lance tout ça, ça pollue la ram et le cache.
Un pote a aussi installé KDE sur sa machine de tueur. Config par défaut, je ne sais plus quelle distrib, le process KDE sirote ses 800Mo de ram (réelle!) à lui tout seul. C'est franchement déplacé comme comportement, je pense que c'est la faute aux packageurs… mais bon que dire contre l'argument "ça ne se voit même pas sur les machines un tant soit peu récentes et c'est ce que veut la majorité des gens, du flashy, du wobbly, des glouglouteries en travers de tout l'espace visuel" ?
=> Là ma solution c'est d'utiliser Enlightenment (ou Gnome shell pour le portable où je dois pouvoir connecter des vidéoproj à chaud), les config ArchLinux par défaut d'Enlightenment et Gnome Shell sont raisonnables.
À ma connaissance, les défauts de matériel, c'est ça passe ou ça casse. Le seul que je propose qui soit de nature à ralentir le système, c'est un défaut de pâte thermique ou une ouverture de ventilo bouchée par des poils de chat, pour un CPU qui est capable de faire du "throttle" en situation de surchauffe. Ceux qui ne font pas de throttle plantent tout simplement…
[^] # Re: Nouvelles versions de logiciels, toujours + lourds
Posté par mornik . Évalué à 8. Dernière modification le 02 juillet 2014 à 00:24.
Si la machine de tueur de ton pote n'est pas capable de faire tourner normalement un KDE, faut revoir quelque chose :
1. la définition de config de tueur (car j'ai un kde dernière génération qui tourne aussi bien que le reste sur des configs vieillissantes)
2. il y a peut-être des erreurs dans le choix de certains composants/système d'aération
3. je peux faire le même argumentaire : le top une debian unstable avec kde. C'est aussi pertinent qu'une arch+cequetuveux, ça ne répond pas à la question.
4. tous le monde sait que la vrai réponse c'est 42 :D
[^] # Re: Nouvelles versions de logiciels, toujours + lourds
Posté par CrEv (site web personnel) . Évalué à 3.
Heu… Core2 Duo c'est pas trop "maintenant"
Une machine de "maintenant" et pas bien haute en perf c'est par exemple un Core i5 à 2,5GHz et 8Go de RAM.
Mais ça ne rendra jamais firefox rapide hein…
[^] # Re: Nouvelles versions de logiciels, toujours + lourds
Posté par robin . Évalué à 2.
Pour la ram, sur les portables, ce n'est toujours pas le cas. Il y a deux ans, j'avais acheté un pc avec 4G de ram. Je viens de le changer, et je voulais en profiter pour passer à 6G, mais ce n'était pas possible sans changer radicalement de gamme de prix (550€ pour les deux).
bépo powered
[^] # Re: Nouvelles versions de logiciels, toujours + lourds
Posté par lasher . Évalué à 3.
Hum, je ne sais pas où tu as acheté ta RAM, mais j'avais acheté 2×8Gio pour ~100$ il y a un ou deux ans pour upgrader mon laptop (je suis passé de 4Gio à 20Gio…).
[^] # Re: Nouvelles versions de logiciels, toujours + lourds
Posté par Chris K. . Évalué à 3.
A ce tarif là tu peux regarder du coté des pc reconditionnés : http://www.laptopservice.fr/6-ordinateur-portable
J'ai acheté un thinkpad chez eux qui tourne comme une horloge.
Après tout dépend de l'utilisation mais avec un environnement de développement et éventuellement une machine virtuelle pour les tests même 6Go ça peut être short.
# j'ai deux hdd identique d'âge différent
Posté par deasy . Évalué à 2.
et leur temps d'accès est différent, environ une ms d'écart.
Bref tout ça pour dire je me demande si avec le temps le temps d'accès ne varie pas.
# Et les nouveaux langages de programmation...
Posté par marzoul . Évalué à 10.
Oui on n'est pas trolldi, mais y'en a sur qui c'est toujours aussi facile de taper :P
Plein de composants des OS, environnements de bureau et applis sont recodés dans des langages en vogue (javaseries…), interprétés (python, javascript/css… oui il y a des jit mais tiens, ne serait-ce pas justement une dépendance bien bien grasse en plus?), ou en se jetant à l'excès sur les fonctionnalités les plus "dynamiques" (enfin mettez votre buzzword favori) des langages de programmation et de leurs dernières moutures (exemples C++: templates, méthodes virtuelles, opérateur .* et j'en passe).
Le manque d'espérience joue. Au Google Summer Of Code, plein de stagiaires bossent sur des choses vouées à être utilisées par le grand monde.
L'utilisation à outrance de machines surpuissantes joue. Un développeur qui teste une appli sur sa machine ne verra même pas les régressions sur la vitesse de l'appli.
Ce qui joue aussi, c'est que beaucoup (trop) de développeurs sont en mode "il faut être ultra réactif pour rester in". Dès qu'un gusse dit que c'est bien d'utiliser CSS pour faire un thème de bureau, bim toute la planète shifte et flanque un moteur web (oh un buzzword) dans le login manager. Ça pousse à l'utilisation de buzz-langages aux performances à redire.
Mais on a encore une chance que certaines choses reviennent au moins en partie dans l'ordre : le mobile. Peu de RAM et de cache, CPU moins puissant, et on vise une autonomie maximale, c'est heureusement un bon argument de vente. La bataille des benchmarks fait rage, certains trichent même. Alors, pour android, on commence à proposer la compilation à l'installation des applis, au lieu de jit par dalvik. Pour plein d'applis on fait une version pour PC, il faut bien en faire une pour mobile, et on va bien finir par se rendre compte que coder proprement dans des vrais langages compilés ça marche très bien partout (ben tiens si c'est pas ce qu'on a toujours fait du temps des pentium III…).
[^] # Re: Et les nouveaux langages de programmation...
Posté par Renault (site web personnel) . Évalué à 3.
Ces langages ou extensions de langage sont là pour apporter plus de sécurité et de simplicité (bon, pas JS) dans le code au détriment des performances.
Le langage C c'est cool mais dans les domaines qui lui sont réservés comme les systèmes embarqués ou les couches très basses. Au dessus on peut écrire du code plus robuste et maintenable, autant en profiter. Le C te permet de gratter des octets avec une norme réduite et une bibliothèque standard qui ne fait pas grand chose. Mais est-ce que ça a un intérêt sur des machines où plus personne ne compte la taille des binaires en dessous du Mo en RAM ?
GSoC c'est bien mais c'est en général une portion ridicule du code de l'ensemble de l'application qui est fournit.
Et je doute que le stagiaire en question a un droit de modification direct du code, code qui sera revu et approuvé par les mainteneurs des projets respectifs comme pour tout autre contributeur.
D'un autre côté le CSS a été conçu pour l'habillage de données, donc c'est bien fait pour faire des thèmes non ?
Je ne suis pas fan du JS mais le but est de mémoire de rendre accessible le développement à un pan entier d'informaticien qui bossent dans le Web quasi-exclusivement.
Ce n'est pas le langage idéal mais ça permet de s'adresser à un groupe de développeurs plus vaste.
Bah c'est une bonne chose.
La puissance des machines c'est fait pour être exploité, sinon autant revenir au 8086. Certains projets veulent plus d'efficience en étant plus rustique, c'est un choix et une alternative pour ceux qui ne bénéficient pas de la puissance.
Tu parles des appareil dont tu as souvent peu de contrôle avec une palanquée d'applications préinstallées qui te seront inutiles et dont celles tu voudras ont une bannière publicitaire ?
Mouais, le téléphone portable est loin d'être un modèle d'efficience. Et avec la vitesse d'évolution que ça a connu comme secteur c'est pire que le PC en terme de course en avant.
[^] # Re: Et les nouveaux langages de programmation...
Posté par gnx . Évalué à 10.
Ah ben tout s'explique, alors !
[^] # Re: Et les nouveaux langages de programmation...
Posté par barmic . Évalué à 4.
C'est intéressant ce que tu dis. On se dit souvent que de toute façon OSEF et puis finalement on se retrouve confronté aux problèmes de perf lié à ce genre de considération.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et les nouveaux langages de programmation...
Posté par karteum59 . Évalué à 8. Dernière modification le 02 juillet 2014 à 10:36.
Oui c'est bien ce qu'on dit: exploitée (pour de vraies choses, pour du calcul, des traitements utiles, pour avoir des machines réactives et rapides), pas gaspillée…
Par ailleurs, tout le monde ne change pas de machine fréquemment (on n'a qu'une planète… on ferait bien de prolonger la durée de vie de nos machines !).
Il y a 15 ans, je lisais piège dans le cyberespace de Roberto Di Cosmo, et (venant d'un horizon Amiga où tout était fluide sur une machine de 14 MHz avec 2 Mo de RAM) je ne pouvais qu'acquiescer au "se demander pourquoi un ordinateur bien plus puissant que celui qui a servi à envoyer des hommes sur la lune, et à les ramener vivants, n'est pas en mesure de manipuler correctement un document d'une centaine de pages quand il est équipé par ce Microsoft Office qui fait la joie de tous nos commentateurs". Malheureusement, ça ne s'est pas vraiment amélioré sous notre OS préféré.
Je note que pour mettre en oeuvre le "projet svelte" qui a abouti à Android Kitkat, google a précisément fourni à ses développeurs une version limitée (en RAM, en CPU, etc.) de son google Nexus, et il a fallu que le système devienne utilisable sur cette machine limitée (représentative des smartphones bas de gamme). Très bonne initiative ! (mais il faut dire qu'ils partaient de loin vu l'embonpoint qu'avait pris Jellybean…)
[^] # Re: Et les nouveaux langages de programmation...
Posté par freem . Évalué à 6.
Hum, l'OS, ou les DEs populaires? Mes machines n'utilisent pas plus de 256Mio de ram au démarrage avec client mail démarré et divers terminaux… mais je n'utilise pas les mêmes logiciels que la moyenne.
[^] # Re: Et les nouveaux langages de programmation...
Posté par Le Gab . Évalué à 1.
Ça ne suffira pas à cause du jit.
un iPhone 4 (même pas 's') est plus véloce que mon Note 1 en android 4.4.3 (omni rom sans google apps).
Alors on pourra toujours pousser pour plus de RAM et de cœurs mais si c'est juste pour tenir la release time de 6mois pour vendre du pseudo 'nouveau', c'est triste.
[^] # Re: Et les nouveaux langages de programmation...
Posté par marzoul . Évalué à 3.
Hum, pas d'accord, ne serait-ce que pour l'éducation des gens. On a des grands océans, est-ce qu'on serait donc supposer les utiliser comme poubelle juste parce que dans les îles pour touristes fortunés ça ne sa voit pas ?
Ne serait-ce que pour le côté green et consommation en énergie raisonnable vu ce qu'on fait, ça fait mal de devoir changer de matos pour lire une page web et éditer un document (le matos neuf a coûté en énergie et matériaux à la fabrication, + ce qu'il va falloir pour recycler l'ancien…).
Oui, mais le problème devient visible quand on ne trouve plus, ou difficilement, de logiciel qui ait les fonctionnalités (la technique !) qu'on veut, mais sans les glouglouteries visuelles, les grosse fonctionnalités qui devraient être en option, et qui soit codé propre.
Je veux dire, les plateformes mobiles en général. Tablettes comprises. Ou dérivés : la board Odroid U2, c'est 4.5W 4coeurs arm 2Go ram, le chip est un Exynos4 donc ce qu'on trouve dans pas mal de smartphones. Comme PC léger et discret c'est vraiment super.
[^] # Re: Et les nouveaux langages de programmation...
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Depuis quand c'est dynamique les templates?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et les nouveaux langages de programmation...
Posté par Snark . Évalué à 6.
Je confirme: les templates C++ c'est à la compilation qu'on en prend plein les dents. Déjà, ça explose le temps de compilation. Et ensuite, bonjour les messages d'erreur avec des lignes de trois pages! À l'exécution par contre, il n'y a pas de pénalité—c'est même fait pour!
[^] # Re: Et les nouveaux langages de programmation...
Posté par Pierre Roc . Évalué à -1.
Sur la question des pénalités à l’exécution, j’ai comme un doute. Il y a un risque de se retrouver avec un binaire énorme à cause d’une duplication du code importante. Avoir un code trop gros peut être coûteux à l’exécution.
[^] # Re: Et les nouveaux langages de programmation...
Posté par khivapia . Évalué à 5. Dernière modification le 03 juillet 2014 à 16:05.
Avoir un code trop gros peut être coûteux à l’exécution.
D'une c'est très rarement le cas en optimisation (le 1er problème est toujours l'algorithme, puis la gestion du cache de données, ensuite la vectorisation et les branches, ensuite l'optimisation du code pour l'exécution et niveau cache de code).
De deux, les template ne dupliquent pas de code puisque une instantiation avec les mêmes paramètres produit le même code. Si on instantie le template avec des paramètres différents, c'est que le programme en a besoin et qu'il devrait de toutes façons écrire deux classes s'il n'utilisait pas les template. Deux effets supplémentaires sur les template : à l'instantiation, le compilateur ne sélectionne que la sous-partie des méthodes qui sont effectivement utilisées par l'instantiation (si un
T<int>n'utilise qu'une fonction foo et qu'unT<double>n'utilise qu'une fonction bar, la fonction bar n'est pas compiilée pourT<int>ni foo pourT<double>) ; en outre, le compilateur peut utiliser le même code si les effets sont identiques (cas des template instantiés avec un type pointeur par exemple).[^] # Re: Et les nouveaux langages de programmation...
Posté par Pierre Roc . Évalué à -2. Dernière modification le 03 juillet 2014 à 19:09.
Arf… ce mépris, ça commence à me gonfler.
Bien évidemment que la duplication de code est présente si et seulement si il y a plusieurs instantiations. Bien évidemment que tout ceci est au conditionnel. Et j’ai toujours pensé que le choix de l’algo. était absolument primordial dans la vitesse de traitement informatique, mais comme ça n’était pas le sujet du fil je ne l’ai pas mentionné.
Je vais prendre un exemple pratique. Je pensais plutôt à un défaut du cache d’instructions éventuel, par exemple mettons qu’on ait un patron de fonction
avec un corps assez long pour que toutes les instances du patron appelées alternativement ne tiennent pas en cache CPU (genre un coup on fait appel à
f<int>puis àf<double>puis àf<maSuperClasseDeLaMortQuiTue>, etc.). Est-ce que le cas d’un défaut du cache d’instruction est facilement atteint avec un code&CPU “standard” ? Là est toutelama question.Par exemple, en restant sur T un type numérique, peut-être vaut-il mieux avoir une fonction f(double) (eg. sans template/polymorphisme), et jouer sur la conversion implicite des arguments de l’appel, plutôt que d’abuser des templates.
C’était tout le sens de mon commentaire : dire a priori que les templates ne coûtent rien à l’exécution me semblait être assez imprudent.
[^] # Re: Et les nouveaux langages de programmation...
Posté par khivapia . Évalué à 2.
Ben ils coûtent si ils sont instantiés plusieurs fois, mais si on les instantie plusieurs fois c'est qu'on aurait fait pareil sans template, non ?
En plus le principe de faire de grosses fonctions n'est pas terrible, surtout pour les appeler alternativement sur des types différent. Ça dénote une conception bizarre du logiciel.
[^] # Re: Et les nouveaux langages de programmation...
Posté par lasher . Évalué à 4.
Il y a un coût réel en terme d'espace à utiliser les templates. Je discutais récemment avec un mec qui avait bossé pour une boite de télécoms il y a quelques années. Il devait écrire un bout de firmware, ce qu'il fit en C++. Le code était rempli de templates, et plus exactement, il avait fait de la méta-programmation par template. Le binaire qu'il a produit est du coup devenu énorme. Il a eu la chance que l'espace pour stocker le code était suffisamment grand pour contenir tout le code, et du coup utiliser les templates avait payé (s'il y a la place pour le code, le compilateur peut souvent générer du code qui est effectivement très bon).
Le problème n'est pas d'utiliser les templates de façon « simple » (fonction template, etc.), mais bien lorsqu'on utilise les templates de façon « intelligente » (méta-prog par templates), car on perd potentiellement de vue la quantité réelle de code généré, là où en C ou dans un langage OO plus « pur » (par exemple hein), comme on ne dispose pas de cet outil, on aurait programmé la même chose dans un style différent (en utilisant le polymorphisme dynamiquement par exemple).
Donc Pierre Roc, même s'il a pris la réponse un peu mal (de façon injustifiée je trouve), a raison de se poser la question de la duplication du code. Si les templates n'avaient comme inconvénient que la façon dont il faut penser pour faire de la méta-prog, je pense que plus de langages auraient évolué dans ce sens (en proposant sans doute une version simplifiée ou plus programmer-friendly de faire).
Par contre, si on parle de cache d'instructions de processeurs modernes, sur Intel le L1I est généralement de 32Kio de nos jours, et AMD oscille entre 32Kio et 64Kio. Si le programme a besoin de brancher tellement de fois qu'il y a de réels défauts de cache en permanence dans le L1I, il faut commencer à se poser la question de comment le truc a été programmé…
[^] # Re: Et les nouveaux langages de programmation...
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Il me semble aussi que g++ instanciait une version du code à chaque appel et pas seulement par type. C'est assez récent comme changement.
"La première sécurité est la liberté"
[^] # Re: Et les nouveaux langages de programmation...
Posté par Anthony Jaguenaud . Évalué à 2.
En effet, les patrons de fonctions été compilé localement dans chaque fichier cpp sans exporter les symbols. Du coup les binaires grossissais pas mal. Mais il y avait un hack :
[^] # Re: Et les nouveaux langages de programmation...
Posté par claudex . Évalué à 4.
Mais tu explique bien que ce n'est pas les template qui posent le problème de la taille du binaire mais le style de programmation. Le même style en C (au délà de sans doute être très pénible à écrire) prendrait la même place.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et les nouveaux langages de programmation...
Posté par khivapia . Évalué à 2. Dernière modification le 04 juillet 2014 à 09:32.
Arf… ce mépris, ça commence à me gonfler.
Désolé ce n'est pas mon but.
Est-ce que le cas d’un défaut du cache d’instruction est facilement atteint avec un code&CPU “standard” ?
J'ai dû mal m'exprimer. La réponse est non : le principal problème d'une appli standard codée de manière standard est le cache de données.
Après tout est dans le 'standard', bien sûr.
Merci à lasher pour son commentaire qui est bien plus éclairant que les miens.
[^] # Re: Et les nouveaux langages de programmation...
Posté par khivapia . Évalué à 3.
C++: templates, méthodes virtuelles, opérateur .* et j'en passe
Euh justement en C++ les template sont coûteux à la compilation uniquement, du coup il est bon de les utiliser (polymorphisme statique) plutô que les méthodes virtuelles & fonctionnalités d'héritage (polymorphisme dynamique, coûteux en perfs).
[^] # Re: Et les nouveaux langages de programmation...
Posté par freem . Évalué à 5.
Pour les templates, sois rassuré, ça n'impacte que la machine du dev. Pour le reste, ça dépend de l'archi du soft et de comment sont utilisées les features, mais à titre de rappel, GCC qui est (était en fait) codé en pur C est vachement plus lent à compiler que clang, avec engorgement de RAM fourni (potentiellement dû à l'usage d'un garbage collector? J'avais vu ça sur un article d'un de leurs dev qui parlait de migrer certains modules en C++, et je ne serai pas étonné que ce soit une des causes de l'amélioration des perfs de GCC depuis l'arrivée d'un concurrent…)
Enfin, en réalité, je suis globalement d'accord avec ton propos, on à beau dire qu'un programme interprété n'a de coût qu'a son premier lancement, entres autres autres, je reste très sceptique à ce sujet, et je trouve que ce n'est pas sain de garder des tonnes de softs pré-compilés en cache et au code source dans le disque. Certes, les ressources, c'est pas cher, mais bon… multiplier les langages implique de multiplier les frameworks (bash, perl, python en même temps sont habituels de nos jours, et ont des binding pour divers frameworks), ce qui à mon avis cause également un gâchis des ressources.
Mais bon, la solution à tout ça, c'est de choisir ses logiciels en fonction des technologies qu'ils utilisent, et pour ça, debtags est très utile aux debianistes.
Autre chose, plutôt qu'utiliser des logiciels hype, utiliser des logiciels fonctionnels, mais bon, c'est sûr, ça implique de pas avoir de coins arrondis, ni même parfois, horreur, de fonds d'écran.
Pour ça, il faut par contre accepter de se souvenir qu'on utilise les logiciels, pas leur esthétique. Être utilisable et intuitif ne signifie pas être joli, c'est même souvent le contraire j'ai remarqué (je ne dis pas que c'est une fatalité ceci dit).
# Probleme de protocole de test?
Posté par groumly . Évalué à 5.
Comment définit tu "ralentir"?
Compares tu a version egale de software?
Et évidemment, la question qui tue, qui revient un peu a la meme chose que la question 1: tu mesures comment?
Parce que si c'est de la mesure "odoimooyé", comparé a ce que tu te rappelles des mesures a la rache de l'année précédente, mmh, comment dire?
Si effectivement tu testes une configuration soft raisonablement équivalente, je vote pour 5. C'est fou comment on prends pour acquis des gains de perfs, et ce qui paraissait rapide sur du matos de la generation précédente parait très vite inacceptable.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# GPU?
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Est-ce que tu as un GPU à pipeline fixe ou presque (OpengGL < 2)?
OpenGL a tellement changé que certaines applications qui faisaient un rendu en hardware avant peuvent le faire en soft sur la même configuration aujourd'hui.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: GPU?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
A part des jeux, il y a des applications qui utilisent openGL sous linux ?
Je regrettes l'absence d'usage de openCL, j'imagine que même un gpu Intel a une grosse puissance de calcul disponible, inexploité.
"La première sécurité est la liberté"
[^] # Re: GPU?
Posté par claudex . Évalué à 3.
Ça commence seulement à être utilisable sous Linux avec des pilotes libres pour Intel (pour les autres, ce n'est pas encore le cas), c'est donc normal que ce ne soit pas encore répandu.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: GPU?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu veux dire qu'il existe enfin des pilotes libres intel pour openCl ?
"La première sécurité est la liberté"
[^] # Re: GPU?
Posté par claudex . Évalué à 4.
Il y a Beignet mais c'est encore balbutiant.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: GPU?
Posté par oinkoink_daotter . Évalué à 8.
Oui, les "compositeurs" des windowmanager. Et ça fait une putain de différence à usage. J'en fait l'amère expérience hier avec un centrino intel 1.7ghz, avec une intel i915. Unity de base sur la dernière ubuntu lts est absolument inutilisable (genre 15s pour afficher le menu quand on clique sur l’icône en haut à gauche), xfce très bien par contre.
# Loi de Wirth
Posté par MTux . Évalué à 10. Dernière modification le 02 juillet 2014 à 08:32.
http://fr.wikipedia.org/wiki/Loi_de_Wirth
Pas faux, a l'époque de DOS si on m'avait dit qu'un jour on aurait des processeurs 8 coeurs à plus de 3GHz, je me serai imaginé un démarrage instantané de l'OS et des logiciels. En fait c'est l'inverse tout était plus rapide sur DOS même si on avait des CPU 386…
Pour continuer à troller je rajoute une couche, j'ai écrit ça en 2012 :
http://maniatux.fr/?article300/les-distributions-linux-sont-de-plus-en-plus-lourdes
Je fais à peu près le même constat que toi. Machine vieille mais pas tant que ça, et pourtant déjà obsolète pour Linux.
[^] # Re: Loi de Wirth
Posté par arnaudus . Évalué à 2.
Ouuhhh, j'en connais qui vont parler de systemd :-)
Par rapport à DOS, c'est compliqué, mais par rapport à Windows, je trouve que depuis quelques années les distributions Linux ont fait beaucoup de progrès au niveau du temps de démarrage. Ce n'est pas instantané, certes, mais c'est très acceptable. Mon PC de boulot met plus de temps à lancer le bios et les trucs matériels que de démarrer le noyau et le serveur graphique. En gros, ça met autant de temps à lancer le système qu'à lancer libre office, c'est quand même notable.
La lourdeur des distributions, c'est autre chose. Les stratégies "à la Ubuntu", avec un bureau qui se comporte comme une surcouche à un système complet, sont évidemment à remettre en cause. D'une manière générale, un OS est un gros truc complexe, et à moins de disposer d'une puissance de développement extraordinaire, on est souvent obligé d'accumuler des couches pas bien conçues pour que ça marche (typiquement, des trucs comme PulseAudio). Les distribs ne vont pas développer et débugger tous les logiciels, elles ne font qu'assembler des briques. Si les briques sont mal foutues ou incompatibles, on ne peut pas blâmer les distrubutions…
Pour la lenteur des vieilles machines, j'ai toujours mis ça sur le compte du facteur psychologique, mais c'est vrai que je n'ai jamais pensé au vieillissement des composants.
[^] # Re: Loi de Wirth
Posté par Sébastien Le Ray . Évalué à 1.
toi t'as pas du démarrer un Windows depuis XP. Sous seven on a un bureau utilisable sous les 20 secondes quand dans le même temps un KDE a pas fini d'afficher son splashscreen et de lancer baloo…
[^] # Re: Loi de Wirth
Posté par cosmocat . Évalué à 5.
C'est marrant mais j'ai pas la même sensation…
J'ai un vieux PC de plus de 6 ans à la maison (fedora/KDE) et (je trouve qu') il démarre plus vite (Core 2Duo 2GHz avec 2Go RAM bon avec un SSD…) que mon win7 du boulot sur un PC d'un peu plus d'un an (Core i5 2,5GHz avec 8Go de RAM). Je suis obligé d'utiliser la mise en veille prolongée pour une utilisation satisfaisante.
Par contre, apparemment, avec Win8 ça s'est amélioré…
[^] # Re: Loi de Wirth
Posté par Astaoth . Évalué à 4.
C'est le SSD qui change tout … le disque dur est la pièce la plus lente d'un ordi.
Emacs le fait depuis 30 ans.
[^] # Re: Loi de Wirth
Posté par mrlem (site web personnel) . Évalué à 10.
Après l'utilisateur ;)
[^] # Re: Loi de Wirth
Posté par Astaoth . Évalué à 1.
Ca dépend pour qui, je ne me sens pas encore l'âme d'un périphérique d'ordinateur :)
Emacs le fait depuis 30 ans.
[^] # suckless !! More is less !
Posté par bobo38 . Évalué à 10. Dernière modification le 02 juillet 2014 à 09:29.
Pour les fans de logiciels légers écrits en C de façon efficace, je recommande les softs affiliés à suckless.org :
http://dwm.suckless.org/ – dwm : gestionnaire de fenêtres en 2000 lignes de codes, dépendance unique à X, ultra rapide, tiling, et concept de multibureau par tag
http://st.suckless.org/ – st : émulateur de terminal mininmal, hyper réactif, il y a bien quelques limitations mais on s'y fait (c'est un émulateur de tty mec…), 4000 lignes de codes à comparer aux 65000 de xterm et aux 32000 de rxvt
http://tools.suckless.org/slock/ – slock : verrouillage de session X (très très simple et efficace : lancé, slock verrouille la session X en cours, et attend qu'on tape le mot de passe, pas de champ de saisie, pas d'habillage inutile, l'écran change de couleur au premier caractère, et se déverrouille si le mot de passe est bon à la saisie de la touche Entrée), remplaçant idéal de xscreensaver, couplé à xautolock et la configuration de X pour gérer la mise en veille de l'écran : un excellent exemple de ce qui peut se faire de mieux en KISS dans l'esprit UNIX.
http://tools.suckless.org/dmenu/ – j'ai du mal à décrire, mais quand on voit les hacks faits à partir de ça c'est cool. Utilisé dans dwm, surf
Pour dwm et st :
– pas de fichier de config… c'est du code en C include, et tu compiles ton business.
– le comportement par défaut ne te plait pas, il y a des patchs pour ajuster ceci ou celà, tu recompiles
Il y a aussi un navigateur web (dépendance à X et à Webkit)
http://surf.suckless.org/
(à tester)
Les types sont allés jusqu'à recoder les fonctions shell de base:
http://tools.suckless.org/sbase
(pour faire des distribution Suckless/Linux ? ;þ)
[^] # Re: suckless !! More is less !
Posté par arnaudus . Évalué à 9.
Mouais.
1) Je ne vois pas l'avantage de coder des applications non-système en C. Pourquoi pas en assembleur, tant qu'on y est? C'est sûr, C permet de faire des trucs comme
#define TRUERED(x) (((x) & 0xff0000) >> 8). Ça marche pour draguer?2) Il n'y a pas nécessairement de rapport entre le nombre de lignes de code et l'efficacité ou la facilité de maintenance. Par exemple, pour st, on se retrouve avec un fichier st.c de 4000 lignes, et des centaines de fonction dedans. À part pour l'exploit de faire tenir un émulateur de terminal dans un fichier, c'est quoi l'intérêt?
3) L'exploit a un coût. Par exemple, le texte qui s'affiche quand on lance "st -h" est codé en dur. Du coup, quand on change une option, il faut modifier le code, et modifier le texte en dur. Il existe probablement des dizaines de bibliothèques qui permettent d'automatiser ça; beaucoup d'entre elles sont d'ailleurs seulement dans un .h et ne nécessitent pas de dépendance externes, elles peuvent juste être #include-ées.
Bref, l'exploit est intéressant en tant que tel, mais il est peut-être raisonnable de trouver un juste milieu. Les buffer overflow dans les applis météos parce qu'un geek a imaginé qu'il savait faire du C, ça va deux secondes, mais je préfère quand les gens utilisent des langages adaptés.
[^] # Re: suckless !! More is less !
Posté par gnx . Évalué à 2.
Ah OK, C est définitivement has-been, je vois.
Et comment tu fais pour extraire certains bits de la valeur que tu reçois, dans un autre langage ???
NB: si tu faisais un décalage de 16 et non de 8, t'arriverais peut-être même à choper O:-)
Oh mon Dieu, quelle horreur !
Quand tu changes une option, tu modifies le code de toutes manières, hein.
[^] # Re: suckless !! More is less !
Posté par arnaudus . Évalué à 4.
Tu fais pas :-) Dans un langage évolué, tu structures tes variables de manière à ce que leur sémantique ne soit pas cryptique :-)
[^] # Re: suckless !! More is less !
Posté par ckyl . Évalué à 3.
Faut pas déconner c'est pas une question de langage mais de cas d'utilisation.
Il y a des problèmes qui imposent de faire tu bit packing ou du bitwise, et il y a tout les autres problèmes (qui sont largement majoritaire). Tu ne peux y échapper. Ça ne veut pas dire qu'il ne faut pas wrapper ça correctement ou en abuser.
D'ailleurs la tendance c'est plutôt de réintroduire l'accès à des struct & malloc dans les langages de haut niveau par ce qu'on s'est rendu compte qu'à un moment faire systématiquement des caches miss, empêcher le prefetch ou faire quadrupler la consommation mémoire bin c'est assez terrible quand ça touche le coeur de l'appli…
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Ou alors tu fais un langage qui ne fait pas n'importe quoi (Ocaml) et qui marche rapidement même avec un GC.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par ckyl . Évalué à 5.
Tu veux dire un langage qui à un module Bigarray exactement pour les mêmes raisons ? Ou un qui a un GC stop the world et dont j'ai jamais vu de bench avec des heap à 16, 32 ou 64 GB ?
Le truc intelligent qu'à fait Ocaml, c'est le stockage unboxed des primitifs au détriment d'un bit. Mais autrement les problèmes sont généraux. Il te faut un accès aux types primitifs, à des structs like et à des buffers.
[^] # Re: suckless !! More is less !
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Je n'ai jamais trop compris pourquoi ils ont sacrifié un pauvre bit innocent :-(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: suckless !! More is less !
Posté par ckyl . Évalué à 4.
Le runtime a besoin de savoir si dans la case memoire tu as une valeur unboxée ou un pointeur vers une valeur boxée. Tu peux trouver l'explication des représentation mémoire d'Ocaml ici: https://realworldocaml.org/v1/en/html/memory-representation-of-values.
Sur la JVM tu n'as pas ca, car la vision boxée / unboxée est faite au niveau du système de type (ce qui est une horreur). Si tu veux comprendre un peu mieux ce genre de problème tu peux regarder là: http://cr.openjdk.java.net/~jrose/values/values-0.html. En pratique ça pose de vrai problèmes, et toutes les plateformes ont a peut près les mêmes problème, même si les réponses ne sont pas exactement les mêmes. Mais à un moment, tu as besoin d'avoir des types structs, un layout mémoire propre et échapper au coup des GC par un moyen ou un autre.
[^] # Re: suckless !! More is less !
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Ca a l'air louche comme même…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: suckless !! More is less !
Posté par chimrod (site web personnel) . Évalué à 7.
s/comme/quand/
Pitié !
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En gros, cela évite d'avoir des objets partout qui bouffent de la place, et tu colles ton entier directement à la place du pointeur. Cela permet aussi d'informer le GC qu'il lit un pointeur et non un entier. L'idée est que la mémoire contient un peu du type de donné réel.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Je ne comprends pas pourquoi le GC tenterait de lire un pointeur là où il y a un entier… Est-ce que ça n'est pas un problème spécifique à OCAML?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
En général, les GC parcourent les zones mémoires à nettoyer avec assez peu d'information.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par gnx . Évalué à 4. Dernière modification le 02 juillet 2014 à 16:37.
Je note les smileys. Cependant, je vais répondre comme s'ils n'y étaient pas, ça évitera que quelqu'un d'autre se méprenne.
Alors j'ai dit « la valeur que tu reçois » : c'est-à-dire tous les cas ou tu échanges des données avec un autre système ou programme (mémoire graphique, message binaire reçu d'un autre équipement, etc.) ou bien quand tu lis un fichier binaire au format défini. Quel que soit le langage, il faut que tu extraies/positionnes tels ou tels bits à telle ou telle position de ton mot ou ton octet, tu ne peux pas passer outre.
De toutes façon, dans tous les autres cas, tu peux et tu vas structurer tes variables de manière à ce que leur sémantique ne soit pas cryptique, en C aussi. Et c'est aussi ce que tu fais une fois tes bits extraits d'une donnée, ou avant de les positionner pour une expédition.
Mais sinon, les bits, ce n'est pas sale, on a le droit de les regarder et de les manipuler. L'approche de plus en plus désincarnée des langages abstraits a beau essayer de cacher ce qui a sous le capot, au final ça marche pourtant comme ça.
[^] # Re: suckless !! More is less !
Posté par arnaudus . Évalué à 3.
Oui, mais c'est ce qui s'appelle l'"abstraction". La question centrale est celle des contraintes du langage, est-ce qu'un langage doit représenter la manière dont la machine fonctionne, ou est-ce que le langage doit fournir des outils pour implémenter formellement ce que le programmeur pense? Bon, en plus, tout ça est proche de la machine, il faut avoir en tête les différences entre les architectures, ça me parait être une complexité dingue pour une histoire de trois nombres entre 0 et 255.
D'une manière plus spécifique, oui, il me paraitrait évident de manipuler du bit de couleur dans Gimp. Dans un émulateur de terminal, je ne vois pas. La manière "correcte" de traiter les couleurs dans ce contexte est, à mon avis, de créer un objet qui contient trois variables de la bonne taille, avec une méthode d'import (qui elle peut éventuellement tripoter les bits—ce n'est pas sale), et des méthodes d'export. Si un émulateur de terminal passe plus de 0.01% de son temps à jouer avec les couleurs, c'est certainement qu'il y a un problème dans l'émulateur, et pas dans l'optimisation de la fonction qui gère les couleurs.
[^] # Re: suckless !! More is less !
Posté par gnx . Évalué à 3.
Ben après c'est toujours la même opposition entre lisibilité/maintenabilité d'un côté et performance de l'autre.
Si au lieu de trimballer des tableaux contenant les 3 couleurs « paquées » dans des entiers 32 bits, on utilise un langage de haut niveau en séparant les couleurs dans des variables qui vont être inférée dans le type de base (64 bits), on se retrouve avec 6 fois plus de mémoire utilisée, des opérations de copies plus coûteuses, et on peut sortir du cache et alors multiplier les temps d'exécutions par 10. Si on multiplie ça par une dizaine de terminaux lancés…
Bon, c'est un pire cas, mais ça illustre assez bien le sujet de ce fil.
[^] # Re: suckless !! More is less !
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 6.
Moi, je préfère utiliser un langage qui se démerde tout seul avec tout ça.
Là, au moins, y a juste à décrire.
[^] # Re: suckless !! More is less !
Posté par gnx . Évalué à 2.
Les champs de bits existent aussi en C.
[^] # Re: suckless !! More is less !
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
Exact mais personnellement, j'en ai pas vu des masses dans le code C qui m'est passé sous les yeux.
L'habitude est plus dans la manipulation des opérateurs de décalage me semble-t-il.
[^] # Re: suckless !! More is less !
Posté par gnx . Évalué à 2.
Oui. Hypothèses pour justifier ça :
- avec les opérateurs, on sait exactement ce qu'on fait ;
- avec les opérateurs, on sait ce qui va être généré (attention au >> tout de même) ;
- avec les champs de bits C, incertitude sur le padding ?
- avec les champs de bits C, incertitude sur l'ordre des champs, des bits, des octets, des mots ?
- avec les champs de bits C, incertitude sur la taille du type crée ?
J'ai mis des points d'interrogation car je ne suis pas sûr qu'il y ait des problèmes potentiels (un spécialiste de la norme confirmerait/infirmerait), mais ça ne m'étonnerait pas. Et du coup, si comme moi, les autres programmeurs médiocres ne le sentent pas, ça peut expliquer que le champ de bits ne soit pas trop utilisé.
Je ne sais pas si en Ada (c'est bien de l'Ada, tes exemples ?) on a plus de certitudes.
[^] # Re: suckless !! More is less !
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 02 juillet 2014 à 22:06.
En assembleur aussi ;)
Là, j'avoue que je ne sais pas non plus.
Ben non, justement. Je n'avais pas mis la fin de l'exemple mais on a ça
Avec ça, tu en connais encore plus.
Mais pour l'ordre des champs, c'est déjà précisé dans l'exemple précédent qui spécifie les tailles ET les emplacements. Par contre, quand tu as besoin d'un champ inutilisé, tu es obligé de le spécifier aussi.
Pour la taille du type, ça peut être précisé dans le type utilisé avec l'attribut Size.
Du coup, ça permet des trucs comme ça. Bon, c'est lourd mais au moins, tout est précisé ;)
D'ailleurs, tu trouveras à peu près tous les exemples de clauses de représentation.
[^] # Re: suckless !! More is less !
Posté par gnx . Évalué à 2.
Merci.
Et le sens de la numérotation des bits (0<=>LSB ou 0<=>MSB) est fixé par la norme ?
Heu, dans ton exemple plus haut, justement, tu ne spécifies par les bits 8 et 9.
Pour parfaire mon information :-) :
- Ça couine si on dépasse l'attribut
'Sizeavec lesrangedes champs ?- Ça couine si deux champs ont des
rangequi se chevauchent ?- Ça couine si deux champs ont des
rangequi se recouvrent alors que leurs offsets (leat) sont différents ?C'est bien de l'Ada, alors :->
[^] # Re: suckless !! More is less !
Posté par gnx . Évalué à 2.
Je me réponds sur un point :
On dirait que non car dans l'exemple que tu as mis en lien, il y a des sortes d'alias sur certains champs :
Dommage, parce qu'avec toutes les bornes à taper, c'est facile de se planter par ci par là.
[^] # Re: suckless !! More is less !
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
En fait, si mais dans mon exemple, il s'agit d'une sorte de structure paramétrée et donc les deux champs ne peuvent exister en même temps. Du coup, ils ne se chevauchent jamais.
[^] # Re: suckless !! More is less !
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Bon, j'ai refait un test mais bon, c'est pas facile, le compilo laisse rien passer :D
Si on compile tel quel, on obtient :
Si on décommente les clauses de représentation pour R et G, on obtient le message d'erreur :
Donc c'est pas facile de faire n'importe quoi :D
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je n'ai jamais compris pourquoi les langages mélangeaient des informations de haut niveau comme le type de donné, les ranges, et leur implémentation en mémoire ( ce qui n'a rien à voir ou presque).
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Attention, c'est quand même très particulier comme cas, la plupart du temps, ça ne sert pas à grand chose et il vaut mieux laisser faire le compilateur.
Mais en même temps, tu as certains cas où tu ne peux pas l'éviter.
Typiquement, le code que j'ai fourni en lien permet d'écrire dans la GDT dont la représentation en mémoire est spécifiée par Intel. Du coup, tu es coincé.
Pour ce qui est de mélanger un peu tout, je préfère avoir les clauses de représentation sous les yeux dans le même langage que celui de programmation et me dire que dans ce cas, cela a une importance plutôt que d'avoir un n-ième fichier pour décrire tout ça.
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Cela sert dans 2 ou 3 cas :
* écriture de drivers et donc dans des registres mémoires
* parseur de fichier binaire
* parseur de message réseau.
C'est tout de même assez courant, en fait.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Certes mais pour l'instant, il n'y a pas énormément d'OS en Ada :)
Exact et dans ce cas, il y aura l'endianness à gérer aussi mais il y a déjà une solution
Exact aussi mais là, ce ne sont pas les solutions existantes qui manquent entre PolyORB, YAMI4 ou de simples sockets comme dans l'exemple de Wikibooks.
Sachant qu'en plus, la norme définit dans l'annexe E comment doivent être faits les systèmes distribués, il faut vraiment un besoin spécifique pour ré-écrire un protocole réseau.
[^] # Re: suckless !! More is less !
Posté par gnx . Évalué à 2.
Merci pour les tests !
[^] # Re: suckless !! More is less !
Posté par Anthony Jaguenaud . Évalué à 2.
Il n'y a pas vraiment d'incertitude le compilateur alignera les champs sur des frontières de mots. Parce que c'est plus efficace et que la norme ne garanti rien la dessus. Donc sous gcc il faut ajouter l'attribut
packedà la structure par exemple, sous visual c'est un#pragmaLà encore, c'est connue mais dépend de l'endianness… Donc pour faire du code portable, il faut généralement déclarer deux structures, une pour du little endian, l'autre pour du big. Voir d'autre pour le porter sur des CPU où l'
intne fait pas 32 bits.Non, la taille est connue. Soit tu élimines le padding (cf point 1), soit tu le fais pas, mais dans ce cas tu t'en moques.
Ce genre de chose doivent de toutes façon être cantonné au fichier d'interface avec l'extérieur. La structure codée ne doit pas apparaître dans le reste du programme.
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
En gros, les champs de bits en C ne garantissent rien du tout sur les champs réellement utilisés au final, si on regarde l'ensemble de la structure (le padding dépend du CPU et du compilo). Pour un driver par exemple, c'est un non sens, d'ou l'usage des macros.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Anthony Jaguenaud . Évalué à 2.
Je n'aurais pas été jusqu'à ne garantissent rien du tout mais c'est un peu ça. Les compilateurs se comporte globalement de la même façon. Dans l'embarqué, tu connais généralement l'ensemble donc les structures sont plus esthétiques à mon sens et plus lisible. L'avantage des macros, c'est que tu n'as que l'endianess à gérer. C'est plus simple de faire du code portable. Par contre, même punition que les structure, les macro doivent être cantonnées à l'accès avec l'extérieur et recopier les données dans une structure interne propre.
Le padding dépend effectivement des deux, même si la principale contrainte vient du CPU. Sur le Power PC par exemple, il ne sait pas faire d'accès mémoire non aligné. Donc si tu force le compilo à ne pas aligner, pour chaque mot, il a 3 chances sur 4 de faire 2 accès mémoires (la deuxième en cache) plus de la recombinaison des données.
[^] # Re: suckless !! More is less !
Posté par lasher . Évalué à 3.
Hum, il y a quand même des « bonnes pratiques », du genre si j'ai quelque chose comme ça (en supposant une archi 64 bits) :
… Alors comme vous disiez Nicolas et toi, le compilateur sera obligé de remplir les octets pour aligner sur la taille des mots. La structure précédente risque fort d'être générée ainsi (et la norme force les compilateurs à respecter l'ordre des champs d'une structure):
… et donc
toto_sgaspille 64 bits en alignement. La bonne pratique qu'on m'a toujours indiquée (et qui ne dépend pas de l'endianness à ma connaissance), c'est de toujours trier mes champs par ordre décroissant par défaut :À ma connaissance (mais mes souvenirs datent, donc je peux me tromper), avec les champs de bit, les problèmes d'alignement sont les mêmes, avec le piège du type entier choisi pour représenter les données :
La structure
foo_sutilise 17 bits, et déclare qu'ils appartiennent à un u16… et du coup il faut allouer deux u16 l'un après l'autre. Si j'avais utiliséu8, j'aurais pu potentiellement économiser 8 bits. Évidemment, dans l'exemple précédent, il faut de toute façon tenir compte du padding général, et au final, ma structure ressemblera sans doute à quelque chose de ce genre :Après, il y a toujours des trucs un peu « sioux » à faire, par exemple si le champ
f1detoto_sest partagé par plusieurs threads, il faudra sans doute rajouter du padding autour, pour éviter les problème de faux partage (false sharing), mais là ça devient sans doute un peu trop tordu…[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Ton problème finale de faux partage n'est rien par rapport au problème de l'écriture sur le registre qui écrase les valeurs autour.
Les champs de bits avec une union sur un registre, j'ai souvent vu ça sur des mini drivers de µcontroller, c'est facile, car le compilo est toujours le même pour une cible donné. Il suffit de regarder ce que génère le compilateur et s'adapter.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Anthony Jaguenaud . Évalué à 2.
Tu as raison sur le principe, pour éviter le padding d'une structure on ordonne les champs dans l'ordre de taille décroissante. Mais tu ne choisi pas forcément le codage d'une trame BUS que tu reçois par exemple.
Sinon, il y a une petite erreur sur ton premier exemple :
Un simple
sizeofentre une structure bien rangé et une autre est vraiment parlant. C'est utile quand la RAM peut manquer, sinon, je trouve plus clair de mettre des champs qui ont des affinités ensembles.[^] # Re: suckless !! More is less !
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Après pour les opérations sur ensemble de bits, je préfère aussi ça :
qui s'utilisent aussi avec or et xor
[^] # Re: suckless !! More is less !
Posté par freem . Évalué à -1.
Tout à fait. Il est inutile d'avoir des logiciels de rendu --tels que blender ou the gimp-- performants après tout. (bon ok, dans le cas de blender il y à aussi du C++ à en croire wikipedia)
[^] # Re: suckless !! More is less !
Posté par arnaudus . Évalué à 6.
Peut-être n'existe-t-il pas une relation divine entre le langage et la performance d'un logiciel?
Ce que je trouve amusant, c'est que dès qu'on discute performance, il semble que tous les développeurs bossent sur de l'embarqué, des drivers de carte graphique, ou sur le noyau. Mais ce développement là représente quoi, en vrai? Quelle proportion des logiciels qu'on utilise tous les jours a besoin des quelques % de différence de temps d'exécution entre C et C++? Le noyau, le serveur X, et puis heuuu… Ça serait débile de croire que si LibreOffice est poussif, c'est parce qu'il n'est pas codé en C.
Si tu fais un tour sur un dépôt de logiciels libres et que tu regardes les langages, tu t'apercevras que 90% (au pifomètre rouillé) des projets en C n'ont absolument aucune raison d'être en C.
[^] # Re: suckless !! More is less !
Posté par Anthony Jaguenaud . Évalué à 4.
Qu'est-ce qui te permet de juger qu'ils ne devraient pas être en C ? Tu es sans doute un des rares à pouvoir choisir au début d'un développement qu'elle sera la complexité du logiciel au final, à choisir le langage avec le meilleurs paradigme et pour chaque paradigme, avoir une vision suffisamment clairvoyante pour analyser en avance de phase lequel des langages sera le plus adapté. Je n'en suis hélas pas capable. :'( Par défaut et comme beaucoup, je code avec ce que je connais. Je me fais des TPs pour tester de nouveaux langages (j'ai tenté haskell dernièrement), mais de là à démarrer un projet pouvant devenir gros… je préfère rester en terrain connu en connaissance de cause et sachant à l'avance les problèmes que je risque de rencontrer.
De toute façon, la langage ne fait pas l'optimisation. C'est l'algorithme qui fait ça.
[^] # Re: suckless !! More is less !
Posté par arnaudus . Évalué à 6.
Le meilleur langage est celui que tu connais, mais il y a des limites.
Les exemples auxquels je pense, c'est par exemple des applis essentiellement basées sur des GUI. Imagine par exemple un truc qui édite des fichiers de config. Tu crées un clicodrome, il n'y a pas de calcul ou d'algorithme particulier. Dans ce cas, tu te vois gérer la mémoire, détuire les pointeurs vers les widgets au fur et à mesure de leur fermeture, etc? Tu n'as aucune contrainte de temps d'exécution, 99% du temps cpu va être consacré à l'affichage des éléments qui sont appelés par une bibliothèque (qui elle pourra être en C).
Un autre exemple (celui auquel je pensais, en fait) sont tous ces jeux de stratégie, type implémentation de jeux de plateaux ou jeux de rôle. Au niveau algo et calcul, il y a que dalle, c'est juste de l'interface autour d'un moteur de jeu. J'ai contribué parfois à ces trucs, en plus, souvent, c'est "Dédé apprend à programmer", c'est plein de segfaults et de pointeurs tout nus qui se balladent partout, les tableaux sont initialisés avec des dimensions constantes (souvent plusieurs millions de cases, hein, faut voir grand), etc.
Justement, raison de plus pour ne pas s'emm* avec ces langages proches de la machine, qui n'ont d'utilité réelle que dans une minorité de cas. Et surtout si on n'est pas développeur de formation et de profession. Personnellement, je vois C comme un outil spécialisé, pour des développeurs système ou embarqué, ou réservés à des cas très particuliers. Pour coder un truc avec une GUI et trois algos triviaux, il me parait beaucoup plus censé de démarrer sur un langage de script (python? ruby?) plutôt que de se demander si on ne va pas avoir un jour besoin de faire de la logique bitwise.
[^] # Re: suckless !! More is less !
Posté par Ph Husson (site web personnel) . Évalué à 2.
Je rajouterais que pour des interfaces graphiques, une programmation événementielle permet d'éviter des accoups au moindre accès au disque ou au réseau, ce que le C ne permet que laborieusement
[^] # Re: suckless !! More is less !
Posté par gnx . Évalué à 3. Dernière modification le 02 juillet 2014 à 21:23.
En théorie. En pratique ça va justement dépendre du langage et du cas. Dans le cas d'un langage interprété/pseudo-compilé ; si un algorithme est moisi mais utilise des opérations complexes qui sont en fait des primitives du langage, il pourra être plus rapide dans ce langage qu'un algorithme chiadé mais dont la répétition des opérations coûte au total plus cher. Exemple : travailler sur des tableaux de caractères en Perl comme on le ferait en C ou dans beaucoup d'autres langages. L'algorithme aura beau être plus efficace sur le papier, il ne le sera pas en pratique à cause d'énormes pénalités à chaque accès à un élément alors qu'un algo plus bourrin ira plus vite s'il fait appel à des primitives qui, elles, sont optimisées.
Donc je dirais que « ce sont le langage et l'algorithme » qui font l'optimisation.
[^] # Re: suckless !! More is less !
Posté par arnaudus . Évalué à 6.
Toutafé. En bio-informatique par exemple, il est très courant d'employer des langages interprétés (principalement R et python) même pour les algorithmes critiques. Évidemment, c'est en partie attribuable au fait que les gens ne sont pas nécessairement développeurs de profession et que ces langages sont plus accessibles, mais c'est aussi lié au fait que (contrairement à ce qu'on peut souvent entendre), ces langages ne sont pas si lents que ça en pratique, car la très très grande majorité des algorithmes consiste à assembler des briques déja optimisées : du tri, des expressions régulières, des sommes, des opérations sur des matrices, etc. Si on ajoute la compilation just-in-time et la parallelisation relativement accessible, on se situe dans des domaines de performance qui sont du même ordre de grandeur que les langages compilés traditionnels, pour un temps de développement très inférieur.
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il ne faut pas exagérer, il y a souvent un facteur 10 entre un script et un langage compilé.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par flan (site web personnel) . Évalué à 8.
Dans le cas qu'il cite, ce n'est forcément le cas. Si tu fais du Python avec du numpy pour faire des calculs matriciels, ton code passera 99% de son temps dans la partie C. Du coup, même si le Python est 10 fois plus lent, la différence sera négligeable.
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
C'est pas faux, sauf si il y a beaucoup d'aller retour entre le code C et le python (avec recopie en trop, accès fichier mal fichu, etc…).
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Albert_ . Évalué à 9. Dernière modification le 03 juillet 2014 à 14:47.
Le probleme c'est que deja la plupart des scientifiques ne veulent pas s'embeter avec du C et ils ont raison. C'est trop bas niveau pour leur besoin et de plus la raccourcis de syntaxe c'est rigolo mais ca laisse un code pas forcement lisible.
Donc ils utilisent des outils qui simplifie leur vie et aussi le debuggage, du coup c'est matlab, python et si c'est un langage compile fortran ou C++.
Et mon experience me montre que de tout de facon les trucs qui sont vraiment lent le gars qui a code a juste code le truc avec ses pieds et ce n'est pas le langage qui changera quoi que ce soit. J'ai un tres bon exemple d'un code que j'ai du optimise qui est passe de 15 jours sur un gros cluster (job tue car trop long) a 2 secondes sur mon portable… Le probleme etait dans l'interface chaise-clavier et nul part ailleurs.
Naturellement les vrais calculs sont fait avec des libs optimise a mort par des pros et ca encore tu peux etre super fort en C/C++/ada/python. Tu ne batteras jamais les specialistes et cela ne sert a rien (en dehors de l'aspect pedagogique) de refuser d'utiliser tel ou tel lib parcequ'elle est dans un langage que tu n'aimes pas. Il y a tres tres peu de chance que tu arrives a faire un algo ou implementer un algo d'une meilleure facon.
En ce qui concerne les langages compiles maintenant il y a aussi le probleme que la plupart des optimisations "facile" (non algorithmique) sont automatiquement faite par les compilos.
[^] # Re: suckless !! More is less !
Posté par Shuba . Évalué à 5.
Numpy rend le calcul numérique en python acceptable, mais il ne faut pas se leurrer, dès que la boucle critique du code fait autre chose qu'une simple multiplication de matrices on sent très vite la différence. Ça peut être qu'une des matrices n'est pas constante et change à chaque itération, ce peut t'obliger à boucler sur une partie de ses valeurs en python, et ça fait tout de suite mal.
À mon boulot on prototype en python, et ensuite on réimplémente les parties critiques en C++, et le gain est souvent un x20 voire un x100. (Les gros gains viennent souvent du fait qu'on ne passe pas non plus notre temps à optimiser le python).
[^] # Re: suckless !! More is less !
Posté par claudex . Évalué à 5.
Il y a aussi pythran pour ça.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: suckless !! More is less !
Posté par Shuba . Évalué à 2.
C'est vrai, on envisage son utilisation mais on n'a pas encore tenté.
[^] # Re: suckless !! More is less !
Posté par Pierre Roc . Évalué à 2.
On peut écrire la partie critique en fortran ou C. Ça se fait assez bien d’ailleurs en numérique (pour le Fortran c’est automatique, en C faut suivre le tuto officiel).
[^] # Re: suckless !! More is less !
Posté par arnaudus . Évalué à 4.
C'est loin d'être vrai. Il suffit de comparer des opérations comparables (cf un de mes anciens commentaires sur un benchmark où R se gamellait, et où j'avais réussi en codant selon les paradigmes du langage à réduire le temps d'exécution de 7 secondes à 0.00 (sic) seconde : http://linuxfr.org/news/version-1-0-de-julia#comment-1327186).
C'est clair, si tu implémentes un algo de tri en perl, il va être 10 fois moins rapide qu'en C. Mais ce n'est pas comme ça qu'on fait un tri en perl, c'est tout.
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il y a de grande chance que ton compilateur ai détecté que tu demandes 500x la même chose et ne le fasse pas.
C'est vrai, mais typiquement ton exemple en R est illisible.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par arnaudus . Évalué à 3. Dernière modification le 03 juillet 2014 à 14:36.
Sérieux, tu n'arrives pas à lire quelque chose comme:
replicate(500, sum(1/((1:10000)^2))?Là c'est vraiment une question d'habitude, pour moi c'est vraiment limpide. Il y a des trucs en R qui sont vraiment illisibles (notamment à cause de l'accumulation de parenthèses), mais je parse très bien cette ligne.
Il n'est pas si malin que ça. Si on remplace 500 par 500000, ça prend 0.45 sec. Le vrai temps est donc autour de 0.004s, certainement trop court pour être mesuré efficacement avec system.time.
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
J'ai fait un tout petit de R. Mais j'ai du mal à voir comment une fonction replicate() pourrait avoir une utilité sans un "truc qui bouge" dans le membre d'à coté. 1:10000 semble être une liste de nombre que l'on mélange avec des scalaires.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par arnaudus . Évalué à 3.
Je sais bien, mais c'est le benchmark initial qui était complètement stupide, je n'ai fait que suivre les instructions! (calculer 500 fois la somme des 1/n2 pour n = 1 à 10000).
Du coup, un bon compilo s'apercevrait qu'on ne fait rien, je pense, et le test concerne tout autant le langage que le compilateur.
Le code initial en R incluait une double boucle, comme si c'était du C. Du coup, R mettait 3h à faire ce calcul stupide, ce qui n'est pas étonnant. Ce que j'ai essayé de montrer, c'est que ça n'était pas de la faute de R, mais du programmeur. Codé correctement, cet algo stupide est tout aussi rapide que du C.
Après, il existe forcément des algorithmes pour lesquels R est beaucoup plus lent que C. C'est évident, c'est un langage interprété. Mais il existe aussi de nombreux cas où en pratique R sera plus rapide que le code C, parce qu'il appelle des routines optimisées. Je ne connais pas les rouages internes de R, mais il est très efficace pour les opérations vectorisées (apply, lapply, sapply, etc), et ça ne m'étonnerait pas qu'il implémente des optimisations de bas niveau pour ça. Il est aussi diaboliquement bon pour des casse-têtes algorithmiques (par exemple tirer au hasard des éléments d'un vecteur avec ou sans remise avec pondération, avec une vitesse que je n'ai jamais réussi à approximer en C++).
Encore une fois, les langages sont tous Turing compplets, on peut tout faire avec n'importe quoi. Mais il est malsain de penser que de tout coder en C montre qu'on est un programmeur balèze. Ça montre juste qu'on est un programmeur qui ne connait que le C :)
[^] # Re: suckless !! More is less !
Posté par Zylabon . Évalué à 0.
Le C c'est le seul langage de "haut niveau" qui offre une chance au programmeur de s'approcher de l'optimalité. Si c'est ce que l'on vise, utiliser C est une bonne idée, à condition d'en avoir les compétence et de s'en donner les moyens.
Please do not feed the trolls
[^] # Re: suckless !! More is less !
Posté par khivapia . Évalué à 7.
le C++ aussi, non ?
[^] # Re: suckless !! More is less !
Posté par ckyl . Évalué à 8.
C'est pas R le langage ou le runtime qui est rapide, ce sont les libs d'algèbre linéaire qu'il y a dessous (et je prends le pari que c'est du C).
Ça serait aussi con que de dire que Python est rapide par ce que Numpy est rapide. Python est lent comme une loutre bourrée. Toutes les libs d'algèbre linéaire & co sortent des runtimes classiques pour chopper un bon gros buffer mémoire et faire leur sauce dans leur coin (cf. la discussion plus bas sur ce genre de besoin).
Bref R en tant qu'outil est rapide. Maintenant venir dire que les langages dynamiques, interprétés ou autre c'est cool pour la perf faut pas déconner. Tu t'en sers juste comme glue. Si tu vas à l'aéroport en velo, c'est pas lui qui te fait traversé l'atlantique en 5h…
[^] # Re: suckless !! More is less !
Posté par gouttegd . Évalué à 5.
Pas que, une partie au moins est en Fortran.
[^] # Re: suckless !! More is less !
Posté par arnaudus . Évalué à 2.
Comme tous les langages, R a une bibliothèque standard—qu'elle soit implémentée en C, en Fortran, en assembleur, ou en javascript ne change pas.
L'objectif n'est pas de comparer des trucs sur une base idéologique, c'est de déterminer en pratique si un langage est adapté au développement de telle ou telle application. Seule une minorité d'applications ont un temps d'exécution critique : pour un uptime de 9 jours sur mon PC de bureau, seules 19 applications (sur 267) ont pris plus de 30 s de temps CPU (soit 0.13s par heure!). Et je suis certain que pour toutes ces applications, seuls quelques % du code sont réellement concernés. Seule une fraction de pourcent des millions de lignes de code que j'utilise au quotidien sur ma machine mérite d'être rapide, le reste pourait être codé en visual Basic que je ne verrais pas la différence.
Je maintiens donc que C est très largement sur-utilisé. C'est un outil très technique, indispensable dans certains domaines, mais son utilisation systématique par le commun des développeur n'est pas justifié. Évidemment, s'ils tombent systématiquement sur des gens qui leur disent que C est une sorte de graal qui tend vers l'optimalité, ou qu'on n'est pas un vrai développeur si on ne code pas en C, on ne va pas sortir de cette situation.
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Je crois que tu te trompes, la majorité des boites codent maintenant en Java. Je ne sais pas si c'est Java qui est lent ou l’empilement de couche, mais une application java est lente.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par claudex . Évalué à 4.
Je dirais que la culture autour du langage qui pousse vers des constructions très généralistes mais parfois très lourdes n'aident pas non plus.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: suckless !! More is less !
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Pour beaucoup de boites, Java n'a pas remplacé C++, il est utilisé dans d'autres domaines (les applis web à 42000 features par exemple).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: suckless !! More is less !
Posté par groumly . Évalué à 1.
Oui, et non.
Java en soi n'est pas particulierement lent.
Par contre la jvm met une plombe a demarrer, le gc peut etre particulierement casse tete, et ca a tendance a bouffer plus de ram que la meme chose ecrite en c.
C'est pas un probleme pour des applis web (enfin, la plupart), c'est vachement plus genant pour des applis avec une UI, ou des petits outils a utilisation frequente et tres courte.
Regarde des trucs genre intellij ou eclipse, tout en java, pas franchement lent (mais oui, ca met beaucoup de temps a demarrer).
Ca depend beaucoup de ce que tu fais et de comment tu l'utilise (comme toujours en fait).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: suckless !! More is less !
Posté par ckyl . Évalué à 3.
La VM est très rapide à démarrer. C'est le chargement des classes, l'init des blocs statiques et les dépendances mal gaulées qui font que ce que tu observes c'est un démarrage lent. Mais la VM elle pourte en vitesse (de mémoire ça se compte en ms). Juste pour ceux que ça intéresse ;)
[^] # Re: suckless !! More is less !
Posté par groumly . Évalué à 2.
Moui, enfin ca revient un peu au meme au final :)
Du moment ou tu lances java a la premiere ligne de ton main s'execute, ya un delai loin d'etre negligeable, c'est ce que je voulais dire.
Et si tu rajoutes des trucs genre spring qui va scanner ton classpath et autres joyeusetes au demarrage (assez courant on va dire :)), ben ouais, t'arrives a qq secondes pour avoir une appli qui peut rendre la main a l'utilisateur.
C'est pas un probleme pour un serveur d'appli, un peu plus pour un ide, et disqualifiant pour un petit outil en ligne de commande.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: suckless !! More is less !
Posté par ckyl . Évalué à 2. Dernière modification le 05 juillet 2014 à 23:34.
Je suis d'accord avec toi. Je fais plutôt dans le technique que dans les guerres de religions/clochés.
Je pense simplement que ça peut intéresser des gens de savoir ce qui coûte cher. Voir ça peut être intéressant de s'en souvenir quand on design quelque chose. Typiquement détricoter le merdier du rt.jar ça a déjà du coûter quelques centaines/milliers d'hommes/an et les applis/lib/framework s'en foutent aussi. Après le design de la JVM et de son écosystème n'est clairement pas fait pour les applis à vie courte.
[^] # Re: suckless !! More is less !
Posté par groumly . Évalué à 2.
Ben c'est effectivement une question interessante, comment faire demarrer une appli rapidement.
Faut bien avouer que sorti du code natif, tous les langages de haut niveau sont assez mauvais la dessus. Java et ruby sont des veaux au demarrage, et j'imagine que python ou .net doivent pas etre tellement meilleurs.
Et meme en natif, c'est facile de se retrouver a instancier un paquet de merde sans s'en rendre compte.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu as des sources pour accélérer le lancement d'IDE basé sur eclipse et leur paquet de plugin ?
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Tout dépends de la taille du logiciel. Chez moi nanimstudio démarre presque aussi vite que gedit…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Justement, je code un client RCP, et "rapide" est pas franchement le 1er qualificatif qui me vient à l'esprit.On a pu faire la comparaison de consommation mémoire entre 2 outils, l'un basé sur eclipse, l'autre maison en c++, pour la même quantité d'objet, il y a un facteur 10.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par groumly . Évalué à 2.
Autant je suis d'accord sur l'empreinte mémoire qui est assez imposante (a ramener au nombre de choses qu'éclipse fait quand meme), autant niveau vitesse pure et réactivité (sorti des pauses GC, évidemment), ca a pas a rougir a mon avis.
Idem pour intellij.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: suckless !! More is less !
Posté par gouttegd . Évalué à 1.
Je ne sais pas à quels « algorithmes critiques » tu penses, mais toutes les implémentations d’algorithmes d’alignement (BLAST, Clustal, Muscle, Needleman & Wunsch, etc.) que je connais sont en C ou en C++. La seule implémentation en Python de BLAST que j’ai vu était à but pédagogique uniquement.
Au passage, la version C++ du NCBI BLAST est beaucoup plus lente que la version C…
[^] # Re: suckless !! More is less !
Posté par freem . Évalué à 4.
Si je dois dire exactement ce que je pense, ok.
Pour moi, le C est effectivement trop utilisé, et dans la plupart des cas les développeurs y gagneraient à utiliser C++ qui, jusqu'à ce que j'aie la preuve du contraire, peut faire les mêmes choses à bas niveau, mais en plus permets de les encapsuler de façon à ne pas risquer d'oublier un
deletefree.L'excuse de la gestion manuelle de la mémoire est un faux problème, en C++ il est rare d'avoir réellement besoin de le faire: les smart pointers et la RAII sont là pour ça. En plus, contrairement à des langages utilisant un GC, c'est bien plus simple de savoir quand un objet va être libéré, et donc quand il finira par libérer les ressources dont il à besoin: accès fichier, connexion à une base de données et connexion à un port sont les premières choses qui me viennent à l'esprit, et je ne connaît pas des masses de programmes qui ne manipulent rien de tout ça.
Les garbages collectors devraient commencer par se collecter eux-mêmes franchement.
Pour le C++, je peux aussi citer les templates qui sont extrêmement puissants. La dernière fois que j'ai eu à toucher du Java ou du C#, il n'était pas possible de faire de la spécialisation partielle, entres autres (je parle d'avant 2011). Pourtant, ça simplifie la vie des devs.
L'un des problèmes par contre du C++, c'est que dès lors que l'on doit exposer des classes et des méthodes l'ABI n'est plus garantie, donc on s'expose à des emmerdes si on à pas le même compilo dans la même version (du coup la méthode habituelle est d'utiliser le sous-ensemble C: des structs qui n'intègrent aucune méthode qui sont gérées par des fonctions. Du C quoi.).
Donc, le C à bel et bien un avantage sur certains langages de plus niveau.
Ce même avantage reviens quand on doit faire interagir des applications écrites dans des langages différents: le Java, le C++, le C#, et probablement d'autres plus obscurs savent tous charger des bibliothèques codées en C.
Je vais continuer sur python (histoire de me faire encore plus moinsser), et dire que je trouve néfaste le fait qu'un langage soit si dépendant de sa version. Sur la machine de laquelle j'écris, j'ai 2 versions de python. Par contre, une seule version de libc. Et manifestement, j'ai pas loin d'une centaine de Mo de dépendance pythonique. Oui, je sais, l'espace mémoire c'est pas cher, mais moi, je me dit que 100Mo * 9, c'est déjà près d'un Go. Pourquoi par 9? Parce qu'il y à 9 PC de bureau à mon taf. 1 Go, c'est vrai, ce n'est rien… mais je suis encore à l'échelle d'une petite entreprise.
Dans le cas de perl, c'est moins pire, seulement 50Mo, mais il faut dire que perl semble beaucoup moins dépendant de la version du langage. Moins utilisé aussi. On peut supposer que ce serait dans les 100Mo aussi s'il y avait 2 versions…
Si l'ensemble des gens de ma boîte tournaient sur Debian, configuré pour être minimaliste (oui, parce que les 150Mo, c'est sur une config que j'essaie de garder minimaliste, je pense que si j'avais un DE monolithique type KDE ou gnome, ce serait très probablement plus gros…) on parlerait alors de 1.5Go, à la louche.
À l'heure ou l'on parle d'économie d'énergie, c'est tout de même dommage, non? Parce que les libs et interpréteurs, il faut les charger en RAM, pour que ça serve. Et quand on charge un programme interprété, il faut stocker la forme binaire optimisée, en RAM également. Hors, la RAM, ça consomme de l'énergie.
J'ai vu une étude qui montrait que le coût en énergie des machine est de moins en moins négligeable face à leur coût d'achat. Certes, c'est dû au matos de plus en plus performant, mais pourquoi as-t-on besoin de matos de plus en plus performant?
Alors, ok, je te rejoins sur le fait que 90% des applications incluant une interface graphique n'ont aucun intérêt particulier à être codées en C. Par contre, je ne vois pas ce qui leur interdirait d'être écrites en C.
Quant à l'argument "oui mais les débutants savent pas faire proprement".
Désolé, cet argument est juste l'un des pires qui existe: si on commence à jauger les langages à l'aune des cochonneries que font les débutants, alors je doute qu'il existe un seul langage correct: je défie quiconque de me prouver que pour un langage donné il est impossible de faire du code de plus de 1000 lignes qui soit crade (je dirait même que moins un langage est typé, plus il est facile d'écrire de la merde, le code php que j'ai devant les yeux au taf le montre bien).
[^] # Re: suckless !! More is less !
Posté par Anonyme . Évalué à 4. Dernière modification le 02 juillet 2014 à 11:44.
Jsais pas mais recompiler pour configurer c’est quand même vachement chiant.
Tu prends i3, i3status, i3lock et dmenu par dessus tout ça et tu as un très bon tiling-WM très light et facilement configurable, toutes les infos qu’il faut (batterie, heure et systray, n’enfopaplus) et en prime t’as un xlock fort joli et configurable pour au minimum afficher une nimage si tu veux, et dmenu parce que ça c’est un nain contournable.
Et pour troller, tu lances kdeinit4 en arrière plan, hin hin hin.
[^] # Re: suckless !! More is less !
Posté par bobo38 . Évalué à 3. Dernière modification le 02 juillet 2014 à 13:20.
Recompiler pour configurer c'est assez chiant. Les fichiers de config plain text me semblent un bon compromis. Le merdier GNOME ou KDE hyperintégré configuré via des GUI pour remplir des bases de données, à côté no comment. Il s'agissait avant tout d'un message pour montrer que tous les logiciels ne deviennent pas « obsèses » avec le temps.
Trois facteurs essentiels qui permettent de contrer la Loi de Wirth :
– une approche UNIX « un outil pour une tâche »; l'exemple de slock se focalisant sur le verrouillage, parce que s'appuyant sur xautolock pour le timer et X pour la mise en veille de l'écran
– une approche KISS, analysant le besoin et le reformulant pour donner la solution minimaliste cohérente « qui va bien »; l'exemple du rendu sobre de slock est de ce point de vue emblématique, sans boite de texte, sans affichage superflu
– une approche « ligne de commande/fichier/plain text »; quitte à ajouter une surcouche GUI par-dessus pour le côté user-friendly à posteriori, ça délimite bien l'aspect fonctionnel de l'aspect rendu
Ce qui est cool dans le libre, c'est qu'on a le choix :) Ça va du merdier hyperintégré qui nécessite l'accélération graphique (WTF) pour afficher des fenêtres, au WM tiling de barbu (qui nécessite de jouer du make).
[^] # Re: suckless !! More is less !
Posté par barmic . Évalué à 4.
Tu as essayé uzbl ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
L'approche unix a ses limites quand il s'agit d'empiler les couches. Quand tes briques changent, faire un tas de briques cohérent est très difficile. Dans linux embarqué, il y a très peu de couple, gcc+linux+libc qui fonctionnent. Il faut des versions précisent à chaque fois.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par xcomcmdr . Évalué à 10.
Ah oui, y'a des gens qui sont encore dans les années 90…
Heureusement qu'on utilise l'accélération graphique pour afficher… des graphismes. Tu sais, le processeur qui est fait pour ça…
soupir
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: suckless !! More is less !
Posté par bobo38 . Évalué à 2. Dernière modification le 05 juillet 2014 à 15:40.
OK, c'est noté : tu as absolument besoin d'une carte 3D pour afficher des fenêtres… pour activer des effets kikoolol (très certainement).
soupir
Ce qui compte c'est d'avoir le choix.
[^] # Re: suckless !! More is less !
Posté par xcomcmdr . Évalué à 2.
Non, simplement pour l'afficher en utilisant un minimum de ressources
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: suckless !! More is less !
Posté par groumly . Évalué à 5.
Non, c'est juste que c'est debile de faire le rendu sur un cpu pas adapte a ca quand t'as du silicium qui a ete fondu tres precisemment pour cette tache.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: suckless !! More is less !
Posté par bobo38 . Évalué à 0. Dernière modification le 06 juillet 2014 à 21:37.
Bon je vais mettre les sous-titres :
Par « merdier hyperintégré qui nécessite l'accélération graphique », je vise GNOME, qui a 2 comportements/rendus différents selon qu'une accélération 3D est détectée ou non. Moi ça me paraît délirant. Quand on regarde les sujets GNOME sur les forums, parfois on hallucine, je me souviens d'un sujet où on a découvert que le type était avec GNOME Fallback grâce à une capture d'écran – qu'on a dû lui demandé parce qu'il disait qu'un truc clochait dans son affichage. Ce serait-y pas un exemples d'obésiciel ça ?
Oui, j'espère bien que ma carte graphique est utilisée pour afficher des trucs sur l'écran de mon PC… Non, je ne souhaite pas que plus de ressources que nécessaire soient attribuées à mon environnement de bureau. Les fenêtres qui bloblottent ce n'est pas pour moi.
Maintenant on a le choix hein… GNOME doit bien correspondre aux besoins de certains.
[^] # Re: suckless !! More is less !
Posté par xcomcmdr . Évalué à 4.
Et c'est pour ça qu'utiliser le CPU pour faire le rendu sera toujours plus coûteux que d'utiliser le GPU.
T'as été battu par Compiz quand tu étais petit ?
Ça fait 3 fois que tu confonds accélération graphique et bling-bling…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: suckless !! More is less !
Posté par freem . Évalué à 1.
demenu c'est un suckless tools :)
[^] # Re: suckless !! More is less !
Posté par freem . Évalué à 1.
s/demenu/dmenu/
[^] # Re: suckless !! More is less !
Posté par barmic . Évalué à 4.
http://sta.li/
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Pourquoi un PC ralentit-il ?
Posté par reynum (site web personnel) . Évalué à 10.
Parce qu'il gravit une côte ?
kentoc'h mervel eget bezan saotred
[^] # Re: Pourquoi un PC ralentit-il ?
Posté par Troy McClure (site web personnel) . Évalué à 5.
Enfin un commentaire pertinent.
Merci.
[^] # Re: Pourquoi un PC ralentit-il ?
Posté par Prosper . Évalué à 2.
Encore un commentaire inutile.
Non Merci.
[^] # Re: Pourquoi un PC ralentit-il ?
Posté par Astaoth . Évalué à 5.
Dans le même genre, pour lui donner un petit coup de boost, iol y a une solution très simple, et relativement "économique" (du moins au début) : le mettre en chute libre, en le faisant passer par la fenêtre.
Emacs le fait depuis 30 ans.
[^] # Re: Pourquoi un PC ralentit-il ?
Posté par mornik . Évalué à 3.
D'ailleurs s'il part de plus en haut encore, il sera plus rapide à la fin.
Un PC qui accélère avec le temps, c'est magique :D
[^] # Re: Pourquoi un PC ralentit-il ?
Posté par N4th4 . Évalué à 6.
Au contraire, il accélère de moins en moins jusqu'à atteindre sa vitesse limite (à cause des forces de frotements qui augmentent avec la vitesse).
[^] # Re: Pourquoi un PC ralentit-il ?
Posté par MTux . Évalué à 2.
Non parce qu'il y a un radar
# Le plus probable
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 5.
Pour ne pas écraser le poulet qui traverse la route.
# En fait il y avait une demande dans le journal :-)
Posté par gnx . Évalué à 1.
Alors, mini PC, donc dans la gamme {Gigabyte Brix, Zotac Zbox, Intel NUC}. Les moins chers que j'aie répertoriés (je ne dis pas que c'est exhaustif) :
Donc Zbox ID18. C'est ce sur quoi je tape ce message et bien que ce ne soit évidemment pas un foudre de guerre, ça me suffit très bien (et je suis avec une Gentoo donc je supporte le temps de compilation de chaque programme) avec 2 Go . Ça supporte jusqu'à 16 Go donc OK pour tes 4 Go. RAM DDR3 SO-DIMM (classique pour portable, pas besoin de DDR3L au contraire des autres modèles cités). HD 2,5". Une sortie DVI (qui me sort aussi l'analogique pour le VGA avec un classique adaptateur à 3 sous) et une HDMI pour mon second écran.
Aucune idée du silence par rapport aux autres.
Voilà, au final (RAM+HD) c'est le même prix qu'un ordi de bureau premier prix mais ce dernier ne remplirait pas la condition "mini PC".
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.