2016-10-30 2 views
0

Je cherche une idée simple pour un programme capable de saturer une CPU avec des calculs. Pour l'instant, la seule idée que j'ai est d'utiliser un générateur de nombres premiers, car le nombre de chiffres dans un nombre premier augmente, la difficulté de générer un augmente de façon exponentielle. Y a-t-il un autre type d'algorithme qui peut faire la même chose?Une idée simple pour un programme qui peut saturer un CPU

+2

Je ne pense pas que le calcul lui-même compte vraiment, n'est-ce pas? Vous pourriez faire une boucle sur une chaîne massive et en faire une copie modifiée. Pour vraiment manger le CPU cependant, vous devriez générer une tonne de threads qui tous font cela pour brancher toutes les unités de traitement. Par curiosité, pourquoi avez-vous besoin de cela? – Carcigenicate

+1

Avez-vous besoin d'utiliser beaucoup d'énergie électrique/faire de la chaleur? Ou avez-vous juste besoin d'utiliser le temps CPU? Dans ce dernier cas, toute boucle simple avec un nombre de répétitions compris entre 1M et 1000M est bonne, en fonction du temps que vous voulez pour qu'elle s'exécute. Est-ce important de savoir comment votre boucle est sensible à l'hyperthreading? (Ou tout autre type de SMT sur les microarchitectures de CPU autres que Intel.) –

Répondre

0
  • Vous ne devriez pas vous soucier du type d'opération que votre CPU est en train de faire, tant qu'il s'agit d'une opération de l'UC.

    std::atomic<bool> flag_exit;
    int a = 1;
    int b = 1;
    while(!flag_exit)
    b = a + b;
    }
    cout << b; // using 'b' just to make sure it isn't optimized away.

  • Vous voudrez peut-être envisager de répartir votre travail sur tous vos cœurs
    Bien que vous pouvez essayer relais super- scalaire de l'exécution de l'ordre (merci Peter Cordes) de scinder les instructions sans rapport, je vous recommande de créer un thread séparé par core.

+0

sauf si 'flag_exit' est un' std :: atomique 'ou quelque chose (ou un' volatile', qui fonctionnera dans ce cas mais pas en général comme un substituer pour un type atomique), la plupart des compilateurs optimisent cela à 'if (! flag_exit) {while (true) {}}', car ils vont faire le chargement une fois et garder la valeur dans un registre. Yup, c'est exactement ce qui se passe avec gcc6.2 ([sur Godbolt] (https://godbolt.org/g/c0x8PG)) –

+0

Il fonctionne bien sûr avec -O0 (auquel cas vous n'avez pas besoin du 'cout' ou si vous utilisez 'std :: atomic flag_exit': https://godbolt.org/g/IG9mKa –

+0

" relayer sur Hyper Threading pour diviser les instructions non reliées entre elles. "C'est le contraire de ce que fait HT. utiliser le même noyau, pour mieux garder le travail à faire.Gagner dans le débit global au détriment de la performance à un seul thread.Exécution superscalaire hors d'ordre normale est ce qui tire parti du parallélisme au niveau de l'instruction dans le flux d'instructions –