Hi all,
 
Je ne savais pas exactement ou poster ce genre de question, mais cette section semble la plus adaptée.
 
- Supposons une application toute simple écrite en ASM ou C, qui ne contient aucun code spécifique à de la programmation multithread et/ou architectures multi-coeur (rien que du séquentiel donc), et qui utiliserait 100% de l'UC pour arriver à ses fins (une boucle de calcul)
 
- je dispose d'un quad-core, et ce qui m'a frappé, c'est que le scheduler arrive à répartir la charge de cette appli sur les 4 coeurs d'exécution (25% de charge / coeur environ) malgré le fait qu'elle n'ait pas été concue dans cet optique. (je ne suis pas expert en programmation SMP, mais il me semblait que le minimum requis soit d'avoir plusieurs fils d'exécution différents avant de pouvoir répartir la charge de traitement)
 
Quelqu'un a-t-il une explication ?  

Localement au code de l'appli non.
 
A mon avis l'appli utilise des primitives OS qui sont threadable et donc threadées, mais comme l'appli attends le résultat des primitives, le thread principal est mis en sommeil le temps que l'api redonne la main.
 
en gros un truc comme ça peut donner 50% d'utilisation cpu par core (dans le cas d'un dual core):
core 0 <x ms thread appli>  
core 1                            < x ms api os qui bosse>

Intéressant
 
Je savais que dans les langages de haut niveau (JAVA ou JS par ex), comme le niveau d'abstraction est important il y a plusieurs mécanismes d'optimisation intermédiaire qui font que beaucoup de traitements sont threadés sans qu'on ne s'en rende compte, mais je ne pensais pas que ce serait le cas des primitives dans les langages bas-niveau.
 
Cependant ce cas-ci est spécial dans le sens où le fait de répartir la charge n'accélère pas le traitement (25% par coeur ou 100% sur un seul coeur, ça revient au même), donc effectivement il y a un threading manifeste, mais ce serait faux de penser que traitement s'effectuera plus rapidement sur CPU multicoeur  

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.