Pull to refresh

Comments 16

UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
О, соглашусь, не так давно заметил, что при загрузке со стима, проц почти в 60% грузится, при том, ни скорость интернета(около Гбита/с) ни скорость ссд (nvme 1600 мб/с) еще не заняты полностью, т.е ограничение видимо в процессор(ну или в ссд, но не знаю), на обычный ссд(sata) скорость заметно падает.
UFO just landed and posted this here
AMD THREADRIPPER 3970X вам в помощь :)
UFO just landed and posted this here
в m.2 скорость тупо упирается в центральный процессор. кто бы мог раньше подумать что ЦП станут «узким горлышком», клеймо которого много лет носили hdd
Ну, потенциально можно подрядить DDR и увеличить скорость ещё в 3 раза.

Потому что обычные файловые операции в винде, почему-то до сих пор однопоточны. Даже рамдрайв не удаётся раскочегарить быстрее 12 ГБ/с, пока не прикрутишь к нему многопоточный рамкеш (тогда на 4-х каналах памяти может бегать уже под 45 ГБ/с — мои личные тесты). Ютуберские тесты по 4 топовых nvme в рейд 0 с их 25 ГБ/с — это только внутренние аппаратные возможности, а не скорость по всему тракту обычной передачи файлов, которую я пока не видел больше 3 ГБ/с в "домашних" ПК.

А как они могут быть многопоточны без поддержки со стороны приложений? Условно, если приложение читает/пишет файл последовательно небольшими блоками с одного устройства — как это можно распараллелить?

В этом случае, проблема "курицы и яйца" (кто первый?) решается банально: первой возможности должна предложить ОС для любых предложений, а не каждое приложение получать такие функции и "сидеть ждать у моря погоды", пока ОС увидит достаточно таких приложений и "соизволит" реализовать поддержку у себя.
P.S. Была бы альтернативная ОС — всё это и не только, давно бы уже было реализовано в ходе конкурентной борьбы.

Постойте — в винде есть и многопоточные, и асинхронные функции для ввода-вывода, которые ничуть не хуже чем их аналоги в Linux или других системах.


Вполне можно написать приложение которое будет читать параллельно из разных частей устройства (из разных потоков или асинхронно в одном) — и если устройство само по себе это позволяет то всё отлично будет работать.


Сама система предлагает как раз очень богатый выбор возможностей (как на уровне приложений так и на уровне драйверов) — только большинство разработчиков используют очень малую его часть.

Тогда очень странно, что этими возможностями почти не пользуются, ведь популярные дисковые тесты показывают такую заметную разницу в производительности режимов одной очереди и мульти. Даже в тех же играх при наличии стриминга текстур (и не только) и загрузке сохранений продолжительностью более пол минуты — этот вопрос более чем актуален.

Раз всё ещё разработка, тогда почему под 18-ый контроллер, а не под 21-ый?

Kingston тоже недавно хвастались на Хабре, что готовят к релизу NVMe с поддержкой PCI-E 4.0, который будет обладать аналогичными скоростями. Вот только умалчивают, на каком контроллере будет их решение. А так, помимо Corsair, сейчас каждый готовит подобные новинки. Интересно, у кого в итоге будет лучшая реализация?
Sign up to leave a comment.