ben ça doit être gai...*
 
pis alors le coup du read synchrone mais pas le write, c'est trop fort...
donc j'ai le droit de travailler pendant que le prog écrit, mais pas pendant qu'il lit ? si ça c'est pas du mongolisme primaire...
 
si y'a pourtant bien un truc qui devrait être assynchrone, c'est bien la lecture, rien ne m'empêche de commencer à traîter ce qui est déjà lu pendant que je continue de charger mon fichier...
 
 
* : donc vous confirmer que si j'écris sur le disque le contenu mémoire situé à une adresse (un byte[] passé par référence par exemple), et qu'un fois écrit je commence à modifier ce dernier (genre le détruire puisqu'il ne me sert plus à rien), alors je vais écrire n'importe quoi dans mon fichier ?
 
que windows gère son propre cache logiciel, et diffère les écritures, je veux bien. mais quand j'écris 2 Go d'un coup dans un fichier, ça me ferait bien mal que la milliseconde suivant l'appel j'aie de nouveau la main dans mon programme

et les buffers logiques du kernel sont pas limités en taille ?
 
franchement, autant pour des blocs de quelques ko, effectivement, le fait que le kernel gère un cache permet effectivement de rendre instantanés les appels aux écritures, autant pour plusieurs mo, j'ai du mal à concevoir comment l'os va pouvoir te rendre la main aussi tôt sans te saturer la mémoire... et pour moi, les caches disques sont plutôt limités en taille.
 
dans tous les cas, lorsque j'avais fait ma fonction d'encryption, et que je la lançais sur de très gros volums (genre un VOB), le faire de faire tourner l'écriture dans un thread séparé me permettait d'aller énormément plus vite.
bon, la lecture aussi était dans un thread, ça pouvait éventuellement venir de là aussi.
 
dans ce cas, on va donc changer mon exemple en parlant non plus de l'enregistrement du graph sur le disque, mais l'inverse : pendant que je lis sur le disque le bloc suivant (thread fournisseur), je peux m'occuper dans un thread séparé (consomateur) de désérialiser les données déjà lues afin de les charger en mémoire sous forme d'arbre. à ce moment le gain sera énorme, pour peu que les accès disques ne bouffent que peu de CPU (donc sur un disque ATAPI, le gain est de 0 par exemple, puisque les accès disques prennent 100% du CPU)

dans ce cas, on va donc changer mon exemple en parlant non plus de l'enregistrement du graph sur le disque, mais l'inverse : pendant que je lis sur le disque le bloc suivant (thread fournisseur), je peux m'occuper dans un thread séparé (consomateur) de désérialiser les données déjà lues afin de les charger en mémoire sous forme d'arbre. à ce moment le gain sera énorme, pour peu que les accès disques ne bouffent que peu de CPU (donc sur un disque ATAPI, le gain est de 0 par exemple, puisque les accès disques prennent 100% du CPU)

ben ça doit être gai...*
 
pis alors le coup du read synchrone mais pas le write, c'est trop fort...
donc j'ai le droit de travailler pendant que le prog écrit, mais pas pendant qu'il lit ? si ça c'est pas du mongolisme primaire...
 
si y'a pourtant bien un truc qui devrait être assynchrone, c'est bien la lecture, rien ne m'empêche de commencer à traîter ce qui est déjà lu pendant que je continue de charger mon fichier...
 
 
* : donc vous confirmer que si j'écris sur le disque le contenu mémoire situé à une adresse (un byte[] passé par référence par exemple), et qu'un fois écrit je commence à modifier ce dernier (genre le détruire puisqu'il ne me sert plus à rien), alors je vais écrire n'importe quoi dans mon fichier ?
 
que windows gère son propre cache logiciel, et diffère les écritures, je veux bien. mais quand j'écris 2 Go d'un coup dans un fichier, ça me ferait bien mal que la milliseconde suivant l'appel j'aie de nouveau la main dans mon programme

et les buffers logiques du kernel sont pas limités en taille ?
 
franchement, autant pour des blocs de quelques ko, effectivement, le fait que le kernel gère un cache permet effectivement de rendre instantanés les appels aux écritures, autant pour plusieurs mo, j'ai du mal à concevoir comment l'os va pouvoir te rendre la main aussi tôt sans te saturer la mémoire... et pour moi, les caches disques sont plutôt limités en taille.
 
dans tous les cas, lorsque j'avais fait ma fonction d'encryption, et que je la lançais sur de très gros volums (genre un VOB), le faire de faire tourner l'écriture dans un thread séparé me permettait d'aller énormément plus vite.
bon, la lecture aussi était dans un thread, ça pouvait éventuellement venir de là aussi.
 
dans ce cas, on va donc changer mon exemple en parlant non plus de l'enregistrement du graph sur le disque, mais l'inverse : pendant que je lis sur le disque le bloc suivant (thread fournisseur), je peux m'occuper dans un thread séparé (consomateur) de désérialiser les données déjà lues afin de les charger en mémoire sous forme d'arbre. à ce moment le gain sera énorme, pour peu que les accès disques ne bouffent que peu de CPU (donc sur un disque ATAPI, le gain est de 0 par exemple, puisque les accès disques prennent 100% du CPU)

 
   
 
si tu as plus de 2Go de mémoire oui, tu as la main un peu après.

ptain, une 8800 GTX

Je relance le débat, mais je confirme un peu tout ce qui est dit :
J'ai un programme qui s'occupe de réunir des fichiers au sein d'un seul.
Il est monothread et tourne de la même façon sous Windows XP 32 bits et 64 bits...
 
Voici son fonctionnement :
Il lit des milliers de fichiers et les compresse en mémoire jusqu'à atteindre 32Mo. Lorsque cette barrière est atteinte, le tampon est écrit et on recommence...
 
Ce que je peux dire, c'est qu'avec une taille de tampon d'écriture de 32Mo, c'est trés rapide... Mais on perd en vitesse si on réduit le tampon (et sans, c'est hyper lent).

Taz> J'ai pas trouver ce genre de fonction sous Windows. Je pense que c'est transparent de toute façon.

avec une vraie API async, t'as surtout le moyen d'obtenir une notification en fin d'opération.