Utilisation d'un quadCore grace au threads?

Version imprimable

18/09/2007, 09h12
babarpapa

Utilisation d'un quadCore grace au threads?

Bonjour,
j'ai fais un plugin d'imagerie très lourd en calcul qui fera le même traitement (segmentation 3D) pour 1500 piles d'images.
J'aurai aimé savoir comment faire pour que je puisse lancer le traitement de 4 piles d'images simultanément avec le même algorithme sur les 4 cores d'un quadCore (Q6600)? Faut il simplement que je lance 4 threads ou peut on nommer concrètement chaque processeur, c'est à dire que je dis au premier thread : "travail avec ce core" etc...D'autre part, est ce que ça sera aussi efficace que de lancer chaque traitement sur des machines monoprocesseurs.
Merci pour votre aide.

Mathieu
18/09/2007, 09h35
CyberChouan

Tu ne peux pas choisir en java quel processeur va faire tourner quel Thread... c'est géré automatiquement par la JVM. Le seul moyen pour faire ça serait de travailler avec des langages de bas niveau (C, etc.)

Cependant, si tu lances 4 Threads, ta JVM devrait automatiquement répartir la charge sur les ressources disponibles (donc sur tes 4 processeurs)
18/09/2007, 12h37
millie

Citation:

Envoyé par CyberChouan

Tu ne peux pas choisir en java quel processeur va faire tourner quel Thread... c'est géré automatiquement par la JVM. Le seul moyen pour faire ça serait de travailler avec des langages de bas niveau (C, etc.)

Même avec un langage bas niveau comme le C, ce n'est pas vraiment possible de le faire. C'est le système (l'OS) qui répartit automatiquement les threads sur les processeurs ou les cores suivant les ressources disponibles (et normalement, il est censé mieux savoir qu'un utilisateur)

D'ailleurs, la JVM doit effectuer un appel système au système d'exploitation pour la création des threads, et ne doit pas non plus choisir où il est réparti.

Maintenant, ce que tu peux faire (vu qu'en général, répartir un algorithme de traitement d'images sur 4 ou 10 threads est à peu près équivalent), tu peux faire des benchmarks pour voir avec combien de thread les calculs sont les plus performants.
En C++ (sur des Sparc), sur un quadri processeur (et pas un quadri core), tous les benchmarks que j'ai effectué sur des algo de traitement d'images m'ont fait comprendre qu'il répartissait tout seul comme un grand les threads sur les 4 processeurs.

Il faudrait que je teste sur un quad core (d'ailleurs, je crois avoir le même processeur que toi).
18/09/2007, 12h39
pverley

Bonjour,

Je n'ai pas la réponse à ton problème mais tu peux regarder du côté de openMP et MPI, il existe peut-être des API pour java
Un petit :google2: "java openMP" ou "java MPI" devrait t'aider à avancer, je l'espère.

Cheers,

Philippe.

Je confirme ce que j'ai dit sur les threads Java :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public synchronized void start() {
        /**
         * This method is not invoked for the main method thread or "system"
         * group threads created/set up by the VM. Any new functionality added 
         * to this method in the future may have to also be added to the VM.
         *
         * A zero status value corresponds to state "NEW".
         */
        if (threadStatus != 0)
            throw new IllegalThreadStateException();
        group.add(this);
        start0();
        if (stopBeforeStart) {
	    stop0(throwableFromStop);
	}
    }

La méthode stop0 est native.

Code:

{"start0", "()V", (void *)&JVM_StartThread},

Le code de JVM_StartThread :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
 
 
JVM_ENTRY(void, JVM_StartThread(JNIEnv* env, jobject jthread))
  JVMWrapper("JVM_StartThread");
  JavaThread *native_thread = NULL;
 
  // We cannot hold the Threads_lock when we throw an exception,
  // due to rank ordering issues. Example:  we might need to grab the
  // Heap_lock while we construct the exception.
  bool throw_illegal_thread_state = false;
 
  // We must release the Threads_lock before we can post a jvmti event
  // in Thread::start.
  { 
    // Ensure that the C++ Thread and OSThread structures aren't freed before 
    // we operate.
    MutexLocker mu(Threads_lock);  
 
    // Check to see if we're running a thread that's already exited or was
    // stopped (is_stillborn) or is still active (thread is not NULL).
    if (java_lang_Thread::is_stillborn(JNIHandles::resolve_non_null(jthread)) ||
        java_lang_Thread::thread(JNIHandles::resolve_non_null(jthread)) != NULL) {
        throw_illegal_thread_state = true;
    } else {
      jlong size = 
             java_lang_Thread::stackSize(JNIHandles::resolve_non_null(jthread));
      // Allocate the C++ Thread structure and create the native thread.  The
      // stack size retrieved from java is signed, but the constructor takes
      // size_t (an unsigned type), so avoid passing negative values which would
      // result in really large stacks.
      size_t sz = size > 0 ? (size_t) size : 0;
      native_thread = new JavaThread(&thread_entry, sz);
 
      // At this point it may be possible that no osthread was created for the
      // JavaThread due to lack of memory. Check for this situation and throw
      // an exception if necessary. Eventually we may want to change this so
      // that we only grab the lock if the thread was created successfully -
      // then we can also do this check and throw the exception in the 
      // JavaThread constructor.
      if (native_thread->osthread() != NULL) {
        // Note: the current thread is not being used within "prepare".
        native_thread->prepare(jthread);
      }
    }
  }
...

Dans la ligne : native_thread = new JavaThread(&thread_entry, sz);

on a le démarrage du thread :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
JavaThread::JavaThread(ThreadFunction entry_point, size_t stack_sz) : Thread() {
  if (TraceThreadEvents) {
    tty->print_cr("creating thread %p", this);
  }
  initialize();
  _is_attaching = false;
  set_entry_point(entry_point);
  // Create the native thread itself.
  // %note runtime_23
  os::ThreadType thr_type = os::java_thread;
  thr_type = entry_point == &compiler_thread_entry ? os::compiler_thread :
                                                     os::java_thread;
  os::create_thread(this, thr_type, stack_sz);

Et os::create_threade qui est dépendant de l'OS, par exemple sous Linux :

Code:

1
2
3
4
5
6
7
 
bool os::create_thread(Thread* thread, ThreadType thr_type, size_t stack_size) {
 
    pthread_t tid;
    int ret = pthread_create(&tid, &attr, (void* (*)(void*)) java_start, thread);
 
}

Simple appel système qui ne permet pas de choisir le processeur.

18/09/2007, 15h47
babarpapa

Merci à tous pour votre aide!
Pour l'instant, je travaille juste avec un core 2 duo, donc 2 core et j'ai fait le test de lancer d'une part un calcul et ensuite les 2 meme calcules sur 2 thread et ça met le même temps qu'avec un seul, donc je suis très satisfait. J'espere que les 4 cores me permettront d'avoir les meme performance si je lance 4 thread.
;)
18/09/2007, 16h05
millie

Des tests que je viens d'effectuer sur un pentium Core2 Quad Q6600.

Sur une opération de convolution (noyau MDIF) avec 1 thread => 9 sec.
2 threads => 4 sec
4 threads => 2 sec
(j'ai pas fait les millisecondes)

Donc, bonne ordre d'idée.

EDIT : J'ai fait des tests en C++, mais comme le montre l'exemple donné précédemment, la JVM de Sun utilise directement les appels systèmes (pthread et compagnie) donc ça doit donner la même chose.
18/09/2007, 16h22
babarpapa

oki, excellent, ça me rassure sur la bonne gestion des threads.
Merci encore ;)