Panel użytkownika
Nazwa użytkownika:
Hasło:
Nie masz jeszcze konta?

Wolne std::async

Ostatnio zmodyfikowano 2017-11-04 15:03
Autor Wiadomość
Gibas11
Temat założony przez niniejszego użytkownika
Wolne std::async
» 2017-11-03 12:22:30
Jak w tytule, stworzenie jakichś śmiesznych 150 instancji
std::future
 zajmuje mi na i7-7700HQ ok. 5 sekund, dokładnie tego nie mierzyłem ale to i tak zupełnie inny rząd wielkości niż wymagany.
C/C++
std::vector < std::future < immutable_image >> imgs;
for( auto i = 0u; i < 150; ++i ) {
    imgs.emplace_back( image.set_region( std::launch::async, { 300, 250 }, { 800, 2000 }, sf::Color { 0, 255, 255 } ) );
}
std::cout << "Done!" << std::endl;
Metody
set_region
:
C/C++
immutable_image set_region( const sf::Vector2u topleft, const sf::Vector2u bottomright, const sf::Color c ) const {
    auto transient = m_data.transient();
   
    for( auto x = topleft.x; x < bottomright.x; ++x ) {
        for( auto y = topleft.y; y < bottomright.y; ++y ) {
            transient.set( x + y * size().x, c );
        }
    }
   
    return immutable_image {
        std::move( transient.persistent() ),
        size()
    };
}
std::future < immutable_image > set_region( const std::launch policy, const sf::Vector2u topleft, const sf::Vector2u bottomright, const sf::Color color ) const {
    return std::async(
    policy,
    [ this ]( const auto tl, const auto br, const auto c ) {
        return this->set_region( tl, br, c );
    },
    topleft,
    bottomright,
    color
    );
}
Jak widać ta dolna funkcja (czyli ta którą wywołuję w pętli) to tylko wrapper na
std::async
. Dlaczego zajmuje to tak długo? Popełniam jakiś banalny błąd (krótko zajmuję się niezmiennymi klasami i asynchronicznością), czy mam wstawić cały kod? Nie ma go za dużo, ale niestety mam w nim dużo zależności (części się pozbędę po rozwiązaniu tego problemu): SFML, immer i C++17.
P-166397
mokrowski
» 2017-11-03 13:11:10
Jak wszystko "pchasz przez kopie", to nie ma się czemu dziwić.
Zmień na referencje (najlepiej stałe) jeśli nie tracą aktualności w czasie wykonania async lub rozważ packaged_task.
P-166399
Gibas11
Temat założony przez niniejszego użytkownika
» 2017-11-03 13:35:41
Tyle że wszystkie te struktury ważą tyle samo lub mniej niż wskaźniki. Zresztą właśnie teraz to sprawdziłem i nie widzę żadnej zauważalnej poprawy. Swoją drogą dodam, że jeśli wywalę zawartość tej lambdy i wstawię samo
return{}
 to czas wykonania maleje w zasadzie do zera, a z tego co się orientuję toto ile wykonuje się 
std::async
 nie powinno być zależne od tego jaką funkcję nim odpalam.
P-166401
pekfos
» 2017-11-03 13:54:14
Jaki masz cel w tworzeniu 150 wątków..?
P-166402
Gibas11
Temat założony przez niniejszego użytkownika
» 2017-11-03 14:06:18
Na mojej platformie
std::async
 wstawia zadania do thread pool-a a nie tworzy osobne wątki. Zresztą nawet gdyby tak było w części zadań będzie dużo czekania na operacje IO, więc procesor i tak skakałby tylko po tych które rzeczywiście mają coś do roboty.
P-166404
j23
» 2017-11-03 16:23:25
Może wątki odwołują się do danych, do których dostęp jest synchronizowany, przez co blokują się nawzajem i spowalniają (m_data.transient(), transient.set() i transient.persistent()).
P-166420
DejaVu
» 2017-11-03 16:29:26
Proponowałbym wywołać na vectorze .reserve, aby każde dodanie elementu nie powodowało realokacji.
P-166421
Gibas11
Temat założony przez niniejszego użytkownika
» 2017-11-03 17:02:37
@@j23: Tym się jeszcze nie zajmowałem i nie robi mi to na razie różnicy, to spowolniłoby tylko wątki a u mnie problem polega na wolnym tworzeniu
std::future < immutable_image >
.
@DejaVu:
std_future < T >
 waży 16 bajtów, za mało żeby zrobić różnicę. Zwłaszcza że
std::vector
 chyba alokuje pamięć wykładniczo, więc tym bardziej by to nie przeszkadzało przy 150 obiektach.
P-166423
« 1 » 2
  Strona 1 z 2 Następna strona