Ubuntu-fr

The Uploader · Le 08/11/2011, à 01:04

L_d_v_c@ a écrit :

The Uploader a écrit :
En pratique, tout faire en assembleur n'est pas réaliste.
Amiga l'a prouvé en effet : 90% en assembleur - 9% en C et 1% en shell script.

Certes, mais ce n'était qu'un petit OS (point de vue taille) des années 80 sur une machine de la même époque, rien à voir avec ce que tout doit gérer un OS d'aujourd'hui. D'autant qu'en assembleur on s'attache à une plateforme processeur, ce qui n'est pas vraiment un avantage : pas de multiplateforme, pas de possibilité de changer les CPU/SPU/GPU (par exemple passage du x86 au PPC) de la machine sous peine d'avoir à tout recoder..

Quant à la maîtrise du code, pour ça il y a par exemple le TDD : https://fr.wikipedia.org/wiki/Test_Driven_Development, les tests fonctionnels, etc...

Dernière modification par The Uploader (Le 08/11/2011, à 01:10)

L_d_v_c@ · Le 08/11/2011, à 01:16

Un i7 : typiquement 6 cœurs à 3,4 GHz consommant 130W ... ça fait 6,37 W / cœur / GHz
TYLE-Gx 100 : 100 cœurs à 1,5 GHz consommant 55W max ... ça fait 0,366 W / cœur / GHz soit 17,4 fois moins en approximation car il faut regarder la puissance de calcul. On a vu que tous les processeurs n'ont pas le même rendement MIPS/GHz ou FLOPS/GHz.

Dit autrement : pour la puissance d'un i7 (130W), tu remplaces par deux TILE-Gx 100 et tu obtiens le double de :

100 general purpose processor cores (tiles)
64-bit VLIW processors with 64-bit instruction bundle
Three-deep pipeline with up to 3 instructions per cycle
Massive 32 Mbytes of on-chip cache in the TILE-Gx100
Up to 750 billion 32-bit operations per second (BOPS)
Up to 200 Tbps of on-chip mesh interconnect
Over 500 Gbps memory bandwidth with two or four 64-bit DDR3 controllers
Scalable cache: The cores include 32KB L1i, 32KB L1d,
and 256KB L2 cache. With its peer-to-peer coherency,
the powerful DDC system scales easily to the 100-core
level and beyond.

The Uploader · Le 08/11/2011, à 01:22

Euh, c'est quoi le rapport avec la taille d'un OS d'aujourd'hui, la maîtrise du code, et les désavantages de l'assembleur ? ^^

L_d_v_c@ · Le 08/11/2011, à 01:27

The Uploader <- très bien ta TDD : on dirait la programmation modulaire ou on teste chaque brique une à une.

The Uploader a écrit :

Euh, c'est quoi le rapport avec la taille d'un OS d'aujourd'hui, la maîtrise du code, et les désavantages de l'assembleur ? ^^

Désolé, je n'ai pas compris la question.

The Uploader · Le 08/11/2011, à 01:32

L_d_v_c@ a écrit :

The Uploader <- très bien ta TDD : on dirait la programmation modulaire ou on teste chaque brique une à une.

'xactement. Avec le TDD, SOLID en POO, le versionning, etc... : pas besoin d'assembleur pour maîtriser le code.

L_d_v_c@ a écrit :

The Uploader a écrit :
Euh, c'est quoi le rapport avec la taille d'un OS d'aujourd'hui, la maîtrise du code, et les désavantages de l'assembleur ? ^^
Désolé, je n'ai pas compris la question.

J'voulais dire, le rapport entre ce que j'ai évoqué (TDD, tout ça), et la puissance des processeurs dont tu parle ensuite. ^^'

Dernière modification par The Uploader (Le 08/11/2011, à 01:33)

L_d_v_c@ · Le 08/11/2011, à 11:10

The Uploader a écrit :

'xactement. Avec le TDD, SOLID en POO, le versionning, etc... : pas besoin d'assembleur pour maîtriser le code.

Vivement que les programmeurs s'y mettent. Un monde sans bug, sans faille de sécurité... ça me plaît.
Enfin vue la taille des codes je me demande si ceux-ci sont bien maîtrisés.

Dernière modification par L_d_v_c@ (Le 08/11/2011, à 15:02)

Zugol · Le 08/11/2011, à 12:53

L_d_v_c@ a écrit :

Vivement que les programmeurs s'y mettent. Un monde sans bug, sans faille de sécurité... ça me plaît.
Enfin vu la taille des codes je me demande si ceux-ci sont bien maîtrisés.

Je suis développeur en SSII et crois moi le problème ne vient pas que de nous. Chaque jour on est forcé de baisser les bras car le management et les business s'en mêlent plus qu'ils ne devraient...

Il existe des méthodes de pilotage de projet, de conception, de test, de déploiement, de maintenance, de versionning, de collaboration, des frameworks d'une incroyable puissance et pourtant très simples d'utilisation, des concepts et des infrastructures qui répondent presque à tous les besoins, bref tout un tas de chose pensées avec autant d'intelligence et de bonne volonté que ce que tu évoques.

Malheureusement pour nous autres, dans 99% aucun des éléments pré-cités n'est employé et on nous fait tout réaliser à l'économie à cours terme.

S'ajoute à ça que l'informatique est une spécialité très mal considérée dans la plupart des entreprises Françaises ou l'on nous prend pour des enfants. On ne nous écoute pas, les décideurs font de très mauvais choix et ne se remettent jamais en question, on cherche des solutions "pas-chères" qui coûtent une fortune à moyen terme et on nous remplace par des gens incompétents pour économiser encore et encore. Et je ne te parles pas des demandeurs/payeurs qui ne font pas l'effort de formaliser leur besoins et qui influent sur les aspects techniques des projets plus que l'équipe de développement elle même.

Donc oui, vivement qu'on s'y mette, mais c'est pas demain la veille en entreprise (dans la plupart en tous cas) et c'est pour ça qu'il y a autant de projets open-sources et personnels. Pour le plaisir de faire de son mieux son travail de développeur avec passion et sans l'influence du commerce ou de la RH...

Maintenant je peux te l'affirmer, il est impossible de maîtriser tout le code. Le 0 bug n'existe pas, même dans la meilleur des situation.

L_d_v_c@ · Le 08/11/2011, à 14:32

Zugol a écrit :

...
Maintenant je peux te l'affirmer, il est impossible de maîtriser tout le code. Le 0 bug n'existe pas, même dans la meilleur des situation.

Pourquoi ? avec toutes les techniques que tu cites ... c'est bien le but ? Arriver au code parfait ...
J'ai l'impression que pendant un temps il y avait plus de bugs hardware que de failles logicielles.
Y a-t-il cette notion de rentabilité, d'être pressé dans le monde Linux et GNU/Linux ?
Sommes-nous d'accords que les mises à jour servaient à apporter de nouvelles fonctionnalités, qu'un programme en version Beta disponible pour le public mentionnait bien à vos risques et périls. Et que celui qui ne choisissait pas n'avait que des programmes en version finale. Oui le cycle était un peu plus long.
Maintenant on a des Firefox qui consomment énormément, qui plante parfois, et qui subiront une mise à jour quand une faille de sécurité déjà présente sera découverte ou exploitée et qui osent porter un numéro de version > 1.0

Si les compilateurs C/C++ sont si géniaux, pourquoi un code pondu en assembleur semble être supérieur par son économie de place, sa rapidité ? (n'engageant que moi)

J'ai récupéré 4000 pages PDF de programmation pour mon processeur en assembleur, puis j'ai abandonné car je suis feignant ou que je ne retrouve pas les entrées/sorties de toutes les bibliothèques comme il y avait sur l'Amiga pour réutiliser le code. Puis 4000 pages.

Toi qui es programmeur Zugol, que penses-tu de l'utilisation mémoire en RAM et sur disques des programmes rencontrés actuellement dans ce monde GNU/Linux, mondeprincipalement non-commercial où les programmeurs ne devraient pas avoir de contrainte à fournir un logiciel avant une date donnée ?

Dernière modification par L_d_v_c@ (Le 08/11/2011, à 15:01)

Zugol · Le 08/11/2011, à 18:05

L_d_v_c@ a écrit :

Pourquoi ? avec toutes les techniques que tu cites ... c'est bien le but ? Arriver au code parfait ...

Parce que la "stack" logicielle est trop importante. Tu ne peux pas comparer des softs dédiés à une seule machine avec ce qui est développé aujourd'hui, avec toutes les notions de portabilités, d'échange, de standardisation. Même si la "stack" employée est parfois sur-dimensionnée par rapport au besoin, on ne peut pas se permettre de s'en passer. A titre d'exemple, tu installes une jre java même si tu ne fais tourner qu'une seule application (qui l'exploite à peine). De plus chaque composant logicielle est développé indépendamment des autres... Les bugs viennent aussi des combinaisons possibles...

Dans le cas d'une application intranet (vision très macro) on a :
langage machine > système d'exploitation > machine java > serveur d'application > serveur web > application > données > réseau...

Quand tu adoptes un framework, il contient lui même des bug encore inconnus, car le nombre de cas de test possibles et 3x supérieur à l'infinie (si, si, 3 fois).

L_d_v_c@ a écrit :

Y a-t-il cette notion de rentabilité, d'être pressé dans le monde Linux et GNU/Linux ?

Oui car le logiciel libre est pauvre en argent et doit avancer plus vite que des société qui pèsent des milliards pour maintenir la tête hors de l'eau. C'est David contre Ultimate-Turbo-Goliath. Le logiciel libre doit innover, séduire et convaincre car l'utilisateur final reste un monsieur-tout-le-monde qui changera de cap à la première brise. On ne peut repousser à l’infini, même la vénérable Debian Stable n'est pas infaillible !...

L_d_v_c@ a écrit :

Sommes-nous d'accords que les mises à jour servaient à apporter de nouvelles fonctionnalités, qu'un programme en version Beta disponible pour le public mentionnait bien à vos risques et périls. Et que celui qui ne choisissait pas n'avait que des programmes en version finale. Oui le cycle était un peu plus long.

...Infini, c'est en cela que le libre pêche. Que faire d'un "inkscape v0.48" ? Oui, l'application n'est pas exempte de bug. Donc personne ne peut se permettre de l'utiliser professionnellement ? Et bien dans ce cas, il n'y a pour ainsi dire aucun logiciel utilisable sous linux. Mais le bug qui hier bloquait toute une machine monotâche aujourd'hui s'intercepte et ce gère. Certes, on obtiens un insolent message d'erreur, mais la machine et sauve...

L_d_v_c@ a écrit :

Maintenant on a des Firefox qui consomment énormément, qui plante parfois, et qui subiront une mise à jour quand une faille de sécurité déjà présente sera découverte ou exploitée et qui osent porter un numéro de version > 1.0

Aujourd'hui un navigateur web est presque un OS tout entier ! Même si Mozilla doit faire mieux, on ne peut pas comparer l'utilisation de ressource d'il y a 20 ans avec ce qui se consomme aujourd'hui.

L_d_v_c@ a écrit :

