URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 77828
[ Назад ]

Исходное сообщение
"Компания PathScale открыла код GCC-совместимого набора компи..."

Отправлено opennews , 13-Июн-11 22:11 
Компания PathScale анонсировала (http://www.pathscale.com/ekopath4-open-source-announcement) открытие исходных текстов высокопроизводительного набора компиляторов EKOPath 4 (http://www.pathscale.com/ekopath-compiler-suite), совместимого с GCC и удовлетворяющего требованиям стандарта ISO C99/C++ 2003. Кроме компиляторов С и С++, в комплект также входят: компилятор для языка Fortran 90/95/2003, совместимый с GDB отладчик PathDB, ассемблер PathAS, набор run-time-компонентов и  стандартные библиотеки. Компилятор уже достаточно давно используется в промышленных системах, отвечает индустриальным требованиям к стабильности и надежности, поддерживает большое число дополнительных оптимизаций для платформ Intel 64 и AMD64, включает поддержку технологий Intel MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AMD SSE4A и AVX.

Код проекта открыт под лицензией GPLv3 и доступен (https://github.com/path64/) в GitHub. Бинарные сборки подготовлены для Linux (http://c591116.r16.cf2.rackcdn.com/ekopath/...

URL: http://www.pathscale.com/ekopath4-open-source-announcement
Новость: http://www.opennet.me/opennews/art.shtml?num=30858


Содержание

Сообщения в этом обсуждении
"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 13-Июн-11 22:11 
> удовлетворяющего требованиям стандарта ISO C99/C++ 2003

Верится с трудом. В первый раз слышу о компиляторе, целиком удовлетворяющем требованиям стандарта С++.
Хотя поддержка С99 - довольно вкусная фича. Не то чтобы мне действительно не хватало тех возможностей С99, которые предоставляет gcc, но приятно знать, что в случае необходимости поддержка будет предоставлена)
И, конечно, столь ненавистная многими "вирусная" лицензия GPLv3 - тоже приятный бонус)


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 01:01 
Главное, что настал конец безальтернативности GCC в опенсурс.
Теперь компиляторы начнут появляться как грибы после дождя.

Остальное мелочи.


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено СуперАноним , 14-Июн-11 08:27 
Ой, как бы не понадобилось каждому проекту прикладного СПО по своему компилятору.
Это к тому, что такая ситуация не способствует совместимости.

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 14:56 
> Ой, как бы не понадобилось каждому проекту прикладного СПО по своему компилятору.
> Это к тому, что такая ситуация не способствует совместимости.

Ой, какой ужас!

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

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

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

Огромное количество проектов уже давно пишутся не под C/C++, а под совсем другие языки, с несовместимыми трансляторами. И ничего живут как-то. Вы просто не в курсе.

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


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 14:42 
Угу, это такой конец конечно. Поддерживает полторы архитектуры аж. И конечно же о победах протрубили, но наверняка забыли указать в каких бенчмарках они проиграли в 2 раза, как обычно. Т.е. если скомпилить среднестатистическую прогу - вероятно выигрыш в 2 раза мы не увидим ;). Хотя +1 компилер на выбор - в общем то неплохо, как ни крути.

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 15:25 
Вы видимо не в силах осознать разницу между словосочетаниями
"конец компилятору" и "конец безальтернативности".

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 16:27 
> "конец компилятору" и "конец безальтернативности".

Чтобы стать реальной альтернативой - надо, очевидно, реализовать сравнимый функционал. Ну вот например, thttpd не является альтернативой nginx. Хотя оба как бы httpd. Проблема в том что у nginx найдется функционал, которого у thttpd нет. Поэтому равноценно заменить - не получится.


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 15-Июн-11 14:47 
Если для вас что-то не является альтернативой чему-то - это никак не означает, что у всех такое же положение, как у вас.

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 15-Июн-11 14:54 
> Чтобы стать реальной альтернативой - надо, очевидно, реализовать сравнимый функционал. Ну вот например, thttpd не является альтернативой nginx. Хотя оба как бы httpd. Проблема в том что у nginx найдется функционал, которого у thttpd нет. Поэтому равноценно заменить - не получится.

Кроме того, что вы
не видите разницы между "концом существования" и "концом безальтернативности",
вы еще не видите разницы
между "быть альтернативой" и "быть (одним и тем же)/одинаковым".


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено anonymous , 13-Июн-11 22:14 
Теперь GCC-шникам не отвертеться от запросов "посему мой код дак медленно рабтает". Раньше отмазывались тем что проект сложный и уже все давным давно оптимизировано.

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Anonymouss , 13-Июн-11 22:16 
> "посему мой код дак медленно рабтает"

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


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 14:44 
> Косяки gcc прекрасно видны в ассемблерном выводе, никогда не отвертеться было.

Более того, почему-то любой компилятор по сравнению с нормальным програмером генерит дичайший г0вн0к0д. Если надо локально оптимизнуть некий участок - нормальный ассемблерщик уделает компилятора в разы. На локальном куске, разумеется. На большой программе компилятор может лучше распределять регистры.



