W dniu 2011-02-01 18:13, Michoo pisze:
> W dniu 01.02.2011 16:58, R. P. pisze:
>> W dniu 2011-02-01 16:53, Andrzej Jarzabek pisze:
>>> On Feb 1, 3:46 pm, "R. P."<r...@w...pl> wrote:
>>>> W dniu 2011-02-01 16:44, Andrzej Jarzabek pisze:
>>>>
>>>>> Nieprawda. "Chytre rzuty" nie wnosz nic w kwestii wydajno ci.
>>>>
>>>> Pozawalaj np. omin tablic funkcji wirtualnych, kt ra daje narzut
>>>> czasowy.
> Jaki narzut ma wywołanie funkcji wirtualnej? Na pewno mierzyłeś (ja
> mierzyłem ;) ). No słucham.

Zależy od tego ile jest klas pochodnych. Jeśli 200 to już robi różnicę.
Parę taktów procesora można stracić... A to jest jądro - tutaj każda
mikrosekunda jest ważna.


>> Po prostu w C++ robisz
>> hierarchię klas (tak jest ładnie) a w C pojęcia klasy nie masz, odpada
>> więc dziedziczenie itp.
> Jak byś miał trochę praktyki to byś się spotkał z GTK i GLIBem. Jak byś
> się spotkał to byś widział czym się kończy kretynizm każący pisać w C a
> skutkujący implementowaniem podzbioru C++ (polimorfizm, funkcje wirtualne).

Takie rzeczy robi się tylko w programowaniu systemowym. Te funkcje będą
setki tysięcy razy wywoływane, nawet jeśli zyska się parę taktów
procesora, to już jest coś (mimo że algorytm asymptotycznie pozostaje o
tej samej złożoności).

do góry

W dniu 2011-02-01 18:07, Michoo pisze:
> W dniu 01.02.2011 16:57, R. P. pisze:
>>
>> Taka np. klasa string w C++ na pewno właściwą strukturą nie jest, bo to
>> samo napisane w interpretowanym awk (ten sam algorytm przetwarzania
>> tekstu) potrafi zadziałać 3x szybciej... Podobnie wiele innych klas w
>> std jest w c++ spapranych.
> Konkret - co takiego było 3 razy szybsze w AWK?

Pewien algorytm obrabiający tekstowy plik CSV, zawierający milion
rekordów, każdy po 30 pól. Nic wielkiego, ale do testów wystarczy.
Algorytm był ten sam, na awk przepisałem go dosłownie tak samo.
Złożoność algorytmu była O(n). W awk wykonał się 3x szybciej.

>> Chociażby stream'y też są wydajnościowo
>> skopane i w C zawsze wychodzi szybciej.
> Ale mierzyłeś, tak? Czy na jakiej podstawie tak twierdzisz? (I w
> porównaniu do czego?).
>

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.

do góry

On 01/02/2011 18:28, R. P. wrote:
> W dniu 2011-02-01 18:13, Michoo pisze:
>> Jaki narzut ma wywołanie funkcji wirtualnej? Na pewno mierzyłeś (ja
>> mierzyłem ;) ). No słucham.
>
> Zależy od tego ile jest klas pochodnych.

Na dzień dobry już po tym widać, że nie masz pojęcia.

> Jeśli 200 to już robi różnicę.
> Parę taktów procesora można stracić...

W stosunku do czego można stracić?

>> Jak byś miał trochę praktyki to byś się spotkał z GTK i GLIBem. Jak byś
>> się spotkał to byś widział czym się kończy kretynizm każący pisać w C a
>> skutkujący implementowaniem podzbioru C++ (polimorfizm, funkcje
>> wirtualne).
>
> Takie rzeczy robi się tylko w programowaniu systemowym.

Jakie rzeczy? Emulację polimorfizmu w C? To chyba właśnie wiadczy o tym,
że C się niezbyt dobrze do tego nadaje.

> Te funkcje będą
> setki tysięcy razy wywoływane, nawet jeśli zyska się parę taktów
> procesora, to już jest coś (mimo że algorytm asymptotycznie pozostaje o
> tej samej złożoności).

No dobrze, ale jaką dokładnie operację w C porównujesz z wywołaniem
metody wirtualnej?

do góry

