The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Первая альфа-сборка FreeBSD 10.0, opennews (??), 14-Сен-13, (0) [смотреть все] +1

Сообщения [Сортировка по времени | RSS]


36. "Первая альфа-сборка FreeBSD 10.0"  +4 +/–
Сообщение от Jon (??), 14-Сен-13, 12:13 
> Может это лучше чем пихать непроверенные фичи в ядро и потом в
> спешке выпускать еще одно чтобы пофиксить?

А теперь перефразируйте для Clang.

Ответить | Правка | Наверх | Cообщить модератору

42. "Первая альфа-сборка FreeBSD 10.0"  +/–
Сообщение от Фтщтнь (?), 14-Сен-13, 13:33 
> А теперь перефразируйте для Clang.

А кланг уже в ядро включили?

Ответить | Правка | Наверх | Cообщить модератору

87. "Первая альфа-сборка FreeBSD 10.0"  –2 +/–
Сообщение от Led (ok), 14-Сен-13, 21:54 
>> А теперь перефразируйте для Clang.
> А кланг уже в ядро включили?

А ним собрано powerpc, ia64 и sparc, как сказано в новости?

Ответить | Правка | Наверх | Cообщить модератору

99. "Первая альфа-сборка FreeBSD 10.0"  –1 +/–
Сообщение от Фтщтнь (?), 14-Сен-13, 23:47 
Анониму опеннета явно лишь бы вбросить. Выбирай что больше нравится
root@daemon:/usr/ports/lang # cd /usr/ports/lang/
root@daemon:/usr/ports/lang # ls -la | grep gcc
drwxr-xr-x    3 root  wheel     7 12 сен 15:02 gcc
drwxr-xr-x    3 root  wheel     9  5 сен 06:37 gcc-aux
drwxr-xr-x    2 root  wheel     5 21 июл 04:57 gcc-ecj45
drwxr-xr-x    3 root  wheel     7 12 сен 15:02 gcc34
drwxr-xr-x    3 root  wheel     7 12 сен 15:02 gcc42
drwxr-xr-x    3 root  wheel     7 12 сен 15:02 gcc44
drwxr-xr-x    3 root  wheel     7 12 сен 15:02 gcc46
drwxr-xr-x    3 root  wheel     7 12 сен 15:02 gcc47
drwxr-xr-x    3 root  wheel     7 12 сен 15:02 gcc48
drwxr-xr-x    3 root  wheel     7 12 сен 15:02 gcc49

root@daemon:/usr/ports/lang # ls -la | grep clang
drwxr-xr-x    3 root  wheel     7 15 авг 15:39 clang
drwxr-xr-x    3 root  wheel     7  4 сен 19:37 clang-devel
drwxr-xr-x    3 root  wheel     7 15 авг 15:39 clang31
drwxr-xr-x    3 root  wheel     7 15 авг 15:39 clang33

Ответить | Правка | Наверх | Cообщить модератору

100. "Первая альфа-сборка FreeBSD 10.0"  +/–
Сообщение от iZEN (ok), 15-Сен-13, 00:08 
> Анониму опеннета явно лишь бы вбросить. Выбирай что больше нравится
> root@daemon:/usr/ports/lang # cd /usr/ports/lang/
> root@daemon:/usr/ports/lang # ls -la | grep gcc

...
> drwxr-xr-x    3 root  wheel 7 12 сен 15:02 gcc49

Сейчас придёт User294 и скажет, что GCC 4.9.0 ещё не вышел, и во Фре машина времени работает. :))

Ответить | Правка | Наверх | Cообщить модератору

154. "Первая альфа-сборка FreeBSD 10.0"  +1 +/–
Сообщение от Аноним (-), 16-Сен-13, 05:08 
> во Фре машина времени работает. :))

Знаем мы вашу машину времени:
- А вот ZFS! Свежий! Налетай!
- Ой! А чего это оно виснет регулярно?
- А, это мы тут sendfile() малость не реализовали.

- А вот пакетный манагер! Новье и круть!
- Б...я! Но там же нет пакетов?
- Ну... возьмите их у PC-BSD, пока мы чего-нибудь придумаем.

Ответить | Правка | Наверх | Cообщить модератору

88. "Первая альфа-сборка FreeBSD 10.0"  –4 +/–
Сообщение от pavlinux (ok), 14-Сен-13, 21:56 
>> А теперь перефразируйте для Clang.
> А кланг уже в ядро включили?

Не, хуже - шлангом теперь компилят всё! Раньше у БЗД только ядро было тормозное, теперь и софт будет.

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

96. "Первая альфа-сборка FreeBSD 10.0"  +2 +/–
Сообщение от iZEN (ok), 14-Сен-13, 22:58 
> Раньше у БЗД только ядро было тормозное, теперь и софт будет.

Разве?
http://www.linux.org.ru/forum/development/9577718?cid=9578888


Ответить | Правка | Наверх | Cообщить модератору

102. "Первая альфа-сборка FreeBSD 10.0"  +1 +/–
Сообщение от pavlinux (ok), 15-Сен-13, 00:10 
>> Раньше у БЗД только ядро было тормозное, теперь и софт будет.
> Разве?
> http://www.linux.org.ru/forum/development/9577718?cid=9578888
> А чё, вся БЗДа уже на Java переписана?
Ответить | Правка | Наверх | Cообщить модератору

103. "Первая альфа-сборка FreeBSD 10.0"  +3 +/–
Сообщение от iZEN (ok), 15-Сен-13, 00:13 
> А чё, вся БЗДа уже на Java переписана?

///---
Унылый c++ в лице clang 3.3 показал 2.2 sec.

Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.1.1.171 Build 20130313

Res = vector2d(-2.65058e+006,5.69089e+006)
Total time = 2.449 (sec)
Average time = 0.002449 (sec)

Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64

Res = vector2d(-2.65058e+006,5.69089e+006)
Total time = 5.632 (sec)
Average time = 0.005632 (sec)

gcc версия 4.8.1 20130603 (Red Hat 4.8.1-1) (GCC)

Res = vector2d(-2.65058e+06,5.69089e+06)
Total time = 5.05 (sec)
Average time = 0.00505 (sec)

clang version 3.3 (tags/RELEASE_33/rc3)

Res = vector2d(-2.65058e+06,5.69089e+06)
Total time = 2.2 (sec)
Average time = 0.0022 (sec)

bhfq ★★★★ (13.09.2013 13:50:07)
---///

Где ты видишь хоть слово "Java"? Это так овальные звёзды действуют, да?
Поспи лучше, а то завтра (упс, уже сегодня) гонка в Ромашково... 16, 32 иль 48 км.

Ответить | Правка | Наверх | Cообщить модератору

104. "Первая альфа-сборка FreeBSD 10.0"  +1 +/–
Сообщение от pavlinux (ok), 15-Сен-13, 00:15 
Дальше-то прочитал?

---
тем не менее gcc без -fPIC
g++ -O2 -m64 cpptest.cpp

./a.out
Res = vector2d(-2.65058e+06,5.69089e+06)
Total time = 2.29 (sec)
Average time = 0.00229 (sec)


Ответить | Правка | Наверх | Cообщить модератору

105. "Первая альфа-сборка FreeBSD 10.0"  –1 +/–
Сообщение от iZEN (ok), 15-Сен-13, 00:17 
> Дальше-то прочитал?
> ---
>  тем не менее gcc без -fPIC
>  g++ -O2 -m64 cpptest.cpp
>  ./a.out
>  Res = vector2d(-2.65058e+06,5.69089e+06)
>  Total time = 2.29 (sec)
>  Average time = 0.00229 (sec)

Всё равно не дотягивает до Clang:
///---
clang version 3.3 (tags/RELEASE_33/rc3)

Res = vector2d(-2.65058e+06,5.69089e+06)
Total time = 2.2 (sec)
Average time = 0.0022 (sec)
---///

Ответить | Правка | Наверх | Cообщить модератору

121. "Первая альфа-сборка FreeBSD 10.0"  +/–
Сообщение от Аноним (-), 15-Сен-13, 03:07 
> Всё равно не дотягивает до Clang:

Уточним: это clang с большинстве тестов сливает gcc. Хотя разумеется всегда можно выпятить контрпример. Правда работе системы в целом это мало поможет. Заодно еще можно на размер сгнеренного кода посмотреть. GCC в этом плане есть что предложить с его LTO и оптимизацией whole program. Реально круто оптимизирует - я тут как-то видел как бинарь с 6 метров похудел до 4. Нехило так - на треть сдулся. Кроме всего прочего это означает и более частый cache hit, так что скорость тоже в плюсе.

Ответить | Правка | Наверх | Cообщить модератору

140. "Первая альфа-сборка FreeBSD 10.0"  –1 +/–
Сообщение от Aesthetus Animus (ok), 15-Сен-13, 17:52 
> Реально
> круто оптимизирует - я тут как-то видел как бинарь с 6
> метров похудел до 4.

Бинарник 4 метра?! Это что же за проект такой? Оптимизируйте дальше.

> Кроме
> всего прочего это означает и более частый cache hit, так что
> скорость тоже в плюсе.

Ничего это не означает. Уменьшение бинарника не ведет вот так просто
к снижению частоты промахов кеша.

Ответить | Правка | Наверх | Cообщить модератору

155. "Первая альфа-сборка FreeBSD 10.0"  +/–
Сообщение от Аноним (-), 16-Сен-13, 05:10 
> Бинарник 4 метра?! Это что же за проект такой? Оптимизируйте дальше.

Бедный Йорик, никогда не видел здоровенных программ на си++.

> Ничего это не означает. Уменьшение бинарника не ведет вот так просто
> к снижению частоты промахов кеша.

Чем меньше кода, тем он чаще целиком умещается в кэш. Вот так вот просто и банально. Хотя я понимаю что фанатам даже такая примитивная логика недоступна.

Ответить | Правка | Наверх | Cообщить модератору

165. "Первая альфа-сборка FreeBSD 10.0"  –2 +/–
Сообщение от SubGun (ok), 16-Сен-13, 11:03 
> Бедный Йорик, никогда не видел здоровенных программ на си++.

У нормальных людей я тоже не видел таких бинарников. Там что, все в коде, без вынесеных библиотек? o_O

Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

188. "Первая альфа-сборка FreeBSD 10.0"  –1 +/–
Сообщение от Аноним (-), 16-Сен-13, 18:21 
> в коде, без вынесеных библиотек? o_O

Ага. В коде. Без вынесенных библиотек. Выносить библиотеки при том что реюз этого где-то еще ни разу не планируется - маразм и напрасная трата времени и сил. Ну и просто куча гумна по всему диску неизвестно зачем + лишний оверхед и тормоза (гуглить на тему того что LTO делает и почему оно становится быстрее, etc если линковать в 1 файл).

И да, проект сделан совершенно нормально:
- Внешние библы - да, юзаются, там где это имеет смысл.
- Логически проект попилен на отдельные составляющие, etc.

Ответить | Правка | К родителю #165 | Наверх | Cообщить модератору

202. "Первая альфа-сборка FreeBSD 10.0"  –1 +/–
Сообщение от Aesthetus Animus (ok), 17-Сен-13, 00:31 
>(гуглить на тему
> того что LTO делает и почему оно становится быстрее, etc если
> линковать в 1 файл).
> И да, проект сделан совершенно нормально:
> - Внешние библы - да, юзаются, там где это имеет смысл.
> - Логически проект попилен на отдельные составляющие, etc.

Что, Усёр294, молчаливо минусуешь? Ответить по существу не позволяет скудость твоих технических познаний? А раз так, кончай пердеть в лужу! :-D

Да, вопрос я ставлю, не затрагивая FreeBSD, причем тут она? О clang-е, если что, речи тоже не идет (это оставим на десерт, если осилишь). Итак gcc и работа кешей/tlb (процессор оставляю на твой выбор)

Ответить | Правка | К родителю #188 | Наверх | Cообщить модератору

221. "Первая альфа-сборка FreeBSD 10.0"  +1 +/–
Сообщение от Аноним (-), 18-Сен-13, 18:05 
> Что, Усёр294, молчаливо минусуешь?

Нифига себе молчаливо?! Может тут что-то стерли?

> Итак gcc и работа кешей/tlb (процессор оставляю на твой выбор)

Да, давай, цыркач, расскажи мне про
1) Как LTO вообще относится к данным. Я весь внимание. Если ты даже не знаешь что он делает - это отлично, но при чем тут я? Приписывать мне свою глупость - феноменальная наглость.
2) Все-таки изучи уже какой размер кэшей у современных процессоров, а не у твоего артефакта, которым еще прабабушка пользовалась. Потом порассуждай о том как туда не влезет 4 метра кода.
3) Вруби уже головной мозг и представь себе что код таки влез в кэш. И в свете этого расскажи мне о диких удобствах префетчинга. Который будет отдыхать при этом почти все время. Ну так, в идеальном случае.

Ответить | Правка | К родителю #202 | Наверх | Cообщить модератору

230. "Первая альфа-сборка FreeBSD 10.0"  –1 +/–
Сообщение от Aesthetus Animus (ok), 18-Сен-13, 20:57 
> Нифига себе молчаливо?! Может тут что-то стерли?

Не переживай так, поторопился я с претензией.

> Да, давай, цыркач, расскажи мне про
> 1) Как LTO вообще относится к данным. Я весь внимание. Если ты
> даже не знаешь что он делает - это отлично, но при
> чем тут я? Приписывать мне свою глупость - феноменальная наглость.

Если хорошо попросишь, я устрою тебе обзор кода модуля lto в gcc. Насчет того, как оно работает в clang - тут я пас, глубоко туда я не заглядывал.

> 2) Все-таки изучи уже какой размер кэшей у современных процессоров, а не
> у твоего артефакта, которым еще прабабушка пользовалась. Потом порассуждай о том
> как туда не влезет 4 метра кода.

На моем артефакте всего по 32KB L1 icache и dcache, 512KB L2 cache, а L3 и вовсе нет. Вот только это _не_интеловское_ железо.

> 3) Вруби уже головной мозг и представь себе что код таки влез
> в кэш. И в свете этого расскажи мне о диких удобствах
> префетчинга. Который будет отдыхать при этом почти все время. Ну так,
> в идеальном случае.

Ок, включил. Ты, помнится, говорил о L3 cache, который у интеля действительно 8MB, но забыл упомянуть, что L1 и L2 такие же мелкие, по 32KB - L1 и 256K L2. Но есть нюансы, L2 и L3 используются одновременно для инструкций и для данных, в отличие от L1. А теперь твоя очередь включить голову, что произойдет с кешированным в L2/L3 инструкциями, при достаточно интенсивной работе с _данными_?

Ответить | Правка | К родителю #221 | Наверх | Cообщить модератору

169. "Первая альфа-сборка FreeBSD 10.0"  –2 +/–
Сообщение от Aesthetus Animus (ok), 16-Сен-13, 12:40 
>> Бинарник 4 метра?! Это что же за проект такой? Оптимизируйте дальше.
> Бедный Йорик, никогда не видел здоровенных программ на си++.

Еще раз четыре мегабайта - это дохрена. Собственно, что это за проект, который столько использует? Сделать большой бинарник - не проблема, но чтобы сильно распух размер секций кода - надо постараться. Еще раз, вы хорошо себе представляете, что должен делать код, если он занимает несколько мегабайт?!

А теперь скажите какая секция того бинарника уменьшилась в ходе оговоренной оптимизации? Если речь о секции данных, то мимо. От cache miss это не спасет вообще никак - оптимизируйте дальше.

> Чем меньше кода, тем он чаще целиком умещается в кэш.

У вас код занимает несколько мегабайт. В какой кеш Вы предлагает его запихнуть? Покажите мне этот кеш, я хочу его! Ну а далее, формулировка "чаще _целиком_ умещается в кэш" так вообще поражает своей технической грамотностью.

Собственно, а где Вы взяли такую чушь, что какой-либо код должен умещаться в кеш целиком? Это что же, по вашему, если это так, то все отлично и мы спасены от промахов кеша? (Это Вам домашнее задание)

> Вот так
> вот просто и банально. Хотя я понимаю что фанатам даже такая
> примитивная логика недоступна.

В общем случае, бинарник бОльшего размера, с подряд идущими инструкциями, без далеких переходов, выходящих за границу линии кеша, лучше обрабатывается кешем, нежели ужатый донельзя бинарник. Префетчеру гораздо проще подгрузить в кеш подряд несколько линий, идущих друг за другом блоков памяти, нежели поочереди грузить несколько разрозненных линий по каждому cache miss (ага, здравствуй tlb miss!).

Это вам, фанатик, так, небольшая пища к размышлению и ядреный пинок провести  профилирование_ полученного кода, а не сравнивать теплое с мягким.

Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

206. "Первая альфа-сборка FreeBSD 10.0"  +1 +/–
Сообщение от Аноним (-), 17-Сен-13, 03:32 
> хорошо себе представляете, что должен делать код, если он занимает несколько мегабайт?!

Оно реализует туеву хучу замороченной логики, парсинг замороченных протоколов, разбор каких-то эзотерических форматов файлов и уйму всего еще. Да, это - дохрена. Сиплюсплюсники "поймавшие волну" генерят код лучше чем экскаватор грунт ворочает. Бинарь на 4-6 метров для си++'нутых программ обычное дело.

> А теперь скажите какая секция того бинарника уменьшилась в ходе оговоренной оптимизации?

Код, внезапно! LTO при линковке IIRC убивает glue, нужный для экспортирования функций и вызова оных извне. Поэтому линковка кода в 1 большой бинарь, из которого экспорт "внутренних" символов не делается - приносит нехилый выигрыш. И по скорости (вызов функций становится быстрее, особенно если функция дергается часто) и по размеру. К вопросу о том почему не надо плодить библы, если реюз кода не планируется.

> Если речь о секции данных, то мимо. От cache miss это
> не спасет вообще никак - оптимизируйте дальше.

Каким хреном LTO относится к данным? Код сдувается, разумеется. Почему - см выше. Я как-то так не парился, а оказалось - крутая фича, временами дает весьма приятный выигрыш без каких либо усилий. Линковка конечно куда дольше, не отнять. И ресурсов жрет прилично.

> У вас код занимает несколько мегабайт. В какой кеш Вы предлагает его
> запихнуть? Покажите мне этот кеш, я хочу его!

Типовой размер L2/L3 кэшей современных х86 нынче измеряется в *мегабайтах*, с разморозкой вас. А у монстров типа xeon и десятками уже бывает. Ну вот у моего десктопного проца, например, 1024Кб на ядро L2 и 8192Кб общего L3. И да, L3 - таки куда лучше чем DDR3 с его адской латентностью и "где-то там". До мозильщиков вон тоже долшло - они лису с -Os вообще собирают.

> поражает своей технической грамотностью.

Не к чему до..ться - до...сь к формулировкам. Ну или к личности оппонента.

> Собственно, а где Вы взяли такую чушь, что какой-либо код должен умещаться
> в кеш целиком?

Он не "должен", работать будет и без этого. Но если уместится и тасовка кода минимизируется - производительность может прилично подскочить. Правда логично? :)

> Это что же, по вашему, если это так, то все отлично и мы спасены от промахов кеша?

Вопрос в общем то в количестве этих самых промахов. Меньше код - меньше промахов. Попробуй оспорь :). В сферическом случае в вакууме, когда кэша хватило на вообще все и вся - промахов почти не будет. Вот так вот просто и логично.

