Pourquoi les téléphones Android ont-ils plus de cœurs que les ordinateurs?

@iBug Cette réponse s'applique mieux à la question de l'OP que la réponse acceptée. La réponse acceptée est celle qui ne répond pas à la bonne question.

"gonfler artificiellement les prix des CPU" -> Si Intel gonflait artificiellement les prix, pourquoi leur concurrence utilise du matériel de prix similaire et pourquoi les ordinateurs armés d'ARM sont si mauvais en comparaison du matériel Intel ? Cette haine envers Intel est ridicule. Fabriquer des CPU est difficile. Ce qui a rendu ARM si populaire parmi les appareils mobiles était l'idée big.LITTLE, quelque chose qu'ils ont conçu avant Intel.

Aussi, je suis assez sûr que c'était Intel qui a commencé avec la technologie multicœur à des prix abordables, avec la ligne Celeron D. Votre réponse n'a aucun sens.

Intel ne contrôle pas le marché des puces PC et ce depuis de nombreuses années. Et la raison pour laquelle les concepteurs de puces sont passés de horloges plus rapides à plus de cœurs est que les horloges plus rapides rencontraient certaines limites physiques fondamentales. Avoir plus de cœurs posait un problème beaucoup plus difficile à résoudre, c'est pourquoi ils ont repoussé cela jusqu'à ce que ce soit le moyen le plus rentable d'augmenter les performances.

Cette réponse concerne définitivement shesp.

Cette réponse n'a aucun sens. Intel est l'un des fabricants de puces dans les PC. Et la question est pourquoi les téléphones ont plus de coeurs que les PC. Pas pourquoi les téléphones ont plus de coeurs que les PC Intel. Cette réponse suppose qu'Intel = PC, ce qui n'est pas le cas.

C'est plus une diatribe sur la méchante corporation Intel, qui à mon avis n'est pas méritée car ARM escroque aussi bien les fabricants de puces indépendants avec des licences.

Intel a conclu des transactions douteuses qui ont été exposées il y a 20 ans ; à l'époque, ils avaient des concurrents comme AMD et Cyrix et cherchaient à avoir un quasi-monopole. Ils possèdent certaines des usines de fabrication les plus avancées que vous puissiez trouver et la série x86 sont des processeurs RISC depuis longtemps avec un décodeur en amont pour les instructions CISC. Vous donnez un avis totalement ignorant et non informé

Je ne comprends pas pourquoi cela reçoit tant de réponses positives; cela ne répond pas à la question originale et est plein de non-sens. L'augmentation des performances des threads uniques a toujours été recherchée car elle accélère facilement tout. Tous les anciens programmes à thread unique bénéficieront du repas gratuit, et les programmes multi-threads en profiteront également. Nous avons cessé d'augmenter la fréquence en raison de limites physiques - et même encore, vous devez être sérieusement illusionné si vous pensez que la seule différence entre un 486 et un Pentium 4 est l'horloge d'instructions - les processeurs x86 superscalaires sont extrêmement ...

... des bêtes complexes qui parviennent à exécuter une IA héritée en appliquant toutes sortes d'optimisations automagiques (exécution hors ordre/parallélisme au niveau de l'instruction, renommage des registres, prédiction de branches, toutes sortes de caches, explosion/fusion d'µops) de manière presque complètement transparente. Vous ne pouvez tout simplement pas atteindre ce niveau de performance en augmentant simplement la fréquence d'horloge d'un 486. L'affirmation selon laquelle "les algorithmes parallèles sont vraiment difficiles à mettre en œuvre" est un mythe complètement faux. Outre les problèmes soi-disant "embarrassingly parallel" (parallélisme évident), créer des versions parallèles d'algorithmes est l'une des tâches les plus difficiles...

... défis auxquels nous sommes confrontés, et dans de nombreux cas (typiquement, lorsque vous avez besoin de données de l'étape précédente de l'algorithme pour alimenter la suivante) cela ne peut tout simplement pas être fait, à moins d'avoir un flux interminable de données à élaborer, afin que vous puissiez mettre en place un pipeline. En outre, la programmation parallèle efficace et correcte lorsque vous avez des ressources partagées à jongler entre plusieurs threads d'exécution est en soi un défi extrêmement difficile. Même Linus Torvalds a mis en garde contre le fait d'être trop intelligent en inventant des primitives de synchronisation, étant donné que généralement presque personne n'arrive à bien le faire.

@Abdul Pas nécessairement. En fait, mis à part les jeux et les simulations physiques, les nombres à virgule flottante ne sont pas autant utilisés. De plus, de nombreux processeurs ARM atteignent des performances FLOPS décentes en réduisant la précision, donc ce n'est pas non plus la seule mesure valable.

Les applications Android ne s'exécutent pas sur la machine virtuelle Java. Elles s'exécutent sur Dalvik VM.

@LuuVinhPhúc Néanmoins, le code Davlik est généré à partir du bytecode Java et dépend donc du GC étant là.

Les tâches d'arrière-plan comme la synchronisation sont à mon avis principalement limitées par les entrées/sorties et peuvent avoir une priorité basse. La collecte des déchets pourrait être un cas d'utilisation, mais avec une collecte des déchets concurrente (c'est-à-dire une collecte des déchets qui peut maintenir l'application en cours d'exécution lors de la collecte), je doute que vous verrez généralement un avantage de plus d'un cœur supplémentaire à moins que la collecte des déchets ne soit très fréquente. Et lorsque la collecte des déchets doit être effectuée très souvent, il y a probablement quelque chose qui ne va pas.

@v6ak Vrai, mais n'y aurait-il pas un fil GC pour chaque processus? Donc une fois qu'il y a 2-3 processus actifs fonctionnant sur le téléphone, 4-8 cœurs ne semblent pas si déraisonnables.

@DmitryGrigoryev Considérez-vous la collecte de déchets lourds dans plusieurs processus comme un scénario courant? En fait, de nombreux processus en arrière-plan fonctionneraient probablement mieux avec une collecte de déchets stop-the-world qu'avec une collecte de déchets concurrente. L'inconvénient principal de la collecte de déchets stop-the-world est une interruption soudaine, ce qui n'a généralement pas d'importance dans les processus en arrière-plan (à quelques exceptions près comme la lecture de musique, mais ils sont principalement gérés par un code natif ou une accélération matérielle de toute façon). La collecte de déchets concurrentielle a un certain surcoût, réduisant le débit total, elle n'est donc pas idéale pour les processus en arrière-plan typiques.

Le GC concurrent a un avantage, il utilise moins de bande passante mémoire en utilisant globalement plus de mémoire. La bande passante mémoire est l'un des problèmes réels avec la technologie ARM et les smartphones.