Avis d'un développeur Mac...
- Créateur du sujet KNT
- Date de début
Pfff, faut pas donner la parole au peuple, au final les réponses sont pas celles aux questions posées 
KaptainKavern a dit:Pfff, faut pas donner la parole au peuple, au final les réponses sont pas celles aux questions posées
...Pas faux...
Bonjour,
Ah moi j'aurai dit l'inverse Parce que si les developpeurs étaient des cons, ca voudrait dire qu'ils ne sont pas suffisament intelligent pour adapter leur logiciel au x86.
Donc dire que la transition vers le x86 sera facile, c'est donc penser que les developpeurs sont suffisament intelligent pour arriver à adapter leur logiciel rapidement et donc qu'ils sont loin d'être con
Cela dit, quand on voit les autres OS qui tournent sur differentes plateforme materiels tel que Linux ou BeOS Intel/PPC, faire une transition d'un même OS portable d'une architecture à l'autre, si l'application a porté a été codé de façon portable (ce qui est une bonne pratique de programmation), il est evident que ce genre de transition est ce qui se fait de plus facile en terme de portage (pour un grand nombre d'appli c'est pas beaucoup plus qu'une recompilation).
Rien à voir par exemple avec un portage entre deux OS radicalement differents et encore moins si en plus de porter sur un OS different on porte sur une architecture differente. On peut prendre l'exemple du portage des jeux DirectX PC/Windows sur Mac/PPC, où le plus gros du portage est d'adapter les moteurs utilisant DirectX, à OpenGL, et où l'endianess et autre specificité du changement d'architecture ne represente qu'une faible partie du travail de portage.
Maintenant evidement si la/les applications à porter ont beaucoup de code ASM, ou autres optimisations specifiques au CPU, là c'est une autre paire de manche qui necessiterait
plus de boulot.
Quoiqu'il arrive, personne ne peut nier que cette transition sera bien plus facile que les deux precedente (68k->PPC, OS9->OSX) puisque les APIs d'OS X et OS X se pretent bien mieux à ce genre d'exercice.
A+
Didier Guillion a dit:
Ah moi j'aurai dit l'inverse
Parce que si les developpeurs étaient des cons, ca voudrait dire qu'ils ne sont pas suffisament intelligent pour adapter leur logiciel au x86.Donc dire que la transition vers le x86 sera facile, c'est donc penser que les developpeurs sont suffisament intelligent pour arriver à adapter leur logiciel rapidement et donc qu'ils sont loin d'être con
Cela dit, quand on voit les autres OS qui tournent sur differentes plateforme materiels tel que Linux ou BeOS Intel/PPC, faire une transition d'un même OS portable d'une architecture à l'autre, si l'application a porté a été codé de façon portable (ce qui est une bonne pratique de programmation), il est evident que ce genre de transition est ce qui se fait de plus facile en terme de portage (pour un grand nombre d'appli c'est pas beaucoup plus qu'une recompilation).
Rien à voir par exemple avec un portage entre deux OS radicalement differents et encore moins si en plus de porter sur un OS different on porte sur une architecture differente. On peut prendre l'exemple du portage des jeux DirectX PC/Windows sur Mac/PPC, où le plus gros du portage est d'adapter les moteurs utilisant DirectX, à OpenGL, et où l'endianess et autre specificité du changement d'architecture ne represente qu'une faible partie du travail de portage.
Maintenant evidement si la/les applications à porter ont beaucoup de code ASM, ou autres optimisations specifiques au CPU, là c'est une autre paire de manche qui necessiterait
plus de boulot.
Quoiqu'il arrive, personne ne peut nier que cette transition sera bien plus facile que les deux precedente (68k->PPC, OS9->OSX) puisque les APIs d'OS X et OS X se pretent bien mieux à ce genre d'exercice.
A+
Si la transition est si facile pourquoi Apple n'a pas livré XCode en version x86 ?
Je me trompe certainement, mais d'apres ce que j'ai vu, ce n'est pas le cas...
Cordialement
Je me trompe certainement, mais d'apres ce que j'ai vu, ce n'est pas le cas...
Cordialement
D'après ce que j'ai lu sur macbidouille, toutes les applications, mise à part iTunes, incluses dans le kit de développement x86 sont compilées nativement pour x86.Didier Guillion a dit:
Faut-il en déduire que XCode est une version x86 ?
@+
iota
Bonjour,
Ca c'est de l'argumentation par l'absurde, absurde justement
Cela dit je ne sait pas si le XCode livré avec la machine de transition est x86 ou PPC, par contre GCC est en x86. Cela ne m'etonnerait pas que XCode soit en x86 aussi d'ailleurs, et s'il ne l'est pas, cela m'etonnerait pas qui le soit d'ici (très) peu de temps.
Cela dit l'OS X des machines de transition est lui en x86 ainsiq ue les logiciels fournis (Safari, Quicktime...etc) à ce que j'ai entendu. Sans compter les autres exemples de portages.
Perso je pense que porter un logiciel MacOS X PPC Cocoa -> MacOS X x86 Cocoa c'est pas plus dur que Linux PPC -> Linux x86.
PAr contre pour les applis Carbon c'est un peu plus dur puisque c'est derivé d'APIs de MacOS 9 qui se prete moins à ce genre de transition. Cela devrait qd même être pas si dur que ca. Visiblement Mathematica (qui n'est pas une petite appli) était en Carbon et à été porté en quelques heures donc...
A+
Didier Guillion a dit:
Ca c'est de l'argumentation par l'absurde, absurde justement
Cela dit je ne sait pas si le XCode livré avec la machine de transition est x86 ou PPC, par contre GCC est en x86. Cela ne m'etonnerait pas que XCode soit en x86 aussi d'ailleurs, et s'il ne l'est pas, cela m'etonnerait pas qui le soit d'ici (très) peu de temps.
Cela dit l'OS X des machines de transition est lui en x86 ainsiq ue les logiciels fournis (Safari, Quicktime...etc) à ce que j'ai entendu. Sans compter les autres exemples de portages.
Perso je pense que porter un logiciel MacOS X PPC Cocoa -> MacOS X x86 Cocoa c'est pas plus dur que Linux PPC -> Linux x86.
PAr contre pour les applis Carbon c'est un peu plus dur puisque c'est derivé d'APIs de MacOS 9 qui se prete moins à ce genre de transition. Cela devrait qd même être pas si dur que ca. Visiblement Mathematica (qui n'est pas une petite appli) était en Carbon et à été porté en quelques heures donc...
A+
Frodon a dit:Bonjour,
Ca c'est de l'argumentation par l'absurde, absurde justement
Cela dit je ne sait pas si le XCode livré avec la machine de transition est x86 ou PPC, par contre GCC est en x86. Cela ne m'etonnerait pas que XCode soit en x86 aussi d'ailleurs, et s'il ne l'est pas, cela m'etonnerait pas qui le soit d'ici (très) peu de temps.
Cela dit l'OS X des machines de transition est lui en x86 ainsiq ue les logiciels fournis (Safari, Quicktime...etc) à ce que j'ai entendu. Sans compter les autres exemples de portages.
Perso je pense que porter un logiciel MacOS X PPC Cocoa -> MacOS X x86 Cocoa c'est pas plus dur que Linux PPC -> Linux x86.
PAr contre pour les applis Carbon c'est un peu plus dur puisque c'est derivé d'APIs de MacOS 9 qui se prete moins à ce genre de transition. Cela devrait qd même être pas si dur que ca. Visiblement Mathematica (qui n'est pas une petite appli) était en Carbon et à été porté en quelques heures donc...
A+
Tu es l'homme qui a vu l'homme et qui vu l'ours ? Ou tu parles par expérience personnelle ?
Cordialement
Bonjour,
Les deux:
Perso j'ai compilé les quelques projets que j'ai en cours en Universal Binary (bien que pouvant pas les tester, n'ayant pas de Transition Kit) sans soucis. Cela dit ce sont des projets Cocoa et sans specificité sur l'architecture marteriel, donc pour eux j'ai juste eu à les compiler.
Et j'ai aussi constaté par l'intermediaire de personne qui developpe sous Linux que bien souvent adapter un logiciel d'un Linux sur architecureX à un Linux sur architectureY est facile (peu d'adaptation necessaire) voir très facile (presque aucune voir aucune adaptation necessaire). Et je vois pas pourquoi il en serait pas de même avec OS X.
A+
Didier Guillion a dit:
Les deux:
Perso j'ai compilé les quelques projets que j'ai en cours en Universal Binary (bien que pouvant pas les tester, n'ayant pas de Transition Kit) sans soucis. Cela dit ce sont des projets Cocoa et sans specificité sur l'architecture marteriel, donc pour eux j'ai juste eu à les compiler.
Et j'ai aussi constaté par l'intermediaire de personne qui developpe sous Linux que bien souvent adapter un logiciel d'un Linux sur architecureX à un Linux sur architectureY est facile (peu d'adaptation necessaire) voir très facile (presque aucune voir aucune adaptation necessaire). Et je vois pas pourquoi il en serait pas de même avec OS X.
A+
On nous dit depuis longtemps que l'architecture RISC des PowerPC est mieux que l'architecture CISC des x86. Je veux bien le croire, mais les faits sont là : le x86 tiens la dragée haute face au PowerPC. Preuve que c'est pas si pourri que ça, non ? Une histoire de meilleure optimisation ? Et alors ? Un bon moteur bien utilisé vaut peut-être mieux qu'un meilleur moteur moins bien utilisé. Et puis griefs prêtés au x86, ils sont vieux de 10 ans, donc à coup-sûr caducs : chez Intel et ses concurrents fondeurs de x86, on n'est pas resté les bras croisés depuis.
Et puis il faut arrêter de dramatiser cette histoire de code à reprendre. Pour 99% des programmes, il n'y aura rien à reprendre : les compilateurs sont performants, de nos jours. Y compris pour le code soi-disant optimisé altivec ou 64 bits. Quand on programme dans un langage de haut-niveau avec un environnement de développement perfectionné, on n'a pas à se soucier de ces options dans le code proprement dit. Si on souhaite en profiter, on donne quelques indications au compilateur et on le laisse faire. Surtout avec un langage comme l'objective-C : orienté objet, utilisation d'un runtime et axé sur les liens tardifs - c'est loin, très loin, du C de base et il reste peu d'astuces au programmeur pour gagner 3 instructions assembleurs sur une ligne de code (astuces qui, au passage, rendent généralement le code plus difficile à maintenir).
Pour le % de programme restant, c'est du code bas niveau. Pour l'essentiel, il concerne les concepteurs de l'OS, et en l'occurence, ce sont les mieux placés pour prendre les devants.
Pour conclure, je vais donner mon avis sur ce switch : comme tous le monde, j'ai un pincement au coeur. Un proc' différent dans des machines différentes, ça confirmait bien la philosophie think different. Mais après tout, cette réaction est plus affective que rationnelle. Aurait-on eu une telle émotion si Apple avait abandonné le PowerPC pour de l'ARM, du SPARC ou du MIPS ? Sérieusement, je ne pense pas que ce switch va poser tant de problème technique que ça (juste un gros doute sur les performances de Rosetta : on n'a jamais vu d'émulateur tenir ses promesses). Le seul souci serait plutôt d'ordre commercial, je pense : entre certains mac-users qui ont du mal à avaler la pilule et d'autres (dont moi) qui se garderont bien d'acheter une machine PowerPC avant leurs remplacements, Apple va peut-être avoir du mal à tenir. Mais après tout, cette décision n'est pas la mienne, et je pense pas que Jobs, Schiller et consorts ont pris cette décision sans penser à tous ça. Jobs est peut-être capricieux (dit-on, moi j'en sais rien), mais c'est pas un abruti non plus. Wait and see, mais je me fait pas trop de souci.
Et puis il faut arrêter de dramatiser cette histoire de code à reprendre. Pour 99% des programmes, il n'y aura rien à reprendre : les compilateurs sont performants, de nos jours. Y compris pour le code soi-disant optimisé altivec ou 64 bits. Quand on programme dans un langage de haut-niveau avec un environnement de développement perfectionné, on n'a pas à se soucier de ces options dans le code proprement dit. Si on souhaite en profiter, on donne quelques indications au compilateur et on le laisse faire. Surtout avec un langage comme l'objective-C : orienté objet, utilisation d'un runtime et axé sur les liens tardifs - c'est loin, très loin, du C de base et il reste peu d'astuces au programmeur pour gagner 3 instructions assembleurs sur une ligne de code (astuces qui, au passage, rendent généralement le code plus difficile à maintenir).
Pour le % de programme restant, c'est du code bas niveau. Pour l'essentiel, il concerne les concepteurs de l'OS, et en l'occurence, ce sont les mieux placés pour prendre les devants.
Pour conclure, je vais donner mon avis sur ce switch : comme tous le monde, j'ai un pincement au coeur. Un proc' différent dans des machines différentes, ça confirmait bien la philosophie think different. Mais après tout, cette réaction est plus affective que rationnelle. Aurait-on eu une telle émotion si Apple avait abandonné le PowerPC pour de l'ARM, du SPARC ou du MIPS ? Sérieusement, je ne pense pas que ce switch va poser tant de problème technique que ça (juste un gros doute sur les performances de Rosetta : on n'a jamais vu d'émulateur tenir ses promesses). Le seul souci serait plutôt d'ordre commercial, je pense : entre certains mac-users qui ont du mal à avaler la pilule et d'autres (dont moi) qui se garderont bien d'acheter une machine PowerPC avant leurs remplacements, Apple va peut-être avoir du mal à tenir. Mais après tout, cette décision n'est pas la mienne, et je pense pas que Jobs, Schiller et consorts ont pris cette décision sans penser à tous ça. Jobs est peut-être capricieux (dit-on, moi j'en sais rien), mais c'est pas un abruti non plus. Wait and see, mais je me fait pas trop de souci.
Didier, si ça peut te rassurer.
On notera au passage que les petits gars de chez blizards on réussi en quelques heures de travail (4-5 heures) à faire fonctionner WOW verxio MacIntel jusqu'à l'écran d'authentification.
@+
iota
On notera au passage que les petits gars de chez blizards on réussi en quelques heures de travail (4-5 heures) à faire fonctionner WOW verxio MacIntel jusqu'à l'écran d'authentification.
@+
iota
Didier Guillion a dit:
Je pense comme Didier que tout n'est pas si simple.
Ok, pour une bonne appli Cocoa avec de l'ObjectiveC, ça va fonctionner.
Mais quelqu'un qui a fait un projet CodeWarrior en Carbon aura certainement plus de mal.
Sans compter les lignes en assembleur, les optimisation Altivec maintenant inutiles, etc.
Moi, ça fait un moment déjà que je me suis tourné vers Java pour éviter tous ces problèmes de dépendances, de librairies, de perte de temps. Bon, ok, j'avoue qu'on ne fait pas des softs aussi intégrés avec ce langage, mais ça m'évite quand même d'être dépendant de toutes ces décisions et transitions.
J'ai une question qui me trotte dans la tête quand même : Est-ce que Apple va tout passer sur Intel et délaisser complètement le PPC ou va être prendre le meilleur des 2 suivant les années et les saisons?
Par exemple, X86 pour le portables, et G5 (et suivants) pour les machines de bureau.
Là, ce serait une prouesse, des binaires qui tournent sur 2 processeurs différents (grâce au FAT binary) et le choix total du processeur dans les 2 familles!
Apple pourrait ainsi choisir entre 3 (ou 4) constructeurs de puces à n'importe quel moment!
Mais j'ai cru comprendre que les PPC allaient quand même être abandonnés un jour ou l'autre? Avez-vous des précisions là dessus.
Sinon, je suis bien conforté dans mon choix de Java. Ca laisse le boulot à Apple pour faire un JVM correcte, pendant ce temps, je n'ai rien à réapprendre ou à modifier.
En tous cas, je comprends vos réactions, vous qui développez en C.
SuperCed a dit:
Là, c'est plus du ressort de l'éditeur de Code Warrior que des développeurs. Mais, ils vont certainement pas laisser en plan leurs utilisateurs.
SuperCed a dit:
Mais qui, aujourd'hui, met encore des lignes d'assembleur dans le code d'une application Mac (ou PC) ? A part les développeurs de l'OS (et encore) et ceux des compilateurs, y en a pas des masses. Et en l'occurence, ce sont certainement les mieux préparés à cette transition. Quand aux optimisations altivec, elles sont plus du ressort du compilateur et des API concernées que du code en lui-même.
lupus yonderboy a dit:
Codewarrior, racheté par Motorola, a arreté le developpement de ses produits.
Au passage la compilation d'un projet sous CodeWarrior va deux fois plus vite que sous XCode...
Je suis en train de porter mes projets CW sous XCode depuis trois jour et j'ai environ 10 plantage XCode par jour. ...
Quand a l'assembleur, si tu veut aller vite, tu l'utilise. C'est ce que l'on appelle l'optimisation...
Cordialement
Frodon a dit:
Merci de ta réponse. Pour l'instant je n'ai essayé que des projets Carbon et des projets AppleScript Studio melant AppleScript, Obj-C et C. Ca ne passe pas...
Je vais essayer avec un projet Cocoa pur avant de dire des bétises.
Cordialement
SuperCed a dit:
J'y crois pas. Car deux archi, ca représente un surcoût en R&D lorsqu'il faut concevoir les machines. Mais c'est vrai qu'Apple doit être très pressée de sortir des PowerBook intel mais va prendre son temps à mon avis pour sortir un Xserve Intel.
Didier Guillion a dit:
Je savais pas. Mais je suppose que que le switch Intel ne change pas grand chose pour toi : si tu veux maintenir et faire évoluer tes projets CodeWarrior, tu es a priori obligé, tôt ou tard, de les passer sous XCode, x86 ou pas.
Didier Guillion a dit:
C'est regrettable, je te l'accorde
Didier Guillion a dit:
Et concrètement, dans quelles situations les compilateurs donnent un exécutable vraiment trop lent pour devoir sacrifier à la maintenabilité du code (en dehors de ceux que j'ai cité) ? Sauf ton respect, Didier, (et au vu de ton expérience et de tes faits, j'en ai beaucoup pour toi) ça ressemble à une habitude d'ancien, ça
lupus yonderboy a dit:Je savais pas. Mais je suppose que que le switch Intel ne change pas grand chose pour toi : si tu veux maintenir et faire évoluer tes projets CodeWarrior, tu es a priori obligé, tôt ou tard, de les passer sous XCode, x86 ou pas.
C'est regrettable, je te l'accorde
Et concrètement, dans quelles situations les compilateurs donnent un exécutable vraiment trop lent pour devoir sacrifier à la maintenabilité du code (en dehors de ceux que j'ai cité) ? Sauf ton respect, Didier, (et au vu de ton expérience et de tes faits, j'en ai beaucoup pour toi) ça ressemble à une habitude d'ancien, ça
Dans un processus d'optimisation, la premiere étape est de de determiner qu'elle fonction occupe le plus de temps machine. Pour cela je te recommande Shark un excellent produit fourni par Apple.
Il ne sert a rien d'optimiser une routine qui ne prends que 5% du temps machine. Les meilleures optimisations que j'ai pu obtenir en passant du C a l'Assembleur sont de l'ordre de divisé par deux.
Dans ce cas un gain de 2% est négligeable.
Donc il faut se focaliser sur les routines prenant plus de 20% voire 50% du temps machine à un moment donné.
Si tu fait du traitement du signal (image, son), tu te rends compte que certaines routines tres courte en taille peuvent prendre 60-80%. Tu demande alors a ton compilateur de les desassembler et tu essaie de faire mieux que lui.
Si tu travaille en C, tu peut "aider" le compilateur, en déclarant tes variables essentielles commes "register". Mais là, il faudrait poursuivre dans le forum "developpement"...
Cordialement
Sujets similaires
- Membre supprimé 2
- Réagissez ! 2
- Schwarzy from Kampala
- Réagissez !