[P3D]pourquoi P3D n est pas en 64 bits.

etien · [↑]

Je viens de lire un truc interessant de la part des developpeurs de P3D sur leur forum qui repondaient a la question: pourquoi pas une version 64bits pour eviter les ooms de plus en plus frequents avec les addons qui grossissent.

"We would love to have true 64bit support, but this isn't a feature we can rush. We're dealing with a massive baseline that has been in development since 1977. The first MS version was in 1982, but even that was a year before I was born. Obviously the baseline has been updated and refactored many times, but there are still snippets of assembly code and 32bit pointer math floating around in there, which adds complexity to the update process."

la: http://www.prepar3d.com/forum-5/?mingleforumaction=viewtopic&t=1862

ce qui se traduit par ""Il y a du code assembleur dans FSX qui date des premieres versions de FS qui dqte de 77"

Maintenant posons nous la question quel peut etre ce code ? Le FS de 82 n avait pas grand chose, le graphique engine et ces calculs trigonometriques ont ete portés sous dx9 donc ce n'est pas ca, peut etre le scheduler? ou des trucs esoteric comme le planetarium? (lune, etoiles etcs) ou l'ia des avions ? Ou pire - mais pas impossible - le flight engine?

Bref on n est pas pret de voir une version 64 bits.

Etienne

Ptipilot · [↑]

Bonjour,

Moi je veux bien qu'il remonte aussi loin, mais les premières instructions en 32 bits datent du 80386, soit 1985.

http://en.wikipedia.org/wiki/Intel_80386

Avant nous étions en 16 bits voir 8 bits...;)

NEPTUNE6P2V7 · [↑]

Bien oui à force de travailler avec des dinosaures de l'air paléontologique on se traine avec un fossile à 32 bits..! mais ils étaient au courant de l'époque ..!
*
et Dieu créa la femme et nous on reste des *Bleus bits* enfarinés

Donc le 64 sera XPLANE l'unique et seul miraculé ...!

Neptune

Yan Solo · [↑]

NEPTUNE6P2V7 a écrit :

Donc le 64 sera XPLANE l'unique et seul miraculé ...!
Neptune

En dépit des qualités de la nouvelle version XPlane faudra qu'il s'améliore encore pour que que j'y puisse passer....

A+++

Daniel-45 · [↑]

Va falloir que je regarde X-plane de plus près ...
Pasque.
Si P3d y traine encore des codes de... çà !

-
Là, c'est sûr que y a souci !! ;-))
-
M'enfin si on revient à la version "première".
Côté FPS on devrait commencer à respirer.
-
Comment çà, c'est pas beau ??
N'empêche !
Là, on doit taper dans le 300000 FPS !!
-
Cé pas grave tout çà.
On est trop nombreux pour qu'on nous oublie.
Nous et nos "sous" surtout ! :-))
-
Y a plein de gens qu'y pensent à nous $$$$$$$$$$$ ....0_o

Daniel

NEPTUNE6P2V7 · [↑]

Yan Solo a écrit :

NEPTUNE6P2V7 a écrit :
Donc le 64 sera XPLANE l'unique et seul miraculé ...!
Neptune
En dépit des qualités de la nouvelle version XPlane faudra qu'il s'améliore encore pour que que j'y puisse passer....
A+++

ILS s'y attèlent YANN SOLO, il faut laisser le temps au temps surtout au développement d'un SIMULATEUR ! pas si simple ...

Neptune

etien · [↑]

moi j avais commence sur le trs 80... etienne

http://www.volny.cz/havlikjosef/historyenglish.htm

MdMax · [↑]

NEPTUNE6P2V7 a écrit :

Donc le 64 sera XPLANE l'unique et seul miraculé ...!

En fait non, X-Plane n'est pas seul dans l'univers du 64 bits. Bien avant lui, FlightGear était déjà en 64 bits pour ceux qui se prenaient la peine de lancer un script de compilation.

Bons vols.

Steph-80 · [↑]

Hello
De l'assembleur dans FsX? La vache, pas si moderne que ça le bouzin finalement.
C'est clair que s'ils doivent se retaper de l'assembleur avec ces milliers de ligne de code pour faire pas grand chose et le retranscrire en langage de haut niveaux moderne, ils ont du pain sur la planche.

