Une tâche gourmande en CPU à plusieurs threads limite le processeur bien avant les températures limites

J'ai écrit une tâche filetée très gourmande en processeur qui fonctionne comme prévu sur mon quad core MacBook Pro 2012. Je le lâche avec 20 fils et les températures atteignent environ 100 ° C, mesurées avec Intel Power Gadget avec un étranglement minimal.

Apportez le même programme et les mêmes fichiers de données à mon MacBook Pro 13 "2016 avec une machine double cœur et démarrez-le, je m'attendrais à ce qu'il maintienne également les 3,3 à 3,4 GHz jusqu'à ce que la température atteigne la barre des 100 ° C. La commande supérieure montre la tâche à 350% (2 cœurs chacun à double thread), mais la fréquence du processeur est réduite à 1,6-1-8 GHz avec la température uniquement à 60 ° C environ avec les ventilateurs complètement silencieux. Si je démarre 4 séparés tâches de processeur à un seul thread, la machine se comporte comme prévu avec une fréquence de 3,3 à 3,4 GHz jusqu'à ce qu'elle atteigne les 100 ° C et que les ventilateurs démarrent. La question est pourquoi mon processeur est-il étranglé?

Les deux machines sont à jour et exécutent les mêmes versions de gcc. Si je prends même le binaire de la machine qui fonctionne et que je le mets sur le Mac 2016, il a le même problème.

Si j'exécute 3 ou 4 threads CPU uniques pour que la machine fonctionne à pleine vitesse, puis démarre le programme threadé, cela ralentit également la fréquence.

Les deux machines ont 16 Go de RAM.

modifier

Après avoir joué avec le code, je soupçonne qu'il est étranglé lorsqu'une tâche crée trop de threads. Dans ce programme, je prends chaque enregistrement que j'ai lu et je crée un fil pour celui-ci. Je ne laisse passer qu'une vingtaine de threads à la fois, donc à aucun moment il n'y a plus de 21 threads, mais il y a 14.400.000 enregistrements à traiter, donc au cours des 30 minutes environ, chacun de ces enregistrements sera traité par un thread séparé.

J'ai créé un programme pthread trivial qui aspirait le temps CPU et en mettait 10 en marche. L'ordinateur portable à problème a exécuté cela et s'est réchauffé à 95 ° C sans problème.

Je suppose que je vais réécrire mon code pour réutiliser le même thread au lieu de les détruire et de les redémarrer.

Mise à jour 13/05/17

Après plusieurs heures de travail, il ne crée plus que n threads et les réutilise, cela n'a pas aidé. À part la température du processeur, qu'est-ce qui fera que cette machine s'étranglera?

Cela peut être long, mais peut-être que la différence de performances monocœur et / ou de performances de cache entre les packages de processeurs 2012 et 2016 est suffisamment grande pour que les cœurs soient privés de données et se réduisent jusqu'à ce qu'ils soient capables de fonctionner à nouveau?

Je fais cette supposition parce que vous indiquez que suffisamment de processus à un seul thread peuvent fonctionner à pleine vitesse sur tous les cœurs, et qu'un simple programme multi-thread peut exécuter à pleine vitesse sur tous les cœurs.

Cela me fait penser qu'il y a quelque chose dans la conception du programme de votre charge de travail réelle par rapport à la charge de travail multi-thread de test qui ne permet pas aux CPU de fonctionner tout le temps

L'extension du noyau /System/Library/Extensions/AppleACPIPlatform.kext contrôle de nombreuses protections de température et de CPU. Il est déjà compilé, bien sûr, sur votre système, mais il peut être disponible sur https://opensource.apple.com (je ne le trouve pas, mais je ne lui ai donné qu'un bref aperçu). Cela ne me surprendrait pas si Apple avait des paramètres très conservateurs sur la capacité du processeur.

Chaque fois que le système d'exploitation reconnaît les threads comme imprévisibles et hors de contrôle, il se réduira pour rester stable sur le plan matériel et système, le modèle 2012 se comporte différemment et pourrait se bloquer dans le pire des cas. Cela m'est arrivé avec un contrôle de thread mal implémenté, ma faute. Il suffit de ne pas exécuter autant de threads sur un double cœur.

Cela m'est arrivé avec un contrôle de thread mal implémenté, ma faute. Il suffit de ne pas exécuter trop de threads sur un processeur dual core.