Ca fait des années que tous les sites techniques (non Mac) démontrent la
supériorité d'un RISC IBM à tout point de vue. Alors j'espère
sérieusement que si ça se fait, c'est qu'Intel a un truc dans les
tiroir. Qu'ils ne nous refilent pas ces saloperies de centrino...
Mais c'est vrai que l'essentiel, c'est l'OS. Et tant qu'Apple continuera
à assurer, je resterai fidèle.
Ce qui me travaille, c'est que je ne suis pas certain que la raison
avancé par Steve soit vraie (pb avec IBM et tout ça).
Si ma mémoire est bonne (n'hésitez pas à corriger), lors de la
présentation du Mac mini, il avait dit qu'ils avaient une stratégie de
reconquête du marché en 3 phases :
- 1 - Le couple iPod + iTunes sur PC, afin de montrer à ceux qui n'ont
pas de Mac à quel point Apple est cool et sexy (pour reprendre les
termes à la mode)
- 2 - Le Mac mini, afin que plus personne ne puisse parler de prix, et
qu'un utilisateur Wintel puisse switcher pour pas grand chose
- 3 - La 3ème étape, il a juste dit qu'on la découvrirait plus tard, et
qu'elle serait révolutionnaire.
Alors, avait-il l'intention de passer Intel depuis longtemps ? Auquel
cas les raisons avancées, même si elles ont un fond de vérité, ne l'ont
été que pour faire avaler la pilule aux macounets.
Pour être "pire", est-ce que ça n'aurait pas été fait en accord avec
IBM, qui finalement n'a peut-être pas l'intention de s'investir pour "si
peu" ?
Alors, avait-il l'intention de passer Intel depuis longtemps ? Auquel
surtout qu'il a gardé en interne depuis le début de MacOS X Rapshody une équipe d'ingénieurs chargé de maintenir une version Intel d'OS X. Lors de la keynote, il a même dit que MacOS X est cross-platform depuis l'origine....
Alors, avait-il l'intention de passer Intel depuis longtemps ? Auquel
surtout qu'il a gardé en interne depuis le début de MacOS X Rapshody une
équipe d'ingénieurs chargé de maintenir une version Intel d'OS X. Lors
de la keynote, il a même dit que MacOS X est cross-platform depuis
l'origine....
Alors, avait-il l'intention de passer Intel depuis longtemps ? Auquel
surtout qu'il a gardé en interne depuis le début de MacOS X Rapshody une équipe d'ingénieurs chargé de maintenir une version Intel d'OS X. Lors de la keynote, il a même dit que MacOS X est cross-platform depuis l'origine....
JMGB
Jean-Daniel SEYRES wrote:
Auquel cas les raisons avancées, même si elles ont un fond de vérité, ne l'ont été que pour faire avaler la pilule aux macounets.
Sur ce point là, à force d'encenser aveuglément Steve depuis des années, les Macounets devraient penser que dans ce domaine comme dans bien d'autres bien plus proches de nous en France, c'est toujours pareil: il faut mentir, toujours et tout le temps, ce qui compte, c'est la façon de présenter les mensonges. Le but était, toujours et encore, de faire prendre des vessies pour des lampes *haute-consommation*.
-- Le génie fait ce qu'il doit. Le talent fait ce qu'il peut. *Virer les minuscules pour me répondre*
Auquel
cas les raisons avancées, même si elles ont un fond de vérité, ne l'ont
été que pour faire avaler la pilule aux macounets.
Sur ce point là, à force d'encenser aveuglément Steve depuis des années,
les Macounets devraient penser que dans ce domaine comme dans bien
d'autres bien plus proches de nous en France, c'est toujours pareil: il
faut mentir, toujours et tout le temps, ce qui compte, c'est la façon de
présenter les mensonges.
Le but était, toujours et encore, de faire prendre des vessies pour des
lampes *haute-consommation*.
--
Le génie fait ce qu'il doit.
Le talent fait ce qu'il peut.
*Virer les minuscules pour me répondre*
Auquel cas les raisons avancées, même si elles ont un fond de vérité, ne l'ont été que pour faire avaler la pilule aux macounets.
Sur ce point là, à force d'encenser aveuglément Steve depuis des années, les Macounets devraient penser que dans ce domaine comme dans bien d'autres bien plus proches de nous en France, c'est toujours pareil: il faut mentir, toujours et tout le temps, ce qui compte, c'est la façon de présenter les mensonges. Le but était, toujours et encore, de faire prendre des vessies pour des lampes *haute-consommation*.
-- Le génie fait ce qu'il doit. Le talent fait ce qu'il peut. *Virer les minuscules pour me répondre*
pdorange
Jean-Daniel SEYRES wrote:
Comme beaucoup ici, je l'ai un peu mauvaise...
C'est un coup dur, mais tout cela peut aussi être profitable...
Ca fait des années que tous les sites techniques (non Mac) démontrent la supériorité d'un RISC IBM à tout point de vue.
Oui et non.
Oui la plateforme PowerPC est probablement techniquement supérieur.
Non dans la réalité la gamme PowerPC a toujours été en retard coté performance et réactivité sur la plateforme Intel. Les rares fois ou les PowerPC sont revenus dans la course, ils ont toujours été rattraper dans les mois suivants pour se laissé distancer (G5 comme dernier exemple et G4 avant).
La grosse différence, AMHA et après consultation de plusieurs sources techniques sur internet, c'est que même si l'architecture PowerPC est supérieur sur le papier, Intel a des moyens que IBM n'a pas financièrement de par la taille du marché notamment. Du coup Intel progresse plus vite et surtout est bien plus dynamique.
Alors j'espère sérieusement que si ça se fait, c'est qu'Intel a un truc dans les tiroir. Qu'ils ne nous refilent pas ces saloperies de centrino...
Y'a déjà. Intel a annoncé Yonah pour début 2006, qui est le futur de Centrino. Un processeur Bi-core 32 bits beaucoup plus petit et assez performant a priori sur le papier. Idéal pour les portable. Yonah marque aussi le passage de Intel a la gravure à 65nm. Yonah inclus aussi SSE optimisé (l'équivalent grosso modo de Altivec).
<http://www.appleinsider.com/article.php?id23>
[...] Ce qui me travaille, c'est que je ne suis pas certain que la raison avancé par Steve soit vraie (pb avec IBM et tout ça) [...] Alors, avait-il l'intention de passer Intel depuis longtemps ?
L'intention pas forcément, mais se reserver la possibilité oui; car on sait maintenant que depuis la béta jusqu'a 10.4 Apple a maintenu en interne une version x86 de MacOS X (pendant 5 ans donc). On voit aussi que Apple a sorti le lendemain de l'annonce tout les outils de développements (XCode 2.1, Universal Binary et un PowerMac Intel), c'était donc près depuis quelques temps.
Auquel cas les raisons avancées, même si elles ont un fond de vérité, ne l'ont été que pour faire avaler la pilule aux macounets. Pour être "pire", est-ce que ça n'aurait pas été fait en accord avec IBM, qui finalement n'a peut-être pas l'intention de s'investir pour "si peu" ?
C'est tout a fait possible en effet. Disons d'un commun accord. J'ai de plus en plus l'impression qu'en fait si le fond (de ce Steve a annoncé) est vrai, la raison fondamental n'est pas tant technique que financière. C'est à dire que si il est probablement vrai que le G5 est difficile a optimiser pour portable, cela a un cout, d'autant plus élevé que : - la difficulté technique est grande - la durée de conception voulut est faible - le marché est petit (seul Apple utilise ces puces)
A coté de ça, les fournisseurs potentiels de PowerPC IBM et FreeScale (ex. Motorola semi conductor) oriente leur marché depuis quelques temps vers d'autres cibles que la micro-informatique. Freescale s'oriente depuis des années vers l'embarqué et IBM oriente ces powerpc vers d'un coté les consoles de jeux (Cell) et de l'autre les gros serveurs haut de gamme (Power). Le marché PowerPC est réduit a Apple comme seul client qui représente malgré des ventes honorables un marché réduit (on parle tout de même de plusieurs centaines de millions de consoles Cell l'an prochain). Tout cela tendrait a rendre, AMHA, le cout de développement et d'évolution des PowerPC pour Mac de plus en plus cher.
En se tournant vers Intel, Apple peut bénéficier d'un produit plus dynamique (rafraichit plus souvent), dont le coup de développement est réduit (marché très large) et aussi avec Intel qui peut proposer tout une gamme de service autour (carte mère, bus, entrées/sorties, architecture portable, etc...) que ne propose pas AMD (qui ne fait globablement que des processeurs).
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime <http://alcazar.xbecom.com/videogarage/> Clarus, the DogCow <http://clarus.chez.tiscali.fr/>
C'est un coup dur, mais tout cela peut aussi être profitable...
Ca fait des années que tous les sites techniques (non Mac) démontrent la
supériorité d'un RISC IBM à tout point de vue.
Oui et non.
Oui la plateforme PowerPC est probablement techniquement supérieur.
Non dans la réalité la gamme PowerPC a toujours été en retard coté
performance et réactivité sur la plateforme Intel. Les rares fois ou les
PowerPC sont revenus dans la course, ils ont toujours été rattraper dans
les mois suivants pour se laissé distancer (G5 comme dernier exemple et
G4 avant).
La grosse différence, AMHA et après consultation de plusieurs sources
techniques sur internet, c'est que même si l'architecture PowerPC est
supérieur sur le papier, Intel a des moyens que IBM n'a pas
financièrement de par la taille du marché notamment.
Du coup Intel progresse plus vite et surtout est bien plus dynamique.
Alors j'espère
sérieusement que si ça se fait, c'est qu'Intel a un truc dans les
tiroir. Qu'ils ne nous refilent pas ces saloperies de centrino...
Y'a déjà.
Intel a annoncé Yonah pour début 2006, qui est le futur de Centrino. Un
processeur Bi-core 32 bits beaucoup plus petit et assez performant a
priori sur le papier. Idéal pour les portable. Yonah marque aussi le
passage de Intel a la gravure à 65nm.
Yonah inclus aussi SSE optimisé (l'équivalent grosso modo de Altivec).
<http://www.appleinsider.com/article.php?id23>
[...]
Ce qui me travaille, c'est que je ne suis pas certain que la raison
avancé par Steve soit vraie (pb avec IBM et tout ça)
[...]
Alors, avait-il l'intention de passer Intel depuis longtemps ?
L'intention pas forcément, mais se reserver la possibilité oui; car on
sait maintenant que depuis la béta jusqu'a 10.4 Apple a maintenu en
interne une version x86 de MacOS X (pendant 5 ans donc).
On voit aussi que Apple a sorti le lendemain de l'annonce tout les
outils de développements (XCode 2.1, Universal Binary et un PowerMac
Intel), c'était donc près depuis quelques temps.
Auquel
cas les raisons avancées, même si elles ont un fond de vérité, ne l'ont
été que pour faire avaler la pilule aux macounets.
Pour être "pire", est-ce que ça n'aurait pas été fait en accord avec
IBM, qui finalement n'a peut-être pas l'intention de s'investir pour "si
peu" ?
C'est tout a fait possible en effet.
Disons d'un commun accord. J'ai de plus en plus l'impression qu'en fait
si le fond (de ce Steve a annoncé) est vrai, la raison fondamental n'est
pas tant technique que financière. C'est à dire que si il est
probablement vrai que le G5 est difficile a optimiser pour portable,
cela a un cout, d'autant plus élevé que :
- la difficulté technique est grande
- la durée de conception voulut est faible
- le marché est petit (seul Apple utilise ces puces)
A coté de ça, les fournisseurs potentiels de PowerPC IBM et FreeScale
(ex. Motorola semi conductor) oriente leur marché depuis quelques temps
vers d'autres cibles que la micro-informatique.
Freescale s'oriente depuis des années vers l'embarqué et IBM oriente ces
powerpc vers d'un coté les consoles de jeux (Cell) et de l'autre les
gros serveurs haut de gamme (Power).
Le marché PowerPC est réduit a Apple comme seul client qui représente
malgré des ventes honorables un marché réduit (on parle tout de même de
plusieurs centaines de millions de consoles Cell l'an prochain).
Tout cela tendrait a rendre, AMHA, le cout de développement et
d'évolution des PowerPC pour Mac de plus en plus cher.
En se tournant vers Intel, Apple peut bénéficier d'un produit plus
dynamique (rafraichit plus souvent), dont le coup de développement est
réduit (marché très large) et aussi avec Intel qui peut proposer tout
une gamme de service autour (carte mère, bus, entrées/sorties,
architecture portable, etc...) que ne propose pas AMD (qui ne fait
globablement que des processeurs).
--
Pierre-Alain Dorange
Vidéo, DV et QuickTime <http://alcazar.xbecom.com/videogarage/>
Clarus, the DogCow <http://clarus.chez.tiscali.fr/>
C'est un coup dur, mais tout cela peut aussi être profitable...
Ca fait des années que tous les sites techniques (non Mac) démontrent la supériorité d'un RISC IBM à tout point de vue.
Oui et non.
Oui la plateforme PowerPC est probablement techniquement supérieur.
Non dans la réalité la gamme PowerPC a toujours été en retard coté performance et réactivité sur la plateforme Intel. Les rares fois ou les PowerPC sont revenus dans la course, ils ont toujours été rattraper dans les mois suivants pour se laissé distancer (G5 comme dernier exemple et G4 avant).
La grosse différence, AMHA et après consultation de plusieurs sources techniques sur internet, c'est que même si l'architecture PowerPC est supérieur sur le papier, Intel a des moyens que IBM n'a pas financièrement de par la taille du marché notamment. Du coup Intel progresse plus vite et surtout est bien plus dynamique.
Alors j'espère sérieusement que si ça se fait, c'est qu'Intel a un truc dans les tiroir. Qu'ils ne nous refilent pas ces saloperies de centrino...
Y'a déjà. Intel a annoncé Yonah pour début 2006, qui est le futur de Centrino. Un processeur Bi-core 32 bits beaucoup plus petit et assez performant a priori sur le papier. Idéal pour les portable. Yonah marque aussi le passage de Intel a la gravure à 65nm. Yonah inclus aussi SSE optimisé (l'équivalent grosso modo de Altivec).
<http://www.appleinsider.com/article.php?id23>
[...] Ce qui me travaille, c'est que je ne suis pas certain que la raison avancé par Steve soit vraie (pb avec IBM et tout ça) [...] Alors, avait-il l'intention de passer Intel depuis longtemps ?
L'intention pas forcément, mais se reserver la possibilité oui; car on sait maintenant que depuis la béta jusqu'a 10.4 Apple a maintenu en interne une version x86 de MacOS X (pendant 5 ans donc). On voit aussi que Apple a sorti le lendemain de l'annonce tout les outils de développements (XCode 2.1, Universal Binary et un PowerMac Intel), c'était donc près depuis quelques temps.
Auquel cas les raisons avancées, même si elles ont un fond de vérité, ne l'ont été que pour faire avaler la pilule aux macounets. Pour être "pire", est-ce que ça n'aurait pas été fait en accord avec IBM, qui finalement n'a peut-être pas l'intention de s'investir pour "si peu" ?
C'est tout a fait possible en effet. Disons d'un commun accord. J'ai de plus en plus l'impression qu'en fait si le fond (de ce Steve a annoncé) est vrai, la raison fondamental n'est pas tant technique que financière. C'est à dire que si il est probablement vrai que le G5 est difficile a optimiser pour portable, cela a un cout, d'autant plus élevé que : - la difficulté technique est grande - la durée de conception voulut est faible - le marché est petit (seul Apple utilise ces puces)
A coté de ça, les fournisseurs potentiels de PowerPC IBM et FreeScale (ex. Motorola semi conductor) oriente leur marché depuis quelques temps vers d'autres cibles que la micro-informatique. Freescale s'oriente depuis des années vers l'embarqué et IBM oriente ces powerpc vers d'un coté les consoles de jeux (Cell) et de l'autre les gros serveurs haut de gamme (Power). Le marché PowerPC est réduit a Apple comme seul client qui représente malgré des ventes honorables un marché réduit (on parle tout de même de plusieurs centaines de millions de consoles Cell l'an prochain). Tout cela tendrait a rendre, AMHA, le cout de développement et d'évolution des PowerPC pour Mac de plus en plus cher.
En se tournant vers Intel, Apple peut bénéficier d'un produit plus dynamique (rafraichit plus souvent), dont le coup de développement est réduit (marché très large) et aussi avec Intel qui peut proposer tout une gamme de service autour (carte mère, bus, entrées/sorties, architecture portable, etc...) que ne propose pas AMD (qui ne fait globablement que des processeurs).
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime <http://alcazar.xbecom.com/videogarage/> Clarus, the DogCow <http://clarus.chez.tiscali.fr/>
Stephane Madrau
Pierre-Alain Dorange wrote:
Non dans la réalité la gamme PowerPC a toujours été en retard coté performance et réactivité sur la plateforme Intel. Les rares fois ou les PowerPC sont revenus dans la course,
Ouais, il faut rappeler que le 604e a été le premier a franchir les 300MHz. Et après, rattrappé, dépassé et adieu... :-)
-- Stéphane
Pierre-Alain Dorange wrote:
Non dans la réalité la gamme PowerPC a toujours été en retard coté
performance et réactivité sur la plateforme Intel. Les rares fois ou les
PowerPC sont revenus dans la course,
Ouais, il faut rappeler que le 604e a été le premier a franchir les
300MHz. Et après, rattrappé, dépassé et adieu... :-)
Non dans la réalité la gamme PowerPC a toujours été en retard coté performance et réactivité sur la plateforme Intel. Les rares fois ou les PowerPC sont revenus dans la course,
Ouais, il faut rappeler que le 604e a été le premier a franchir les 300MHz. Et après, rattrappé, dépassé et adieu... :-)
-- Stéphane
Laurent PERON
surtout qu'il a gardé en interne depuis le début de MacOS X Rapshody une équipe d'ingénieurs chargé de maintenir une version Intel d'OS X. Lors
J'ai l'impression que beaucoup sont étonnés d'apprendre que OSX marche sur x86. Darwin, qui est open source, est compilable depuis longtemps (depuis toujours ?) sur x86, ya rien de nouveau la dedans.
Les seuls choses qui manquent (et qui doivent etre portés sur x86) ce sont les drivers non inclus dans la distrib open source de Darwin, et les optimisations spécifiques altivec par exemple, qui sont dans Cocoa, Carbon, etc. Le reste c'est du C / Objective-C / Obj-C++ tout ce qu'il y a de plus classique et qu'il suffit de recompiler sur x86. Et ca c'est pas grand chose à faire, vu que GCC existe sur x86.
Ou bien me trompe-je ?
LaP
surtout qu'il a gardé en interne depuis le début de MacOS X Rapshody une
équipe d'ingénieurs chargé de maintenir une version Intel d'OS X. Lors
J'ai l'impression que beaucoup sont étonnés d'apprendre que OSX marche
sur x86. Darwin, qui est open source, est compilable depuis longtemps
(depuis toujours ?) sur x86, ya rien de nouveau la dedans.
Les seuls choses qui manquent (et qui doivent etre portés sur x86)
ce sont les drivers non inclus dans la distrib open source de Darwin,
et les optimisations spécifiques altivec par exemple, qui sont
dans Cocoa, Carbon, etc. Le reste c'est du C / Objective-C / Obj-C++
tout ce qu'il y a de plus classique et qu'il suffit de recompiler
sur x86. Et ca c'est pas grand chose à faire, vu que GCC existe
sur x86.
surtout qu'il a gardé en interne depuis le début de MacOS X Rapshody une équipe d'ingénieurs chargé de maintenir une version Intel d'OS X. Lors
J'ai l'impression que beaucoup sont étonnés d'apprendre que OSX marche sur x86. Darwin, qui est open source, est compilable depuis longtemps (depuis toujours ?) sur x86, ya rien de nouveau la dedans.
Les seuls choses qui manquent (et qui doivent etre portés sur x86) ce sont les drivers non inclus dans la distrib open source de Darwin, et les optimisations spécifiques altivec par exemple, qui sont dans Cocoa, Carbon, etc. Le reste c'est du C / Objective-C / Obj-C++ tout ce qu'il y a de plus classique et qu'il suffit de recompiler sur x86. Et ca c'est pas grand chose à faire, vu que GCC existe sur x86.
Ou bien me trompe-je ?
LaP
Patrick Stadelmann
In article <42a961eb$0$31018$, Laurent PERON wrote:
Les seuls choses qui manquent (et qui doivent etre portés sur x86) ce sont les drivers non inclus dans la distrib open source de Darwin, et les optimisations spécifiques altivec par exemple, qui sont dans Cocoa, Carbon, etc. Le reste c'est du C / Objective-C / Obj-C++ tout ce qu'il y a de plus classique et qu'il suffit de recompiler sur x86. Et ca c'est pas grand chose à faire, vu que GCC existe sur x86.
Ou bien me trompe-je ?
Même avec du bête code algorithmique, le passage de PC à Mac n'est pas toujours évident. Compiler le soft c'est une chose, encore faut-il qu'il fonctionne correctement, ça n'est pas immédiat. Et il faut aussi que les performances soient correctes. Souvent on peut implémenter une même fonctionnalité de différentes manières. L'approche la plus performante sur un processeur n'est pas forcément la même sur un autre. Et rien que réoptimiser pour SSE au lieu d'AltiVec, c'est un sacré boulot.
Patrick -- Patrick Stadelmann
In article <42a961eb$0$31018$636a15ce@news.free.fr>,
Laurent PERON <laurent_point_peron_point_lap@free.fr> wrote:
Les seuls choses qui manquent (et qui doivent etre portés sur x86)
ce sont les drivers non inclus dans la distrib open source de Darwin,
et les optimisations spécifiques altivec par exemple, qui sont
dans Cocoa, Carbon, etc. Le reste c'est du C / Objective-C / Obj-C++
tout ce qu'il y a de plus classique et qu'il suffit de recompiler
sur x86. Et ca c'est pas grand chose à faire, vu que GCC existe
sur x86.
Ou bien me trompe-je ?
Même avec du bête code algorithmique, le passage de PC à Mac n'est pas
toujours évident. Compiler le soft c'est une chose, encore faut-il qu'il
fonctionne correctement, ça n'est pas immédiat. Et il faut aussi que les
performances soient correctes. Souvent on peut implémenter une même
fonctionnalité de différentes manières. L'approche la plus performante
sur un processeur n'est pas forcément la même sur un autre. Et rien que
réoptimiser pour SSE au lieu d'AltiVec, c'est un sacré boulot.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <42a961eb$0$31018$, Laurent PERON wrote:
Les seuls choses qui manquent (et qui doivent etre portés sur x86) ce sont les drivers non inclus dans la distrib open source de Darwin, et les optimisations spécifiques altivec par exemple, qui sont dans Cocoa, Carbon, etc. Le reste c'est du C / Objective-C / Obj-C++ tout ce qu'il y a de plus classique et qu'il suffit de recompiler sur x86. Et ca c'est pas grand chose à faire, vu que GCC existe sur x86.
Ou bien me trompe-je ?
Même avec du bête code algorithmique, le passage de PC à Mac n'est pas toujours évident. Compiler le soft c'est une chose, encore faut-il qu'il fonctionne correctement, ça n'est pas immédiat. Et il faut aussi que les performances soient correctes. Souvent on peut implémenter une même fonctionnalité de différentes manières. L'approche la plus performante sur un processeur n'est pas forcément la même sur un autre. Et rien que réoptimiser pour SSE au lieu d'AltiVec, c'est un sacré boulot.
Patrick -- Patrick Stadelmann
pdorange
Laurent PERON wrote:
surtout qu'il a gardé en interne depuis le début de MacOS X Rapshody une équipe d'ingénieurs chargé de maintenir une version Intel d'OS X. Lors
J'ai l'impression que beaucoup sont étonnés d'apprendre que OSX marche sur x86. Darwin, qui est open source, est compilable depuis longtemps (depuis toujours ?) sur x86, ya rien de nouveau la dedans.
D'autant que on sait aussi qu'avant la finale 10.0, les alpha et beta était livrés aux développeurs pour PowerPC et x86/PC. A cette époque il y avait aussi la RedBox, censé faire tourner les logiciels Windows dans MacOS X.
Ensuite Apple a officiellement abandonner macOS X pour PC avant la sortie de la 10.0 pour officiellement des couts de développements trop élevé. On sait maintenant que c'est faux, puisque Steve nous a annoncé que Apple n'avait jamais cessé de maintenir la compatibilité a tout les stades de MacOS X...
De plus durant cette période, plusieurs fois les rumeurs sont revenus sur le tapis comme quoi Apple avait des PC avec MacOS X dans ces labos.
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime <http://alcazar.xbecom.com/videogarage/> Clarus, the DogCow <http://clarus.chez.tiscali.fr/>
surtout qu'il a gardé en interne depuis le début de MacOS X Rapshody une
équipe d'ingénieurs chargé de maintenir une version Intel d'OS X. Lors
J'ai l'impression que beaucoup sont étonnés d'apprendre que OSX marche
sur x86. Darwin, qui est open source, est compilable depuis longtemps
(depuis toujours ?) sur x86, ya rien de nouveau la dedans.
D'autant que on sait aussi qu'avant la finale 10.0, les alpha et beta
était livrés aux développeurs pour PowerPC et x86/PC.
A cette époque il y avait aussi la RedBox, censé faire tourner les
logiciels Windows dans MacOS X.
Ensuite Apple a officiellement abandonner macOS X pour PC avant la
sortie de la 10.0 pour officiellement des couts de développements trop
élevé.
On sait maintenant que c'est faux, puisque Steve nous a annoncé que
Apple n'avait jamais cessé de maintenir la compatibilité a tout les
stades de MacOS X...
De plus durant cette période, plusieurs fois les rumeurs sont revenus
sur le tapis comme quoi Apple avait des PC avec MacOS X dans ces labos.
--
Pierre-Alain Dorange
Vidéo, DV et QuickTime <http://alcazar.xbecom.com/videogarage/>
Clarus, the DogCow <http://clarus.chez.tiscali.fr/>
surtout qu'il a gardé en interne depuis le début de MacOS X Rapshody une équipe d'ingénieurs chargé de maintenir une version Intel d'OS X. Lors
J'ai l'impression que beaucoup sont étonnés d'apprendre que OSX marche sur x86. Darwin, qui est open source, est compilable depuis longtemps (depuis toujours ?) sur x86, ya rien de nouveau la dedans.
D'autant que on sait aussi qu'avant la finale 10.0, les alpha et beta était livrés aux développeurs pour PowerPC et x86/PC. A cette époque il y avait aussi la RedBox, censé faire tourner les logiciels Windows dans MacOS X.
Ensuite Apple a officiellement abandonner macOS X pour PC avant la sortie de la 10.0 pour officiellement des couts de développements trop élevé. On sait maintenant que c'est faux, puisque Steve nous a annoncé que Apple n'avait jamais cessé de maintenir la compatibilité a tout les stades de MacOS X...
De plus durant cette période, plusieurs fois les rumeurs sont revenus sur le tapis comme quoi Apple avait des PC avec MacOS X dans ces labos.
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime <http://alcazar.xbecom.com/videogarage/> Clarus, the DogCow <http://clarus.chez.tiscali.fr/>
Grrrr
On Fri, 10 Jun 2005 12:09:19 +0200, Patrick Stadelmann wrote:
In article <42a961eb$0$31018$, Laurent PERON wrote:
Les seuls choses qui manquent (et qui doivent etre portés sur x86) ce sont les drivers non inclus dans la distrib open source de Darwin, et les optimisations spécifiques altivec par exemple, qui sont dans Cocoa, Carbon, etc. Le reste c'est du C / Objective-C / Obj-C++ tout ce qu'il y a de plus classique et qu'il suffit de recompiler sur x86. Et ca c'est pas grand chose à faire, vu que GCC existe sur x86.
Ou bien me trompe-je ?
Même avec du bête code algorithmique, le passage de PC à Mac n'est pas toujours évident. Compiler le soft c'est une chose, encore faut-il qu'il fonctionne correctement, ça n'est pas immédiat.
Il n'est pas si difficile de faire du code portable et utilisable pour toutes les architectures communes (x86, PPC, ARM, MIPS, sh, par ex). Les problèmes se situent généralement dans le noyau et la libc. Pour le reste, si on code pas trop crade, il suffit généralement de recompiler.
Et il faut aussi que les performances soient correctes. Souvent on peut implémenter une même fonctionnalité de différentes manières. L'approche la plus performante sur un processeur n'est pas forcément la même sur un autre.
Bien sur, du code portable ne sera jamais optimisé à fond pour aucune architecture. Mais, à ce jour, on ne connait pas d'autre moyen que d'écrire le code à la main en assembleur, pour celà. On obtient des performances correctes en utilisant correctement un compilateur C. C'est là qu'il faut bien maitriser les options de compil...
Et rien que réoptimiser pour SSE au lieu d'AltiVec, c'est un sacré boulot.
Non. C'est à ça que servent les librairies. Il faut écrire la lib une fois pour chaque architecture, et l'utiliser dans les programmes. Ca localise les problèmes et les rends très simple à résoudre (une telle lib est généralement assez petite pour être portée en très peu de temps sur une nouvelle architecture).
On Fri, 10 Jun 2005 12:09:19 +0200, Patrick Stadelmann wrote:
In article <42a961eb$0$31018$636a15ce@news.free.fr>,
Laurent PERON <laurent_point_peron_point_lap@free.fr> wrote:
Les seuls choses qui manquent (et qui doivent etre portés sur x86)
ce sont les drivers non inclus dans la distrib open source de Darwin,
et les optimisations spécifiques altivec par exemple, qui sont
dans Cocoa, Carbon, etc. Le reste c'est du C / Objective-C / Obj-C++
tout ce qu'il y a de plus classique et qu'il suffit de recompiler
sur x86. Et ca c'est pas grand chose à faire, vu que GCC existe
sur x86.
Ou bien me trompe-je ?
Même avec du bête code algorithmique, le passage de PC à Mac n'est pas
toujours évident. Compiler le soft c'est une chose, encore faut-il qu'il
fonctionne correctement, ça n'est pas immédiat.
Il n'est pas si difficile de faire du code portable et utilisable pour
toutes les architectures communes (x86, PPC, ARM, MIPS, sh, par ex).
Les problèmes se situent généralement dans le noyau et la libc.
Pour le reste, si on code pas trop crade, il suffit généralement de
recompiler.
Et il faut aussi que les performances soient correctes. Souvent on peut
implémenter une même fonctionnalité de différentes manières.
L'approche la plus performante sur un processeur n'est pas forcément la
même sur un autre.
Bien sur, du code portable ne sera jamais optimisé à fond pour aucune
architecture. Mais, à ce jour, on ne connait pas d'autre moyen que
d'écrire le code à la main en assembleur, pour celà.
On obtient des performances correctes en utilisant correctement un
compilateur C. C'est là qu'il faut bien maitriser les options de compil...
Et rien que réoptimiser pour SSE au lieu d'AltiVec,
c'est un sacré boulot.
Non. C'est à ça que servent les librairies. Il faut écrire la lib une
fois pour chaque architecture, et l'utiliser dans les programmes.
Ca localise les problèmes et les rends très simple à résoudre (une
telle lib est généralement assez petite pour être portée en très peu
de temps sur une nouvelle architecture).
On Fri, 10 Jun 2005 12:09:19 +0200, Patrick Stadelmann wrote:
In article <42a961eb$0$31018$, Laurent PERON wrote:
Les seuls choses qui manquent (et qui doivent etre portés sur x86) ce sont les drivers non inclus dans la distrib open source de Darwin, et les optimisations spécifiques altivec par exemple, qui sont dans Cocoa, Carbon, etc. Le reste c'est du C / Objective-C / Obj-C++ tout ce qu'il y a de plus classique et qu'il suffit de recompiler sur x86. Et ca c'est pas grand chose à faire, vu que GCC existe sur x86.
Ou bien me trompe-je ?
Même avec du bête code algorithmique, le passage de PC à Mac n'est pas toujours évident. Compiler le soft c'est une chose, encore faut-il qu'il fonctionne correctement, ça n'est pas immédiat.
Il n'est pas si difficile de faire du code portable et utilisable pour toutes les architectures communes (x86, PPC, ARM, MIPS, sh, par ex). Les problèmes se situent généralement dans le noyau et la libc. Pour le reste, si on code pas trop crade, il suffit généralement de recompiler.
Et il faut aussi que les performances soient correctes. Souvent on peut implémenter une même fonctionnalité de différentes manières. L'approche la plus performante sur un processeur n'est pas forcément la même sur un autre.
Bien sur, du code portable ne sera jamais optimisé à fond pour aucune architecture. Mais, à ce jour, on ne connait pas d'autre moyen que d'écrire le code à la main en assembleur, pour celà. On obtient des performances correctes en utilisant correctement un compilateur C. C'est là qu'il faut bien maitriser les options de compil...
Et rien que réoptimiser pour SSE au lieu d'AltiVec, c'est un sacré boulot.
Non. C'est à ça que servent les librairies. Il faut écrire la lib une fois pour chaque architecture, et l'utiliser dans les programmes. Ca localise les problèmes et les rends très simple à résoudre (une telle lib est généralement assez petite pour être portée en très peu de temps sur une nouvelle architecture).
Patrick Stadelmann
In article , Grrrr wrote:
Il n'est pas si difficile de faire du code portable et utilisable pour toutes les architectures communes (x86, PPC, ARM, MIPS, sh, par ex).
"pas si difficile" ne veut pas dire facile. Ton code théoriquement portable aura en fait des bugs qui n'apparaîtront qu'à l'exécution sur une autre plateforme. Il ne suffit donc pas d'écrire du code portable, il faut encore le tester et le débugger sur l'autre plateforme.
Les problèmes se situent généralement dans le noyau et la libc. Pour le reste, si on code pas trop crade, il suffit généralement de recompiler.
En général, oui. Mais il y a plein de cas particulier où le comportement sera différent. Dès que tu bosses avec des nombres flottant par exemple, le code donnera facilement des résultats différents.
Et rien que réoptimiser pour SSE au lieu d'AltiVec, c'est un sacré boulot.
Non. C'est à ça que servent les librairies. Il faut écrire la lib une fois pour chaque architecture, et l'utiliser dans les programmes.
Dans la cas du port de Mac OS X sur Intel, il a bien fallu réécrire cette librairie !
Ca localise les problèmes et les rends très simple à résoudre (une telle lib est généralement assez petite pour être portée en très peu de temps sur une nouvelle architecture).
Selon le niveau d'optimisation recherché, pour du code vectoriel, non.
Patrick -- Patrick Stadelmann
In article <pan.2005.06.10.11.10.41.622944@Grrr.org.invalid>,
Grrrr <Grrr@Grrr.org.invalid> wrote:
Il n'est pas si difficile de faire du code portable et utilisable pour
toutes les architectures communes (x86, PPC, ARM, MIPS, sh, par ex).
"pas si difficile" ne veut pas dire facile. Ton code théoriquement
portable aura en fait des bugs qui n'apparaîtront qu'à l'exécution sur
une autre plateforme. Il ne suffit donc pas d'écrire du code portable,
il faut encore le tester et le débugger sur l'autre plateforme.
Les problèmes se situent généralement dans le noyau et la libc.
Pour le reste, si on code pas trop crade, il suffit généralement de
recompiler.
En général, oui. Mais il y a plein de cas particulier où le comportement
sera différent. Dès que tu bosses avec des nombres flottant par exemple,
le code donnera facilement des résultats différents.
Et rien que réoptimiser pour SSE au lieu d'AltiVec,
c'est un sacré boulot.
Non. C'est à ça que servent les librairies. Il faut écrire la lib une
fois pour chaque architecture, et l'utiliser dans les programmes.
Dans la cas du port de Mac OS X sur Intel, il a bien fallu réécrire
cette librairie !
Ca localise les problèmes et les rends très simple à résoudre (une
telle lib est généralement assez petite pour être portée en très peu
de temps sur une nouvelle architecture).
Selon le niveau d'optimisation recherché, pour du code vectoriel, non.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Il n'est pas si difficile de faire du code portable et utilisable pour toutes les architectures communes (x86, PPC, ARM, MIPS, sh, par ex).
"pas si difficile" ne veut pas dire facile. Ton code théoriquement portable aura en fait des bugs qui n'apparaîtront qu'à l'exécution sur une autre plateforme. Il ne suffit donc pas d'écrire du code portable, il faut encore le tester et le débugger sur l'autre plateforme.
Les problèmes se situent généralement dans le noyau et la libc. Pour le reste, si on code pas trop crade, il suffit généralement de recompiler.
En général, oui. Mais il y a plein de cas particulier où le comportement sera différent. Dès que tu bosses avec des nombres flottant par exemple, le code donnera facilement des résultats différents.
Et rien que réoptimiser pour SSE au lieu d'AltiVec, c'est un sacré boulot.
Non. C'est à ça que servent les librairies. Il faut écrire la lib une fois pour chaque architecture, et l'utiliser dans les programmes.
Dans la cas du port de Mac OS X sur Intel, il a bien fallu réécrire cette librairie !
Ca localise les problèmes et les rends très simple à résoudre (une telle lib est généralement assez petite pour être portée en très peu de temps sur une nouvelle architecture).
Selon le niveau d'optimisation recherché, pour du code vectoriel, non.
Patrick -- Patrick Stadelmann
serge
Pierre-Alain Dorange wrote:
De plus durant cette période, plusieurs fois les rumeurs sont revenus sur le tapis comme quoi Apple avait des PC avec MacOS X dans ces labos.
Mais ces rumeurs ne sont pas allées très loin tant la transition paraissait impensable. Le plus gros obstacle était la compatibilité des applis PowerPC : autant le principe des binaires universelles FAT est connu depuis longtemps, autant Rosetta est la vraie nouveauté qui rend la transition réaliste.
Et la boîte qui a développé Rosetta (chez eux QuickTransit) a deux dirigeants anciens de NeXT... comme quoi on reste vraiment entre connaissances.
Comme dirait Cringely: NeXT rachète Apple, Appl^W NeXT fusionne avec Intel, Intel se libère de son couple avec MS, fin de la domination de Microsoft.
De plus durant cette période, plusieurs fois les rumeurs sont revenus
sur le tapis comme quoi Apple avait des PC avec MacOS X dans ces labos.
Mais ces rumeurs ne sont pas allées très loin tant la transition
paraissait impensable. Le plus gros obstacle était la compatibilité des
applis PowerPC : autant le principe des binaires universelles FAT est
connu depuis longtemps, autant Rosetta est la vraie nouveauté qui rend
la transition réaliste.
Et la boîte qui a développé Rosetta (chez eux QuickTransit) a deux
dirigeants anciens de NeXT... comme quoi on reste vraiment entre
connaissances.
Comme dirait Cringely: NeXT rachète Apple, Appl^W NeXT fusionne avec
Intel, Intel se libère de son couple avec MS, fin de la domination de
Microsoft.
De plus durant cette période, plusieurs fois les rumeurs sont revenus sur le tapis comme quoi Apple avait des PC avec MacOS X dans ces labos.
Mais ces rumeurs ne sont pas allées très loin tant la transition paraissait impensable. Le plus gros obstacle était la compatibilité des applis PowerPC : autant le principe des binaires universelles FAT est connu depuis longtemps, autant Rosetta est la vraie nouveauté qui rend la transition réaliste.
Et la boîte qui a développé Rosetta (chez eux QuickTransit) a deux dirigeants anciens de NeXT... comme quoi on reste vraiment entre connaissances.
Comme dirait Cringely: NeXT rachète Apple, Appl^W NeXT fusionne avec Intel, Intel se libère de son couple avec MS, fin de la domination de Microsoft.
