Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Matériel Ordinateur Système Mac Apple et intel, c'est officiel !!!

Apple et intel, c'est officiel !!!

77 réponses
Avatar
lionelnet
Voir le compte rendu de la WWDC....

Moi je vais me coucher !!

--
http://power.pomme.free.fr
iChat : Syndicate of law
AluBook 1.25 Mac Mini 1.42 Mac OS X 10.3.8
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
3 4 5 6 7
Avatar
fbarrin
Eric Lévénez wrote:

Les seules choses à laquelle le développeur doit faire attention sont (à 2
ou 3 détails données dans les docs Apple) :

- portabilité du code (little/big endian, taille des pointeurs...)
- optimisation liée au PPC (Altivec, code assembleur...)


les optimisations sur mac, c'est un peu un probleme. J'ai un emulateur
playstation 1 qui viens du monde unix et qui rame énormément sur un G4
1,25 (une play c'est 33MHz!)
Apparemment ou ce n'est pas facile d'optimiser sur mac, ou c'est trop
chiant.
j'ai lu un commentaire d'un developpeur sur le web qui se plaignait
qu'apple pousse trop l'utilisation de classes cocoa au lieu de
programmer des morceaux en C pur pour optimiser les opérations simples
et répétitives, ce qui alourdit les programmes : est on dans ce cas pour
mac os x? est ce que çà peut s'arranger avec le passage en intel (les
développeurs qui optimisent pour i86 sont plus nombreux) ou au
contraire, est ce qu'apple ne va pas encore plus forcer l'utilisation de
langages de haut niveau faisant abstraction du processeur?

Avatar
benoistf
Pierre-Alain Dorange wrote:

Une "Road Map" [*] Apple aussi clair existe ? Ou ça ?
Ca serait une première.
Mais si voyons. Souviens-toi:

"Les G5 à 3GHz pour l'été 2004" SJ
;)

--
Benoist

Avatar
Eric Lévénez
Le 8/06/05 22:27, dans
<1gxuze9.3d92zh5gm0peN%, « Fahimy »
a écrit :

Eric Lévénez wrote:

Les seules choses à laquelle le développeur doit faire attention sont (à 2
ou 3 détails données dans les docs Apple) :

- portabilité du code (little/big endian, taille des pointeurs...)
- optimisation liée au PPC (Altivec, code assembleur...)


les optimisations sur mac, c'est un peu un probleme. J'ai un emulateur
playstation 1 qui viens du monde unix et qui rame énormément sur un G4
1,25 (une play c'est 33MHz!)


Sur n'importe quelle machine, l'optimisation d'un programme est un problème.
Le premier jet d'un programme est souvent fonctionnel, les optimisations
spécifiques viennent après.

Apparemment ou ce n'est pas facile d'optimiser sur mac, ou c'est trop
chiant.


Disons que les programmeurs sont en majorité sur x86 avec un GCC (par ex)
plus optimisé, alors que passé sur sur Mac, ils découvrent et il faut dire
que le compilo GCC est moins bon.

j'ai lu un commentaire d'un developpeur sur le web qui se plaignait
qu'apple pousse trop l'utilisation de classes cocoa au lieu de
programmer des morceaux en C pur pour optimiser les opérations simples
et répétitives, ce qui alourdit les programmes : est on dans ce cas pour
mac os x?


Tout dépend quel type de programme on fait. L'environnement Cocoa est plus
lourd à l'exécution, mais apporte beaucoup plus de richesse et de
fonctionnalité sans que le programmeur ait à faire quoique ce soit. Un des
dernier exemple est le fameux Pomme-Ctrl-D.

est ce que çà peut s'arranger avec le passage en intel (les
développeurs qui optimisent pour i86 sont plus nombreux) ou au
contraire, est ce qu'apple ne va pas encore plus forcer l'utilisation de
langages de haut niveau faisant abstraction du processeur?


J'espère que ce sera le deuxième cas. OPENSTEP a été conçu en vue de la
portabilité, et les utilisateurs de Mac OS X vont s'en apercevoir.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.


Avatar
jim.fcsm
Jerome Vernet wrote:

Et ça, ce serait bien.


Ah bon ? Et pourquoi acheter un mac dans ce cas ?


Dans le domaine professionnel quand on s'aperçoit que parce qu'un soft
métier n'est pas présent sur Mac, on n'achète des PCs... ça peut avoir
un sens si l'on tient à conserver MacOS, non ?

--
YZ : Cupertino vient de lâcher Apple Garamond
PM : Que fait la police ?
-+- PM in LTQFRJ : Killed X-File ? -+-


Avatar
Schmurtz
(Fahimy) wrote:

Zeldus wrote:

Et dire que venant du monde PC, j'étais heureux d'avoir basculé sur Mac.
Dans moins de deux ans, Apple ne sera qu'un simple assembleur de PC avec
un simple bios propriétaire qui permettra de faire tourner "Leopard",
Mac OS X pour PC. Et les utilisateurs de Macintosh pourront même faire
tourner Windows en natif sur leur machine...


ce n'est pas grave, le systeme par defaut est Mac, et les gens qui
achetent un ordi de nos jours, l'achetent la plupart du temps pour ce
qu'il y a "par défaut". Dans ce cas, pour un systeme d'exploitation
magnifique, stable, puissant, et un tas de logiciels annexes utiles. Les
gens auxquels je montrerait le futur macintel (je suis vendeuse) quand
ils accrocheront à iphoto et Cie, ils iront pas acheter une boite de
windows pour la mettre à la place.


Je pense que c'est en gros ce qui se passera. Les gens normaux (ie, ceux
qui ne s'intéressent pas à l'informatique, soit la majorité des gens) ne
sauront pas qu'il est possible de lancer macosx sur un pc, ou alors ne
sauront pas comment faire. Et connaissant les juristes de chez apple,
j'imagine que peu de monde tentera de défier apple en diffusant très
largement la méthode pour le faire.

Quand au bios... j'espere qu'on en saura vite bien plus sur ce qu'on va
perdre et gagner par rapport à open firmware.


Personnellement, la principale chose que j'attends d'apple, c'est que
tout se passe comme actuellement : boot sans lignes de texte qui
défilent, possibilité de booter facilement sur des disques externes/sur
des CDs, existance du mode target. Et là dessus, j'espère qu'on peut
leur faire confiance.

--
Schmurtz


Avatar
Schmurtz
(Fahimy) wrote:

Eric Lévénez wrote:

Les seules choses à laquelle le développeur doit faire attention sont (à 2
ou 3 détails données dans les docs Apple) :

- portabilité du code (little/big endian, taille des pointeurs...)
- optimisation liée au PPC (Altivec, code assembleur...)


les optimisations sur mac, c'est un peu un probleme. J'ai un emulateur
playstation 1 qui viens du monde unix et qui rame énormément sur un G4
1,25 (une play c'est 33MHz!)
Apparemment ou ce n'est pas facile d'optimiser sur mac, ou c'est trop
chiant.


Surtout quand le développeur en question vient de se taper
l'optimisation pour x86... c'est rarement amusant d'optimiser du code,
alors le faire une fois ça passe, mais le faire une deuxième fois ça
devient vite lourd.

j'ai lu un commentaire d'un developpeur sur le web qui se plaignait
qu'apple pousse trop l'utilisation de classes cocoa au lieu de
programmer des morceaux en C pur pour optimiser les opérations simples
et répétitives, ce qui alourdit les programmes : est on dans ce cas pour
mac os x? est ce que çà peut s'arranger avec le passage en intel (les
développeurs qui optimisent pour i86 sont plus nombreux) ou au
contraire, est ce qu'apple ne va pas encore plus forcer l'utilisation de
langages de haut niveau faisant abstraction du processeur?


Il faire attention aux fous de l'optimisation : en général ils
optimisent des trucs qui n'apporte rien.

Regarde par exemple une appli tout ce qu'il y a de plus classique avec
une interface utilisateur complexe et derrière des fonctionnalités de
calculs un peu gourmande. Pour l'interface, aucun besoin d'optimiser,
même avec du cocoa écrit sans soucis d'optimisation, tout reste très
fluide, donc aucun besoin de chercher à faire du C qui sera plus
compliqué à écrire, moins fonctionnel au final, et tout aussi réactif.

Ce qui importe, c'est d'optimiser les fonctionnalités internes de
calculs gourmand (àmha rarement plus de quelques pourcents de code).
C'est cette partie là qui doit être optimisée, pas le reste. Si vraiment
c'est les appels cocoa qui ralentissent le traitement dans ces zones de
code critique, ben faut abandonner leur utilisations mais uniquement
dans ces zones critiques.

--
Schmurtz


Avatar
bertrand.bachellerie_nospam
C'est ce qu'Apple va faire. Il y aura un DVD d'install de Mac OS X et idem
pour les applications. Chaque programme sera dispo en Universal-Binary.

Apple pourra même fournir plus d'architectures dans le futur car les
développeurs n'auront qu'un bouton de plus à cocher.
Donc finalement, Apple a bien joué son coup.

Pour peu que les devs jouent le jeu et cochent les cases kivonbien, on
pourrait avoir une gamme Mac Intel, une gamme Mac PPC... Bref, un choix
multiplié, et surtout une assurance pour l'avenir. :)


J'ai l'impression que c'est ce que beaucoup de Macounets ont de mal à
comprendre. C'est bien de jouer à Astérix dans son village gaulois qui
résiste à l'envahisseur, mais si l'on veut une véritable pérennité,
celle-ci passe par la possibilité de pouvoir choisir le type CPU le plus
adapté et le plus prometteur pour l'avenir.
Apple a du retenir la leçon de la stagnation de la fréquence du G4: je
ne pense pas qu'Apple aurait pu s'en remettre une seconde fois si elle
s'était fait de nouveau larguée.

--
Bertrand


Avatar
fbarrin
Eric Lévénez wrote:

Sur n'importe quelle machine, l'optimisation d'un programme est un problème.
Le premier jet d'un programme est souvent fonctionnel, les optimisations
spécifiques viennent après.


les émulateurs dont je parle ont déjà une paire d'années. Le fait est
que les auteurs d'émulateurs sout windows, dans le meme laps de temps,
font des produits qui tournent 2 fois plus vite. Il faudra que je teste
les versions Linux x86 pour me faire une idée plus précise.

Disons que les programmeurs sont en majorité sur x86 avec un GCC (par ex)
plus optimisé, alors que passé sur sur Mac, ils découvrent et il faut dire
que le compilo GCC est moins bon.


finalement est ce que ce n'est pas plutot une question de compilateur
libre (gcc) peu optimisé parce que destiné à etre portable et à etre
révisé en permanence, alors que sur windows on tourne plutot sur du
propriétaire (piraté souvent) dont l'évolution est bloquée sur une
longue durée et l'optimisation plus importante?

Tout dépend quel type de programme on fait. L'environnement Cocoa est plus
lourd à l'exécution, mais apporte beaucoup plus de richesse et de
fonctionnalité sans que le programmeur ait à faire quoique ce soit. Un des
dernier exemple est le fameux Pomme-Ctrl-D.


Dashboard?

J'espère que ce sera le deuxième cas. OPENSTEP a été conçu en vue de la
portabilité, et les utilisateurs de Mac OS X vont s'en apercevoir.


donc tout faire en haut niveau et en objet, en objective C- java,
arreter les bout de code en C, y compris pour optimiser des opérations
très élémentaires et répétitives?
Le C est portable pourtant. En tant qu'utilisatrice je le sens quand je
vois les freewares d'émulation ou d'encodage pour mes acquisition TV,
que mon mac ne tourne pas à fond comme un windows sous virtual dub.
C'est dommage il n'y a pas d'intermédiare entre la programmation crade
mais efficace et la programmation propre mais lourde?

Avatar
une.bevueVOTEZ
Benoist Felsenheld wrote:

Pour peu que les devs jouent le jeu et cochent les cases kivonbien, on
pourrait avoir une gamme Mac Intel, une gamme Mac PPC... Bref, un choix
multiplié, et surtout une assurance pour l'avenir. :)


ça, effectivement, c'est une * TRES * bonne nouvelle ;-)

--
une bévue

Avatar
pdorange
Jean-Yves Bernier wrote:

Faut pas confondre processeur x86 et PC.


Ouais, n'empêche que je vais devoir jeter mon code Altivec.

Font chier, font chier, font chier...


Oui et Non.
Apple propose depuis 10.3 une librairie qui encapsule les calculs
Vectoriels, ils conseillent d'utiliser celle-ci en lieu de place des
appels directes a Altivec.

Et comme par hasard, on lit dans le "Universal Binary Guideline" que
cette librairie est portée sur Intel... Du coup en passant par cette
librairie ton code profite des performances spécifiques du processeur
vectoriel a tout les coups (Altivec pour PPC et SSE pour Intel).

Ca s'appelle "Accelerate Framework" :
<http://developer.apple.com/documentation/MacOSX/Conceptual/universal_bi
nary/universal_binary_vector/chapter_6_section_2.html>

et comprend VectorLib et Image Accelerate.

Je ne sais pas exactement ce que ça vaut (je m'en sers pas) mais ça me
parait être un effort intéressant.

--
Pierre-Alain Dorange

Vidéo, DV et QuickTime <http://alcazar.xbecom.com/videogarage/>
Clarus, the DogCow <http://clarus.chez.tiscali.fr/>


3 4 5 6 7