2 remarques :
Sous Linux, la différence est faible (voir clone(2))
"Les variables sont les même" : avec la portée, tu t'en sort
le multi proc, les nouvelles (pas très fraîches) que j'en ai c'est :
le coût de migration d'un thread sur un autre proc n'est pas toujours inférieur au fait de le garder sur place (à cause des caches, entre autres)
le 2ème proc peut servir au noyeau ou aux autres démons.
en C aussi tu peux le faire :
avec la méthode Electric fence (sous UNIX)
tu réserve un truc plus long que nécessaire, tu le mmap(1) dans un fichier, tu vire l'accès en lecture au fichier, tu catche le signal SIGSEGV (signal(1)) et tu parcours le truc j'usqu'au signal.
2 petits problèmes :
BSD et Linux n'ont pas le même comportement de signal(1)
Certains proc ne peuvent accéder qu'a des frontières de mot.
>mais pas du polymorphisme
Je doit me planter de terme, je parle de 2 classes ayant une fonction portant le même nom mais une implémentation différente, ça y'a beaucoup de cas ou c'est faisable à la compilation (entre autre pour les feuilles de l'arbre d'héritage).
J'évite de faire générer des pointeurs sur les fonctions membres dans mes champs de pixels.
Si t'as envie de programmer comme une merde, tu peux le faire avec n'importe quel language.
Simplement, si tu veux programmer proprement (définition libre), y'a des langages qui t'aident plus que d'autres.
Consernant la synchro, la notion de "monitor" est TRES loin d'un mutex posix.
<troll>
MMMMMmmmmmh le tueur, pour gagner un demi (peut-être même moins) cycle d'horloge tu programme tes boucles vers zéro.
On t'a pas parlé d'architecture superscalaire où que ton proc il aurait rien foutu de toute manière (d'où le moins d'un demi) ?
On t'as pas non plus dit que x86 est un des derniers jeu d'instruction cisc (et encore, l'architecture en dessous est de plus en plus risc)?
Commence par travailler sur la complexité, vire tes accès mémoire (1cache miss=200 cmp), tes divisions et modulos (40cmp).
Là tu auras du gain. mais les boucles à l'envers ... j'ai du mal !
</troll>
Ouais, la subtilité, c'est de virer le typage dynamique discrètement (en fait je sais pas bien le faire).
Mais le polymorphisme est vachement pratique en C!
Le problème du inline vient du C, je te le rappelle. Quand tu a du code dans un .h, tu le compile où ? Le même problème se pose avec les templates.
Le problème est résolu en JAVA (un seul fichier par classe) et dans les trucs monolythiques (genre SmallTalk) où tout le code est en vrac dans le fichier.
Ce n'est pas ce que j'ai voulu dire, avec un peu de culture, tu peux faire générer à C++ du C tel que tu l'aurais codé mais sans te prendre la tête (inline automatique, héritage, etc ...).
Il faut voir le C++ comme une série de Macro évoluées au dessus du C.
<ma vie>
Personellement, j'ai du inline asm (deconnectable) au milieu de C++ (pour certains opérateur MMX) et ça marche très vite.
</ma vie>
Il ne faut pas oublier que le C atteint ses limites avec les architectures superscalaire et les instructions SIMD. Le gros problème : il n'a pas de remplaçant.
J'écris mal.
Je parlais d'héritage multiple, en y pensant, j'ai pensé à ce vieux bout d'article lu. Je ne veux PAS dire qu'il y a un problème avec Eiffel, je me souvenais que Eiffel avait traité le problème d'une manière ou d'une autre, sans jugement de valeur.
Je ne veux pas tuer Eiffel (pas avant d'avoir fait connaissance du moins ... on verra après).
Il me semble qu'il y a qqun qui maîtrise Eiffel ici.
Je crois me souvenir (j'ai juste lu une intro y'a 1 ou 2 ans) que lors d'un héritage en diamant (c'est de ça qu'on parle depuis tout-à-l'heure) tu choisi pour chaque symbole l'implémentation que tu veux (classe de gauche ou classe de droite).
Là où je suis actuellement (jusqu'à vendredi prochain) ils développent sous win2k.
Comme je suis en recherche, je suis indépendant (donc sous linux).
J'ai du faire une démo sous win pour un salon :
la misère. J'ai développé sous Linux avec 3 #ifdef
et j'ai porté au dernier moment.
Le débugger de mémoire (Purify de Rationnal) :5000F, le profiler : pareil, pour la couverture ils ont pas ! Evidemment, ils m'ont pas filé de license temporaire (c'est la misère à désinstaller parraît-il)
Le MsDEV ne suit pas les pointeurs sur fonction (dommage, j'utilise GLUT)
J'ai utilisé gcc, gdb, gprof,gmake,gcov et electric fence (gdb bloque le sigsegv et rend la main). Moyenne en quoi pour 0 francs j'avais mieux qu'eux.
C'était la première fois que je faisait une couverture, j'incite tout le mond à en faire, ontrouve des bugs insoupsonnables avec ça !
C'est lourd, je connait une dizaine de langages (heum des fois j'oublie un peu) mais j'ai jammais trouvé le bon.
Je vais m'intéresser à eiffel, ruby et python bientôt, le problème c'est qu'on passe sa vie à apprendre des languages (et souvent les bibliothèque qui vont avec) mais : on fout rien de sa vie, on repasse au C au moindre problème, aucun n'est satisfaisant.
Récement, j'ai repris un truc en Smalltalk, c'est sympa (y'a rien comme syntaxe, super objet, packages), un peu déroutant au début (expression exécutées de gauche à droite, 3 niveaux de priorité) mais c'est super lent, et c'est limite monolythique (ça c'est une impression).
En dehors de la portabilité (très discutable de plus) JAVA apporte une maintenabilité impressionnante face au C++, ceux qui connaissent le nom "génie logiciel" savent de quoi je parle.
1 fichier par classe
la notion (explicite) de package
pas de pointeur (ça ne résout pas tout, mais ça aide)
la notion d'INTERFACE
la notion de SYNCHRONISATION (implémentez un monitor en C++, vous m'en direz des nouvelles)
Y'en a d'autres mais ça fait longtemps ...
Actuellement je suis au C (plus ou moins ++)... pour la vitesse (traitement de l'image en temps réel).
Sincèrement ?
heuu non, je peux pas imprimer (avec une OKI 7200, achetez pas OKI, ça marche pas sous Linux, ça imprime même pas en TCP/IP, que en NetMachin).
Et rebooter sous Win2K ça prend au moins 15min (en comptant le login).
[^] # Re: threads/process
Posté par Dugland Bob . En réponse à la dépêche Caudium v/s Apache. Évalué à 1.
Sous Linux, la différence est faible (voir clone(2))
"Les variables sont les même" : avec la portée, tu t'en sort
le multi proc, les nouvelles (pas très fraîches) que j'en ai c'est :
le coût de migration d'un thread sur un autre proc n'est pas toujours inférieur au fait de le garder sur place (à cause des caches, entre autres)
le 2ème proc peut servir au noyeau ou aux autres démons.
[^] # Re: en JAVA????
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
avec la méthode Electric fence (sous UNIX)
tu réserve un truc plus long que nécessaire, tu le mmap(1) dans un fichier, tu vire l'accès en lecture au fichier, tu catche le signal SIGSEGV (signal(1)) et tu parcours le truc j'usqu'au signal.
2 petits problèmes :
BSD et Linux n'ont pas le même comportement de signal(1)
Certains proc ne peuvent accéder qu'a des frontières de mot.
Trop facile !
[^] # Re: en JAVA????
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
Tous les jours je découvre une instruction !
Pour le café, ils ont rien chez Intel ?
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
T'inquiète pas, je relis régulièrement !
surtout en ce moment.
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
Je doit me planter de terme, je parle de 2 classes ayant une fonction portant le même nom mais une implémentation différente, ça y'a beaucoup de cas ou c'est faisable à la compilation (entre autre pour les feuilles de l'arbre d'héritage).
J'évite de faire générer des pointeurs sur les fonctions membres dans mes champs de pixels.
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
Simplement, si tu veux programmer proprement (définition libre), y'a des langages qui t'aident plus que d'autres.
Consernant la synchro, la notion de "monitor" est TRES loin d'un mutex posix.
[^] # Re: Vraiment impressionant ... (explication sur java A LIRE!)
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
Pourquoi tout le monde utilise Windows ?
Pourquoi IBM parle de Linux ?
Pourquoi on parle de l'UMTS ?
Parce-que c'est la mode.
[^] # Re: en JAVA????
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à -1.
Java ça pue, c'est indiscutable, un point c'est tout !
[^] # Re: en JAVA????
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
MMMMMmmmmmh le tueur, pour gagner un demi (peut-être même moins) cycle d'horloge tu programme tes boucles vers zéro.
On t'a pas parlé d'architecture superscalaire où que ton proc il aurait rien foutu de toute manière (d'où le moins d'un demi) ?
On t'as pas non plus dit que x86 est un des derniers jeu d'instruction cisc (et encore, l'architecture en dessous est de plus en plus risc)?
Commence par travailler sur la complexité, vire tes accès mémoire (1cache miss=200 cmp), tes divisions et modulos (40cmp).
Là tu auras du gain. mais les boucles à l'envers ... j'ai du mal !
</troll>
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
Mais le polymorphisme est vachement pratique en C!
Le problème du inline vient du C, je te le rappelle. Quand tu a du code dans un .h, tu le compile où ? Le même problème se pose avec les templates.
Le problème est résolu en JAVA (un seul fichier par classe) et dans les trucs monolythiques (genre SmallTalk) où tout le code est en vrac dans le fichier.
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
Il faut voir le C++ comme une série de Macro évoluées au dessus du C.
<ma vie>
Personellement, j'ai du inline asm (deconnectable) au milieu de C++ (pour certains opérateur MMX) et ça marche très vite.
</ma vie>
Il ne faut pas oublier que le C atteint ses limites avec les architectures superscalaire et les instructions SIMD. Le gros problème : il n'a pas de remplaçant.
[^] # Re: Bonne nouvelle :-)
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
[^] # Re: c'etait quoi ton probleme avec Eiffel?
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
Je parlais d'héritage multiple, en y pensant, j'ai pensé à ce vieux bout d'article lu. Je ne veux PAS dire qu'il y a un problème avec Eiffel, je me souvenais que Eiffel avait traité le problème d'une manière ou d'une autre, sans jugement de valeur.
Je ne veux pas tuer Eiffel (pas avant d'avoir fait connaissance du moins ... on verra après).
[^] # Re: Ruby, c'est bien. si c'est vrai d'abord !
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
[^] # Re: en JAVA????
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
Ils ont quelle tête les investisseurs d'i2bp maintenant ?
[^] # Re: Ruby, c'est bien. si c'est vrai d'abord !
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
Je suis ETUDINAT à la fac !
j'ai encore plus de temps libre qu'eux !
[^] # Re: Vraiment impressionant ... (explication sur java A LIRE!)
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
Natif->JVM (ou JNI, mais pas dans les classes natives)
Sun ne donne pas les source de sa JVM
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
Je crois me souvenir (j'ai juste lu une intro y'a 1 ou 2 ans) que lors d'un héritage en diamant (c'est de ça qu'on parle depuis tout-à-l'heure) tu choisi pour chaque symbole l'implémentation que tu veux (classe de gauche ou classe de droite).
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
Comme je suis en recherche, je suis indépendant (donc sous linux).
J'ai du faire une démo sous win pour un salon :
la misère. J'ai développé sous Linux avec 3 #ifdef
et j'ai porté au dernier moment.
Le débugger de mémoire (Purify de Rationnal) :5000F, le profiler : pareil, pour la couverture ils ont pas ! Evidemment, ils m'ont pas filé de license temporaire (c'est la misère à désinstaller parraît-il)
Le MsDEV ne suit pas les pointeurs sur fonction (dommage, j'utilise GLUT)
J'ai utilisé gcc, gdb, gprof,gmake,gcov et electric fence (gdb bloque le sigsegv et rend la main). Moyenne en quoi pour 0 francs j'avais mieux qu'eux.
C'était la première fois que je faisait une couverture, j'incite tout le mond à en faire, ontrouve des bugs insoupsonnables avec ça !
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à -1.
J'ai bon ?
Je peux faire consultant à une brique la journée maintenant?
Bouge pas :
start-up
Internet
Architecture logicielle
B2B
B2P
CRM
intranet
extranet
bob Ricard (oops!)
workgrouping (en ing ça marke plus de points)
www.kitetoa.com
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
Si tu sait l'utiliser, c'est aussi rapide que du C (vu que ton C++ est traduit en C avant compilation).
Par contre pour l'apprentissage, c'est la misère (gérer le inline, le volatile).
J'ai été obligé d'arrêter le trip quand je me suis noyé dans les templates (un jour j'y arriverais).
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
En plus tu vire la partie problématique de l'héritage multiple (j'ai un vieux souvenir de Eiffel qui me reviens en tête à ce propos).
[^] # Re: Et Ruby, hein ?
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
Je vais m'intéresser à eiffel, ruby et python bientôt, le problème c'est qu'on passe sa vie à apprendre des languages (et souvent les bibliothèque qui vont avec) mais : on fout rien de sa vie, on repasse au C au moindre problème, aucun n'est satisfaisant.
Récement, j'ai repris un truc en Smalltalk, c'est sympa (y'a rien comme syntaxe, super objet, packages), un peu déroutant au début (expression exécutées de gauche à droite, 3 niveaux de priorité) mais c'est super lent, et c'est limite monolythique (ça c'est une impression).
[^] # Re: Quel avenir pour JAVA
Posté par Dugland Bob . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.
1 fichier par classe
la notion (explicite) de package
pas de pointeur (ça ne résout pas tout, mais ça aide)
la notion d'INTERFACE
la notion de SYNCHRONISATION (implémentez un monitor en C++, vous m'en direz des nouvelles)
Y'en a d'autres mais ça fait longtemps ...
Actuellement je suis au C (plus ou moins ++)... pour la vitesse (traitement de l'image en temps réel).
[^] # Re: www.telecom.gouv.fr
Posté par Dugland Bob . En réponse à la dépêche Réaction au rapport Carcenac : oui, MAIS. Évalué à 1.
heuu non, je peux pas imprimer (avec une OKI 7200, achetez pas OKI, ça marche pas sous Linux, ça imprime même pas en TCP/IP, que en NetMachin).
Et rebooter sous Win2K ça prend au moins 15min (en comptant le login).