LINUX.ORG.RU
ФорумTalks

Аппаратное копирование памяти


0

2

За последние годы вышло столько новых версий памяти (DDR, DDR2, DDR3), но насколько я знаю, ни в одной из этих версий не внедряют копирователь памяти прямо в контроллер памяти. Хотя мне видится, что копировать оно будет куда быстрее, чем процессор.

★★★★★

Ответ на: комментарий от cvs-255

Т.е. тебя интересует совсем тупое копирование без какой либо логики?
Но зачем? Единственное, что мне приходит в голову это инициализация памяти каким-либо значением (0 например).
Других применений навскидку придумать не могу.

Stahl ★★☆
()
Ответ на: комментарий от Stahl

быстрое перекидывание буфера из принимающего буфера в какой-нибудь другой. Местами приъходится учитывать, что memmove/memcpy O(n)

Dark_SavanT ★★★★★
()

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

Зачем там копирование?

n_play
()
Ответ на: комментарий от Stahl

игрулька загрузила с жесткого в раму уровень, размером 2Gb, и делала это минуту. Потом игрок пробежал десять метров и получил пулю в жопу. Обиженный, надовил F9 qickload и опять две минуты печально наблюдал, как ползет прогрессбар загрузки уровня. Пробежал, получил в жопу пулю, нажал F9...

stevejobs ★★★★☆
()
Ответ на: комментарий от cvs-255

И в любом случае, копирует оно через шину.

притом, что шина памяти итак самая быстрая. Быстрее неё только потроха процессора. Разве нет?

n_play
()
Ответ на: комментарий от Dark_SavanT

быстрое перекидывание буфера из принимающего буфера в какой-нибудь другой. Местами приъходится учитывать, что memmove/memcpy O(n)

мне кажется или тут попахивает PIO? Тогда неудивительно.

n_play
()
Ответ на: комментарий от stevejobs

И если игрулька такая сложная, что подобный вариант обычен, а памяти дофига, то что мешает продублировать память сейчас?

Не-не-не... Ты давай более низкоуровневый пример, который покажет что тупое копирование на уровне контроллера памяти будет использоваться часто (часто это не раз в несколько минут, а хотя бы раз в 100000 чаще) и позволит сэкономить много времени.

Stahl ★★☆
()
Ответ на: комментарий от cvs-255

DMA не умеет memory <-> memory, если я правильно помню.

хм, а что же тогда DMA по твоему?

процессор заказал забрать содержимое буффер с устройста по адресу Х и положить его по адресу У. Котнроллер DMA как закончит, так подаст сигнал процессору. Всё.

n_play
()
Ответ на: комментарий от Stahl

именно, в его примере раскрыта проблема изьянов игростроения

n_play
()
Ответ на: комментарий от stevejobs

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

Просто оторвать игроделам руки за повторную загрузку уже загруженного ресурса.

Sadler ★★★
()
Ответ на: комментарий от stevejobs

игрулька загрузила с жесткого в раму уровень, размером 2Gb, и делала это минуту.

И, конечно же, аппаратный копировальщик памяти ускорит работу жёсткого диска.

Надовил F9 qickload и опять две минуты печально наблюдал, как ползет прогрессбар загрузки уровня.

А это уже говнокод.

true_admin ★★★★★
()
Ответ на: комментарий от Sadler

игроделы не умеют оверлеи итп, чтобы загружать только изменения, для этого нужно слишком много мозга

сам смотри - более половины всех игрушек заново вытягивают все на свете на каждый чих

если статистика такая, значит им нужно помочь и ускорить их странные телодвижения на аппаратном уровне, чтобы они хотя бы не тормозили

можно даже сделать какие-нибудь специальные вызовы в сишной библиотеке, чтобы их названия КАК БЫ НАМЯКИВАЛИ, что вот этой функцией можно быстро ревертнуть назад адский объем оперативки

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от n_play

Сдается мне, что контроллер памяти DDRn может общаться с планками памяти побыстрее, чем процессор через контроллер памяти

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от n_play

все равно надо эти 2Gb развернуть в оперативку. Одаренные личности будут хранить эти 2Gb уровня в файлах XML, а после распарсивания при переходе в раму они превратятся в указатели на конкретную память. Парсить XML - это не мешки таскать, это тяжелее, хоть SSD хоть оптоволокно - как минуту загрузки было, так и останется

проверим на опыте: куча старинных (>5 лет) игор ничуть не ускорило загрузку уровней от того, что сменилось несколько поколений железа. Почему-то сразу вспоминается Gothic 3 :) Ну или вот The Force Unleashed 1 портированный на PC, там тормозит вообще все вне зависимости от железа.

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 2)
Ответ на: комментарий от n_play

хм, а что же тогда DMA по твоему?

IO -> memory, memory -> IO, и, емнип, IO -> IO

Хотя уточнил, на некоторых не-x86 возможно и память->память

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от n_play

хм, а что же тогда DMA по твоему?

«процессор заказал забрать содержимое» «по адресу» «Х и положить его по адресу У.»
Вот, что он хотел.

atrus ★★★★★
()
Последнее исправление: atrus (всего исправлений: 1)

с точки зрения приклада - ни один контроллер чипа памяти ни улучшит виртуальный COW.

если есть большой блоб который надо часто копировать - юзай mmap вместо memcpy.

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

если есть большой блоб который надо часто копировать - юзай mmap вместо memcpy.

а если копировать надо? Как, например, в большинстве программ, вызывающих memcpy.

А оптимизация memcpy, судя по истории с glibc, довольно актуальная тема

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 2)

а как ты себе представляешь реализацию этого дела? Процессор будет каждый раз ждать, пока контроллер памяти раздуплится, копируя поблочно из одного чипа в другой?

Harald ★★★★★
()
Ответ на: комментарий от Harald

Нет, параллельно будет идти копирование и работа остального. Как контроллер закончит, выдаст сигнал

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от stevejobs

я вот как-то играл в The Great Escape, игрушка ничем особо не привлекательная кроме того, что уровни грузились почти моментально, я немного поковырял, выяснилось что ресурсы для уровней сгруппированы по одному файлику для уровня плюс один файлик видимо для общих повторяющихся ресурсов

Harald ★★★★★
()
Ответ на: комментарий от cvs-255

ну и как ты это реализуешь, параллельную работу? :) Микросхемы памяти внезапно научатся читать или записывать два отдельных блока одновременно?

Harald ★★★★★
()

«Генератор бредовых идей, клоун серого вторника...»

Pakostnik ★★★
()
Ответ на: комментарий от cvs-255

memcpy заоптимизирован вдоль и поперёк; в большинстве случаев копируются не очень большие блоки (еденицы К), которые быстрее скопировать чем запрограммить некий контроллер (ДМА, MMU) на перенос данных. А если учесть что ядер много, еще и аппаратно разделять его использование и как-то учесть перенос данных в кэшах CPU и блокировать области при переносе и информировать/синхронизировать прочее железо(тот-же ДМА) о невалидности. Масса гимора при неясных перспективах. А все оттого что кто-то криво проектирует софт и гоняет блобы по памяти.

MKuznetsov ★★★★★
()
Ответ на: комментарий от Harald

Нет. Но за то время, пока копирование процессором скопирует 1 байт, контроллер скопирует больше. Потому что-то + копирование контроллером будет быстрее, чем что-то + копирование процессором.

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от cvs-255

пока копирование процессором скопирует 1 байт, контроллер скопирует больше.

контроллер ещё проинициализировать надо, а потом прерывание от него обработать, 1 байт точно быстрее процессором скопируется

а на больших объёмах копируемых данных разница будет незначительной

Harald ★★★★★
()
Последнее исправление: Harald (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Есть ненулевая вероятность что O(n) контроллера будет быстрее чем O(n) на процессоре.

Но подкол засчитан, я выразился не совсем корректно.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от cvs-255

Как-то там решили описаные тобой проблемы?

может быть..НО ЗАЧЕМ ? прямое физическое копирование память-память - прерогатива ядра ОС, но в структурах ядра не должно быть больших часто копируемых блобов,а мелочи типа копирования в/из кольцевых буферов - быстрее копировать не задействуя доп.железо.

На уровне юзера ваше «копирование памяти внутри плашек памяти минуя всё» вообще некуда присунуть :) При memcpy(src,dst) реальное содержимое src dst может быть размазано по всем плашкам и под вашу мега-функцию придётся делать системный вызов, практически аналогичный mmap, с непредсказуемым временем исполнения и который ещё хрен соптимизируеш.

MKuznetsov ★★★★★
()
Ответ на: комментарий от Harald

а на больших объёмах копируемых данных разница будет незначительной

как раз на больших объемах, где время инициализации относительно мало, это будет окупаться.

А с учетом того, что контроллер памяти нынче в процессоре, можно отдельные команды и регистры запилить для инициализации

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от cvs-255

можно отдельные команды и регистры запилить для инициализации

и что, они от этого за 0 времени исполняться будут? :)

Harald ★★★★★
()
Ответ на: комментарий от Dark_SavanT

Есть ненулевая вероятность что O(n) контроллера будет быстрее чем O(n) на процессоре.

каким образом?

Harald ★★★★★
()
Ответ на: комментарий от Harald

Быстрее будут. Соответственно, плюсы начнут чувствоваться на меньших объемах копируемой памяти

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от Dark_SavanT

Есть ненулевая вероятность что O(n) контроллера будет быстрее чем O(n) на процессоре.

Ну, как по мне, так она ровно нулевая - вряд ли есть какие-то секретные шины, более быстрые, чем процессорная шина. Профит может быть в 1) одновременной работе процессора и DMA 2) обходе кэшей.

tailgunner ★★★★★
()
Ответ на: комментарий от cvs-255

А с учетом того, что контроллер памяти нынче в процессоре, можно отдельные команды и регистры запилить для инициализации

вы не поверите. MOVS и его товарищи.

но не минуя CPU с его кешами,MMU и шины. Как и должно быть

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

компиляторы movs вроде как не используют совсем, оно только во вручную написанном ассемблерном коде встречается

Harald ★★★★★
()
Ответ на: комментарий от MKuznetsov

но не минуя CPU с его кешами,MMU и шины. Как и должно быть

Т.е. есть куча накладных расходов.

Память все равно нынче используется страницами по 4К. Так что фрагментация не такая страшная, как может показаться. Т.е. а потому преобразование виртуального адреса к физическому надо провести не более 1 раза на страницу, после чего можно смело копировать.

Вопрос кешей решаем.

cvs-255 ★★★★★
() автор топика
Последнее исправление: cvs-255 (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.