Threads par Processeur
En Java, est-il un moyen via un programme pour trouver le nombre de threads simultanés sont pris en charge par un CPU?
Mise à jour
Pour être clair, je ne suis pas en train de marteler le CPU avec les fils et je suis conscient de l'Exécution.getRuntime().availableProcessors() de la fonction, qui me fournit une partie de l'information que je cherche.
Je veux savoir si il y a un moyen de régler automatiquement la taille du pool de threads de sorte que:
- si je suis en cours d'exécution sur un enfant de 1 an de serveur, j'obtiens 2 fils (1 thread par CPU x l'arbitraire d'un coefficient multiplicateur de 2)
- si je passe à un processeur Intel i7 quad core de deux ans à partir de maintenant (qui prend en charge 2 threads par cœur), j'ai 16 threads (2 logique threads par PROCESSEUR x 4 Processeurs x l'arbitraire multiplicateur de 2).
- si, au lieu de cela, j'utilise un huit core Ultrasparc T2 serveur (qui prend en charge 8 threads par cœur), je reçois 128 threads (8 threads par PROCESSEUR x 8 Processeurs x l'arbitraire multiplicateur de 2)
- si je déployer le même logiciel sur un cluster de 30 machines différentes, potentiellement achetées au cours de différentes années, je n'ai pas besoin de lire le CPU spécifications et définir les options de configuration pour chacun d'entre eux.
Vous devez vous connecter pour publier un commentaire.
De l'exécution.availableProcessors renvoie le nombre de processeurs logiques (c'est à dire threads matériels) pas de cœurs physiques. Voir CR 5048379.
Un seul non-hyperthreading CPU core pouvez toujours exécuter un thread. Vous pouvez frayer beaucoup de fils et de le CPU basculer entre eux.
Le meilleur nombre dépend de la tâche. Si c'est une tâche qui prend beaucoup de puissance CPU et ne nécessiter aucun I/O (comme le calcul de pi, le premier des nombres, etc.) puis 1 thread par CPU ne sera probablement mieux. Si la tâche est plus d'I/O bound. comme le traitement de l'information à partir d'un disque, alors vous aurez probablement obtenir de meilleures performances en ayant plus d'un thread par CPU. Dans ce cas, l'accès au disque peut avoir lieu pendant que le PROCESSEUR de traitement de l'information à partir d'une précédente lecture du disque.
Je vous suggère de faire quelques tests de la façon dont la performance dans votre situation échelles avec un nombre de threads par cœur de PROCESSEUR et de décider sur cette base. Puis, lorsque votre application s'exécute, il peut vérifier la
availableProcessors()et de décider combien de threads il doit reproduire.Hyperthreading, faire le seul core semblent le système d'exploitation et toutes les applications, y compris
availableProcessors(), 2 Processeurs, donc si votre application peut utiliser l'hyperthreading, vous aurez l'avantage. Si non, alors les performances vont souffrir un peu, mais sans doute pas assez de faire des efforts supplémentaires dans la restauration pour les il la peine de tout.Il n'existe pas de méthode standard pour obtenir le nombre de prises en charge threads par cœur de PROCESSEUR à l'intérieur de Java. Votre meilleur pari est de trouver un Java CPUID utilitaire qui vous donne les informations sur le processeur, et puis le match contre une table, vous devrez générer que vous donne les threads par noyau que le processeur gère sans un "vrai" changement de contexte.
-Adam
Un CPU ne posent normalement pas de limite sur le nombre de threads, et je ne pense pas que Java lui-même a une limite sur le nombre de natifs (noyau) de threads qu'il va engendrer.
Il existe une méthode availableProcessors() dans la classe Runtime. Est-ce que vous cherchez?
Chaque processeur ou processeur core, peut faire exactement 1 chose à la fois. Avec l'hyperthreading, les choses deviennent un peu différent, mais pour la plupart, qui reste vrai, c'est pourquoi mon HT de la machine au travail à peu près ne va jamais au-dessus de 50%, et même quand il est à 100%, il n'est pas de traitement deux fois plus à la fois.
Vous aurez probablement juste de faire quelques tests sur des architectures communes vous prévoyez de déployer sur pour déterminer le nombre de threads que vous voulez exécuter sur chaque PROCESSEUR. Juste en utilisant 1 fil peut être trop lent si vous êtes en attente pour beaucoup d'I/O. en cours d'Exécution beaucoup de threads de ralentir les choses comme le processeur devra passer threads plus souvent, ce qui peut être très coûteux. Je ne suis pas sûr si il n'y a aucune limite codée en dur pour le nombre de threads que vous pouvez courir, mais j'ai garantir que votre application serait probablement venir à une analyse de trop de fil de commutation avant de vous arrivé à quelque limite dure. En fin de compte, vous devez laisser le comme une option dans le fichier de configuration, de sorte que vous pouvez facilement ajuster votre application à tout ce processeur que vous exécutez sur.
De base:
Application chargée dans la mémoire est un processus. Un processus possède au moins 1 fil. Si vous le souhaitez, vous pouvez créer autant de threads que vous voulez dans un processus (en théorie). Si le nombre de threads dépend de vous, et les algorithmes que vous utilisez.
Si vous utilisez des pools de threads, cela signifie que le pool de thread gère le nombre de threads parce que la création d'un thread consomme des ressources. Les pools de threads recycler les threads. Cela signifie beaucoup de logique threads peuvent s'exécuter à l'intérieur d'un thread physique l'un après l'autre.
Vous n'avez pas à considérer la nombre de threads, il est géré par le pool de threads algorithmes. Les pools de threads choisir différents algorithmes pour les serveurs et les ordinateurs de bureau (Systèmes d'exploitation).
Edit1:
Vous pouvez utiliser explicite fils si vous pensez que le pool de thread n'est pas utiliser les ressources que vous avez. Vous pouvez gérer le nombre de threads de manière explicite dans ce cas.
C'est une fonction de la VM, pas le CPU. Il a à voir avec la quantité de mémoire consommée par thread. Lorsque vous manquez d'espace sur le tas, vous avez terminé. Comme avec d'autres posters, je soupçonne votre application devient inutilisable avant de ce point, si vous dépassez le segment de l'espace en raison du nombre de threads.
Voir ce discussion.