Pour ceux qui se demande ce que c'est que de "l'assembleur" c'est un vieux langage de programmation de bas niveaux très proche du langage machine qui elle (la machine) ne comprend que des 1 ou des zéro'.
Langage de bas niveaux certes, mais coté programmation, c'est du haut vol.
La je suis bluffé.

gastonj · [↑]

Bonjour,
Programmer en assembleur... cela se fait encore tous les jours et il n'y a rien d'extraordinaire à ça! Bon, il est vrai que certains compilateurs ( "C" notamment) génèrent un code ultra-performant. Mais le principal problème est la qualité du développement plus que le langage utilisé et là ...il y a souvent beaucoup à dire. Cela varie au gré des équipes qui se suivent sur le projet au fil ...des ans! C'est pas comme pour les web-applications kleenex (y compris smartphones) qui occupent les 7/8 des informaticiens actuellement. Une application, un jour ou l'autre, doit mourir car les concepts et l'architecture de base sont devenus obsolètes. D'autres deviennent mortes-nées, c'est ce qu'a pensé Microsoft avec FS et Flight. Avec P3D on voit qu'il est difficile de faire revivre un programme tombé dans le coma!
Cordialement,
JMC

Daube · [↑]

Apres faut voir comment se presente l'architecture de ces modules codes en assembleur.
Y'a deux possibilites: ou bien tu les modifies pour les passer en 64 bits, ce qui sous-entend qu'il faut d'abord les comprendre, puis les alterer, donc a peu pres ce qu'il y a de plus chiant pour un codeur... ou bien tu les remplace purement et simplement par d'autres fonctions codees avec un language moderne, et directement en 64 bits avec ton code a toi. La c'est mieux, pour le developpeur.

Mais souvent, lorsqu'un truc est (bien) code en assembleur, c'est tres difficile (voir impossible) de faire un truc plus performant avec un language normal.

kbumbaz · [↑]

Salut,

Je ne suis pas sur que quand ils évoquent assembly ils fasse référence à de l'assembleur.

Assembly
http://en.wikipedia.org/wiki/Assembly_(CLI)

Assembleur
http://en.wikipedia.org/wiki/Assembly_language

- L'assembleur était vu comme un langage dédié à un CPU.
- Une assembly : Chez Microsoft (comme chez Sun/Oracle) où la mode est au framework de développement, vous pouvez développez en C# C++ ou VB .NET, lors de la compil, le compilateur génère une "assembly" ! C'est un programme en langage CLI (Common Language Interface) capable de d’être interprété par le framework .NET. Théoriquement si vous faites la même appli en C#.NET ou VB.NET vous obtiendriez la même assembly (j'ai bien dis théoriquement car dans la pratique il y a des différences dues à la gestion des langages eux mêmes.).

Voila, malgré le CLI, il y a qd même parfois le besoin de compiler dans certains cas les programmes pour x86 ou 64bits (notamment lors de l'utilisation de librairies : si une seule librairie est spécifique 32bits, il faut tout compiler en 32, idem pour 64bits)

Ces deux paragraphes illustrent un exemple de la techno .NET mais l'idée reste valable pour beaucoup de framework.

Bye

etien · [↑]

nah en 77 c etait de l assembleur bien lourd et bien optimal avec des astuces de souix pour que ca depote. Je sais j ai pratiqué.

Exemple classique: driver reseau d'un router developpé selon les methodes "propres" de couches, langage object vituel, fonction bien explicitées etc contre gros hack bien illisible lineaire en assembleur optimisé à donf et complètement non maintenable, raport final de performance: de 1 a 20....

Pourquoi? car le codeur en assembleur va toujours aller chercher le micro code qui correspond exactement a ce dont il a besoin, alors que le compilateur suit sa propre logique qui n est pas toujours optimale (push pull de stack, non utilisation de certaines fonctions dediees a un processeur donne etc).

Etienne

Ptipilot · [↑]

etien a écrit :

nah en 77 c etait de l assembleur bien lourd et bien optimal avec des astuces de souix pour que ca depote. Je sais j ai pratiqué.

Ha... Toi aussi!...:a:a:a
Il faut dire qu'en ce temps là, on s'éclatait en programmation...=D

C'est vrai que pour que ça dépote, lorsque je développais (dans les années 85), j'ai compilé des sous modules en assembleur ou en C, dans du Clipper. Bonjour la maintenance derrière!....=8

etien · [↑]

Clair de l assembleur dans clipper ca devait etre chaud...

J ai serieusement bidouillé en 90-91 sur un campus US, le pire ? Pas sur, peut etre la fois ou m a demandé d optimiser le compilateur c d unix a l epoque apres l avoir décompilé, oui bien d ecrire des virus snoopers sur les sockets unixs?

Maintenant je fais des chateaux... c est plus modeste

Etienne

Daniel-45 · [↑]

Yo !!
On se refait le "Trip" "6502 Risc" de Motorola contre le "Z80 Cisc" de Zilog ???
Cà bataillai dur à l'époque !
Et ...
Cà nous rajeunit pas :-(
-
N'empêche:
Une belle "loop" en adressage pre ou post indexée ....
Des nuits que j'ai passé sur ces "C....ries".
Mé j'aimai bien.
Comme les concours ou fallait faire le "max" avec 80 ou 120 octets...
Pas Gigas / mega / Kilos, non, des octets ....
-
Bon exercice pour apprendre à optimiser un code.
-
Back to P3d...
Ils ont acheté (sûrement cher) la license ESP de MS.
Le noyeau reste d'origine.
Et quand on sait les soucis qu'ont eu les gars de "Ace" pour actualiser le bestiau vers les multicoeurs.
Cà va pas être simple, et çà va coûter du temps, donc des sous...
-
Mais ESP (donc FSX) reste la plus grande base de dévelopement.
Y a déjà la planète, même si c' est parfois succint.
Des millier ? millions ? d'objets pré existant.
Même si la qualité doit rester limitée à cause du moteur de rendu.
Il y a une porte ouverte à tous les ajouts possibles.
-
Suffit de se ballader sur la " AVSIM library" pour comprendre que çà intéresse du monde.
-
Après...
Tout passer de 8 vers 16 vers 32 vers 64 ....
A suivre.
J'ai dit 8, pasque si vous jetez un oeil vers certaines variables de FSX ...
Elles ont des limites qui n' ont aucune justification actuelle ... ;-)
-
C' est comme çà.
C' est pas grave.
L' histoire est pas finie.
-
J' suis quand même au dessus de l'Auvergne.
Dans un vieux biplan.
Le nez dehors.
Y a le soleil qui se couche sous les nuages ...
C' est beau.
-
J'aime bien mon FS.
-
Daniel

gastonj · [↑]

Bonsoir,
Le 6502 ... c'est Rockwell il me semble et pas Motorola...faut pas confondre avec le 6802 (je dois en avoir encore quelques puces de 6502, 6802 ou Z80 à 40 pattes dans mes tiroirs) . Le 6502, c'est l'Apple II et il y avait déjà un simulateur de vol sur cette bécane en 1979 ... en 3D Filaire bien sur...Si c'est beaucoup de jeux ...avec Visicalc, c'est le premier PC utilisable autrement qu'en contrôle de processus et je parle pas du Pascal UCSD. J'ai énormément programmé la dessus à mes débuts. Pfff...c'était ma jeunesse et ça valait pas loin de deux briques avec 64K et 2 drives!
Cordialement,
JMC

Dernière modification par gastonj (30-11-2012 20:01:01)

happening · [↑]

Ouais, c'est intéressant, mais inquiétant. Très inquiétant.
Mon seul espoir niveau simu est du coté de P3D. Le 64 bits est LE passage obligé dans l'évolution logique et la progression constante de la qualité des scènes pour FSX. Pas de 64 bits = un plafond dans le détail et la densité de l'autogen qui est déjà atteint, malgré l'évolution des machines.
Je me doute bien que recoder le coeur du programme pour le 64 bits est compliqué, donc chère. Il n'est pas étonnant qu'il y est de l'assembleur dans le coeur de FSX, c'était même prévisible.
En gros il nous dit que le budget alloué a P3D est limité, même pour l'indispensable passage au 64 bits. En gros ca me fait flipper pour l'avenir de P3D, et comme il n'y a pas de remplaçant au préhistorique FSX...

gastonj · [↑]

Bonjour,
Je crains qu'il n'y ait pas d'avenir 64 bits pour P3D! Une refonte du système s'imposerait pour le passage et l'assembleur n'est pas le seul problème. Même pour un programme écrit en "C", il faut faire attention à la taille des variables, notamment les nombres entiers, l'arithmétique des pointeurs mémoire etc...Un travail colossal pour les dizaines de millier de lignes de code et un coût énorme, presque aussi important qu'un nouveau développement. Sans compter que l'architecture du programme est déjà issue d'un replâtrage pour les processus concurrents (ce qu'on appelle la gestion des multi-cores). Tout ce que je pense qu'il est raisonnable d'espérer, c'est une correction des nombreuses boggues qui doivent encore trainer dans un programme sans maintenance depuis de longues années. Une meilleure adaptation à W7 ou W8 et directX aussi sans doute... bof, j'espère me tromper mais il me semble qu'ils visaient un meilleur réalisme pour en faire un outil de simulation professionnelle.
Cordialement,
JMC

Daube · [↑]

Travail collossal si tu veux absoluement conserver le code original.
Si en revanche tu remplace le code original par ton propre code, c'est une toute autre histoire. Faut simplement voir comment le code original est structure.

Comme ecrit precedemment, il y a certainement des modules dans le noyau qui sont des antiquites. Mais a partir du moment ou tu sais ce que ce module est sense calculer, tu peux tres bien le remplacer par du nouveau code qui fait la meme chose.

Maintenant on peut en debattre pendant des annees. Le fait est que les gars de P3D sont les seuls a avoir le nez dans le code actuellement, et donc sont les seuls a savoir exactement ce qu'il en est. De notre point de vue exterieur, il est tout simplement impossible de juger de la faisablite de la chose.

gastonj · [↑]

Bonjour,
Tu as sans doute raison! Cependant, par expérience, je peux te dire que ce n'est pas la faisabilité technique qui tranchera le sujet de son portage mais son aspect économique. Toutefois, ce n'est pas vraiment notre problème!
Cordialement,
JMC

Yan Solo · [↑]

A vous lire je me dis que finalement pour l'avenir il nous reste que deux solutions :
1) XPlane
2) le développement d'un nouveau simu

toutes les autres solutions présentes comme P3D n'ont aucun avenir car celui-ci sera un jour ou l'autre le 64bits...

A+++

Ptipilot · [↑]

gastonj a écrit :

Bonjour,
Je crains qu'il n'y ait pas d'avenir 64 bits pour P3D! Une refonte du système s'imposerait pour le passage et l'assembleur n'est pas le seul problème. Même pour un programme écrit en "C", il faut faire attention à la taille des variables, notamment les nombres entiers, l'arithmétique des pointeurs mémoire etc...Un travail colossal pour les dizaines de millier de lignes de code et un coût énorme, presque aussi important qu'un nouveau développement.

Ce n'est pas si colossal que cela surtout avec les outils de recherche dans le code.

Pour les bouts de code en ASM, j'ai la même vision que Daube. Je n'en vois plus réellement l'utilité aujourd'hui avec les compilateurs modernes. Autant réécrire directement ces fonctions avec des bouts de code moderne.

Après, avoir la volonté de le faire, est une autre histoire...=O

gastonj a écrit :

Sans compter que l'architecture du programme est déjà issue d'un replâtrage pour les processus concurrents (ce qu'on appelle la gestion des multi-cores).

Là, je diverge complétement sur ton analyse.
Qu'il ne puisse pas encore être optimisé, là surement!... Comme tout code d’ailleurs...
Par contre, comme tu m'as l'air d'être du métier, regarde et analyse son mode de fonctionnement et tu t'apercevras qu'ils ont utilisé les techniques de développement les plus performantes pour FSX.
Comme je l'ai déjà mentionné ici même, la seule chose que je vois qui pourrait améliorer le fonctionnement du code, c'est de mettre le thread de l'ATC qui est monolitique et qui tourne sur le core principale du processeur (en même temps que le thread principal...) ailleurs. Le mieux étant de le "fibreriser" est de dispatcher ceux ci sur l'ensemble des cores. Malheureusement cela doit poser quelques problèmes de synchro...
Mais, je pense que l'équipe de P. Taylor à l'époque, ne l'a pas fait uniquement pour des questions de gestion des priorités.

Sinon, pour être honnête, si j'étais propriétaire du code aujourd'hui, ma priorité sur celui-ci ne serait pas de le passer en 64 bits!...:a

Dernière modification par Ptipilot (01-12-2012 18:49:45)

gastonj · [↑]

Bonjour,
Oui, je suis du métier. Ils ont fait sans doute au mieux avec les possibilités à l'époque ... mais bon, c'est ce que j'appelle un replâtrage en touchant superficiellement ce qui pouvait l'être. Cependant, l'amélioration est très sensible et justifiait bien l’appellation "accélération". Maintenant, mon point de vue principal réside dans l'opportunité de le faire économiquement si tu regardes mon post précédent. Je suis sur que si c'est rentable, ils le feront et, que dans le cas contraire, ils s'abstiendront.
En ce qui concerne l'assembleur, je connais peu (ou pas) de gens qui ont pu réaliser directement un code plus performant que celui généré par le dernier compilateur "GNU C" à l'exception de la gestion spécifique du matériel et c'était déjà le cas en 1985 avec les compilateurs "C" Microsoft ou Borland et consort.

Cordialement,
JMC

Dernière modification par gastonj (01-12-2012 16:05:16)

Ptipilot · [↑]

gastonj a écrit :

Oui, je suis du métier. Ils ont fait sans doute au mieux avec les possibilités à l'époque ...

Le problème, c'est que la technique n'as pas vraiment évoluée dans ce domaine ces dix dernières années...
Là, je serai curieux de connaitre ce que tu pourrais y incorporer en plus et qui améliorerait (ent) le fonctionnement du moteur????......:8

gastonj a écrit :

mais bon, c'est ce que j'appelle un replâtrage en touchant superficiellement ce qui pouvait l'être.

En informatique, il est vraiment très, très , très rare que l'on réécrive tout... Donc, si tu vas par là, 99,9 % des programmes qui tournent de part le monde ne sont que des replâtrages.;)

gastonj a écrit :

Cependant, l'amélioration est très sensible et justifiait bien l’appellation "accélération".

Accéleration, n'as apporté aucune évolution technique.
Son but n'était juste que d'apporter quelques fonctionnalités complémentaires. Ce n'est pas la même chose....

Les avancées techniques ont eu lieu, d'une part entre le passage de FS9 à FSX RTM, et d'autre part avec le SP1 où ils ont touché en profondeur la gestion du moteur pour le rendre multicore.
Le SP2 lui, ne corrigeant que quelques bugs + ajout de l'implémentation DX10.
Ensuite, Acceleration ramène quelques fonctionnalités supplémentaires en s'appuyant sur cet ensemble.;)

Dernière modification par Ptipilot (01-12-2012 18:57:37)

#1 [↑][↓] 29-11-2012 12:50:54

[P3D]pourquoi P3D n est pas en 64 bits.

#2 [↑][↓] 29-11-2012 17:39:48

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#3 [↑][↓] 29-11-2012 17:47:42

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#4 [↑][↓] 29-11-2012 18:12:34

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#5 [↑][↓] 29-11-2012 19:51:00

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#6 [↑][↓] 29-11-2012 20:10:04

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#7 [↑][↓] 29-11-2012 21:39:09

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#8 [↑][↓] 29-11-2012 22:10:37

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#9 [↑][↓] 29-11-2012 23:28:54

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#10 [↑][↓] 30-11-2012 10:53:08

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#11 [↑][↓] 30-11-2012 11:24:55

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#12 [↑][↓] 30-11-2012 11:59:04

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#13 [↑][↓] 30-11-2012 12:41:02

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#14 [↑][↓] 30-11-2012 12:58:48

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#15 [↑][↓] 30-11-2012 13:18:04

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#16 [↑][↓] 30-11-2012 18:41:37

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#17 [↑][↓] 30-11-2012 19:58:20

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#18 [↑][↓] 01-12-2012 02:06:16

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#19 [↑][↓] 01-12-2012 09:50:23

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#20 [↑][↓] 01-12-2012 11:24:18

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#21 [↑][↓] 01-12-2012 11:59:57

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#22 [↑][↓] 01-12-2012 14:21:30

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#23 [↑][↓] 01-12-2012 14:51:07

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#24 [↑][↓] 01-12-2012 16:01:47

Re : [P3D]pourquoi P3D n est pas en 64 bits.

#25 [↑][↓] 01-12-2012 16:56:55

Re : [P3D]pourquoi P3D n est pas en 64 bits.

Pied de page des forums