Si les compilateurs C/C++ sont si géniaux, pourquoi un code pondu en assembleur semble être supérieur par son économie de place, sa rapidité ? (n'engageant que moi)

Troll plus vieux que le troll ! On ne fera jamais plus rapide que l'assembleur, mais si demain tu te met aux devs, tu ne peux pas développer tout "from scrtach "à chaque fois, tu va te développer des outils, des libriaires, des composants et les partager si tu les estimes efficaces... Les langages évolués ne sont pas nés d'une fantaisie mais d'un besoin. Aujourd'hui développer sans s'appuyer sur le paradigme objet relève du suicide. Il en va de même pour tout ce qui se fait. Et à chaque couche logicielle, chaque composant inutilisé, chaque mémoire mal allouée, chaque driver inutile, chaque bus de communication dormant, chaque machine virtuelle tu perds du temps CPU et de la RAM...

Admettons que demain on se remette tous à l'assembleur et bien il engendrera à nouveau le C qui engendrera à nouveau les C++ qui engendrera... C'est presque Darwinien ! Imagines le temps qu'il faudrait à une équipe pour développer le cry-engine from scratch en assembleur ! Imagine le manque de standardisation ! Imagine que tout serait à refaire pour chaque processeur.

L_d_v_c@ a écrit :

Toi qui es programmeur Zugol, que penses-tu de l'utilisation mémoire en RAM et sur disques des programmes rencontrés actuellement dans ce monde GNU/Linux, mondeprincipalement non-commercial où les programmeurs ne devraient pas avoir de contrainte à fournir un logiciel avant une date donnée ?

On ne peut pas généraliser, mais beaucoup de développeurs volontaires ne sont pas des ingénieurs formés au génie logiciel (et même ceux là, tous ne sont pas bons), parfois des gens astucieux qui produisent un code préformant mais in-maintenable par un tiers et non évolutif, parfois des néophytes qui développent avec un langage des librairies simples mais lourdes... Tu sais, "la performance" est une spécialisation du génie logiciel. Il existe peu d'ingénieurs qualifiés pour chaque langage, framework ou architecture et aucun pour chacune des combinaisons possibles...

Pour résumer, et soi assuré que je ne moque ni dénigre tes propos, si on pouvait faire ce que tu dis, on le ferait, on l'aurait toujours fait et il n'y aurait que le langage assembleur.

Puise je me permettre de te demander quel est ton niveau d’expérience en développement (en gros) ainsi que ton age ? N'y voit aucun mal c'est pour alimenter la discussion que je trouve passionnante et pour mieux me mettre à ta place. Personnellement j'ai 33 ans, je fais mumuse avec des ordis depuis l'age de 10 ans (atari ST), je bosse dans l'informatique depuis 12 ans et je n'ai jamais fais grand chose de bien de mes 10 doigts !

The Uploader · Le 08/11/2011, à 18:09

Zugol a écrit :

atari ST

L'Amiga du pauvre.

(ce vieux troll! )

Zugol · Le 08/11/2011, à 19:05

The Uploader a écrit :

(ce vieux troll! )

"Hipster was trolling before trolling was called trolling" !

Bliter_U · Le 08/11/2011, à 19:42

Voila une discutions qui me fait plaisir, sa parle d'Amiga, de musique et de Linux .. je prend surtout que j'ai du mal avec Ubuntu et le Midi ... c'est si simple sur Amiga ... Surtout pour se qui est des Sysex ... J'aimerais sauvegarder les banques de sons de mes synthés en .syx mais la il y a du chemin a faire ... Et un éditeur de sons pour synthé serais la bien venu sur Ubuntu ... Sans parler d'un séquencer du type Bars&Pipes Professional 2.5.

Bliter_U · Le 08/11/2011, à 20:00

Et pour la blague, si quelqu’un aurais l'idée de développer une sorte de tablette tactile type lecteur d'ebook orienté sysex et editeur de sons via connections midi et pour l'export une prise USB le tout fonctionnant sur batterie ou adaptateur secteur ben sa serais pas mal pour les musiciens orienté synthés non virtuel Bon bien c'est une idée comme une autre

lawl · Le 08/11/2011, à 20:13

Oui car le logiciel libre est pauvre en argent et doit avancer plus vite que des société qui pèsent des milliards pour maintenir la tête hors de l'eau. C'est David contre Ultimate-Turbo-Goliath. Le logiciel libre doit innover, séduire et convaincre car l'utilisateur final reste un monsieur-tout-le-monde qui changera de cap à la première brise. On ne peut repousser à l’infini, même la vénérable Debian Stable n'est pas infaillible !...

Je rajouterais aussi que tout dev est un homme et est donc dépendant du temps et veux aussi voir et avoir un résultat donc il faut parfois faire l'impasse ou reporter la mise en place d'une solution "idéal".
Mais cela est pareil dans tout les domaines de conception même pour construire une maison ont fait tjrs des compromis temps/argent.

Si les compilateurs C/C++ sont si géniaux, pourquoi un code pondu en assembleur semble être supérieur par son économie de place, sa rapidité ?

Un tournevis c'est incassable cela passe partout mais quand tu a une cuisine ikea à monter tu a intérer à avoir une visseuse électrique si tu ne veux pas divorcer !

Enfin voila penser que l'on peut faire 0 bug dans un programme un minimum sérieux c'est croire que l'homme peux parvenir à la perfection.
Une fusée c'est bien écrasé à cause d'une division par zéro et le code était certainement en assembleur !

grim7reaper · Le 08/11/2011, à 20:23

L_d_v_c@ a écrit :

Si les compilateurs C/C++ sont si géniaux, pourquoi un code pondu en assembleur semble être supérieur par son économie de place, sa rapidité ?

Il faut avoir une méconnaissance totale pour sortir des inepties pareilles.
Faire mieux que le compilo sur un soft’ entier ça reste vrai dans de très rares occasions :
- se concentrer sur un modèle de proc unique ;
- connaître son architecture et son fonctionnement au cycle près (et avec les processeurs de nos jours, bon courage car ce sont des monstres de complexité : exécution Out-of-Order, superscalaire, multicore, multithread, pipeline sur plusieurs niveaus, prédicteur de branchements, etc.) ;
- être excellent en assembleur.

En gros, c’est uniquement possible pour l’embarqué (et encore, dans certains cas seulement). Sur PC, tu oublies ça tout de suite : tu ne peux pas faire jeu égal avec un compilo (et encore moins le battre) sur un soft’ entier.

lawl a écrit :

Enfin voila penser que l'on peut faire 0 bug dans un programme un minimum sérieux c'est croire que l'homme peux parvenir à la perfection.
Une fusée c'est bien écrasé à cause d'une division par zéro et le code était certainement en assembleur !

Si tu parles d’Ariane 4 le code fautif était en Fortran.

L_d_v_c@ · Le 08/11/2011, à 21:01

Zugol <- C'est bizarre mais je continue de penser que si nous n'arrivons jamais au 0 bug, c'est bien la preuve que le code n'est pas maîtrisé. (C'est ma vision des chose d'un point de vue mathématique).

Puise je me permettre de te demander quel est ton niveau d’expérience en développement (en gros) ainsi que ton age ? N'y voit aucun mal c'est pour alimenter la discussion que je trouve passionnante et pour mieux me mettre à ta place. Personnellement j'ai 33 ans, je fais mumuse avec des ordis depuis l'age de 10 ans (atari ST), je bosse dans l'informatique depuis 12 ans et je n'ai jamais fais grand chose de bien de mes 10 doigts !

Tout petit niveau d'expérience en développement, beaucoup d'initiations mais peu de pratique. Un grand intérêt pour les structures d'ordinateur. Je suis né en 1976. À 10 ans, j'aidais au garage. Moto à 7 ans et MO5 TO7 (LOGO) à l'école à 9 ans. Mon père était contre l'idée d'avoir un ordinateur à la maison alors un peu plus tard je faisais mumuse avec la calculatrice programmable TI57 (vite maîtrisé vues les possibilités), je me divertissais avec la moto, le vélo, la musique, les montages électroniques, les expérience de MC Giver ...
Plus tard à 14 ans j'ai acheté un CPC6128, je me suis initié au Basic 1.0 sans pousser l'apprentissage vu mon emploi du temps chargé à l'époque.

Puis en 1993 je me suis fait traité de fou par mon professeur d'électronique devant toute la classe quand je lui ai demandé conseil en lui avouant vouloir faire une interface de 1024 Mo de RAM à partir de plusieurs sous modules (devant s'interfacer avec le A1200, je me renseignais car je ne savais pas à l'époque que le 68EC020 n'adresse physiquement qu'en 24 bits). Il a dit que je ne me rendais pas compte de ce que ça représentait. Que "jamais il n'y aurait 1 Go de RAM dans les ordinateurs à la maison."

D'un autre coté, 29 francs le module de 1 Mio de RAM multiplié par beaucoup de modules, il ne manquait que les sous.

Enfin je voulais devenir professeur de sciences physiques depuis la sixième, c'est ce qui m'a motivé et fait inscrire à l'université en 1996, mais j'ai eu un accident de voiture en 1999. Depuis les choses on changé. J'ai validé ma licence É.É.A. en 2004 et j'ai abandonné ma licence d'informatique en 2006 n'arrivant plus à palier études et traitements post-accident. Refus de la part de l'IUFM en 2007, je me suis inscrit au C.N.E.D. en remise à niveau en électronique et j'ai loupé l'inscription en préparation C.A.P.E.T. suite à un contre-temps post-accident.

Je ne bricole plus en électronique quand je constate la flambée des prix pour ce qui s’apparente à un luxe.

Alors je m'intéresse à la musique très haute définition. La liste de mon matériel est sur mon site LDVC@

J'ai possédé plusieurs ordinateurs (dont un Canon OX-7 ultra-portable avec lequel je pilotais mon jeu de lumières dans quelques fêtes) et calculatrices personnelles doublé d'un héritage de mon grand-père.

En développement limité : une trentaine de programmes TI d'analyse numérique qui se sont un peu répandu dans ma promotion à l'université en bac+3. J'ai rendu la copie au bout de 45 mn (sur 1h30). Le professeur a demandé si j'avais loupé, j'ai dit "non-non, j'ai tout vérifié". Le 20/20 m'a compensé la note de mathématiques.

Pour finir à la rigolade : c'est grâce au baccalauréat Génie des matériaux que j'ai pu entré à l'université pour faire de l'électronique, reçu lors des inscriptions, donné à 99,8% d'échec à la fin de la deuxième année. (N'ayant pas fait le Bac S). J'ai remonté les statistiques et validé le D.E.U.G. Technologie Industrielle en 1998 avec 101/200.

L_d_v_c@ · Le 08/11/2011, à 21:06

lawl a écrit :

...
Une fusée c'est bien écrasé à cause d'une division par zéro et le code était certainement en assembleur !

Ah oui, les programmeurs ont dû sauter le lycée car on vérifie toujours qu'on ne va pas faire une division par zéro avant de faire une division, non ?

L_d_v_c@ · Le 08/11/2011, à 21:31

grim7reaper a écrit :

...
En gros, c’est uniquement possible pour l’embarqué (et encore, dans certains cas seulement). Sur PC, tu oublies ça tout de suite : tu ne peux pas faire jeu égal avec un compilo (et encore moins le battre) sur un soft’ entier.

L'informatique industrielle a dû modifié mon jugement. C'est vrai qu'il faut trouver des solutions qui tournent sur un large parc informatique, ce qui n'est pas le cas avec les automates programmables, et ne l'était pas non plus avec l'Amiga.

Pour ceux qui veulent en prendre plein la tête, voici une démonstration totalement maitrisé je pense en langage machine PC !

Démonstration qui rappelle ce qui se faisait sur Amiga et qui utilise le processeur PC et les cartes graphiques récentes.

65536 octets !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Démonstration 64kio faite en assembleur !
http://www.clubic.com/lancer-le-telecha … ation.html

En plus ça tourne avec wine avec une carte graphique de bureautique :

 lspci|grep VGA
0b:00.0 VGA compatible controller: ATI Technologies Inc RV370 [Sapphire X550 Silent]
81:00.0 VGA compatible controller: ATI Technologies Inc RV370 [Sapphire X550 Silent]
83:00.0 VGA compatible controller: ATI Technologies Inc RV370 [Sapphire X550 Silent]

... soit c'est un bug ... non, j'ai bien trois cartes vidéo double écran sur cet ordinateur M.A.O. que je me suis monté.

Zoom 3 fonctionne avec wine en 640×480 et monte à 30 FPS. 5mn20 de vidéo + 1mn40 de remerciement et de détails de programmation : de compression surtout comme 5 Mo de textures compressées dans 1 ko.

Zoom 3 est ma référence de ce qui peut se faire avec un PC de type 86 ou x64_86. La preuve en vidéo avec de la musique trance.

65536 octets. Presque mon dernier mot !

PS : on peut me prendre pour un troll, rien que le nom me fait rire, mais je ris moins si on croit que j'ai une méconnaissance totale.

grim7reaper · Le 08/11/2011, à 21:36

T’es gentil mais moi je te parle de véritables applications, pas de démo pour faire mumuse (c’est très bien techniquement ça je ne le remets pas en cause, mais ça reste de la branlette technique qui n’a absolument rien à voir avec le développement d’application).

Je ne sais pas moi, montre moi une bibliothèque assembleur qui rivalisent avec ublas ?
Un équivalement à x264 entièrement en assembleur ?
Un truc du genre quoi.

Dernière modification par grim7reaper (Le 08/11/2011, à 21:38)

L_d_v_c@ · Le 08/11/2011, à 21:39

grim7reaper a écrit :

... mais ça reste de la branlette technique qui n’a absolument rien à voir avec le développement d’application).

N'est-ce pas en rapport avec ce qu'écrivait Zugol par rapport à l'économie devant être faite sur le facteur temps pour rendre un projet ?

grim7reaper · Le 08/11/2011, à 21:44

Non, c’est en rapport avec ça :

grim7reaper a écrit :

L_d_v_c@ a écrit :
Si les compilateurs C/C++ sont si géniaux, pourquoi un code pondu en assembleur semble être supérieur par son économie de place, sa rapidité ?
Il faut avoir une méconnaissance totale pour sortir des inepties pareilles.
Faire mieux que le compilo sur un soft’ entier ça reste vrai dans de très rares occasions :
- se concentrer sur un modèle de proc unique ;
- connaître son architecture et son fonctionnement au cycle près (et avec les processeurs de nos jours, bon courage car ce sont des monstres de complexité : exécution Out-of-Order, superscalaire, multicore, multithread, pipeline sur plusieurs niveaus, prédicteur de branchements, etc.) ;
- être excellent en assembleur.
En gros, c’est uniquement possible pour l’embarqué (et encore, dans certains cas seulement). Sur PC, tu oublies ça tout de suite : tu ne peux pas faire jeu égal avec un compilo (et encore moins le battre) sur un soft’ entier.

C’est mieux avec les passages en gras ?

Une démo ce n’est pas un soft’ entier, un petit programme tout au plus.
Donc j’attends ton équivalent (enfin plus rapide) 100% asm de x264 (ou uBLAS ou autre) en assembleur.

Dernière modification par grim7reaper (Le 08/11/2011, à 21:44)

Zugol · Le 08/11/2011, à 22:07

L_d_v_c@ a écrit :

Ah oui, les programmeurs ont dû sauter le lycée car on vérifie toujours qu'on ne va pas faire une division par zéro avant de faire une division, non ?

Là, je pense que tu n'as pas bien conscience de ce que représente le métier (les métiers) de la conception informatique. Ce que tu dis là, est lourd de sens ! Non, il ne "suffit" pas de "vérifier" qu'on ne fait pas un division par zéro. On parle d'un nombre de tests et de vérifications impossible à contrôler. Effectivement, développer quelque chose en solo et faire le tour de ses opérations c'est envisageable pour un TP ou un projet perso, mais l'informatique moderne engendre des projets qui impliquent parfois plusieurs centaines de développeurs au 4 coins du monde et nécessite une organisation telle qu'aucun humain, avec toute l'astuce et la bonne volonté possible, ne peut seul en connaitre et en comprendre toutes les facettes et donc encore moins prévoir tous les contrôles possibles. On parle là de millions de lignes de code de dernière génération qui pour chacune représente des centaines d'instruction système. On parle de systèmes d'information et d'architecture pas seulement de programmes batch sans interaction qui effectuent des calcul aussi complexes soient ils. Parfois même on ne sait pas ce que l'on doit développer car il faut formaliser des processus métiers qui ne sont pas les nôtres (oui, les développeurs doivent exceller dans leur domaine mais aussi comprendre le métier des autres car eux ne feront jamais l'effort inverse !) et que personne n'est capable d'expliquer. Un bug, ce n'est pas juste un null pointer ou un zero divide. Parfois un bug est issu d'une variable qui ne devrait pas être nulle, d'une valeur totalement imprévue ou de millions de possibilités engendrées par les dizaines de couche logicielles ainsi que toutes les interactions humaines possibles...

J'ai côtoyé des tas d'anciens demomakers extrêmement astucieux qui créaient des "programmes" en 4k magnifiques. Peu d'entre eux sont capables de s'intégrer dans le monde du génie logiciel car ils produisent un code in-maintenable ou totalement figé à toute évolution mais pourtant parfaitement optimisé et exempt de bug. Pour eux, un programme ça se lance, ça s'exécute et ça se termine. Sortie de là, à part quelques interruptions ils sont incapables de s'atteler à des problèmes d’interactions humaine, de multithreading, de files de communication, de modélisation de bases de données, de buffer pool, d'instanciation et j'en passe et des meilleurs.

Sérieux là, tu nous prends pour qui ?

ps : je ne suis pas amère, non, mais je trouve que tu ironises un peu trop...

Dernière modification par Zugol (Le 08/11/2011, à 22:09)

Inso · Le 08/11/2011, à 22:33

Zugol a écrit :

L_d_v_c@ a écrit :
Pourquoi ? avec toutes les techniques que tu cites ... c'est bien le but ? Arriver au code parfait ...
Parce que la "stack" logicielle est trop importante. Tu ne peux pas comparer des softs dédiés à une seule machine avec ce qui est développé aujourd'hui, avec toutes les notions de portabilités, d'échange, de standardisation. Même si la "stack" employée est parfois sur-dimensionnée par rapport au besoin, on ne peut pas se permettre de s'en passer. A titre d'exemple, tu installes une jre java même si tu ne fais tourner qu'une seule application (qui l'exploite à peine). De plus chaque composant logicielle est développé indépendamment des autres... Les bugs viennent aussi des combinaisons possibles...
Dans le cas d'une application intranet (vision très macro) on a :
langage machine > système d'exploitation > machine java > serveur d'application > serveur web > application > données > réseau...
Quand tu adoptes un framework, il contient lui même des bug encore inconnus, car le nombre de cas de test possibles et 3x supérieur à l'infinie (si, si, 3 fois).

J'avais lu un article il y a quelques temps (science & vie ?) qui traitait justement des bugs dans les programmes. Il était expliqué assez clairement que vu la taille des applications et les communications inter-programmes, le nombre de combinaison à tester était quasiment infini. Ils parlaient aussi de systèmes sophistiqués automatisés de tests, mais que ceux-ci n'arriveraient pas à déterminer tous les case de figure, même mathématiquement. Ils concluaient à un problème insoluble à moins, éventuellement, d'une remise en cause profonde des systèmes logiciels.

PS: j'ai toujours mes 2 Atari ST (sinon je ne me serais pas permis de poster ici hein )

L_d_v_c@ · Le 08/11/2011, à 22:36

grim7reaper a écrit :

...
Une démo ce n’est pas un soft’ entier, un petit programme tout au plus.
Donc j’attends ton équivalent (enfin plus rapide) 100% asm de x264 (ou uBLAS ou autre) en assembleur.

x264 semble avoir été très optimisé en C, je ne trouve pas le même programme écrit en assembleur mais je note dans http://student.ulb.ac.be/~jamartin/mem/FINAL.pdf

95/120 page 87 a écrit :

Finalement, nous avons donc choisi le codec open source x264 (écrit en en langage C) qui, après comparaison avec JM, s’est révélé meilleur. Non seulement il adopte une approche de qualité, tournée vers la performance ; mais il propose aussi, en assembleur, une utilisation partielle du parallélisme de bas niveau.

Ça ne répond pas à ta question mais au moins après recherche je sais qu'il existe quelque part l'algorithme en assembleur.

Pardon Zugol, je l'ai écrit : je n'ai pas de grande expérience de programmation, juste des cas d'école où on nous a appris à analyser chaque test, chaque E/S, à tout anticiper et se placer le plus possible au niveau processeur. J'ai juste un peu de mal avec le fait qu' Ariane 4 ait crachée car l'algorithme présentait une faille. Je me souvient de ces images à la télévision ...
J'ai longtemps cru que la fusée était trop fragile car j'ai cru la voir se tordre avant d'exploser.
Puis je n'ai jamais aimé entendre parler d'erreur informatique, de "bogue". Un ordinateur non surmené a peu de chance de planter à cause du matériel. Ça peut arriver, le plus souvent à cause du RAM défectueuse sur nos ordinateurs, qui sème le doute sur le reste du matériel.
Mais dans l’aérospatiale comme dans l'aviation, les commandes sont répétées.

Finalement c'est un peu comme effacer un fichier d'un RAID1 sur plusieurs disques. Il peut y avoir autant de disques qu'on veut, si on donne l'ordre de faire shred ça ne pardonne pas.

Alors pourquoi mettre un délai pour le lancement d'une fusée de plusieurs millions ? économiquement à cause des ingénieurs à payer sur lesquels ils économisent et on en revient au début de la discussion ?

Dernière modification par L_d_v_c@ (Le 08/11/2011, à 22:40)

grim7reaper · Le 08/11/2011, à 22:41

L_d_v_c@ a écrit :

Ça ne répond pas à ta question mais au moins après recherche je sais qu'il existe quelque part l'algorithme en assembleur.

Bien sûr, c’est pour ça que je parle de soft’ entier.
Il est parfois possible d’optimiser certaines parties du code en écrivant de l’assembleur (encore que, parfois on croit optimiser mais en fait on fiche la merde en se croyant meilleur que le compilo…), mais la majorité du soft’ reste en C (et donc optimisé par le compilo qui fait un bien meilleur boulot que l’humain).

L_d_v_c@ a écrit :

J'ai juste un peu de mal avec le fait qu' Ariane 4 ait crachée car l'algorithme présentait une faille.

C’est pas vraiment une faille dans l’algo, c’est plus une histoire de réutilisation qui n’aurait pas dû être faite.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#101 Le 08/11/2011, à 01:04

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#102 Le 08/11/2011, à 01:16

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#103 Le 08/11/2011, à 01:22

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#104 Le 08/11/2011, à 01:27

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#105 Le 08/11/2011, à 01:32

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#106 Le 08/11/2011, à 11:10

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#107 Le 08/11/2011, à 12:53

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#108 Le 08/11/2011, à 14:32

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#109 Le 08/11/2011, à 18:05

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#110 Le 08/11/2011, à 18:09

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#111 Le 08/11/2011, à 19:05

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#112 Le 08/11/2011, à 19:42

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#113 Le 08/11/2011, à 20:00

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#114 Le 08/11/2011, à 20:13

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#115 Le 08/11/2011, à 20:23

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#116 Le 08/11/2011, à 21:01

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#117 Le 08/11/2011, à 21:06

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#118 Le 08/11/2011, à 21:31

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#119 Le 08/11/2011, à 21:36

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#120 Le 08/11/2011, à 21:39

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#121 Le 08/11/2011, à 21:44

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#122 Le 08/11/2011, à 22:07

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#123 Le 08/11/2011, à 22:33

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#124 Le 08/11/2011, à 22:36

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

#125 Le 08/11/2011, à 22:41

Re : Y'en a t'il parmi vous qui avaient un Atari ou un Amiga ??

Pied de page des forums