Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[52.14.45.36] |
|
Страницы: (2) 1 [2] все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
to SUnteXx & Flex Ferrum
механизм страничной адресации работает не быстро,совсем не быстро и если не выделять память самому то маздай ее раскидает как придется в Physical Memory= сие значит следующее=твой файлец будет сильно или не очень=но фрагментирован в Physicsal Memory далее значит что чипсет не будет переходить в burst mode при работе с ним ЭТО ЗНАЧИТ ЧТО ТЫ ПОЛУЧИШЬ НА МЕСТАХ СТЫКА СКОРОСТЬ 100-200MB/Sec вместо 800 при пакетной передаче я думаю мне не надо объяснять что мы конкретно упираемся в производительность памяти даже при скорости 1GB/Sec |
Сообщ.
#17
,
|
|
|
Правильно ты сказал. Механизм страничной адресации работает не быстро. Но!!! Процессор оперирует страницами по 4 кб. Ему пофигу - расположены они рядом или на расстояении в 128 мб. Шина адреса имеет ширину в 32 бита. Отсюда вывод - с точки зрения процессора, находящегося в режиме страничной адресации линейной памяти абсолютно все равно - на сколько фрагментирована выделенная тобою область памяти. Адресация идет в любом случае через таблицу страниц. И насколько близко или далеко они расположены - не имеет значения. Скорость будет одна и та-же. ИМХО, конечно...
|
Сообщ.
#18
,
|
|
|
ты знаешь что такое burst mode ?
|
Сообщ.
#19
,
|
|
|
cудя по всему даже если знаешь то не представляешь насколько она важна
1.процессор и его внешняя шина работают в асинхронном режиме 2.ширина шины проца может и не совпадать с шириной шины памяти 3.отсюда значит и чипсет и/или имеет буфер запросов (обычно это L3/L2) и/или работает в асинхронном режиме RAM<=>CPU (ex KT7A) 4.что есть burst mode=пакетный режим передачи при котором адресная шина инкрементируется не ожидая запроса от CPU и сразу читается новая порция данных 5.при отсутствии burst mode но при последовательном чтении чипсет один такт страдает X потому что ждет адреса 6.при случайном хоть и страничном доступе получается еще хуже= тайминги SDRAM 3-1-1-1 сие значит что на активацию столбца у тебя уйдет не менее 3 тактов=значит в среднем 4-5 7.идем далее=размер строки кэша обычно >32байт =типично 128= и как показывает приктика гнусная железяка ждет ПОЛНОГО заполнения строки L1 прежде чем сможет к ней обратиться 8.L1 крайне мелкий и ты получишь еще FUN вытеснения данных из кэша как показывает практика такие вот мелочи поднимают скорость демок раза в 2-3 P.S:надеюсь я достаточно ясно выразился? |
Сообщ.
#20
,
|
|
|
2x:
Картинка 10000х15000х32 = 572.2Mb! Легче самому свопить, а то у меня ограничение на своп стоит (около 256Мб)! И что ты сделаешь в таком случае? А если битмапа на винте не поместится, как быть? ФотожоП жрет дох места на винте, причем свопит сам, а его кодили не л\%хи, так почему не сделать так же? Будет медленновато, но зато будет, чем них ни памяти не будет, ни винта, ни свопа, ни нормально работающей проги...!) 2mtdr: А сколько там цветов в битмапе? Может если строчки как-нить совмещать (к примеру, если 15, 17, 281 и 293 строчки совпадают, то савкать в своп в своем формате, что в начало новой строки савкается похожесть на одну из строк... или что-нить вроде того, или с кусками строк, ...?) ЗЫ Лучше всего, имхо, савкать на винт самому, а потом просто считывать нужный кусок битмапы, иначе заебе\%\%ся (с мягким знаком)! |
Сообщ.
#21
,
|
|
|
собственно что свопить надо самому я считал очевидным
|
Сообщ.
#22
,
|
|
|
Мне пришлось как-то печатать в файл битмапы и побольше. Очень выручает печать по частям. БМП так устроен, что если его печатать хитро по частям в обратном порядке, то получится правильное изображение. Так что выделяешь стандартный 32м битмап, "сканишь" им все изображение и дописываешь в файл.
|
Сообщ.
#23
,
|
|
|
x:
Все это интересно, если ты пишешь демку. В демке картинки по 500Мб врядли используются. И потом - эти 500 Мб ты не уложишь в память без фрагментации - система возьмет свое. Приложение не одно, все они свопятся и т. д. и т. п. Отсюда вывод - либо организовывать "системный" своп через FileMapping, либо свой собственный. Я в свое время пошел по второму пути. Это в данном случае более грамотно. У больших картинок есть своя специфика хранения. Практически все они хранятся тайлами определенного размера (обычно выбираются степени двойки). Пример таких форматов - TIFF, JFIF. В последнем случае каждый тайл жпегуется. Формат BMP для таких картинок практически не применятся (из за своей специфики хранения). Так вот, в этом случае очень удобно организовывать кольцевые буфферы, в которых изображение подкачивается так-же, как и в описанном x'ом режиме burts mode - то есть с предсказанием. |
Сообщ.
#24
,
|
|
|
ну уж чего я непонимаю, так если у тебя файл на выходе ну и пиши ты его целиком на хард. А дальше с харда подгружай только тот кусочек который тебе надо. Если еще в правильном формате будешь писать, а не bmp, то вообще все должно неплохо работать. А реализация в принципе не очень сложна если уж так подходить...
|
Сообщ.
#25
,
|
|
|
я собственно не настаиваю
просто изложил специфику данного вопроса как я сам ее знаю все факты изложены=пусть дальше сам решает что и как делать вот наверное и все |