os et concept de langage

Le 05-04-2010, ? propos de
Re: os et concept de langage,
Alban Taraire ?crivait dans fr.comp.os.linux.debats :

On Thu, 01 Apr 2010 12:52:23 +0000, JKB wrote:

Je te demande d'utiliser un calcul de trajet issu de pgrouting

(Boost,

C++) et le même algorithme codé à la main.

Possible mais complètement irrelevant, les API comme Boost ou Qt sont là
principalement pour coder des GUI, pas des algos de traitement.
Évidement si tu as un algo en background qui a besoin d'être rapide, tu
vas pas coder ça en Visual Basic, ça tombe un peu sous le sens (en même
temps, même une GUI sous VB...).

Faut utiliser les bons outils à bon escient.

Sauf que je n'ai pas écrit le SIG de base qui utilise boost. De
plus, lorsque tu regardes attentivement la libboost, il s'agit d'une
bibliothèque d'usage générale avec des tas de fonctions
mathématiques génériques dedans (et là, on est d'accord, c'est une
erreur de la nature !).

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 05-04-2010, ? propos de
Re: os et concept de langage,
Alban Taraire ?crivait dans fr.comp.os.linux.debats :

On Thu, 01 Apr 2010 10:21:41 +0000, JKB wrote:

je ne connait pas motif, mais une interface graphique qui n'est pas obj
si elle ne l'est pas j'en veux pas

Tu peux faire _sans_ objet au sens programmation objet. Et pour

avoir

fait du Qt (objet) et du Motif (non objet), la programmation de

Motif

est bien plus efficace et facile.

Qu'est-ce qu'il faut pas lire ! Efficace, sans doute en terme de taille
de code et/ou de rapidité d'exécution (ce qui, en général pour une GUI,
est quelque chose dont on n'a que foutre tant que ça reste raisonable).

Certainement pas efficace en terme de rapidité de développement.

Dire que c'est plus facile, c'est vraiment du pur snobisme (et un
mensonge). Tu serais pas du genre à coder avec ed toi ? ;)

Non, même pas. Mais j'ai fait mes armes en programmation impérative
et fonctionnelle. Je ne vois toujours pas ce qui fait que la
programmation objet est supérieure à une programmation impérative.
J'entends par là de vrais arguments, pas des poncifs du type "c'est
mieux parce qu'on utilise des objets".

Rien n'empêche d'utiliser des modules à la façon Fortran dans une
programmation impérative. On peut écrire des trucs non maintenables
dans n'importe quel type de langage et aujourd'hui, les codes les
plus dégueulasses qu'il m'a été donné de voir ont été écrits en C++.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 05-04-2010, ? propos de
Re: os et concept de langage,
Alban Taraire ?crivait dans fr.comp.os.linux.debats :

On Thu, 01 Apr 2010 09:23:41 +0000, JKB wrote:

Pourquoi ? J'ai codé des trucs parfaitement aboutis avec un simple
compilo C et X11/Xt/Xm. Pas besoin de C++ pour cela. Et Motif est
un truc _très_ agréable à coder en C.

En général j'ai tendance à être d'accord ou au moins respecter ce que tu
dis, mais là quand même trouver Motif _très_ agréable faut arrêter la
fumette (ou être maso). Ou alors ça a *beaucoup* changé ces 15 dernières
années ?

Il y a un truc vraiment bien dans Motif et qui a été rejeté dans
tous les trucs plus modernes : Xm a été écrit comme le successeur de
Xt et de X11 et tous les objets sont orthogonaux. Dans Qt ou dans
GTK (au hasard), rien n'est vraiment orthogonal. Ça me fait même
penser au PL/1 : nouveau besoin, nouveau patch. C'est cette clarté
que je trouve agréable par rapport à du Qt ou du GTK. Et ça reste
clair même avec des fenêtres assez compliquées.

Maintenant, on peut ne pas aimer le
design de Motif, personnellement, j'aime assez parce que ce
design se fait par un fichier externe au soft compilé, ce qui est très
bien.

C'est pas très spécifique à Motif ça... Tiens prends un truc moderne
comme Qt, c'est pareil : ton UI dans un fichier séparé (et en XML super
simple), et ton code à part.

Même là-dedans, ils ont réussi à foutre du XML... Le Xressource, ce
n'était certainement pas assez bien...

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

On Tue, 06 Apr 2010 07:33:09 +0000, JKB wrote:

Sauf que je n'ai pas écrit le SIG de base qui utilise boost. De