> (Это Вам домашнее задание)

Ну да, сразу видно бсдшника - пальцы веером. При том что типовой размер кэша современного проца не знает, как и про то что делает LTO.

> В общем случае, бинарник бОльшего размера, с подряд идущими инструкциями, без далеких
> переходов, выходящих за границу линии кеша, лучше обрабатывается кешем,

Если код целиком в кэш не влез - его куски будут дергаться из оперативы по мере промахов, а там латентность уже совершенно конская. А сферический случай в вакууме - это, конечно, круто, но кого это волнует?

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

А еще лучше - если в кэш вгрузится все что используется. Так что промахов в идеальном случае почти не будет. Чем чаще наступает именно этот случай - тем лучше. Вот уменьшение размера кода очень тому способствует.

> нежели поочереди грузить несколько разрозненных
> линий по каждому cache miss (ага, здравствуй tlb miss!).

Вот кэши и делают нынче жиииииирными. Чтобы туда лезло как можно больше. Потому что latancy DDR3 и близко не стоял с кэшатиной.

>  профилирование_ полученного кода, а не сравнивать теплое с мягким.

Приколись, оно покажет то что и должно. В среднем по больнице станет лучше, ясен хрен.

Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

210. "Первая альфа-сборка FreeBSD 10.0"  –3 +/–
Сообщение от Aesthetus Animus (ok), 17-Сен-13, 19:49 
> Код, внезапно! LTO при линковке IIRC убивает glue, нужный для экспортирования функций
> и вызова оных извне.

Отнюдь не это делает lto - с домашним заданием ты не справился. Гуглить gimple!

Что? О каком экспортировании функций ты говоришь?! А ну-ка,
$ nm <бинарник>
$ size <бинарник>
до и после твоей lto оптимизации.

>> Если речь о секции данных, то мимо. От cache miss это
>> не спасет вообще никак - оптимизируйте дальше.
> Каким хреном LTO относится к данным? Код сдувается, разумеется. Почему - см
> выше. Я как-то так не парился, а оказалось - крутая фича,
> временами дает весьма приятный выигрыш без каких либо усилий.

Каким хреном lto относится к данным? Никаким, но должен же я убедиться, что мой оппонент хоть малейшее представление об lto.

Разумеется, дает выигрыш в _размере_кода_. Дает ли (дало ли) какой-то выигрыш в твоем случае? Сомневаюсь. А ты можешь его измерить? Ты, помнится, о cache miss говорил?

> Типовой размер L2/L3 кэшей современных х86 нынче измеряется в *мегабайтах*, с разморозкой

Ой... а я забыл, что есть такой процессор, x86/x86_64...

> Не к чему до..ться - до...сь к формулировкам. Ну или к личности
> оппонента.

Дорогой мой неразумный друг, напомню, et hominem исходило от тебя, буквально в первом же ответе на мое замечание. В том посте, напоминаю, я указал на безграмотность твоих доводов относительно корреляции размера кода и частоты cache miss. Чуть позже я призвал тебя провести профилирование кода (сам то знаешь, как это сделать?), чтобы определить эту частоту. Или ты и дальше будешь сводить все к личностям?

Профилировать твой код я не могу - нет его у меня, и не буду - твой код, ты и профилируй, потому привожу общие соображения относительно оптимизации и указываю на твои заблуждения. (Не отрицаю, может частота cache miss и уменьшилась, но это тем интереснее, так как это side effect, который требует особого внимания) У тебя код есть, но ты, вместо того, чтобы показать мне конкретные результаты, громко кричишь, про разного рода доводы, хотя понятия не имеешь ни о работе cache, ни о работе tlb.

> Он не "должен", работать будет и без этого. Но если уместится и
> тасовка кода минимизируется - производительность может прилично подскочить. Правда логично?
> :)

Тасовка? Это еще один технический термин, применимый в ключе работы кешей? Тасовка чего, с чем, где? Что хотел сказать автор? :-D

>> Это что же, по вашему, если это так, то все отлично и мы спасены от промахов кеша?
> Вопрос в общем то в количестве этих самых промахов. Меньше код -
> меньше промахов. Попробуй оспорь :). В сферическом случае в вакууме, когда
> кэша хватило на вообще все и вся - промахов почти не
> будет. Вот так вот просто и логично.

Кеш все равно меньше общего объема памяти, все равно он многократно вытесняется. О том, что влияет на cache miss ниже и в предыдущих постах.

>> (Это Вам домашнее задание)
> Ну да, сразу видно бсдшника - пальцы веером. При том что типовой
> размер кэша современного проца не знает, как и про то что
> делает LTO.

Сюрприз! Я Linux Kernel программист. Более того, речь я веду только о gcc и linux, чтобы тебе было проще :-)

> Если код целиком в кэш не влез - его куски будут дергаться
> из оперативы по мере промахов, а там латентность уже совершенно конская.
> А сферический случай в вакууме - это, конечно, круто, но кого
> это волнует?

