?

Log in

No account? Create an account
1st_noiz [entries|archive|friends|userinfo]
1st_noiz

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

C/C++ memory management - realloc and mremap [Jan. 16th, 2012|02:22 pm]
1st_noiz
English version below

Прочитал новость, что mremap в Linux 3.2 ускорили, а точнее улучшили работу с TLB. Какие программы это ускорит? В каких случаях вообще используется realloc?

К примеру динамический буффер в куче. Когда мы добаваляем в него данных, и он автоматически расширяется, при этом данные в нем хранятся непрерывно. Например std::vector. Однако std::vector, как и все контейнеры STL, и даже контейнеры сторонних библиотек используют std::allocator для управления памятью. std::allocator имеет только две функции для управления памятью allocate и deallocate.
Все просто, однако мы не можем использовать опимизированную realloc. Таким образом когда мы в std::vector добавим очередной элемент, и это потребует расширения std::vector, мы вызовем allocator.allocate() с новым размером, расчитанным по определенным правилам, потом скопируем все элементы в новое место и вызовем allocator.deallocate() для сторого куска. Плюс вызов конструкторов, деструкторов если необходимо. Таким образом все STL контейнеры не могут использовать realloc, потому что завязаны на std::allocator. Даже больше, в С++ память выделяется с помощью new, delete и идеологически нет возможности сделать realloc, кроме как через new, copy, delete. С одной стороны это упрощает C++, но с другой мы теряем часть возможностей доступных уровнем ниже.
А теперь вопрос, зачем нужно хранить данные непрерывно? Есть C функции, которые работают с непрерыными кусками памяти (binary_search, строковые,...), однако ядро имеет writev/readv, т.е. работать с фрагментированными кусками памяти. Можно иметь свой контейнер, который будет хранить фрагментированно и binary_search, строковые функции которые будут рабоать с таким контейнером.
Быстрый поиск по boost и я не нашел подобного контейнера. Вопрос о накладных расходах хранения данных фрагментированно - понятно, что хранить каждый байт в своем фрагменте и выводить через writev() и по памяти и по CPU накладнее. Будет время, сделаю тесты по скорости динамических буферов с хранением непрерывно и фрагментированно.
К слову coreutils и libevent используют realloc в некоторых местах для работы с динамическими буферами, nginx нет.


Read the news about increseasing speed of mremap in Linux 3.2, specifically work with TLB. What pragramms will benefit from this? In which cases is realloc used? I.e. dynamic buffer on the
heap. When we add data to it, it increases automaticaly, meanwhile data is stored continiously. For example, std::cector. But std::vector, as all STL containers, and even third-party libraries
containers use std::allocator for memory management. std::allocator has only two function for memory management allocate and deallocate. That's simple, but we are not able to use optimised realloc.
Thus when we add new element to std::vector, and it will be needed to expand std::vector, we will call allocator.allocate() with new size, computed with some defined rules, then copy all elements in new place and call allocator.deallocate() for old chunk. Plus calling constructors, destructors if necessary. So all STL containers can't use realloc, because are linked with std::allocator. Even more, all memory in C++ memory is managed with new and delete and ideologically there is no way to do realloc, except new, copy, delete. One the one side it makes C++ easier, but on the other we loose some functionality, available on lower level.
And now the question is - why we need to store data continiously? There are С functions, that work with continiously allocated data (binary_search, string functions, ...), but kernel has writev/readv, and thus can work with fragmented memory. We can have our own container, that will store data fragmented and our binary_search, string functions that will work with such container. Fast search in boost, but I didn't find any such container. The question is about overhead with storing data fragmented. It's clear, that storing single byte in it's own chunk and output it with writev() will have a lot of CPU and memory overhead. Sometime I'll write test comparing storing data contitiously and fragmented.
By the way coreutils and libevent use realloc in some places to work with dynamic buffers, nginx do not.
LinkLeave a comment

Science article generator [Jan. 8th, 2012|06:27 pm]
1st_noiz
English version below

Генератор научных статей. Вводим автора(ов) нажимаем generate и у нас статья с картинками, формулами, графиками. Я ввел
Edward Lee и получил "802.11B Considered Harmful", что вполне забавно.


Science article generator. Type author(s) click generate and you will get article with pictures, formulas, charts. I have typed Edward Lee and got "802.11B Considered Harmful", that seems pretty funny.
LinkLeave a comment

DJBX33A collisions [Jan. 7th, 2012|09:35 pm]
1st_noiz
(English version below)

Прочитал новость о коллизиях в реализациях хэш функций в php/python/ ...
Как пишут в статье "PHP realistically: 500k of POST → 1 minute" и не поверил, что в действительности так. Нашел коллизии для DJBX33A, создал файл на 1.0MB с 27k записей, проверил на сервере. POST запрос выполняется на одном ядре современного серверного процессора 50(!) секунд. Не оптимальный POST, есть как уменьшить, но я на этом остановился. Проверил несколько своих сайтов с бекендом на PHP, дружно ложаться... Ограничил POST на 100Кб, но это не решение. Ждем когда сделают рандомизацию хэш функции.



Read the news about collisions in hash functions of php/python/... As it was said in the article "PHP realistically: 500k of POST → 1 minute" and didn't believe it, that it is really so. Found collisions for DJBX33A, created 1Mb file with 27k records, tested on the server. POST request is executed on one core of modern server CPU for 50(!) seconds. It's not the optimal POST, can be smaller, but I stoped with that. Tested some of my sites with PHP backend, all are going down... Limited POST for 100Kb, but that's not the solution. Will wait for hash function randomisation.
LinkLeave a comment

Работа!!! [Dec. 24th, 2011|09:36 pm]
1st_noiz
[Tags|, ]

Ищется студент, знакомый с веб серверами, HTML, JavaScript, PHP, Linux, желающий узнать их лучше.
Предлагаем: разработку реальных проектов, консультации специалистов, небольшое вознаграждение.
Это возможность изучать то, что тебе интересно, и получать за это деньги.

mail+jabber: ru.artem@gmail.com
LinkLeave a comment

Кристаллы [Apr. 7th, 2011|09:56 am]
1st_noiz
Сегодня хочется немного посмотреть на кристаллы, точнее на то, что на них размещается. Вот первый из них, который собственно и побудил написать на эту заметку.
Xeon E7
Это кристалл нового Xeon E7 c 10 ядрами. Но главное не это. Посмотрите сколько места занимает 30(!) Мб кеша. Если разметка блоков верная, в чем я сомневаюсь, то кеш память занимает половину всего кристалла. Немного повременим с размышлениями, а посмотрим на другие экспонаты.
Read more...Collapse )
Link2 comments|Leave a comment

livejournal rss [Mar. 30th, 2011|11:59 am]
1st_noiz
[Tags|]

Оказывается чтобы читать livejournal в RSS нужно к названию блога добавить /data/rss
И почему на странице блога нигде нет ссылок?

Upd:Для blogspot нужно добавить /atom.xml
Link2 comments|Leave a comment

Tch. companies [Jan. 21st, 2011|10:59 pm]
1st_noiz
By profit

Read more...Collapse )
LinkLeave a comment

Дух стартапов [Jan. 18th, 2011|11:46 am]
1st_noiz
10 000 подписчиков за 2 дня к стартапу Hipster без пояснения что он собственно будет делать. Сейчас эта цифра уже 14 000.
LinkLeave a comment

Видео производства карт памяти [Jan. 17th, 2011|09:51 pm]
1st_noiz
LinkLeave a comment

Почему ПО работает медленее? [Jan. 16th, 2011|11:25 pm]
1st_noiz

Провокационная картинка. Кажется новый софт работает все медленнее, однако это только половина правды. Во многих случаях производительность уходит не зря:

  • Новый функционал

  • Поддержка старого функционала - он обычно никуда не уходит

  • Обработка большего количества информации. Фотографии и видео лучшего качества, принтеры и мониторы большего разрешения


Кстати интересная статья на тему куда расходуются все большее количество транзисторов в процессорах - Communications of the ACM 2009/05 "Spending Moore's Dividend".
Link3 comments|Leave a comment

navigation
[ viewing | most recent entries ]
[ go | earlier ]