eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingBCB Moj ulubiony kod;)Re: BCB Moj ulubiony kod;)
  • Data: 2010-02-20 04:31:53
    Temat: Re: BCB Moj ulubiony kod;)
    Od: Mariusz Marszałkowski <m...@g...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    On 19 Lut, 23:58, Michoo <m...@v...pl> wrote:
    > Mariusz Marszalkowski pisze:
    >
    > > On 19 Lut, 22:48, Michoo <m...@v...pl> wrote:
    > >> To jest dokladnie ten sam kod, ale w jednym wypadku dane upakowane i
    > >> false-sharing daje o sobie znac, w drugim nie.
    >
    > > Nie wiem czy rozumiem, ten sam kod w wielu watkach?
    >
    > 8 watkow. W pierwszym przypadku trzymajace swoje zmienne 'lokalne' w
    > globalnej tablicy o rozmiarze 8 a w drugim - na stosie.
    No to sprawa jasna, lokalnosc danych jest kluczowa dla wydajnosci.

    > > Chcialem przypomniec troche inny fakt, a mianowicie ze
    > > tej szybkiej pamieci w nowoczesnych komputerach nadal jest znacznie
    > > mniej niz pamieci w ogole. Jesli algorytm nie dobiera sie do danych
    > > sekwencyjnie, to caly czas najlepiej upakowac wszystkie dane tak,
    > > aby zmiescily sie w niezbyt duzej pamieci cache.
    >
    > Zgadza sie. Tylko sytuacja w ktorej potrzebujemy dostep losowy i dane
    > sie mieszcza w cache nie jest specjalnie czesta... No i czasami lepiej
    > po prostu przeorganizowac dane tak, zeby sie dalo je w pipeline uzyc.
    Moj program tak ma. Wiele czesciowych wynikow trzyma w roznych
    tablicach do ktorych dostep jest bardzo chaotyczny. Kiedys napisalem
    program ktory mial niemal wszystkie czesciowe wynik w pamieci, ale
    dzialal wolniej, prawdopodobnie dlatego, ze czesciowe wyniki znacznie
    przekraczaly rozmiar pamieci cache - oplacalo sie wykonac wiecej
    obliczen,
    ale zajac mniej pamieci. Poza tym kazdy program ktory korzysta ze
    struktury
    hash-table ma losowy dostep do pamieci. Przeszukujac graf, albo drzewo
    tez
    szybko trafiamy w dosc przypadkowy fragment pamieci - a to powszechne
    struktury danych. Upieram sie, ze upakowanie danych nadal jest
    kluczowe dla
    wydajnosci.

    > > W przypadku przetwarzania wieloprocesorowego sprawa komplikuje sie
    > > jeszcze bardziej. Idealnie jesli kazdy watek moze miec swoja lokalna
    > > kopie
    > > danych, ale to nie jest zawsze mozliwe.
    >
    > Czyli wlasnie rezygnujemy z oszczedzania pamieci na rzecz wydajnosci.
    Nie rezygnujemy z oszczednosci pamieci. Nadal upychamy dane jak to
    tylko oplacalne, ale upakowane dane powielamy tak aby kazdy procesor
    mial swoja kopie.

    > Pozdrawiam
    Rowniez pozdrawiam

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

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: