PC ou MAC ?

[WBell]

Pour ma part, j'adore. Les premières semaines furent déroutantes mais ensuite que du bonheur: simplicime, intuitif, logique. Rien à voir avec l'abominable et illisible gestion des pointeurs du C, dont il est évidemment issu.

En fait, je me rend compte que coder, au lieu d'être un plaisir, se transforme vite en partie de "tu veux être plus malin que moi ? Tu vas voir !". Aujourd'hui, un compilateur te dit :

There is a semi-colon missing at the end of line 11456. Bleuargh. I won't compile your piece of shit.

J'aimerais tomber un jour sur un compilateur qui me dise :

There is a semi-colon missing at the end of line 11456. Would you like me to add it for you ? [Y]es/[N]o/ee the code

C'est à l'outil de suppléer au déficiences humaines, normalement. Pas l'inverse. On est encore dans la préhistoire de l'informatique. J'aimerais vivre dans 150 ans, juste pour voir ce que ça donnera sur les outils de "création de logiciels" .

[Noob]

A la limite objective-c pourquoi pas, mais s'il vous plait pourquoi quand on bosse dans le simulateur on a pas le même comportement que sur le téléphone.

- Deux différences disons surprenantes : Pas de garbage collector sur le téléphone.

- Système de fichier case sensitive sur l'iPhone et pas dans mac os X.

[Nicolas Azor]

Tu devrais essayer awesome.

9OnYBKZNHrs

[pankkake]

Système de fichier case sensitive sur l'iPhone et pas dans mac os X.

loooooooooooooooooooool

Tu devrais essayer awesome.

Ou n'importe quel WM, il sera mieux que celui de Mac OS. Quoique, il y a Unity maintenant qui doit arriver à faire pire !

[Nirvana]

Unity est très bien, je vois pas le problème. Celui qui est vraiment naze, c'est plutôt Gnome Shell.

Et les tiling WMs, non merci. J'ai besoin d'un truc familier, pas de m'afficher comme un £33T h4ckZ0Я.

[pankkake]

J'ai besoin d'un truc familier, pas de m'afficher

Je crois que tu fais un amalgame avec les utilisateurs de Mac.

Les tiling WM sont utilisés pour des raisons d'ergonomie, i.e. d'efficacité niveau interaction homme-machine.

[Rincevent]

Les disputes Maque/Zindoze/Nunuxe n'ont aucun intérêt. Ce n'est pas moi qui le dit, c'est Jeff.

[pankkake]

Je ne vais certainement pas m'opposer à cette position. Ce sont juste des ordinateurs qui n'ont rien de magique.

[Nirvana]

Linus Torvalds isn't someone you'd accuse of excessive diplomacy and his answer to a question about Nvidia's lack of support for Linux with its Optimus technology has been far from compromising. When posed with that query during a Q&A session at Aalto University in Finland, Torvalds begins by identifying Nvidia as "the single worst company we've ever dealt with" and goes on to give his assessment of its actions with a resolute "fuck you" and an accompanying middle finger gesture to the camera.

The frustrated user of an Optimus laptop says that she finally got full support for her machine via a GitHub project that's been working decently well, but Linus evidently shares her annoyance at Nvidia's unwillingness to support the open source OS. He's particularly incensed by the fact Nvidia's Tegra line of ARM chips is selling so well because of Android, a mobile OS that has its roots in Linux. While Torvalds believes there's little we can do to influence Nvidia's decision making, he does see a silver lining in the fact that its attitude is "the exception rather than the rule."

Fast-forward to 49:30 in the video below for Linus' uncensored answer, though if you want to get a true picture of his perspective on hardware support and all other issues concerning open source development, you'd do well to watch the entire talk.

http://www.theverge.com/2012/6/17/3092829/linus-torvalds-fuck-you-nvidia

[Calembredaine]

- Système de fichier case sensitive sur l'iPhone et pas dans mac os X.

sur MacOX tu peux choisir. Pas défaut ce n'est pas case sensitive.

[Noob]

sur MacOX tu peux choisir. Pas défaut ce n'est pas case sensitive.

Oui oui je sais bien, n'empêche que lorsque tu touches un Mac pour la première fois de ta vie, devoir débuguer un truc qui passe dans le simulateur, mais fait crasher ton application sur le téléphone ça fait spécial.

[pankkake]

http://www.theverge.com/2012/6/17/3092829/linus-torvalds-fuck-you-nvidia

C'est une réaction sage et mesurée, par rapport certaines de ces précédentes

(Et amplement méritée de la part de nVidia. Il n'y en a plus chez moi.)

[Sloonz]

A la limite objective-c pourquoi pas, mais s'il vous plait pourquoi quand on bosse dans le simulateur on a pas le même comportement que sur le téléphone.

Parce que ce n’est pas un émulateur (comme le serait qemu), tout bêtement, c’est un portage de l’API iOS au dessus de celles de MacOS X. [troll]Ça permet d’éviter comme chez Android un temps de chargement de l’émulateur de 10 minutes.[/troll]

Mais je ne vois vraiment pas comment tu as réussi à activer le GC sous un environnement « iOS » par contre…

[Noob]

Parce que ce n’est pas un émulateur (comme le serait qemu), tout bêtement, c’est un portage de l’API iOS au dessus de celles de MacOS X. [troll]Ça permet d’éviter comme chez Android un temps de chargement de l’émulateur de 10 minutes.[/troll]

Mais je ne vois vraiment pas comment tu as réussi à activer le GC sous un environnement « iOS » par contre…

Oui oui je sais bien merci, mais pour le coup ce genre de surprise, ben c'est pas ce qu'il y a de mieux. Pourquoi ne pas avoir simplement la même convention sur les deux OS, hein pourquoi ? Ce serait trop simple ?

Sinon la surprise du ramasse miette, c'est bien qu'il disparaisse lorsque tu exécutes ton application dans iOS.

[Sloonz]

Oui oui je sais bien merci, mais pour le coup ce genre de surprise, ben c'est pas ce qu'il y a de mieux. Pourquoi ne pas avoir simplement la même convention sur les deux OS, hein pourquoi ? Ce serait trop simple ?

FS case-insensitive = le mal. Mal nécessaire pour MacOS X, par souci de compatibilité avec MacOS 9. Qui ne l’était pas sous iOS puisqu’ils n’avaient aucun souci de ce genre.

Sinon la surprise du ramasse miette, c'est bien qu'il disparaisse lorsque tu exécutes ton application dans iOS.

Non, la surprise c’est que tu aies réussi à le faire apparaître quand tu exécutes ton application dans l’« émulateur ».

[Calembredaine]

Sinon la surprise du ramasse miette, c'est bien qu'il disparaisse lorsque tu exécutes ton application dans iOS.

Cela dit, activer le ramasse miette pour une application iOS, ce n'est pas très malin vu la faible quantité de RAM des appareils. Il est nécessaire d'optimiser au max la gestion de la mémoire.

(je ne dirais pas la même chose quand on développe pour Mac)

[Noob]

Cela dit, activer le ramasse miette pour une application iOS, ce n'est pas très malin vu la faible quantité de RAM des appareils. Il est nécessaire d'optimiser au max la gestion de la mémoire.

(je ne dirais pas la même chose quand on développe pour Mac)

Petit bémol, c'est pas tant la quantité de RAM qui pose problème que les ressources CPU limitée, oui un garbage collector c'est pas gourmand en RAM, mais en CPU.

Qui ne l’était pas sous iOS puisqu’ils n’avaient aucun souci de ce genre.

Non, la surprise c’est que tu aies réussi à le faire apparaître quand tu exécutes ton application dans l’« émulateur ».

Je veux bien, mais ça moi je m'en fiche hein, c'était mon premier jour sous mac os, et je me suis emmerdé juste à cause de cette différence.

Pour le 2, c'est bien moi qui me suis planté, je lisais simplement un cours sur objective-c et quand j'ai appris que mon application fuyait, ben j'ai corrigé le tir, mais c'était pas non plus ce que j'attendais de la part du langage objective-c.

[Calembredaine]

Petit bémol, c'est pas tant la quantité de RAM qui pose problème que les ressources CPU limitée, oui un garbage collector c'est pas gourmand en RAM, mais en CPU.

Heu, on ne peut pas dire que la gestion de la RAM sous garbage collector soit vraiment optimisée.

Cela dit, si en plus tu juges son utilisation contraignante pour le CPU, je me demande pourquoi tu soulèves ce point précis.

Par ailleurs, je viens de vérifier: garbage collector n'est pas supporté quand on compile pour iOS, même en utilisant le simulateur. (Xcode 4.3.3)

Tu devrais mettre ta version de Xcode à jour, elle doit être très très vieille, je n'ai même pas souvenir que l'on ai pu un jour activer Garbage Collector dans ce contexte.

[Calembredaine]

quand j'ai appris que mon application fuyait, ben j'ai corrigé le tir, mais c'était pas non plus ce que j'attendais de la part du langage objective-c.

Garbage Collector, c'était une première tentative d'Apple pour aider les programmeurs à ne plus s'emmerder avec la gestion de la mémoire. Ce n'était pas très bien foutu.

Mais c'est vieux et cela ne s'utilise plus. Aujourd'hui, il suffit d'activer ARC (Automatic Reference Counting) pour ne plus avoir à gérer quoique ce soit. Et ça fonctionne très bien autant sous iOS que sous OSX

[Noob]

Heu, on ne peut pas dire que la gestion de la RAM sous garbage collector soit vraiment optimisée.

Cela dit, si en plus tu juges son utilisation contraignante pour le CPU, je me demande pourquoi tu soulèves ce point précis.

Par ailleurs, je viens de vérifier: garbage collector n'est pas supporté quand on compile pour iOS, même en utilisant le simulateur. (Xcode 4.3.3)

Tu devrais mettre ta version de Xcode à jour, elle doit être très très vieille, je n'ai même pas souvenir que l'on ai pu un jour activer Garbage Collector dans ce contexte.

Je te parle d'un temps que les moins de 4 ans ne peuvent pas connaître (août 2008 et iOS 2) , c'était tout juste à la sortie du 3G en Suisse.

Et ça fait longtemps que je n'y touche plus.

Ce que je souligne c'est que le langage changeait selon l'environnement que tu utilisais, point barre. D'un côté t'as un GC de l'autre t'as des free.

Ce qui est quand même un peu chiant, car ce n'est plus tout à fait le même langage. (Je considère que la gestion de la mémoire fait partie du langage)

Et sinon je ne comprends pas ce que tu veux dire par gestion de la RAM pas vraiment optimisée avec un GC.

[Calembredaine]

Je te parle d'un temps que les moins de 4 ans ne peuvent pas connaître (août 2008 et iOS 2) , c'était tout juste à la sortie du 3G en Suisse.

Et ça fait longtemps que je n'y touche plus.

Ce que je souligne c'est que le langage changeait selon l'environnement que tu utilisais, point barre. D'un côté t'as un GC de l'autre t'as des free.

Ce qui est quand même un peu chiant, car ce n'est plus tout à fait le même langage. (Je considère que la gestion de la mémoire fait partie du langage)

Et pour ma part, je voulais souligner qu'il n'est pas très honnête de critiquer un système, une machine ou une marque sur la base d'informations obsolètes.

Et sinon je ne comprends pas ce que tu veux dire par gestion de la RAM pas vraiment optimisée avec un GC.

C'est pourtant simple, avec GC, la libération des objets ne se fait pas forcément au moment exact où l'application n'en a plus besoin. D'où une consommation mémoire accrue.

[Noob]

Et pour ma part, je voulais souligner qu'il n'est pas très honnête de critiquer un système, une machine ou une marque sur la base d'informations obsolètes.

C'est pourtant simple, avec GC, la libération des objets ne se fait pas forcément au moment exact où l'application n'en a plus besoin. D'où une consommation mémoire accrue.

Je suis d'accord iOS 2 était vraiment une grosse merde, d'ailleurs une bonne partie des API de iOS 2 ont changé depuis, je me souvient des API deprecated sans équivalent connu, c'était juste du pur bonheur.

Après à partir du 3 ça a commencer à ressembler à quelque chose, probablement que maintenant c'est tout à fait correct. (à epsilon près, cf problème de système de fichier)

Par contre ce n'est pas vraiment la RAM qui compte plutôt que le temps de réponse ou la réactivité.

Typiquement les appels à malloc et free sont extrêmement coûteux. Une machine virtuelle qui réclame cette mémoire en gros bloc pour l'attribuer à l'application en cas de besoin est bien plus efficace qu'un appel système. On a un léger coup en RAM, mais cette allocation est de fait beaucoup plus rapide.

[Calembredaine]

Par contre ce n'est pas vraiment la RAM qui compte plutôt que le temps de réponse ou la réactivité.

Typiquement les appels à malloc et free sont extrêmement coûteux.

malloc et free en Objective-C?

Heu, certes, tu peux utiliser du C pur dans tes applications mais bon autant utiliser les classes ad hoc, non? Sinon, l'intérêt de l'objective-c est absolument nul.

[Noob]

malloc et free en Objective-C?

Heu, certes, tu peux utiliser du C pur dans tes applications mais bon autant utiliser les classes ad hoc, non? Sinon, l'intérêt de l'objective-c est absolument nul.

J'ai fait exprès pour que ceux qui ne font pas d'obj-c comprennent, je pensais à [[MaClasse alloc] init] et release ou dealloc.

Tout appel à l'OS coûte en temps CPU, plus tu en as, plus tes performances se casse la gueule. D'où l'avantage d'une vm dont la gestion de la mémoire est hors du contrôle de l'utilisateur.

[pankkake]

http://neuroskeptic.blogspot.co.uk/2012/06/brains-are-different-on-macs.html

[WBell]

Une machine virtuelle qui réclame cette mémoire en gros bloc pour l'attribuer à l'application en cas de besoin est bien plus efficace qu'un appel système. On a un léger coup en RAM, mais cette allocation est de fait beaucoup plus rapide.

Dans l'absolu c'est vrai, mais on reste sur une machine mobile, avec des contraintes plus fortes sur ce que l'OS va faire en gestion des ressources.

http://neuroskeptic….nt-on-macs.html

J'ai vu ça hier, ça m'a fait tout de suite penser à ce thread . Pour être juste ce n'est pas "ça s'affiche moins bien sur Mac", c'est plutôt "entre un PC et un Mac, ça ne s'affiche pas pareil". Et pour avoir dû normaliser une expérience pendant ma thèse entre des PC (sous différents) Windows, et des Macs (sous différents OSX), il y a plein de choses qui ne se comportent pas de la même manière, sans qu'un dév. (même système) puisse imaginer que cela impacte le logiciel. Il y a des petits détails, qui paraissent insignifiants, mais qui au final peuvent tous influencer le résultat. Et quand on additionne le tout (et quand on pense que, pour un même OS, les différentes versions ne se comportent pas de la même manière)…

Quelques petits exemples : la réponse de la souris n'est pas la même entre un PC et un Mac. Pour la machines ayant des dalles d'écran 6 bits (pour diminuer les coûts), les astuces du type 'sub-pixel aliasing' ne donnent pas les valeurs attendues par le dev. Le polling des données sur un port USB n'est pas le même entre un PC et un Mac (et donc une appli multiplateforme, mais dont l'équipe de dev n'a pas fait attention peut par exemple perdre la dernière trame d'un flux vidéo envoyé sur le port USB). Ne parlons pas des simples fautes de programmations (du même style que la confusion système métrique/système impérial pour les unités de mesures sur la fusée qui a explosé) : séparer les milliers des dizaines se fait par un espace, un point ou une virgule suivant la lange. Mais aussi suivant la page de code associée par défaut au clavier. Un mauvais programmeur qui rentre en dur ce genre d'information va avoir de mauvaises surprises…

De toutes façons, il y a une bonne raison pour laquelle le coût du matériel certifié coûte si cher en milieu médical. Il y a tellement de choses à contrôler que ça devient dantesque.

[Noob]

Dans l'absolu c'est vrai, mais on reste sur une machine mobile, avec des contraintes plus fortes sur ce que l'OS va faire en gestion des ressources.

Meuh non voyons, un téléphone c'est fait pour jouer, pas pour recevoir des appels :-)

[Sloonz]

Tout appel à l'OS coûte en temps CPU, plus tu en as, plus tes performances se casse la gueule. D'où l'avantage d'une vm dont la gestion de la mémoire est hors du contrôle de l'utilisateur.

Ça tombe bien, malloc/free et +alloc/-dealloc ne font que rarement appel à l’OS (grosso-modo quand il faut changer la taille du tas, avec brk). Et la question de la gestion manuelle ou automatique est orthogonale aux performances des mécanismes d’allocation de segments, une vm aussi a aussi des malloc/free à gérer. Une vm doit décider que la plage d’adresse 0xf14c12d5-0xf14c12e5 est associée à un objet (mot-clef new en Java par exemple), ce qui est exactement équivalent à ce que fait malloc, puis que cette plage est libre quand l’objet n’est plus référence, ce qui est très exactement ce que fait free.

Au niveau des performances de la gestion de la mémoire, la seule chose qu’on peut reprocher à Objective-C en tant que langage (je parle pas de l’implémentation hein, je connais pas les performances de la runtime Apple sur ces questions relativement à d’autres systèmes) c’est l’impossibilité d’allouer un objet sur la pile.

[pankkake]

Meuh non voyons, un téléphone c'est fait pour jouer, pas pour recevoir des appels :-)

Comme je le disais ailleurs, le smartphone c'est le téléphone pour les gens qui n'ont pas de vie sociale.

[Noob]

Ça tombe bien, malloc/free et +alloc/-dealloc ne font que rarement appel à l’OS (grosso-modo quand il faut changer la taille du tas, avec brk). Et la question de la gestion manuelle ou automatique est orthogonale aux performances des mécanismes d’allocation de segments, une vm aussi a aussi des malloc/free à gérer. Une vm doit décider que la plage d’adresse 0xf14c12d5-0xf14c12e5 est associée à un objet (mot-clef new en Java par exemple), ce qui est exactement équivalent à ce que fait malloc, puis que cette plage est libre quand l’objet n’est plus référence, ce qui est très exactement ce que fait free.

Je suis d'accord sur à peu près tout sauf sur le fait que la taille du tas ne changerait pas rapidement. Ce qui forcerait à demander et à rendre de la mémoire à l'OS ce qui est on est bien d'accord une perte de temps.

Ce que permet une vm, c'est de justement tenir compte de ces changements rapides et de ne pas rendre de mémoire.

A contrario, la libc n'a pas vocation à profiler l'application pour déterminer la taille optimale du tas.