Ксакеп, жесткий диск тут не при делах, нас это не должно заботить. Ну подождёт один поток пару наносекунд, С парой наносекунд, конечно, загнул. Если головка диска раскручена, то, считай, что доступ к файлу будет порядка 8 мс.
соглашусь с Ксакепом, жёсткий диск будет узким местом. другое дело О3У, или кэш проца Изм. Koenig (14.12 / 11:00) (1)
Freddy, я нагуглил, вернет доступное количество процессоров для JVM, то есть с учетом Hyper-Threading. Еще в документации сказано, что значение во времени исполнения может изменятся.
Ксакеп, теперь понятно, возможно даже повышенный износ диска, надо тестировать. Виктор, запилишь тест с замером времени? стековое выполнение и паралельное
Freddy, самому интересно. Ставлю на то, что будет 2.
Ну так я вижу что происходит следующее: поток забирает себе список, читает кусочек из диска, освобождает список, головка диска переходит к следующему файлу, блокировка, чтение кусочка, разблокировка, перепрыгивание назад, блокировка чтение, разблокировка. То есть куча времени тратится на такое вот перепрыгивание, а это долгая операция.
"Runtime.getRuntime().availableProcessors()" Любопытства ради: если у меня двухъядерный процессор, но с поддержкой hyper-threading, метод скажет, что у меня два процессора или четыре?
Ксакеп, много - это один вопрос? А что если у человека 2 жестких или вообще он часть озу подключил как раздел для быстрых операций?
Ксакеп, жесткий диск тут не при делах, нас это не должно заботить. Ну подождёт один поток пару наносекунд, пока в другом операция чтения будет и ничего страшного. 20 потоков не значит, что все параллельно в один момент исполняются, так что жестким диском можно пренебречь.
После чтения статьи осталось больше вопросов чем ответов. Например, почему 20 потоков оказались быстрее, нежели 1 поток? У нас ведь один разделяемый ресурс — жёсткий диск.  К записиJavaКатегории
|
Мы в соцсетях
|
Эль Презеденте
