quand je parle des primitives c'est les primitive OS.
donc les api systèmes, les services, les drivers D3D, OpenGl etc...
donc une appli mono-threadée peut déclencher à l'insu de son plein gré une palaquée de thread qui se répartiront sur divers cpu.
néamoins comme tu as pu le constater: comme il y a "blocage", généralement la somme de la charge sur chaque cpu reviens à un une charge de 100% sur un seul cpu.
----
alors après il peut réellement y avoir un gain suivant comment les api sont foutues: tu prends le D3D ou l'OpenGl, les drivers nVidia & Ati ont généralement un thread qui bufferise les commandes, et un thread qui optimise les commande (et pourquoi pas un autre qui fait le poussage vers le hardware).
donc même avec une appli mono-thread, si le service est threadé en interne tu peux avoir du recouvrement de temps.
bon après les drivers D3D/OpenGl threadés c'est pas forcément un bon exemple vu que j'ai déjà rencontré des problème de compétitions contre-productifs.
en fait nVidia utilise des heuristiques pour basculer certaines stratégies interne, et avec une simulation PhysX threadée, sur un dual-core, le driver nVidia se tappait des délires faisant ramer l'ensemble.
Message édité par bjone le 31-05-2008 à 16:08:34