Marteno Rodia <m...@o...pl> napisał(a):
>
> Co by=B6cie proponowali?

Proponuję: Uczta Programistów - Henry S. Warren Jr.

Pzdr


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Mariusz Marszałkowski pisze:
> Jędrzej Dudkiewicz <j...@g...com> napisał(a):
>
>> bartekLTG wrote:
>>> Maciej Pilichowski wrote:
>>>> aby zawsze pisac ++var zamiast
>>>> var++


> Może tak jest wydajniej, ale czy to nie jest pomylenie idei? Język C++
> względem C i asemblera, zdecydowanie lepiej nadaje się do zarządzania
> dużymi projektami i do ponownego wykorzystania kodu. Dzięki temu
> jest optymalizowane co innego - czas i nakład ludzkiej pracy. Po co
> używać języka wysokopoziomowego i jednocześnie wnikać w niuanse kompilacji?

> Warto pamiętać że optymalizowanie zapisu może przyspieszyć program
> co najwyżej liniowo. Zoptymalizowany w ten sposób program może
> działać szybciej, ale jednocześnie przestaje być podatny na modyfikacje.
> Jeśli po pewnym czasie pracy nad programem przychodzi pomysły na
> modyfikację algorytmu, która może przyspieszyć więcej niż dobre
> zakodowanie, to prawdopodobnie będzie trzeba napisać wszystko od nowa.
> Twierdzę to w oparciu o doświadczenia jakie zdobyłem pisząc program do
> gry w szachy - optymalizowałem go na oba sposoby około roku czasu.

Miód na moje serce. Radykalnie przemyślany algorytm da (wiele) więcej
niż 'optymalizacja zapisu' (bardzo to fajnie nazwałeś)

Mariusz Marszałkowski pisze:
> Marteno Rodia <m...@o...pl> napisał(a):
>
> Np. te dwie lektury:
>
> Procesory Pentium - Michael L. Schmit
> Optymalizacja Kodu - Kris Kaspersky
>
> I z rok albo dwa doświadczenia jako koder

Otóż niekoniecznie. Bardzo rzadka (w moim odczuciu) jest sytuacja
autentycznego profilowania (i innych obiektywych metod precyzyjnej oceby
wydajności). Powiedzmy sobie wymaga to sporo determinacji, czasu i
środowiska. Znacznie częściej koderzy nabywają umiejętności przez
przekaz pomiędzy ludźmi. O ile w dziedzinie wzorców, dobrego stylu
jakość przekazu widać, to w dziedzinie optymalizacji pokutują różne
nawet przesądy których nikt obiektywnie nie weryfikuje. Często ludowe
sposoby dają zerowy lub ujemny efekt przyśpieszenia, przy zaciemnieniu kodu.
Katastrofę optymalizacyjną to widać (99% CPU i rzężący dysk itd, zresztą
nie od razu przekłada się to na diagnozę) ale jak nieoptymalnośc jest w
mniejszym stopniu to intuicja nie wsparta wiedzą często jest zawodna

Zakładam, że autor książki za to bierze kasę, że sprawdza swoje
twierdzenia w labolatorium.

do góry

Marteno Rodia wrote:
> On May 19, 11:48 am, "Mateusz Loskot" <m...@l...net> wrote:
>>> albo co jest szybsze: int array[10] czy int *array = new int[10].
>> Pierwsze to alokacja na stosie, drugie na tzw. stercie (dynamic storage)
>> Ogólna zasada przy optymalizacji, to im mniej alokacji pamięci
>> tym lepiej. Alokacja to wolna operacja.
>
> To co zrobić, żeby unikać konstrukcji spowalniających program? Pamięci
> muszę używać, a żeby używać - muszę chyba jakoś ją zaalokować.

Ale nie zawsze jej potrzebujesz, bo może już masz. Np. zamieniasz w
napisie wszystkie literki na małe, to w C++ zamiast funkcji
string strToLower(const string& x);
lepiej
void strToLower(string& x);

Ten przykład nie dotyczy akurat języków, gdzie napisy są obiektami
immutable, ale chodzi o ogólną zasadę.

--
Paweł Kierski
n...@p...net

do góry

On 21 Maj, 05:26, "Mariusz Marszałkowski"
<b...@W...gazeta.pl> wrote:

> Może tak jest wydajniej, ale czy to nie jest pomylenie idei? Język C++
> względem C i asemblera, zdecydowanie lepiej nadaje się do zarządzania
> dużymi projektami i do ponownego wykorzystania kodu. Dzięki temu
> jest optymalizowane co innego - czas i nakład ludzkiej pracy. Po co
> używać języka wysokopoziomowego i jednocześnie wnikać w niuanse kompilacji?

Moze ktos chce pisac wydajnie nie tracac mocniejszej kontroli typow i
innych 'usprawnien', ktorych nie oferuje C ;p

> Jeśli ktoś chce wydajnie zapisać program to musi użyć języka C i/albo
> asemblera. Języki te mają to do siebie, że ich kompilatory nie wstawiają
> do kodu wynikowego żadnych ukrytych wstawek. Kompilator wygeneruje to
> co napiszesz.

Jesli nie uzyje wlasciwosci, ktore potrzebuja wsparcia czy to w
runtime, czy w czasie kompilacji dodatkowego narzutu w kodzie
(virtual, exceptions, rtti), to w wyniku bedzie dokladnie to co
napisze bez zadnych wstawek (a przynajmniej powinno).

--
Pozdrowienia,
Marcin 'Malcom' Malich
m...@m...pl
http://malcom.pl

do góry

Marcin 'Malcom' Malich <m...@g...com> napisał(a):

> On 21 Maj, 05:26, "Mariusz Marsza=B3kowski"
> <b...@W...gazeta.pl> wrote:
>
> > Mo=BFe tak jest wydajniej, ale czy to nie jest pomylenie idei? J=EAzyk C+=
> +
> > wzgl=EAdem C i asemblera, zdecydowanie lepiej nadaje si=EA do zarz=B1dzan=
> ia
> > du=BFymi projektami i do ponownego wykorzystania kodu. Dzi=EAki temu
> > jest optymalizowane co innego - czas i nak=B3ad ludzkiej pracy. Po co
> > u=BFywa=E6 j=EAzyka wysokopoziomowego i jednocze=B6nie wnika=E6 w niuanse=
> kompilacji?
>
> Moze ktos chce pisac wydajnie nie tracac mocniejszej kontroli typow i
> innych 'usprawnien', ktorych nie oferuje C ;p
>
> > Je=B6li kto=B6 chce wydajnie zapisa=E6 program to musi u=BFy=E6 j=EAzyka =
> C i/albo
> > asemblera. J=EAzyki te maj=B1 to do siebie, =BFe ich kompilatory nie wsta=
> wiaj=B1
> > do kodu wynikowego =BFadnych ukrytych wstawek. Kompilator wygeneruje to
> > co napiszesz.
>
> Jesli nie uzyje wlasciwosci, ktore potrzebuja wsparcia czy to w
> runtime, czy w czasie kompilacji dodatkowego narzutu w kodzie
> (virtual, exceptions, rtti), to w wyniku bedzie dokladnie to co
> napisze bez zadnych wstawek (a przynajmniej powinno).
>

No oczywiście można napisać program w C++ bez użycia klas gdyż składnia C++
z małymi wyjątkami jest nadzbiorem składni C. Klas też lepiej nie używać,
bo jak optymalizować zapis jeśli dane są podzielone na klasy i nie ma
wszędzie do nich dostępu? Optymalizacja zapisu to żonglerka strukturą
danych. Po zmianie struktury danych zmienia się części procedur.
Obudowywanie danych w klasy (choćby jako składowe statyczne, które nie dają
narzutu) podwaja nakład pracy przy takim eksperymentowaniu. Więc powstaje
programowanie w C przy użyciu kompilatora C++ :)

Pzdr


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 21 Maj, 18:07, "Mariusz Marszałkowski"
<b...@W...gazeta.pl> wrote:

> No oczywiście można napisać program w C++ bez użycia klas gdyż składnia C++
> z małymi wyjątkami jest nadzbiorem składni C. Klas też lepiej nie używać,
> bo jak optymalizować zapis jeśli dane są podzielone na klasy i nie ma
> wszędzie do nich dostępu? Optymalizacja zapisu to żonglerka strukturą
> danych. Po zmianie struktury danych zmienia się części procedur.

A jak zoptymalizowac zapis jesli dane podzielone sa na struktury w C?

> Obudowywanie danych w klasy (choćby jako składowe statyczne, które nie dają
> narzutu) podwaja nakład pracy przy takim eksperymentowaniu. Więc powstaje
> programowanie w C przy użyciu kompilatora C++ :)

Narzutu czego?

Nie potrafie zrozumiec do czego zmierzasz :>

--
Pozdrowienia,
Marcin 'Malcom' Malich
m...@m...pl
http://malcom.pl

do góry

Marcin 'Malcom' Malich <m...@g...com> napisał(a):

> On 21 Maj, 18:07, "Mariusz Marsza=B3kowski"
> <b...@W...gazeta.pl> wrote:
>
> > No oczywi=B6cie mo=BFna napisa=E6 program w C++ bez u=BFycia klas gdy=BF =
> sk=B3adnia C++
> > z ma=B3ymi wyj=B1tkami jest nadzbiorem sk=B3adni C. Klas te=BF lepiej nie=
> u=BFywa=E6,
> > bo jak optymalizowa=E6 zapis je=B6li dane s=B1 podzielone na klasy i nie =
> ma
> > wsz=EAdzie do nich dost=EApu? Optymalizacja zapisu to =BFonglerka struktu=
> r=B1
> > danych. Po zmianie struktury danych zmienia si=EA cz=EA=B6ci procedur.
>
> A jak zoptymalizowac zapis jesli dane podzielone sa na struktury w C?

Po prostu jest mniej pracy w C. Zmienne typu strukturalnego w C (zgodnie z
ideą C) deklaruje się globalnie, wszystkie funkcje deklaruje się
globalnie, a dostęp do wszystkich danych i składowych jest publiczny.
W C++ projektując strukturę danych trzeba dodatkowo zastanowić się:
1) jakie metody będą miały dostęp do jakich danych
2) jakie składowe będą w sekcjach prywatnych, jakie w chronionych
3) jakiej hierarchii dziedziczenia użyć
Po zmianie struktury danych w C++ trzeba te kroki przejść na nowo. Te
kroki ułatwiają ponowne wykorzystanie kodu, zmniejszają podatność na
błędy, ale nie ułatwiają optymalizacji zapisu.

Np. pisząc program numeryczny w C, zadeklarujesz globalnie tablicę liczb.
Napiszesz później trzy procedury:
1) pierwsza wczyta dane z pliku do tej tablicy liczb
2) druga wykona zadanie numeryczne
3) trzecia zapisze wyniki do pliku.

Programując to samo w C++ napiszesz:
1) klasę do wczytywania danych
2) klasę do obliczeń
3) klasę do wyprowadzania danych.

Nagle zobaczysz że już podczas wczytywania danych możesz przeprowadzić
wstępne obliczenia - co przyspieszy program. Dla struktury klas w C++ nie
będzie to naturalne, ponieważ struktura danych do obliczeń jest
odseparowana w klasie obliczeń. Będziesz musiał dopisać specjalne metody
do komunikacji pomiędzy klasą wczytywania danych a klasą obliczeniową.
Być może narzut na dodatkowe metody przewyższy zysk z wstępnych obliczeń
podczas wczytywania - ale koszt metod składowych to już inna kwestia.

Natomiast w C masz w całym programie dostęp do wszystkich danych. Od razu
podczas wczytywania zrobisz wstępne obliczenia i zmodyfikujesz globalne
dane. Po prostu w C trzeba zmodyfikować mniej kodu.

Jeśli w końcu dokonasz kilku takich spostrzeżeń i kilku takich modyfikacji
kodu, obojętnie czy pisałeś w C czy w C++, to dojdziesz do wniosku że
pierwotny podział kodu i danych na logiczne bloki nie był najlepszy. Będzie
trzeba przepisać wszystko od nowa. I znów zyskasz pisząc w C, bo omijasz
podział na klasy i nie zastanawiasz się jaką składową umieścić w jakiej
klasie i w jakiej sekcji, żeby po kolejnym spostrzeżeniu cały ten
skrupulatny podział trzeba było zburzyć...

>
> > Obudowywanie danych w klasy (cho=E6by jako sk=B3adowe statyczne, kt=F3re =
> nie daj=B1
> > narzutu) podwaja nak=B3ad pracy przy takim eksperymentowaniu. Wi=EAc pows=
> taje
> > programowanie w C przy u=BFyciu kompilatora C++ :)
>
> Narzutu czego?
>
> Nie potrafie zrozumiec do czego zmierzasz :>

Narzut na dodatkowe zaprojektowanie klas. Dobre zaprojektowanie jest
czasochłonne. Klasy projektuje się po to aby kod ponownie wykorzystać
bez ponownego wnikania w ich szczegóły implementacyjne. Zaprojektowane
tak klasy nie są w żaden sposób podatne na późniejsze "sprytne modyfikacje"
w celu przyspieszenia.

Pzdr.



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Mariusz Marszałkowski pisze:
> Marcin 'Malcom' Malich <m...@g...com> napisał(a):
>
>> On 21 Maj, 18:07, "Mariusz Marsza=B3kowski"
>> <b...@W...gazeta.pl> wrote:

> Po prostu jest mniej pracy w C. Zmienne typu strukturalnego w C (zgodnie z
> ideą C) deklaruje się globalnie, wszystkie funkcje deklaruje się
> globalnie, a dostęp do wszystkich danych i składowych jest publiczny.
Jeśli chciałeś podać przykład za C (za tym stylem) to ci nie wyszło.
Brak podziału na prywatny/publiczny (w dowolny paradygmacie, czy to
stary modularnym, czy obiektowym) odbiera ci swobodę (w pr. małym) lub
blokuje *w wielkim projekcie) możliwość ulepszenia lokalnej
implementacji bez zmiany interfejsu.
Zostaje żmudna ręczna robota.
Wracając do optymalizacji, znasz takie słowo "gówna lepiej nie ruszać" -
to m.in. o programowaniu w całości na globalach. Ulepszanie zwykle nie
następuje.

ścinam się czasem z gośćmi którym się wydaje, że reprezentują
proceduralny styl pisania. Z tym że nie wiedzą, co to naprawdę jest, że
też zawiera podział na publiczne i prywatne. Trzeba by sie odwołać do
książek z lat 70-tych i sobie powtórzyć.

> W C++ projektując strukturę danych trzeba dodatkowo zastanowić się:
> 1) jakie metody będą miały dostęp do jakich danych
> 2) jakie składowe będą w sekcjach prywatnych, jakie w chronionych
> 3) jakiej hierarchii dziedziczenia użyć
> Po zmianie struktury danych w C++ trzeba te kroki przejść na nowo. Te
> kroki ułatwiają ponowne wykorzystanie kodu, zmniejszają podatność na
> błędy, ale nie ułatwiają optymalizacji zapisu.
>

>
> Natomiast w C masz w całym programie dostęp do wszystkich danych. Od razu
> podczas wczytywania zrobisz wstępne obliczenia i zmodyfikujesz globalne
> dane. Po prostu w C trzeba zmodyfikować mniej kodu.
Lub cały kod - patrz wyżej.

>
> Jeśli w końcu dokonasz kilku takich spostrzeżeń i kilku takich modyfikacji
> kodu, obojętnie czy pisałeś w C czy w C++, to dojdziesz do wniosku że
> pierwotny podział kodu i danych na logiczne bloki nie był najlepszy. Będzie
> trzeba przepisać wszystko od nowa. I znów zyskasz pisząc w C, bo omijasz
> podział na klasy i nie zastanawiasz się jaką składową umieścić w jakiej
> klasie i w jakiej sekcji, żeby po kolejnym spostrzeżeniu cały ten
> skrupulatny podział trzeba było zburzyć...
>
>>> Obudowywanie danych w klasy (cho=E6by jako sk=B3adowe statyczne, kt=F3re =
>> nie daj=B1
>>> narzutu) podwaja nak=B3ad pracy przy takim eksperymentowaniu. Wi=EAc pows=
>> taje
>>> programowanie w C przy u=BFyciu kompilatora C++ :)
>> Narzutu czego?
>>
>> Nie potrafie zrozumiec do czego zmierzasz :>
>
> Narzut na dodatkowe zaprojektowanie klas. Dobre zaprojektowanie jest
> czasochłonne.
Lepsze jest jakiekolwiek ujęcie np. z hermetyzacją (dorzuć sobie inne
postulaty) niz programowanie na globalsach. Kod z kiepskimi klasami
łatwiej ulepszysz, kod na globalsach tylko w kosz.
Układ klas choćby uwierający ogarniesz i przemyślisz. Układ setek
globalnych (publicznych) zmiennych ... możesz sobie obiecywać że ogarniesz.

> Klasy projektuje się
>
Widzisz, projektuje się. mniejszy będzie nakład pracy na konserwację,
jeśli proces projektowania(choćby niedoskonały) zachodzi (alternatywą
jest zupełny żywioł). A jeśli proces projektowania zachodzi, notacja
obiektowa lepiej wyraża 'co poeta miał na myśli'. Alternatywą jest
modularne 'stare' programowanie, ale tam też PROJEKTUJESZ co jest
prywatne, co publiczne itd.

W innej części tego wątku poparłem cię, że radykalnie mądrzejszy
algorytm da więcej niż kolanowe tricki. Niestety tym razem promujesz
ujecie gdzie trudno o wyższy wysiłek intelektualny (lub mniejszy efekt
porównywalnym wysiłkiem). Jednak tricki niż intelekt.

ujęcie obiektowe nie wzięło się z próżni, jest kolejną iteracją w
kilkudziesięcioletnim procesie rozwoju. Realizuje (na swój sposób)
kanoniczne zasady: podział na interfejs a implementację, hermetyzację,
izolację, abstrakcję i kilka innych słówek (pora już późna). Zwolennicy
OO wierzą/mają dowody, że ten styl lepiej realizuje bardzo stare postulaty.

Broń sobie ujęcia proceduralnego (modularno-proceduralnego) jak chcesz,
ale sorry troszkę głębiej to poznaj. Złap jakaś zżólknietą książke i
poznaj temat.

Małe CV: W 1990 prowadziłem (w zespole) system w C migrowany na C++
(oczywiście przez etap C z klasami, a jeszcze wczesiej był eta
obiektowym w swym sensie jeszcze w notacji w C) na drobne Hmmm set tyś
linii. Ale mogę kurna czegoś nie wiedzieć.

PS. Jest taki podzbiór programowania w CPP (i to spory) gdzie nie ma
mierzalnych narzutów w kodzie maszynowym (ale nie o tym piszę). Myślę że
dorabiasz ideologię do praktyki.

do góry

Jacek Czerwinski <...@...z.pl> napisał(a):

> Mariusz Marszałkowski pisze:
> > Marcin 'Malcom' Malich <m...@g...com> napisał(a):
> >
> >> On 21 Maj, 18:07, "Mariusz Marsza=B3kowski"
> >> <b...@W...gazeta.pl> wrote:
>
> > Po prostu jest mniej pracy w C. Zmienne typu strukturalnego w C (zgodnie z
> > ideą C) deklaruje się globalnie, wszystkie funkcje deklaruje się
> > globalnie, a dostęp do wszystkich danych i składowych jest publiczny.
> Jeśli chciałeś podać przykład za C (za tym stylem) to ci nie wyszło.
> Brak podziału na prywatny/publiczny (w dowolny paradygmacie, czy to
> stary modularnym, czy obiektowym) odbiera ci swobodę (w pr. małym) lub
> blokuje *w wielkim projekcie) możliwość ulepszenia lokalnej
> implementacji bez zmiany interfejsu.
> Zostaje żmudna ręczna robota.
> Wracając do optymalizacji, znasz takie słowo "gówna lepiej nie ruszać" -
> to m.in. o programowaniu w całości na globalach. Ulepszanie zwykle nie
> następuje.
>
> ścinam się czasem z gośćmi którym się wydaje, że reprezentują
> proceduralny styl pisania. Z tym że nie wiedzą, co to naprawdę jest, że
> też zawiera podział na publiczne i prywatne. Trzeba by sie odwołać do
> książek z lat 70-tych i sobie powtórzyć.

Czy ja gdzieś napisałem co popieram i co reprezentuję?
Nie zrozumieliśmy się kompletnie. Zwróć uwagę że mój post był w
kontekście "jeśli koniecznie ktoś chce wyuzdać kod" a nie
w kontekście dobrego systematycznego programowania. W takim
kontekście w ogóle nie istnieje pojęcie "konserwacji kodu", bo
programista przedkłada przyspieszenie o 1% nad eleganckim
zapisem. Co się da to poprawiasz a jak już zabrnąłeś za
daleko to idzie w kosz i piszesz na nowo. Nie jestem zwolennikiem
czegoś takiego, ale niektórzy tak chcą robić - pozostaje im życzyć
dobrej zabawy. Są nawet organizowane różne zawody takich programów,
wszystkie źródła które czytałem były napisane globalnie. Np.
były programy samo-modyfikujące się w asemblerze. Samo-modyfikacja
była wprowadzana po to żeby zaoszczędzić 1 bajt (słownie jeden bajt)
na rozmiarze kodu wynikowego.

Zdrowia

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 20 Maj, 14:32, A.L. <a...@a...com> wrote:

> >Czyli cały czas mówimy o użyciu współbieżności w celu lepszego
> >wykorzystania zasobów sprzętowych. Powtórzę: to nie jest wyłączna
> >cecha AIO. Współbieżność jest narzędziem bardziej ogólnym.
>
> .. i uzycie jej nie gwarantuje automatycznie poprawienia sprawnosci...
>
> http://www.ddj.com/go-parallel/article/showArticle.j
html?articleID=21...

Co to ma do obliczeń wykonywanych równolegle z I/O?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

do góry