Nicolas LAURENT a écrit 31 commentaires

en meme temps, dans son comparatif il utilise gcc 4.0.0-20040915 qui est au mieux un gcc-4.0-preXX. Peut etre que la release finale apporte un gain en perf. Il y a quand meme 7 mois d'ecart entre les deux! J'espere qu'il y aura une mise a jour de son bench, car il semble bien fait.

J'me reponds tout seul! uucpssh.org semble etre une solution de qualité... j'vais tester!

Je te réponds que ton "overhead non négligeable" est battu en brèche par le comparatif proposé.

cela reste un bench: sur un produit matriciel la vesion C est nettement plus rapide que celle OCalm (presque 40%).... Cela reste un point particulier j'en conviens.


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.

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...). Le tout est de savoir si il est négligeable. Dans certain cas il l'est, ou du moins il est acceptable; dans d'autre il ne l'est pas. Pour ma part, je pense que dans les couches bas niveau il ne l'est pas. Il ne parait pas choquant de dire que GdkPixbuf est un composant "bas niveau" dans le sens ou on peut "empiler dessus" plusieurs couches logicielle.

J'ai l'impression que de débat dérape: j'ai simplement dit que chaque langage possède sont domaine de prédilection. Le bench dont tu propose le lien semble aussi l'indiquer. Par exemple, pour le calcul scientifique, aucun langage ne fait mieux que les langage bas niveau (C, fortarna)... au prix d'une plus grande difficulté de programmation.

hélas je ne blague pas. Une gestion automatique de la mémoire ajoute inévitablement un overhead non négligeable. Je ne connais aucun langage compilé qui offre une gestion de la mémoire avec "garde-fous" (les smart-pointer du C++ ou les bibliothèques genre efence sont des "rustines" dans le sens ou il est assez facile de les mettre en défaut). Aussi, je pense que pour les couches de bas niveau, le développeur dois se reposer sur un algorithme sain et une programmation propre. Il doit éviter les facilités qu'offre certains langages qui automatise certaine tache de gestion. Pour les applications cependant, il ne faut pas se priver (dans la mesure où on ne code pas un bout de code critique) !

Cependant, il est toujours possible faire rajouter du code à la compilation pour valider les accès mémoire (genre purify ou dans une moindre mesure valgrind). Mais cela pose le problème de l'exhaustivité des tests.....



PS. je ne code (quasiment) pas en ASM et je pense connaitre plusieurs langages de programmation, dont une bonne partie non compilé (...)

<mode="ironique">
mais bien sûr, invoquons une jvm pour afficher des PNG....


Les langages compilés (C/C++/fortran/...) reste incontournables et ce n'est pas prés de changer (ne serait-ce que pour coder les interpreteurs). Or, avec ces langages, il n'y a pas de garde barrière. C'est bien au programmeur de réfléchir (une vertue de plus en plus rare on dirait). Cependant, l'avantage c'est la performance. Je sais, beaucoup vont me dire qu'aujourd'hui ce n'est plus un problème, que les machines sont puissantes, que les ressources (mémoire, CPU, disque, ..) sont peu onéreurses.... Mais, personnellement, je trouve ce genre de raisonnement absurde. Evidement, je ne dis pas qu'il faut tout coder en C sous pretexte de performance. Cependant, je n'imagine pas utiliser un langage de très haut niveau et/ou interprété pour implémenter des "briques de base" comme un toolkit graphique.

tu trouveras là (http://perso.club-internet.fr/nicolas-laurent/C/socket.html(...)) un petit tutoriel sur les sockets que j'ai écrit il y a quelques temps. La partie sur l'appel à "select" est détaillée ici:
http://perso.club-internet.fr/nicolas-laurent/C/socket-13.html(...)

Dans ton code, c'est le accept() qui est bloquant. La bonne solution est bien d'utiliser select().


Bon courage.

Je vais peut-être dire un bétise mais purify et valgrind ne fonctionne pas du tout de la même façon:

- valgrind "émule" un processeur et intercepte les accès mémoire.
Valgrind s'utilise à l'exécution d'un programme.

- purify "instrumente" un exécutable pour inserer du code avant chaque accès mémoire pour valider si celui-ci est correct. Purify s'utilise à l'édition des liens d'un exécutable.


Cette différence architecture permet à valgrind d'être utilisable sur la plupart des codes (exécutable, bibliothèque dynamique, ...) là où le concurent de Rational n'est capable que de gérer des exécutables (ciao jni!)

Cependant, cette architecture semble avoir un prix: il parait délicat de faire un portage de valgrind sur d'autre type de plate-forme (sun/solaris, mips/SGI, ...).


J'ai du mal à voir ce que Rational a pu breveté d'autre que "on vérifie que l'accès mémoire est correct". On serait bien loin de la technique.... Et cette idée me parait presque aussi vielle que les OS mutli-taches.

Si tu as des sous pense plutot Wifi! :-)

Salut,

pour ma part, j'ai commencé à lire la doc de bison:

http://www.gnu.org/software/bison/manual/(...)

Pour ce que je voulais faire (m'initier à l'analyse syntaxique) ça m'a largement suffit.

Dans cette doc, les bases sont bien expliquées.

Bonne lecture!

C'est même sûr que non... j'ai déjà fait ce genre de tests.

C'est même sûr que non... j'ai déjà fait ce genre de tests.

ben reteste, ça marche bien, c'est portable et tu ne pourras pas faire plus rapide.


ben pourtant, mes routines (C et ASM) _sont_ plus rapides... et la première est portable.

> "subl $1, %1\n\t"

et dec c'est pour les chiens ? ;)


non mais utiliser subl me fait gagner 17 % en temps....



Tu devrais essayer avec prefetchnta plutôt que prefetcht2

Essaye aussi un prefetch à une distance de 256, ca peut être plus rapide (tu ne donnes pas la taille moyenne de tes vecteurs).


j'ai fait le test avec 256 et c'est les meme resultat qu'avec 128. La taille des vecteurs varie entre 1 et 1500. Dans un meme calcul, il peut y avoir des vecteur de toute taille.



Essaye aussi d'aller dans le sens incrémental pour parcourir ton vecteur (les chipsets sont capables de faire des prefetchs hardware uniquement dans ce sens).


le parcours à l'envers m'a fait gagner quelques % sur MIPS mais effectivement sur ia32 j'y perd.




Sinon, vu comme ta boule de calcul est courte, je pense que quasiment tous les gains se feront sur les accès mémoire.


oui, c'est aussi ma conclusion...

Ben si ! :-)

CPU: Athlon2200+
Ram: 128
3D : GeForceTi4200 8x
Res : 1280x1024
FPS : 4767
FPS p-e : 822

heu.. desole, l'interface graphique est encore a ces debuts... donc il n'y a pas beux screenshots. Il n'y a juste qu'une image d'un prototype d'interface

Si XHTML/CSS ne suffisent plus cela signifie que ton interface ne correspond plus à l'appelation "client léger"... AMHA, utiliser javascript/plugins/autre c'est détourner l'utilisation des navigateurs. Autant appeler un chat, un chat et faire du client lourd avec une techno portable (ou presque)!

Oublie le SUN CC 5 et passe au CC 6! La STL fournie avec la version 5 est moisie et les performances du C++ sont pitoyables!

Par contre je n'ai pas d'élément de comparaison avec gcc...

parce qu'il n'existe pas d'equivalent libre.
dans la CAO (électronique, mécanique ...), le logiciel propriétaire regne en maitre

Inexact: pour la mécanique, Code_Aster, le code de calcul d'EDF, est désormais disponible sous une licence libre. Et il y a deux ou trois logiciels de calcul libre. D'ailleurs je suis en train d'en écrire un (pub!).

Le vrai problème est que ces codes libres ne sont pas du tout utilisés dans l'industrie...

Aller je t'en donne une: la barre de tâche....
Même si personnellement je préfère utiliser des icônes gérer mes applications (comme sous IRIX ou Solaris) je constate que les environnements graphiques majeurs (KDE et GNOME) ont reproduit le même "concept".
Je sais pas si l'idée orignale vient de chez Microsoft mais en tout cas, à ma connaissance, aucun Unix
(commercial ou non) ne le faisait.... Bref, tout ça pour dire que l'attitude systématique "Les produit Micro$oft sont nuls, Linux RuLeZ" est vraiement puérile et foncièrement non-constructive.

<ironique>
Parce toi tu détiens la vérité ultime sans doute......
</ironique>
Je ne vois pourquoi oeuvrer pour les logiciels libres empêcherait d'apprécier Windows 2000. Ici apprécier ne signifie pas encourager mais plutôt s'intéresser à ce que fait Microsoft. Tu sais il n'ont pas _que_ des mauvaises idées les gens de Redmond... Parfois même certains projets libre sont inspirés par leur logiciels... parfois...
Un peu de modération et de curiosité ne peuvent pas faire de mal.

Je suis tout à fait d'accord avec toi!

Tout pareil, mais la mienne elle a encore rien de brulé :-)

"Moi je n'ai aucune honte à jouer avec des jeux dit piratés, vu leur prix.
400 balles : soit c'est destiné à une poignée de privilègiés."

ça me parait clair.