-
X-Received: by 10.140.87.70 with SMTP id q64mr215270qgd.10.1428996089565; Tue, 14 Apr
2015 00:21:29 -0700 (PDT)
X-Received: by 10.140.87.70 with SMTP id q64mr215270qgd.10.1428996089565; Tue, 14 Apr
2015 00:21:29 -0700 (PDT)
Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!news.glorb.com!
m20no3337962iga.0!news-out.google.com!k20ni156qgd.0!nntp.google.com!z60no136211
2qgd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: pl.comp.programming
Date: Tue, 14 Apr 2015 00:21:29 -0700 (PDT)
In-Reply-To: <a...@g...com>
Complaints-To: g...@g...com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=178.36.94.29;
posting-account=xjvq9QoAAAATMPC2X3btlHd_LkaJo_rj
NNTP-Posting-Host: 178.36.94.29
References: <1...@n...fucking.idea>
<5...@g...com>
<a...@g...com>
<0...@g...com>
<f...@g...com>
<5...@g...com>
<6...@g...com>
<a...@g...com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <5...@g...com>
Subject: Re: Atomowość operacji vs wieloprocesorowość
From: "M.M." <m...@g...com>
Injection-Date: Tue, 14 Apr 2015 07:21:29 +0000
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
Xref: news-archive.icm.edu.pl pl.comp.programming:207810
[ ukryj nagłówki ]On Monday, April 13, 2015 at 8:27:29 PM UTC+2, Wojciech Muła wrote:
> On Thursday, April 9, 2015 at 6:45:16 PM UTC+2, M.M. wrote:
> > > Ale to jest już inny przypadek.
> > Ściśle inny, generalnie ten sam - wątek jakoś zmodyfikował zawartość
> > zmiennej, a programista nie jest pewny:
> > 1) czy zmodyfikowana zmienna jest widoczna dla innych wątków,
>
> No to do tego jest bariera pamięci.
>
> > 2) czy inny wątek może zobaczyć zmienną zmodyfikowana 'w połowie'.
>
> A od tego mamy gwarancje spójności od producenta. :)
>
> > > Dodawanie, odejmowanie i operacje
> > > bitowe też mogą być atomowe na x86, ale dla pozostałych rzeczywiście
> > > trzeba mieć jakąś formę sekcji krytycznej.
> > Ok, ale w praktyce używamy języków wysokiego poziomu. Piszę np.
> > a = b;
> > a kompilator wywnioskował że b będzie równe zero i zrobi:
> > a ^= a;
> > Na jakimś procesorze xor może nie być już atomowe.
>
> Oczywiście, o to trzeba zadbać. C++11 ma std::atomic, które daje ładne
> API do atomiców, barier itp., natomiast kompilator ma wiedzę, którą
> jest w stanie wykorzystać. Nie wiem, jak to wygląda w innych językach
> imperatywnych (Ada, C#).
>
> > > Sekcje krytyczne, w sensie mutexy, czy semafory, jako obiekty systemowe
> > > są wolne, a nawet bardzo wolne. Dlatego tam gdzie liczy się wydajność
> > > pojawiają się algorytmy lockfree, czyli nie ma jako takiej blokady na
> > > sekwencję instrukcji, ale np. próbuje się do skutku wykonać jakąś
> > > operację, powiedzmy dopisania do kolejki. I tu już można to robić
> > > wydajnie właśnie operacjami atomowymi (głównie compare & exchange)
> > > no i trzeba pamiętać o barierach pamięci (memory fence).
> >
> > Myślałem że memory fence też jest wolne, ale jeszcze nigdy na oczy
> > nie widziałem pomiarów czasu. Może faktycznie to się opłaca...
>
> Ostatnio kolega wykonał proste testy: prefiks lock na instrukcji
> increment (tj. pełna blokada) vs increment, później store fence --
> z barierą było 2-3 razy szybciej. Podejrzewam, że to trochę
> zależy od całego komputera (kontroler pamięci, liczba procesorów),
> ale sądzę, że czynnik 2 jest dobrym przybliżeniem.
Czyli przyspieszenie niezbyt duże. Blokady są koszmarnie wolne, dwukrotnie
przyspieszenie to za mało dla wielu praktycznych zastosowań. Z kolei
jeśli dzielimy zadania na bardzo duże porcje, to nawet 10cio krotne
przyspieszenie mechanizmu synchronizacji nie przyniesie mierzalnego
przyspieszenia całego programu.
Ciekawym rozwiązaniem, jak pisałeś, wydają się klasy obudowujące inta w
bibliotece qt czy std. Jest też klasa atomic pointer. Jeszcze nigdy nie używałem tych
klas, trudno mi się wypowiedzieć o ich przydatności i
wydajności. Najbardziej ciekawe jest jednak, jak się mają możliwości tych
klas do spotykanych problemów w praktyce. Może warto im się przyjrzeć.
Pozdrawiam
Następne wpisy z tego wątku
- 15.04.15 18:38 Wojciech Muła
- 16.04.15 06:43 M.M.
Najnowsze wątki z tej grupy
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
- Ada 2022 Language Reference Manual to be Published by Springer
- Press Release - AEiC 2023, Ada-Europe Reliable Softw. Technol.
- Ada-Europe - AEiC 2023 early registration deadline approaching
- Ada-Europe Int.Conf. Reliable Software Technologies, AEiC 2023
- Ile cykli zajmuje mnożenie liczb 64-bitowych?
Najnowsze wątki
- 2024-06-27 SAMOCHODY ELEKTRYCZNE: EKOLOGICZNA HIPOKRYZJA CZY EKONOMICZNA GŁUPOTA? | GOSPODARCZE ZERO #21
- 2024-06-27 Głośnik piezoelektryczny
- 2024-06-23 Mala autonomiczna kamera monitoringu
- 2024-06-26 czas na emeryturę i EB
- 2024-06-26 Wyjścia video kart graficznych (NVIDIA)
- 2024-06-27 Warszawa => Key Account Manager <=
- 2024-06-27 Bażanowice => Expert Migration Architect (Azure) <=
- 2024-06-27 Ulm => IT Netzwerktechniker (m/w/d) <=
- 2024-06-27 Warszawa => Kierownik Działu Spedycji Międzynarodowej <=
- 2024-06-27 Warszawa => Head of International Freight Forwarding Department <=
- 2024-06-26 Kraków => International freight forwarder <=
- 2024-06-26 Częstochowa => Marketing Specialist (E-Commerce) <=
- 2024-06-26 Warszawa => Fullstack Java Developer <=
- 2024-06-26 Warszawa => React Native Developer <=
- 2024-06-26 Rzeszów => Frontend Developer (React) <=