Pour l'appli : un seul CPU, beaucoup de processus, 3 threads par processus, des IPC et beaucoups d'entrées/sorties disque et de com réseau.
Les entrées/sorties disque consomme plus de CPU sous Windows que sous Linux et dès que la machine devient chargée, le scheduler de Windows à un comportement de merde.
Ben voila, tu as ton explication, ce n'est pas comme ca qu'une appli sous Windows est developpee.
Sous Unix, l'habitude est d'utiliser des processus pour separer les taches, sous Windows la regle c'est :
- utiliser les threads, sauf si tu as reellement besoin d'avoir une separation entre processus
- ne pas utiliser bcp de threads, car c'est totalement inefficace(tout comme utiliser bcp de processus/threads sous Unix d'ailleurs, car le scheduler finit par passer son temps a scheduler et context-switcher 200 threads plutot que faire bosser les threads existants), si tu as besoin de plus de 2 threads par CPU, c'est soit que ton soft fait bcp d'I/O lentes(et dans ce cas avoir 2-3 threads de plus est acceptable), soit que ton design est mauvais
- utiliser les completion ports pour communiquer soit sur disque soit reseau
Bref, le mieux c'est :
- avoir un thread pool
- toujours utiliser les completion ports pour les communications, ca permet d'avoir un design totalement asynchrone et un faible nombre de threads toujours en train de bosser plutot que 300 threads donc 290 ne font qu'attendre.
[^] # Re: Ca devait arriver
Posté par pasBill pasGates . En réponse au journal Projet Origami de Microsoft. Évalué à 3.
Les entrées/sorties disque consomme plus de CPU sous Windows que sous Linux et dès que la machine devient chargée, le scheduler de Windows à un comportement de merde.
Ben voila, tu as ton explication, ce n'est pas comme ca qu'une appli sous Windows est developpee.
Sous Unix, l'habitude est d'utiliser des processus pour separer les taches, sous Windows la regle c'est :
- utiliser les threads, sauf si tu as reellement besoin d'avoir une separation entre processus
- ne pas utiliser bcp de threads, car c'est totalement inefficace(tout comme utiliser bcp de processus/threads sous Unix d'ailleurs, car le scheduler finit par passer son temps a scheduler et context-switcher 200 threads plutot que faire bosser les threads existants), si tu as besoin de plus de 2 threads par CPU, c'est soit que ton soft fait bcp d'I/O lentes(et dans ce cas avoir 2-3 threads de plus est acceptable), soit que ton design est mauvais
- utiliser les completion ports pour communiquer soit sur disque soit reseau
Bref, le mieux c'est :
- avoir un thread pool
- toujours utiliser les completion ports pour les communications, ca permet d'avoir un design totalement asynchrone et un faible nombre de threads toujours en train de bosser plutot que 300 threads donc 290 ne font qu'attendre.