Groups > ger.ct > #535142 > unrolled thread

A thousand files ...

Started by	Bonita Montero <Bonita.Montero@gmail.com>
First post	2021-12-24 20:08 +0100
Last post	2021-12-31 12:27 +0100
Articles	20 on this page of 27 — 7 participants

Back to article view | Back to ger.ct

  A thousand files ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-24 20:08 +0100
    Re: A thousand files ... Hendrik van der Heijden <hvdh@gmx.de> - 2021-12-24 21:48 +0100
      Re: A thousand files ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-25 03:04 +0100
        Re: A thousand files ... Andreas Kohlbach <ank@spamfence.net> - 2021-12-25 05:16 -0500
          Re: A thousand files ... Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-25 11:23 +0100
          Re: A thousand files ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-25 11:51 +0100
            Re: A thousand files ... Andreas Kohlbach <ank@spamfence.net> - 2021-12-25 12:01 -0500
        Re: A thousand files ... Hendrik van der Heijden <hvdh@gmx.de> - 2021-12-26 22:12 +0100
          Re: A thousand files ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-27 10:33 +0100
            Re: A thousand files ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-27 11:21 +0100
              Re: A thousand files ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-27 18:32 +0100
                Re: A thousand files ... Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2021-12-28 11:33 +0100
                  Re: A thousand files ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-28 11:47 +0100
                    Re: A thousand files ... Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2021-12-29 00:12 +0100
                      Re: A thousand files ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-29 06:20 +0100
                        Re: A thousand files ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-29 06:29 +0100
                        Re: A thousand files ... Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2021-12-29 10:49 +0100
                          Re: A thousand files ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-29 11:58 +0100
                            Re: A thousand files ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-29 11:59 +0100
                            Re: A thousand files ... Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2021-12-29 12:01 +0100
                              Re: A thousand files ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-29 12:23 +0100
                              Re: A thousand files ... "Dr. Joachim Neudert" <neudert@5sl.org> - 2021-12-29 12:44 +0100
                                Re: A thousand files ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-29 14:30 +0100
    Re: A thousand files ... spamfalle2@arcor.de (Marc Stibane) - 2021-12-25 19:46 +0100
      Re: A thousand files ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-25 20:25 +0100
        Re: A thousand files ... spamfalle2@arcor.de (Marc Stibane) - 2021-12-25 22:32 +0100
    Re: A thousand files ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-31 12:27 +0100

Page 1 of 2 [1] 2 Next page →

#535142 — A thousand files ...

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-12-24 20:08 +0100
Subject	A thousand files ...
Message-ID	<sq55rr$kik$1@dont-email.me>

Heißt bei mir ein kleines Programm mit dem ich die Performance für
Filesystem-Metadaten von Windows / NTFS ggü. Linux / ext4 getestet
habe.
Und zwar macht das folgendes: Es kreiert in einem gegenenen Ver-
zeichnis dir (erster Kommandozeilen-Parameter) aus t Threads (zwei-
ter Parameter) die jeweils Files kreieren (dritter Parameter) und
die in Abhängigkeit des vierten Parameters mit einer gewissen Menge
an Bytes füllen, oder eben auch gar nicht wenn der Parameter Null
ist.
Ergebnis: Das Linux-System hat einen Ryzen 7 1800X, das Windows 10
System hat einen Threadripper 3990X (SMT wg. des Scheduler-Problems
aus), beide die gleichen SATA3-SSDs. Wenn ich aus 100 Threads paral-
lel je 1.000 files à 4kB in Serie kreieren lasse, dann ist ext4 unter
Linux etwas mehr als 20 mal so schnell wie Windows und Windows ver-
braucht für die selbe Aufgabe fast 200 mal mehr CPU-Zeit.
Ich hab ja auch erwartet, dass das Windows-System langsamer ist bzw.
mehr CPU-Last macht, aber dass das Ergebnis so dramatisch ausfällt,
das hab ich mir wirklich nicht gedacht. Absoluter Murks, was MS da
abliefert.

Hier ist das kleine Progrämmchen:

#if defined(_MSC_VER)
	#include <Windows.h>
#elif defined(__unix__)
	#include <fcntl.h>
	#include <unistd.h>
#endif
#include <iostream>
#include <system_error>
#include <vector>
#include <thread>
#include <cassert>
#include <sstream>
#include <mutex>
#include <exception>
#include <iomanip>
#include <charconv>
#include <stdexcept>
#include <cstring>
#include <type_traits>

using namespace std;

#if defined(_MSC_VER)
using handle_t = HANDLE;
#elif defined(__unix__)
using handle_t = int;
#endif

template<typename ParseType>
	requires is_scalar_v<ParseType>
static ParseType parseInt( char const *str );
static void throwSysErr( char const *errStr );
static void changeDir( char const *path );
static handle_t createFile( char const *fileName );
static void closeFile( handle_t handle );
static void writeFile( handle_t handle, void const *p, unsigned n );
static void whatExit( char const *what );

int main( int argc, char **argv )
{
	try
	{
		vector<char> writeBuff;
		auto theThread = [&]( string prefix, unsigned nFilesPerThread )
		{
			try
			{
				ostringstream ossSuffix;
				for( unsigned iFile = nFilesPerThread; iFile--; )
				{
					ossSuffix.str( "" );
					ossSuffix << prefix << setfill( '0' ) << setw( 16 ) << hex << iFile;
					handle_t h = createFile( ossSuffix.str().c_str() );
					if( writeBuff.size() )
						try
						{
							writeFile( h, &writeBuff[0], (unsigned)writeBuff.size() );
						}
						catch( ... )
						{
							closeFile( h );
							throw;
						}
					closeFile( h );
				}
			}
			catch( exception &exc )
			{
				whatExit( exc.what() );
			}
		};
		if( argc < 1 + 4 )
			return EXIT_FAILURE;
		changeDir( argv[1] );
		unsigned nThreads = parseInt<unsigned>( argv[2] ),
		         nFilesPerThread = parseInt<unsigned>( argv[3] ),
		         fileSize = parseInt<unsigned>( argv[4] );
		vector<jthread> threads;
		threads.reserve( nThreads );
		writeBuff.resize( fileSize );
		ostringstream ossPrefix;
		for( unsigned iThread = nThreads; iThread--; )
		{
			ossPrefix.str( "" );
			ossPrefix << setfill( '0' ) << setw( 16 ) << hex << iThread;
			threads.emplace_back( theThread, ossPrefix.str(), nFilesPerThread );
		}
	}
	catch( exception &exc )
	{
		whatExit( exc.what() );
	}
}

template<typename ParseType>
	requires is_scalar_v<ParseType>
static ParseType parseInt( char const *str )
{
	ParseType p;
	from_chars_result fcr = from_chars( str, str + strlen( str ), p );
	if( fcr.ec != errc() || *fcr.ptr )
		throw invalid_argument( "parameter-error" );
	return p;
}

static void throwSysErr( char const *errStr )
{
#if defined(_MSC_VER)
	int errc = GetLastError();
#elif defined(__unix__)
	int errc = errno;
#endif
	throw system_error( error_code( errc, system_category() ), errStr );
}

static void changeDir( char const *path )
{
#if defined(_MSC_VER)
	if( !SetCurrentDirectoryA( path ) )
#elif defined(__unix__)
	if( chdir( path ) )
#endif
		throwSysErr( (ostringstream() << "Can't set current directory to \"" 
<< path << "\"").str().c_str() );
}

static handle_t createFile( char const *fileName )
{
#if defined(_MSC_VER)
	handle_t handle = CreateFileA( fileName, GENERIC_READ | GENERIC_WRITE, 
0, nullptr, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL );
	if( handle == INVALID_HANDLE_VALUE )
		throwSysErr( "CreateFile() failed" );
#elif defined(__unix__)
	int handle = creat( fileName, S_IRUSR | S_IWUSR );
	if( handle == -1 )
		throwSysErr( "creat() failed" );
#endif
	return handle;
}

static void closeFile( handle_t handle )
{
#if defined(_MSC_VER)
	BOOL succ = CloseHandle( handle );
#elif defined(__unix__)
	bool succ = !close( handle );
#endif
	assert(succ);
}

static void writeFile( handle_t handle, void const *p, unsigned n )
{
#if defined(_MSC_VER)
	DWORD dwWritten;
	if( !WriteFile( handle, p, n, &dwWritten, nullptr ) || dwWritten != n )
		throwSysErr( "WriteFile() failed" );
#elif defined(__unix__)
	if( write( handle, p, n ) != n )
		throwSysErr( "write() failed" );
#endif
}

static void whatExit( char const *what )
{
	static mutex mtx;
	lock_guard lock( mtx );
	cout << what << endl;
#if defined(_MSC_VER)
	ExitProcess( EXIT_FAILURE );
#elif defined(__unix__)
	::exit( EXIT_FAILURE );
#endif
}

[toc] | [next] | [standalone]

#535146

From	Hendrik van der Heijden <hvdh@gmx.de>
Date	2021-12-24 21:48 +0100
Message-ID	<sq5bn0$85n$1@solani.org>
In reply to	#535142

Am 24.12.2021 um 20:08 schrieb Bonita Montero:
> Heißt bei mir ein kleines Programm mit dem ich die Performance für
> Filesystem-Metadaten von Windows / NTFS ggü. Linux / ext4 getestet
> habe. [..]> Wenn ich aus 100 Threads paral-
> lel je 1.000 files à 4kB in Serie kreieren lasse, dann ist ext4 unter
> Linux etwas mehr als 20 mal so schnell wie Windows und Windows ver-
> braucht für die selbe Aufgabe fast 200 mal mehr CPU-Zeit.

CPU-Zeit oder Zeit?

> Ich hab ja auch erwartet, dass das Windows-System langsamer ist bzw.
> mehr CPU-Last macht, aber dass das Ergebnis so dramatisch ausfällt,
> das hab ich mir wirklich nicht gedacht. Absoluter Murks, was MS da
> abliefert.

Ist das Dateisystem-Caching vergleichbar konfiguriert?


Hendrik vdH

[toc] | [prev] | [next] | [standalone]

#535157

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-12-25 03:04 +0100
Message-ID	<sq5u75$mmd$1@dont-email.me>
In reply to	#535146

>> Heißt bei mir ein kleines Programm mit dem ich die Performance für
>> Filesystem-Metadaten von Windows / NTFS ggü. Linux / ext4 getestet
>> habe. [..]> Wenn ich aus 100 Threads paral-
>> lel je 1.000 files à 4kB in Serie kreieren lasse, dann ist ext4 unter
>> Linux etwas mehr als 20 mal so schnell wie Windows und Windows ver-
>> braucht für die selbe Aufgabe fast 200 mal mehr CPU-Zeit.

> CPU-Zeit oder Zeit?

CPU-Zeit bzw. es wird auf dem Windows-Rechner ein wenig mehr CPU-Zeit
als Walltime verbraucht.

>> Ich hab ja auch erwartet, dass das Windows-System langsamer ist bzw.
>> mehr CPU-Last macht, aber dass das Ergebnis so dramatisch ausfällt,
>> das hab ich mir wirklich nicht gedacht. Absoluter Murks, was MS da
>> abliefert.

> Ist das Dateisystem-Caching vergleichbar konfiguriert?

Dürfte hier keine Rolle spielen, denn ich schreibe nur und lese keine
Nutzdaten.

[toc] | [prev] | [next] | [standalone]

#535170

From	Andreas Kohlbach <ank@spamfence.net>
Date	2021-12-25 05:16 -0500
Message-ID	<87lf09q9au.fsf@usenet.ankman.de>
In reply to	#535157

On Sat, 25 Dec 2021 03:04:22 +0100, Bonita Montero wrote:
>
>>> Heißt bei mir ein kleines Programm mit dem ich die Performance für
>>> Filesystem-Metadaten von Windows / NTFS ggü. Linux / ext4 getestet
>>> habe. [..]> Wenn ich aus 100 Threads paral-
>>> lel je 1.000 files à 4kB in Serie kreieren lasse, dann ist ext4 unter
>>> Linux etwas mehr als 20 mal so schnell wie Windows und Windows ver-
>>> braucht für die selbe Aufgabe fast 200 mal mehr CPU-Zeit.
>
>> CPU-Zeit oder Zeit?
>
> CPU-Zeit bzw. es wird auf dem Windows-Rechner ein wenig mehr CPU-Zeit
> als Walltime verbraucht.

Beinhaltet Walltime nicht auch CPU Time? Dann kann die CPU Time nicht
höher als die Walltime sein.

F'up2 de.comp.os.unix.linux.misc (ich lese die andere nicht).
-- 
Andreas

[toc] | [prev] | [next] | [standalone]

#535171

From	Gerrit Heitsch <gerrit@laosinh.s.bawue.de>
Date	2021-12-25 11:23 +0100
Message-ID	<c9543e90-18e6-960f-6189-bfdbbec60c83@laosinh.s.bawue.de>
In reply to	#535170

On 12/25/21 11:16 AM, Andreas Kohlbach wrote:
> On Sat, 25 Dec 2021 03:04:22 +0100, Bonita Montero wrote:
>>
>>>> Heißt bei mir ein kleines Programm mit dem ich die Performance für
>>>> Filesystem-Metadaten von Windows / NTFS ggü. Linux / ext4 getestet
>>>> habe. [..]> Wenn ich aus 100 Threads paral-
>>>> lel je 1.000 files à 4kB in Serie kreieren lasse, dann ist ext4 unter
>>>> Linux etwas mehr als 20 mal so schnell wie Windows und Windows ver-
>>>> braucht für die selbe Aufgabe fast 200 mal mehr CPU-Zeit.
>>
>>> CPU-Zeit oder Zeit?
>>
>> CPU-Zeit bzw. es wird auf dem Windows-Rechner ein wenig mehr CPU-Zeit
>> als Walltime verbraucht.
> 
> Beinhaltet Walltime nicht auch CPU Time? Dann kann die CPU Time nicht
> höher als die Walltime sein.

Auf einem System mit mehr als einer CPU schon.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#535178

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-12-25 11:51 +0100
Message-ID	<sq6t4e$u0p$1@dont-email.me>
In reply to	#535170

>> CPU-Zeit bzw. es wird auf dem Windows-Rechner ein wenig mehr CPU-Zeit
>> als Walltime verbraucht.

> Beinhaltet Walltime nicht auch CPU Time? Dann kann die CPU Time nicht
> höher als die Walltime sein.

Doch, kann die weil mehre HW-Threads ja gleichzeitig CPU-Zeit verbraten
können.

> F'up2 de.comp.os.unix.linux.misc (ich lese die andere nicht).

Absolut egoistisch. Lass es so wie es ist, deine Gruppe wird ja
weiterhin bedient. Das ist echt eine komplett idiotische Verhal-
tensweise zu fordern, dass man alle ge-x-posteten Newsgroups auf
Follow-Ups checkt.
FUp2 sollten eigentlich nur dazu dienen, dass wenn ein Thema in
einer Guppe nicht mehr on-topic ist die Follow-Ups an eine passen-
dere Gruppe weiterzuleiten. Ich meine es ist ja weiterhin in bei-
den Gruppen on-topic, also was soll das ?

[toc] | [prev] | [next] | [standalone]

#535192

From	Andreas Kohlbach <ank@spamfence.net>
Date	2021-12-25 12:01 -0500
Message-ID	<87mtkopqit.fsf@usenet.ankman.de>
In reply to	#535178

On Sat, 25 Dec 2021 11:51:58 +0100, Bonita Montero wrote:
>
>>> CPU-Zeit bzw. es wird auf dem Windows-Rechner ein wenig mehr CPU-Zeit
>>> als Walltime verbraucht.
>
>> Beinhaltet Walltime nicht auch CPU Time? Dann kann die CPU Time nicht
>> höher als die Walltime sein.
>
> Doch, kann die weil mehre HW-Threads ja gleichzeitig CPU-Zeit verbraten
> können.

Okay, an parallele Verarbeitung hatte ich nicht gedacht.

Danke auch an Gerrit (dessen Antwort zusätzlich auch per Mail kam).

>> F'up2 de.comp.os.unix.linux.misc (ich lese die andere nicht).
>
> Absolut egoistisch. Lass es so wie es ist, deine Gruppe wird ja
> weiterhin bedient. Das ist echt eine komplett idiotische Verhal-
> tensweise zu fordern, dass man alle ge-x-posteten Newsgroups auf
> Follow-Ups checkt.
> FUp2 sollten eigentlich nur dazu dienen, dass wenn ein Thema in
> einer Guppe nicht mehr on-topic ist die Follow-Ups an eine passen-
> dere Gruppe weiterzuleiten. Ich meine es ist ja weiterhin in bei-
> den Gruppen on-topic, also was soll das ?

AFAIK gilt X'post *ohne* F'up als unfein. Nur aus diesem Grund machte ich
das. Oder hat sich das geändert?

Ich lasse das X'post ohne F'up...
-- 
Andreas

[toc] | [prev] | [next] | [standalone]

#535368

From	Hendrik van der Heijden <hvdh@gmx.de>
Date	2021-12-26 22:12 +0100
Message-ID	<sqalrt$n7i$1@solani.org>
In reply to	#535157

Am 25.12.2021 um 03:04 schrieb Bonita Montero:
>> Ist das Dateisystem-Caching vergleichbar konfiguriert?
> 
> Dürfte hier keine Rolle spielen, denn ich schreibe nur und lese keine
> Nutzdaten.

Doch, beim Schreiben ist das total relevant, mehr als beim Lesen.
Das entscheidet, ob und wann was konsistent und persitiert sein muss.
Strengstenfalls muss jeder fclose-Call warten, bis alle (Meta)Daten
von der Disk rückgemeldet geschrieben sind, und darf erst dann
zurückkommen. Wenn zwischendurch der Strom weg ist, sind dann alle
Dateien, deren fclose returned hat noch da.
Das andere Extrem ist volles Write Caching, wo alle Dateien
der letzten Betriebsminute oder so futsch wären.



Hendrik vdH

[toc] | [prev] | [next] | [standalone]

#535421

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-12-27 10:33 +0100
Message-ID	<sqc194$b1t$1@dont-email.me>
In reply to	#535368

Am 26.12.2021 um 22:12 schrieb Hendrik van der Heijden:

> Doch, beim Schreiben ist das total relevant, mehr als beim Lesen.

Die Betriebssysteme geben eigentlich so gut wie alle ihren freien,
also nicht zu irgendwelchen working sets gehörigen, Speicher als
Cache frei. Und ich meine: Ich schreibe da gerade mal 400MB, das
geht in jeglichen Write Buffer heutiger Systeme.
Und wenn das so relevant wäre, dann müsste das Windows-System ja
einen Vorteil haben, denn das hat 64GB DDR4-2666-ECC, während das
Linux 16GB DDR4-2133-ECC hat.

> Das entscheidet, ob und wann was konsistent und persitiert sein muss.
> Strengstenfalls muss jeder fclose-Call warten, bis alle (Meta)Daten
> von der Disk rückgemeldet geschrieben sind, ...

Nö, das macht kein Betriebssystem; das wird asynchron weggeschrieben.
Es kann also mit Leichtigkeit passieren, dass wenn das System wärhend
des Schreibens in eine gerade erstellte Datei crasht, die nach dem
Reboot nicht mehr wiederzufinden ist. Will man das nicht, dann muss
man nach dem letzten write() ein fsync() machen; dann sind alle Meta-
und Nutzdaten der vorangegangenen Änderungen persistetn.

> Wenn zwischendurch der Strom weg ist, sind dann alle
> Dateien, deren fclose returned hat noch da.

Das ist einwandfrei falsch, s.O.

[toc] | [prev] | [next] | [standalone]

#535425

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-12-27 11:21 +0100
Message-ID	<sqc42k$q3r$1@dont-email.me>
In reply to	#535421

Am 27.12.2021 um 10:33 schrieb Bonita Montero:

>> Wenn zwischendurch der Strom weg ist, sind dann alle
>> Dateien, deren fclose returned hat noch da.
> 
> Das ist einwandfrei falsch, s.O.

So, ich habs gerade mal übeprüft. Und zwar hab ich in mein Progrämmchen
eine Funktion eingebaut die FlushFileBuffers() bzw. fsync() nach dem
Schreiben in die Datei und vor dem Schließen macht.
Ich hab das Ganze gerade mal unter Linux mit dem Ryzen 7 1800X / 16GB
Rechner ausprobiert, und da dauert das Schreiben von 100.000 Dateien
aus 100 Threads in ein Verzeichnis ohne Flushing 2,218s, mit Flushing
vor jedem close() 19,850s. Unter Windows dauert das ohne Flushing
48,184s, mit Flushing 83,795s. Würde beim Schließen einer Datei
automatisch geflusht, dann gäb's ja keine Unterscheide.


#if defined(_MSC_VER)
	#include <Windows.h>
#elif defined(__unix__)
	#include <fcntl.h>
	#include <unistd.h>
#endif
#include <iostream>
#include <system_error>
#include <vector>
#include <thread>
#include <cassert>
#include <sstream>
#include <mutex>
#include <exception>
#include <iomanip>
#include <charconv>
#include <stdexcept>
#include <cstring>
#include <type_traits>

using namespace std;

#if defined(_MSC_VER)
using handle_t = HANDLE;
#elif defined(__unix__)
using handle_t = int;
#endif

template<typename ParseType>
	requires is_scalar_v<ParseType>
static ParseType parseInt( char const *str );
static void throwSysErr( char const *errStr );
static void changeDir( char const *path );
static handle_t createFile( char const *fileName );
static void closeFile( handle_t handle );
static void writeFile( handle_t handle, void const *p, unsigned n );
static void flushFile( handle_t handle );
static void whatExit( char const *what );

int main( int argc, char **argv )
{
	try
	{
		vector<char> writeBuff;
		bool flush;
		auto theThread = [&]( string prefix, unsigned nFilesPerThread )
		{
			try
			{
				ostringstream ossSuffix;
				for( unsigned iFile = nFilesPerThread; iFile--; )
				{
					ossSuffix.str( "" );
					ossSuffix << prefix << setfill( '0' ) << setw( 16 ) << hex << iFile;
					handle_t h = createFile( ossSuffix.str().c_str() );
					if( writeBuff.size() )
						try
						{
							writeFile( h, &writeBuff[0], (unsigned)writeBuff.size() );
						}
						catch( ... )
						{
							closeFile( h );
							throw;
						}
					if( flush )
						flushFile( h );
					closeFile( h );
				}
			}
			catch( exception &exc )
			{
				whatExit( exc.what() );
			}
		};
		if( argc < 1 + 4 )
			return EXIT_FAILURE;
		changeDir( argv[1] );
		unsigned nThreads = parseInt<unsigned>( argv[2] ),
		         nFilesPerThread = parseInt<unsigned>( argv[3] ),
		         fileSize = parseInt<unsigned>( argv[4] );
		flush = argc == 1 + 5;
		vector<jthread> threads;
		threads.reserve( nThreads );
		writeBuff.resize( fileSize );
		ostringstream ossPrefix;
		for( unsigned iThread = nThreads; iThread--; )
		{
			ossPrefix.str( "" );
			ossPrefix << setfill( '0' ) << setw( 16 ) << hex << iThread;
			threads.emplace_back( theThread, ossPrefix.str(), nFilesPerThread );
		}
	}
	catch( exception &exc )
	{
		whatExit( exc.what() );
	}
}

template<typename ParseType>
	requires is_scalar_v<ParseType>
static ParseType parseInt( char const *str )
{
	ParseType p;
	from_chars_result fcr = from_chars( str, str + strlen( str ), p );
	if( fcr.ec != errc() || *fcr.ptr )
		throw invalid_argument( "parameter-error" );
	return p;
}

static void throwSysErr( char const *errStr )
{
#if defined(_MSC_VER)
	int errc = GetLastError();
#elif defined(__unix__)
	int errc = errno;
#endif
	throw system_error( error_code( errc, system_category() ), errStr );
}

static void changeDir( char const *path )
{
#if defined(_MSC_VER)
	if( !SetCurrentDirectoryA( path ) )
#elif defined(__unix__)
	if( chdir( path ) )
#endif
	{
		ostringstream oss;
		oss << "Can't set current directory to \"" << path << "\"";
		throwSysErr( oss.str().c_str() );
	}
}

static handle_t createFile( char const *fileName )
{
#if defined(_MSC_VER)
	handle_t handle = CreateFileA( fileName, GENERIC_READ | GENERIC_WRITE, 
0, nullptr, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL );
	if( handle == INVALID_HANDLE_VALUE )
		throwSysErr( "CreateFile() failed" );
#elif defined(__unix__)
	int handle = creat( fileName, S_IRUSR | S_IWUSR );
	if( handle == -1 )
		throwSysErr( "creat() failed" );
#endif
	return handle;
}

static void closeFile( handle_t handle )
{
#if defined(_MSC_VER)
	BOOL succ = CloseHandle( handle );
#elif defined(__unix__)
	bool succ = !close( handle );
#endif
	assert(succ);
}

static void writeFile( handle_t handle, void const *p, unsigned n )
{
#if defined(_MSC_VER)
	DWORD dwWritten;
	if( !WriteFile( handle, p, n, &dwWritten, nullptr ) || dwWritten != n )
		throwSysErr( "WriteFile() failed" );
#elif defined(__unix__)
	if( write( handle, p, n ) != n )
		throwSysErr( "write() failed" );
#endif
}

static void flushFile( handle_t handle )
{
#if defined(_MSC_VER)
	if( !FlushFileBuffers( handle ) )
#elif defined(__unix__)
	if( fsync( handle ) )
#endif
		throwSysErr( "flushin file-bufferes failed" );
}

static void whatExit( char const *what )
{
	static mutex mtx;
	lock_guard lock( mtx );
	cout << what << endl;
#if defined(_MSC_VER)
	ExitProcess( EXIT_FAILURE );
#elif defined(__unix__)
	::exit( EXIT_FAILURE );
#endif
}

[toc] | [prev] | [next] | [standalone]

#535499

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-12-27 18:32 +0100
Message-ID	<sqctb2$vg4$1@dont-email.me>
In reply to	#535425

Am 27.12.2021 um 11:21 schrieb Bonita Montero:
> Am 27.12.2021 um 10:33 schrieb Bonita Montero:
> 
>>> Wenn zwischendurch der Strom weg ist, sind dann alle
>>> Dateien, deren fclose returned hat noch da.
>>
>> Das ist einwandfrei falsch, s.O.
> 
> So, ich habs gerade mal übeprüft. Und zwar hab ich in mein Progrämmchen
> eine Funktion eingebaut die FlushFileBuffers() bzw. fsync() nach dem
> Schreiben in die Datei und vor dem Schließen macht.
> Ich hab das Ganze gerade mal unter Linux mit dem Ryzen 7 1800X / 16GB
> Rechner ausprobiert, und da dauert das Schreiben von 100.000 Dateien
> aus 100 Threads in ein Verzeichnis ohne Flushing 2,218s, mit Flushing
> vor jedem close() 19,850s. Unter Windows dauert das ohne Flushing
> 48,184s, mit Flushing 83,795s. Würde beim Schließen einer Datei
> automatisch geflusht, dann gäb's ja keine Unterscheide.

Übrigens noch ein interessantes Phänomen: Wenn ich unter Linux die
Anzahl der Threads in der flushenden Variante verzehnfache und die
Anzahl der Files pro Thread dafür auf ein Zehntel reduziere, dann
sinkt die Verarbeitungszeit von besagten 19,*s auf ca. 10s. Will
heißen, dass weil es mehr Theads gibt die parallel auf die Vollen-
dung des Flushens warten der Durchsatz eben entsprechend steigt.
Wenn ich das gleiche unter Windows mache, dann _steigt_ die Ver-
arbeitungs-Zeit um 9s, d.h. Windows serialisiert wohl die Opera-
tionen unter den Threads, was alles andere als optimal ist. In
dem Fall ergibt sich also ein Effizienz-Verhältnis von 9 : 1 für
Linux.

[toc] | [prev] | [next] | [standalone]

#535568

From	Dietz Proepper <dietz-usenet@rotfl.franken.de>
Date	2021-12-28 11:33 +0100
Message-ID	<20211228113341.247d24ad.dietz-usenet@rotfl.franken.de>
In reply to	#535499

Bonita Montero <Bonita.Montero@gmail.com> wrote:

(Vorausgeschickt - mit Windoze habe ich mich recht gut ausgekannt als
man es noch "NT" nannte ...)

> Übrigens noch ein interessantes Phänomen: Wenn ich unter Linux die
> Anzahl der Threads in der flushenden Variante verzehnfache und die
> Anzahl der Files pro Thread dafür auf ein Zehntel reduziere, dann
> sinkt die Verarbeitungszeit von besagten 19,*s auf ca. 10s. Will
> heißen, dass weil es mehr Theads gibt die parallel auf die Vollen-
> dung des Flushens warten der Durchsatz eben entsprechend steigt.
> Wenn ich das gleiche unter Windows mache, dann _steigt_ die Ver-
> arbeitungs-Zeit um 9s, d.h. Windows serialisiert wohl die Opera-
> tionen unter den Threads, was alles andere als optimal ist. In
> dem Fall ergibt sich also ein Effizienz-Verhältnis von 9 : 1 für
> Linux.

Versuch' doch mal, die Zahl an I/O-Ops im Vergleich zu den
(FS-)Meta-Ops zu erhöhen. Wenn ich die Parameter Deines Testprogramms
richtig verstehe, etwas der Art "testdir 1000 1 40960000".

Die reine I/O-Leistung sollte in der gleichen Größenordnung liegen.
Allerdings sind Metaoperationen (create(dir), close, unlink & friends)
bei NTFS schon immer um einige Größenordnungen lahmer als bei z.B. ext4,
zumindest mit den Defaulteinstellungen (atime-Updates, Journalverhalten,
"etc."). Tante Google sollte auf "ntfs optimization"
einiges an Antworten ausspucken.

Achja, es auf wirklich identischer Hardware auszuprobieren wäre
natürlich auch interessant.

[toc] | [prev] | [next] | [standalone]

#535573

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-12-28 11:47 +0100
Message-ID	<sqeq05$nea$1@dont-email.me>
In reply to	#535568

Am 28.12.2021 um 11:33 schrieb Dietz Proepper:

> Versuch' doch mal, die Zahl an I/O-Ops im Vergleich zu den
> (FS-)Meta-Ops zu erhöhen. Wenn ich die Parameter Deines Testprogramms
> richtig verstehe, etwas der Art "testdir 1000 1 40960000".

Das versteht sich von selbst, dass dann die Performance unter beiden
Systemen ähnlicher wird. Ich hab's gersde mal mit 4096000 (eine Null
weniger) probiert und da ist das Linux-System nach 4,935s fertig, das
Windows-System nach 7,505s.

> Achja, es auf wirklich identischer Hardware auszuprobieren wäre
> natürlich auch interessant.

Eigentlich egal weil die Cache-Größe nicht relevant ist und nichmtal
die 8-Kern-CPU am Maximum der Leistung anschlägt, geschweige denn die
64-Kern-CPU.

[toc] | [prev] | [next] | [standalone]

#535697

From	Dietz Proepper <dietz-usenet@rotfl.franken.de>
Date	2021-12-29 00:12 +0100
Message-ID	<20211229001253.6db9ce92.dietz-usenet@rotfl.franken.de>
In reply to	#535573

Bonita Montero <Bonita.Montero@gmail.com> wrote:

> Am 28.12.2021 um 11:33 schrieb Dietz Proepper:
> 
> > Versuch' doch mal, die Zahl an I/O-Ops im Vergleich zu den
> > (FS-)Meta-Ops zu erhöhen. Wenn ich die Parameter Deines
> > Testprogramms richtig verstehe, etwas der Art "testdir 1000 1
> > 40960000".  
> 
> Das versteht sich von selbst, dass dann die Performance unter beiden
> Systemen ähnlicher wird. Ich hab's gersde mal mit 4096000 (eine Null
> weniger) probiert und da ist das Linux-System nach 4,935s fertig, das
> Windows-System nach 7,505s.

Ui. 50% Aufschlag? Das ist sonderbar.

> > Achja, es auf wirklich identischer Hardware auszuprobieren wäre
> > natürlich auch interessant.  
> 
> Eigentlich egal weil die Cache-Größe nicht relevant ist und nichmtal
> die 8-Kern-CPU am Maximum der Leistung anschlägt, geschweige denn die
> 64-Kern-CPU.

Es ist halt wenig sinnvoll, solche Benchmarks auf ggf. sehr unter-
schiedlichen Systemen zu betreiben.

Hast Du wenigstens versucht, dem NTFS noatime beizubringen?

[toc] | [prev] | [next] | [standalone]

#535712

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-12-29 06:20 +0100
Message-ID	<sqgr70$833$1@dont-email.me>
In reply to	#535697

Am 29.12.2021 um 00:12 schrieb Dietz Proepper:

> Es ist halt wenig sinnvoll, solche Benchmarks auf ggf. sehr unter-
> schiedlichen Systemen zu betreiben.

Überhauptnicht, denn es soll ja die unterschiedliche Effizienz
der Systeme messen.

> Hast Du wenigstens versucht, dem NTFS noatime beizubringen?

Würde sicher wenig Unterschied machen.

[toc] | [prev] | [next] | [standalone]

#535713

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-12-29 06:29 +0100
Message-ID	<sqgro4$f95$1@dont-email.me>
In reply to	#535712

>> Hast Du wenigstens versucht, dem NTFS noatime beizubringen?

> Würde sicher wenig Unterschied machen.

Hab's gerade ausbprobiert: so gut wie kein Unterschied.

[toc] | [prev] | [next] | [standalone]

#535753

