Ils n'aiment pas Mac OS X: Changement d'opinion...

  • Créateur du sujet Créateur du sujet Membre supprimé 2
  • Date de début Date de début
Et j'en rajoute une couche Joey sur quelque chose que je connais parfaitement puisque je te le rappelle je suis moi même développeur.
Si MacOSX est largement plus lent dans sa version beta que dans sa version finale la raison en est le code de déboguage qui 1) charge la mémoire, 2) demande du temps de traitement, 3) empêche l'optimisation complète du code objet. Moi même mes programmes avec code de déboguage sont entre 2 et 3 fois plus gros, et tournent également 2 à 3 fois moins vite que le code final ...

Tu n'arrives pas à faire tourner tes progs MacOSX sur autre chose que le volume MacOSX ! Encore heureux ... Le gestionnaire de MacOS9 est bien incapable de lancer une appli MacOSX ! Comme tu ne peux lancer un prog W95 sous W3.11. Le FileSystem est compatible de manière descendante, pas ascendante ...
Quand à l'interface, beaucoup d'utilisateurs déçus au départ, on déjà fait marche arrière. Non seulement on va s'habituer à MacOSX très vite, mais en plus on voudra plus revenir en arrière, après quelques temps d'utilisation. Le progrès c'est toujours comme çà. Encore un exemple Windows. Quand W95 est sorti, plein de monde sur PC a dit que l'interface était nulle, que 3.11 c'était plus souple (???), etc ... Moi en tant qu'Amigaïste habitué de l'interface 3.11 et du WorkBench (bureau de l'Amiga que W95 a copié), je me marrais. Combien de gens reviendrais à W3.11 pour l'interface aujourd'hui ?
Non franchement, je jongle avec minimum
6 systèmes d'exploitation chaque semaine (OS400, Linux, AmigaOS, MacOS, W95/98, NT), et je t'affirmes que MacOSX va faire mal. Il est plus rapide que tous (sauf AmigaOS), plus stable (sauf OS400), son interface est la mieux concue, et la plus évolutive (eh oui). Quand à sa consommation mémoire, 64 Mo sont suffisants en environnement natif dans la version beta, et seront donc plus que suffisant dans la version finale qui sans le code de déboguage, sera forcément plus légère.
Pour finir, réussir à concilier un système aussi puissant avec une interface aussi souple (tu n'as pas du en explorer toutes les possibilités), qui va permettre aux développeurs de créer des super softs rapidement, et avec une réelle aisance, moi je pense au contraire, que les gars d'Apple ont fait un super boulot. Moi je leur tire mon chapeau, et j'espère pouvoir bientôt vous livrer des programmes qui tireront parti des merveilleuses possibilités qu'offre ce système.
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par JackSim:
Relis la news, la résolution est donnée. Et c'est pas du 320x240.

<HR></BLOCKQUOTE>

Oui mais là MOSR a encore fumé sa moquette.
Une MX est incapable de sortir 150 FPS à Q3 en 1280x1024.
T'aura beau lui mettre un bi-G4, un quadri-athlon 1Ghz ou un octo-alpha aux fesses, le chip graphique ne peut pas afficher à cette cadence.
C'est même au delà des capacités intrinsèques de la plus performante des cartes nvidia du marché qui est quand même plus de 2x plus rapide que la MX.
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par HURRICAN:
Si MacOSX est largement plus lent dans sa version beta que dans sa version finale la raison en est le code de déboguage qui 1) charge la mémoire, 2) demande du temps de traitement, 3) empêche l'optimisation complète du code objet. Moi même mes programmes avec code de déboguage sont entre 2 et 3 fois plus gros, et tournent également 2 à 3 fois moins vite que le code final ...<HR></BLOCKQUOTE>

Pour la beta, ils avaient déjà dit qu'il avaient viré une bonne partie du code de déboguage.
Par ailleurs, je ne crois pas trop à ce genre de chose, car c'est franchement pas compliqué de faire une build sans les infos de déboguage... je pense plutot qu'ils ont trouvé ça de mieux comme leurre pour expliquer la lenteur / lourdeur générale de MacOS X, alors que c'est du à autre chose.

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Tu n'arrives pas à faire tourner tes progs MacOSX sur autre chose que le volume MacOSX ! Encore heureux ... Le gestionnaire de MacOS9 est bien incapable de lancer une appli MacOSX ! Comme tu ne peux lancer un prog W95 sous W3.11. Le FileSystem est compatible de manière descendante, pas ascendante ...<HR></BLOCKQUOTE>

Relis mon poste, je ne parle absolument pas de ça. Ca n'a rien à voir. Je vois pas non plus ce que le file system vient faire la dedans: c'est du HFS+ dans les 2 cas
wink.gif
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par Albert:
Oui mais là MOSR a encore fumé sa moquette.
Une MX est incapable de sortir 150 FPS à Q3 en 1280x1024.
<HR></BLOCKQUOTE>

Bien vu, j'avais meme pas fait attention
wink.gif


ca fait tout juste:
1280*1024*4*150/(1024*1024) = 750Mb/s de débit de données au niveau de la carte 3D... de toute façon, c'est un non sens total vu que l'écran est surement pas à 150Hz.
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par Joey:
Pour la beta, ils avaient déjà dit qu'il avaient viré une bonne partie du code de déboguage.<HR></BLOCKQUOTE>

Ben moi j'ai toujours lu et entendu le contraire. Et une beta ça sert à çà justement. On y met des lignes de code pour pouvoir tracer les erreurs et les corriger dans la version finale. C'est un peu comme si lors d'un crashtest, on enlevait les capteurs pour allèger la voiture ...

Pour la vitesse de l'interface, il est aussi à signaler que tu peux désactiver les effets gourmands. Tu obtiens alors quelque chose d'aussi rapide que MacOS9.

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
Relis mon poste, je ne parle absolument pas de ça. Ca n'a rien à voir. Je vois pas non plus ce que le file system vient faire la dedans: c'est du HFS+ dans les 2 cas
<HR></BLOCKQUOTE>

Désolé si je n'ai pas compris le sens de ta phrase. Je l'ai relu, et je comprends toujours la même chose. Peux tu expliquer autrement et plus en détail ce qui t'arrives ?
Et je vais reprendre les docs techniques, mais à moins que je sois fou, le FileSystem a bel et bien changé. MacOSX est un Unix ...
 
Moi j'ai pré-commandé ma version X et je l'attend avec impatience.
Apple a tenu compte des diverses observations (menu Pomme, finder etc...) et ça c'est déjà génial.
Quand les programmeurs utiliseront tous "Cocoa", on aura des logiciels pro, performants et vite développés.
Une fois que l'on a compris le mécanisme de cocoa et de l'OS on se rend compte à quel point ce système a été pensé dans les moindres détails.
Tout le reste est littérature...

------------------
+
MacFervent
+
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR> Désolé si je n'ai pas compris le sens de ta phrase. Je l'ai relu, et je comprends toujours la même chose. Peux tu expliquer autrement et plus en détail ce qui t'arrives ?<HR></BLOCKQUOTE>

Je dis simplement que t'as pas du tout de souplesse niveau gestion des fichiers avec ce système: par ex, si tu essais d'installer les outils developpeurs sur un autre disque que celui de MacOS X, il n'y a plus rien qui marche (je l'ai fait parce que je n'avais plus de place sur le disque MacOS X). Et c'est n'importe quoi parce que l'installateur m'autorise à installer sur un autre disque justement. C'est comme si si tu essayais d'installer Photoshop sur un autre disque que celui de démarrage et qu'il refuse de fonctionner: inadmissible (pour un utilisateur mac évidemment, pour les PCistes...). Et des exemples comme ça, il y en a pleins. C'est pour ça que je dis qu'on fait un retour en arrière en ce qui concerne tout ce qui fait la spécifité et la puissance d'utilisation du mac.

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Et je vais reprendre les docs techniques, mais à moins que je sois fou, le FileSystem a bel et bien changé. MacOSX est un Unix ... <HR></BLOCKQUOTE>

Oui et non: MacOS X peut tourner sur des disques UFS ou HFS+, mais c'est évident qu'il faut prendre HFS+, pour avoir moins de problèmes avec les fichiers multi-forks, vu que les autres file systems ne supportent pas ça en natif.
 
Il est tout à fait possible de faire du 150 FPS en utilisant la version 1.27h de Q3 qui n'est pas encore disponible puisque celle ci utilise à la fois les deux processeurs, mais aussi les moteurs Altivec (au nombre de 4 dans ke 733
smile.gif
)
donc je pense, que c'est possible, mais quel intérêt de faire un test sur un bi-733 puisque qu'ils ne seront pas commercialisés ?
 
Ton problème d'outils déplacés ne fonctionnant plus, ressemble plutôt à un problème avec ces outils, et pas avec l'OS. Je paries qu'il va chercher un fichier qui devrait se trouver sur le même volume que lui, et que forcément il ne trouve pas, car planqué dans un répertoire système. On peut se poser une question déjà. As tu installé ces outils sur une partition OS9 système, ou sur une partition sans système. Je pense que sans système il ne devrait pas y avoir de problèmes. Avec, il se pourrait que HFS+ ailles chercher le premier répertoire système ...
Toutefois il peut s'agir également d'un bug de la version beta. Il faudrait consulter les forums MacOSX pour voir si quelqu'un a soulevé le problème.
Mais encore une fois, je t'affirme que la souplesse n'est pas là où tu le crois. Preuve en est les modifications déjà apportées par Apple.
Je voudrais que l'on regarde les choses en face. Combien de temps MacOS9 a t-il mis pour devenir ce qu'il est ? N'oublions pas que son code devient ingérable, et par conséquent buggué et peu stable, et qu'il est très gourmand au regard de ces capacités (l'Amiga fait mieux avec un système tenant en 512 Ko !). MacOSX est un système reprenant des fondements stables, connus, et évolutifs. Pour ces capacités il n'est pas plus goumand que la moyenne, et son code neuf et donc propre, va permettre de le faire avancer très rapidement. Je vois vraiment pas ce qui pourrait empêcher MacOSX de supplanter MacOS9 en quelques mois. Il n'a pratiquement que des avantages.
J'allais oublier, les softs adaptés pour MacOSX, tournent nettement plus vite que leurs homologues prévus pour MacOS9, y compris et surtout au niveau de l'interface graphique (même sur un iMac G3/350 ...). Le G4 permettant d'aller plus vite sous OSX ? Encore heureux ! Ils vont quand même pas délaisser le surplus de puissance que fournit l'Altivec du G4 sous prétexte que plein de monde a encore un G3 ! C'est ce qu'on appelle l'optimisation ...
 
Le test aurait été fait avec une Geforce2 Ultra, j'aurais sans doute accepté, mais avec une MX, ce n'est vraiment pas possible.
 
La vitesse du test Q3 ?
P'tet ben que oui, p'tet ben que non, je serais normand là dessus.
La Mx est incapable de gèrer çà seule c'est sûr.
La carte s'adapte peut être également mieux à la structure du Mac et ses performances sont donc peut être supérieure à celle obtenues dans un PC.
Il est un fait, l'Altivec et le G4 avec ses 5,5 Gigaflops est capable de soulager la carte d'une partie des calculs. Il faut que le programme ait été optimisé pour çà et cela semble être le cas.
M'enfin je doute quand même.
J'aimerais voir les caractéristiques complètes du test, pour y croire.
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>La carte s'adapte peut être également mieux à la structure du Mac et ses performances sont donc peut être supérieure à celle obtenues dans un PC.<HR></BLOCKQUOTE>

Je pense pas. A vrai dire, ça m'étonnerait beaucoup, car les PC ont beaucoup d'avance sur les Macs niveau cartes 3D. Cela dit, comme j'ai fait le calcul plus tot, si l'on suppose que le frameBuffer est rafraichi 150 fois par secondes sur 1280x1024, ça nous fait 700Mb/s de données dans la carte - j'y crois pas
01E20700 trop.

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Il est un fait, l'Altivec et le G4 avec ses 5,5 Gigaflops est capable de soulager la carte d'une partie des calculs. Il faut que le programme ait été optimisé pour çà et cela semble être le cas.<HR></BLOCKQUOTE>

5,5 gigaflops... faut pas dire n'importe quoi, c'est le maximum théorique: donc impossible à atteindre! En moyenne, on est très loin de ça. Et encore ça suppose que l'unité Altivec est utilisée à fond. Ce qui est impossible dans un jeu. Il y a simplement des parties du code qui ne peuvent pas être écrite / optimisée en Altivec!

Les 5,5 gigaflops, tu les atteindrais peut-être dans le cas d'une simple multiplication matricielle sur un paquet de vecteurs, mais bon, ça supposerait encore que le processeur ne fasse que ça, ce qui est impossible, vu qu'il y a les interruptions, le multithreading... et donc le processeur jongle en permanence entre plusieurs bouts de code, et à chaque fois qu'il passe dans un autre bout de code, le pipelining est forcément cassé, les caches sont flushés...
 
Ben non, ce n'est pas la carte qui fait tout, c'est sur qu'il est impossible d'atteindre du 700%b/s, c'est aussi sur que la GeForce 2MX ne puissent atteindre le 150FPS toute seul, mais avec la puissance d'altivec et de deux G4, même si on est loin du 5,5 Gigaflops, ce qui me parait évident qu'on ne puissenbt pas l'atteindre avec un jeu, je trouve qu'il est probable qu'on puissent atteindre les 150FPS
smile.gif
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>
Je pense pas. A vrai dire, ça m'étonnerait beaucoup, car les PC ont beaucoup d'avance sur les Macs niveau cartes 3D. Cela dit, comme j'ai fait le calcul plus tot, si l'on suppose que le frameBuffer est rafraichi 150 fois par secondes sur 1280x1024, ça nous fait 700Mb/s de données dans la carte - j'y crois pas
<HR></BLOCKQUOTE>

Ca n'a rien à voir ! Les PC disposent de cartes graphiques plus puissantes comme la Ge2GX d'accord, mais une même carte peut parfaitement s'accorder dans un Mac et pas dans un PC. Regardes, tous les tests qui ont comparer les perfs de Q3 avec une Ge2MX contre une ATI Radéon, ont souvent mis un PC équipé de la même Ge2MX comme 'base'. Et ben le PC se fait bouffer ... La carte 3D n'est pas le seul élément entrant en compte dans la rapidité !
Quand aux 5,5 Gigaflops, bien sûr qu'ils sont théoriques, mais en admettant que 10% de la puissance soit perdue en swap, etc..., il reste encore 5 Gigaflops ! As tu déjà fait tourner UT en software sur un G4/500 (donc sans optimisation Altivec )? Tu serais étonné du résultat. Bien sûr on a pas la qualité obtenue avec une carte 3D, mais il obtient déjà d'excellent résultats !
J'imagines ce que peux donner un 733 sur un bus plus rapide, et avec 4 Altivec utilisés !

Ce qui me mets le doute moi, c'est qu'on est à la limite de la bande passante transitant à travers la carte, pas la capacité de calculs.
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par [MGZ]Toine:
Ben non, ce n'est pas la carte qui fait tout, c'est sur qu'il est impossible d'atteindre du 700%b/s, c'est aussi sur que la GeForce 2MX ne puissent atteindre le 150FPS toute seul, mais avec la puissance d'altivec et de deux G4, même si on est loin du 5,5 Gigaflops, ce qui me parait évident qu'on ne puissenbt pas l'atteindre avec un jeu, je trouve qu'il est probable qu'on puissent atteindre les 150FPS
smile.gif
<HR></BLOCKQUOTE>

Non, un moteur 3D, c'est plus de 80% de temps de temps de dessin, donc dans la carte 3D et le reste seulement dans le processeur. Et ça va encore augmenter avec le T&L dans le but de soulager encore plus le processeur justement.

L'altivec ne soulage pas la carte 3D: ce serait comme dire qu'il soulage le modem: aucun rapport entre les 2. L'Altivec peut accélérer les calculs d'OpenGL, mais ne va pas accélérer le rasterizer de la carte: impossible! Et meme s'il pouvait le faire, ce serait un non sens puisqu'il faudrait transferrer des montagnes de données sur le bus depuis le processeur vers la carte et en plus si l'unité Altivec devait travailler sur la VRAM de la carte, elle serait complètement bridée vu que la VRAM est très lente d'accès en lecture (meme sur AGP).

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par HURRICAN:
Quand aux 5,5 Gigaflops, bien sûr qu'ils sont théoriques, mais en admettant que 10% de la puissance soit perdue en swap, etc..., il reste encore 5 Gigaflops !<HR></BLOCKQUOTE>

10%, tu rigoles? Et le pipelining qui saute avec les instructions de branchement, et le chargement des données dans les caches, et le transfert en mémoire, le chargement dans les registres, etc, etc...? Ces 5 gigaflops, c'est si le processeur fonctionne tout seul et avec toutes ses données accessibles immédiatement, et c'est pas possible dans 95% des cas en pratique.

HURRICAN a dit:
J'imagines ce que peux donner un 733 sur un bus plus rapide, et avec 4 Altivec utilisés !

Mais c'est un non sens total!!! L'unité Altivec est une unité de calcul mathématique! Il y a plein de code qui ne peut pas être optimisé Altivec! Le code réseau, le code audio par ex. En plus les données doivent être dans un certain format pour pouvoir être utilisées par l'Altivec. Et en plus t'as tous les problèmes d'interdépendance des données: dans un moteur 3D par exemple, tu ne peux pas commencer à calculer les projections avant d'avoir fait les transformations des modèles. C'est pas parce que tu mets 4 unités en parallèles que tu vas aller 4 fois plus vite.

Le seul cas ou tu pourras peut-être t'approcher de ce 4 fois, ce sera par exemple en transformant 4 modèles 3D en même temps (vu que ça c'est typiquement pour l'Altivec), et encore t'aurais très probablement un énorme goulot d'étranglement au niveau du bus ce qui briderait les unités Altivec (et toute façon le cache servira pas à grand chose, vu que de toute façon, toutes les données 3D ne rentreront pas dedans, donc tout son contenu sera effacé puis rechargé en permanence).

L'unité Altivec sert à faire des maths (éventuellement faire des transfert mémoire plus rapide par blocks de 128 bits)!! Donc pour les programmes de maths qui peuvent calculer beaucoup plus vite en traitant les données en parallèle, pour les filtres Photoshop où tu dois calculer pleins de pixels en même temps avec une même série d'opération. Tu vas dire que c'est justement ce que fait la carte 3D et que donc l'Altivec peut l'aider pour ça, mais non, pas possible, puisque:
1) elle a déjà des processeurs optimisés pour ça
2) l'Altivec, n'a de toute façon pas accès au données qui sont dans la mémoire de la carte, et même s'il essait de les lire, comme je l'ai dit plus haut, l'accès à la VRAM en lecture est toujous très lent
3) et même en passant les 2 conditions précédentes, en admettant que l'Altivec fasse le rasterizer, il faudrait ensuite transferrer le résultat sur le bus AGP à coup de 700Mb/s par ex, ce qui est ridicule.

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par HURRICAN:
As tu déjà fait tourner UT en software sur un G4/500 (donc sans optimisation Altivec )? Tu serais étonné du résultat. Bien sûr on a pas la qualité obtenue avec une carte 3D, mais il obtient déjà d'excellent résultats ! <HR></BLOCKQUOTE>

Ca marche aussi très bien sur un G3 500, le G4 n'a pas grand chose à voir la dedans. N'oublies pas que les tests sur les G4 sans altivec ont montré qu'il n'y avaient pas de différence flagrante avec les G3.

 
Ah oui, j'ajoute aussi que meme si un certain code peut être réécrit pour tirer profit d'Altivec, il faut encore que ça en vaille la peine i.e. que le programmeur ne passe pas 3h à réécrire toute la routine et les structures de données pour placer au final 10 instructions Altivec dedans. Parce que là, personne ne le fera même si c'est pour gagner 1ns.
Au cas ou tu ne l'aurais pas remarqué, les programmeurs de jeux n'ont simplement plus le temps d'optimiser leur code.
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par Joey!:
...C'est comme dire qu'Altivec soulage le modem...
<HR></BLOCKQUOTE>

Mais oui, il soulage le modem... en théorie, ALtivec peux émuler un modem à 45 Mbps...
grin.gif
lol...