Pratique dans certains cas ! En fait le mieux c'est quand même de limiter par service (port) ou par nom/type d'application, pour éviter que la mise à jour du système mette à bas la navigation par exemple, et ne plus dépendre de l'utilisation d'un programme tiers comme trickle (et donc forcer tous les utilisateurs du système à rentrer dans la boucle de limitation), l'idéal est de mettre le traffic sur TCP 80 plus prioritaire (sans oublier en upload), ou de limiter le traffic sur TCP 21, voire encore de déterminer que lors de multiples connexions concurrentes, l'une d'entre elle ne peut pas monopoliser plus de x % du traffic ; j'avais essayé une fois de limiter au niveau kernel avec la QoS mais ça ne marchait pas, sûrement que je n'avais pas réussi à configurer le truc correctement, c'est en effet assez compliqué si mon souvenir est exact. Si quelqu'un a un script de commandes QoS qui fonctionne, ce serait bien de faire tourner...
section .data
second_degre_voulu db 'vrai second degre', 0
proba_limite dd 3
extern brain_introspection
ok_second_degre db 'ok ok c\'etait du second degre...', 0
j_m_en_doutais db 'je m\'en doutais que c\'etait du foutage de gueule... 3% de chance au max que ce soit du 2nd degre...'
extern printf
En fait effectivement, j'ai été contraint (sous la torture) à faire un script ASP (en VB) pour nos clients neuneus (un truc pour nous uploader des trucs en XML) et j'ai trouvé que la doc en ligne était immonde par rapport à celle dispo pour PHP. J'utilisais pas de produit microsoft (le serveur ASP SunONE pour Linux) donc peut-etre que pour leurs clients payants ils donnent de la bonne doc sur cdrom ?
Je suis attristé de voir un framework aussi mal fourni.
C'est a dire ?
SWING est catastrophique à programmer en comparaison à GTK ou QT.
C'est a dire ?
Le framework ne contient même pas de class pour gérer du FTP, il faut passer par une librairie externe (jakarta dans mon cas).
("classe", "bibliothèque"). Ca te paraitrait normal qu'une GUI fasse du FTP ? Tu connais pas la notion de séparation des tâches ? Utilise une bilbiothèque pour faire du FTP, je vois pas le problème.
La documentation de sun est vraiment laborieuse.
Ca depend à quoi tu la compares. Je ne connais pas la documentation de .Net mais par rapport aux autres doc dispos sous linux (par exemple les man pour le C, perldoc pour perl) je la trouve tout a fait satisfaisante[1].
[1] sauf quand la doc sur les servlets omet une précision radicalement importante qu'il faut aller pêcher dans les specs des servlets à force de rien comprendre au comportement du bouzin (en l'occurrence, demander le changement de l'encoding de reception des parametres http apres qu'un parametre ait ete lu n'a aucun effet)
Hotplug multiplexe tout evennement de plugging ou unplugging du matériel il est donc tout à fait à même de scripter le montage de l'apn losqu'il est branché.
C'est curieux je trouve pas les précommandes 10.1 (official) sur mandrakestore.com d'habitude c'etait la tres tot. Peut-etre pour pas polluer les commandes Community (mais franchement je me demande si beaucoup de gens "achètent" la community).
2) pour développer un projet. Là, je fais assez peu d'appels-système, mais en revanche, dès que je dois en faire un (genre lancer plusieurs threads, forker, créer une socket...), je le fais sans hésiter. Sans le C, je nagerais...
Il y a appel système et appel système... fork, socket ou open sont très bien supportés dans plein de langages, en C ou en Perl par exemple. Sans le C, en Perl, je peux t'assurer que tu ne nagerais pas (en Python ou en Ruby aussi, je ne veux pas seulement prêcher pour ma chapelle).
En ce qui concerne le Perl, je n'y avais pas pensé, merci pour l'idée :-) .
Cela dit, s'il manque des appels-systèmes, je pense que je vais vite l'oublier.
Non mais faut voir aussi... dans les deux listes suivantes, tu utilises plutôt quoi :
1. fork, socket, read, write
2. statfs, brk, getdents, init_module
La première liste est un exemple de ce qui est dispo en Perl (utile dans les programmes), la deuxième de ce qui n'est pas dispo en Perl[1] (utile en gros seulement dans les applis système). Si tu as déjà utilisé directement quelque chose de la deuxième liste, ça n'a pas dû être très souvent (sauf si tes applis sont monstrueusement proches du système).
[1] en fait ils sont dispo mais c'est juste pas aussi simple qu'un appel de fonction Perl traditionnel
Je suis d'accord qu'il ne s'agit que d'un bench, mais ce bench a le bon goût d'être relativement complet par rapport aux autres puisqu'il aborde plusieurs types d'algo différents, et n'oublie pas de tester la consommation mémoire. Si tu veux encore parler de produit matriciel ou de calcul scientifique, je ne me battrai pas sur ce point pour la simple raison que je ne connais pas assez ce domaine, et il est possible que la stratégie d'allocation mémoire de ocaml (ou d'un autre équivalent) soit peu compatible avec les données et algorithmes en jeu.
par construction, il y a un overhead si la gestion d'une ressource est automatique. (Si tu n'est pas d'accord avec cette affirmation, je vois pas bien comment t'en convaincre...)
Ben je suis désolé je suis pas d'accord. Sur les processeurs modernes par exemple, les règles d'optimisation pour produire un code assembleur performant sont tellement complexes et nombreuses que même si optimiser une petite boucle sera plus rapide à la main, pour un algorithme plus long il vaudra mieux l'écrire en C et avoir un compilateur performant (ou un autre langage).
Ton argument, même s'il a l'air théoriquement séduisant, n'est pas vrai en toute circonstance, en particulier dans celles où les choses à prendre en compte sont trop nombreuses ou trop complexes pour l'esprit humain.
Dans le cas de l'allocation mémoire (mais tu parlais du cas général dans cet argument-là), je suis d'accord qu'en théorie une gestion automatique devrait impacter les performances. On voit que pour le calcul matriciel comme tu en parler, gcc est nettement devant. Mais pour fibonacci ocaml est nettement devant ! Alors que penser ?
Je pense que toutes choses considérées, ça vaut le coup de perdre quelques pourcents (on en est là) de performance brute en utilisant un langage à gestion automatique de la mémoire, pour l'énorme prix de supprimer magiquement 95% des segfaults et une bonne partie (je ne saurais pas la chiffrer) des problèmes de sécurité. Après tout, les processeurs augmentent leur puissance annuellement à un rythme plus rapide que quelques pourcents - et on utilise aussi des processeurs qui sont en permanence en famine d'accès mémoire, ce qui montre qu'il y a déjà beaucoup de performance gâchée pour des buts beaucoup moins nobles.
Bien sûr c'est là le point essentiel de notre divergence :)
Quel genre de programme tu fais pour avoir besoin de faire des syscalls tout le temps ? En general tu as une bibliotheque autour du langage qui cache les syscalls et on n'a pas besoin de plus... Par exemple je sais qu'en perl il "manque" des syscalls mais que je n'ai jamais besoin d'y acceder (et au passage si tu cherches de la doc bien faite sur un langage, la serie de man de perl plus perldoc sont encore bien plus efficaces que les man du C).
Mais sur le fond je suis bien sur d'accord que lorsqu'un systeme est ecrit en C il est plus facile de s'y interfacer dans le meme langage... pour les trucs systeme.
par contre, je me posais la question suivante ... si un langage de programmation doit etre independant de l'architecture ...
Le mythe de la "portabilité" du C a la peau dure. Il suffit de regarder la tronche d'un code C ultra-portable comme par exemple gzip pour voir qu'il faut que le programmeur rustine dans tous les coins si il veut être compilé "partout". Ce qu'il y a c'est que le C est tellement proche de l'assembleur dans l'esprit qu'il n'était je pense pas envisageable de définir une fois pour toute des types de base de taille constante qui risquaient d'impacter beaucoup trop les performances lorsque le support natif de la taille en question n'était pas disponible.
Je te réponds que ton "overhead non négligeable" est battu en brèche par le comparatif proposé. Et je te réponds qu'il existe des langages compilés avec systèmes de gestion automatique de mémoire, le contraire de ce que tu affirmais avant, et je te cite même des exemples et je te donne un lien. Je ne vois pas en quoi ça dérape, tu ne réponds même plus à mes arguments.
C'est plutôt toi qui change le débat si tu veux parler de "domaine de prédilection" des langages (ce n'est pas ce dont on parle, on parle d'utiliser un langage avec gestion automatique de la mémoire pour quelque chose comme GdkPixbuf) ou bien encore de calcul scientifique.
Moi je te réponds juste qu'affirmer qu'il n'existe pas de langage compilé avec gestion automatique de la mémoire est faux, et que parler d'"overhead non négligeable" m'a l'air faux d'après les résultats qu'on peut lire en suivant mon lien.
Une gestion automatique de la mémoire ajoute inévitablement un overhead non négligeable.
Et quand les tests eux-même prouvent le contraire ?[1]
Je ne connais aucun langage compilé qui offre une gestion de la mémoire avec "garde-fous"
Moi je connais[2] juste ocaml, mlton, smlnj, bigloo, cmucl, et encore c'est dans la sous-catégorie de ceux qui ont les même performances que C à moins de 5% près.
Ça me fascine à quel point les gens en général et les linuxiens en particulier s'accrochent de toutes leurs forces à leurs vieux langages qui génèrent un nombre incalculable de segfault et de trous de sécurité qui n'existeraient même pas si on voulait bien essayer de consacrer un peu de temps à utiliser les résultats de la recherche en informatique des années 60/70 (c'est pas trop demander en théorie). Le pire c'est que sous Linux je pense que vous êtes une majorité de programmeurs de ton avis.
Dis-moi, tu blagues ou tu penses vraiment qu'il y a une antinomie entre "langage compilé" et "gestion automatique de la mémoire" ?
Dis-moi, où est-ce que j'ai parlé de JVM, de très haut niveau, d'interprété ?
Et, dis-moi, est-ce que tu es au courant qu'il existe au moins un langage compilé avec gestion automatique de la mémoire qui a exactement les même performances que le C, sous linux ?
Tu as l'air bon en C et en assembleur mais il te faudrait connaître d'autres choses je pense.
Oui c'est vrai. Pourquoi renoncer à la peine de mort si 30 ans en prison ça coûte plus cher à la société ? Et pourquoi permettre le vote des femmes si ça coûte plus cher à la société ? Et pourquoi proposer l'instruction publique à tous les enfants si ça coûte plus cher à la société ? Et pourquoi avoir un système judiciaire si ça coûte plus cher à la société que tranquillement assassiner son voisin ? Et pourquoi enterrer ses morts si ça coûte plus cher à la société ?
C'est vrai ça, la civilisation ça coûte cher. Supprimons-la !
[^] # Re: TROUVE
Posté par gc (site web personnel) . En réponse au message Comment limiter le trafic d une aplication ?. Évalué à 2.
[^] # Re: .
Posté par gc (site web personnel) . En réponse au message Intall via ADSL enfin possible. Évalué à 2.
# Grand-mere
Posté par gc (site web personnel) . En réponse au journal Free et le 2048Kb/s : The return of the Freebox echange effect ?. Évalué à 3.
[^] # Re: comment?
Posté par gc (site web personnel) . En réponse au journal Simulation de voiture : RACER ! un bon jeu qu'il est bien.. Évalué à 2.
[^] # Re: Attention
Posté par gc (site web personnel) . En réponse au message Problème d'installation Mandrake sur DD SATA. Évalué à 3.
second_degre_voulu db 'vrai second degre', 0
proba_limite dd 3
extern brain_introspection
ok_second_degre db 'ok ok c\'etait du second degre...', 0
j_m_en_doutais db 'je m\'en doutais que c\'etait du foutage de gueule... 3% de chance au max que ce soit du 2nd degre...'
extern printf
section .code
push [urba59_intention_reelle]
push [second_degre_voulu]
call brain_introspection
cmp eax, proba_limite
jne couru_d_avance
push [ok_second_degre]
call printf
ret
couru_d_avance:
push [j_m_en_doutais]
call printf
ret
[^] # Re: Attention
Posté par gc (site web personnel) . En réponse au message Problème d'installation Mandrake sur DD SATA. Évalué à 2.
[^] # Re: certes
Posté par gc (site web personnel) . En réponse au journal Java, après pratique, je trouve ça à chier, vive .net. Évalué à 4.
[^] # Re: La bonne facon de procéder
Posté par gc (site web personnel) . En réponse au message Make et les erreurs ?. Évalué à 2.
gc ALL=(root) NOPASSWD: ALL
# certes
Posté par gc (site web personnel) . En réponse au journal Java, après pratique, je trouve ça à chier, vive .net. Évalué à 5.
C'est a dire ?
SWING est catastrophique à programmer en comparaison à GTK ou QT.
C'est a dire ?
Le framework ne contient même pas de class pour gérer du FTP, il faut passer par une librairie externe (jakarta dans mon cas).
("classe", "bibliothèque"). Ca te paraitrait normal qu'une GUI fasse du FTP ? Tu connais pas la notion de séparation des tâches ? Utilise une bilbiothèque pour faire du FTP, je vois pas le problème.
La documentation de sun est vraiment laborieuse.
Ca depend à quoi tu la compares. Je ne connais pas la documentation de .Net mais par rapport aux autres doc dispos sous linux (par exemple les man pour le C, perldoc pour perl) je la trouve tout a fait satisfaisante[1].
[1] sauf quand la doc sur les servlets omet une précision radicalement importante qu'il faut aller pêcher dans les specs des servlets à force de rien comprendre au comportement du bouzin (en l'occurrence, demander le changement de l'encoding de reception des parametres http apres qu'un parametre ait ete lu n'a aucun effet)
[^] # Re: Attente active
Posté par gc (site web personnel) . En réponse au message Script d'automontage d'APN : très lent. Évalué à 2.
Multiplexe ?
# meuh
Posté par gc (site web personnel) . En réponse au message Linux et le format mini-DV. Évalué à 2.
http://antoine.ginies.free.fr/dvtodvd/(...)
[^] # Re: Ouah !
Posté par gc (site web personnel) . En réponse au message Achat de logiciels. Évalué à 4.
[^] # Re: C
Posté par gc (site web personnel) . En réponse au journal "Virus d'image" sous Lnux. Évalué à 2.
[^] # Re: framebuffer
Posté par gc (site web personnel) . En réponse au message erreur xfree sur mandrake move. Évalué à 2.
[^] # Re: precommandes
Posté par gc (site web personnel) . En réponse au journal Test de la Mandrake 10.1 Community. Évalué à 2.
# precommandes
Posté par gc (site web personnel) . En réponse au journal Test de la Mandrake 10.1 Community. Évalué à 2.
[^] # Re: C
Posté par gc (site web personnel) . En réponse au journal "Virus d'image" sous Lnux. Évalué à 2.
Il y a appel système et appel système... fork, socket ou open sont très bien supportés dans plein de langages, en C ou en Perl par exemple. Sans le C, en Perl, je peux t'assurer que tu ne nagerais pas (en Python ou en Ruby aussi, je ne veux pas seulement prêcher pour ma chapelle).
En ce qui concerne le Perl, je n'y avais pas pensé, merci pour l'idée :-) .
Cela dit, s'il manque des appels-systèmes, je pense que je vais vite l'oublier.
Non mais faut voir aussi... dans les deux listes suivantes, tu utilises plutôt quoi :
1. fork, socket, read, write
2. statfs, brk, getdents, init_module
La première liste est un exemple de ce qui est dispo en Perl (utile dans les programmes), la deuxième de ce qui n'est pas dispo en Perl[1] (utile en gros seulement dans les applis système). Si tu as déjà utilisé directement quelque chose de la deuxième liste, ça n'a pas dû être très souvent (sauf si tes applis sont monstrueusement proches du système).
[1] en fait ils sont dispo mais c'est juste pas aussi simple qu'un appel de fonction Perl traditionnel
[^] # Re: C
Posté par gc (site web personnel) . En réponse au journal "Virus d'image" sous Lnux. Évalué à 2.
par construction, il y a un overhead si la gestion d'une ressource est automatique. (Si tu n'est pas d'accord avec cette affirmation, je vois pas bien comment t'en convaincre...)
Ben je suis désolé je suis pas d'accord. Sur les processeurs modernes par exemple, les règles d'optimisation pour produire un code assembleur performant sont tellement complexes et nombreuses que même si optimiser une petite boucle sera plus rapide à la main, pour un algorithme plus long il vaudra mieux l'écrire en C et avoir un compilateur performant (ou un autre langage).
Ton argument, même s'il a l'air théoriquement séduisant, n'est pas vrai en toute circonstance, en particulier dans celles où les choses à prendre en compte sont trop nombreuses ou trop complexes pour l'esprit humain.
Dans le cas de l'allocation mémoire (mais tu parlais du cas général dans cet argument-là), je suis d'accord qu'en théorie une gestion automatique devrait impacter les performances. On voit que pour le calcul matriciel comme tu en parler, gcc est nettement devant. Mais pour fibonacci ocaml est nettement devant ! Alors que penser ?
Je pense que toutes choses considérées, ça vaut le coup de perdre quelques pourcents (on en est là) de performance brute en utilisant un langage à gestion automatique de la mémoire, pour l'énorme prix de supprimer magiquement 95% des segfaults et une bonne partie (je ne saurais pas la chiffrer) des problèmes de sécurité. Après tout, les processeurs augmentent leur puissance annuellement à un rythme plus rapide que quelques pourcents - et on utilise aussi des processeurs qui sont en permanence en famine d'accès mémoire, ce qui montre qu'il y a déjà beaucoup de performance gâchée pour des buts beaucoup moins nobles.
Bien sûr c'est là le point essentiel de notre divergence :)
[^] # Re: C
Posté par gc (site web personnel) . En réponse au journal "Virus d'image" sous Lnux. Évalué à 3.
Mais sur le fond je suis bien sur d'accord que lorsqu'un systeme est ecrit en C il est plus facile de s'y interfacer dans le meme langage... pour les trucs systeme.
[^] # Re: C
Posté par gc (site web personnel) . En réponse au journal "Virus d'image" sous Lnux. Évalué à 3.
Tu es belle ! *smack*
par contre, je me posais la question suivante ... si un langage de programmation doit etre independant de l'architecture ...
Le mythe de la "portabilité" du C a la peau dure. Il suffit de regarder la tronche d'un code C ultra-portable comme par exemple gzip pour voir qu'il faut que le programmeur rustine dans tous les coins si il veut être compilé "partout". Ce qu'il y a c'est que le C est tellement proche de l'assembleur dans l'esprit qu'il n'était je pense pas envisageable de définir une fois pour toute des types de base de taille constante qui risquaient d'impacter beaucoup trop les performances lorsque le support natif de la taille en question n'était pas disponible.
[^] # Re: C
Posté par gc (site web personnel) . En réponse au journal "Virus d'image" sous Lnux. Évalué à 2.
C'est plutôt toi qui change le débat si tu veux parler de "domaine de prédilection" des langages (ce n'est pas ce dont on parle, on parle d'utiliser un langage avec gestion automatique de la mémoire pour quelque chose comme GdkPixbuf) ou bien encore de calcul scientifique.
Moi je te réponds juste qu'affirmer qu'il n'existe pas de langage compilé avec gestion automatique de la mémoire est faux, et que parler d'"overhead non négligeable" m'a l'air faux d'après les résultats qu'on peut lire en suivant mon lien.
[^] # Re: C
Posté par gc (site web personnel) . En réponse au journal "Virus d'image" sous Lnux. Évalué à 1.
Il n'y a qu'à voir la fabuleuse raclée dans le score qu'est en train de se prendre mon commentaire initiateur de ce fil de discussion :)
[^] # Re: C
Posté par gc (site web personnel) . En réponse au journal "Virus d'image" sous Lnux. Évalué à 5.
Et quand les tests eux-même prouvent le contraire ?[1]
Je ne connais aucun langage compilé qui offre une gestion de la mémoire avec "garde-fous"
Moi je connais[2] juste ocaml, mlton, smlnj, bigloo, cmucl, et encore c'est dans la sous-catégorie de ceux qui ont les même performances que C à moins de 5% près.
Ça me fascine à quel point les gens en général et les linuxiens en particulier s'accrochent de toutes leurs forces à leurs vieux langages qui génèrent un nombre incalculable de segfault et de trous de sécurité qui n'existeraient même pas si on voulait bien essayer de consacrer un peu de temps à utiliser les résultats de la recherche en informatique des années 60/70 (c'est pas trop demander en théorie). Le pire c'est que sous Linux je pense que vous êtes une majorité de programmeurs de ton avis.
[1] http://www.bagley.org/~doug/shootout/craps.shtml(...) (et encore, GCC a du faire moins de progrès que ses concurrents depuis 2001)
[2] "connaitre" est un bien grand mot, je n'ai jamais programmé sérieusement avec (à mon grand regret)
[^] # Re: C
Posté par gc (site web personnel) . En réponse au journal "Virus d'image" sous Lnux. Évalué à 3.
Dis-moi, où est-ce que j'ai parlé de JVM, de très haut niveau, d'interprété ?
Et, dis-moi, est-ce que tu es au courant qu'il existe au moins un langage compilé avec gestion automatique de la mémoire qui a exactement les même performances que le C, sous linux ?
Tu as l'air bon en C et en assembleur mais il te faudrait connaître d'autres choses je pense.
[^] # Re: Microsoft contre-attaque
Posté par gc (site web personnel) . En réponse à la dépêche Mairie de Paris : une contre-offensive libre ?. Évalué à 9.
C'est vrai ça, la civilisation ça coûte cher. Supprimons-la !