plus,

lorsque tu regardes attentivement la libboost, il s'agit d'une
bibliothèque d'usage générale avec des tas de fonctions

mathématiques

génériques dedans (et là, on est d'accord, c'est une erreur de la
nature !).

C'est surtout une question d'utilisation. En fait si tu y réfléchis bien,
vue la puissance des pc actuels, très peu d'applications ont vraiment
*besoin* d'être rapides à exécuter.
Combien d'applis doivent gérer les rues de tout un pays ? Combien doivent
parcourir un arbre de plus de quelques dizaines d'entrées ?

Par contre ce qui compte, c'est de pouvoir coder vite, faire des UI
marketables (c'est à dire jolies), et éventuellement portables sans trop
de soucis.
C'est ça les besoins du marché, pas d'avoir la meilleure implémentation
en assembleur qui prend 0.001s de moins que le concurrent en Qt ou Boost.
Et si un gars a besoin mettons de trier un tableau de 100 nombres, qu'il
le fasse avec les algos génériques de Boost ne me pose aucun problème,
plutôt que perdre du temps à réimplémenter un truc complexe pour gagner
peanuts.

Et si tu as vraiment besoin de vitesse, rien ne t'empêche de développer
rapidement les parties simples en Qt, et le reste en ce que tu veux.
Tiens prends Bibble par exemple (http://www.bibblelabs.com).

Ils ont sans doute le développeur de RAW le plus rapide et le plus
optimisé pour multicores/proc du marché.
L'UI est faite en Qt, et leurs algos en je ne sais quoi (autre chose en
tous cas ça c'est sûr).
Résultat, c'est super rapide, ça présente bien, c'est portable (Win/Mac/
Linux) et c'est même pas très cher.

Je trouve que c'est un très bon exemple de savoir optimiser juste ce
qu'il faut optimiser (les algos de traitement) sans perdre de temps à
*tout* optimiser.

Ça me fait penser à l'anecdote de je ne sais plus qui (Stroustrup ou un
type de ce style) qui racontait qu'un gars de son université (ça remote à
loin) faisait des concours avec les machines de l'époque vs. lui et sa
règle à calcul.
C'est vrai qu'il était super rapide, et qu'il avait vraiment optimisé
l'utilisation de sa règle, mais au final pour quoi ? Il allait de toutes
façons se faire écraser un jour ou l'autre.

Bref, optimiser, c'est bien, mais à bon escient.

--
Alban

Le 06-04-2010, ? propos de
Re: os et concept de langage,
Alban Taraire ?crivait dans fr.comp.os.linux.debats :

On Tue, 06 Apr 2010 07:33:09 +0000, JKB wrote:

Sauf que je n'ai pas écrit le SIG de base qui utilise boost. De

plus,

lorsque tu regardes attentivement la libboost, il s'agit d'une
bibliothèque d'usage générale avec des tas de fonctions

mathématiques

génériques dedans (et là, on est d'accord, c'est une erreur de la
nature !).

C'est surtout une question d'utilisation. En fait si tu y réfléchis bien,
vue la puissance des pc actuels, très peu d'applications ont vraiment
*besoin* d'être rapides à exécuter.
Combien d'applis doivent gérer les rues de tout un pays ? Combien doivent
parcourir un arbre de plus de quelques dizaines d'entrées ?

Tu n'imagines même pas. Mes applications à moi, elles se contentent
de faire du géocodage d'adresse puis des optimisations. Et là, le
temps CPU se compte en dizaines d'heures.

Par contre ce qui compte, c'est de pouvoir coder vite, faire des UI
marketables (c'est à dire jolies), et éventuellement portables sans trop
de soucis.
C'est ça les besoins du marché, pas d'avoir la meilleure implémentation
en assembleur qui prend 0.001s de moins que le concurrent en Qt ou Boost.
Et si un gars a besoin mettons de trier un tableau de 100 nombres, qu'il
le fasse avec les algos génériques de Boost ne me pose aucun problème,
plutôt que perdre du temps à réimplémenter un truc complexe pour gagner
peanuts.

On ne doit pas avoir la même notion du peanuts.

Et si tu as vraiment besoin de vitesse, rien ne t'empêche de développer
rapidement les parties simples en Qt, et le reste en ce que tu veux.
Tiens prends Bibble par exemple (http://www.bibblelabs.com).

Ils ont sans doute le développeur de RAW le plus rapide et le plus
optimisé pour multicores/proc du marché.
L'UI est faite en Qt, et leurs algos en je ne sais quoi (autre chose en
tous cas ça c'est sûr).
Résultat, c'est super rapide, ça présente bien, c'est portable (Win/Mac/
Linux) et c'est même pas très cher.

Je trouve que c'est un très bon exemple de savoir optimiser juste ce
qu'il faut optimiser (les algos de traitement) sans perdre de temps à
*tout* optimiser.

Je n'ai jamais dit le contraire. Maintenant, j'aimerais que tu
m'expliques sans rire comment optimiser un traitement SIG qui
utilise Boost alors même que Boost est mauvais.

Ça me fait penser à l'anecdote de je ne sais plus qui (Stroustrup ou un
type de ce style) qui racontait qu'un gars de son université (ça remote à
loin) faisait des concours avec les machines de l'époque vs. lui et sa
règle à calcul.
C'est vrai qu'il était super rapide, et qu'il avait vraiment optimisé
l'utilisation de sa règle, mais au final pour quoi ? Il allait de toutes
façons se faire écraser un jour ou l'autre.

Bref, optimiser, c'est bien, mais à bon escient.

Je pense surtout qu'on ne joue pas dans la même cour. Lorsque
j'arrive à grater 10% sur des opérations, les 10% sont bons à
prendre soit pour donner le résultat plusieurs heures avant, soit
pour rajouter des choses dans les algorithmes. Je n'en suis pas à
m'emmerder pour avoir le résultat d'une feuille de calcul en 2 ms au
lieu de 10 !

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 6 Apr 2010 11:32:08 GMT
Alban Taraire <zarma@toto.com> a écrit :

On Tue, 06 Apr 2010 07:33:09 +0000, JKB wrote:

> Sauf que je n'ai pas écrit le SIG de base qui utilise
> boost. De
plus,
> lorsque tu regardes attentivement la libboost, il s'agit
> d'une bibliothèque d'usage générale avec des tas de fonctions
mathématiques
> génériques dedans (et là, on est d'accord, c'est une erreur
> de la nature !).

C'est surtout une question d'utilisation. En fait si tu y réfléchis
bien, vue la puissance des pc actuels, très peu d'applications ont
vraiment *besoin* d'être rapides à exécuter.
Combien d'applis doivent gérer les rues de tout un pays ? Combien
doivent parcourir un arbre de plus de quelques dizaines d'entrées ?

Par contre ce qui compte, c'est de pouvoir coder vite, faire des UI
marketables (c'est à dire jolies), et éventuellement portables sans
trop de soucis.
C'est ça les besoins du marché, pas d'avoir la meilleure
implémentation en assembleur qui prend 0.001s de moins que le
concurrent en Qt ou Boost. Et si un gars a besoin mettons de trier un
tableau de 100 nombres, qu'il le fasse avec les algos génériques de
Boost ne me pose aucun problème, plutôt que perdre du temps à
réimplémenter un truc complexe pour gagner peanuts.

Et si tu as vraiment besoin de vitesse, rien ne t'empêche de
développer rapidement les parties simples en Qt, et le reste en ce
que tu veux. Tiens prends Bibble par exemple
(http://www.bibblelabs.com).

Ils ont sans doute le développeur de RAW le plus rapide et le plus
optimisé pour multicores/proc du marché.
L'UI est faite en Qt, et leurs algos en je ne sais quoi (autre chose
en tous cas ça c'est sûr).
Résultat, c'est super rapide, ça présente bien, c'est portable
(Win/Mac/ Linux) et c'est même pas très cher.

Je trouve que c'est un très bon exemple de savoir optimiser juste ce
qu'il faut optimiser (les algos de traitement) sans perdre de temps à
*tout* optimiser.

Ça me fait penser à l'anecdote de je ne sais plus qui (Stroustrup ou
un type de ce style) qui racontait qu'un gars de son université (ça
remote à loin) faisait des concours avec les machines de l'époque vs.
lui et sa règle à calcul.
C'est vrai qu'il était super rapide, et qu'il avait vraiment optimisé
l'utilisation de sa règle, mais au final pour quoi ? Il allait de
toutes façons se faire écraser un jour ou l'autre.

Bref, optimiser, c'est bien, mais à bon escient.

Règles de l'optimisation (par les gourous de l'optimisation) :
- Règle numéro 1 : Ne le faites pas.
- Règle numéro 2 (pour les experts seulement) : Ne le faites pas
maintenant.

Le 06-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :

Yliur a écrit :

Règles de l'optimisation (par les gourous de l'optimisation) :
- Règle numéro 1 : Ne le faites pas.
- Règle numéro 2 (pour les experts seulement) : Ne le faites pas
maintenant.

dit différemment
la meilleure optimisation qui soit
c'est la lisibilité du code

Venant de toi, on ne peut s'attendre à mieux. L'optimisation d'un
bout de code, surtout en calcul intensif, ce n'est pas la lisibilité
du code. Si tu ouvres n'importe quel bouquin d'analyse numérique, tu
verras que c'est même assez souvent orthogonal comme notion.

de la part d'un ancien tripatouilleur d'assembleur 6800

Et ?

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB a écrit :

Le 06-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :

Yliur a écrit :

Règles de l'optimisation (par les gourous de l'optimisation) :
- Règle numéro 1 : Ne le faites pas.
- Règle numéro 2 (pour les experts seulement) : Ne le fai tes pas
maintenant.

dit différemment
la meilleure optimisation qui soit
c'est la lisibilité du code

Venant de toi, on ne peut s'attendre à mieux. L'optimisation d'un
bout de code, surtout en calcul intensif, ce n'est pas la lisibilità ©
du code. Si tu ouvres n'importe quel bouquin d'analyse numérique, tu
verras que c'est même assez souvent orthogonal comme notion.

oui mais le calcul intensif ne représente pas grand chose en terme
de quantité de lignes écrites,l'optimisation réside plus d ans la méthode
de calcul que dans l'écriture du calcul

tiens un exemple posté il n'y a pas longtemps sur fsm
tu peux optimiser tout ce que tu veux "code pondu à l'arraché"

http://groups.google.com/group/fr.sci.maths/browse_thread/thread/61b3e6d9 8acd7912/20845b6b8fd5dc2c?lnk=gst&q=remy+bc+#20845b6b8fd5dc2c

cela te met sur les genoux n'importe quel super, hyper, mega calculateur
de la mort qui tue sur place

les pouillièmes gagnés par l'optimisation sont insignifiants
sauf si tu répartis le calcul bien sûr et de manière optim isée de
préférence ,mais l'on est là encore dans la méthode
et non pas dans l'écriture à proprement parlé du calcul

de la part d'un ancien tripatouilleur d'assembleur 6800

Et ?

non rien, un vieux souvenir où je m'étais évertué à   essayer de
comprendre une routine optimisée, cela c'est fini par une réà ©criture

JKB

--
http://remyaumeunier.chez-alice.fr/

Le 06-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Le 06-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :

Yliur a écrit :

Règles de l'optimisation (par les gourous de l'optimisation) :
- Règle numéro 1 : Ne le faites pas.
- Règle numéro 2 (pour les experts seulement) : Ne le faites pas
maintenant.

dit différemment
la meilleure optimisation qui soit
c'est la lisibilité du code

Venant de toi, on ne peut s'attendre à mieux. L'optimisation d'un
bout de code, surtout en calcul intensif, ce n'est pas la lisibilité
du code. Si tu ouvres n'importe quel bouquin d'analyse numérique, tu
verras que c'est même assez souvent orthogonal comme notion.

oui mais le calcul intensif ne représente pas grand chose en terme
de quantité de lignes écrites,l'optimisation réside plus dans la méthode
de calcul que dans l'écriture du calcul

Gnîii ? Comme tu travailles sur une représentation finie, je te mets
au défi de séparer le calcul théorique de sa représentation
infromatique sans un jour ou l'autre se tirer une balle dans le
pied !

tiens un exemple posté il n'y a pas longtemps sur fsm
tu peux optimiser tout ce que tu veux "code pondu à l'arraché"

http://groups.google.com/group/fr.sci.maths/browse_thread/thread/61b3e6d98acd7912/20845b6b8fd5dc2c?lnk=gst&q=remy+bc+#20845b6b8fd5dc2c

Tu n'en as pas marre de faire de l'autopromo ? Surtout vu le contenu
de l'enfilade...

cela te met sur les genoux n'importe quel super, hyper, mega calculateur
de la mort qui tue sur place

les pouillièmes gagnés par l'optimisation sont insignifiants
sauf si tu répartis le calcul bien sûr et de manière optimisée de
préférence ,mais l'on est là encore dans la méthode
et non pas dans l'écriture à proprement parlé du calcul

<soupir>

Pour rappel, le postulat de base était que lorsque tu as des gros
calculs à écrire, tu commences par optimiser ce que tu peux en
faisant des optimisations triviales (dans le fil, virer des
aberrations comme Boost pour coder un A* à la main plutôt que
d'empiler pgrouting + Boost le tout sur postgresql, même si au final
ça le ferait). Un fois que tu as pris la peine de faire cette
première phase d'optimisation, tu peux encore gratter aux marges
mais le gros du boulot, c'est éviter de faire des conneries en
utilisant des briques toutes faites qui sont trivialement
sous-optimales.

En d'autres termes, parce que tu as la comprenette bouchée à l'émeri :
si tu dois calculer pour un jeu sur un échiquier le trajet d'une
pièce, boost est ton ami (mais tu pourrais aussi y aller avec une
recherche exhaustive). Si maintenant, tu dois calculer les trajets
d'un voyageur de commerce à l'échelle d'un département, boost n'est
plus ton ami, même si théoriquement, la bibliothèque sait faire.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB a écrit :

Le 06-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Le 06-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :

Yliur a écrit :

Règles de l'optimisation (par les gourous de l'optimisation) :
- Règle numéro 1 : Ne le faites pas.
- Règle numéro 2 (pour les experts seulement) : Ne le f aites pas
maintenant.

dit différemment
la meilleure optimisation qui soit
c'est la lisibilité du code

Venant de toi, on ne peut s'attendre à mieux. L'optimisation d' un
bout de code, surtout en calcul intensif, ce n'est pas la lisibilità ©
du code. Si tu ouvres n'importe quel bouquin d'analyse numériqu e, tu
verras que c'est même assez souvent orthogonal comme notion.

oui mais le calcul intensif ne représente pas grand chose en term e
de quantité de lignes écrites,l'optimisation réside plu s dans la méthode
de calcul que dans l'écriture du calcul

Gnîii ? Comme tu travailles sur une représentation finie, je te mets
au défi de séparer le calcul théorique de sa repré sentation
infromatique sans un jour ou l'autre se tirer une balle dans le
pied !

donc on est d'accord

tiens un exemple posté il n'y a pas longtemps sur fsm
tu peux optimiser tout ce que tu veux "code pondu à l'arraché "

http://groups.google.com/group/fr.sci.maths/browse_thread/thread/61b3e 6d98acd7912/20845b6b8fd5dc2c?lnk=gst&q=remy+bc+#20845b6b8fd5dc2c

Tu n'en as pas marre de faire de l'autopromo ?

si je ne le fais pas, c'est pas toi qui le ferra :-)

Surtout vu le contenu
de l'enfilade...

je m'en fou de l'enfilade ,je prends juste un exemple et une question
qui restent en suspens pour moi, qui en plus rentre parfaitement dans le
cadre, l'on a bien un calcul intensif et une non-optimisation ,se
compliquer la vie ne sert pas à grand chose sauf à se faire pla isir

cela te met sur les genoux n'importe quel super, hyper, mega calculate ur
de la mort qui tue sur place

les pouillièmes gagnés par l'optimisation sont insignifiants
sauf si tu répartis le calcul bien sûr et de manière op timisée de
préférence ,mais l'on est là encore dans la méthod e
et non pas dans l'écriture à proprement parlé du calcul

<soupir>

Pour rappel, le postulat de base était que lorsque tu as des gros
calculs à écrire, tu commences par optimiser ce que tu peux en
faisant des optimisations triviales (dans le fil, virer des
aberrations comme Boost pour coder un A* à la main plutôt qu e
d'empiler pgrouting + Boost le tout sur postgresql, même si au fi nal
ça le ferait). Un fois que tu as pris la peine de faire cette
première phase d'optimisation, tu peux encore gratter aux marges
mais le gros du boulot, c'est éviter de faire des conneries en
utilisant des briques toutes faites qui sont trivialement
sous-optimales.

En d'autres termes, parce que tu as la comprenette bouchée à l'émeri :
si tu dois calculer pour un jeu sur un échiquier le trajet d'une
pièce, boost est ton ami (mais tu pourrais aussi y aller avec une
recherche exhaustive). Si maintenant, tu dois calculer les trajets
d'un voyageur de commerce à l'échelle d'un département, boost n'est
plus ton ami, même si théoriquement, la bibliothèque sa it faire.

cela dépend avant tout pour moi ,de ce que tu veux en faire
la question est plutôt : cela vaut il le coup de réécrire le bouzin

ton client, tu le tiens bien par c... ?

JKB

--
http://remyaumeunier.chez-alice.fr/