Comments 28
На правах красноглазия спрошу, gcc в генте собирается уже автоматом 3 раза или до сих пор руками приходится? :)
Оно всегда собиралось 3 раза, это часть сборки gcc и gentoo тут ни при чем. Я неправ?
Нет, всё так. Первый раз исходный код собирается host-компилятором, который сам может и не быть gcc, в итоге получается т. н. stage1. Потом stage1 собирает stage2, а stage2 собирает stage3. В конце stage2 и stage3 сравниваются, и, если они совпадают, делается вывод, что и host-компилятор, и сборка gcc на этой платформе работают правильно, после чего stage3 считается готовым к установке.
emerge делает всё сам.
Для углубленого ознакомления стоит ознакомиться с «gcc: компиляция на форсаже с турбо-наддувом» Криса Касперски, переодически заглядывая в man gcc. И тесты, тесты, тесты — это то, на что обычно не хватает времени и сил
Лучше чрезмерно не увлекаться различными флагами и оптимизациями, а то может получиться и «может привести к неработоспособности бинарников», и хуже. Если бы какая-то опция давала очевидное преимущество, то включалась бы вместе с -O2. Того, что написано в http://en.gentoo-wiki.com/wiki/Safe_Cflags, вполне хватает.
Советую также почитать http://funroll-loops.info/.
Советую также почитать http://funroll-loops.info/.
А может кто — то меня просветить, почему всегда выбирают число процессов/потоков равное числу ядер + 1? Почему плюс один? Не первый раз встречаю, очень интересно, а спросить негде :(
Чтобы число процессов всегда было чуть больше, чем «можно». В этом случае процесс уже инициализирован, все медленные операции (типа чтения с винта, и прочие) уже прошли и процесс просто ждёт, когда процессор освободится.
Спасибо, но всё равно немного непонятно… Если все процессы уже инициализированы, всё в памяти, готово к работе, то не логично ли повесить по одному процессу на ядро и дать им работать? Ведь этот лишний процесс будет только мешать, потому как будет наседать на уже занятое ядро и тратить ресурсы на переключение контекста на себя? В случае именно с компиляцией я могу понять, там может быть надо на винт что — то складывать и делать другие медленные операции… Спрашиваю, потому уже видел такое же в одной числодробильной библиотечке. Там расчёт распараллеливался на несколько потоков и число потоков по дефолту равно ядра+1. Всё уже в памяти, винт и другие не при чём, чисто только сам обсчёт в несколько потоков. Вот я и решил что это общее правило всегда и непонятно почему…
Файлов обычно компилируются очень много и они довольно маленькие, и дисковые операции связанные с записью результата и чтения следующего файла приводят к тому, что каждый из запущенных процессов так или иначе в это время периодически простаивает.
Вы так пишете, словно никогда ничего не компилировали. Иначе бы видели, что каждый процесс gcc отъедает в среднем менее 1.0
Вы так пишете, словно никогда ничего не компилировали. Иначе бы видели, что каждый процесс gcc отъедает в среднем менее 1.0
Ну в общем да, как — то раз только wine собирал, но не обращал внимания на загрузку. С компиляцией — то понятно, там дисковых операций много, мне интересно почему всегда так же в общем случае, где надо просто посчитать что — то, то тоже выбирают кол-во потоков с +1. Решил тут спросить, потому что в тему…
Если выделить на каждый процессор ровно по одному потоку сборки, то можеть получиться так, что в какое-то время процессор будет простаивать, ожидая ответа от жёсткого диска или другого устройства. Если же количество потоков будет чуть больше, чем количество процессоров, то высока вероятность, что во время таких вынужденных простоев ждущий процесс будет вытеснен другим, которому есть, что вычислять.
+1 — не единственный вариант; например, при наличии системы с 8 процессорами имеет смысл выбрать от 2 до 4 дополнительных потоков (конечно, если хватает памяти).
+1 — не единственный вариант; например, при наличии системы с 8 процессорами имеет смысл выбрать от 2 до 4 дополнительных потоков (конечно, если хватает памяти).
Спасибо. А что, если диск и другие устройства не при чём? Спрашиваю, потому уже видел такое же в одной числодробильной библиотечке. Там расчёт распараллеливался на несколько потоков и число потоков по дефолту равно ядра+1. Всё уже в памяти, чисто только сам обсчёт в несколько потоков. Вот я и решил что это общее правило всегда и непонятно почему…
Чтобы полнее нагружать процессор. Не всегда один поток грузит один процессор на все 100%.
Хочу также заметить что на системах с HT, где число ядер видимых системой в 2 раза больше ядер физических, «обманывать» систему добавляя 1 лишний процесс, не имеет смысла. Раздвоение потоков уже физически делает то, с чем не справляется планировщик ядра операционки, выделяя процессорное время то одному, то другому процессу. Во всяком случае это видно из тестов, но всё может меняться от ядра к ядру. Как раз Con Kolivas's BFS пытается решить эту проблему.
Я тут только что заметил что у меня march=native не включает mmx, а в /proc/cpuinfo он присутствует. Скажите, стоит ли его насильственно тащить через make.conf, или mmx отключили по разумным причинам? gcc-4.4.4
И ещё один вопрос: какой эффект даёт -mfpmath=sse? Я почему — то думал что он должен с -msse проставляться. Есть мысль собрать систему в новыми флагами, только не понятно будет ли с этого толк.
И ещё один вопрос: какой эффект даёт -mfpmath=sse? Я почему — то думал что он должен с -msse проставляться. Есть мысль собрать систему в новыми флагами, только не понятно будет ли с этого толк.
Статистика такова, что реальное ускорение для системы в целом, gnu сеймейства в данном случае, дает именно mmx, лишь по той причине что по статистике распределения mmx и sse* кода, первый занимает чуть ли не 60% (не хочу быть голословным, но линки сейчас найти не смогу).
Так же стоит обратить внимание как сейчас обстоят дела в gcc с записью такого вида: -mfpmath=387,sse.
Так же стоит обратить внимание как сейчас обстоят дела в gcc с записью такого вида: -mfpmath=387,sse.
А кто может подсказать, как задать размер стека при компиляции? А то сёня столкнулся с проблемой, а в гугле говорят задавать стек для всех приложений через ulimit -s.
а чё, в системе, не способной существовать без компиляции, до сих пор ниасилили автоматическую оптимизацию ключей компиляции?
Мне кажется кто-то не читал представленный материал. Как раз -O2 -march=native это и делает. Всё остальное делается на свой страх и риск. Например вы можете включить опасные оптимизации, но никто не будет гарантировать работоспособность приложения.
Даже проще — юзер должен выбрать из предложеных сетов оптимизации: -O0 -O1 -Os -O2 -O3. От отсутствия оптимизации до оптимизации в ущерб ресурсам. По умолчанию в Save Cfags предлагается O2.
Даже проще — юзер должен выбрать из предложеных сетов оптимизации: -O0 -O1 -Os -O2 -O3. От отсутствия оптимизации до оптимизации в ущерб ресурсам. По умолчанию в Save Cfags предлагается O2.
Почему некоторые оптимизации являются опасными?
Я видимо испорчен Java, но мне оптимизации представляются чем-то вроде refactoring, то есть они должны изменять способ выполнения операции, но сохранять при этом результат.
Я видимо испорчен Java, но мне оптимизации представляются чем-то вроде refactoring, то есть они должны изменять способ выполнения операции, но сохранять при этом результат.
Если бы всё было так просто :)
gcc не включает -funroll-loops (разворот циклов для более правильного задействования механизма предсказаний процессора) даже на -O3. Всё прекрасно до тех пор пока ваш цикл не вылезет за пределы L1 или даже L2 — и вся ваша оптимизация только замедлит выполнение кода.
Или -ffast-math, включающий супер оптимизации для числобоек, только вот это не гарантирует соблюдение стандартов IEEE и ISO. Спрашивается, а зачем нам такая «скорость», если приложение вдруг не пройдёт >>100к юнит тестов у заказчика.
Совершенно понятно, что все оптимизации имеют место быть до тех пор пока вы держите ситуацию под контролем, код вам знаком, и уже давно «на ты» с профилировщиком и отладчиком.
gcc не включает -funroll-loops (разворот циклов для более правильного задействования механизма предсказаний процессора) даже на -O3. Всё прекрасно до тех пор пока ваш цикл не вылезет за пределы L1 или даже L2 — и вся ваша оптимизация только замедлит выполнение кода.
Или -ffast-math, включающий супер оптимизации для числобоек, только вот это не гарантирует соблюдение стандартов IEEE и ISO. Спрашивается, а зачем нам такая «скорость», если приложение вдруг не пройдёт >>100к юнит тестов у заказчика.
Совершенно понятно, что все оптимизации имеют место быть до тех пор пока вы держите ситуацию под контролем, код вам знаком, и уже давно «на ты» с профилировщиком и отладчиком.
пост какой-то пустой и несодержательный
мануалы хендбука с генту.орг есть на русском языке. там пространно и аргументированно расписано.
приходилось восстанавливать систему, переставляя материнку и проц на более старые. переоптимизированная система при этом, очевидно, работать не хотела.
не оптимизируйте под процессор, если не уверены.
людей, которым нужно оттачивание под конкретные фичи процессора встречались только на кластере, где было массовое пережатие видео и все радовались как дети выигрышу в единицы процентов.
мануалы хендбука с генту.орг есть на русском языке. там пространно и аргументированно расписано.
приходилось восстанавливать систему, переставляя материнку и проц на более старые. переоптимизированная система при этом, очевидно, работать не хотела.
не оптимизируйте под процессор, если не уверены.
людей, которым нужно оттачивание под конкретные фичи процессора встречались только на кластере, где было массовое пережатие видео и все радовались как дети выигрышу в единицы процентов.
Использую -momit-leaf-frame-pointer — позволяет использовать частично оптимизации -fomit-frame-pointer там где последний убирается пакетом как запрещенный. И он также оставляет возможность отладки.
Sign up to leave a comment.
Оптимизация компиляции GCC на примере Gentoo