Discussion :

[FR119492]

Bonjour à tous!
Ce soir, je vous propose une petite question pour tester vos connaissances sur les langages que vous adorez ou que vous détestez:

On veut remplir avec la valeur 0.0+j*0.0 toutes les cases d'un tableau 10'000*10'000, déclaré en complexe sur 16 octets. Vaut-il mieux le parcourir ligne par ligne ou colonne par colonne?

A mon avis, il est indispensable qu'un programmeur connaisse la réponse valable pour le langage qu'il utilise, et ça fait partie des connaissances de base. Alors, qu'en est-il pour le langage préféré de chacun d'entre vous?

Jean-Marc Blanc

PS. En ce qui concerne le Fortran, c'est colonne par colonne.

[deadalnix]

Franchement RAB, combien de fois j'alloue un tableau de 100 000*100 000 complexes ? (oui en france, c'est des espace pas des ' et savoir écrire les nombres, c'est au moins aussi important que le cache CPU). Early optimisation is the root of evil. Commencer par se poser cette question, c'est donc pour moi l'assurance de pondre du code de merde.

Puis vachement utile pour traiter un signal sur un DSP, programmer un protocole réseau, faire une interface graphique ou un pilote de périphérique.

Sans compter que l'appellation ligne colonnes est largement arbitraire, et va montrer très vite ses limites quand on fait un tableau de tableau de tableau.

Enfin, on peut considérer que c'est le cache qui doit s'adapter aux diverses manières de coder et non l'inverse et/ou au compilo de gérer de telles optimisations.

A ce titre la, allons y de nos questions capillotractées : peut-on dans votre langage mettre ne œuvre l'optimisation dual-loop afin de profiter d'une meilleure prédiction de branchement dans le CPU ? (en C on peut, mais pour des langages haut niveau, je suis pas sur que ça marche).

[Mac LAK]

la compréhension du cache est au moins aussi importante que de choisir le bon algo... Tout comme savoir sur quelle plate-forme on travaille...

Tu n'as pas les mêmes performances avec un CPU Intel et le compilateur Intel qu'avec un GCC basique sur un PowerPC, par exemple, notamment parce que le premier offre des fonctions câblées qui seront utilisées automatiquement... Et que ton "super algo" sur Intel sera peut-être une vieille bouse sur un PPC ! Tandis qu'un bon algo PPC (c'est à dire utilisant un max de registres) sera en règle générale totalement poussif sur un Intel.

Et là, c'est une différence qu'aucun compilateur ne pourra combler, il faut effectivement finir par implémenter deux algos différents et optimisés pour la plate-forme.

Tout comme éviter de travailler en dehors des limites de cache : tu peux la jouer "fine" et la récupérer en début de programme (ce qui est donc du code spécifique), et t'adapter en conséquence, ou prendre des valeurs courante acceptables. Mais il serait étonnant qu'un compilateur / interpréteur tienne compte de ceci (sauf compilateurs de fondeurs, bien entendu), quelle que soit la "hauteur" de niveau du langage.

On en revient au point de base : ça n'a pas (trop) d'importance sur un programme one-shot qui servira une ou deux fois seulement. C'est crucial sur quelque chose destiné à être utilisé des milliers d'heures, y compris avec un langage de haut niveau.

Franchement RAB, combien de fois j'alloue un tableau de 100 000*100 000 complexes ? (oui en france, c'est des espace pas des ' et savoir écrire les nombres, c'est au moins aussi important que le cache CPU). Early optimisation is the root of evil. Commencer par se poser cette question, c'est donc pour moi l'assurance de pondre du code de merde.

Allouer un tableau énorme est pourtant fréquent... Ne serait-ce qu'en imagerie/vidéo, en traitement du signal, en BDD, et j'en passe.

Puis vachement utile pour traiter un signal sur un DSP, programmer un protocole réseau, faire une interface graphique ou un pilote de périphérique.

Ben... oui.
DSP ? Flux de données importants et/ou gros buffers, ou signal à maintenir en mémoire (donc volumineux en général). De plus, traiter un signal le plus rapidement possible impose de savoir sur quoi on travaille (ex : utilisation SSE).
Protocole réseau ? Gros buffers, réactivité importante, nécessité de connaître l'organisation mémoire.
Interface graphique ? Nombreuses images et dessins, la réactivité impose là aussi de savoir sur quoi on travaille.
Pilote de périphérique ? Accès à des mappings de mémoire plus ou moins gros, gestion des buffers, totalement dépendant de la machine et de son architecture.

Sans compter que l'appellation ligne colonnes est largement arbitraire, et va montrer très vite ses limites quand on fait un tableau de tableau de tableau.

D'où l'intérêt de savoir comment est implémenté ce tableau, afin de pouvoir l'initialiser de façon optimale sans être obligé de faire une double / triple / etc. boucle d'affectation.

Enfin, on peut considérer que c'est le cache qui doit s'adapter aux diverses manières de coder et non l'inverse et/ou au compilo de gérer de telles optimisations.

C'est ça : c'est au matos de s'adapter au soft ??? Faudrait envisager d'apprendre les réalités économiques (voire physiques / électroniques), tu sais... Que l'on demande au hard de savoir faire un DMA, ou d'avoir un bus 32 bits, OK. De là à changer l'architecture ou le CPU à la demande, il y a une nette différence.
Quant au compilateur, il s'adapte dans une certaine mesure. Mais si tu vas trop à l'encontre de l'architecture de la machine, ce n'est plus son problème, mais le tien.

C'est à force de dire "changez de matos si notre programme est trop lent" que l'on obtient des devs qui ne savent plus programmer correctement... On n'a pas toujours la possibilité matérielle (ou financière) de changer la plate-forme matérielle, c'est au développeur logiciel de savoir faire son travail correctement.

[deadalnix]

Allouer un tableau énorme est pourtant fréquent... Ne serait-ce qu'en imagerie/vidéo, en traitement du signal, en BDD, et j'en passe.

Que des truc pour débutants en somme. Je sais aps toi, mais mon premier programme n'était pas un SGBD perso. D'ailleurs, je n'ai jamais codé de SGBD.

Ben... oui.
DSP ? Flux de données importants et/ou gros buffers, ou signal à maintenir en mémoire (donc volumineux en général). De plus, traiter un signal le plus rapidement possible impose de savoir sur quoi on travaille (ex : utilisation SSE).

Rha le spécialiste en carton pate xD . Bon, déjà ça n'a rien a voir avec ce qu'un débutant pourrait pondre, mais en plus, au contraire, on travaille ne ressources limités dans ce domaine. C'est pour ça qu'on a inventé les filtres à réponse impulsionelle infinie par exemple.

Protocole réseau ? Gros buffers, réactivité importante, nécessité de connaître l'organisation mémoire.

Non mais bis ! Des gros buffers dans les codes réseaux ??

Interface graphique ? Nombreuses images et dessins, la réactivité impose là aussi de savoir sur quoi on travaille.

Ça n'a jamais importé ici non plus. En tout cas pas tant que l'utilisateur est en dessous de quelque milliers d'actions par minutes . . .

Combien d'utilisateur vont se plaindre car leur fenêtre apparait 1ms plus tard ?

Et si c'est bien plus lent que ça, c'est pas une allocation de tableau qui va changer le problème.

Pilote de périphérique ? Accès à des mappings de mémoire plus ou moins gros, gestion des buffers, totalement dépendant de la machine et de son architecture.

Oui, mais bon les buffers de taillé démesurés ici aussi . . .

D'où l'intérêt de savoir comment est implémenté ce tableau, afin de pouvoir l'initialiser de façon optimale sans être obligé de faire une double / triple / etc. boucle d'affectation.

Early optimisation is the root of evil.

Puis genre les débutant ils connaissent pas la syntaxe, mais on va leur apprendre l'optimisation.

C'est à force de dire "changez de matos si notre programme est trop lent" que l'on obtient des devs qui ne savent plus programmer correctement... On n'a pas toujours la possibilité matérielle (ou financière) de changer la plate-forme matérielle, c'est au développeur logiciel de savoir faire son travail correctement.

Oui je te rejoint sur la fin, les programmeurs ne savent plus comment marche la machine et font du code de plus en plus merdique. C'est un fait.


On considère en général que 90% du temps se passe dans 10% du code. Ça veux dire que 90% du code peut être écris par quelqu'un qui n'a foutrement aucune connaissance de ces problèmes sans impacter significativement les performances.

[Mac LAK]

Rha le spécialiste en carton pate xD . Bon, déjà ça n'a rien a voir avec ce qu'un débutant pourrait pondre, mais en plus, au contraire, on travaille ne ressources limités dans ce domaine. C'est pour ça qu'on a inventé les filtres à réponse impulsionelle infinie par exemple.

Je te rappelle qu'on parle quand même de logiciel, initialement... Alimenter un DSP (vraiment au hasard, celui de la carte audio, vidéo ou celle du tuner télé dans ta tour), ça demande de gros volumes de données afin d'éviter les underruns liés au scheduling de l'OS...
Et ça, n'importe qui ou presque peut le faire, et donc, c'est souvent fait de façon un peu "barbare". Ils utilisent un DSP, il ne font pas le microcode à l'intérieur, c'est très différent.

Non mais bis ! Des gros buffers dans les codes réseaux ??

T'as déjà tenté de sniffer un réseau gigabit bien chargé ? Non ? Alors tu ne sais pas de quoi tu parles. Continue à faire trois ping en croyant que c'est du réseau...

Combien d'utilisateur vont se plaindre car leur fenêtre apparait 1ms plus tard ?

Moi, pour commencer, et la plupart des gens ayant plus de réflexes qu'un poulpe cuit. Quand je vois certains programmes QT ou KDE se dessiner bloc par bloc, perso, j'ai peur de voir le code derrière...

Et si c'est bien plus lent que ça, c'est pas une allocation de tableau qui va changer le problème.

En fait, si : pré-allouer les données et les afficher sans tout recalculer, ça fait gagner énormément de temps et de fluidité. Poussée à l'extrême (et au bas niveau), ça s'appelle du triple buffering par exemple.

Oui, mais bon les buffers de taillé démesurés ici aussi . . .

Cas d'école : composant Ethernet gigabit.
Taille du buffer hardware : 2 Mo, soit 1/64ème de seconde sur un réseau à pleine charge (1/32ème de seconde sur un réseau chargé décemment, c'est à dire à 50%).
Va tenir la charge avec sans implémenter de gros buffers, tiens... T'as la même chose avec la plupart des drivers, d'ailleurs, le hard suffit juste à tenir la réactivité (c'est moins cher), c'est le soft qui prends le relais derrière.

Early optimisation is the root of evil.

Lately optimisation is the root of stupidity. Surtout quand c'est tellement à la base du projet qu'optimiser à la fin du projet revient à tout casser et tout refaire.
D'abord choisir la bonne méthode. C'est l'optimisation FINE que l'on fait en fin de projet, l'optimisation "au départ", ça s'appelle de la conception.

Il n'est pas nécessaire d'aller jusqu'au hack sauvage pour ça : pour l'exemple du C, c'est leur apprendre à utiliser "memset" au lieu d'une boucle bourine, tout simplement.

On considère en général que 90% du temps se passe dans 10% du code.

On parle plutôt de 80/20 en général, et c'est quand même sujet à caution... Surtout quand le code "peu exécuté" conditionne fortement les performances du code "souvent exécuté", ne serait-ce que par la préparation des données et l'architecture générale du code "critique" au sein du projet.

Conception, donc...

Ça veux dire que 90% du code peut être écris par quelqu'un qui n'a foutrement aucune connaissance de ces problèmes sans impacter significativement les performances.

Faux. Fournir des données dans un format crétin au code critique, ça impacte les performances. Et ça, quelqu'un qui n'a aucune connaissance de ces problèmes ne peut pas savoir comment organiser correctement les données...

[jabbounet]

Envoyé par deadalnix Voir le message
Ça veux dire que 90% du code peut être écris par quelqu'un qui n'a foutrement aucune connaissance de ces problèmes sans impacter significativement les performances.

Je confirme ce que dit MAK LAK sur le sujet
A une époque j'ai travaillé sur un EAI c'etait un language de super haut niveau (on faisait un modèle UML de l'appli, on codait les méthodes/ états des state machines dans un pseudo langage C++ like). et derrière ça te générais toutes ton appli sans que tu ai d'autres question a te poser.

Bref tu faisais de jolis dessins pour avoir une appli derrière.

Et bien malgré ce niveau d'abstraction tres élevé du langage, si tu n'avais pas un minimum la notion de ce qui se passais derrière (en gros comment le moteur gérais ses thread et ses locks qui étaient totalement masqué par le langage) et bien tu te retrouvais vite a avoir des problèmes de perf.

tout ça pour dire que même sur ce langage soit disant de haut niveau, savoir comment marchait la machine/ l'OS permettait de faire la différence entre une appli qui tournais du feu de dieu et un tas de #####.

[deadalnix]

je réagis vis a vis du parcours en ligne ou en colonne pour l'allocation d'un tableau.

Ce que tu me cite pour le réseau (sniffer) non, ce n'est pas programme run protocole réseau que de sniffer un réseau. Et la plupart du temps quand tu code un protocole réseau, tu traites ou tu drop, mais tu stocke pas (ou alors tu passe par TCP qui le fait pour toi et tu taffes au dessus).

Pour ce qui est de l'interface graphique, tu m'évoque des soucis de conceptions, et sur ce point je te rejoint. Il y a pas mal de soft qui ont la réactivité d'un cheval mort. mais c'est jamais du au fait que tu as initialisé un tableau en ligne ou en colonnes.

Pour ce qui est de la conception/optimisation, pour moi la différence est claire. Et initialiser un tableau en ligne ou en colonne, ça fait partie de la seconde catégorie. La première étant de réfléchir a comment éviter de faire des initialisation à outrance.

Pour les formats de données, oui, c'est de la conception. Tu n'auras qu'a dire à Mr Jecodecommeungoret dans quel format tu veux tes données, et il pourra te pondre les 80% de code qui vont bien. Pour les 20% il est clair que c'est les plus intéressants.

[chaplin]

Bonjour à tous!
Ce soir, je vous propose une petite question pour tester vos connaissances sur les langages que vous adorez ou que vous détestez:

On veut remplir avec la valeur 0.0+j*0.0 toutes les cases d'un tableau 10'000*10'000, déclaré en complexe sur 16 octets. Vaut-il mieux le parcourir ligne par ligne ou colonne par colonne?

A mon avis, il est indispensable qu'un programmeur connaisse la réponse valable pour le langage qu'il utilise, et ça fait partie des connaissances de base. Alors, qu'en est-il pour le langage préféré de chacun d'entre vous?

Jean-Marc Blanc

PS. En ce qui concerne le Fortran, c'est colonne par colonne.

Quelqu'un m'a mis au dépourvu sur une question à laquelle j'ai répondu sur le coup de la pulsion à propos de calcul matriciel. Et ben, je suis aller dans l'EDI qui permet de faire de l'ASM et puis j'ai épluché de la doc sur le site d'Intel (par curiosité). Comme je fais pas confiance aux boîtes noir, je répondrais ASM. D'autres s'amusent avec les GPU. Après c'est toujours une question de machine ... de moyens.

Moralité, j'ai pas fait grand chose, mais je comprends le discours de Mac Lag et l'intervention de FR119492.

[Mac LAK]

Mais je crois que je sais ou on est pas d'accord : je réagis vis a vis du parcours en ligne ou en colonne pour l'allocation d'un tableau.

C'est juste la partie émergée de l'iceberg, ça... Ou le glaçon posé dessus.
Ce n'était qu'un exemple, montrant toutefois de façon significative que la méconnaissance du langage et/ou de la plate-forme peut impacter significativement un programme qui semble pourtant "parfait"...

Ce que tu me cite pour le réseau (sniffer) non, ce n'est pas programme run protocole réseau que de sniffer un réseau. Et la plupars du temps quand tu code un protocole réseau, tu traites ou tu drop, mais tu stocke pas (ou alors tu passe par TCP qui le fait pour toi et tu taffes au dessus).

Je parlais de snif réseau pour savoir si tu avais bien conscience du volume de données que représente un tel réseau, une fois "chargé"... Ton protocole, quel qu'il soit, transfère les données à cette vitesse, c'est à dire jusqu'à cent mégaoctets par seconde en pic.

Va bouffer ça sans de gros buffers, tiens...

Il y a pas mal de soft qui ont la réactivité d'un cheval mort. mais c'est jamais du au fait que tu as initialisé un tableau en ligne ou en colonnes.

Un plus un plus un plus un plus un plus un ....
A la fin, ça fait beaucoup. Surtout quand au milieu du lot tu as plusieurs gros "plus cent" !!!

Pour ce qui est de la conception/optimisation, pour moi la différence est claire. Et initialiser un tableau en ligne ou en colonne, ça fait partie de la seconde catégorie. La première étant de réfléchir a comment éviter de faire des initialisation à outrance.

Perdu !!!
La conception, à ce niveau, c'est organiser les données dans le bon ordre. Si t'es sur un programme de dessin raster, par exemple, tu vas calquer tes structures internes sur le format requis par le sous-système graphique de l'OS... Qui, en général, est en lignes.
Si ton langage, par exemple, est plus à l'aise sur les colonnes, ça veut dire que tu vas plomber tes perfs (et pas qu'un peu...) si tu n'inverses pas les coordonnées X et Y dans ton travail, c'est à dire effectuer (logiquement) une symétrie par rapport à la première bissectrice. Si ce n'est pas pensé dès le départ, ça coûtera une fortune ensuite de le modifier.
L'optimisation "fine", c'est par exemple remplacer la boucle "for" par un memset quand la valeur de copie est constante, ou introduire des points de rupture d'exécution, etc.

Bref, l'optimisation "fine" (la seule acceptable en fin de projet), ce sont des choses qui ne modifient pas les pré/postconditions des fonctions, mais qui peuvent éventuellement en modifier l'invariant.
Si tu modifies les interfaces de tes fonctions en phase d'optimisation, c'est que tu fais en fait de la rétroconception pour pallier un manque de conception initiale.

Tu n'auras qu'a dire à Mr Jecodecommeungoret dans quel format tu veux tes données, et il pourra te pondre les 80% de code qui vont bien.

Heu... Je ne veux pas paraître moqueur, mais tu as déjà vu un "vrai" CdC / specs d'un client, un "qui paie" ? Et surtout, le prix auquel c'est habituellement vendu ?
Quand on dit à quelqu'un censé être ingénieur "Tu me fais un module d'acquisition de tel protocole", c'est à peu près la seule chose qu'il a comme informations... Parce qu'il est censé faire la sous-spec, et la sous-conception au passage, de ses propres modules !
Ce que tu dis, c'est valable quand on s'adresse à un AP, à qui on a déjà prémâché le boulot. Or, les "débutants" dont on parle sur ce topic, ce sont hélas souvent des gens avec un bôôôôô diplôme d'école d'ingé. Et quand on voit ce que certains osent faire, on se dit que Kinder Surprise devrait être une école d'ingés.

[alex_pi]

Perdu !!!
La conception, à ce niveau, c'est organiser les données dans le bon ordre. Si t'es sur un programme de dessin raster, par exemple, tu vas calquer tes structures internes sur le format requis par le sous-système graphique de l'OS... Qui, en général, est en lignes.
Si ton langage, par exemple, est plus à l'aise sur les colonnes, ça veut dire que tu vas plomber tes perfs (et pas qu'un peu...) si tu n'inverses pas les coordonnées X et Y dans ton travail, c'est à dire effectuer (logiquement) une symétrie par rapport à la première bissectrice. Si ce n'est pas pensé dès le départ, ça coûtera une fortune ensuite de le modifier.

Ou alors, tu avait défini un type image, et une fonction d'accès à la paire de coordonnée (x, y), et le jour où tu vois qu'il faut le faire dans l'autre sens, tu as inversé la représentation concrète de ton type image, et aucun autre point du programme ne s'en ai rendu compte ?
Ah non merde, ça ce sont les mecs qui ne savent pas penser "optimisé" qui font ça, pas les Véritables. Désolé :-\

[chaplin]

Pour l'utilisation dans delphi des tableaux dynamiques, je viens de découvrir cet article:

Okay let me clear this up. Dynamic arrays are coding horrors (I hate seeing 'em worse than I do gotos now), and we're seeing why in this thread. Why is it a coding horror? Because there is a lot happening behind the scenes that no one knows or thinks about on the face of it - in fact it totally goes against the intent and spirit of Pascal (which was a teaching language intended to expose everything).

Let's look at what it's doing. Basically what's being asked by the OP is to create a dynamic array of dynamic arrays.

Behind the scenes, though, what is happening? The system is allocating memory using pointers. Now, those sections of memory can be where ever the system is able to find free memory. So how do they get addressed? By finding the pointer and pointing to its contents.

Now let's take that back to what is being attempted here. We have a dynamic array of dynamic arrays, which means ultimately that you have Header.Width * Header.Height pointers in the system to various spots in memory, NOT a contiguous block of memory to work from. You also have a very inefficient structure, both in terms of memory (Header.Width * Header.Height pointers at 4 bytes per shot plus Header.Width * Header.Height TTerrainCells.), plus the additional processing of having to follow each and every pointer out to the data value.

Heureusement qu'il y a d'autres techniques, c'est toujours instructif.

[ZoinX]

Ou alors, tu avait défini un type image, et une fonction d'accès à la paire de coordonnée (x, y), et le jour où tu vois qu'il faut le faire dans l'autre sens, tu as inversé la représentation concrète de ton type image, et aucun autre point du programme ne s'en ai rendu compte ?
Ah non merde, ça ce sont les mecs qui ne savent pas penser "optimisé" qui font ça, pas les Véritables. Désolé :-\

Voyons enfin, est-ce que tu te rends du coût monstrueux de ton appel de fonction ??????????

N'importe quel vrai informaticien te le dira, pour avoir un programme bien optimisé, il est important dès l'étape de conception de s'assurer que tout le code sera dans le main(), les appels de fonction sont beaucoup trop coûteux (surtout sur proc PowerPC, les Intel ça va encore par contre)

(humour, désolé, pas taper )

[chaplin]

En écoutant un informaticien, j'ai appris à ne pas toujours fait confiance à la machine et je l'ai constaté en pratique, c'est choquant au début, on devient méfiant après coup.

EDIT: Au fait, pourquoi faut-il défragmenter les disques durs ?

[Mac LAK]

Ou alors, tu avait défini un type image, et une fonction d'accès à la paire de coordonnée (x, y), et le jour où tu vois qu'il faut le faire dans l'autre sens, tu as inversé la représentation concrète de ton type image, et aucun autre point du programme ne s'en ai rendu compte ?

Une couche d'abstraction supplémentaire ? Cool !
Soit elle est compilée, et c'est coûteux en temps vu que c'est utilisé à chaque accès à un pixel (une convolution là-dessus et tu vas pleurer...).
Soit elle est sous forme de "template", et ça recompile 90% de ton code à chaque modif.
Dans les deux cas, c'est une usine à gaz... Ce qui

Ah non merde, ça ce sont les mecs qui ne savent pas penser "optimisé" qui font ça, pas les Véritables. Désolé :-\

Des types "image" comme celui-ci, il en existe plein. Leur principale caractéristique, c'est que ce ne sont habituellement que des containers pour les structures natives du système graphique... Donc, pas spécialement portable. Les fonctions portables de telles entités sont en général horriblement lentes, par exemple quand après chargement d'un bitmap on modifie quelques pixels dessus au lieu d'appliquer les "bonnes" méthodes, comme une fusion de bitmaps ou l'affichage type calque.

N'importe quel vrai informaticien te le dira, pour avoir un programme bien optimisé, il est important dès l'étape de conception de s'assurer que tout le code sera dans le main(), les appels de fonction sont beaucoup trop coûteux (surtout sur proc PowerPC, les Intel ça va encore par contre)

Le développement, c'est toujours un compromis entre performance et temps de développement (inclus temps de maintenance / évolution pour ce dernier).

Certes, tout faire dans le main() est plus rapide. Toutefois, la maintenabilité n'est alors pas au rendez-vous, et la réutilisabilité encore moins. Il m'est déjà arrivé, toutefois, de voir des bouts de code particulièrement critiques être écrits exclusivement avec des macros, mais définies dans un beau module séparé bien propre.

D'où le découpage d'un projet en modules, classes, voire programmes, librairies, etc. et leur utilisation, quand tout va bien, dans plusieurs projets. Toutefois, cela n'a jamais voulu dire qu'il fallait mettre une couche d'abstraction à chaque étage, ni rendre tout générique. Une "bonne" couche d'abstraction, c'est destiné au portage et/ou au masquage d'implémentation, c'est à dire que c'est à un endroit bien particulier du code : au niveau de l'OS, des interfaces des librairies, de la gestion des protocoles de communication, etc.
Sûrement pas en plein milieu du projet sur un truc totalement interne...

Plus je te lis, ZoinX, plus j'ai l'impression d'écouter un étudiant farci de théories bien scolaires qui n'a jamais appliqué concrètement ses connaissances en milieu professionnel...

En écoutant un informaticien, j'ai appris à ne pas toujours fait confiance à la machine et je l'ai constaté en pratique, c'est choquant au début, on devient méfiant après coup.

Bof... On s'y fait, plus l'informatique devient complexe, et plus ça vire au chamanisme parfois. Il y a des projets qui "tombent en marche", et tout le monde semble trouver ça normal. Pas pour moi en tout cas, c'est sûrement pour ça aussi que je trouve toujours mes bugs, que mon code est toujours testable, modulaire, et réutilisable.

EDIT: Au fait, pourquoi faut-il défragmenter les disques durs ?

Pour gagner du temps... Défragmenter lors de la création d'un fichier coûte trop de temps, et c'était encore pire à l'époque du DOS. Maintenant, Windows le fait en tâche de fond, mais ça reste une simple raison de performances lors de l'accès aux fichiers.

[alex_pi]

Une couche d'abstraction supplémentaire ? Cool !
Soit elle est compilée, et c'est coûteux en temps vu que c'est utilisé à chaque accès à un pixel (une convolution là-dessus et tu vas pleurer...).

En quoi avoir

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
int acces_image(image i, int l, int c){
  return i[l][c]
}

est-il couteux ??

[Mac LAK]

En quoi avoir

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
int acces_image(image i, int l, int c){
  return i[l][c]
}

est-il couteux ??

Trois pushs pour les paramètres, un appel de fonction (et donc un pipeline d'exécution HS si la prédiction de branchement a fait un miss lors de l'appel, plus un lors du retour), encore un push pour le résultat, un nettoyage de pile et un pop.

Fait ça pour chaque pixel d'une image normale (1280x1024), t'as déjà la perte multipliée par 1.300.000 environ. Si c'est sur une convolution 3x3, c'est encore multiplié par dix (neuf lectures plus une écriture), on flirte avec les 12 millions d'appels... Pour une seule image !! Soit, en gros, 0.15 secondes de délai en comptant (gentiment) que ton appel ne coûte "que" 40 cycles CPU sur un processeur à 3 GHz.

Si tu dois faire UN traitement d'image, c'est ridicule et négligeable... Et dans ce cas, ton code adaptatif est totalement inutile au passage.
Si tu dois en faire des milliers (voire des milliers par seconde), c'est prohibitif, et dans ce cas, ton code adaptatif est nuisible.

Coûteux, c'est évident. Mais en plus, c'est nuisible ou inutile, à toi de choisir !

[alex_pi]

Trois pushs pour les paramètres, un appel de fonction (et donc un pipeline d'exécution HS si la prédiction de branchement a fait un miss lors de l'appel, plus un lors du retour), encore un push pour le résultat, un nettoyage de pile et un pop.

Ah oui j'oubliais, le Véritable connait tellement bien sa machine et son langage qu'il n'a pas besoin d'utiliser un compilo capable de faire de l'inlining.

Pour quelqu'un qui explique qu'il faut impérativement apprendre à programmer en gérant sa mémoire à la main, sinon "on ne comprend pas ce qu'il se passe et on prend des mauvaises habitudes", ne pas comprendre la notion élémentaire d'inlining de fonctions est quand même assez inquiétant.

C'est bien ça le problème des programmeurs dans ton genre, qui veulent à tout pris "comprendre ce qu'il se passe", et moralité regardent le code par le petit bout de la lorgnette. A vouloir faire des "optimisation" à la noix, tu te prives d'un code modulaire, où le fait de vouloir passer d'une représentation en ligne à une représentation en colonnes à un coup nul (il suffit dans la fonction donnée plus haut de permuter l et c). A croire que tu comprends les détails, tu oublies la vision d'ensemble, tu oublies qu'un code est amené à évoluer, et que parfois, les gens ne sont pas des génies absolus et n'ont pas vu tous les problèmes potentiels en phase de conception, et qu'il faudra changer le code et débugger.

Je persiste donc, apprendre a programmer avec un langage qui incite à mettre rapidement les mains dans le cambouis avant de prendre des bonnes habitudes algoritmiques, des habitudes de modularité, et surtout de maintenabilité et d'évolutivité du code mène à ce genre de choses. C'est donc un choix absurde et sans intérêt.

[jabbounet]

en tout cas prendre un language ou il y'a de l'arithmétique signée et non signé, parce que j'en ai marre de l'expliquer aux développeurs java

si on te l'a expliqué un jour ce ne ser pas génant pour faire du java en suite.
si on ne te l'a jamais expliqué ce sera plus génant pour ne pas faire de java ensuite

[Mac LAK]

Ah oui j'oubliais, le Véritable connait tellement bien sa machine et son langage qu'il n'a pas besoin d'utiliser un compilo capable de faire de l'inlining.

Inlining que tu n'as pas précisé, comme l'a souligné gorgonite... Ben oui, hein, l'inlining "automatique", c'est justement indéfini : tu ne sais pas à priori si ta fonction sera inlinée ou pas... Et comme tu n'as pas jugé bon de le préciser dans ta fonction, elle coûte cher.

Quant à inliner : certes, côté performances, ce sera moins coûteux : un ou deux cycles perdus en général, guère plus. Toutefois, cela rend l'exécutable un peu plus lourd aussi, peut poser de sévères problèmes de debug, et cela a le même effet qu'un template/macro tout en étant moins efficace : ça oblige à recompiler tout le code en cas de modification.

De façon générale, du code portable restant efficace est rarement obtenu en modifiant une fonction : c'est plutôt que l'on fait des interfaces communes, et que l'on casse tout le bouzin à l'intérieur pour le faire coller à l'interface de la librairie d'une part, et de l'OS d'autre part. Tripaille interne, proche de la machine et du système d'exploitation, tu peux pas comprendre...

Pour quelqu'un qui explique qu'il faut impérativement apprendre à programmer en gérant sa mémoire à la main, sinon "on ne comprend pas ce qu'il se passe et on prend des mauvaises habitudes", ne pas comprendre la notion élémentaire d'inlining de fonctions est quand même assez inquiétant.

Oh, je la comprends très bien, ne t'inquiètes pas. Le plus inquiétant, c'est plutôt toi qui croit que le compilo va inliner forcément tout ce qui va bien, et rien que ce que va bien si on le laisse faire tout seul sa sauce. Et comme tu n'as pas précisé "inline" dans ta fonction, elle ne sera à priori jamais transformée ainsi sauf à inliner au maximum.
Et dans ce cas, tu vas te retrouver avec un exécutable de 40 mégas pour faire un afficheur de JPEG ?

C'est bien ça le problème des programmeurs dans ton genre, qui veulent à tout pris "comprendre ce qu'il se passe", et moralité regardent le code par le petit bout de la lorgnette. A vouloir faire des "optimisation" à la noix, tu te prives d'un code modulaire, où le fait de vouloir passer d'une représentation en ligne à une représentation en colonnes à un coup nul (il suffit dans la fonction donnée plus haut de permuter l et c). A croire que tu comprends les détails, tu oublies la vision d'ensemble, tu oublies qu'un code est amené à évoluer, et que parfois, les gens ne sont pas des génies absolus et n'ont pas vu tous les problèmes potentiels en phase de conception, et qu'il faudra changer le code et débugger.

D'une part, une telle abstraction est inutile de façon générale : c'est nécessaire en faisant une librairie multi-langage, respectant (peu ou prou) les mêmes interfaces d'un langage à l'autre, c'est à dire approximativement les mêmes appels de fonctions dans le même ordre.

D'autre part, si jamais elle s'avérait strictement nécessaire (un cas plus courant est la gestion de l'endianness), il est alors crucial de "planquer" ce code au fond de la librairie de façon à limiter la recompilation en cas de changement... De plus, ce serait alors à faire avec des macros / templates plutôt que de l'inlining, qui est réservé aux fonctions un peu plus lourdes et demandant, notamment, des variables locales.

Quant à voir le maximum possible en phase de conception, c'est justement à ça qu'on voit la différence entre un théoricien de la programmation (qui pond des usines à gaz inmaintenables) et un bidouilleur (qui refond le code tous les trois jours)... Et l'avantage d'être "au milieu" justement : on prends les bons côtés des deux mondes, en connaissant aussi les inconvénients et contraintes des deux mondes en question.

Je persiste donc, apprendre a programmer avec un langage qui incite à mettre rapidement les mains dans le cambouis avant de prendre des bonnes habitudes algoritmiques, des habitudes de modularité, et surtout de maintenabilité et d'évolutivité du code mène à ce genre de choses. C'est donc un choix absurde et sans intérêt.

Et pourtant... Commencer de manière médiane permet, au contraire, d'avoir à la fois la modularité et la performance, c'est ça que tu n'arrives pas à intégrer.

connais-tu itk ? qu'en penses-tu ?

Non, connais pas. Je n'ai pas le temps matériel d'explorer toutes les librairies possibles et imaginables, hélas.

[gorgonite]

Non, connais pas. Je n'ai pas le temps matériel d'explorer toutes les librairies possibles et imaginables, hélas.

c'est du C++, et elle m'a l'air d'être la plus au point...


au passage, si tu dois traiter beaucoup d'images, mais malheureusement avec des algos attendant différents types de représentations (RGB,TSL, etc), comment t'y prendrais-tu sans abstraire tout cela et/ou éviter d'avoir à faire une conversion très coûteuse avant chaque opération sur un pixel ?

surtout que pas mal de développeurs se plantent sur la précision d'une conversion RGB -> TSL et finissent par obtenir une image noire avec des algos corrects... s'ils avaient manipulé des réels au sens mathématiques (perso, il a fallu que je fournisse ce morceau sinon mes élèves n'auraient pas réussi à mettre en place leur travail)