🚀 go-pugleaf

> Nie, nie musi być, nawet pomijając mniej lub bardziej dziwne składnie.
> Można zawsze pisać swoje procedurki w osobnym pliku, kompilować
> osobno i dopiero linkować razem. Ale płaci się za to wywołaniem CALL,
> stosem itd.


Czyli, tradycyjnie - znaj proporcjum, mocium panie! ;-)
Nauka jest taka, że sens ma "owstawkowanie" W CAŁOŚCI bloków wydzielonych funkcjonalnie z programu (niekoniecznie w postaci osobnej procedury).



> Większość funkcji C działa na łańcuchach znaków kończących się bajtem
> zerowym, bo po prostu tak są zdefiniowane łańcuchy znaków w C.


long int strtol (const char* str, char** endptr, int base)
double strtod (const char* str, char** endptr)

Funkcja zwraca przekonwertowaną wartość, zwraca również (przez referencję endptr) wskaźnik do pierwszego znaku ZA przekonwertowanym ciągiem cyfr.
Jakiekolwiek gmeranie w bajtach dalej odbieram jako RAŻĄCY BŁĄD - chyba, że ktoś mnie przekona, że jest w tym jakiś głębszy sens



> Można zawsze np. zmienić '\n' lub kropkę na bajt zerowy '\0' i
> dopiero takim "stuningowanym" łańcuchem nakarmić strdo*().


Można różne rzeczy, ale "ręczne" parsowanie ciągu bajtów w celu stworzenia złudzenia jakiejś użyteczności zrypanej funkcji standardowej budzi u mnie wewnętrzny sprzeciw.



> Pewnie poziom optymalizacji większy od zera?


Poziom optymalizacji, to takie trochę czary-mary-makagigi.
Kod wynikowy - to jest konkret. :-)



> Natomiast można oszczędzić w innych miejscach, np. I/O jest powolne -
> nie wyświetlaj na ekran ani nie zapisuj do pliku po jednym czy kilku
> bajtach. Buforuj i zapisuj cały bufor na raz. Tak samo z odczytem.


O czym ta mowa... ;-)

Korzystając z prostych środków napisałem program, który wykonuje swoją pracę w niecałe pół sekundy, podczas gdy jego wersja "kanoniczna" robiła to samo w ponad cztery - już z uwzględnieniem buforowania.
To jest zysk wyłącznie na optymalizacji I/O, i to nawet bez powąchania asemblera. ;-)
Sprzętowo takie przyśpieszenie mógłby zapewnić chyba upgrade do jakiegoś i7 z 2026 roku - a i to wątpliwe, bo ostatnio gęstnieją narzekania, że z coś nie ten-tego z Prawem Moore'a...

W ogóle taką "masówkę" powinno się załatwiać w wątku niezależnym od GUI, a już najlepiej temat zrównoleglić.
Tylko jak zrównoleglić sekwencyjny odczyt z pliku?
Można by stanąć gdzieś w środku bufora, złapać na szybko koniec linii i puścić drugi wątek parsujący.
Jeszcze tylko trzeba upchać jakoś dane z dwóch wątków, wiedząc, że wyszukiwać w nich będzie funkcja hashująca...

Choroba, samo pisanie na tej grupie jest inspirujące! :-)



> Jeśli kompilujesz C z optymalizacjami, to wygrać z kompilatorem w
> tych czasach może być ciężko.


Taki kod w C:


QueryPerformanceCounter(&StartCounter);

*cptr = 0x0;
while (iValue)
{
   *--cptr = char(iValue % 10) | '0';
   iValue /= 10;
}

QueryPerformanceCounter(&EndCounter);


wypluty przez MinGW do kodu asemblera wygląda tak:



	call	_QueryPerformanceCounter@4
	subl	$4, %esp
	movl	$2137483647, %ecx
	leal	143(%esp), %ebx
	leal	133(%esp), %edi
	movb	$0, 143(%esp)
	.p2align 4,,10
L2:
	movl	%ecx, %eax
	subl	$1, %ebx
	imull	%esi
	movl	%ecx, %eax
	sarl	$31, %eax
	sarl	$2, %edx
	subl	%eax, %edx
	leal	(%edx,%edx,4), %eax
	addl	%eax, %eax
	subl	%eax, %ecx
	orl	$48, %ecx
	cmpl	%edi, %ebx
	movb	%cl, (%ebx)
	movl	%edx, %ecx
	jne	L2
	leal	72(%esp), %eax
	movl	%eax, (%esp)
	call	_QueryPerformanceCounter@4
	subl	$4, %esp


Zakładam, że cała akcja dzieje się pomiędzy dwoma wywołaniami QueryPerformanceCounter.
Da się tu coś istotnego wywalić?
Na moje oko (skłute składnią AT&T :D) kompilator wyłapał i uwzględnił sąsiadujące modulo i dzielenie przez 10.
A wtedy - nic tu się nie urwie (ponad poziom szumu).


Czym się kurde różni SAR od SHR?