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

DMA это разве не то?
Ну если и не то, то во всяком случае близко...

DMA не умеет memory <-> memory, если я правильно помню. И в любом случае, копирует оно через шину.

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

А зачем?

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

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

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

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

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

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

Кэширование есть ведь

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

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

для угрунов есть ССД, который выдаст эти 2GB за несколько секунд

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

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

Местами приъходится учитывать, что memmove/memcpy O(n)

Специальные контроллеры тоже O(n) %)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

быстрое memcpy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну вот на ARM есть DMA с режимом memory->memory. Как-то там решили описаные тобой проблемы?

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

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

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

А DMA есть не для всех.

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

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

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

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

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

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

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

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

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

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

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

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

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

fork().

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

O(n) ~ k*n

у контроллера и процессора k разный

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

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

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

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

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

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

почему разный?

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

fork().

LOL :)

ps. учи матчасть

а зачем нужен андроид, когда есть макос?

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

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

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

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