eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingwydajnosc wyjatkow
Ilość wypowiedzi w tym wątku: 17

  • 11. Data: 2012-03-29 09:01:01
    Temat: Re: wyjatki
    Od: " " <f...@g...SKASUJ-TO.pl>

    w wiki jest napisane:

    "Two schemes are most common. The first, dynamic registration, generates code
    that continually updates structures about the program state in terms of
    exception handling.[8] Typically, this adds a new element to the stack frame
    layout that knows what handlers are available for the function or method
    associated with that frame; if an exception is thrown, a pointer in the
    layout directs the runtime to the appropriate handler code. This approach is
    compact in terms of space, but adds execution overhead on frame entry and
    exit. It was commonly used in many Ada implementations, for example, where
    complex generation and runtime support was already needed for many other
    language features. Dynamic registration, being fairly straightforward to
    define, is amenable to proof of correctness.[9]

    The second scheme, and the one implemented in many production-quality C++
    compilers, is a table-driven approach. This creates static tables at compile
    and link time that relate ranges of the program counter to the program state
    with respect to exception handling.[10] Then, if an exception is thrown, the
    runtime system looks up the current instruction location in the tables and
    determines what handlers are in play and what needs to be done. This approach
    minimizes executive overhead for the case where an exception is not thrown,
    albeit at the cost of some space, although said space can be allocated into
    read-only, special-purpose data sections that are not loaded or relocated
    until and unless an exception is thrown.[11] This second approach is also
    superior in terms of achieving thread safety."

    czyli gdyby to drugie u mnie dzialalo to bym mial spowolnienia w
    loader time i nawet nie wiem,

    jak wspomnialem mz wykorzystanie wyjatkow by wylaczyc na stale jakas
    funkcje/galaz z ktorej polecial jakis niezidentyfikowany blad moze
    byc moze miec ew pewien sens - (poki co jedyne ew sensowne dzialanie
    jakiemi sie z tym kojarzy) - ale nie pisze poki co programow
    ktore by tego wymagaly a wolalbym kiedys przemyslec obsluge bledow w
    szerszy i ogolnijszy sposob

    co do longjmp to ta struktura pod b55 jest np taka

    typedef struct __jmp_buf {
    unsigned j_ebp;
    unsigned j_ebx;
    unsigned j_edi;
    unsigned j_esi;
    unsigned j_esp;
    unsigned j_ret;
    unsigned j_excep;
    unsigned j_context;
    } jmp_buf[1];

    nie wiem po co niektore pola (np edi esi ebx, czy to potrzeba zachowania
    czesci kontekstu funkcji z catch? ani co to jest j_ret) bo srednio sie
    w tym orientuje - ogolnie wydaje sie to byc jednak kwestia obslugi
    mechanizmu powrotu w tyl po drzewku a nie samych kwestii z wyjatkami
    (bo same powroty mozna rozpatrywac w oderwaniu od wyjatkow)







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


  • 12. Data: 2012-03-29 10:39:54
    Temat: Re: wydajnosc wyjatkow
    Od: " " <f...@g...pl>

    >
    > Gdzie tu jest problem z wydajnością, albo z ogromną pamięcią? Nie
    > mogę się doszukać. Lippman bzdury pisał czy ja czegoś nie rozumiem?
    >

    o ile chodzi o sam "long ret" (raczej nie powinno sie to nazywac
    long jump) czyli np ret pod label

    void fu()
    {
    ret somewhera_back;
    }

    to mz nie powinno to byc chyba wolniejsze niz zwykly ret,
    trzeba zaladowac odwinieta wartosc wskaznika stosu (jest znana
    statycznie) i skoczyc pod label

    mov esp, 0x45526536
    jmp somewhere_back

    chyba tylko tyle - i moze wlasnie ew takie rety pod label
    sporadycznie przydalyby sie w jezyku


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


  • 13. Data: 2012-03-29 19:23:34
    Temat: Re: wyjatki
    Od: Tomasz D <t...@g...com>

    Złapanie GPFa pod windą jest możliwe dzięki structured exceptions.

    A swoją drogą, jeśli nie robisz tego celowo, zacznij korzystać z przeglądarki
    sprawdzającej pisownię, bo to aż w oczy kłuje :/


  • 14. Data: 2012-03-30 15:24:48
    Temat: Re: wyjatki
    Od: g...@n...invalid (Adam Wysocki)

    <f...@g...skasuj-to.pl> wrote:

    > jak wspomnialem mz wykorzystanie wyjatkow by wylaczyc na stale jakas
    > funkcje/galaz z ktorej polecial jakis niezidentyfikowany blad moze
    > byc moze miec ew pewien sens - (poki co jedyne ew sensowne dzialanie
    > jakiemi sie z tym kojarzy) - ale nie pisze poki co programow
    > ktore by tego wymagaly a wolalbym kiedys przemyslec obsluge bledow w
    > szerszy i ogolnijszy sposob

    Ukrywanie błędów to ślepa uliczka. Tak długo, jak nie masz pewności, co
    właściwie się stało, próba kontrolowanego kontynuowania programu może
    być ryzykowna. Chociażby dlatego że nie wiesz w jakim stanie jest heap,
    w końcu poszedł wyjątek = coś poszło nie tak jak przewidziano.

    M.in. dlatego stosowanie catchall jest przez wielu uznawane za złą praktykę.

    Osobna sprawa to catch własnego wyjątku - ja często w miejscach, w których
    zakładam, że coś powinno być tak a nie inaczej, daję dla pewności coś ala
    assert - ale własny, zawsze kompilowany, a nie biblioteczny (który rozwijany
    jest tylko w wersji debugowej). Makro sprawdza warunek i jak jest niezgodny,
    to rzuca wyjątek z określoną treścią, np:

    int rs = funkcja();
    Assert(rs == 3, "%d", rs);

    switch (a)
    {
    case ...:
    break;
    default:
    Assert(false, "%d", a);
    }

    Wtedy funkcja łapiąca wyjątek może wypisać komunikat i wyjść, a main wtedy
    zakończy program (dbam o to żeby miejsce wyjścia z programu było tylko
    jedno).

    > nie wiem po co niektore pola (np edi esi ebx, czy to potrzeba zachowania
    > czesci kontekstu funkcji z catch? ani co to jest j_ret)

    Jak chcesz programować wysokopoziomowo to musisz nauczyć się myśleć
    wysokopoziomowo. Rejestry zostaw kompilatorowi.

    --
    Gof


  • 15. Data: 2012-03-30 15:49:31
    Temat: Re: wyjatki
    Od: " M.M." <m...@g...SKASUJ-TO.pl>

    g...@n...invalid (Adam Wysocki) napisał(a):

    > Ukrywanie błędów to ślepa uliczka.
    [...]
    > zakończy program (dbam o to żeby miejsce wyjścia z programu było tylko
    > jedno).

    Nie ma innego wyjścia, kod diagnostyczny w każdym większym programie
    musi stanowić jego istotną część. Kilka lat temu z wersji release
    przestałem usuwać kod diagnostyczny. Gdy ważna jest wydajność, albo
    gdy asercja jest bardzo czasochłonna, to można stosować testy na
    wyrywki, typu:

    if( rand() % 1024 == 0 )
    test(...);

    Pozdrawiam






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


  • 16. Data: 2012-03-30 18:56:43
    Temat: Re: wydajnosc wyjatkow
    Od: bartek szurgot <b...@n...spam>

    On 03/28/2012 08:51 AM, M.M. wrote:
    > Czesc
    >
    > Kiedyś dawno z lat temu 10 albo jeszcze dawniej, przeczytałem
    > straszną rzecz o wyjątkach w C++. Pisał sam Lippman więc się trochę
    > przejąłem. Pisał on mianowicie że po włączeniu wyjątków skompilowany
    > program nie zmieścił się w pamięci ram. Nie zastanawiając się głębiej
    > uznałem że wyjątki wiążą się z jakimś narzutem i gdy była ważna
    > szybkość działania programu to ich nie używałem.
    >
    > Teraz gdy się zastanawiam to wydaje mi się kompletnie bezsensowne aby
    > wyjątki wiązały się z jakimś dużym narzutem. Do czego ten narzut niby jest
    > potrzebny?
    >
    > Gdy kompilator napotyka instrukcję try to co musi zrobić? Moim zdaniem
    > musi gdzieś zapamiętać adres wejścia do sekcji catch. Coś takiego
    > chyba najlepiej zapamiętać na jakimś stosie. Więc dużo zależy od tego
    > jak stos jest realizowany. Jeśli odkładanie elementu na stos jest
    > związane z malloc to mamy narzut taki sam jaki narzut ma malloc. Jeśli
    > stos jest budowany bez malloc to narzut jest pomijalny, wystarczy tylko
    > zapamiętać trochę danych, może z 20-30 bajtów.
    >
    > Gdy kompilator napotyka koniec sekcji catch to co musi zrobić? Chyba tylko
    > musi usunąć ze stosu to co wcześniej na nim zapamiętał. Więc o wydajności
    > decyduje sposób w jaki to kompilator zapamiętuje.
    >
    > A co gdy kompilator napotyka throw Object? Zdaje się że musi odczytać
    > kolejno zapamiętane informacje przy napotkaniu try. Jeśli znajdzie
    > pasujący catch( Object ) to musi odtworzyć stos pointer. Potem na stos
    > odkłada Object i musi zrobić long jump do odpowiedniego catch.
    >
    > Jednak wyjatki rzadko sie uaktywniają. Najczęściej mamy
    > if( false ) throw Object. Czy kompilator jak widzi ze w
    > procedurze jest throw Object to musi wygenerować jakiś
    > kod który się wykona pomimo że wyjątek nie będzie rzucony?
    > Moim zdaniem nie musi.
    >
    > Gdzie tu jest problem z wydajnością, albo z ogromną pamięcią? Nie
    > mogę się doszukać. Lippman bzdury pisał czy ja czegoś nie rozumiem?
    >
    > Pozdrawiam


    hejka,

    zapewne mowa o dość starej książce Lippmana. :) tak w b. dużym skrócie
    sprawa ma się tak: stare podejście "dynamiczne" powodowało odkładanie na
    stosie sporo śmiecia, by program wiedział jakie obiekty niszczyć w
    przypadku zgłoszenia wyjątku. oznacza to wzrost rozmiaru binarki i sporo
    dodatkowej pamięci na stosie. było tak na początku lat '90. obecnie
    stosuje się podejście "tablicowe" (pomysł z połowy lat '90), które nie
    powoduje ŻADNEGO narzutu czasowego ani pamięciowego, podczas normalnego
    (i.e. nie-wyjątkowego) przebiegu. w praktyce oznacza to, że jest
    "tańsze" niż ręczne klepanie kodów powrotu, które zawsze trzeba
    sprawdzić. :) użycie wyjątków powoduje jedynie zwiększenie binarki o
    ~10-20%, na wygenerowanie w/w tablic.

    niedawno pisałem o tym na blogu:
    http://www.baszerr.eu/doku.php/blog/2012/02/26/1
    są też przykładowe kody do pobrania i odpalenia - można się pobawić.

    dla osób zainteresowanych problematyką narzutów C++ polecam doskonały
    raport techniczny:
    http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.
    pdf
    obalonych jest tam mnóstwo mitów, również ten o narzucie jakie powodują
    wyjątki (podrozdział 5.4).

    świat się zmienia, technologia idzie do przodu a wiedza się
    dezaktualizuje... :)

    --
    pozdrawiam serdecznie / best regards,
    bartek szurgot
    /* http://www.baszerr.eu */


  • 17. Data: 2012-03-30 20:54:15
    Temat: Re: wyjatki
    Od: " " <f...@g...SKASUJ-TO.pl>

    > Jak chcesz programować wysokopoziomowo to musisz nauczyć się myśleć
    > wysokopoziomowo.

    hehe, nie mam takiego zamiaru



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

strony : 1 . [ 2 ]


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: