Stachu 'Dozzie' K. wrote:

> Wydajność się zyskuje nie na fistaszkach w rodzaju oszczędzenia jednego
> bajtu czy czterech cykli procesora, tylko na złożoności obliczeniowej
> (asymptotycznej).

To są takie rozważania teoretyczne, ale jak popatrzeć czasem na dyskusje na
LKML, to tam jednak czasami przejmują się pojedynczymi instukcjami. Sądzę,
że ma to sens - w końcu oni mają w tym doświadczenie.

do góry

W dniu 2011-02-01 23:24, Wojciech Jaczewski pisze:
> Stachu 'Dozzie' K. wrote:
>
>> Wydajność się zyskuje nie na fistaszkach w rodzaju oszczędzenia jednego
>> bajtu czy czterech cykli procesora, tylko na złożoności obliczeniowej
>> (asymptotycznej).
>
> To są takie rozważania teoretyczne, ale jak popatrzeć czasem na dyskusje na
> LKML, to tam jednak czasami przejmują się pojedynczymi instukcjami. Sądzę,
> że ma to sens - w końcu oni mają w tym doświadczenie.
>

Dokładnie tak!

Wiesz, Dozzie chyba jednak fantazjuje. Zapytany o Haskella nabrał wody w
usta. ;) Coś tam pewnie słyszał, ale do końca nie wie gdzie ;)

do góry

Krzysiek Kowaliczek wrote:

>> Magia typu void*. Nie ma co się rozpisywać. Jako programista
>> unixowy/linuxowy doskonale wiesz co mam na myśli.
>>
>
> Rozumiem że w programie dostajesz magiczne dane, ponieważ słaby
> system typów nie uratował Cię od pomyłki?

W przypadku sterowników urządzeń te magiczne dane można otrzymać z
urządzenia. Urządzenie zwykle śle strumień bajtów, bez systemu typów.

do góry

A. L. wrote:

> Mit ze "systemy operacyjne tzreba pisac w C bo nei ma typowania i jest
> bliskiasemblerowi" jest jednym z najbardziej idiotycznych mitow jakie
> sie rozpowszechniaja, a jak juz pisalem, fakt ze wiele programow
> "systemowych" jest napisanych w nietypowanym i niepewnym (non safe) C
> jest sprawca wielu problemow.

Jest sprawcą wielu problemów, ponieważ te programy istnieją i działają.
Gdyby programy nie powstały (bo ktoś tyle czasu zajmował się hierarchią
obiektów itp. technikami dobrego projektowania, że ostatecznie pominął ten
drobny szczegół, jak zrobienie działającego programu), to i problemów by nie
wywołały.

do góry

On 02/01/2011 11:05 PM, R. P. wrote:
> W dniu 2011-02-01 23:00, Jędrzej Dudkiewicz pisze:
>> Awk jest specjalizowanym narzędziem do przetwarzania tekstu, nic
>> dziwnego, że będzie działał szybciej niż napisany naprędce program w
>> C++. Fakt, że jest interpretowany, specjalnie nie przeszkadza, bo część
>> międląca napisy to kod cyzelowany pewnie od późnych lat
>> siedemdziesiątych. XIX wieku. W sensie - od dawna.
>
> Jasne, ale zaznaczam, że to był ten sam algorytm (dość trywialny
> O(n))... w C++ pomimo zastosowania resize'ów i używania referencji gdzie
> się da nie udało mi się uzyskać takiej wydajności jak w naprędce
> napisanym programie w awk, od którego nie jestem żadnym specjalistą i
> znam go co nieco tylko!

Skoro algorytm był trywialny, to znaczy, że znaczenie miało tylko
wycyzelowanie kodu go wykonującego. Gdyby cyzelowanie oznaczało tylko
referencje i resize, to programowanie byłoby proste.

>>> Tak mierzyłem. Miałem zestaw funkcji wczytujący pliki do pamięci (pliki
>>> 2-3 Gb) - stream okazał się 3x wolniejszy od chamskiego C-owego fgets'a.
>>> To są fakty.
>>
>> Bo stream może zrobić 3 razy więcej od chamskiego C-owego fgets. Poza
>> tym fgets czyta do stałego bufora. W świetle tego trzykrotna różnica nie
>> jest taka powalająca.
>
> Może zrobić 3x więcej. Ale jeśli mnie interesuje tylko wczytanie pliku
> linia po linii do wektora, to wolę użyć fgets.

No to po co używasz streamów? Jak chcesz znaleźć pierwsze wystąpienie
litery 'a' w stringu to używasz wyrażeń regularnych?

> 3x szybciej to nie jest
> duża różnica? Tzn. że task skończy się 3x szybciej, a trwa kilka dni (bo
> plików jest setki tysięcy)...

Ale przecież ja mówiłem o osiągach w porównaniu z możliwościami. To Twój
problem, że ich nie używasz.

JD

do góry

On 01/02/2011 20:28, R. P. wrote:
> W dniu 2011-02-01 20:57, Andrzej Jarzabek pisze:
>>
>> Powiem szczerze: bez konkretów i w świetle tego, co napisałeś,
>> najbardziej prawdopodobnym wyjaśnieniem wydaje się to, że kiepsko to
>> zaimplementowałeś bo słabo znasz C++.
>
> LOL. Algorytm był prosty, kolejne linie wczytywałem do wektora, na

A do czego wrzucałeś kolejne linie w awk?

> początku był zrobiony resize na wektorze, podobnie jak były robione
> resize'y na stringach. I dupa. Niewiele pomogło. Po prostu narzut
> związany z obsługą klas,

Nie ma żadnego narzutu.

> albo kiepska implementacja string.

Jet to możliwe, ale nie da się tego stwierdzić co najmniej bez
obejrzenia Twojego kodu.

> Przetwarzałeś texty w C++? Masz doświadczenie? Bo jakoś nie wierzę...

To uwierz.

> gdybyś przetwarzał, to byś wiedział, że std::string ma wiele wad.

Niewątpliwie ma, ale raczej nie takich, jak myślisz.

>>> Tak mierzyłem. Miałem zestaw funkcji wczytujący pliki do pamięci (pliki
>>> 2-3 Gb) - stream okazał się 3x wolniejszy od chamskiego C-owego fgets'a.
>>> To są fakty.
>>
>> Ditto, plus: jeśli zrobię 1000 razy wolniejszą implementację fgets, to
>> przyznasz, że C się nie nadaje?
>
> Nie, uznam że jesteś cienki ;)

A skąd wiesz, że tej implementacji biblioteki standardowej, na której to
testowałeś, ie napisał ktoś, kto jest cienki?

(pomijając w tym momencie możliwość, że to Ty jeteś cienki)

do góry

On 01/02/2011 21:50, Marek Borowski wrote:
>
> Cos mam wrazenie ze mylicie systemy z systemami. Operacje bliskie
> hardware najwygodniej sie robi w C. Jak np w innych jezykach wysokiego
> poziomu deklarujesz wywolanie funkcji z pod konkretnego adresu he ?
>
> W C prosze bardzo:
>
> void (*fun)(void) = (void (*)(void))0xFC00;
> fun();

Naprawdę muszę pisać, jak to można zrobić w C++?

> Jak po odebraniu pakietu dobierzesz sie do jego pol, bez dodatkowych
> narzutow ?
>
> W C jest to trywialne:
>
> uint8_t *buffer;
>
> a po odebraniu;
>
> struct Packet* usb = (struct Packet*) buffer;
>
> usb->requestType i jedziemy.

Naprawdę? Szkoda tylko, że jak piszesz tę strukturę, to musisz pilnować,
żeby wszystkie pola były na swoim miejscu i żeby Ci kompilator nie
namieszał paddingiem na przykład.

Jak w C zapiszesz pole pakietu, które jest zaczyna się od ósmego bajta i
jest czterobajtową liczbą, powiedzmy bez znaku, zapisaną w formacie -
uwaga - big endian?

W C++ za to możesz bez problemu wrapnąć bufor bajtowy w klasę, która
jako dane pole udotępnia ci dajmy na to 14 bajt bufora albo wartość
liczbową w natywnym formacie, zapisaną jako big endian na bajtach od 4 do 7.

do góry

On 02/02/2011 01:06 AM, Andrzej Jarzabek wrote:
> On 01/02/2011 21:50, Marek Borowski wrote:
>>
>> Cos mam wrazenie ze mylicie systemy z systemami. Operacje bliskie
>> hardware najwygodniej sie robi w C. Jak np w innych jezykach wysokiego
>> poziomu deklarujesz wywolanie funkcji z pod konkretnego adresu he ?
>>
>> W C prosze bardzo:
>>
>> void (*fun)(void) = (void (*)(void))0xFC00;
>> fun();
>
> Naprawdę muszę pisać, jak to można zrobić w C++?
>
>> Jak po odebraniu pakietu dobierzesz sie do jego pol, bez dodatkowych
>> narzutow ?
>>
>> W C jest to trywialne:
>>
>> uint8_t *buffer;
>>
>> a po odebraniu;
>>
>> struct Packet* usb = (struct Packet*) buffer;
>>
>> usb->requestType i jedziemy.
>
> Naprawdę? Szkoda tylko, że jak piszesz tę strukturę, to musisz pilnować,
> żeby wszystkie pola były na swoim miejscu i żeby Ci kompilator nie
> namieszał paddingiem na przykład.

__attribute__((packed)), pola struktury nie mogą być przekładane.

> Jak w C zapiszesz pole pakietu, które jest zaczyna się od ósmego bajta i
> jest czterobajtową liczbą, powiedzmy bez znaku, zapisaną w formacie -
> uwaga - big endian?

Rozumiem, że chodzi o deklarację tego pola w strukturze? Otóż wstawię na
początek pól na łączną wartość 7 bajtów, potem wstawię czterobajtową
zmienną, a potem wywołam funkcję "preprocess_packet", która mi zawoła
ntohl i pochodne na wskazanych polach, w tym na tej zmiennej.

> W C++ za to możesz bez problemu wrapnąć bufor bajtowy w klasę, która
> jako dane pole udotępnia ci dajmy na to 14 bajt bufora albo wartość
> liczbową w natywnym formacie, zapisaną jako big endian na bajtach od 4
> do 7.

Jasne, ale w środku albo będziesz kopiował dane do oddzielnych pól, albo
będziesz trzymał wskaźniki do nich i wołał ntohl przy dostępie, albo
wstawisz powyższy syf. To trzecie ma najmniejszy narzut pamięciowy i
obliczeniowy w czasie wykonania.

Tak czy owak, zaletą C++ jest to, że jakby co, to można tego rozwiązania
użyć, ale znacznie ładniej zapakowanego.

JD

do góry

W dniu 01.02.2011 21:29, R. P. pisze:
>> No dobrze, ale jaką dokładnie operację w C porównujesz z wywołaniem
>> metody wirtualnej?
>
> Np. wsk. do funkcji z indeksem.
Wywołanie metody wirtualnej to jest wywołanie pod adres
vtable[nr_metody] gdzie vtable to wskaźnik będący pierwszym elementem
składowym obiektu.

ebx zawiera wskaźnik do obiektu z 2 metodami virt, wywołanie 2giej. Zrób
to szybciej w C.

0x080487c4 <main+68>: mov eax,DWORD PTR [ebx]
0x080487c6 <main+70>: mov DWORD PTR [esp],ebx
0x080487c9 <main+73>: call DWORD PTR [eax+0x4]

--
Pozdrawiam
Michoo

do góry

W dniu 01.02.2011 19:30, R. P. pisze:
> Tak mierzyłem. Miałem zestaw funkcji wczytujący pliki do pamięci (pliki
> 2-3 Gb) - stream okazał się 3x wolniejszy od chamskiego C-owego fgets'a.
Wierzę.

> To są fakty.
Tak, ale świadczące o programiście/pomiarze/kompilatorze a nie o języku.

Ja na kodzie http://prowizorka.da.ru/~michoo/smieci/iogets.cpp
dostrzegam ~12% różnicy.

michoo@altair:/tmp$ head -n 1 /progs/file|wc -c
15
michoo@altair:/tmp$ wc -l /progs/file
67108864 /progs/file
michoo@altair:/tmp$ ls -lh /progs/file
-rw-r--r-- 1 michoo michoo 960M 02-02 02:36 /progs/file
michoo@altair:/tmp$ g++ kod.cpp -O2 -D RUN_C_RUN
michoo@altair:/tmp$ /usr/bin/time ./a.out </progs/file
C
7.98user 0.92system 0:11.96elapsed 74%CPU (0avgtext+0avgdata
3344maxresident)k
1209576inputs+0outputs (0major+264minor)pagefaults 0swaps
michoo@altair:/tmp$ g++ kod.cpp -O2
michoo@altair:/tmp$ /usr/bin/time ./a.out </progs/file
C++
9.67user 0.94system 0:12.19elapsed 87%CPU (0avgtext+0avgdata
3776maxresident)k
1209576inputs+0outputs (0major+292minor)pagefaults 0swaps

No chyba, że ktoś odpala ten kod w trybie kompatybilności z C.
michoo@altair:/tmp$ /usr/bin/time ./a.out </progs/file
C++
95.26user 1.52system 1:41.08elapsed 95%CPU (0avgtext+0avgdata
3744maxresident)k
1209576inputs+0outputs (0major+290minor)pagefaults 0swaps

--
Pozdrawiam
Michoo

do góry