Может уже есть какие-нибудь библиотеки?
Boost так не может?
Уверен, что писать драйвер мне не надо (не окупится время), а вот чтобы память пользовать - надо.
А если в настройках операционки убрать фвиртуальную память до минимума?
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Для новичков > malloc/calloc только в физической памяти |
| Автор: nikkadim 23.7.2012, 23:11 |
| Добрый день, Подскажите, реально ли выделить память только лишь в физической области, т.е. не использовать виртуальную? Необходимо использовать только быструю память (работаю с GigE) для кеширования больших данных (4-5GB) перед сбросом их на диск. Спасибо. |
| Автор: boostcoder 23.7.2012, 23:16 |
| для вянды - писать свой драйвер. для линукс - модуль ядра. Добавлено через 14 секунд да и не надо оно тебе, поверь. |
| Автор: nikkadim 23.7.2012, 23:17 |
| Да, винда x64. Может уже есть какие-нибудь библиотеки? Boost так не может? Уверен, что писать драйвер мне не надо (не окупится время), а вот чтобы память пользовать - надо. А если в настройках операционки убрать фвиртуальную память до минимума? |
| Автор: bsa 23.7.2012, 23:23 |
| nikkadim, тебе зачем? почему тебя виртуальная не устраивает? В современных ОС работать с физической памятью могут только ядро и драйверы. |
| Автор: boostcoder 23.7.2012, 23:30 | ||
уверен, ты не с той стороны подошел к решению задачи. |
| Автор: nikkadim 23.7.2012, 23:40 |
| Ок. У меня есть GigE камеры, каждая цепляется к своему PC, поток от них получаю минимум в 600 Mbit/s, мне необходимо из этого потока выделять фреймы и сохранять каждый в TIFF или в RAW где-то. Вот это "где-то" должно быть быстрее чем скорость приходящего потока, чтобы не терять фреймы (терять их я не могу, по условиям задачи). Отсюда возможностей не много, либо к каждому PC цеплять SSD, либо принимать все что валится сначала в выделенный буфер, а по окончанию потока сбрасывать это неспеша на диск. |
| Автор: bsa 23.7.2012, 23:50 |
| nikkadim, если у ОС есть достаточно свободной физической памяти, то она ее тебе предоставит через malloc/calloc. Если нет, то сбросит в своп редкоиспользуемый кусок памяти, и отдаст его тебе. |
| Автор: nikkadim 23.7.2012, 23:52 | ||
Вот если бы это было действитель но так, наверно я был бы почти щаслив! Спасибо. Последние Windows релизы (Win7x64) так умеют? Или подскажите плз ключевые слова, чтобы почитать про это. |
| Автор: boostcoder 23.7.2012, 23:55 | ||||||||||
уверен, что алгоритм выделения фреймов и преобразование их в какой-то формат, займет бОльшую часть времени, нежели сохранение.
терять ты их можешь тупо из-за того что проц не успевает ;)
ты все сильно преувеличиваешь. 600 Mbit это приблизительно 70 мбайт в сек. не так то уж много. но да, редко какой хард сможет сохранять с такой скоростью без тормозов. RAID в помощь. Добавлено через 3 минуты и 42 секунды
любые так умеют.
гугл -> malloc |
| Автор: nikkadim 24.7.2012, 00:03 | ||||||||
Да нет, проц курит в это время. Граббинг идет через драйвер и SDK производителя камеры, с этим все ок. А преобразование в формат идет через Libtiff оторый добавляет лишь около сотки байт в заголовок, а далее идет RAW, тоже нагрузки практически нет. Хороший RAID0 стоит тооже не плохо, как и хороший SDD (возможно и с рейдом) все это приводит к удорожанрию проекта, плюс изначально он планировался мобильным на лэптопах, чтобы можно было приехать быстро развернуться сделать измерения и ехать обрабатывать данные. В случае с рейдом это скорее всего тянет на DesctopPC. Так надо оно, если на борту и так есть достаточно памяти, тем более которая нужна только лишь на минуту или две. |
| Автор: boostcoder 24.7.2012, 00:06 | ||||
это происходит на отдельном компе? т.е. аппаратная обработка?
неправда. |
| Автор: nikkadim 24.7.2012, 00:14 | ||||||
Нет, это на каждом. Ок, наврал, около сотни байт еще вконце добавляет. Я не использую сжатие вообще. Снимаю с сенсора Bayer-массив как он есть и упаковываю его в TIFF. Но даже если и не упаковывать, разницы в скорости работы с буффером памяти в 500 фреймов с упаковкой в моих условиях нет. Я мог бы и в RAW писать, если бы libTIFF тормоза давал, а потом уже упаковывать, но дело не в этом, а в том куда байтики польются в момент съемки сначала. Добавлено через 10 минут и 43 секунды Я думаю меня вполне для начала устроит факт подсказанный bsa, нашел еще подтверждение тому в нескольких буржуйских источниках. Я об этом не знал, всегда думал что если физическая память заканчивается, то новые запросы он адресуют уже дальше по адресации в swap. Правда как и любая дисковая операция это может хорошенько подвесить систему, помню как моя Win95 или 98 просвопивалась на автокадах и прочих студиях. |
| Автор: Бонифаций 24.7.2012, 06:40 |
| в линуксе я могу Вам подсказать как сделать, чтобы область памяти была именно в RAM. Это вызов http://www.kernel.org/doc/man-pages/online/pages/man2/mlock.2.html В windows не знаю. Добавлено через 2 минуты и 49 секунд вот мне тут коллеги подсказывают, что в win это virtuallock() http://msdn.microsoft.com/en-us/library/windows/desktop/aa366895(v=vs.85).aspx |
| Автор: nikkadim 24.7.2012, 06:42 | ||
Интересно, не знал. Спасибо. |
| Автор: GremlinProg 24.7.2012, 07:27 | ||
в Windows это AWE: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366527(v=vs.85).aspx но для доступа к физической памяти все равно требуется хотя бы небольшое, но виртуальное окно, т.е. тут заморочек еще хватит, но если нужен простой статический буфер, проблем, думаю, не будет: резервируй диапазон физических страниц, мепируй их на аналогичный диапазон виртуальных страниц и пиши-читай туда что хошь, ни кто его не отберет и не сбросит на диск Добавлено через 2 минуты и 54 секунды правда тут потребуются некоторые привилегии, которые, впрочем, нужны и на virtuallock |
| Автор: 500mhz 24.7.2012, 08:54 |
| А чем GlobalAlloc + GMEM_FIXED не угодил? |
| Автор: bsa 24.7.2012, 11:30 |
| Народ, вы чего? Преждевременная оптимизация - это вред. Не надо на это заморачиваться. Я уверен, если программа под буфер потребует менее половины ОЗУ, то проблем со свопом быть вообще не должно. А если выяснятся узкие места, то всегда можно будет разгрузить "узкое место" за счет чего-то другого. Например, во время граббинга проц простаивает (допустим загрузка 5%), при этом памяти потребляется 2 ГБ из 4-х. Отсюда следует вывод, что можно сжимать данные перед укладкой в буфер. В итоге, проц загрузится на 50-80%, зато памяти будет расходоваться 256 МБ (для случая jpeg, например; в любом случае, числа "взяты с потолка"). |
