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. 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 : 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. |
|
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. |
|
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. |
|
pekfos |
» 2017-11-03 13:54:14 Jaki masz cel w tworzeniu 150 wątków..? |
|
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. |
|
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()). |
|
DejaVu |
» 2017-11-03 16:29:26 Proponowałbym wywołać na vectorze .reserve, aby każde dodanie elementu nie powodowało realokacji. |
|
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. |
|
« 1 » 2 |