Article View: pl.comp.lang.c
Article #310435Podsumowanie Projektu Liczniki - programowanie i wydajność różnych j. prog.
From: Jacek Marcin Jaworski
Date: Sun, 15 Jan 2023 19:27
Date: Sun, 15 Jan 2023 19:27
182 lines
14266 bytes
14266 bytes
Podsumowanie Projektu Liczniki
autor: Jacek Marcin Jaworski
pseudonim: Energo Koder
utworzono: 2022-09-17
wersja: 167 z dnia: 2023-01-15
system: Linux (distro: Kubuntu)
program: LibreOffice
Spis treści
1 Wstęp.................................................................................................................................................................. 3
2 licznik.sh............................................................................................................................................................. 3
3 licznik.py............................................................................................................................................................. 3
4 licznik.d............................................................................................................................................................... 3
5 licznik.c++........................................................................................................................................................... 4
6 Porównanie jakości kodu.................................................................................................................................. 4
7 Porównanie ilości kodu..................................................................................................................................... 5
8 Porównanie wydajności.................................................................................................................................... 5
9 Podsumowanie.................................................................................................................................................. 5
10 2022-12-28:...................................................................................................................................................... 6
1 Wstęp
Od kiedy zacząłem programować zawsze intrygowało mnie ile linii kodu mają moje programy
oraz ile linii mają programy popularnych projektów o otwartych źródłach. Początkowo prowadziło to
do cudakowania i szacowania ilości linii ze wzoru: objętość plików z kodem w bajtach / 32 znaki.
Wynikało to z obserwacji, że śr. dł. linii w C++ to ok. 32 znaki.
W latach 2004-2022 zrealizowałem projekt energo-liczniki. Taka długotrwałość projektu wynika z jego
rozszerzania z upływem lat. Od razu miałem zamiar zakodować wersje w Baszu i w Pytonie. W ten
sposób chciałem poznać te języki skryptowe. Dodatkowo okazało się, że jest to świetna okazja by
poznać wyrażenia regularne. W 2022r. stwierdziłem, że rozbudowana wersja w Pytonie powinna być
uproszczona, gdyż algorytm skanowania nie był sprawdzony pod względem poprawności. Dodatkowo
mógł on działać poprawnie tylko dla niektórych języków programowania (pochodnych C). W 2022r.
spolonizowałem liczniki w Baszu i Pytonie - wynikało to z logicznego wniosku, że w Polsce należy
myśleć, mówić, pisać i programować po polsku. W 2022r. zaprogramowałem wersję w D i C++ - dają
one takie same wyniki jak wersja w Pytonie. Celem było uzyskanie możliwości porównania tych
najważniejszych dla mnie języków programowania.
Liczniki to programy w j. C++ i D oraz skrypty w j. Basz i Pyton służą one do badania ilości linii w kodach
źródłowych programów. Są to programy konsolowe zwracające wyniki skanowania na konsolę. Wersja
w j. Basz ma prostsze opcje. Wynika to z faktu, że opiera się ona na standardowych programach
konsoli do przetwarzania tekstów. Wersje w Pytonie, D i C++ mają więcej opcji jednak zwracają wyniki
w takim samym formacie co wersja w Baszu.
W dawniejszych czasach używałem systemów Linuks i Windows. Z tamtych dawnych czasów wynikało
ciekawe spostrzeżenie, że wersja Basz działa szybciej na Linuksie, natomiast wersja w Pytonie działała
szybciej na Windowsie. Wyglądało na to, że w Windows funkcje plikowe są b. wolne i b. wolno tworzy
on nowe procesy i wolno je likwiduje. Obecnie jednak używam wyłącznie systemu Linuks i nie jestem w
stanie porównać działania liczników na systemie Windows.
2 licznik.sh
Jest to skrypt w j. Basz. Jest oparty na standardowych programach konsoli takich jak find i wc.
Jego cechą szczególną jest to, że używa programu parallel do zrównoleglenia skanowania plików
źródłowych. Ciekawe jest to, że na procesorze Intel i7 10510 z 4 podwójnymi rdzeniami użycie parallel
spowalnia skrypt. To bardzo dziwne bo znaczy to, że program parallel jest niewydajny mimo banalnego
zadania jakie wykonuje.
3 licznik.py
Jest to skrypt w języku Pyton. Działa całkowicie sekwencyjnie.
4 licznik.d
Jest to program w języku D. Działa całkowicie sekwencyjnie.
5 licznik.c++
Jest to program w języku C++. Jego cechą szczególną jest zastosowanie mojej biblioteki energo-
protekcja. W jej skład wchodzi klasa Katalog która jest w stanie pobierać listy plików i w wątkach je
klasyfikować wg zadanego wyrażenia regularnego. Została ona użyta w tym programie.
6 Porównanie jakości kodu
Rewelacje Zalety Wady Partactwa
licznik.sh + Prostota; + Dokumenty - Brak debugera; - exit 1 nie działa w
+ parallel: miejscowe; - Podatność na f.;
Równoległe + F. działają tak jak literówki; -
skanowanie standardowe - Proceduralna Przekomplikowane
plików; programy konsoli; architektura; getopt;
+ shellcheck - Brak rozdzielenia - Archaiczna,
deklaracji i definicji nietypowa składnia
f. wyr. reg.;
licznik.py + Składnia oparta + Standardowa - Brak rozdzielenia
na wcięciach; składnia wyr. reg.; deklaracji i definicji
+ Obiektowość: + W konst. i dest. f.;
wzorzec wizytator; działają f. wirt. - Utrudniona
+ Wyjątki; nawigacja po
kodzie z powodu
nie wydzielenia
klas do plików;
- Brak IDE z
debugerem;
licznik.d + Genialna f. + Standardowa - Brak rozdzielenia Niestandardowe
getopt; składnia wyr. reg. deklaracji i definicji operatory do
+ Obiektowość: + W konst. i dest. f.; łączenia tablic i
wzorzec wizytator. działają f. wirt. - Utrudniona napisów: ~ i ~=;
+ Działa nawigacja po
dziedziczenie kodzie z powodu
operatorów. nie wydzielenia
klas do plików;
- Brak IDE z
debugerem;
licznik.c++ + Obiektowość: + Podział QRegularExpressio - W konstruktorach
wzorzec wizytator i programu na pliki n: Alternatywa i destruktorach nie
jasna architektura; deklaracji i definicji kilku wyr. reg. działają f. wirtualne
+ Rozdzielnie klas; wymaga - jednak tylko w
deklaracji klas i f. niegrupujących odniesieniu do
od ich definicji; nawiasów; obiektu *this1;
+ Wygodna - Nie działa
kontrola pam. dziedziczenie
sprytnym wsk. operatorów;
QSharedPointer; - Ręcznie trzeba
+ Kl. Katalog z wskazywać f.
klasyfikacją ścieżek wstawiane.
w wątkach.
7 Porównanie ilości kodu
Ilość linii
licznik.sh 217
licznik.py 290
licznik.d 303
licznik.c++ 627
8 Porównanie wydajności
Czas skanowania kat. energo-protekcja
licznik.sh [Sekwencyjne skanowanie plików] 0,120
licznik.sh [Równoległe skanowanie plików] 0,316
licznik.py 0,114
licznik.d 0,359
licznik.c++ [Sekwencyjna klasyfikacja ścieżek] 0,246
licznik.c++ [Równoległa klasyfikacja ścieżek] 0,049
9 Podsumowanie
Liczniki kodowane w różnych językach ujawniły ich silne i słabe strony.
W programowaniu kluczowa jest zwięzłość kodu i wyrazistość architektury. Okazuje się, że są to
sprzeczne koncepcje. W tym projekcie najczytelniejsza architektura programu w C++ generuje ponad
100% więcej kodu niż równorzędny program w D.
licznik.C++ dostaje skrzydeł, gdy klasyfikuje nazwy plików wyrażeniami regularnymi w wątkach. Na 4
podwójnych rdzeniach daje to przyspieszenie 5x. To daje w standardzie klasa Katalog z mojej bibl.
1 Czyli w zagregowanych obiektach f. wirt. działają normalnie.
energo-protekcja. licznik.C++ można by dodatkowo przyspieszyć skanując pliki źródłowe w wątkach.
Nie koduję tego, bo nie zastosuję tego nigdzie indziej - dlatego szkoda na to czasu.
licznik.py działa najszybciej w śród rozwiązań sekwencyjnych.
licznik.sh w wer. sekwencyjnej działa prawie tak samo szybko jak skrypt w j. Pyton. Gdy w licznik.sh
zastosowałem zrównoleglenie skanowania plików źródłowych odnotowałem ponad 3x dłuższy czas
działania. Sprawa wyjaśniła się w d. 2022-11-19: wtedy okazało się, że konsolowy program parallel jest
skryptem w j. Perl - jasne jest, że użycie j. skryptowego w tym celu to jakiś defekt umysłowy - takich
rzeczy się nie robi. Ponad to ze stron GNU wiem, że nawet w 2022r. dalej się coś grzebie przy tym
skrypcie.
10 2022-12-28:
Wczoraj i dziś pracowałem nad dostosowaniem licznik.C++ do aktualnej wer. mojej bibl. energo-
protekcja.
W licznik.C++ uzupełniłem brakujące opcje -l|--licencja i -w|--wersja .
Ze wszystkich liczników usunąłem opcje -h|--help .
W licznik.C++ włączyłem równoległą klasyfikację plików za pomocą wyr. reg. - To spowodowało 5x
przyspieszenie na 4 podwójnych rdzeniach.
We wszystkich licznikach zmieniłem sposób zliczania linii: teraz zliczają one wyłącznie znaki nowej linii -
wynika to z faktu, że narzędzia konsoli (będące podstawą licznik.sh) nie są w stanie stwierdzić czy w
ostatniej linii są jakieś znaki, czy nie. W celu unifikacji przyjąłem, że nie obsługuję tego w pozostałych
wer. liczników.
Przy okazji ponownie przeprowadziłem testy i uzupełniłem to podsumowanie.
Technical Details
Message-ID:
<17bcac92-6b24-48ee-b353-0edc6908eee8n@googlegroups.com>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!3.eu.feeder.erje.net!feeder.erje.net!weretis.net!feeder8.news.weretis.net!news.mixmin.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mailShow Full Headers
Complete Article Headers
X-Received: by 2002:a05:620a:29d1:b0:706:7088:1fe9 with SMTP id s17-20020a05620a29d100b0070670881fe9mr30871qkp.11.1673810866145; Sun, 15 Jan 2023 11:27:46 -0800 (PST) X-Received: by 2002:a05:620a:2718:b0:705:b390:87ef with SMTP id b24-20020a05620a271800b00705b39087efmr1213749qkp.745.1673810865991; Sun, 15 Jan 2023 11:27:45 -0800 (PST) Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!3.eu.feeder.erje.net!feeder.erje.net!weretis.net!feeder8.news.weretis.net!news.mixmin.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: pl.comp.lang.c Date: Sun, 15 Jan 2023 11:27:45 -0800 (PST) Injection-Info: google-groups.googlegroups.com; posting-host=188.147.108.100; posting-account=uFgJ3goAAAAHaGlwfVGxxrSUMlvEACGk NNTP-Posting-Host: 188.147.108.100 User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <17bcac92-6b24-48ee-b353-0edc6908eee8n@googlegroups.com> Subject: Podsumowanie Projektu Liczniki - programowanie i wydajność różnych j. prog. From: Jacek Marcin Jaworski <jaworski1978@adres.pl> Injection-Date: Sun, 15 Jan 2023 19:27:46 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit