Страниц: [1]
  Печать  
Автор Тема: Осторожно: precompiled headers!  (Прочитано 4566 раз)
oder
Гость
« : Августа 18, 2012, 08:27:42 pm »

Наконец то, мне удалось побороть тормоза при компиляции в QNX 6.5
У нас проект с precompiled header и мы туда включаем STL и всякую базовую дребедень, чтоб не напрягаться с инклудами в каждом файле. Файл прекомпайлд-хидеров получается порядка 25 Мб. Так вот, после переноса прекомпайлд-хидеров на RAM-диск, скорость компиляции возростает в 5 (пять!) раз (с ~9 файлов в минуту до ~50).
В какой же ж#пе должна быть подсистема кеширования диска, чтоб при 512 Мб памяти выделенных для кеша она не могла закешировать одного файла на 25 Мб, который генерируется один раз и потом к нему постоянно лишь идут обращения на чтение.  Shocked
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #1 : Августа 19, 2012, 02:23:31 pm »

В QNX 6.5 кэширование организовано не по-файлово, а по-блоково, видать gcc при обращении к солянке хидеров, каждый раз обращается к новому участку, поэтому кэширование файла происходит постепенно. Так же не стоит забывать, что 512Mb - это фигня, т.к. в кєш попадает весь gcc toolchain с либами и прочим хозяйством. А также все временные файлы и объектники, которые один раз создаются и до линковки не нужны.
Записан

oder
Гость
« Ответ #2 : Августа 19, 2012, 04:28:15 pm »

Прикол в том, что toolchain, как раз, не попадает. Все бинарники и все /usr/include я перегнал на рамдиск ещё задолго до того, когда только 6.5 осваивали. Иначе новый GCC 4.2.1 ну уж очень отставал от старого GCC 3.3.5 из QNX 6.3.
И precompiled headers - насколько я понимаю - это, просто, сохранённый в файл образ памяти после некоторого промежуточного этапа разбора хидеров. Тоесть, используя его при компиляции .cpp компилятор грузит всё это добро в память и стартует не с самого начала, а уже с какой-нибудь подготовленной стадии. А если ещё учесть, что файлов в проекте более чем предостаточно, то времени закешировать файл хидеров должно хватать. Вернее даже, файл, просто, должен бы оставаться в кеше ещё со времени его записи.
Записан
vshemm
Sr. Member
****
Offline Offline

Сообщений: 317


Просмотр профиля
« Ответ #3 : Августа 19, 2012, 11:20:39 pm »

Поблоковое решение на данный момент наиболее ээ reliable. Оно и в линуксе давно применяется,
и с некоторых пор в Windows. Оно позволяет эффективно обрабатывать рандом-запросы к файлам,
что как раз важно для precompiled headers. Так что тут кросс-компиляция рулит.
А рам диск (или SSD) решают проблему для юзера, но не для кеширования QNX`ом.

Вообще, абсолютные показатели (9 файлов в минуту и даже 50) очень низкие, у вас там пень про что ли? Smiley
Записан
oder
Гость
« Ответ #4 : Августа 20, 2012, 12:26:15 am »

Да Core 2 Quad, вроде.  Smiley Но тут не в процессоре проблема. Процессор простаивает - загибается ввод/вывод. И кеш, как ни печально, совсем не помогает - даже если его и гигабайт дать.
У них проблема какая-то с кешами там. Бывает, что система после некоторого времени работы начинает жутко тормозить на элементарных дисковых операциях (видно даже по неестественно медленной распаковке .tar.gz.). И тогда и компиляция может длиться значительно дольше. Реально случалось, что полный ребилд программного комплекса мог занимать 2 часа вместо стандартных 40-45 минут. Визуально выглядит так, что при компиляции каждого файла наблюдается постоянная дисковая активность на несколько секунд (лампочка HDD не гаснет) - потом заметная пауза перед следующим файлом. В нормальном состоянии системи - когда она свежая после перезагрузки - диск только изредка помигивает и файлы идут как минимум раза в два быстрее.

[Edit]
Я боюсь, что они там каких-нибудь своих алгоритмов кеширования нафантазировали, пока "значительно улучшали систему кеширования диска" в QNX 6.4/6.5 и эти алгоритмы могут быть не совсем масштабируемыми на большие объемы и/или не совсем эффективными.
« Последнее редактирование: Августа 20, 2012, 12:31:10 am от oder » Записан
vshemm
Sr. Member
****
Offline Offline

Сообщений: 317


Просмотр профиля
« Ответ #5 : Августа 20, 2012, 12:45:23 am »

Очень странно. У меня даже в виртуалке (virtualbox) шустрее компиляция идет. И если у вас не мегабайтные файлы
исходников, на которых загибается компилятор, то даже не знаю.
Хотя у меня кеширование на хосте включено.

В общем, 2-3 файла в сек на ядро у core 2 duo средняя скорость. Это на кваде дает ~500-700 в минуту ) Кеширует XP.
Записан
oder
Гость
« Ответ #6 : Августа 20, 2012, 12:54:52 am »

Ну, может у вас чистое C? Оно компилируется намного легче и быстрее, чем C++.
Записан
vshemm
Sr. Member
****
Offline Offline

Сообщений: 317


Просмотр профиля
« Ответ #7 : Августа 20, 2012, 12:57:17 am »

Нуда Smiley Поэтому и сделал оговорку про сорцы и компилятор.
Записан
AG
QOR.Moderator
*****
Offline Offline

Сообщений: 872



Просмотр профиля WWW
« Ответ #8 : Августа 27, 2012, 12:07:41 pm »

Поблоковое решение на данный момент наиболее ээ reliable.
Тут пожалуй соглашусь, ибо это действительно проще чем по-файловое кеширование.

Оно и в линуксе давно применяется,
и с некоторых пор в Windows.
Судя по умным книгам, в винде и линухе как раз применяется по-файловое кеширование... Не бросите ли ссылку подтверждающую Ваше утверждение. Просто хочу почитать - для меня эта тема ооооочень интересная.
Записан

vshemm
Sr. Member
****
Offline Offline

Сообщений: 317


Просмотр профиля
« Ответ #9 : Августа 29, 2012, 12:36:23 am »

Скажу сразу - в винде поблоковое решение применяется давно, но нормально работать оно начало недавно Wink

Также вопрос с терминологией. Дело в том, что и в винде и в линуксе все уже давно (лет 10 как минимум)
объединили в один большой механизм - Cache Manager и Page Cache соответственно. Они кешируют все - обычные
read/write над файлами и устройствами, обращение к memory-mapped файлам, метаданные файловых систем и т.д.
В винде даже есть механизм использование кеша как DMA буферов, чтобы сразу туда сетевые карты пихали данные
(нужно для кеширования сетевых ФС). Конечно, информация о файлах как объектах ФС используется (например,
для FastIO или обеспечения когерентности кеша когда в один файл одновременно пишут и с помощью write и как
в memory-mapped file). Так что кеши частично file-based(?) и блоковые в общем смысле.

Ссылки для ознакомления:
http://www.ibm.com/developerworks/linux/library/l-linux-filesystem/
http://duartes.org/gustavo/blog/post/page-cache-the-affair-between-memory-and-files

И, конечно, Windows Internals Руссиновича (4+ издание), глава Cache Manager и Linux Kernel Development Лава,
глава Page Cache. Understanding the Linux Kernel тоже пойдет, но там рассматривается довольно древнее ядро.

И, разумеется, исходники + крохи по блогам девелоперов Smiley
Записан
AG
QOR.Moderator
*****
Offline Offline

Сообщений: 872



Просмотр профиля WWW
« Ответ #10 : Августа 29, 2012, 10:32:31 am »

Ясно, спасибо. Буду тогда копать.
Записан

Страниц: [1]
  Печать  
 
Перейти в: