Discussion :

[Anarchy64]

Bonjour. J'ai voulu faire une sorte de stress test très basique pour mon disque dur, en lui écrivant des données aléatoires en continu, et ça a donné ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
int main(void)	{
 
	srand((unsigned int)time(NULL)); 
	unsigned char n = RAND(1,255); // Création d'un nombre aléatoire
	FILE *fs = NULL;
	fs = fopen("test1.bin", "wb"); // Ouverture du fichier
	time_t initial = clock();
	time_t actual = 0;
 
	while (actual / CLOCKS_PER_SEC < 120)	{
		fwrite(&n, 1, 1, fs);	// Ecriture
		__asm	ror n, 3;		// Rotation
		actual = clock() - initial;
	}	// Tant que 120 secondes ne sont pas écoulées, continuer
 
	fclose(fs);
	system("pause");
 
	return 0;
}

Le problème, c'est que c'est mon processeur qui se fatigue avant mon HDD (utilisation proc 25%, et c'est un quad core, utilisation HDD 10% pour un 7200 rpm).
Et ce n'est pas dû à la rotation de l'octet, où au fait de gérer le timer, mais de fwrite qui est trop lent.

Donc ce que j'aimerais savoir, c'est comment faire pour que l'écriture soit bien plus rapide ? Hormis utiliser les threads parce que il faudra que je lance ce programme sur un ssd donc bon...

Merci d'avance !

[Obsidian]

Dans un premier temps, tu peux passer des blocs plus grands que 1 octet à fwrite. Sinon, par définition, tu fais un appel système par octet. C'est extrêmement coûteux. Les flux C sont bufferisés par défaut et les bibliothèques C standards modernes sont également faites pour tamponner les appels systèmes, mais quand même.

Ensuite ça va surtout dépendre de ton système d'exploitation. C'est lui qui va gérer activement les disques juste après le hardware et il faudra optimiser la programmation système pour influer au minimum sur ses strates.

Si c'est le débit brut qui t'intéresse, tu peux te tourner vers les raw devices ou ce qui en tient lieu. À part cela, personnellement, je tâcherais d'utiliser mmap() ou assimilé pour faire le plus grand mapping possible dans la mémoire physique, j'utiliserais un pointeur pour modifier un octet en mémoire par intervalles multiples de la taille d'une page afin de « salir » chacune d'elle au moindre coût CPU, et demanderait la synchronisation de tout cela.

[Anarchy64]

Ok merci de la réponse, j'espère juste que ça ne va pas me bouffer trop de temps ^^.

[Mat.M]

salut tu devrais savoir que les entrées/sorties dans un sytème informatique ça ralentit l'exécution des opérations parce que c'est très lent.
Etant donné que du numérique tu passes à des traitements analogiques.
En plus il y a le rôle de l'OS que mentionne à juste titre Obsidian.
La solution de passer des blocs plus gros est valable car effectivement ça sera mis en tampon dans le cache du disque dur

[LittleWhite]

Bonjour,

Pour éviter la mise en cache, on peut utiliser fsync, et ouvrir le fichier avec le flag : O_DIRECT de open (c'est assez compliqué à utiliser, car il faut un segment mémoire aligné par rapport aux blocs du disque).
Après, pour stresser la chose, l'utilisation de OpenMP (pour paralléliser à faible cout en code) est pratique (autant utiliser tous les coeurs).
Et écrire des bloc de 1 Mo par 1 Mo, c'est mieux aussi.

[Obsidian]

Pour éviter la mise en cache, on peut utiliser fsync, et ouvrir le fichier avec le flag : O_DIRECT de open (c'est assez compliqué à utiliser, car il faut un segment mémoire aligné par rapport aux blocs du disque).

O_DIRECT est l'interface moderne sous Linux pour gérer les raw devices.

[LittleWhite]

Vous voyez, j'ai juste