"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено aaa , 16-Июн-11 00:46 
Если не трудно, Приведите пример с "разами" vs. gcc-4.6-O3 -march native и т.п. Без сарказма, просто интересно.

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 13-Июн-11 22:18 
Не открой они исходники о них бы так никто и не узнал.

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено devl547 , 13-Июн-11 22:23 
Кому было нужно - знали.

Такие вещи как Open64, Pathscale ENZO, Intel Compiler - это энтерпразный сектор. И компиляторы затачивались в основном под параллелизацию и числодробильню.


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 13-Июн-11 22:30 
Продукты PathScale - это высший пилотаж, смертным о них знать не обязательно, о них знают те, кто компилирует программы для космических проектов, топовых кластеров, военных проектов и атомных станций.

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 13-Июн-11 22:59 
/me снимает лапшу с ушей

Кончайте это бла-бла-бла с придыханием, это лучше подойдет Рейзер-, Ваком- или Эппл-фанбою. Розовых слоников не бывает. Есть продукт, возможно удовлетворяющий некоторому набору требуемых характеристик и скорее всего просасывающий в остальном, а то что оно бороздило Большой театр - это вы менеджероте и хаброте расскажите, им это интересно.


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Mick , 14-Июн-11 00:49 
Ну работал я в свое время (года 4 назад) с PathScale-овским компилятором. На моих задачах он давал 10-15% над gcc. С совместимостью все было лучше, чем у интела, но не 100%-но гладко. Интересная штука, но не ужас-ужас какая интересная.

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 16:39 
> Продукты PathScale - это высший пилотаж, смертным о них знать не обязательно,

Сколько апломба. А по факту, почему-то самым "ынтерпрайзным" и впаривают вечно черт знает что.

> о них знают те, кто компилирует программы для космических проектов, топовых
> кластеров, военных проектов и атомных станций.

Вы просто этих военных наверное не видели. Обычно это наиболее тупые и деревянные из всех возможных кастомеров. Не только отечественные, кстати - они такие везде ;). А что до атомных станций, поговаривают что на Фукусиме кроме всего прочего возможно внесла лепту и система управления, перепутавшая полный слет питания с разрывом трубопровода (правда маленький баг?) и срубившая по этому поводу контур аварийного охлаждения реактора (как мило!). А пока там до персонала в суете дотумкало что клапан аварийной системы охлаждения закрыт - понятное дело, реактору лучше не стало и вообще, времени на разбор ситуации не осталось толком. Атомные станции, говорите? По-моему, пора уже показательные расстрелы вводить. Чтобы поменьше пальцевали и побольше отвечали головой.


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Michael Shigorin , 19-Июн-11 01:25 
> Продукты PathScale - это высший пилотаж, смертным о них знать не обязательно,
> о них знают те, кто компилирует программы для космических проектов, топовых кластеров

То-то покупают мерзостный PGI.


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 13-Июн-11 22:30 
А как у него с cxx0x?

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено xxx , 13-Июн-11 22:43 
>Код проекта открыт под лицензией GPLv3

Однако, как я понимаю прямое заимствование кода в GCC будет невозможным из-за политики фонда?


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 13-Июн-11 22:51 
Наверняка, Столман не включит без передачи кода.

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Sylvia , 13-Июн-11 23:18 
требуется передача прав на код, просто лицензии не достаточно

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Тот_Самый_Анонимус , 14-Июн-11 07:10 
И потом они ругают других за несвободу...

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 21:43 
Ну, как минимум они у других пока свободу не отнимали. Любой инструмент можно использовать во благо или во зло.

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Andrey Mitrofanov , 15-Июн-11 10:14 
> И потом они ругают других за несвободу...

Они уже пользуют свободу, которую им дал фонд. Форк выпускают. Вот пусть его сами и тащат-ментейнят до собственного изумления -- _свобода_.

Какие ещё вопросы к FSF по поводу свободы??


"Компания PathScale открыла код GCC-совместимого набора..."
Отправлено anonymous , 15-Июн-11 10:20 
кто «они»? какой «форк»? O_O

"ткрыла код GCC-совместимо"
Отправлено Andrey Mitrofanov , 15-Июн-11 10:25 
Упс... Десит-на. """EKOPath is a 'fork' of SGI's Pro64х[...]"" http://www.phoronix.com/scan.php?page=news_item&px=OTU2OA

Прошу прощения, обманулся та-а-акой gcc-совместимостью.


"Компания PathScale открыла код GCC-совместимого набора..."
Отправлено anonymous , 13-Июн-11 23:34 
> Однако, как я понимаю прямое заимствование кода в GCC будет невозможным из-за
> политики фонда?

нет, из-за того, что архитектуры компиляторов наверняка разные.


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 13-Июн-11 22:59 
Теперь Линуксы будут еще шутрее. Приятный сюрприз. Может у них еще есть и микроядро Linux-совместимое?

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Sylvia , 13-Июн-11 23:17 
какие хорошие новости.

GPLv3 ? кое-кто уже наверняка мылит веревку и идет вешаться )


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено ВКПб , 13-Июн-11 23:55 
Изя и другие латентные вантузятники?

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Sylvia , 14-Июн-11 00:56 
я скорее имела ввиду товарищей активно вопящих что GCC им не нужен и ядро и базовый юзерспейс своей *BSD они уже почти собрали pcc/clang/ или чем-нибудь еще )

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено dsf , 14-Июн-11 08:33 
гцц не плюет на стандарты, гцц дополняет стандарты. слэнг обеспечивая поддержку гцц-расширений, получается, тоже плюёт на стандарты?

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено СуперАноним , 14-Июн-11 08:38 
А стандарты GNU - это стандарты де факто. Вот большинство разработчиков СПО на них и ориентируются. Ну а желающие собирать "более стандартным" clang пусть пишут патчи.
-std=gnu99

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 12:43 
Кстати, да, pcc/clang могут в смешном положении оказаться.

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено _yurkis_ , 14-Июн-11 13:52 
>я скорее имела ввиду товарищей активно вопящих что GCC им не нужен и ядро и базовый юзерспейс своей *BSD они уже почти собрали pcc/clang/ или чем-нибудь еще )

1. С открытием исходников PathScale GCC не стал более нужным.
2. С открытием исходников PathScale clang/pcc не стали хуже
3. С открытием исходников PathScale 99% дистрибутивов линукса все так же буду собирать ядро и мир GCC.
4. Патчи из PathScale с большой долей верноятности не попадут в GCC либо в силу архитектурных отличий либо "не кошерно".
5. Интересно посмотреть PathScale vs pcc не на числодробилках.

Так с чего бы веревку мылить? Хотят хлопцы иметь в базовой ситеме компилятор под СОВМЕСТИМОЙ лицензией. clang и pcc вполне себе достойный проекты. А Вы говорите как будто это что-то плохое.


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 17-Июн-11 01:06 
Если вам такое мерещится, фанатьё именно вы :))

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено pavlinux , 14-Июн-11 00:59 
Intel C/C++

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Sylvia , 14-Июн-11 01:01 
эти навряд ли ;) у них своя ниша, хотя пусть тоже может подумают чтобы что-нибудь открыть

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 14:48 
> подумают чтобы что-нибудь открыть

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


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено anonymous , 14-Июн-11 15:54 
>нивелируется тем что оно гадит процессорам амд

Это как?


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 17:02 
> Это как?

Одно время тут был разбор полетов: интел уличили в неиспользовании новых SSE команд (которые есть в амдшных процах) при работе на амдшных процах. А на интеле - использовались. В memcpy, чтоли. Легко победить на стометровке! Особенно если сопернику привязать к ноге пушечное ядро. Что интел и заимплеметил.


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 13-Июн-11 23:43 
Supported Platforms
Stable:
Novell, Red Hat, Oracle, Ubuntu, FreeBSD
Beta:
Windows, Mac
Страно както Ubuntu есть а Debian куда делся?

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Stax , 14-Июн-11 02:34 
А вы задумайтесь, почему например Red Hat есть, а Fedora нет?

Да просто тут все - это список дистрибутивов, предлагающих серверные решения уровня enterprise, с сертификацией и поддержкой. Поэтому попадают Red Hat и Oracle, но не Fedora. Debian ведь не предлагает никаких серверных решения с гарантиями - а Ubuntu Server таковым является: существует поддержка от производителя, программы сертификации и прочее.

(как тут оказался FreeBSD, не берусь сказать..)


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Rush , 14-Июн-11 03:03 
> Debian ведь не предлагает никаких серверных решения с
> гарантиями - а Ubuntu Server таковым является: существует поддержка от производителя,
> программы сертификации и прочее.

Извините, что не в тему, зато про Ubuntu:

У нас десятки серверов под Ubuntu Server, используем только LTS (8.04, 10.04). Несколько серверов используют технологию LXC. И что вы думаете произошло недавно? Прилетело обновление 2.6.32-32, поломавшее поддержку Network Namespace в LXC!!! Это нарушение всех принципов, ломать ABI внутри релиза, да ещё и LTS. Canonical предложили обновить ведро до linux-image-server-lts-backport-maverick - ок, конечно это не совсем то, что ожидалось, но хотя бы что то. Но тут же выяснилось, что самые свежие обновления утилит LXC с бекпортом не дружат! Хорошо, что мы поддерживаем собственный репозиторий (спеллчекер предложил заменить на "суппозиторий" что кагбэ намекает), и нам не составило труда сделать бекпорт утилит из более поздних (не LTS!!!) выпусков. Короче это бред какой то... Вот вам и "серверные решения уровня enterprise, с сертификацией и поддержкой". Я понимаю, что этим сообщением поднасрал любимому дистру (он у нас и на воркстейшнах, у меня и на всём где можно дома), но возможно кому то это сообщение окажется полезным.


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Rush , 14-Июн-11 03:13 
Вдогонку, чтобы было понятно откуда негодование:

За ночь (часы наименьшей нагрузки) нужно было перевезти десяток серверов. Контейнеры благополучно перелезли по сети на хост-машины в новом датацентре, а после установки перевезёных в эту ночь серверов отказались перелезать обратно. Время поджимает, скоро нагрузка даст о себе знать, а тут такая засада - попробуй догадаться, что как раз после включения хост-машин поднялось то злополучно обновлённое ядро 2.6.32-32, а потом всё это ещё и устаканить после бессонной ночи.


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Stax , 14-Июн-11 07:58 
Ну вы же должны понимать :)
Есть разница между декларированием поддержки и некоторых гарантий (кстати, возможно, гарантии предоставляются только тем, кто купил поддержку?) и реальным уровнем поддержки.

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

Просто есть разница между реальной жизнью и формальными заявлениями. В реальной жизни, например, Debian Stable на сервере может оказаться надежнее и менее проблематичным, чем Ubuntu Server со всеми гарантиями последнего и при работе на сервере, сертифицированном под убунту. Но тем не менее производитель будет поддерживать убунту в первую очередь - есть гарантия, есть ответственные люди, доступна поддержка - в отличие от дебиана, где с разработчиков взятки гладки - как вышло, так и работает. Корелляция между гарантиями и реальной стабильностью обыычно есть, но не всегда :)

А что до реальной ситуации, то сейчас, конечно, нужно брать редхат, если требуется стабильность. Кстати, нормальные LXC там будут; пока есть как technology preview, т.е. без гарантий. Но это не означает, что у разработчиков ubuntu server руки кривые и т.д... просто сколько лет редхат в этом бизнесе и сколько убунта?.. Да и штат разработчиков и тестеров с бюджетом у редхата о-го-го будет, убунта за свой сервер явно и десятой доли этого не получает. Со временем, думаю, и убунта сервер станет весьма пристойным продуктом, соответствующим своим заявлениям. Просто пока рано еще.


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Rush , 14-Июн-11 10:50 
> Ну вы же должны понимать :)

Я всё понимаю, но поплакаться в жилетку таки хотелось :)


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 21:48 
> Я всё понимаю, но поплакаться в жилетку таки хотелось :)

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


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Rush , 15-Июн-11 12:40 
>> Я всё понимаю, но поплакаться в жилетку таки хотелось :)
> Нормальные админы до того как рубить с плеча, тестируют вещи типа перемещения
> машин и обновлений на небольшой тестовом окружении. Если все прошло гладко
> - ок, делается на основном. А вы сами себе злобный буратино.
> Каноникал конечно облажались, но вы ничем не лучше.

Админ - теоретек? Если внимательно читали, половина машин в предыдущую ночь переехала удачно.


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено crypt , 15-Июн-11 12:14 
Правильно сделал. Описал подробно, что за косяк и с чем вышел. Мы теперь знать будем, как бывает.

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Клыкастый , 17-Июн-11 12:39 
какая печальная история. сервер на убунте шовышовынивжисть.

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 00:06 
"будут ещё шустрее"?
Он, ведь, "компилирует быстрее", а не "полученные файлы работают быстрее".

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено ВКПб , 14-Июн-11 00:08 
http://www.phoronix.com/scan.php?page=article&item=pathscale...

Садись на диету.


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено ВКПб , 14-Июн-11 00:11 
Если он GCC совместимый как им подменить GCC?

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено anonymous , 14-Июн-11 00:26 
погоди, проприетарщики "медленно разворачивают корабль в сторону опенсорса", дня через два будут актуальные исходники, потом хлынет волна патчей от сообщества, потом уже и нормальная замена gcc. Пока доступны бинарники и то полуработающие.

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено ВКПб , 14-Июн-11 00:43 
Собрал xz с ним, получилось медленнее на 3%, чем с gcc 4.4.3. Опции дефолтные

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 21:49 
> Собрал xz с ним, получилось медленнее на 3%, чем с gcc 4.4.3.
> Опции дефолтные

Ну просто бравые проприетарные перцы как обычно упомянули только о своих сильных сторонах. Забыв упомянуть остальные.


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Клыкастый , 17-Июн-11 12:40 
> Собрал xz с ним, получилось медленнее на 3%, чем с gcc 4.4.3.
> Опции дефолтные

давай подробнее медленнее собиралось или медленнее выполняется? размер получившегося кода? интересно таки!


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено klalafuda , 14-Июн-11 00:21 
Say RMS gb? :) Солнце всходит и заходит и - зашло. GCC больше не уникален. Теперь окончательно :)

На самом деле, теперь по логике вещей ключевым и сопряженным проектам fsf нужно асап вносить в код как можно больше гнусизмов и пр. мелких радостей. Под любой ширмой. Чтобы все-таки альтернативы альтернативами но без gcc - никуда. Как кому-то без винды. Ибо что там осталось то полезного без всеми нами любимого (без сарказма) gcc? Ничего :)


"Компания PathScale открыла код GCC-совместимого набора..."
Отправлено anonymous , 14-Июн-11 00:31 
> Say RMS gb? :) Солнце всходит и заходит и - зашло. GCC
> больше не уникален. Теперь окончательно :)

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


"Компания PathScale открыла код GCC-совместимого набора..."
Отправлено klalafuda , 14-Июн-11 00:43 
> хочу увидеть сабжевый компилятор для ia-32. а также для (тут перечисление архитектур, поддерживаемых gcc). так что пока уникален. и надолго, думаю.

Если есть реальная для x86_64 причем не столько C сколько C++ со всеми хотя бы низкоуровневыми примамбасами типа stl/boost/ACE/etc - это уже большой и жирный гвоздь в крышку гроба :)

Не сомневаюсь, что ia32 все ещё актуальна в своих секторах. Но куда более актуальна AMD64. И чем дальше тем больше. Найти сегодня сугубо 32х разрядный интел - это ещё поискать нужно. Корки и те давно уже своё отживают. Хороший был зверь. О чем тогда разговор? Про сервера молчу - какой там нафик ia32? Даже не смешно. Но, повторюсь, верю, кому-то актуально. Так что и спорить не буду.


"Компания PathScale открыла код GCC-совместимого набора..."
Отправлено anonymous , 14-Июн-11 00:49 
лично меня 64 бита не волнуют. и ещё много лет волновать не будут. так что для меня этот компилятор совершенно бесполезен. увы.

"Компания PathScale открыла код GCC-совместимого набора..."
Отправлено Аноним , 14-Июн-11 06:41 
Должны волновать не биты, а дополнительные регистры в x86_64.

"Компания PathScale открыла код GCC-совместимого набора..."
Отправлено anonymous , 14-Июн-11 06:45 
> Должны волновать не биты, а дополнительные регистры в x86_64.

а меня и регистры не волнуют, потому что я не собираюсь это всё использовать. x86 давно помер и очень противно воняет.


"Компания PathScale открыла код GCC-совместимого набора..."
Отправлено Аноним , 14-Июн-11 21:51 
> лично меня 64 бита не волнуют. и ещё много лет волновать не
> будут. так что для меня этот компилятор совершенно бесполезен. увы.

А 32-битный х86 уже по сути умер - нынче 4 Гб и более совершенно обыденное дело. IA32? Это прошлый век. В 21 веке как максимум 32-битным имеет право быть какой-нибудь маложручий арм в телефоне.


"Компания PathScale открыла код GCC-совместимого набора..."
Отправлено anonymous , 14-Июн-11 21:59 
> А 32-битный х86 уже по сути умер - нынче 4 Гб и
> более совершенно обыденное дело. IA32? Это прошлый век. В 21 веке
> как максимум 32-битным имеет право быть какой-нибудь маложручий арм в телефоне.

твоё бесценное мнение очень важно для меня.


"Компания PathScale открыла код GCC-совместимого набора..."
Отправлено Аноним , 14-Июн-11 23:11 
Капитан напоминает, что PAE давным-давно позволяет не только 4 Гб и более, но даже 64 Гб. Впрочем, некоторые материнки до сих пор не поддерживают 4 Гб оперативы. Включая, что смешно, те, которые поддерживают только 64хбитные процессоры. Советую Вам, как человеку несомненно нуждающемуся в более 4Гб оперативной памяти, проверить свою материнку)

"Компания PathScale открыла код GCC-совместимого набора..."
Отправлено Клыкастый , 17-Июн-11 12:44 
> А 32-битный х86 уже по сути умер - нынче 4 Гб и более совершенно обыденное дело.

прочти про PAE.

А Когда прочтёшь вернись и расскажи нам о преимуществах 64 бит и о том, ради чего ты собираешься закрывать глаза на недостатки.



"Компания PathScale открыла код GCC-совместимого набора..."
Отправлено Sylvia , 14-Июн-11 00:49 
сабжевый компилятор поддерживает x86_32

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


"Компания PathScale открыла код GCC-совместимого набора..."
Отправлено anonymous , 14-Июн-11 00:50 
> сабжевый компилятор поддерживает x86_32

пока что дали только 64 бита. вот дадут сборку на 32 -- посмотрим, как оно справляется.


"Компания PathScale открыла код GCC-совместимого набора..."
Отправлено pavlinux , 14-Июн-11 01:04 
> ... тут перечисление архитектур, поддерживаемых gcc ...

Увы, но архитектуры умирают быстрее GCC :)  



"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 00:45 
Да они никак и не претендуют на роль замени GCC, люди решили поменять модель бизнеса растивая побольше заработать... желаю им успеха, нам от етого толька лучше будет.  Даеш больше компиляторов, хороших и разных.

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено pavlinux , 14-Июн-11 01:14 
Вот клёвая приблуда (была, два года без апдейтов), для перебора вариантов флагов компиляции,
компиляция, и сравнение результатов, (гентушники должны кончить в этом месте). :)

http://sourceforge.net/projects/pathscale-ici/

This is an Interactive Compilation Interface (ICI) to access and modify internal
PathScale compiler optimization decisions to tune applications at fine-grain
level for performance, size, power consumption, architecture-compiler DSE, etc.



"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Sylvia , 14-Июн-11 03:02 
acovea давно уже есть и гентушники давно уже на нее забили, как и почти все остальные впрочем тоже

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 02:05 
А MPlayer получица им собрать???

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Stax , 14-Июн-11 02:38 
> А MPlayer получица им собрать???

Вы не получите большого выйгрыша - все части, где профайлер показывал, что есть смысл ускорять уже переписаны на ассемблере руками. Т.е. компилятор C на них не влияет, а от ускорения остального эффекта почти не будет. Посмотрите те же форониксовские тесты, у ffmpeg зависимость от компилятора минимальная.

Хотя если вы используете какой-то редкий фильтр и он не оптимизирован, то эффект может быть. Особенно если в компиляторе есть хороший автовекторизатор - в gcc он не очень, да и глючит, поэтому ffmpeg / mplayer его вообще отключают - пользы нет, а баги появляются.


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 02:05 
сабжевый компилятор не поддерживает ARM, так что сугубо нишевая штука

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Sylvia , 14-Июн-11 03:02 
> сабжевый компилятор не поддерживает ARM, так что сугубо нишевая штука

поддерживает.

Supported architectures are:

    x86_32
    x86_64
    mips_32
    mips_64
    rsk6_32
    rsk6_64
    arm


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Sylvia , 22-Июн-11 20:11 
впрочем как выяснилось не поддерживают, оно пытается собраться, но не собирается,
ждут патчей от коммьюнити )

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Кодир , 14-Июн-11 10:23 
Что смешно, оба мира - PathScale и FOSS ну никак не пересекаются! Вопрос: зачем эти заигрывания? Те, кто писал под промышленные системы, тому исходники PS не нужны - он просто пишет свои прошивки. А опенсорсу не нужна абсолютно гетерогенная система PS, т.к. заимствования кода тут минимальные. Ну, разве что заменят ГЦЦ на ПС, но для этого придётся ПС заточить подо все костыли ГЦЦ! Причём это будет уже третий компилер, разрывающий общие усилия разрабов. ЗАЧЕМ?

"Компания PathScale открыла код GCC-совместимого набора..."
Отправлено anonymous , 14-Июн-11 10:30 
> третий компилер, разрывающий общие усилия разрабов. ЗАЧЕМ?

не разрывайся, кто ж тебя заставляет? или ты считаешь, что сейчас весь народ бросит пилить gcc, llvm/clang, pcc и так далее, и вместо этого дружно ломанётся пилить новое?

открытый качественный компилятор, да ещё под GPL — это хорошо.

или по-твоему, надо позакрывать все проекты, у которых уже есть аналоги, и оставить один Самый Главный Проект? проспись, что ли.


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Андрей , 14-Июн-11 22:47 
> ЗАЧЕМ?

Ну, в последнее время дружно всех ломают. А код, сгенерированный этим компилятором, якобы, в серьёзных проектах применяется. А кто как ни широкая общественность может подтвердить, ну или точне не обнаружить ляпсусов по безопасности генерируемого кода? И таким образом они повысят доверие в "свой" продукт.


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 10:23 
GPLv3 - это win!

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 12:13 
Про ARM ни слова. И эти робяты претендуют на энтерпрайзность?

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено xanten , 14-Июн-11 12:31 
А компиляция С++ шаблона класса из отдельного файла у них реализована?

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено brother anon , 14-Июн-11 17:38 
Кому это надо? Template export практически никакой компилятор не поддерживает, поэтому использовать эту фичу — такой же vendor lock-in как GCC-измы.

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено lucentcode , 14-Июн-11 19:00 
Годная новость... Ещё один свободный набор компиляторов не помешает. Да и уровень оптимизаций у него впечатляет. Думаю, что это событие повлияет на развитие и GCC с LLVM. От конкуренции всем профит будет.

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено yakovm , 14-Июн-11 19:17 
К сожалению, это действительно нишевый продукт. Поддерживаются только x86-64 и MIPS (желающие могут почитать документацию на сайте). Кроме того, GCC уже практически поддерживает C++0x, а этот - нет, и далеко не факт, что его внутренняя структура позволяет легко такую поддержку добавить.

Думаю, они его открыли, чтобы уменьшить стоимость разработки. Поддерживать разработку качественного полномасштабного компилятора C++ в одно рыло - сейчас очень дорогое удовольствие. И в этом смысле GPL - самое правильное решение: BSD/MIT обладают многими достоинствами, но стимуляция к разделению стоимости разработки к ним не отностися. Это, кстати, почему clang, скорее всего, не имеет перспектив.

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


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 14-Июн-11 21:54 
> Это, кстати, почему clang, скорее всего, не имеет перспектив.

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


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 15-Июн-11 01:33 
Что-то я сомневаюсь что мотивом открытия послужило желание сэкономить на разработке. Посмотрел цени на их сайте, вряд ли они испытывают проблемы с деньгами...

Кстати у них там имеется еще PathScale® ENZO он остался закрытым ведь да?


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено megabaks , 15-Июн-11 02:56 
да когда же уже выложат полные сорсы!?
задолбали - не собираецо оно из гита!
ненависть!

"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 15-Июн-11 07:43 
> да когда же уже выложат полные сорсы!?
> задолбали - не собираецо оно из гита!
> ненависть!

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


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 15-Июн-11 04:05 
Мда у меня тоже не собираеца, шо за ерунда такая...

[  1%] Built target iberty
[  1%] Built target decnumber
[  1%] Built target cpp
[  1%] Built target spin-x8664
[  1%] Built target gspin-x8664
[  2%] Built target genoptions
[  2%] Built target gencheck
[  2%] Built target gengtype
[  2%] Built target genmodes
[  2%] Built target gen
[  2%] Built target genopinit
[  2%] Built target genpreds
[  3%] Built target gcov_iov
[  3%] Built target genflags
[  3%] Built target genattrtab
[  3%] Built target genoutput
[  3%] Built target genautomata
[  3%] Built target genattr
[  3%] Built target genextract
[  3%] Built target gengenrtl
[  3%] Built target genconfig
[  3%] Built target genemit
[  3%] Built target genpeep
[  3%] Built target genrecog
[  3%] Built target genconditions
[  3%] Built target genconstants
[  3%] Built target gencondmd
[  3%] Built target gencodes
[  7%] Built target backend-x8664
[  7%] Built target cc142-x8664
[  8%] Built target cc1plus42-x8664
[  8%] Built target crtbegin-x86_64
[  8%] Built target crtbeginS-x86_64
[  8%] Built target crtend-x86_64
[  8%] Built target crtendS-x86_64
[  8%] Built target table
[  8%] Built target driver_gen_sources
[  9%] Built target pathcc
[  9%] Built target pathcc_deb
[ 10%] Built target pathcc_rpm
[ 10%] Built target pathcc_sle10
[ 10%] Built target stageit-driver
[ 10%] Built target cif
[ 10%] Built target cmplrs
[ 10%] Built target tag_tree_build
[ 10%] Built target tag_attr_build
[ 11%] Built target dwarf-x8664
[ 12%] Built target elf
[ 13%] Built target elfutil
[ 13%] Built target rtkutils
[ 13%] Built target gensyn
[ 13%] Built target gen_util-x8664
[ 13%] Built target isa_gen-x8664
[ 13%] Built target isa_gen_topcode-x8664
[ 13%] Built target isa_subset_gen-x8664
[ 13%] Built target targ_isa_subset-x8664
[ 13%] Built target isa_registers_gen-x8664
[ 13%] Built target targ_isa_registers-x8664
[ 13%] Built target abi_properties_gen-x8664
[ 13%] Built target isa_properties_gen-x8664
[ 13%] Built target targ_isa_properties-x8664
[ 13%] Built target isa_enums_gen-x8664
[ 13%] Built target targ_isa_enums-x8664
[ 13%] Built target isa_lits_gen-x8664
[ 13%] Built target targ_isa_lits-x8664
[ 13%] Built target isa_operands_gen-x8664
[ 13%] Built target targ_isa_operands-x8664
[ 13%] Built target si_gen-x8664
[ 13%] Built target barcelona_si_gen
[ 13%] Built target barcelona
[ 13%] Built target core_si_gen
[ 13%] Built target core
[ 13%] Built target em64t_si_gen
[ 13%] Built target em64t
[ 13%] Built target proc_gen-x8664
[ 13%] Built target targ_proc-x8664
[ 13%] Built target isa_pack_gen-x8664
[ 13%] Built target targ_isa_pack-x8664
[ 13%] Built target isa_bundle_gen-x8664
[ 13%] Built target targ_isa_bundle-x8664
[ 13%] Built target isa_decode_gen-x8664
[ 13%] Built target isa_hazards_gen-x8664
[ 13%] Built target isa_print_gen-x8664
[ 13%] Built target isa_pseudo_gen-x8664
[ 13%] Built target opteron_si_gen
[ 13%] Built target opteron
[ 13%] Built target proc_properties_gen-x8664
[ 13%] Built target sandy_si_gen
[ 13%] Built target sandy
[ 13%] Built target targ_abi_properties-x8664
[ 14%] Built target targ_isa_decode-x8664
[ 14%] Built target targ_isa_hazards-x8664
[ 14%] Built target targ_isa_print-x8664
[ 14%] Built target targ_isa_pseudo-x8664
[ 14%] Built target targ_proc_properties-x8664
[ 15%] Built target targinfo-x8664
[ 15%] Built target wolfdale_si_gen
[ 15%] Built target wolfdale
[ 15%] Built target comutil-host
[ 16%] Built target comutil-x8664
[ 16%] Built target gen_x_list
[ 16%] Built target gen_x_prop
[ 16%] Built target gen_x_set
[ 16%] Built target generate_preg_list
[ 16%] Built target generate_topcode
[ 18%] Built target wopt-x8664
[ 21%] Built target be-static-x8664
[ 24%] Built target cg-x8664
[ 24%] Built target be-exec-x8664
[ 26%] Built target be-x8664
[ 27%] Built target ipl-x8664
[ 29%] Built target lno-x8664
[ 30%] Built target wopt-shared-x8664
[ 31%] Built target whirl2c-x8664
[ 31%] Built target whirl2f-x8664
[ 32%] Built target prompf_anl-x8664
[ 32%] Built target headers-stage
[ 33%] Built target bfd
[ 33%] Built target ld
[ 33%] Built target stageit-ipa_link
[ 33%] Built target ipl-symlinks
[ 33%] Built target be-all
[ 33%] Built target wgen42-x8664
[ 34%] Built target inline-x8664
[ 35%] Built target ipa-x8664
[ 35%] Built target compiler-stage
[ 35%] Built target compiler-stage-C
[ 35%] Generating pscrt-static-x86_64/memcpy_em64t_c.o
Signal: Segmentation fault in Global Optimization -- LPRE: CO Var save/reload phase.                                                                                        
Error: Signal Segmentation fault in phase Global Optimization -- LPRE: CO Var save/reload -- processing aborted
*** Internal stack backtrace:
    ~/compiler/build/lib/4.0.10/x8664/be() [0x86c271]
    ~/compiler/build/lib/4.0.10/x8664/be() [0x86c970]
    ~/compiler/build/lib/4.0.10/x8664/be(ErrMsgLine+0x8e) [0x86c74e]
    ~/compiler/build/lib/4.0.10/x8664/be() [0x86de62]
    /lib/x86_64-linux-gnu/libc.so.6(+0x33cc0) [0x2b65cd5adcc0]
    ~/compiler/build/lib/4.0.10/x8664/be(_ZN3CSE13Do_cse_pass_2Ev+0x808) [0x78a418]
    ~/compiler/build/lib/4.0.10/x8664/be(_ZN11EXP_WORKLST20Generate_save_reloadEP6ETABLE+0x60) [0x78a810]
    ~/compiler/build/lib/4.0.10/x8664/be(_ZN6ETABLE25Perform_LPRE_optimizationEv+0x3ed) [0x7f4ebd]
    ~/compiler/build/lib/4.0.10/x8664/be(_ZN9COMP_UNIT11Do_load_preEii+0xfb) [0x7f52db]
    ~/compiler/build/lib/4.0.10/x8664/be(Pre_Optimizer+0x29ce) [0x7f90de]
    ~/compiler/build/lib/4.0.10/x8664/be(Perform_Global_Optimization+0xaa) [0x85065a]
    ~/compiler/build/lib/4.0.10/x8664/be() [0x4a8022]
    ~/compiler/build/lib/4.0.10/x8664/be(main+0x748) [0x4a16b8]
    /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xff) [0x2b65cd598e1f]
    ~/compiler/build/lib/4.0.10/x8664/be() [0x4a5e3d]
pathcc INTERNAL ERROR: ~/compiler/build/lib/4.0.10/x8664/be died due to signal 4
make[2]: *** [src/libpscrt/pscrt-static-x86_64/memcpy_em64t_c.o] Error 1
make[1]: *** [src/libpscrt/CMakeFiles/pscrt-static-x86_64.dir/all] Error 2
make: *** [all] Error 2


"Компания PathScale открыла код GCC-совместимого набора компи..."
Отправлено Аноним , 15-Июн-11 06:07 
> Error: Signal Segmentation fault in phase Global Optimization -- LPRE:

OMG! Bugz!


"Компания PathScale открыла под лицензией GPL высокопроизводи..."
Отправлено Аноним , 15-Июн-11 22:08 
Вот зараза какая https://github.com/path64/compiler/issues/6#issuecomment-137...

Release build with gcc isn't supported - Do a Debug build, but more
importantly gcc-4.2 is a *hard* dependency for building.

Чем его ещо можна скомпилить если у него тажая жосткая зависимость к gcc-4.2 ?


"Компания PathScale открыла под лицензией GPL высокопроизводи..."
Отправлено lucentcode , 05-Окт-11 23:51 
Это подстегнёт разрабов GCC тоже шевелится быстрее. А обмен идеями и кодом тоже подстегнут развитие как GCC, так и    EKOPath 4