|
|
|
|
|
|
|
Вернуться
| 1 Егоров Илья Валерьевич, 12 октября 2019 г. 12:41:16 | |
|
Так что, если немного подумать, можно заметить, что нормальный неблокирующий ввод-вывод без всяких костыльных потоков однозначно даст повышение производительности, если сравнивать реализации с одной и той же обработкой остатка / обходиться без оптимизации ветвлений, ибо, пока будет задействован диск для получения данных для буфера, процессор не будет простаивать.
|
|
|
| 2 Егоров Илья Валерьевич, 12 октября 2019 г. 12:28:08 | |
Согласен, пример неудачный, но с точки зрения формата ввода показательный.
Разбиение на блоки можно сформулировать по-другому: взятие символа из буфера, что в общем-то на практике и происходит. Остаток есть следствие оптимизации кол-ва ветвлений (вместо проверки конца буфера в функции получения символа проверяем в функции считывания порции данных, в случае 561 это башня). Так спокойно расширяется до ввода любого формата.
|
|
|
| 3 Меньшиков Фёдор Владимирович, 12 октября 2019 г. 12:23:26 | |
|
561 крайне неудачный пример, там основные расходы не на ввод, а на сортировку, которая невозможна без полного ввода.
|
|
|
| 4 Егоров Илья Валерьевич, 12 октября 2019 г. 12:11:05 | |
|
Да и даже если заменить копирование буфера на 2 буфера, которые в volatile булеане переключать, остается требование махинаций с недочитанной башней. В случае обычного fread без выкрутасов самый оптимальный вариант (проверено тут на всем известно каких задачах под плюсами) — прыгнуть через fseek на K = остаток байт назад и просто прочесть остаток вместе с продолжением. В случае неблокирующего / костыль через потоки такое не прокатит.
|
|
|
| 5 Егоров Илья Валерьевич, 12 октября 2019 г. 12:02:44 | |
Почему же ввод обязательно требуется заканчивать?
Можно разбить чтение ввода на блоки по N байт (скажем, типичные 4096). Получили N байт, сделали копию и разбудили решающий задачу поток, запросили следующий блок. Пока первый поток ждет окончания ввода, второй обрабатывает тот кусок данных, который дали. Организовать синхронизацию можно через cond.
Возьмем как пример 561. Башни.
Каждая башня разделяется символом перевода строки => в полученном блоке данных достаточно вычленять башни путем проверки на перевод строки, каждую определенной функцией обрабатывать. Когда достигли конца блока, оставшуюся часть где-нибудь, как вариант, сохраняем и конкатенируем со следующим блоком.
В случае неблокирующего ввода-вывода это вполне может что-то дать при удачном размере буфера и определенных характеристиках диска, но вот костыль через потоки имеет издержки на создание нового потока, синхронизацию, само переключение потоков и прочие прелести. Да и копирование буфера — операция относительно не самая быстрая, поэтому сей путь — рискованный и в проде желательно не применять. Как правило, стандартный однопоточно-синхронный fread + fseek в перспективе все равно лучше.
|
|
|
| 6 Меньшиков Фёдор Владимирович, 12 октября 2019 г. 10:47:46 | |
|
Интересно, какую задачу Вы можете начать решать до того, как Вы закончили её ввод.
|
|
|
| 7 Егоров Илья Валерьевич, 10 октября 2019 г. 18:43:09 | |
|
Предполагаю, даже при этом можно получить профит, если использовать многопоточность не для распараллелирования (которое не выйдет в силу наличия лишь 1 ядра; исключение — гипертреды), а для обхода блокировок, если неблокирирующий ввод-вывод отсутствует в стандартной либе или же требует существенного изменения кода. Однако, в этом случае надо б либо хорошо знать поведение планировщика потоков, либо использовать какие-либо хитрости.
|
|
|
| 8 Меньшиков Фёдор Владимирович, 10 октября 2019 г. 18:30:51 | |
|
Вроде как можно, только виртуальная машина, на которой запуск происходит, имеет только одно ядро.
|
|
|
| 9 Терентьев Андрей Николаевич, 09 октября 2019 г. 9:41:33 | |
|
Ребят, можно ли использовать многопоточной при решении некоторых задач?
|
|
|
Чтобы оставить сообщение необходимо зарегистрироваться и авторизоваться!
| | | |