On 01/02/2011 18:30, R. P. wrote:
> W dniu 2011-02-01 18:07, Michoo pisze:
>
>> Konkret - co takiego było 3 razy szybsze w AWK?
>
> Pewien algorytm obrabiający tekstowy plik CSV, zawierający milion
> rekordów, każdy po 30 pól. Nic wielkiego, ale do testów wystarczy.
> Algorytm był ten sam, na awk przepisałem go dosłownie tak samo.
> Złożoność algorytmu była O(n). W awk wykonał się 3x szybciej.

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++.

> 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?

do góry

W dniu 2011-02-01 20:57, Andrzej Jarzabek pisze:
> On 01/02/2011 18:30, R. P. wrote:
>> W dniu 2011-02-01 18:07, Michoo pisze:
>>
>>> Konkret - co takiego było 3 razy szybsze w AWK?
>>
>> Pewien algorytm obrabiający tekstowy plik CSV, zawierający milion
>> rekordów, każdy po 30 pól. Nic wielkiego, ale do testów wystarczy.
>> Algorytm był ten sam, na awk przepisałem go dosłownie tak samo.
>> Złożoność algorytmu była O(n). W awk wykonał się 3x szybciej.
>
> 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
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, albo kiepska implementacja string.
Przetwarzałeś texty w C++? Masz doświadczenie? Bo jakoś nie wierzę...
gdybyś przetwarzał, to byś wiedział, że std::string ma wiele wad.

>> 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 ;)

do góry

W dniu 2011-02-01 20:29, Andrzej Jarzabek pisze:
> On 01/02/2011 18:28, R. P. wrote:
>> W dniu 2011-02-01 18:13, Michoo pisze:
>>> Jaki narzut ma wywołanie funkcji wirtualnej? Na pewno mierzyłeś (ja
>>> mierzyłem ;) ). No słucham.
>>
>> Zależy od tego ile jest klas pochodnych.
>
> Na dzień dobry już po tym widać, że nie masz pojęcia.

Niby czemu? Od czego zależy wielkość vtable? :)

>
>> Jeśli 200 to już robi różnicę.
>> Parę taktów procesora można stracić...
>
> W stosunku do czego można stracić?

Do "wzorcowej" implementacji w C++.

>> Te funkcje będą
>> setki tysięcy razy wywoływane, nawet jeśli zyska się parę taktów
>> procesora, to już jest coś (mimo że algorytm asymptotycznie pozostaje o
>> tej samej złożoności).
>
> No dobrze, ale jaką dokładnie operację w C porównujesz z wywołaniem
> metody wirtualnej?

Np. wsk. do funkcji z indeksem. Rzutowanie dwóch różnych struktur na
void*, rzeźbienie po pamięci. W C++ są dodatkowe ograniczenia, jeśli
chcesz to robić "po bożemu" - np. sprawdzanie runtime'owe kosztuje parę
taktów procka.

do góry

On 01-02-2011 14:34, Krzysiek Kowaliczek wrote:
> Użytkownik R. P. napisał:
>> Prostoty. C++ ze swoimi szablonami itp. narzędziami jest zbyt
>> skomplikowany do pisania oprogramowania systemowego w nim.
>
> Kto Cię zmusza do używania szablonów? Masz jeszcze do dyspozycji
> bezpieczniejszy system typów ( choć daleko mu jeszcze do ideału ),
> destruktory, itd. Zresztą pisałem też o Adzie i Pascalu.
>
>>> Rozumiem że w programie dostajesz magiczne dane, ponieważ słaby
>>> system typów nie uratował Cię od pomyłki?
>>
>> Halo, przecież ja mówię cały czas o programowaniu systemowym, nie
>> aplikacyjnym!
>
> To właśnie w programowaniu systemowym powinno się kłaść *maksymalny*
> nacisk na bezpieczeństwo!
>
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();

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.

Proste i wygodne.


Pozdr

Marek

do góry

On 01/02/2011 20:29, R. P. wrote:
> W dniu 2011-02-01 20:29, Andrzej Jarzabek pisze:
>>>
>>> Zależy od tego ile jest klas pochodnych.
>>
>> Na dzień dobry już po tym widać, że nie masz pojęcia.
>
> Niby czemu? Od czego zależy wielkość vtable? :)

Od ilości funkcji wirtualnych. Ale jaka jest wg. Ciebie zależność między
narzutem na wywołanie funkcji wirtualnej, a wielkością vtable?

>>> Jeśli 200 to już robi różnicę.
>>> Parę taktów procesora można stracić...
>> W stosunku do czego można stracić?
>
> Do "wzorcowej" implementacji w C++.

Dlaczego uważasz, że istniejące implementacje są gorsze niż wzorcowa.

>> No dobrze, ale jaką dokładnie operację w C porównujesz z wywołaniem
>> metody wirtualnej?
>
> Np. wsk. do funkcji z indeksem.

Na przykład czego? Chodzi o wywołanie funkcji przez n-ty element tablicy
wskaźników na funkcje? I na jakiej podstawie twierdzisz, że wywołanie
funkcji wirtualnej jest bardziej kosztowne?

> Rzutowanie dwóch różnych struktur na void*,

To nie zapewnia funkcjonalności funkcji wirtualnej.

> rzeźbienie po pamięci.

To nie zapewnia funkcjonalności funkcji wirtualnej.

> W C++ są dodatkowe ograniczenia, jeśli

Jakie?

> chcesz to robić "po bożemu" - np. sprawdzanie runtime'owe kosztuje parę
> taktów procka.

Dlaczego uważasz, że sprawdzenie runtime'owe to jest "robienie tego po
bożemu"? I czego właściwie? Rzutowania wskaźników? O operatorze
static_cast słyszałeś, czy może uważasz, że jest "bezbożny"?

do góry

On 02/01/2011 07:30 PM, R. P. wrote:
> W dniu 2011-02-01 18:07, Michoo pisze:
>> W dniu 01.02.2011 16:57, R. P. pisze:
>>>
>>> Taka np. klasa string w C++ na pewno właściwą strukturą nie jest, bo to
>>> samo napisane w interpretowanym awk (ten sam algorytm przetwarzania
>>> tekstu) potrafi zadziałać 3x szybciej... Podobnie wiele innych klas w
>>> std jest w c++ spapranych.
>> Konkret - co takiego było 3 razy szybsze w AWK?
>
> Pewien algorytm obrabiający tekstowy plik CSV, zawierający milion
> rekordów, każdy po 30 pól. Nic wielkiego, ale do testów wystarczy.
> Algorytm był ten sam, na awk przepisałem go dosłownie tak samo.
> Złożoność algorytmu była O(n). W awk wykonał się 3x szybciej.

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.

>>> Chociażby stream'y też są wydajnościowo
>>> skopane i w C zawsze wychodzi szybciej.
>> Ale mierzyłeś, tak? Czy na jakiej podstawie tak twierdzisz? (I w
>> porównaniu do czego?).
>>
>
> 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.

JD

do góry

W dniu 2011-02-01 23:00, Jędrzej Dudkiewicz pisze:
> On 02/01/2011 07:30 PM, R. P. wrote:
>> W dniu 2011-02-01 18:07, Michoo pisze:
>>> W dniu 01.02.2011 16:57, R. P. pisze:
>>>>
>>>> Taka np. klasa string w C++ na pewno właściwą strukturą nie jest, bo to
>>>> samo napisane w interpretowanym awk (ten sam algorytm przetwarzania
>>>> tekstu) potrafi zadziałać 3x szybciej... Podobnie wiele innych klas w
>>>> std jest w c++ spapranych.
>>> Konkret - co takiego było 3 razy szybsze w AWK?
>>
>> Pewien algorytm obrabiający tekstowy plik CSV, zawierający milion
>> rekordów, każdy po 30 pól. Nic wielkiego, ale do testów wystarczy.
>> Algorytm był ten sam, na awk przepisałem go dosłownie tak samo.
>> Złożoność algorytmu była O(n). W awk wykonał się 3x szybciej.
>
> 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!

>>>> Chociażby stream'y też są wydajnościowo
>>>> skopane i w C zawsze wychodzi szybciej.
>>> Ale mierzyłeś, tak? Czy na jakiej podstawie tak twierdzisz? (I w
>>> porównaniu do czego?).
>>>
>>
>> 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. 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)... jak dla mnie różnica kolosalna. W obu
przypadkach algorytm jest ten sam więc czasy asymptotyczne identyczne.

do góry