Они (куски) и так будут дергаться. Ну не живет какое-то одно приложение, без соседства с другими. Еще раз, читай что тебе написал: к промахам приводит не излишне большой размер кода, а частые переходы за границы линии кеша. Именно поэтому код, имеющий бОльший размер не обязан увеличивать частоту промахов, важно то, как компилятор организовал work flow.

> А еще лучше - если в кэш вгрузится все что используется. Так
> что промахов в идеальном случае почти не будет. Чем чаще наступает
> именно этот случай - тем лучше. Вот уменьшение размера кода очень
> тому способствует.

Опять ты про tlb забыл :-D

> Приколись, оно покажет то что и должно. В среднем по больнице станет
> лучше, ясен хрен.

Ну? Я жду.

Ответить | Правка | К родителю #206 | Наверх | Cообщить модератору

223. "Первая альфа-сборка FreeBSD 10.0"  +1 +/–
Сообщение от Аноним (-), 18-Сен-13, 18:49 
> $ nm <бинарник>

Без дебажных символов в обоих случаях "no symbols". C дебажными символами ясен перец куча хлама в обоих случаях: nm прочел инфо о адресах из дебага. И? Сюда сие btw не влезет: лимит на объем поста куда меньше.

> $ size <бинарник>

На, скушай, дебажный -O0 vs полный набор, с LTO и прочая. Эксперименты показали что в основном выигрыш по размеру наступает от задействования LTO (-flto -fwhole-program). Остальные оптимизации не больно то и пытаются размер бинаря скостить.


$ size mp-O0 
   text       data        bss        dec        hex    filename
5575972       9264      68464    5653700     5644c4    mp-o0
$ size mp-lto 
   text       data        bss        dec        hex    filename
3695969       5308      73120    3774397     3997bd    mp-lto

Нормально сдулось, да? Основной профит от LTO как раз - остальные оптимизации как-то больше на скорость нацелены а не размер бинаря.

> до и после твоей lto оптимизации.

Оно не "до" и не "после". Это опции линкера, бэть.

> Ну? Я жду.

Да на тебе образчик.

Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

231. "Первая альфа-сборка FreeBSD 10.0"  –1 +/–
Сообщение от Aesthetus Animus (ok), 18-Сен-13, 21:12 
> Без дебажных символов в обоих случаях "no symbols".

Умничка, этого я и хотел увидеть. А теперь скажи, как это связано вот с этим: "LTO при линковке IIRC убивает glue, нужный для экспортирования функций и вызова оных извне"? Я упорно не понимаю, что ты этим хотел сказать. О каком экспорте ты говоришь?

>> $ size <бинарник>
> На, скушай, дебажный -O0 vs полный набор

Так, стоять! Ты что, пытаешься мне впарить сравнение lto и полностью отключенной оптимизации?!

>> Ну? Я жду.
> Да на тебе образчик.

И это все? Тебя научить пользоваться профилировщиком?

Ответить | Правка | К родителю #223 | Наверх | Cообщить модератору

241. "Первая альфа-сборка FreeBSD 10.0"  +/–
Сообщение от Аноним (-), 21-Сен-13, 23:25 
> ты этим хотел сказать. О каком экспорте ты говоришь?

Я наверное криво выразился и частично тупанул по чужому описанию: на самом деле LTO оптимизит программу целиком, в том числе и выбрасывая код который бы позволил бы рассматривать функции как нечто отдельное и самодостаточное.

> Так, стоять! Ты что, пытаешься мне впарить сравнение lto и полностью отключенной оптимизации?!

Ну да, немного считерил. Ок, -O3, отличие только в флагах LTO:
$ size mp-O3
   text       data        bss        dec        hex    filename
4331375      10920      72760    4415055     435e4f    mp-O3

$ size mp-lto
   text       data        bss        dec        hex    filename
3688498       5212      70496    3764206     396fee    mp-lto

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

> И это все? Тебя научить пользоваться профилировщиком?

Я и сам умею. Только в данном случае мне таки лениво, там предсказуемую конфигу собирать, которая от внешних факторов не зависит - это целый тестлаб поднимать надо. Вломак мне столько возиться чисто для того чтобы пальцы на форуме растопырить :).

Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

247. "Первая альфа-сборка FreeBSD 10.0"  –1 +/–
Сообщение от Aesthetus Animus (ok), 22-Сен-13, 01:50 
> Ну да, не так эпично как показалось на первый взгляд, но в
> целом очень даже мило.

Ну вот, цифры не такие уж и радужные, уменьшилось всего на 15 процентов, а не на 30.

> Вломак мне столько возиться

Возиться? Ну я что, прошу тебя сделать чистые эксперименты? Мне достаточно средних по больнице цифр.

man perf
man perf-stat


Ответить | Правка | К родителю #241 | Наверх | Cообщить модератору

177. "Первая альфа-сборка FreeBSD 10.0"  +/–
Сообщение от Aesthetus Animus (ok), 16-Сен-13, 15:14 
>> Бинарник 4 метра?! Это что же за проект такой? Оптимизируйте дальше.
> Бедный Йорик, никогда не видел здоровенных программ на си++.
>> Ничего это не означает. Уменьшение бинарника не ведет вот так просто
>> к снижению частоты промахов кеша.
> Чем меньше кода, тем он чаще целиком умещается в кэш. Вот так
> вот просто и банально. Хотя я понимаю что фанатам даже такая
> примитивная логика недоступна.

А вообще, знакомая манера... с видом эксперта разглагольствовать о вещах, в которых них*я не понимает. Усёр294, опять ты, штоле?

Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

207. "Первая альфа-сборка FreeBSD 10.0"  –1 +/–
Сообщение от Аноним (-), 17-Сен-13, 03:33 
> А вообще, знакомая манера... с видом эксперта разглагольствовать о вещах, в которых
> них*я не понимает.

Действительно, нифига не знать про то что делает LTO и совершенно не раздуплять какой размер кэшей у современных процессоров - это так по вашему :).


Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

211. "Первая альфа-сборка FreeBSD 10.0"  –1 +/–
Сообщение от Aesthetus Animus (ok), 17-Сен-13, 20:04 
> Действительно, нифига не знать про то что делает LTO и совершенно не раздуплять какой размер кэшей у современных процессоров - это так по вашему :).

Усёр294, что за привычка писать писать одно и тоже в нескольких, много раз за пост, да еше и дублируя в нескольких разрозненных постах?

Ну что же, какой вопрос - такой ответ: в сортах (и размерах) x86-го говна разбираться не обязан. Зато я знаю, куда больше о его внутренней архитектуре чем ты, хотя нигде, кроме как на рабочем компе, его не использую и код для него не пишу.

А вот какие у тебя познания (даже по сравнению со мной) относительно lto - ты уже продемонстрировал в соседнем посте. Ты бы сначала разобрался, что такое gcc, как он работает, какие структуры данных в нем используются.

Ответить | Правка | К родителю #207 | Наверх | Cообщить модератору

189. "Первая альфа-сборка FreeBSD 10.0"  –1 +/–
Сообщение от iZEN (ok), 16-Сен-13, 19:07 
>> Всё равно не дотягивает до Clang:
> Уточним: это clang с большинстве тестов сливает gcc.

Ещё точнее (благо, FreeBSD позволяет собрать Chromium из порта тем или иным компилятором) — пройти тест http://octane-benchmark.googlecode.com/svn/latest/index.html

Данные брал по лучшему (самому высокому) результату из пяти запусков теста в каждой сборке Хромиума:

chromium-29.0.1547.65@LLVM/Clang 3.3 Octane Score: 10742
Richards 12769
Deltablue 14632
Crypto 12949
Raytrace 14194
EarleyBoyer 17769
Regexp 2237
Splay 5460
NavierStokes 14855
pdf.js 9584
Mandreel 10938
GB Emulator 17274
CodeLoad 10226
Box2DWeb 12369

chromium-29.0.1547.65@GCC 4.6.3 Octane Score: 10855
Richards 12762
Deltablue 14612
Crypto 13004
Raytrace 15466
EarleyBoyer 13977
Regexp 2242
Splay 5362
NavierStokes 14899
pdf.js 11038
Mandreel Mandreel 11144
GB Emulator 17870
CodeLoad 11156
Box2DWeb 12626

Флаги компиляции GCC (выдернуто из лога компиляции):
===>  Building for chromium-29.0.1547.65
cd /portsobj/usr/ports/www/chromium/work/chromium-29.0.1547.65 && /usr/bin/env TMPDIR="/tmp" BUILDTYPE=Release  GPERF=/usr/local/bin/gperf TMPDIR="/tmp" TMPDIR="/tmp" SHELL=/bin/sh NO_LINT=YES ADDR2LINE="/usr/local/bin/addr2line" AR="/usr/local/bin/ar" AS="/usr/local/bin/as" CPPFILT="/usr/local/bin/c++filt" GPROF="/usr/local/bin/gprof" LD="/usr/local/bin/ld" NM="/usr/local/bin/nm" OBJCOPY="/usr/local/bin/objcopy" OBJDUMP="/usr/local/bin/objdump" RANLIB="/usr/local/bin/ranlib" READELF="/usr/local/bin/readelf" SIZE="/usr/local/bin/size" STRINGS="/usr/local/bin/strings" PREFIX=/usr/local  LOCALBASE=/usr/local  LIBDIR="/usr/lib"  CC="gcc46" CFLAGS="-O2 -pipe -fno-stack-protector -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing"  CPP="cpp46" CPPFLAGS=""  LDFLAGS=" -Wl,-rpath=/usr/local/lib/gcc46"  CXX="g++46" CXXFLAGS="-O2 -pipe -fno-stack-protector -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc46"  MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install  -s -o root -g wheel -m 555"  BSD_INSTALL_LIB="install  -s -o root -g wheel -m 444"  BSD_INSTALL_SCRIPT="install  -o root -g wheel -m 555"  BSD_INSTALL_DATA="install  -o root -g wheel -m 444"  BSD_INSTALL_MAN="install  -o root -g wheel -m 444" /usr/local/bin/ninja   -C out/Release chrome


> Заодно еще можно на размер сгнеренного кода посмотреть. GCC в этом плане
> есть что предложить с его LTO и оптимизацией whole program. Реально
> круто оптимизирует - я тут как-то видел как бинарь с 6
> метров похудел до 4. Нехило так - на треть сдулся. Кроме
> всего прочего это означает и более частый cache hit, так что
> скорость тоже в плюсе.

% ls chrom*
-rw-r--r--  1 root  wheel    35M  4 сен 13:11 chromium-29.0.1547.65.clang33.tbz
-rw-r--r--  1 root  wheel    40M 16 сен 18:34 chromium-29.0.1547.65.gcc463.tbz

Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

199. "Первая альфа-сборка FreeBSD 10.0"  –1 +/–
Сообщение от iZEN (ok), 16-Сен-13, 21:40 
Протестировать Chromium, собранный GCC 4.8.2 к сожалению не удалось — на этапе компиляции компилятор сообщил об ошибке:

[9299/11969] CXX obj/components/autofi...re_common.autofill_message_generator.o
ninja: build stopped: subcommand failed.
*** [do-build] Error code 1

Stop in /usr/ports/www/chromium.
*** [build] Error code 1

Stop in /usr/ports/www/chromium.

Ответить | Правка | Наверх | Cообщить модератору

201. "Первая альфа-сборка FreeBSD 10.0"  –1 +/–
Сообщение от iZEN (ok), 16-Сен-13, 23:49 
Chromium в GCC 4.7.4 тоже не собирается:

In file included from ../../content/renderer/pepper/pepper_truetype_font_linux.cc:9:0:
../../content/public/common/child_process_sandbox_support_linux.h:42:62: error: 'off_t' has not been declared
[9253/11969] CXX obj/chrome/common/common.common_message_generator.o
ninja: build stopped: subcommand failed.
*** [do-build] Error code 1

Stop in /usr/ports/www/chromium.
*** [build] Error code 1

Stop in /usr/ports/www/chromium.

===>>> make failed for www/chromium
===>>> Aborting update

% /usr/local/bin/gcc47 --version
gcc47 (FreeBSD Ports Collection) 4.7.4 20130831 (prerelease)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Ответить | Правка | Наверх | Cообщить модератору

254. "Первая альфа-сборка FreeBSD 10.0"  +/–
Сообщение от Аноним (-), 23-Сен-13, 01:24 
> Chromium в GCC 4.7.4 тоже не собирается:

Так в фрибзде это нормальная ситуация - там вечно что-то факапится при сборке.

Ответить | Правка | К родителю #201 | Наверх | Cообщить модератору

257. "Первая альфа-сборка FreeBSD 10.0"  –1 +/–
Сообщение от iZEN (ok), 23-Сен-13, 13:08 
>> Chromium в GCC 4.7.4 тоже не собирается:
> Так в фрибзде это нормальная ситуация - там вечно что-то факапится при сборке.

Внезапно:
% pkg_info -Ex chromium
chromium-29.0.1547.65

Ответить | Правка | К родителю #254 | Наверх | Cообщить модератору

222. "Первая альфа-сборка FreeBSD 10.0"  +/–
Сообщение от Аноним (-), 18-Сен-13, 18:08 
> chromium-29.0.1547.65@LLVM/Clang 3.3 Octane Score: 10742
> chromium-29.0.1547.65@GCC 4.6.3 Octane Score: 10855

Мм... это шедеврально. Изя сам показывает нам деградацию производительности со шлангом. И рассказывает о проблемах с HTML5 видео. Moar бенчей! Давай, запусти там тот же peacekeeper например.

Ответить | Правка | Наверх | Cообщить модератору

125. "Первая альфа-сборка FreeBSD 10.0"  +1 +/–
Сообщение от pavlinux (ok), 15-Сен-13, 05:37 
> Всё равно не дотягивает до Clang:
> Total time = 2.2 (sec)  

Где у шланга 2-ой знак после запятой???

У g++ Total time = 2.29 (sec)

Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

134. "Первая альфа-сборка FreeBSD 10.0"  +/–
Сообщение от Fomalhaut (?), 15-Сен-13, 14:15 
2.2 = 2.20.
(C) Ваш К.О.
Ответить | Правка | Наверх | Cообщить модератору

135. "Первая альфа-сборка FreeBSD 10.0"  +/–
Сообщение от pavlinux (ok), 15-Сен-13, 14:21 
> 2.2 = 2.20.
> (C) Ваш К.О.

Ипать, каКОй умный, а мы тут дебилы - в одном и том же код заметили исчезновение одной циферки.  

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру