Deklaracja w klasie - obiekt, czy wskaźnik?
Paweł
Chcia�bym sie upewni�, czy moje domniemania s� poprawne odno�nie
deklaracji w klasie obiektu(np. int obiekt), czy teďż˝ wskaznika(np. int *a).
Czy s� jakie� przeciwskazania odno�nie deklaracji obiektu, lub wskaznika
w klasie.
Jedynee, co mi przychodzi do g�owy, to w klasie powwinno sie deklarowa�
wska�nik w sytuacji, gdy w trakcie dzialania programu, ta zmienna moze
nie byc uzywana i zeby zaoszczdzic pamiec, nie rezerwuje sie pamieci na
caly obiekt, tylko na wskaznik, a to znacznie mniej miejsca zajmuje. W
sytuacji deklaracji obiektu, to ta zmienna nawet jesli nie bedzie
uzywana, to i tak bedzie zajmowala pamiec.
Czy sa jeszcze jakies inne roznice, np w szybkosci dzialania, lub cos
podobnego?
Jacek Czerwinski
> Witam wszystkich
>
> Chcia�bym sie upewni�, czy moje domniemania s� poprawne odno�nie
> deklaracji w klasie obiektu(np. int obiekt), czy teďż˝ wskaznika(np. int *a).
>
> Czy sa jeszcze jakies inne roznice, np w szybkosci dzialania, lub cos
> podobnego?
Eeeee "jeszcze" takie "drobiazgi" jak zupe�nie inny sens, inne
dzia�anie. Ale to "szczeg�".
Najpierw zr�b program kt�ry dzia�a, potem si� martw czy wydajnie.
Przedwczesna optymalizacja nie ma sensu. Co wi�cej, obstawiam �e tak
amatorsko po omacku optymalizuj�c pogorszysz wyniki.
Poczytaj coďż˝ o OOP ambitniejszego niďż˝ poziom szkolny (wzorce projektowe
i pokrewne tematy). Zawieranie vs dziedziczenie (niedok�adnie tw�j
temat, ale cos o�wieci).
Paweł
> Paweďż˝ pisze:
>> Witam wszystkich
>>
>> Chcia�bym sie upewni�, czy moje domniemania s� poprawne odno�nie
>> deklaracji w klasie obiektu(np. int obiekt), czy teďż˝ wskaznika(np. int
>> *a).
>>
>
>> Czy sa jeszcze jakies inne roznice, np w szybkosci dzialania, lub cos
>> podobnego?
>
> Eeeee "jeszcze" takie "drobiazgi" jak zupe�nie inny sens, inne
> dzia�anie. Ale to "szczeg�".
nakierowaďż˝ na jakieďż˝ strony lub tematy.
> Najpierw zr�b program kt�ry dzia�a, potem si� martw czy wydajnie.
> Przedwczesna optymalizacja nie ma sensu. Co wi�cej, obstawiam �e tak
> amatorsko po omacku optymalizuj�c pogorszysz wyniki.
>
> Poczytaj coďż˝ o OOP ambitniejszego niďż˝ poziom szkolny (wzorce projektowe
> i pokrewne tematy). Zawieranie vs dziedziczenie (niedok�adnie tw�j
> temat, ale cos o�wieci).
Faktycznie, wskazniki sie przydaja przy dziedziczeniu. A to zawieranie,
to o co biega, bo odnosze wrazenie, ze wiem o co chodzi, tylko nie
dok�adnie.
Michał Sopniewski
Witam,
faktyczne odpowiadanie na ten post jest troszeczkę wyręczaniem
przeglądarki, ale co mi tam.
1.) zmienne tworzone statycznie (np. int x =1;) są umieszczane na
stosie, a dynamicznie (int* x = new int(1);) na stercie,
2.) dostęp do zmiennych na stosie jest znacznie szybszy niż do
zmiennych na stercie (polecam do poczytania)
3.) obiekty na stosie mają zdefiniowany czas życia, na stercie nie
mają (pdp :-))
Paweł
> On 2 Sty, 00:37, Paweďż˝<ppf9@USUN_TOpoczta.fm> wrote:
> Witam,
> przegl�darki, ale co mi tam.
Bez przesady :-).
> 1.) zmienne tworzone statycznie (np. int x =1;) sďż˝ umieszczane na
> stosie, a dynamicznie (int* x = new int(1);) na stercie,
> 2.) dost�p do zmiennych na stosie jest znacznie szybszy ni� do
> zmiennych na stercie (polecam do poczytania)
> 3.) obiekty na stosie maj� zdefiniowany czas �ycia, na stercie nie
> majďż˝ (pdp :-))
>
Wiedzialem np, ze jedno jest umieszczane na stosie, a drugie na stercie,
ale nie wiedzialem, ze dostep do jednego jest szybsze niz do drugiego.
Marcin 'Qrczak' Kowalczyk
wrote:
> 2.) dostęp do zmiennych na stosie jest znacznie szybszy niż do
> zmiennych na stercie (polecam do poczytania)
Nie dostęp, tylko alokacja. Dostęp jest praktycznie tak samo szybki.
Jacek Czerwinski
> On 2010-01-02 13:11, Michaďż˝ Sopniewski wrote:
>> On 2 Sty, 00:37, Paweďż˝<ppf9@USUN_TOpoczta.fm> wrote:
>> 1.) zmienne tworzone statycznie (np. int x =1;) sďż˝ umieszczane na
>> stosie, a dynamicznie (int* x = new int(1);) na stercie,
Jak obiekt jest na stercie, nic z niego nie jest na stosie.
>> 2.) dost�p do zmiennych na stosie jest znacznie szybszy ni� do
>> zmiennych na stercie (polecam do poczytania)
Dop�ki nie piszesz sterownika rakiety Tomahawk, nie ma to znaczenia
(dost�p, r�znica 1 rozkazu CPU, alokowanie to inna bajka).
>> 3.) obiekty na stosie maj� zdefiniowany czas �ycia, na stercie nie
>> majďż˝ (pdp :-))
Trzeba pilnowac destruktor�w itd.
Logika !!! tego obiektu si� naprawde k�ania. Co, po co na co i z czym
wsp�pracuje.
>>
> Wiedzialem np, ze jedno jest umieszczane na stosie, a drugie na stercie,
> ale nie wiedzialem, ze dostep do jednego jest szybsze niz do drugiego.
To jest bzdurna optymalizacja (zwďż˝ jak najpiewr nie jest zrobione
zgodnei z sensem)
Maciej Sobczak
wrote:
> faktyczne odpowiadanie na ten post jest troszeczkę wyręczaniem
> przeglądarki, ale co mi tam.
>
> 1.) zmienne tworzone statycznie (np. int x =1;) są umieszczane na
> stosie,
Nie. Zmienne tworzone statycznie są umieszczane w obszarze dla
zmiennych statycznych. Natomiast na stosie są umieszczane te zmienne,
które są tworzone automatycznie.
> 2.) dostęp do zmiennych na stosie jest znacznie szybszy niż do
> zmiennych na stercie (polecam do poczytania)
Nie. Dostęp jest tak samo szybki, jeśli architektura pamięci jest
jednorodna.
Różnica w szybkości może być przy alokacji i dealokacji.
> 3.) obiekty na stosie mają zdefiniowany czas życia, na stercie nie
> mają (pdp :-))
Nie. Jedne i drugie mają zdefiniowany czas życia i ten czas kończy się
wraz z wywołaniem destruktora. Ani wcześniej ani później.
Faktem jest, że obiekty automatyczne mają destruktor wołany...
automatycznie.
--
Maciej Sobczak * www.msobczak.com * www.inspirel.com
Kicer
> 2.) dost�p do zmiennych na stosie jest znacznie szybszy ni� do
> zmiennych na stercie (polecam do poczytania)
gdzie poczytac?:>
bo imo nie ma r�znicy miedzy mov rej,[eax] a mov rej,[esp]
chyba ze o cos innego chodzi ?
--
Michaďż˝ Walenciak
Kicer86 at gmail dot com
http://kicer.elsat.net.pl
gg: 3729519
Krzysztof Rudnik
Za to jawna alokacja na stercie ułatwia (jest dostępne w języku) sprawdzenie
poprawności. Nie ma w standardowym C sprawdzenia przepełnienia stosu.
A na niektórych architekturach jest nieduży.
Krzysiek
Maciej Wawrzynczuk
> 2.) dostęp do
> zmiennych na stosie jest znacznie szybszy niż do zmiennych na stercie
> (polecam do poczytania)
Przestraszyłeś mnie. Chciałbym wierzyć że decyzję jak deklarować zmienną
można podjąć na etapie projektu - np. żeby była ona powiązana z kolorem
tych śmiesznych rombów na UMLowych bohomazach. A z tego co napisałeś
wynika, że powinieniem dokładnie policzyć bity na stercie, żeby mój
program działał szybko. ;)
Piotr Wyderski
> Nie. Dost�p jest tak samo szybki, je�li architektura pami�ci jest
> jednorodna.
W przypadku obiekt�w ze sterty mo�e wyst�pi� false sharing,
co dla automatycznych jest wyj�tkowo nieprawdopodobne.
Pozdrawiam
Piotr Wyderski
Piotr Wyderski
> Nie ma w standardowym C sprawdzenia przepełnienia stosu.
To daje tylko iluzję bezpieczeństwa. Jeżeli takie sprawdzanie
jest, to po wykryciu przepełnienia program i tak się wygrzmoci.
Dokładnie to samo osiągnie się dzięki dostarczanym przez
wiekszość systemów operacyjnych guard pages.
Jeśli sprawdzanie stosu ma być naprawdę przydatne, to musi
być realizowane statycznie. A to wyklucza m.in. nieograniczoną
rekursję.
Pozdrawiam
Piotr Wyderski
Piotr Wyderski
> A z tego co napisałeś wynika, że powinieniem dokładnie
> policzyć bity na stercie, żeby mój program działał szybko. ;)
Poniekąd tak jest :-)
Puśc sobie na N rdzeniach inkrementację 0..N-1-tej wartości:
int counters[N];
a zobaczysz coś ciekawego...
Pozdrawiam
Piotr Wyderski
Adam Drzewiecki
> Puśc sobie na N rdzeniach inkrementację 0..N-1-tej wartości:
>
> int counters[N];
>
> a zobaczysz coś ciekawego...
A można wiedzieć, co to będzie? Jestem ciekaw, ale mam procesor z jednym
rdzeniem ;)
Pozdrawiam
Adam Drzewiecki
Krzysiek Kowaliczek
tzw. "false sharing":
http://www.ddj.com/go-parallel/article/showArticle.jhtml?articleID=217500206
Pozdrawiam
KK
Maciej Sobczak
> W przypadku obiektów ze sterty może wystąpić false sharing,
Czy to nie jest proste do rozwiązania na poziomie samego alokatora?
Faktem jest, że musiałby być bardziej świadomy wielowątkowości swojego
środowiska, ale przecież jest więcej powodów, żeby taki właśnie był.
> co dla automatycznych jest wyjątkowo nieprawdopodobne.
Prawda.
Maciej Sobczak
> Jeśli sprawdzanie stosu ma być naprawdę przydatne, to musi
> być realizowane statycznie. A to wyklucza m.in. nieograniczoną
> rekursję.
Oraz VLA.
A tak na poważnie, jeżeli ktoś się stresuje możliwością braku pamięci
(przepełnienie stosu to brak pamięci), to sterta *też* jest tematem, o
którym należy pomyśleć i też należy to zrobić statycznie - co jest o
tyle śmieszne, że wtedy jest już niepotrzebna.
Piotr Wyderski
> Czy to nie jest proste do rozwi�zania na poziomie samego alokatora?
Niestety to nie jest takie proste. �le zaprojektowany alokator mo�e
oczywi�cie sporo popsu�, ale nawet dobrze zaprojektowany sam nie
jest w stanie niczego naprawiďż˝. Zaalokowane obiekty mogďż˝ trafiaďż˝
do innych w�tk�w, kt�re mog� je do woli modyfikowa�. Alokator
nie wie, co si� potem stanie z obiektem, wi�c mo�e potem umie�ci�
kolejne obiekty w tej samej linii cache, co ju� u�ywane. Alternatyw�
by�oby wyr�wnywanie rozmiaru ��danego bloku do co najmniej 128
bajt�w, co powodowa�oby
a) nieakceptowalny wzrost zapotrzebowania na pami�� przez ma�e obiekty
-- trudno wyobrazic sobie w�z�y std::list czy std::map o takiej
wielko�ci;
b) du�y spadek wydajno�ci spowodowany marnowaniem pojemno�ci cache
na przechowywanie paddingu do ko�ca linii -- wiekszo�c stanowi�yby
�mieci,
a nie by� mo�e przydatne wkr�tce obiekty.
Pe�na eliminacja zjawiska false sharing wymaga dzia�a� na poziomie
modelowania przep�ywu danych w programie, a wi�c dotyczy nawet
bardziej architektury niďż˝ implementacji.
> Faktem jest, �e musia�by by� bardziej �wiadomy wielow�tkowo�ci swojego
> �rodowiska, ale przecie� jest wi�cej powod�w, �eby taki w�a�nie by�.
Obecnie on zazwyczaj jest �wiadomy na tyle, na ile mo�e.
Tu musia�by jednak umie� przewidywa� przysz�e losy obiektu,
co jest niewykonalne.
Pozdrawiam
Piotr Wyderski
Marcin 'Qrczak' Kowalczyk
> W przypadku obiektów ze sterty może wystąpić false sharing,
> co dla automatycznych jest wyjątkowo nieprawdopodobne.
To nie jest zagadnienie na poziomie autora wątku. W tym kontekście
można to pominąć.
Maciej Sobczak
<piotr.wyder...@mothers.against.spam.gmail.com> wrote:
> Alternatywą
> byłoby wyrównywanie rozmiaru żądanego bloku do co najmniej 128
> bajtów, co powodowałoby
>
> a) nieakceptowalny wzrost zapotrzebowania na pamięć przez małe obiekty
> -- trudno wyobrazic sobie węzły std::list czy std::map o takiej
> wielkości;
Ale spokojnie sobie wyobrażam std::list czy std::map przydzielające
swoje węzły całymi grupami. Zwłaszcza jeśli granulacja ma być na
poziomie 128 bajtów, czyli bardzo małym.
To prawda, że umieszczanie jednego węzła w 128-bajtowym bloku byłoby
głupotą, ale już przydzielenie 128/sizeof(Node) węzłów up-front wydaje
się być oczywistą optymalizacją, która nawet nie daje dużego narzutu.
Zwłaszcza, że szanujący się kontener i tak cache'uje węzły.
(tak, tego nie da się łatwo zrobić przez "normalne" API alokatora, ale
nikt nie zabrania kreatywnej synergii pomiędzy różnymi elementami
standardowej implementacji)
Wtedy false sharing może być problemem tylko przy obiektach
przydzielanych jawnie (czyli przez new a nie za pośrednictwem
kontenerów) przez samego użytkownika - ale jeżeli ktoś przydziela na
stercie jawnie i luzem *drobne* obiekty (dużo poniżej 128 bajtów), to
ma poważniejszy problem, niż potencjany false sharing...
wo3kie
>Przestraszyłeś mnie. Chciałbym wierzyć że decyzję jak deklarować zmienną
>można podjąć na etapie projektu - np. żeby była ona powiązana z kolorem
>tych śmiesznych rombów na UMLowych bohomazach. A z tego co napisałeś
>wynika, że powinieniem dokładnie policzyć bity na stercie, żeby mój
>program działał szybko. ;)
Za przeproszeniem, Pi*cie jak potrzaskani, az sie Was czytac nie chce.
1) Uzycie wskaznika do obiektu zamiast obiektu, Wzorzec Pimpl
(Prywatna Implementacja, Wzorzec Most). Niektorzy powiedza, STRASZNIE
WOLNE! ale ma inne zalety, redukuje zaleznosci.
2) Uzycie wskaznika do obiektu zamiast obiektu, Definicja Rekurencyjna
Nieskonczona, Klasa BinaryTreeNode zawiera dwa wskazniki do
BinaryTreeNode zamiast dwoch obiektow. Niektorzy powiedza, STRASZNIE
WOLNE!, to sprobujcie to zakodowac inaczej.
3) Uzycie wskaznika do obiektu zamiast obiektu jezeli nie znamy
rozmiaru danych
Klasa Strina z optymalizacja Short String Optimalization
stcuct BasicString{
char _data1[8]; // znamy rozmiar, tworzymy obiekt
char * _data2; // nie znamy rozmiaru, musimy dac wskaznik
};
4) Uzycie obiektu zamiast wskaznika, Klasa zawiera inna klase, przez
caly czas swojego zycia niezmienna, tworzymy obiekt
struct Fare{
// obiekt, FareCode nie zmienia sie w czasie
FareCode _fareCode;
};
5) Uzycie wskaznika do obiektu zamiast obiektu, Klasa zawiera
polaczenie do innej klasy ktorej nie zawiera, tworzymy wskaznik. Jak
bedziecie podmieniac obiekt w trakcie dzialania programu.
struct Fare{
// wskaznik, moze buc pusty, moze sie zmieniac
FareController * _fareController;
};
6) funkcja zwraca wartosc opcjonalnie, (eg.: sqrt, find, get, ...) -
zwraca wskaznik, pusty oznacza fiasko, jednak lepiej uzyc czegos
takiego jak boost::optional, wtedy zwraca obiekt
7) Uzycie wskaznika do obiektu zamiast obiektu, Potrzebujemy
polimorfizmu metod, uzywamy wskaznik
8) Uzycie wskaznika do obiektu zamiast obiektu, Potrzebujemy zmieniac
znaczenie w trakcie dzialania programu, (eg.: Wzorzec Strategia),
uzywamy wskaznik.
struct Find{
// dla obiektow polimorfizm nie dziala
FindStrategy * _strategy;
};
9) Uzycie wskaznikow do obiektow zamiast obiektow, Dwie klasy
definiuja sie nawzajem, uzywamy forward deklaracji i uzywany
wskaznikow. Ot przyklad z palca wziety: Skrzyzowanie i Droga.
Droga zawiera co najmniej jedno skrzyzowanie, skrzyzowanie zawiera co
namniej dwie drogi. Sprobujie tutaj z obiektami, zeby bylo szybciej.
10) Uzycie wskaznika do obiektu zamiast obiektu, Klasa 'zawiera'
'obiekt' innej klasy ktora jest noncopyable,
struct S : boost::noncopyable {};
Zeby przyspieszyc program uzyjcie takze tutaj obiektow.
struct C {
C( S * s ):_s(s){}
S * _s;
};
...
Wszystkie powyzsze przyklady maja gdzies Wydajnosc o ktora tak bardzo
sie martwicie od poczatku dyskusji, czy to bedzie sterta, czy to
bedzie stos, czy to bedzie rejestr...
Uwazam, ze decyzje o tym, czy to bedzie wskaznik, czy to bedzie obiekt
mozna podjac w czasie planowania projektu.
Ewentualne DROBNE ZMIANY moga by podyktowane wzgledami
wydajnosciowymi. Optymalizujcie na poziomie struktur danych,
algorytmow, zrownoleglania/synchronizacji a nie wskaznik/obiekt
To sa pewne schematy dzialania i sie poprostu nie da inaczej,
powiedzialbym Idiomy.
Nawet jezeli Profiler jasno wskaze, ze waskim gardlem w naszym Drzewie
Binarnym jest indirect odwolanie do wezla Lewego i Prawego zamiast i
tak nikt nie zamieni wskaznikow na pelne obiekty.
Bo mu sie to nie skompiluje HA HA HA
Łukasz
Jacek Czerwinski
> Panowie,
>
>
> ....
>
> Wszystkie powyzsze przyklady maja gdzies Wydajnosc o ktora tak bardzo
> sie martwicie od poczatku dyskusji, czy to bedzie sterta, czy to
> bedzie stos, czy to bedzie rejestr...
> Uwazam, ze decyzje o tym, czy to bedzie wskaznik, czy to bedzie obiekt
> mozna podjac w czasie planowania projektu.
> Ewentualne DROBNE ZMIANY moga by podyktowane wzgledami
> wydajnosciowymi. Optymalizujcie na poziomie struktur danych,
> algorytmow, zrownoleglania/synchronizacji a nie wskaznik/obiekt
> To sa pewne schematy dzialania i sie poprostu nie da inaczej,
> powiedzialbym Idiomy.
>
> Nawet jezeli Profiler jasno wskaze, ze waskim gardlem w naszym Drzewie
> Binarnym jest indirect odwolanie do wezla Lewego i Prawego zamiast i
> tak nikt nie zamieni wskaznikow na pelne obiekty.
Popieram "oboma rencami". �licznie to wy�o�y�e�.
W�a�nie o to chodzi, o projekt i sens dzia�ania, mozliwo�ci prawid�owego
i elastycznego wyra�enia celu po co programujemy (w tym OOP best
practice), a nie o 1 rozkaz CPU wi�cej czy mniej (kt�ry osobi�cie, nie
b�d�c aktywnym specjalist�, nie podejmuj� si� wyja�ni� jak si�
przek�ada na mikrosekundy na wsp�lczesnych maszynach, i czy w og�le
pozornie szybszy zawsze jest szybszy. Zaznaczam, wiele lat temu
potrafilem poznaďż˝ czasy do jednego cyklu CPU, ale to se ne vrati).
Piotr Wyderski
> Za przeproszeniem, Pi*cie jak potrzaskani, az sie Was czytac nie chce.
Nie ma przymusu, ka�dy porz�dny czytnik ma funkcj� listy zablokowanych
nadawc�w, a lud tutejszy cywilizowany i z killfajli nie ucieka. :-)
[ciach]
> Wszystkie powyzsze przyklady maja gdzies Wydajnosc o ktora tak bardzo
> sie martwicie od poczatku dyskusji
Trudno tego nie zauwa�y�. Tak jak i tego, �e bardzo mnie ciesz� powy�sze
zalecenia -- im wi�cej ludzi bedzie je stosowa�o, tym grubsz� warstw� mas�a
b�d� m�g� smarowa� chleb, wi�c mam osobisty interes w ich popieraniu.
Pisz� to zupe�nie na powa�nie.
> Uwazam, ze decyzje o tym, czy to bedzie wskaznik, czy to bedzie obiekt
> mozna podjac w czasie planowania projektu.
Na etapie planowania projektu zazwyczaj nic nie wiadomo nawet na
znacznie wy�szym poziomie, wi�c "decyzja" b�dzie czyst� spekulacj�.
> Optymalizujcie na poziomie struktur danych,
> algorytmow, zrownoleglania/synchronizacji
Przecie� ta ga��� w�tku dotyczy w�a�nie optymalizacji na poziomie
synchronizacji, okre�laj�c algorytm przydzia�u w�z��w. A �e powodem
jest obrzydliwie niskopoziomowe zjawisko, o kt�rym sama my�l burzy
dobre samopoczucie grafikom od UML i innym domoros�ym Picassom,
to ju� nic nie poradz�. �wiat jest jaki jest i "rozwi�zanie" problemu
metod� zadekretowania jego nieistnienia nie jest szczeg�lnie efektywne.
> Ewentualne DROBNE ZMIANY moga by podyktowane wzgledami
> wydajnosciowymi.
Drobne zmiany prowadz� do drobnej poprawy wydajno�ci. Je�li chcesz
mie� rzeczywisty prze�om, to musisz zdecydowac si� na g��bokie zmiany.
Cz�sto to kluczowa niskopoziomowa struktura danych okre�la ca��
wysokopoziomow� struktur� programu, a jak ona powinna wygl�da�, to
si� nie dowiesz bez rzeczywistych test�w. Je�li schrzanisz to na pocz�tku,
to potem sobie mo�esz do woli "drobno zmienia�".
> Nawet jezeli Profiler jasno wskaze, ze waskim gardlem w naszym Drzewie
> Binarnym jest indirect odwolanie do wezla Lewego i Prawego zamiast i
> tak nikt nie zamieni wskaznikow na pelne obiekty.
Piszesz o algorytmach, a o osadzaniu drzewa w tablicy te� nie s�ysza�e�?
Pozdrawiam
Piotr Wyderski
Mateusz Loskot
news:hhm103$g73$1...@inews.gazeta.pl...
> Witam wszystkich
>
> Chcia�bym sie upewni�, czy moje domniemania s� poprawne odno�nie
> deklaracji w klasie obiektu(np. int obiekt), czy teďż˝ wskaznika(np. int
> *a).
>
> Czy s� jakie� przeciwskazania odno�nie deklaracji obiektu, lub wskaznika w
> klasie.
>
> Jedynee, co mi przychodzi do g�owy, to w klasie powwinno sie deklarowa�
> wska�nik w sytuacji, gdy w trakcie dzialania programu, ta zmienna moze nie
> byc uzywana i zeby zaoszczdzic pamiec, nie rezerwuje sie pamieci na caly
> obiekt, tylko na wskaznik, a to znacznie mniej miejsca zajmuje. W sytuacji
> deklaracji obiektu, to ta zmienna nawet jesli nie bedzie uzywana, to i tak
> bedzie zajmowala pamiec.
Jak juďż˝ Jacek zasugerowaďż˝, poczytaj na temat podstaw OOP
oraz zwi�zk�w pomi�dzy obiektami jak kompozycja i agregacja.
Poczytaj jak realizuje siďż˝ composition a jak aggregation w C++,
na czym polega r�nica.
...i sam sobie odpowiesz na pytanie czy wska�nik czy nie.
Pozdrawiam
--
Mateusz Loskot, http://mateusz.loskot.net
pl.comp.lang.c FAQ: http://pl.cpp.wikia.com/wiki/FAQ
C++ FAQ: http://parashift.com/c++-faq-lite
Jędrzej Dudkiewicz
> wo3kie pisze:
>> Panowie,
>> ....
>> Wszystkie powyzsze przyklady maja gdzies Wydajnosc o ktora tak bardzo
>> sie martwicie od poczatku dyskusji, czy to bedzie sterta, czy to
>> bedzie stos, czy to bedzie rejestr...
>> Uwazam, ze decyzje o tym, czy to bedzie wskaznik, czy to bedzie obiekt
>> mozna podjac w czasie planowania projektu.
>> Ewentualne DROBNE ZMIANY moga by podyktowane wzgledami
>> wydajnosciowymi. Optymalizujcie na poziomie struktur danych,
>> algorytmow, zrownoleglania/synchronizacji a nie wskaznik/obiekt
>> To sa pewne schematy dzialania i sie poprostu nie da inaczej,
>> powiedzialbym Idiomy.
>
>
> Właśnie o to chodzi, o projekt i sens działania, mozliwości prawidłowego
> i elastycznego wyrażenia celu po co programujemy (w tym OOP best
> practice), a nie o 1 rozkaz CPU więcej czy mniej
Jest taki "pejper" Ulricha Dreppera, "What Every Programmer Should Know
About Memory". I tam są bardzo piękne wykresy pokazujące czas dostępu do
komórek pamięci w zależności od różnych parametrów. I z tego wynika, że
nie bijesz się o 1 rozkaz CPU czy nawet 10, ale raczej 100 do 1000.
JD
wo3kie
wrote:
> Jest taki "pejper" Ulricha Dreppera, "What Every Programmer Should Know
> About Memory". I tam są bardzo piękne wykresy pokazujące czas dostępu do
> komórek pamięci w zależności od różnych parametrów. I z tego wynika, że
> nie bijesz się o 1 rozkaz CPU czy nawet 10, ale raczej 100 do 1000.
Przejrzalem pobieznie ten dokument, jest dosyc dlugi. Moglbys
sprecyzowac o ktory wykres chodzi? Wybacz, ale nie bede czytal teraz
tych 114 stron, tylko dlatego ze rzuciles tytul jakiegos ebooka.
Ja zrobilem prosty tescik, wygenerowalem kod maszynowy dla dwoch
programow.
// Program pierwszy, mamy tutaj obiekt
struct Internal{ int i; };
struct External{ Internal i; };
int main(){
External e;
e.i.i = 0;
int i = e.i.i;
}
// Proram drugi, mamy tutaj wskaznik
struct Internal{
int i;
};
struct External{
Internal * i;
};
int main(){
External e;
e.i->i = 0;
int i = e.i->i;
}
Oto kody wygenerowane dla tych programow. Specjalnie nie przydzielalem
pamieci do wskaznika, chodzilo mi o sam dostep do danych. Dlaczego
tak, bo przydzielanie zasobow do wskaznika moze wystapic tylko raz z
programie, wiec ma znikomy wylyw na wydajnosc, potem ten wskaznik
moze byc tylko kopiowany/przenoszony - nie wydaje mi sie to wazne w
tej dyskusji.
// Program pierwszy
int main(){
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
External e;
e.i.i = 0;
4: c7 45 f0 00 00 00 00 movl $0x0,0xfffffffffffffff0(%rbp)
int i = e.i.i;
b: 8b 45 f0 mov 0xfffffffffffffff0(%rbp),%eax
e: 89 45 fc mov %eax,0xfffffffffffffffc(%rbp)
11: b8 00 00 00 00 mov $0x0,%eax
}
16: c9 leaveq
17: c3 retq
// Program drugi
int main(){
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
External e;
e.i->i = 0;
4: 48 8b 45 f0 mov 0xfffffffffffffff0(%rbp),%rax
8: c7 00 00 00 00 00 movl $0x0,(%rax)
int i = e.i->i;
e: 48 8b 45 f0 mov 0xfffffffffffffff0(%rbp),%rax
12: 8b 00 mov (%rax),%eax
14: 89 45 fc mov %eax,0xfffffffffffffffc(%rbp)
17: b8 00 00 00 00 mov $0x0,%eax
}
1c: c9 leaveq
1d: c3 retq
Rzeczywiscie doliczylem sie roznicy - jedna instrukcja maszynowa przy
kazdym dostepie, zarowno odczyt jak i zapis.
I to zadna jakas skomplikowana, zwykly mov.
A wracajac do pytania "obiekt czy wskaznik", to na etapie
projektowania systemu / modulu / klasy False Sharing jest dla mnie
naprawde kluczowym i glownym kryterium wyboru ktory sposob
implementacji wybrac. Nie logika aplikacji, nie czytelnosc kodu i
jawnosc intencji, tylko wlasnie False Sharing. (sarkazm, bo sie
jeszcze ktos nie domysli (o; )
> W przypadku obiektów ze sterty może wystąpić false sharing,
> co dla automatycznych jest wyjątkowo nieprawdopodobne.
Moze mi to ktos lopatologicznie wytlumaczyc, dlaczego tak jest?
Mnie sie wydawalo, ze False Sharing wystepuje jezeli rozne watki
uzywaja roznych adresow pamieci, ale te adresy sa na tyle blisko
siebie z punktu widzenia sprzetu (ramka cache) ze sprzet broni przed
rownoczesnym dostepem do tych adresow. Ale przeciez dwie zmienne moga
byc blisko siebie niezaleznie czy sa na stosie, czy sa na stercie.
Łukasz
Krzysiek Kowaliczek
>> kom�rek pami�ci w zale�no�ci od r�nych parametr�w. I z tego wynika, �e
>> nie bijesz siďż˝ o 1 rozkaz CPU czy nawet 10, ale raczej 100 do 1000.
> Ja zrobilem prosty tescik, wygenerowalem kod maszynowy dla dwoch
> programow.
> Rzeczywiscie doliczylem sie roznicy - jedna instrukcja maszynowa przy
> kazdym dostepie, zarowno odczyt jak i zapis.
Tutaj nie chodzi o ilo�� dodatkowych rozkaz�w procesora,
ale o ilo�� cykli jak� b�dzie musia� czeka� procesor
na dostarczenie danych z pami�ci g��wnej w przypadku,
gdy nie ma ich w pami�ci podr�cznej.
>> W przypadku obiekt�w ze sterty mo�e wyst�pi� false sharing,
>> co dla automatycznych jest wyj�tkowo nieprawdopodobne.
> Moze mi to ktos lopatologicznie wytlumaczyc, dlaczego tak jest?
False sharing wyst�pi w przypadku, gdy dane dla kilku procesor�w
wyst�pi� w jednej ramce pami�ci podr�cznej. W zale�no�ci od
procesora mo�e ona wynosi� np. 64 lub 128 bajty. Dlatego jest
nieprawdopodobne, aby taka sytuacja wyst�pi�a w przypadku stosu
w�tk�w.
Pozdrawiam
KK
Wojciech Muła
> On 5 Sty, 19:41, Jędrzej Dudkiewicz <jedrzej.dudkiew...@gmail.com>
> wrote:
> > Jest taki "pejper" Ulricha Dreppera, "What Every Programmer Should Know
> > About Memory". I tam są bardzo piękne wykresy pokazujące czas dostępu do
> > komórek pamięci w zależności od różnych parametrów. I z tego wynika, że
> > nie bijesz się o 1 rozkaz CPU czy nawet 10, ale raczej 100 do 1000.
>
> Przejrzalem pobieznie ten dokument, jest dosyc dlugi. Moglbys
> sprecyzowac o ktory wykres chodzi? Wybacz, ale nie bede czytal teraz
> tych 114 stron, tylko dlatego ze rzuciles tytul jakiegos ebooka.
Jędrzej się przejęzyczył, chodziło o czasy dostępu a nie liczbę rozkazów.
Więc - dostęp do rejestru 1 cykl, do cache 1. poziomu kilka (u mnie:
3 cykle), do cache 2. poziomu kilkanaście (u mnie: 10 albo 20 cykli), do
pamięci głównej kilkadzisiąt-kilkaset (u mnie: 150 albo 200 cykli),
a niefart pod tytułem page fault parę tysięcy cykli.
w.
--
A kiedyś był taki wypadek, że przyjechała wycieczka na "Jezioro łabędzie"
z biletami na krytą pływalnię.
Jędrzej Dudkiewicz
> wo3kie <wo3...@gmail.com> wrote:
>
>> On 5 Sty, 19:41, Jędrzej Dudkiewicz <jedrzej.dudkiew...@gmail.com>
>> wrote:
>>> Jest taki "pejper" Ulricha Dreppera, "What Every Programmer Should Know
>>> About Memory". I tam są bardzo piękne wykresy pokazujące czas dostępu do
>>> komórek pamięci w zależności od różnych parametrów. I z tego wynika, że
>>> nie bijesz się o 1 rozkaz CPU czy nawet 10, ale raczej 100 do 1000.
>> Przejrzalem pobieznie ten dokument, jest dosyc dlugi. Moglbys
>> sprecyzowac o ktory wykres chodzi? Wybacz, ale nie bede czytal teraz
>> tych 114 stron, tylko dlatego ze rzuciles tytul jakiegos ebooka.
>
> Jędrzej się przejęzyczył, chodziło o czasy dostępu a nie liczbę rozkazów.
> Więc - dostęp do rejestru 1 cykl, do cache 1. poziomu kilka (u mnie:
> 3 cykle), do cache 2. poziomu kilkanaście (u mnie: 10 albo 20 cykli), do
> pamięci głównej kilkadzisiąt-kilkaset (u mnie: 150 albo 200 cykli),
> a niefart pod tytułem page fault parę tysięcy cykli.
Tak, chodziło o cykle, nie o rozkazy. Ale cały czas bijesz się właśnie o
nie.
JD
wo3kie
<wojciech_m...@poczta.null.onet.pl.invalid> wrote:
> Jędrzej się przejęzyczył, chodziło o czasy dostępu a nie liczbę rozkazów.
> Więc - dostęp do rejestru 1 cykl, do cache 1. poziomu kilka (u mnie:
> 3 cykle), do cache 2. poziomu kilkanaście (u mnie: 10 albo 20 cykli), do
> pamięci głównej kilkadzisiąt-kilkaset (u mnie: 150 albo 200 cykli),
> a niefart pod tytułem page fault parę tysięcy cykli.
A co ma to wspolnego z wskaznikami? Pytam raz jeszcze, co ma Page
Fault, Stronicowanie, Segmentacja, Cache 2L, Cache 3L itd... do
wskaznikow w rzeczywistych programach (pomijam programy ktore w
calosci mieszcza sie w Cachu)? Utworz wektor 70 000 000 elementow,
obiektow, bez zadnych wskaznikow i przeiteruj sie po nim. Raz uda sie
trafic w Cachu dla kolejnych elementow, ale kiedys w koncu chybimy i
trzeba bedzie szukac w innych rodzajach pamieci. Te zjawiska wynikaja
glownie z ilosci danych a nie sposobu przydzialu pamieci, stos/sterta.
Jezeli wolasz kolejna funkcje, ktora dawno nie byla wolana, ona tez
przdopodobnie nie jest juz w cache L1. Wszystkie jej zmienne lokalne,
chociaz sa lokalne a nie dynamiczne, trzeba bedzie i tak sukcesywnie
pobierac z dalszych pamieci i ewentualnie cache'owac dla ponownego
uzycia.
Iterujac sie po tablicy, najczesciej siegamy do kolejnego elementu -
ktory prawdopodobnie tez bedzie w Cache - co zajmuje niewiele czasu.
Siegajac pod wskaznik utworzony na poczatku dzialania programu, pod
ktorym jest tabela z wartosciami wczytanymi z pliku konfiguracyjnego,
robimy o wiele dalszy skok, co ma prawo zajac o wiele wiecej cykli
zegara. To Fakt. Ale czy macie lepszy pomysl?
Majac dwa obiekty, typu Parent i Child, takie, ze Parent zn swojego
Childa a Child zna swojego Parenta tez nie uzywanie wskaznikow? Bo
miedzy tworzeniem Parentem a Childem moze minac bardzo dlugi okres, i
Child moze znajdowac sie juz w zupelnie innym miejscu w pamieci przez
co moze wystapic Page Fault?
Challo, ludzie. Dostep przez wskaznik jest dluzszy niz dostep do
zmiennej na stosie. Ale co z tego? Pewnych rzeczy, ktore wymienilem
wczeniej w punktach 1-10 nie da sie zrobic przy pomocy obiektow i
tyle. Glupota by bylo tworzeniem licznika w petli dynamicznie zamiast
statycznie
for( int * i = new int( 0 ) ; * i < 10 ; ++ *i ){}
ale przy projektowaniu systemow, modulow, klas, mozna wskazac pewne
typowe sytuacje gdzie jasno mozna powiedziec, czy uzyc wskaznik czy
uzyc obiekt. Bez liczenia cykli zegara. Ponadto UML i techniki
obiektowe powstaly nie tylko dla zboczonych programistow C++ ktorzy
licza cykle zegara, ale dla programistow innych jezykow gdzie takie
problemy istnieja w mniejszym stopniu, dla architektow ktorzy nie
musza znac niuansow jezyka programowania i architektury sprzetu, dla
Business Analitykow - ktorzy najczesciej nie maja pojecia o
programowaniu ale swietnie znaja wiedze biznesowa. Im wystarczy
rozumiec roznice pomiedzy 'Zawiera Na Wlasnosc' a 'Wie/Zna/Ma Dostep'.
Piotr napisal,
> Piszesz o algorytmach, a o osadzaniu drzewa w tablicy też nie słyszałeś?
Akurat tak sie zdaza, ze slyszalem, to wcale nie jest trudne. Ale ma
inne wady zwiazane z zarzadzaniem pamiecia, przy dodawaniu elementow i
przy ich usuwaniu. A czy Ty powaznie uzywasz drzew opartych na tablicy
zeby bylo szybciej? A czy Ty powaznie uzywasz Listy opartej na tablicy
zeby bylo szybciej? A czy Ty powaznie nie uzywasz wektora z
dynamicznym przydzialem pamieci tylko odpowiednio duzych tablic zeby
bylo szybciej?
> False sharing wystąpi w przypadku, gdy dane dla kilku procesorów
> wystąpią w jednej ramce pamięci podręcznej. W zależności od
> procesora może ona wynosić np. 64 lub 128 bajty. Dlatego jest
> nieprawdopodobne, aby taka sytuacja wystąpiła w przypadku stosu
> wątków.
Tak, zgadza sie, czyli mechanizm False Sharingu dobrze rozumie. Dalej
jednak nie wiem, jak stos watkow ma przed tym uchronic?
Nawet czytajac ten artykul, http://www.ddj.com/go-parallel/article/showArticle.jhtml?articleID=217500206
nie widze zadnego rozsadnego uzasadnienia.
Kilka watkow, jeden wektor, utworzony lokalnie, prawdopodobnie na
stosie, i False Sharing dalej wystepuje. Najwidoczniej potrzebuje
jeszcze jakies naprowadzenie.
Łukasz
Wojciech Muła
> On Jan 5, 10:57 pm, Wojciech Muła
> <wojciech_m...@poczta.null.onet.pl.invalid> wrote:
> > Jędrzej się przejęzyczył, chodziło o czasy dostępu a nie liczbę rozkazów.
> > Więc - dostęp do rejestru 1 cykl, do cache 1. poziomu kilka (u mnie:
> > 3 cykle), do cache 2. poziomu kilkanaście (u mnie: 10 albo 20 cykli), do
> > pamięci głównej kilkadzisiąt-kilkaset (u mnie: 150 albo 200 cykli),
> > a niefart pod tytułem page fault parę tysięcy cykli.
>
> A co ma to wspolnego z wskaznikami? Pytam raz jeszcze, co ma Page
> Fault, Stronicowanie, Segmentacja, Cache 2L, Cache 3L itd... do
> wskaznikow w rzeczywistych programach (pomijam programy ktore w
> calosci mieszcza sie w Cachu)? Utworz wektor 70 000 000 elementow,
> obiektow, bez zadnych wskaznikow i przeiteruj sie po nim.
Problem z serii: Idealnie kulista kura poruszą się bez tarcia
w jednorodnym polu elektrycznym... i tylko zdziwiona mruga oczkami. :)
> Raz uda sie trafic w Cachu dla kolejnych elementow, ale kiedys w koncu chybimy i
> trzeba bedzie szukac w innych rodzajach pamieci. Te zjawiska wynikaja
> glownie z ilosci danych a nie sposobu przydzialu pamieci, stos/sterta.
Mając wskaźniki do - z punktu widzenia programu - losowych obszarów
pamięci, nietrafienia w cache masz jak w banku. Dlatego jeśli ktoś
potrzebuje szybkich programów, wówczas musi brać pod uwagę istnienie
wielopoziomowych pamięci o różnym czasie dostępu. Klasyczną już strukturą
danych, która uwzględnia dwupoziomowe pamięci: szybki RAM vs wolne
dysk/CD/DVD są B-drzewa i wariacje.
w.
--
Daj, ać ja pokompiluję, a ty poczywaj.
Witold Witaszewski
Piotr Wyderski
> A wracajac do pytania "obiekt czy wskaznik", to na etapie
> projektowania systemu / modulu / klasy False Sharing jest dla mnie
> naprawde kluczowym i glownym kryterium wyboru ktory sposob
> implementacji wybrac. Nie logika aplikacji, nie czytelnosc kodu i
> jawnosc intencji, tylko wlasnie False Sharing.
Owszem, bywajďż˝ takie sytuacje i to zazwyczaj w kluczowych
z punktu widzenia wydajno�ci miejscach. Opisywa�em tu kiedy�
pomiary w�asnego systemu, gdzie zadbanie o wyr�wnanie danych
zwi�kszy�o wydajno�� ca�o�ci ponad 15 razy, tj. na 4 rdzeniach
wyj�ciowy program dzia�a� tyle razy wolniej ni� na jednym.
Na logik� aplikacji struktura danych wp�ywu nie ma, bo program
niezale�nie od jej wyboru ma robi� to, co za�o�ylismy; w innym razie
jest niepoprawny.
Struktura danych ma za to wielki wp�yw na sw�j interfejs, kt�ry
powinien odpowiada� jej zasadzie dzia�ania. A do w�a�ciwego
interfejsu potem dobudowujesz reszt� po stronie uzytkownik�w
tej klasy. Czytelno�c kodu i jawno�c intencji nie maj� z tym
�adnego zwi�zku, moga by� dobre lub z�e w obu przypadkach.
> Moze mi to ktos lopatologicznie wytlumaczyc, dlaczego tak jest?
> Mnie sie wydawalo, ze False Sharing wystepuje jezeli rozne watki
> uzywaja roznych adresow pamieci, ale te adresy sa na tyle blisko
> siebie z punktu widzenia sprzetu (ramka cache) ze sprzet broni przed
> rownoczesnym dostepem do tych adresow. Ale przeciez dwie zmienne moga
> byc blisko siebie niezaleznie czy sa na stosie, czy sa na stercie.
Jest tak dlatego, �e stos w�tku jest stosunkowo du�� struktur�,
efektywnie tablic� o rozmiarze kilku MiB, wyr�wnan� do rozmiaru
strony. Dlatego FS nie wyst�pi z tej prostej przyczyny, �e dane
automatyczne r�nyc w�tk�w sa od siebie dostatecznie odleg�e.
Aby wyst�pi�, musia�by� przekaza� adres zmiennej na stosie w�tku
A do w�tku B, czego si� zazwyczaj nie robi.
I nie, dyskusja nie dotyczy pytania "obiekt czy wska�nik", bo nie o wadach
struktur w�z�owych rozmawiamy, tylko "wska�nik na jaki obszar pami�ci".
Pozdrawiam
Piotr Wyderski
wo3kie
<piotr.wyder...@mothers.against.spam.gmail.com> wrote:
> I nie, dyskusja nie dotyczy pytania "obiekt czy wskaźnik", bo nie o wadach
> struktur węzłowych rozmawiamy, tylko "wskaźnik na jaki obszar pamięci".
Tak wlasnie, swietnie to ujales. Przeczytalem jeszcze raz pytanie
ktore zadal Pawel na poczatku dyskusji i dla mnie ta dyskusja dotyczy
pytania "obiekt czy wskaznik"!
Pawel ani slowem nie wspomnial o Wielowatkowosci. Prawdopodobnie
zaczyna programowac obiektowo i ma wiele watpliwosci, tak jak ja sam
mialem na poczatku kilka lat temu. Podal jeden przyklad ktory jak dla
mnie jest w pelni rozsadny przy pewnych zalozeniach projektowych.
Jezeli obiekt A moze zawierac oopcjonalnie obiekt B, o którym wiemy,
ze moze byc duzy, czy jest sens zrobic go jako wskaznik zamiast
obiektu? Wedlug mnie, Tak.
To kilka osob na tym forum, miedzy innymi Ty zepchneliscie temat na
niuanse synchronizacji i komunikacji wielowatkowej. W jakim celu,
zdolowac go ze jeszcze tyle sie musi nauczyc, popisac sie przed
innymi? A moze uczulic, ze taki problem moze wystapic u niego za kilka
lat, bo nie podejrzewam, zeby Pawel majac watpliwosci przy takich
prostych decyzjach projktowych zaczal jutro pisac potezne aplikacje
wielowatkowe.
Myslisz, ze o Pawlowi chodzilo o False Sharing, tylko zapomnialo mu
sie napisac? Prawdopodobnie oczekiwal nakierowania na Wzorce
Projektowe, Dobre Praktyki Projektowania, Idiomy, moze jakas
literature.
Bardzo podobne sytuacje sa na forum o rowerach. Pada proste pytanie,
'Chlopaki, co kupic, Alivio czy Deore'? Pada Odpowiedz, 'Kup Xtr, sam
mam, zadowolony jestem.' Ktos inny radzi, 'Xtr to dziadostwo, kup Stam
X7.' I sie zaczyna awantura o wyzszosci Sram X0 za 999pln nad Shimano
Xtr za 666pln, ktore jest o 1/3 tansze.
Tak samo jest na forum fotograficznym, 'Chlopaki, co kupic, Olympusa
czy Pentaxa?'. Pada odpowiedz, 'Kupuj Canona'. Co z tego, ze jest o
polowe drozszy. A ktos inny radzi, 'Olej Canona, przy ISO 12000 ma
lekkie szumy, wybierz Nicona ktory tych szumow nie ma az do ISO
20000'.
Dlatego za przeproszeniem Panowie, dalej uwazam, ze Pi*cie jak
potrzaskani. Stwierdzenie bez adresata, kto sie poczul urazony to jego
problem.
Łukasz
Piotr Wyderski
> Przeczytalem jeszcze raz pytanie ktore zadal Pawel na poczatku
> dyskusji i dla mnie ta dyskusja dotyczy pytania "obiekt czy wskaznik"!
I dosta� w�a�ciw� odpowied�.
> Pawel ani slowem nie wspomnial o Wielowatkowosci.
A ja rozmawia�em z Ma�kiem, a nie z Paw�em, wi�c mnie jego stosunek
do wielow�tkowo�ci (piszemy z ma�ej litery) nie interesuje.
> To kilka osob na tym forum, miedzy innymi Ty zepchneliscie temat na
> niuanse synchronizacji i komunikacji wielowatkowej. W jakim celu,
> zdolowac go ze jeszcze tyle sie musi nauczyc, popisac sie przed
> innymi?
Zgad�e�, jak jeden m�� cierpimy na kompleks mniejszo�ci i chcieli�my
siďż˝ popisaďż˝, by poprawiďż˝ sobie samopoczucie. A tak serio, to po pierwsze
chyba zbyt powa�nie traktujesz usenet, a po drugie, to wolno tu rozmawiac
na dowolny zwi�zany z programowaniem w C++ temat i nikt, a w szczeg�lno�ci
nie ty, b�dziesz ustala�, co i w jaki spos�b mamy pisa�. Jak ci si� nie
podoba,
to za�� sobie w�asne forum.
> Dlatego za przeproszeniem Panowie, dalej uwazam, ze Pi*cie jak
> potrzaskani. Stwierdzenie bez adresata, kto sie poczul urazony to jego
> problem.
Chcia�bym, by przekaz dotar�, wi�c schodz� na tw�j poziom:
poca�uj mnie w dup�. R�wnie� bez adresata... :-)
Piotr Wyderski
Seweryn Habdank-Wojewódzki
> Dlatego za przeproszeniem Panowie, dalej uwazam, ze Pi*cie jak
> potrzaskani. Stwierdzenie bez adresata, kto sie poczul urazony to jego
> problem.
Wydaje mi sie, ze niepotrzebnie sie denerwujesz.
Wszyscy sie zgadzaja z Toba i Knuthem (a moze z Knuthem
i z Toba) ze premature optimization daje kiepskie rezultaty.
Co wiecej sprawa opcjonalnej wiekszej klasy zostala
omowiona i odpowiedzi padly. Mam nadzieje, ze nie chcesz,
aby kazdy przepisywal Twoje sugestie, aby wyrazic poparcie :-).
Jednak pragne rowniez poprzec Piotra i high-end gurus.
C++ ma ta ZALETE, ze pozwala pracowac na wielu poziomach
abstrackcji. To nawet student powinien wiedziec i powinien
miec dobre rozeznanie w problemach kiedy i jak uzyc C++.
W innym watku dyskutant "mgk" pieje nt. wspanialosci Javy itd.
Klopot polega na tym, ze dopoki takie wysoko zaawanasowane
dyskusje nie pojawiaja sie, to ograniczone postrzeganie
programowania, takie jak prezentuje mgk, dominuje i powstaja
wlasnie problemy z "wymieraniem C++". Jesli jednak
dydaktycznie potraktujesz zaawansowane dyskusje, to wiele
sie dowiesz. Nie musisz drzec szat, ale np. hipotetyczny "student"
bedzie wiedzial co mozna w C++ rozwiazac i kiedy ten
"asembler" nalezy uzywac a kiedy pisac w Javie. Co wiecej
nawet sama dyskusja pozwala na postawienie pytania
czy inne super hiper jezyki wysokiego rzedu pozwalaja
na swiadome lub automatyczne ale nie losowe kontrolowanie
takich spaw jak byly omawiane. Co wiecej takie dyskusje pozwalaja
na zorientowanie sie jakie sa ogolne problemy. No i po ostatnie
a moze po piersze dyskusje zachowane sa na sieci, mozna
do nich wrocic w sensie czerpania wiedzy.
Tak wiec IMHO zaawansowane dyskusje to perla tej grupy
- nie jestem stalym bywalcem innych grup, ale takich wlasnie
dyskusji mi brakuje w stajni Pythona i Javy.
Pozdrawiam,
Seweryn Habdank-Wojewodzki.
wo3kie
> Wydaje mi sie, ze niepotrzebnie sie denerwujesz.
Ja, nie, jestem na codzien spokojnym czlowiekiem ;o).
Nie chodzi mi nawet o to, ze porusza sie rozne aspekty danego tematu.
Jestem jak najbardziej za. Ale jak czytam takie cos, to mi sie
klawiatura pali pod palcami,
>Przestraszyłeś mnie. Chciałbym wierzyć że decyzję jak deklarować zmienną
>można podjąć na etapie projektu - np. żeby była ona powiązana z kolorem
>tych śmiesznych rombów na UMLowych bohomazach. A z tego co napisałeś
>wynika, że powinieniem dokładnie policzyć bity na stercie, żeby mój
>program działał szybko. ;)
>Poniekąd tak jest :-)
Czy niektorzy na tym forum, naprawde patrzac na diagram UML, czy
jakikolwiek inny, mniej formalny potrafia oszacowac juz nawet nie
ilosc rozkazow maszynowych, ale nawet ilosc cykli?
Czy niektorzy na tym forum, naprawde widzac deklaracje klasy i jej
atrybuty, obiekty i wskazniki, potrafia wskazac ktore wskazniki
spowoduja problemy synchronizacji wielowatkowej?
Nie wydaje mi sie, stad to moje oburzenie. Jezeli sie myle, Mea Cupla.
Co do optymalizacji, nie mam nic przeciwko. Nawet przedwczesnej. Ale
nalezy dobrac odpowiedni poziom optymalizacji do aktualnego stan
projektu. We wczesnej fazie, jeszcze na etapie komponentow tez mozna
optymalizowac. Jezeli widac, ze jakies dwa komponenty beda ze soba
scisle wspolpracowaly, od razu mozna je polaczyc w calosc unikajac
kosztow komunikacji (chociazby sieciowej) miedzy nimi. Nie nalezy z
tym czekac do poznego kodowania i testowania. Tak samo deklarujac
klase i jej metody. Glupota by bylo przekazywanie wszystkich
parametrow przez wartosc w nadziei, ze kompilator to zoptymalizuje
lepiej. Ewentualnie, jak performace test wykaze inaczej, to sie
poprawi. Podobnie przy pisaniu algorytmu. Jezeli widzimy, ze jakies
obliczania nie zaleza od tresci petli i mozna je wykonac tylko raz
przed petla, mozna od razu ten fragment kodu przesunac na zewnatrz
petli. Podalem kilka prostych przykladow, tak prostych, ze przez
niektorych autorow nie sa nawet uwazane za optymalizacje, ale wiecie o
co mi chodzi...
Natomiast deklarujac zmienna w klasie, i zastanawiac sie czy zrobic ja
obiektem czy wskaznikiem, bo byc moze wystapi problem z watkami to
jest dla mnie duzo za wczesnie. Nic nowego pewnie nie odkryje, nawet
padlo to juz w dyskucji. Napisz projekt tak, zeby dzialal poprawnie.
Stosuj obiekty i wskazniki do wyrazania intencji. A jezeli zostanie ci
czas w projekcie, albo program nie bedzie spelnial postanowionych
wymagan wydajnosciowych - jak najbardziej dokonuj zmian i optymalizuj.
Jak juz zostalem tutaj pouczony, niektorzy pisza na tym forum tylko do
wybranych i pojedynczych osob. Poniewaz jednak robia to na forum
publicznym, dostepnym dla kazdego, te w/w osoby nie powinny sie dziwic
i tym bardziej miec pretensji, ze ktos moze sie odniesc do ich rozmowy
i sie do niej ustosunkowac.
Wszyscy piszemy na forum publicznym i na nas wszystkich ciazy pewna
odpowiedzialnosc. Ktos inny moze czyta te rozmowy. Ktos dla kogo
ktorykolwiek z nas moze byc autorytetem. I jeszcze niech sie ze dwa
razy pojawi oswiadczenie, ze deklarujac zmienna i zastanawiajac sie
czy zrobic ja obiektem czy wskaznikiem nalezy sie kierowac cyklami
procesora, nie pozostanie mi nic innego jak czekac w pracy na
pierwszych domoroslych programistow. Kandydatow do pracy ktorzy
wychowali sie nie na literaturze, rowniez traktujac ja z przymruzeniem
oka bo niektore ksiazki zawieraja takze kontrowersyjne materialy,
tylko wlasnie na tej grupie dyskusyjnej.
Lukasz