В последнее время довольно часто приходится слышать о неимоверной прожорливости Огненной Лисы. Появляется множество расширений (полезных и не очень) и вместе с этим растут запросы к ресурсам вашей машины. За удобство приходится платить кровными мегами.

Несмотря на устойчивое общее мнение, что оперативки много не бывает, последнее время я неоднократно натыкаюсь на коментрании, в которых народ с уверенностью в своей правоте утверждает, что 4 гига памяти в нотбуке это ненужная роскошь. В качестве аргумента приводятся две причины — первая то, что 32 битные Windows не видят более 3.5 гиг и не используют излишек. Вторым аргументом является энергопотребление, мол 4-х гиговая конфигурация скушает батарею нотбука куда как быстрее, чем 2-х гиговая.
Лаборатория сайта Tom's hardware guide протеститровала поведение серийного лаптопа Dell при работет с 2 и с 4 гигабайтами памяти на борту. За что им большое спасибо. Результаты эксперимента подробно описаны здесь.
Для тех, кому лень переходить по ссылке сообщаю, что энергопотребление немного упало с ростом памяти (что неожиданно), а производительность выросла (как и ожидалось)
К сожалению, осталась за кадром конфигурация с 3 гигами, в которой память перестает работать как двухканальная, и мы так и не сможем аргументировано утвеждать насколько это плохо.

Herb Sutter (автор Exceptional C++, бывший глава ISO C++ standards committee, мистер Free Lunch Is Over и прочая, и прочая) работает в Microsoft и иногда по средам читает атомные лекции.

Я наконец-то на одну такую попал, и очень радовался. На умных мужиков всегда радостно поглядеть и послушать.
Для отчета — кроме Херба, видел живого Олександреску и живого Walter Bright (который "D").

Лекция называлась «Machine Architecture: Things Your Programming Language Never Told You» (здесь можно скачать презентацию и видео) и была про конкретную часть abstraction penalty — Memory Latency.

Я попытаюсь коротко рассказать о ключевой мысли лекции. Она простая, очевидная и тысячу раз сказанная. Думаю, еще раз повторить азбуку — никогда не повредит.

На моём сайте пользователи загружают картинки, которые уменьшаются до необходимого размера (максимальная сторона — 800 точек). И столкнулся с ограничением памятя для работы PHP скриптов, для обработки фотографий 7 мпикс уже не хватало памяти, а сейчас фотоаппараты и поболее будут, не заставлять же пользователей обрезать фотографии до отправки, многие вообще тогда не будут загружать их.

Ошибка была на строке:

$image = imagecreatefromjpeg($filename);

PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 3072 bytes) in…

Чтобы решить проблему, необходимо уменьшить исходную фотографию. ImageMagick на хостинге не оказалось, поэтому не знаю, можно ли было решить проблему через эту библиотеку.
Зато оказалось что можно выполнить внешнюю команду через exec();

Решение проблемы:

$filename = 'image.jpg';
$maxside = 800;
$size = getimagesize($filename);
if (($size[0] > $maxside) or ($size[1] > $maxside)) {
  exec ('mogrify -resize '.$maxside.'x'.$maxside.' '.$filename);
  $size = getimagesize($filename);
}
$image = imagecreatefromjpeg($filename);

P.S.: Поиск в гугле показал несколько форумов, где проблему предлагали решать в лоб — уменьшением лимита памяти, путём договорённости с админами хостинга.

Мы знаем, что Google Chrome — самый быстрый и один из наименее требовательных браузеров. Но если вы все-же испытываете недостаток в оперативной памяти, причиной которому стал Chrome, то достаточно добавить --purge-memory-button в командную строку запуска. И будет вам счастье.

Узнал здесь

Добрый день.

Простая истина гласит, гнать нужно то что гонится. Успешному разгону кроме центральных процессоров, неплохо поддается системная память. Но не все йогурты одинаково полезны, а точнее не все микрочипы хорошо гонятся относительно своей номинальной частоты.

Управляемая память в .Net поделена на стек и несколько хипов. Самые важные из хипов – это обычная (эфемерная) куча и LOH. Эфемерная куча – это то место, где живут все обычные объекты. LOH – это то место где живут большие (больше 85000 байт) объекты.

LOH обладает некоторыми особенностями:

• Объекты в LOH никогда не перемещаются
• LOH только растет и никогда не уменьшается (т.е. если объект собран сборщиком мусора, размер LOH все равно остается неизменным)
• Хип LOH освобождается только тогда, когда LOH полностью пуст

Из этих двух особенностей LOH происходят два важных следствия, про которые часто забывают:

• Память в LOH может оказаться фрагментированной. Т.е. происходит то, с чем так боролись в unmanaged мире: в какой-то момент у вас может быть 10Mb свободной памяти, но вы не сможете выделить память под объект размером 1Mb
• Если вы однажды выделили память под большой объект, а потом используете только маленькие, то вы фактически лишаете себя большого куска памяти. При чем, если у вас в LOH был список или хэш-таблица размером N, а вы добавили в него один элемент, то список реаллоцируется и растет в два раза, сответственно размер LOH составит как минимум 3*N (N – исходные данные, 2N – копия данных и резерв под новый размер). Следующий рост потребует в LOH непрерывный кусок памяти размером в 4*N, а так как такого куска в LOH у нас нет (есть только N), его придется позаимствовать из адресного пространства процесса. В итоге размер LOH вырастет до 7*N, и так далее.

Если вспомнить, что LOH аллоцируется кусками по 16Mb, то все происходящее покажется еще более разрушительными. С первым следствием можно бороться аккуратно переиспользуя объекты. Со вторым — не используя большие объекты. Получается как-то не очень, особенно если с большими коллекциями работать все-таки хочется. Посмотрим, что как можно решить эту проблему.

Почти все разработчики знают, что кэш процессора — это такая маленькая, но быстрая память, в которой хранятся данные из недавно посещённых областей памяти — определение краткое и довольно точное. Тем не менее, знание «скучных» подробностей относительно механизмов работы кэша необходимо для понимания факторов влияющих на производительность кода.

В этой статье мы рассмотрим ряд примеров иллюстрирующих различные особенности работы кэшей и их влияние на производительность. Примеры будут на C#, выбор языка и платформы не так сильно влияет на оценку производительности и конечные выводы. Естественно, в разумных пределах, если вы выберите язык, в котором чтение значения из массива равносильно обращению к хеш-таблице, никаких результатов пригодных к интерпретации вы не получите. Курсивом идут примечания переводчика.

 

Цены на плеер Nano от Apple неуклонно снижаются, спасибо прогрессу и падающей цене на память.


2005 (2GB)
Розничная цена $199
Цветной дисплей, нет жесткого диска
Цена компонентов $90.18
Память $54 (Поставщик Samsung)
Экран $9

Высоконагруженный проект (web-сайт) — не обязательно популярная социальная сеть, видеохостинг или MMORPG. Простейший способ резко повысить требования сайта к железу — перенести хранение сессий в БД. В этой статье мы рассмотрим способ хранить данные в БД, и при этом не жертвовать производительностью. Пожертвовав небольшим объемом ОЗУ можно прилично сэкономить процессорное время. Мы говорим о стиуации, когда недоступны memcached и другие специальные средства кэширования.

Краткая заметка с линками и примерами о профайлинге:

1. производительности: hotshot или python profile/cProfile + визуализатор логов kcachegrind (есть порт под windows, аналог WinCacheGrind)
2. использование памяти: dowser с web-интерфейсом

Я прочитал очень-очень интересную статью «Стратегии управления памятью для Erlang VM». Она была написана в качестве диссертации Джеспером Вильхельмсоном. Я подумал, что было бы неплохо обсудить различия между управлением памятью в Erlang и Java VM от Oracle.

Под впечатлениями от habrahabr.ru/blogs/java/134102.

Недавно мне приходилось немного поковыряться внутри JVM. Довольно интересный опыт. Текст в вышеупомянутом топике не совсем сходится с моим опытом, но я не считаю себя обладателем абсолютной истины. Ниже я поделюсь с читателями небольшой частью моих экспериментов, которые касаются непосредственно объектов Java.

При написании приложений, одной из важнейших вопросов являются потребление памяти и отзывчивость (скорость работы).

Считается, что сборщик мусора – черный ящик, работу которого нельзя предугадать.

А еще говорят, что GC в .NET практически не настраиваемый. А еще, что нельзя посмотреть исходники как классов .NET Framework, так и CLR, GC и т.п.

А я скажу как бы ни так!

В данной статье мы рассмотрим:

• структура организации размещения объектов в памяти
• CLR 4.5 Background Server GC
• правильная настройка сборщика мусора
• эффективный апгрейд приложений до .NET 4.0+
• правильное ручное управление памятью

В Badoo используется много сервисов на C и C++, большинство из которых работают с огромными объёмами данных. Как правило, сервисы выступают в роли «быстрого кэша» или «быстрой базы данных», т.е. совершают различные операции с массивами однотипных данных. Для быстрого доступа к данным мы давно и успешно используем Judy-массивы (англ. Judy arrays). Но однажды нам захотелось странного: обрабатывать большие массивы целых чисел на PHP, и мы сразу вспомнили про Judy.

Немного истории

Judy-массивы были изобретены Дугласом Баскинсом (англ. Douglas Baskins) в начале 2000-го года. Проект их разработки финансировался компанией HP, но примерно через два года был закрыт. За это время было выпущено четыре версии, причём разработка последней заняла больше года, и в ней разработчики смогли в два раза ускорить Judy, в два раза уменьшить потребление памяти, хоть и далось это нелёгкой ценой: объём кода вырос в 5 раз, а его сложность  ― на порядок.

Управление памятью – центральный аспект в работе операционных систем. Он оказывает основополагающее влияние на сферу программирования и системного администрирования. В нескольких последующих постах я коснусь вопросов, связанных с работой памяти. Упор будет сделан на практические аспекты, однако и детали внутреннего устройства игнорировать не будем. Рассматриваемые концепции являются достаточно общими, но проиллюстрированы в основном на примере Linux и Windows, выполняющихся на x86-32 компьютере. Первый пост описывает организацию памяти пользовательских процессов.

^{(источник)}
Не так давно был опубликован стандарт на DDR4 SDRAM – оперативную память нового поколения. Стандарт во всех деталях описывает устройство памяти, но о том, в чём, собственно, отличия от памяти предыдущего поколения, или какие преимущества сулит переход на DDR4 сказано или совсем немного или не сказано вообще (вероятно, в надежде на фантазию читателей :-) ).
В этом посте я постараюсь изложить основные отличия DDR3 от DDR4, и какие преимущества несет для конечных пользователей новый стандарт памяти.

Дорогие хаброжители, мы запустили небольшой проект, который рассказывает о разгоне в формате видео. В первом видеоролике мы подготовили 2-х минутное видео, в котором пошагово показали, как разогнать оперативную память Corsair Dominator Platinum CL10 CMD16GX3M4A2666C10 до частоты 2800 МГц. Данная память основана на микросхемах Samsung 2 Gbit ревизии D с маркировкой K4B2G0846D. Если у вас есть память на таких же микросхемах, то это видео поможет вам получить небольшую прибавку производительности. В основе тестового стенда мы использовали процессор Intel Core i7-4770K и материнскую плату ASUS Maximus VI Impact. Если у вас есть сложности с разгоном или вы не знаете, как что-то разогнать, пишите в комментариях, мы постараемся вам помочь или снимем для вас видеоурок. Приятного просмотра!

Ранее мы увидели как организована виртуальная память процесса. Теперь рассмотрим механизмы, благодаря которым ядро управляет памятью. Обратимся к нашей программе: