x86 Mac Os X, Un site qui peut être utile

[Jean-Baptiste]

Bonjour,

Le site x86 Mac Os X vous propose un catalogue gratuit des logiciels Macintosh pour PowerPC et Pentium.

Vous cherchez à connaître si un logiciel est prévu pour les deux processeurs?
Visitez le site x86 Mac Os X

Vous développez un logiciel et il est prêt pour les deux processeurs?
Inscrivez votre logiciel sur x86 Mac Os X
C'est gratuit et rapide!

Le site x86 Mac Os X
x86 Mac Os X

Cordialement
Le Site x86 Mac Os X

PS: Ceux qui peuvent aider à l'amélioration des traductions sont les
bien venu!

[f_cam]

Codée correctement ou pas, des que l'appli sera grosse consommatrice de CPU, la différence sera nette entre une appli native et rosetta, on se demande bien pourquoi steve n'a fait qu'ouvrir quelques documents photoshop, sans appliquer de filtres.

Ca ne sert pas a grand chose aujourd'hui mais ca serait bien d'avoir quelque chose de touffu pour quand les machines seront pretes.

[Guest_Fredbezies_*]

Codée correctement ou pas, des que l'appli sera grosse consommatrice de CPU, la différence sera nette entre une appli native et rosetta, on se demande bien pourquoi steve n'a fait qu'ouvrir quelques documents photoshop, sans appliquer de filtres.

Ca ne sert pas a grand chose aujourd'hui mais ca serait bien d'avoir quelque chose de touffu pour quand les machines seront pretes.
[right][snapback]1218192[/snapback][/right]

Photoshop, l'exemple même d'usine à gaz ?

Si une appli est codé proprement, en utilisant Cocoa (et non carbon), la transition devrait se faire sans douleur.

Et il est quasiment certains qu'Adobe sortira une version x86 de Photoshop OSX

Quoique pour un usage courant, Gimp suffit largement

[chombier]

Si une appli est codé proprement, en utilisant Cocoa (et non carbon), la transition devrait se faire sans douleur.
[right][snapback]1218294[/snapback][/right]

Cocoa ou Carbon, le coeur de ton appli est compilée pour un processeur particulier, avec ses optimisations spécifiques.
Se dire qu'un interpréteur de code altivec va faire aussi bien qu'une autre conception par un développeur utilisant les extensions SSE et consoeurs relève du fantasme.

[Guest_Fredbezies_*]

Si une appli est codé proprement, en utilisant Cocoa (et non carbon), la transition devrait se faire sans douleur.
[right][snapback]1218294[/snapback][/right]

Cocoa ou Carbon, le coeur de ton appli est compilée pour un processeur particulier, avec ses optimisations spécifiques.
Se dire qu'un interpréteur de code altivec va faire aussi bien qu'une autre conception par un développeur utilisant les extensions SSE et consoeurs relève du fantasme.
[right][snapback]1218317[/snapback][/right]

Jamais dit le contraire. Mais optimiser une application pour un processeur particulier, sur un unix comme MacOS-X, c'est assez """""idiot"""""

D'ailleurs, comme je le disais au dessus, les applications cités sont soit tirées des labos d'Apple, soit c'est de l'open source

[f_cam]

Jamais dit le contraire. Mais optimiser une application pour un processeur particulier, sur un unix comme MacOS-X, c'est assez """""idiot"""""

N'importe quoi. Aucun rapport entre l'utilité d'optimiser une appli pour un processeur et le fait d'avoir un OS dérivé d'un unix.
On peut effectivement dire que, lorsque c'est possible, il est mieux d'utiliser les libraries optimisés d'Apple (le framework accelerate par exemple), mais c'est parce que comme ça c'est apple qui fait le travail d'optimisation, et lors du passage x86 on profite du travail des ingénieurs d'apple, mais ça n'a aucun rapport avec le fait d'être un unix ou pas.

D'ailleurs, comme je le disais au dessus, les applications cités sont soit tirées des labos d'Apple, soit c'est de l'open source

Si les logiciels cités sont soit des logiciels Apple, soit de l'open source c'est surtout (à mon avis) parce que pour tout ce qui est appli commerciale il y a une inertie beaucoup plus importante. Le developpeur ne se dit pas "tiens je vais aller bidouiller du x86 aujourd'hui", si (par exemple) les bugs des versions actuelles sont plus important, et bien il bossera la dessus (et de toute façon c'est son patron qui décide).
Et puis les developer transition kits commencent tout juste à arriver (le mien est prevu pour le 18 juillet, alors que j'ai commandé le jour de l'annonce)

[Guest_Fredbezies_*]

Jamais dit le contraire. Mais optimiser une application pour un processeur particulier, sur un unix comme MacOS-X, c'est assez """""idiot"""""

N'importe quoi. Aucun rapport entre l'utilité d'optimiser une appli pour un processeur et le fait d'avoir un OS dérivé d'un unix.

Si tu le dis. J'ai encore sortie une énorme connerie. Surtout - test perso - le gain est souvent infime, à moins de coder le logiciel directement en assembleur

On peut effectivement dire que, lorsque c'est possible, il est mieux d'utiliser les libraries optimisés d'Apple (le framework accelerate par exemple), mais c'est parce que comme ça c'est apple qui fait le travail d'optimisation, et lors du passage x86 on profite du travail des ingénieurs d'apple, mais ça n'a aucun rapport avec le fait d'être un unix ou pas.

Unix est surement le système le plus portable qui existe. Comme il est codé en C/C++, il se """"contrefout"""" du CPU utilisé

Si les logiciels cités sont soit des logiciels Apple, soit de l'open source c'est surtout (à mon avis) parce que pour tout ce qui est appli commerciale il y a une inertie beaucoup plus importante. Le

Non ?

developpeur ne se dit pas "tiens je vais aller bidouiller du x86 aujourd'hui", si (par exemple) les bugs des versions actuelles sont plus important, et bien il bossera la dessus (et de toute façon c'est son patron qui décide).
Et puis les developer transition kits commencent tout juste à arriver (le mien est prevu pour le 18 juillet, alors que j'ai commandé le jour de l'annonce)
[right][snapback]1219042[/snapback][/right]

Quand même, le 18 juillet prochain ? Doit y avoir de la demande chez Apple