Прошу дополнить и поправить картину мироздания

ты забавно баттхёртишь

clang
Samples: 20K of event 'cycles', Event count (approx.): 17560088941
  45,57%  flac  libFLAC.so.8.3.0   [.] FLAC__lpc_compute_residual_from_qlp_coefficients
  20,68%  flac  libFLAC.so.8.3.0   [.] FLAC__lpc_compute_autocorrelation
  13,56%  flac  libFLAC.so.8.3.0   [.] find_best_partition_order_
   4,59%  flac  libFLAC.so.8.3.0   [.] FLAC__fixed_compute_best_predictor
   4,05%  flac  libFLAC.so.8.3.0   [.] process_subframe_
   3,18%  flac  libFLAC.so.8.3.0   [.] FLAC__bitwriter_write_rice_signed_block
   2,08%  flac  libFLAC.so.8.3.0   [.] FLAC__MD5Transform
   1,63%  flac  libFLAC.so.8.3.0   [.] process_frame_
   0,79%  flac  libc-2.19.so       [.] __memcpy_sse2_unaligned
   0,72%  flac  flac               [.] format_input
   0,54%  flac  libFLAC.so.8.3.0   [.] FLAC__stream_encoder_process
   0,33%  flac  [kernel.kallsyms]  [k] copy_user_generic_string
   0,31%  flac  libFLAC.so.8.3.0   [.] FLAC__MD5Accumulate
   0,31%  flac  libm-2.19.so       [.] __ieee754_log_sse2
   0,11%  flac  libm-2.19.so       [.] __llround
   0,08%  flac  libc-2.19.so       [.] __GI___mempcpy
   0,04%  flac  [kernel.kallsyms]  [k] __radix_tree_lookup
   0,04%  flac  [kernel.kallsyms]  [k] ktime_get_update_offsets
   0,03%  flac  [kernel.kallsyms]  [k] get_page_from_freelist.isra.88
   0,03%  flac  libFLAC.so.8.3.0   [.] FLAC__bitwriter_write_raw_uint32
   0,03%  flac  [kernel.kallsyms]  [k] truncate_inode_pages_range
   0,03%  flac  [kernel.kallsyms]  [k] ext4_da_get_block_prep
   0,03%  flac  [kernel.kallsyms]  [k] delay_tsc
   0,02%  flac  [kernel.kallsyms]  [k] find_get_entry

gcc
Samples: 23K of event 'cycles', Event count (approx.): 19682521599
  36,23%  flac  libFLAC.so.8.3.0   [.] FLAC__lpc_compute_residual_from_qlp_coefficients
  27,30%  flac  libFLAC.so.8.3.0   [.] find_best_partition_order_.isra.6
  17,44%  flac  libFLAC.so.8.3.0   [.] FLAC__lpc_compute_autocorrelation
   4,85%  flac  libFLAC.so.8.3.0   [.] FLAC__fixed_compute_best_predictor
   2,69%  flac  libFLAC.so.8.3.0   [.] FLAC__bitwriter_write_rice_signed_block
   2,11%  flac  libFLAC.so.8.3.0   [.] FLAC__fixed_compute_residual
   1,87%  flac  libFLAC.so.8.3.0   [.] FLAC__crc16
   1,54%  flac  libFLAC.so.8.3.0   [.] FLAC__MD5Transform
   0,84%  flac  libc-2.19.so       [.] __memcpy_sse2_unaligned
   0,54%  flac  libFLAC.so.8.3.0   [.] FLAC__lpc_window_data
   0,52%  flac  flac               [.] format_input
   0,51%  flac  libFLAC.so.8.3.0   [.] FLAC__stream_encoder_process
   0,39%  flac  libFLAC.so.8.3.0   [.] FLAC__lpc_quantize_coefficients
   0,37%  flac  [kernel.kallsyms]  [k] copy_user_generic_string
   0,33%  flac  libm-2.19.so       [.] __ieee754_log_sse2
   0,28%  flac  libFLAC.so.8.3.0   [.] process_subframe_.isra.11
   0,17%  flac  libFLAC.so.8.3.0   [.] FLAC__MD5Accumulate
   0,14%  flac  libFLAC.so.8.3.0   [.] FLAC__lpc_compute_lp_coefficients
   0,12%  flac  libm-2.19.so       [.] __llround
   0,12%  flac  libc-2.19.so       [.] __GI___mempcpy
   0,10%  flac  libFLAC.so.8.3.0   [.] FLAC__format_entropy_coding_method_partitioned_rice_contents_ensure_size
   0,04%  flac  [kernel.kallsyms]  [k] delay_tsc
   0,03%  flac  [kernel.kallsyms]  [k] ext4_finish_bio
   0,03%  flac  libFLAC.so.8.3.0   [.] process_frame_.isra.14
   0,03%  flac  [kernel.kallsyms]  [k] drop_buffers
   0,03%  flac  [kernel.kallsyms]  [k] get_page_from_freelist.isra.88
   0,03%  flac  [kernel.kallsyms]  [k] block_invalidatepage
   0,02%  flac  [kernel.kallsyms]  [k] __radix_tree_create

http://img0.joyreactor.cc/pics/comment/Twix-Single-наконец-то-твикс-объединил...

ты забавно баттхёртишь

И что ты этим хотел сказать?

Яж тебе сказал - выкатывай perf record - т.е. *.data, а не хрен знает что.

http://rghost.ru/57568604

В мануалах к clang вообще мало упоминания про LLVM. Там говорится про AST. Но AST - это не IR.

AST — это первая стадия компиляции, результат синтаксического разбора твоей программы. Потом программа компилируется в LLVM IR. Потом LLVM транслирует её в код ассемблера для конкретной архитектуры.

Стоит отметить, что хотя LLVM IR может быть полностью переносимым между платформами, IR, получаемый в результате компиляции C, уже привязан к целевой платформе.

LLVM IR может быть полностью переносимым между платформами,

Вранье. Не может. By design.

Я так понимаю IR получается привязанный уже после препроцессора. Из-за всяких там #ifdef __WINDOWS__.

А кроме препроцессора что-нибудь еще делает IR непереносимым?

Я так понимаю IR получается привязанный уже после препроцессора.

Ты опять ни хрена не понял. Как ты умудряешься-то? Сто раз бы уже прочитал бы документацию.

IR привязан к целевой платформе, так как там жестко вшиты:

- размерности типов

- alignments

- интринсики

- аттрибуты ABI (типы вызовов, например)

Вранье. Не может. By design.

Почему не может? Может. Я сам ещё не пробовал писать, но не вижу причин, почему нельзя. Только надо очень внимательно следить за тем, как происходит вызов функций из библиотек, системных функций и чтение из памяти (чтобы избежать проблем с endianness).

Ты опять ни хрена не понял

Это мое перманентное состояние. Несмотря на то, что целыми днями только и делаю что читаю маны)

Я так понимаю IR получается привязанный уже после препроцессора.

Он получается не после препроцессора, а уже после всего компилятора. Это та стадия, которая у GCC глубоко в кишках.

Это мое перманентное состояние.

Так может, что-то в консерватории пора поправить?

Несмотря на то, что целыми днями только и делаю что читаю маны)

Может, пора остановиться, и научиться читать для начала?

- размерности типов

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

- alignments

Я знаю, что Clang жёстко вшивает туда alignment, но разве LLVM не умеет в большинстве случаев выбирать для разных типов данных нужный alignment самостоятельно?

- интринсики

Какие интринсики? LLVM intrisics в коде вызываются как функции.

- аттрибуты ABI (типы вызовов, например)

Это да, но ведь LLVM умеет выбирать атрибуты по умолчанию, так что опять же это играет роль только при вызове функций из внешних библиотек.

Почему не может? Может.

Обоснуй. Или ты тупо в это веруешь, как те дурачки из Google, которые Renderscript пилят?

Я сам ещё не пробовал писать, но не вижу причин, почему нельзя.

Потому, что нельзя полностью очистить IR от alignment-ов. Потому, что нельзя не кастовать указатели к целочисленным типам и обратно (то есть, надо знать размерность указателя). Потому, что sizeof(...) должен раскрываться до IR.

Только надо очень внимательно следить за тем, как происходит вызов функций из библиотек, системных функций и чтение из памяти (чтобы избежать проблем с endianness).

Как бы ты не «следил», а зашить все это в IR придется. Жестко.

Погоди-погоди что-то не сходится. Если IR платформозависимый - значит компилятор должен генерить IR для каждой платформы самостоятельно. Тогда какой вообще от IR прок. Можно сразу фигачить в ассемблер каждой платформы

ОК, это значит, что не надо вызывать никаких внешних функций с типами переменной размерности.

Структуры. Касты (особенно указатели к целым и обратно).

но разве LLVM не умеет в большинстве случаев выбирать для разных типов данных нужный alignment самостоятельно?

Обратно же структуры.

Какие интринсики?

SIMD, например. memcpy и memset всякие. Ну и тому подобное говно.

Если IR платформозависимый - значит компилятор должен генерить IR для каждой платформы самостоятельно.

Этих платформозависимых параметров IR довольно мало, по сравнению с полным описанием платформы. Размерности типов, alignment-ы, набор интринсиков, и все вроде - смотри в clang-е в код lib/Basic/Targets.cpp, на предмет платформозависимой информации.

Тогда какой вообще от IR прок. Можно сразу фигачить в ассемблер каждой платформы

Ну и как ты собираешься «фигачить в ассемблер» без длинной цепочки из разных IR?

gcc устроен точно так же, кстати, там этих IR еще больше чем в Clang+LLVM. Уровень, аналогичный LLVM IR, там называется GIMPLE.

Обоснуй.

Ну хорошо, я согласен, что собственных вещественных доказательств у меня нет.

Или ты тупо в это веруешь, как те дурачки из Google, которые Renderscript пилят?

Да, и ещё как все остальные дурачки. Включая тех, которые пилят LLVM.

Потому, что нельзя полностью очистить IR от alignment-ов.

Почему?

Потому, что нельзя не кастовать указатели к целочисленным типам и обратно (то есть, надо знать размерность указателя).

Ну и не надо их кастовать, надо getelementptr.

Потому, что sizeof(...) должен раскрываться до IR.

Для этого есть приём на основе getelementptr.

Включая тех, которые пилят LLVM.

Те, которые пилят LLVM, их отговаривали и крыли матом.

Почему?

Приведи пример хоть немного сложного кода, полностью отвязанного от этих подробностей.

Ну и не надо их кастовать, надо getelementptr.

Тогда не надо Си пользоваться. Потому что в Си кастовали, кастуют и будут кастовать до морковкиного заговения.

Для этого есть приём на основе getelementptr.

Опять же, с Си и подобными не пройдет - оно нужно на этапе вычисления константных выражений.

Опять же, с Си и подобными не пройдет

Да, это известно, что с Си и подобными это не пройдёт. Я и не предполагал, что это пройдёт с абсолютно любой программой на любом языке. Но я думаю, что если очень постараться написать платформонезависимый IR, то это возможно.

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

Чёт по твоим ссылкам какое-то говно в *.data.

Ты даже забенчить нормально не можешь, нулёвая балаболка. Это делается так:

# CC=gcc CFLAGS="-O3 -march=native -funroll-loops -funroll-all-loops" ./configure --disable-cpplibs --disable-xmms-plugin --disable-ogg --disable-oggtest;make clean;make -j9

# for i in {1..4};do time taskset -c 6 ./src/flac/flac --best 600sec.wav -c &> /dev/null;done |& grep ^real
real    0m3.372s
real    0m3.361s
real    0m3.362s
real    0m3.360s

Мне не нужно в бенчах твоё ио.

Ах да, "-funroll-loops -funroll-all-loops" - дали ещё 15%. Т.е. шланг обоссан в хламину(почти в 2раза). Можно ещё поиграться с ключиками, авось шланг обоссыться в 3раза. При этом в шланга тоже есть ключики анрольные, а вот только они нихрена не дают.

Судя по дизасму твоих со"шек гцц нагинерил псевдовекторизацию в некоторых ветках, а шланг нет. Заюзай -mno-sse2, ибо возможно твоё амд говно. Судя по гуглу это анлоченный кусок говна 5летней давности.

И вобще - ты где-то явно темнишь. Выкати свои таргет - я соберу у себя и гляну.

gcc -### -march=native -E /usr/include/stdlib.h 2>&1 | grep "/usr/libexec/gcc/.*cc1"

А для не-си-подобных языков нужен другой IR.

Ну, LLVM — это довольно универсальный бэкэнд для компиляторов.

Но, конечно, задача генерации платформонезависимого IR — это очень специфическая задача, затачивать языки специально под это большого смысла не имеет.

Зачем тебе тогда LLVM, если ты хочешь из него выкинуть все низкоуровневые возможности?

Так нет же, проблема как раз в том, что Си более высокоуровневой, чем LLVM IR. Поэтому из него IR получается платформозависимый.

Ну, LLVM — это довольно универсальный бэкэнд для компиляторов.

То подмножество IR, которым ты его собрался ограничить, уже совсем ни фига не универсально.

Си более высокоуровневой, чем LLVM IR.

И что? В IR запросто можно увидеть касты указателей к целым и назад там, где в исходном Си ничего такого и близко не было.

Ты в сторону не уходи, безграмотная балаболка. Какой тип у char + char?

Ты в сторону не уходи, безграмотная балаболка. Какой тип у char + char?

А, т.е. ты обосрался. И какой же тип у char + char?

Собственно, что и следовало доказать. Мало того, что кукарекаеющий и нулёвый балабол, дак к тому же ещё и нищий, а как кукарекал. Как кукарекал.

Ты в сторону не уходи, безграмотная балаболка.

Ах да, ничтожество. В чем заключается мой уход в сторону?

Ты выкатил выхлоп perf - я ответил. В чем заключается уход и где тут «прямо»? Ты же мне ответишь?

А так же почему ты не ответил на тему ветки и слился какраз-таки в сторону. Осилишь мне, удотище, найти char + char в ветке? Или обосрёшься, как всегда.

Уйди удотище - ты серишь.

Ты выкатил выхлоп perf

Я ничего не выкатывал.

Я от тебя уже давно требую только одного - ответить за твой сучьий, ламерский базар про char + char. До тех пор, пока ты, сучка, за это не ответишь, ты не имеешь права вонять на какие либо иные темы. Сначала отчитайся по всему, где ты обосрался ранее, прежде чем обсираться по новой.

И какой же тип у char + char?

Нет, сучка, это ты обязан ответить, почему «царь сишки» посмел не знать, какой тип у char + char.

Чёт по твоим ссылкам какое-то говно в *.data

perf report читает символы из твоих библиотек, они не сходятся, потому я и положил свои бинари

/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.1/cc1 -E -quiet /usr/include/stdlib.h "-march=amdfam10" -mmmx -m3dnow -msse -msse2 -msse3 -mno-ssse3 -msse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-sha -mno-pclmul -mpopcnt -mabm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 --param «l1-cache-size=64» --param «l1-cache-line-size=64» --param «l2-cache-size=512» "-mtune=amdfam10" -fstack-protector-strong

Я ничего не выкатывал.

До, до.

Я от тебя уже давно требую только одного

Дак требуй. Мне от этого что? В чем проблема?

Ты лучше вырубай sse2 и пробуй.

без sse2 gcc сильно медленнее

gcc 4.9.1 -march=native -O3 -mno-sse2
real    0m6.665s
real    0m6.665s
real    0m6.666s

gcc 4.9.1 -march=native -O3 -funroll-loops -funroll-all-loops
real    0m4.920s
real    0m4.926s
real    0m4.926s

llvm 3.4.2 -march=native -O3 -flto
real    0m5.156s
real    0m5.157s
real    0m5.157s

4920/5156=0.954 ок gcc теперь чуть быстрее, не в 2 и не в 3 раза

polly 3.4 работает, но не даёт ничего с флагами из мануала:

-Xclang -load -Xclang /home/kozi/polly_build/lib/LLVMPolly.so -mllvm -polly
-mllvm -enable-polly-openmp -lgomp
-mllvm -polly-vectorizer=polly

# CC=gcc CFLAGS="-O3 -march=native  -funroll-loops -funroll-all-loops"
real    0m3.378s
real    0m3.374s
real    0m3.367s
real    0m3.366s

# CC=clang CFLAGS="-O3 -march=native -flto"
real    0m4.909s
real    0m4.893s
real    0m4.856s
real    0m4.856s

4920/5156=0.954 ок gcc теперь чуть быстрее, не в 2 и не в 3 раза

Ок, ок. Почти в 2раза быстрее: 0,693.

polly 3.4 работает, но не даёт ничего с флагами из мануала:

А ты можешь сначала проверять, а потом кукарекать? Я и не сомневался. Опенмп - шланг там опенмп научился?

Запомни раз и навсегда. Шланг говно. Всегда был говном и всегда будет.

Конечно впилить фейковое лто и назвать его лто круто, но обосрались пацаны.

Иди хоть что-то найди, на чем шланг не обосрётся. И да, как там оптимизирует конпелятор под кусок протухшего говна вместо процессора - всем покласть.

и в чём вопрос? хз, но ты почитай книжку «Linkers and loaders» в том числе и про это.

Ты забыл самую главную причину: потому что Эпл!