From	Dietz Proepper <dietz-usenet@rotfl.franken.de>
Date	2021-12-29 10:49 +0100
Message-ID	<20211229104904.7f875513.dietz-usenet@rotfl.franken.de>
In reply to	#535712

Bonita Montero <Bonita.Montero@gmail.com> wrote:

> Am 29.12.2021 um 00:12 schrieb Dietz Proepper:
> 
> > Es ist halt wenig sinnvoll, solche Benchmarks auf ggf. sehr unter-
> > schiedlichen Systemen zu betreiben.  
> 
> Überhauptnicht, denn es soll ja die unterschiedliche Effizienz
> der Systeme messen.

Bittewie? Wolltest Du nicht die Effizienz von Windows im Vergleich zu
Linux messen?

Den Vergleich "Windows auf Hardware A" und "Linux auf Hardware B" kann
man schon machen. Welchen Erkenntnisgewinn das bringen soll ist eine
andere Frage.

> > Hast Du wenigstens versucht, dem NTFS noatime beizubringen?  
> 
> Würde sicher wenig Unterschied machen.

Tipp, beschäftige dich mal ein wenig mit elementaren Grundlagen zum
Thema "Messung".

[toc] | [prev] | [next] | [standalone]

#535766

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-12-29 11:58 +0100
Message-ID	<sqhf1b$csq$1@dont-email.me>
In reply to	#535753

Am 29.12.2021 um 10:49 schrieb Dietz Proepper:

>> Überhauptnicht, denn es soll ja die unterschiedliche Effizienz
>> der Systeme messen.

> Bittewie? Wolltest Du nicht die Effizienz von Windows im Vergleich zu
> Linux messen?

Indem ich gleichartige Operationen anstoße und die Zeit dafür
messe. Das erlaubt einen Vergleich der unterschiedlichen Effizienz.
Die SSDs sind die selben, die CPU schlägt auf keinem der beiden
Systeme am Maximum an, d.h. das ist schon mal nur relevant, also
sind hier nur die Datenstrukturen und Algorithmen der Betriebssysteme
relevant.

> Tipp, beschäftige dich mal ein wenig mit elementaren Grundlagen zum
> Thema "Messung".

Du bist ein Depp.

[toc] | [prev] | [next] | [standalone]

#535767

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2021-12-29 11:59 +0100
Message-ID	<sqhf2l$csq$2@dont-email.me>
In reply to	#535766

Am 29.12.2021 um 11:58 schrieb Bonita Montero:
> Am 29.12.2021 um 10:49 schrieb Dietz Proepper:
> 
>>> Überhauptnicht, denn es soll ja die unterschiedliche Effizienz
>>> der Systeme messen.
> 
>> Bittewie? Wolltest Du nicht die Effizienz von Windows im Vergleich zu
>> Linux messen?
> 
> Indem ich gleichartige Operationen anstoße und die Zeit dafür
> messe. Das erlaubt einen Vergleich der unterschiedlichen Effizienz.
> Die SSDs sind die selben, die CPU schlägt auf keinem der beiden
> Systeme am Maximum an, d.h. das ist schon mal nur relevant, also
                                                 ^^^ nicht
> sind hier nur die Datenstrukturen und Algorithmen der Betriebssysteme
> relevant.
> 
>> Tipp, beschäftige dich mal ein wenig mit elementaren Grundlagen zum
>> Thema "Messung".
> 
> Du bist ein Depp.
>

[toc] | [prev] | [next] | [standalone]

#535770

From	Dietz Proepper <dietz-usenet@rotfl.franken.de>
Date	2021-12-29 12:01 +0100
Message-ID	<20211229120141.0bab7cfe.dietz-usenet@rotfl.franken.de>
In reply to	#535766

Bonita Montero <Bonita.Montero@gmail.com> wrote:

> Am 29.12.2021 um 10:49 schrieb Dietz Proepper:
> 
> >> Überhauptnicht, denn es soll ja die unterschiedliche Effizienz
> >> der Systeme messen.  
> 
> > Bittewie? Wolltest Du nicht die Effizienz von Windows im Vergleich
> > zu Linux messen?  
> 
> Indem ich gleichartige Operationen anstoße und die Zeit dafür
> messe. Das erlaubt einen Vergleich der unterschiedlichen Effizienz.
> Die SSDs sind die selben, die CPU schlägt auf keinem der beiden
> Systeme am Maximum an, d.h. das ist schon mal nur relevant, also
> sind hier nur die Datenstrukturen und Algorithmen der Betriebssysteme
> relevant.

Aber klar doch. *Tätschel*.

> > Tipp, beschäftige dich mal ein wenig mit elementaren Grundlagen zum
> > Thema "Messung".  
> 
> Du bist ein Depp.

Und ab ins Körbchen.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2 [1] 2 Next page →

csiph-web

A thousand files ...

Contents

#535142 — A thousand files ...

#535146

#535157

#535170

#535171

#535178

#535192

#535368

#535421

#535425

#535499

#535568

#535573

#535697

#535712

#535713

#535753

#535766

#535767

#535770