> фиерия глупости.

Да, именно «фИерия».

> фиерия глупости.

О да, наполненный глубоким смыслом комментарий. И главное, своевременный. Если ты не заметил, мне уже всё объяснили.

Кажется я таки собрал эту вундервафлю!

# pathcc -version
Path64 Community Compiler: Version 4.0.10
Built on: 
Thread model: posix
GNU gcc version  (PathScale 4.0.10 driver)

Copyright PathScale Inc.  All Rights Reserved.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

# cat test.cpp 
#include <iostream>

int main()
{
        std::cout << "Hello!!!" << std::endl;
        return 0;
}

# pathcc -lstdc++ test.cpp 

# ./a.out 
Hello!!!

> Теперь надо придумать что с ней делать...

Сравнить скорость генерируемого кода с GCC? :)

> Теперь надо придумать что с ней делать...

Начинай пересобирать Федору.

> Компания PathScale...

А я даже не слышал о такой компании... а она:

от 8% до 270%

Два сакраментальных вопроса: Ядро собирает? Кеды собирает?

Кому что, а соурсникам кеды. А гном?

Очень ждем ебилдов!

А почему сам не соберёшь ебилд?

Ждём deb'ов.

Ждем патчей в GCC.

+1

давай ключики

+1

А вообще народ, вы только на лоре новости читаете, или я просто придираюсь и здесь могло быть over 9000 народу? Не лором единым.

>Теперь надо придумать что с ней делать...

собери чонить из реп простенькое, что на крестах :) до жути интересно

> Теперь надо придумать что с ней делать...

Для начала собрать его же им самим, а затем, например, собрать им gzip, bzip2 и xz и сравнить скорость сжатия и распаковки одних и тех же файлов (например, исходников ядра в tmpfs) архиваторами, скомпиленными gcc и этой «вундервафлей».

плевать - пробовал забанить и матлибы и фортран и ещё что-то
насрать!
не собираецо

ща попробую дуру эту тоже собрать. у тебя с какими флагами в итоге собралось?

а головой подумать!?

Пока обычные люди смотрят затмение - гентушники компилируют компиляторы.

завидуй молча...

ыгы, сумерки скажи еще.

Уже почти все закончилось. Онлайн-трансляция была тут: http://www.youtube.com/google

> Пока обычные люди смотрят затмение

не у всех есть возможность. У нас облачно, ничего не видно.

>Пока обычные люди смотрят затмение - гентушники компилируют компиляторы.

...а тролли спешат оббежать все сайты, чтобы побольше затроллить

да уж, просто потрясно.
на что там смотреть? на комментарии?

>...а тролли спешат оббежать все сайты, чтобы побольше затроллить

а люди людят.

> Теперь надо придумать что с ней делать...

собрать что-то вроде ffmpeg или bzip, и собсно пустить на одной и той же машине gcc-шное и вундервафлевое.

time конечно выложить сюда.

в генту уже прибыл бинарный пакет

[ebuild  N     ] dev-lang/ekopath-bin-4.0.10_pre20110612  34,373 kB

ну так собери им че-нить да покажи как работает, будь уже мужиком.

для того чтоб получить максимальную отдачу нужно перекомпилить все, ядро, все библиотеки... а так впринципе не очень то и нужно

Исходники еще не доступны. Тот код в github это совсем другое и сто лет как было доступно. Подождите официального заявления про исходники.

>Тот код в github это совсем другое
Там то что надо это.

Подождите официального заявления про исходники

вот оно - https://twitter.com/ctopathscale: «github.com/path64 has enough open to build base compiler»

Ссылки

• https://github.com/path64/compiler
• https://github.com/path64/debugger
• https://github.com/pathscale/stdcxx
• https://github.com/pathscale/libcxxrt
• https://github.com/pathscale/libunwind
• https://github.com/pathscale/compiler-rt

gcc vs pathcc vs icc

Погонял немного появившийся сегодня в генте бинарный EKOPath 4.0.10_pre20110612 в сравнении с GCC 4.5.2 и ICC 12.0.4 (из Intel Composer XE 2011.4.191)
Сравнивал на архиваторах gzip v.1.4 и bzip2 v.1.0.6
Процессор AMD Athlon(tm) II X3 445 с частотой 3 GHz
Команды тестов:

time nice -n -20 /path_to_gzip/gzip < linux-2.6.39.tar | pipebench > /dev/null 

time nice -n -20 /path_to_bzip2/bzip2 < linux-2.6.39.tar | pipebench > /dev/null 

Summary:
Piped   92.33 MB in 00h00m15.77s:    5.85 MB/second
real    0m15.776s
user    0m15.703s
sys     0m0.169s

Summary:
Piped   92.33 MB in 00h00m14.61s:    6.31 MB/second
real    0m14.618s
user    0m14.562s
sys     0m0.153s

Summary:
Piped   72.57 MB in 00h01m13.11s: 1016.32 kB/second
real    1m13.121s
user    1m12.994s
sys     0m0.165s

Summary:
Piped   72.57 MB in 00h01m10.82s:    1.02 MB/second

real    1m10.824s
user    1m10.718s
sys     0m0.146s

Summary:
Piped   72.57 MB in 00h01m05.26s:    1.11 MB/second

real    1m5.264s
user    1m5.144s
sys     0m0.162s

вот убийцу CUDA с радостью потыкаем - посмотрим!

Интересные результаты.

-O2

А почему О2, а не O3?

А почему О2, а не O3?

-O3 параметр не однозначный, часто дает даже замедление. К тому же у всех этих компиляторов -O2 идет как нормальный уровень куда включены все стабильные оптимизации.

Кстати для pathcc надо бы поиграться с параметрами оптимизации, там их много, как и в gcc.

> И кстати по ощущениям pathcc более совместим с gcc чем тот же icc

Но он, вроде, и помедленнее icc получается. А на интеловском проце, поди, ещё больше разница была бы.

Но он, вроде, и помедленнее icc получается. А на интеловском проце, поди, ещё больше разница была бы.

Угу, но icc даже gzip собрать не смог, что странно весьма.

Если будет время потом прогоню ещё dcraw и xz. Да и с дополнительными параметрами оптимизации у pathcc надо бы разобраться, а то может оно собрало код вообще без mmx/sse/etc

Ебилды для Gentoo:
http://git.overlays.gentoo.org/gitweb/?p=dev/xarthisius.git;a=commit;h=690207d2

http://gentoo-overlays.zugaina.org/xarthisius/dev-lang.html.en

dev-lang/ekopath-bin, =dev-lang/ekopath-9999, =dev-lang/path64-9999

как собирал?
код кстати меняется на гитхабе...
бинарник поставить не вариант - ибо 64-онли

>* [[ $(gcc-version) != 4.2 ]] && die «To bootstrap Path64 you'll need to use gcc:4.2[vanilla]»;
ппц...

Да, он собирается только GCC 4.2 и только в Debug-билд (не Release).

лол )

да счаз )

[ root@desktop ] driver # ../../bin/table < /var/tmp/portage/dev-lang/path64-9999/work/path64-9999_build/src/driver/OPTIONS.P
Ошибка сегментирования
[ root@desktop ] driver # 

> -O3 параметр не однозначный, часто дает даже замедление.

Увеличение по размеру/памяти - возможно. Но замедление? В любом случае стоит дополнительно проверить O3. А еще неплохо бы делать несколько замеров и показывать минимальное, максимальное и среднее значение, чтобы можно было оценить погрешность измерений. А то если разница между gcc и pathcc - в десятых долях секунды а погрешность - в секундах... Например, у меня разброс между соседними запусками bzip2 около 4%.

PS: очень важно перед тестом не забыть ВЫКЛЮЧИТЬ cpufreq/cpuspeed - это даст прирост по скорости еще на 20% :)

на некотором софте даёт таки замдление

>Но замедление?
Прямое следствие

Увеличение по размеру/памяти

Кэш не резиновый.
Бенчмарки в гугле. Числодробилкам от -O3 хорошо, остальному обычно не очень.

> Прямое следствие

Нет тут следствия. Код большего размера может выполняться быстрее кода меньшего размера. Вместо цикла, выполняющегося 5 раз, можно написать все тело цикла 5 раз подряд, в результате кода станет больше, а работать он будет быстрее, потому что не будет лишних проверок на окончание цикла и инкрементов счетчика, плюс освободится несколько регистров процессора, которые тоже можно использовать для чего-то полезного.

Больше кода - не значит медленнее.

> Бенчмарки в гугле.

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

Cколько, например, будет выполняться вот такой кусок кода:

int main()
{
  int i, j = 0;
  for (i = 0; i < 1000000000; i++)
    if (i+1 > 0)
      j++;
  return j%2;
}

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

main:
        xorl    %eax, %eax
        ret

Так что не надо про бенчмарки в гугле. Или ссылку на конкретный бенчмарк, который можно повторить, или ссылку на официальное заявление разработчиков gcc, в котором они утверждают, что O3 может привести к замедлению. Мои тесты показывают, что -O3 по сравнению с -O2 дает либо такую же, либо большую производительность.

> Числодробилкам от -O3 хорошо, остальному обычно не очень.

Все наоборот. Числодробилки обычно изначально оптимизированы хорошо, и O3 дает там такую же производительность, как O2. А в остальных программах, где девелоперы специально не оптимизировали вызовы, O3 дает выигрыш.

>Код большего размера может выполняться быстрее кода меньшего размера
А может и медленнее. В реальном мире часто встречается второе.
Меньше кода — не значит медленнее.

Бенчмарки в гугле кривые.

http://www.global.phoronix-test-suite.com/index.php?k=profile&u=staalmannen-6...
http://www.global.phoronix-test-suite.com/index.php?k=profile&u=staalmannen-2...
Достаточно прямые? Там видно, что с GCC -O2 бывает заметно быстрее, чем -O3. А бывает и медленнее.
С GCC из результатов с заметной разницей 5 против 3 в пользу -O2.
Повторяемо, не слишком фороникс (но их test-suite).

>Cколько, например, будет выполняться вот такой кусок кода:
И да, мерять скорость в циклах — идиотизм из прошлого века.

Тест запускался по 3 раза каждый, сюда я постил лучший результат. Разброс результатов между запусками не превышал 0.250 секунды так что можете считать результаты вполне достоверными. Естественно в scaling_governor было выставлено performance.
Почему у вас разброс по запускам 4% не понятно, может сдимаемый файл не на tmpfs? И попробуйте выставлять sticky bit на бинарники.

PS Единственно что. Я перепроверил позже параметры оптимизации pathcc, в том числе с помощью утилиты analyze-x86 проскакивавшей тут когда то. Опции -mmmx -msse -msse2 msse3 вообще не изменили код. А вот опция -ipa аналог -ip у icc дала на bzip2 прирост примерно в 5% а gzip с ней не собрался.

PSS Насчет -O3. Вот вы пособирайте разные архиваторы dcraw-ы c -O2 и -03 и проверте сами раз не верите. Еще на acovea погоняйте. В 60% случаев производительность падает, и только в остальный 40% растет но совсем не много, и при этом размер бинарника сильно увеличивается, то есть памяти система собранная с -O3 будет жрать значительно больше.

В любом случае стоит дополнительно проверить O3

Вот возмите и проверте. У меня прогон тех тестов что выше занял 30-40 минут всего, ничего сложного в этом нет.

С чего ты написал этот каммент?

с x86

под 32-бита не собираецо ---->не нужно

Выкинь уже свой pentium ii, и купи нормальный проц.