Выполнять операции в памяти, минуя жесткий диск, не всегда быстрее

Выполнять операции в памяти, минуя жесткий диск, не всегда быстрее

Декабрь 11, 2015

intellcity

Среди обывателей и разработчиков бытует распространенное вывод, что сокращение количества запросов к твёрдому диску и исполнение предельного числа операций в памяти ведет к ускорению работы ПО. Распространение для того чтобы явления как Big Data, сделало одним из самые популярных способов экономии времени для программистов исполнение операций только в оперативной памяти. Но, новые изучения оспаривают общепринятое вывод о том, что каждые операции выполняются стремительнее в оперативной памяти, чем при наличии обращений к твёрдому диску на протяжении работы.
Смотрите кроме этого: Seven – самый узкий внешний жёсткий диск от Seagate

Американская компания Seagate создала жёсткий диск Seagate Seven, толщина которого образовывает всего 7 миллиметров. В соответствии с имеющейся информации, накопитель владеет количеством в 500 ГБ и разъёмом USB, а красивый корпус из нержавеющей стали защищает устройство от внешних действий. Продажи твёрдого диска начнутся в последних числах Января 2015 года. Купить Seagate Seven возможно будет за 100 долл.

Приятным бонусом для пользователя станет возможность выбрать любую надпись, которая будет нанесена на поверхность твёрдого диска в ходе его производства.

Общепринятое вывод оспаривает документ называющиеся «When In-Memory Computing is Slower than Heavy Disk Usage», опубликованный исследователями из Университета Калгари и Университета Английской Колумбии. Они протестировали предположение, в соответствии с которому, операции постоянно будут выполняться стремительнее в оперативной памяти, чем при записи данных на жесткий диск. Для этого был выбран несложный пример. Они сравнили другие методы создания строчка в 1 MB и ее записи на диск.

При применения оперативной памяти, размер составляемой строки строго фиксирован: сперва 1, по окончании 10, 1000, а после этого 1 000 000 байт, а по окончании результаты в виде строчков были записаны на диск. Запись совершалась для каждой строки раздельно: 1 000 000 строчков размером 1 байт, 100 000 строчков в 10 байт и без того потом.Код, на котором выполнялось тестирование, был написан на Java и Python для двух платформ: Windows и Linux.

Сравнивалось время работы лишь с диском, позже лишь с оперативной памятью и суммировалось со временем, затраченным на запись строчков на жесткий диск.Полученные систематические результаты продемонстрировали, что проводить все операции только в оперативной памяти, дабы минимизировать доступ к диску, а позже единожды записать данные, занимает намного больше времени, чем легко пара раз совершить запись на протяжении операции. К примеру, при применении Java на обеих тестируемых платформах, дабы организовать 1 000 000 строчков размером в 1 байт и позже разом их записать, тратится в 9 000 раза больше времени, чем если бы они были сходу последовательно записаны 1 000 000 раз на диск.Обращение к памяти на Python отрабатывало намного стремительнее чем на Java, но все равно, скорость записи всех строчков в один подход осуществлялась в много раз медленнее, чем если бы они сходу писались по одной по окончании формирования.

Как и следовало ожидать, при сокращении нужных «сцеплений» строчков в оперативной памяти время их одномоментной записи начало приближаться ко времени, нужному для последовательной записи на диск. Авторы работы поясняют, что применяемые для теста высокоуровневые языки делают довольно много работы «за кулисами» дабы разобраться с каскадными связями, созданием объектов и копированием строчков для записи и экономии пространства дополнительных байтов данных. «Приведенное выше описание справедливо для любой постоянной записи данных, каковые по окончании нее изменяться не будут» — говорят исследователи.

Иначе, способ записи строчков на диск был действеннее из-за принципов работы ОС в плане буферизации данных, т.е. в действительности эти пишутся на диск лишь в то время, когда это в действительности нужно.Чтобы повысить скорость работы в оперативной памяти нужно осознавать, как как раз ОС и язык программирования подходят к вопросу обработки операций. Авторы смогли ускорить работу Python-кода на Linux, что обращался лишь к оперативной памяти, через трансформацию порядка связей, например, методом добавления новой строки в конце обрабатываемой, а не по окончании.

На работу Java-кода в целом подобные новшества не повлияли, но, производительность при работе с поменянными данными в самой памяти существенно повысилась. Но это никак не помогло повысить производительность на ОС Windows. Помимо этого, данное улучшение прекратило трудиться, в случае если связанная строка объявлялась глобальной переменной.

Хоть это и весьма ограниченный пример, но его сущность содержится в том, что разработчики не должны по умолчанию вычислять, что работа в оперативной памяти стремительнее, чем при обращениях к твёрдому диску. Чтобы знать точно, будет ли операция выполняться стремительнее при применении лишь оперативной памяти, разработчики должны прекрасно знать правила лежащие в базе работы языка и ОС в аналогичных случаях. Как пишут сами авторы, их изучение оправдывает необходимость:

Пересмотра методов работы с памятью на системном уровне;
Более важной подготовки разработчиков в плане знания тонкостей работы ПО на системном уровне.

Это повысит возможности оперативной памяти и окажет помощь лучше применять ее потенциал.

Выполнять операции в памяти, минуя жесткий диск, не всегда быстрее

Случайная статья:

Проверка жесткого диска на ошибки

Похожие статьи:

Закрепленное видео

Свежие

Записи

Рубрики