eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingjak napisać szybki program › Re: jak napisać szybki program
  • Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!newsfeed.atman.pl!goblin2!goblin.stu
    .neva.ru!feeder2.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.87.MISMATCH!ne
    ws.astraweb.com!border2.a.newsrouter.astraweb.com!transit4.hitnews.eu!feeder.ne
    ws-service.com!postnews.google.com!g19g2000vbi.googlegroups.com!not-for-mail
    From: Maciej Sobczak <s...@g...com>
    Newsgroups: pl.comp.programming
    Subject: Re: jak napisać szybki program
    Date: Wed, 20 May 2009 01:55:46 -0700 (PDT)
    Organization: http://groups.google.com
    Lines: 84
    Message-ID: <9...@g...googlegroups.com>
    References: <9...@r...googlegroups.com>
    <2...@c...tac>
    <0...@r...googlegroups.com>
    <5...@q...googlegroups.com>
    <2...@o...googlegroups.com>
    <gurhp6$rh3$1@news.onet.pl>
    <d...@g...googlegroups.com>
    <gutqoa$fjh$1@news.onet.pl>
    <f...@l...googlegroups.com>
    <guu61o$k3e$1@news.onet.pl> <guut87$pu9$1@news.onet.pl>
    <2...@s...googlegroups.com>
    <guv72b$ofk$1@news.onet.pl>
    NNTP-Posting-Host: 137.138.182.236
    Mime-Version: 1.0
    Content-Type: text/plain; charset=ISO-8859-2
    Content-Transfer-Encoding: quoted-printable
    X-Trace: posting.google.com 1242809746 31697 127.0.0.1 (20 May 2009 08:55:46 GMT)
    X-Complaints-To: g...@g...com
    NNTP-Posting-Date: Wed, 20 May 2009 08:55:46 +0000 (UTC)
    Complaints-To: g...@g...com
    Injection-Info: g19g2000vbi.googlegroups.com; posting-host=137.138.182.236;
    posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S
    User-Agent: G2/1.0
    X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.8)
    Gecko/2009032608 Firefox/3.0.8,gzip(gfe),gzip(gfe)
    Xref: news-archive.icm.edu.pl pl.comp.programming:182062
    [ ukryj nagłówki ]

    On 19 Maj, 23:08, Michoo <m...@v...pl> wrote:

    > > char my_buffer[my_size];
    >
    > > Niezależnie od metody dane muszą być przetransferowane z/do my_buffer.
    >
    > W przypadku dobrej implementacji (na gruncie czystej teorii - nie chce
    > mi się teraz zastanawiać gdzie to jak jest zaimplementowane - chodzi mi
    > o sam fakt, że jest to jedyny zysk jaki można osiągnąć) i/o kopiowanie
    > danych na drodze dysk->ram, bufor karty sieciowej-> ram, etc powinno być
    > robione "na zewnątrz" procesora (i to w trybie nie odcinającym go od szyny).

    Tak i jest to możliwe zarówno przy synchronicznym jak i
    asynchronicznym I/O.
    Różnica między nimi jest tylko w tym, że pierwszy czeka na zakończenie
    procesu a drugi jest "powiadamiany".

    Oczywiście można sobie też wyobrazić, że w jednym z przypadków system
    korzysta z dodatkowych buforów i wykonuje dodatkowe kopie danych, ale
    to jest kwestia jakości implementacji i nie ma związku z samym
    aspektem synchro/asynchro.

    Dlatego nie ma sensu twierdzić, że AIO daje jakiś zysk w kontekście
    zarządzania buforami.

    > synchroniczne i/o: program robi wywołanie systemowe "czytaj" system
    > wywala wątek z kolejki procesów gotowych i zleca kontrolerowi transfer,
    > po otrzymaniu przerwania od kontrolera proces wraca do kolejki i w
    > najbliższym czasie wraca z wywołania

    Tak.

    > asynchroniczne i/o: program robi wywołanie systemowe "czytaj" system
    > zleca kontrolerowi transfer, wątek powraca z wywołania i może pracować.
    > po otrzymaniu przerwania od kontrolera system powiadamia wątek o
    > zakończeniu operacji.

    To duży skrót myślowy [*], ale przyjmijmy roboczo, że tak jest.
    Trwa to dokładnie tyle samo (bo dysk się kręci tak samo szybko).

    [*] Skrót myślowy polega na tym, że w językach sekwencyjnych nie ma
    czegoś takiego jak "powiadamianie wątku". Są dwa możliwe mechanizmy:
    1. Sygnalizacja (notify) jakiegoś wskazanego obiektu
    synchronizacyjnego. Pozwala to właściwym wątkom roboczym zorientować
    się (blokująco bądź nie), że operacja się zakończyła.
    2. Wywołanie przez callback - to wywołanie odbywa się w *innym* wątku,
    z osobnym stosem, przynajmniej koncepcyjnie (tu wliczamy wszystko od
    sygnałów w C po AsyncHandler w Javie). Zwykle jedyna rzecz jaką można
    w takim callbacku sensownie zrobić to... ręcznie punkt 1.

    To żadna magia, dlatego też w ostatecznym rozrachunku SIO i AIO
    mogą robić to samo, z dokładnością do ilości *śpiących* wątków
    userlandu. W szczególności istnieją implementacje, które robią SIO
    jako nakładkę (!) na AIO albo odwrotnie. To właśnie sprawia, że AIO
    nie jest cudownym rozwiązaniem a ponieważ jest intruzywne i słabo
    komponowalne (nie da się go zastosować do *istniejącego* kodu), to
    powinno być stosowane... ostrożnie.

    > W drugim przypadku wątek może pracować w trakcie kopiowania danych.

    Czyli cały czas mówimy o użyciu współbieżności w celu lepszego
    wykorzystania zasobów sprzętowych. Powtórzę: to nie jest wyłączna
    cecha AIO. Współbieżność jest narzędziem bardziej ogólnym.

    --
    Maciej Sobczak * www.msobczak.com * www.inspirel.com

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: