> Код получается быстрее гцц и уж темболее силэнга.

Пока что быстрее он получается только у разработчиков компилятора. У остальных он даже не компилируется.

Интересно сравнение с оптимизирующими компиляторами Intel C++, Fortran

По слухам на спеках icc лучше, что пожалуй неудивительно.

Наверное у EKOPath дела совсем плохи были.

> Интересно, сколько в нем кода gcc.

в open64 был фронтэнд от gcc + бекенд от SGI, доработанный.

> Не осилили C++0x, поэтому решили заимплементить за счет сообщества.

а кто осилил?

Александреску осилил стандарт и бросил кресты.

Про D и Александреску я в курсе.
Из контекста выходило, что Александреску начал пилить C++0x.
Ан нет же... все-таки пиляет дальше D...

> Интересно, что повлияло на из решение открыть исходники.

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

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

Неистово лорчую!

>собравшего мир и ядро этим компилятором

но зачем? надо на основных задачах тестировать.

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

Который уже нельзя закрыть и продавать. Ну и зачем он нужен такой компании, основной источник доходов которой - продажа лицензий на проприентарное ПО? Нет денег — нет еды.

> GCC и OpenWatcom-у сливает.

Где сливает, что собирал, как мерял? Какой код, как собирал?

OpenWatcom в текущем состоянии имеет проблемы:

1. Поддерживается старый стандарт С++. Watcom С++ был выкуплен SciTech примерно в 2001 году и передан сообществу через пару лет, открыты исходники почти на всё кроме утилиты подготовки документации (утилита досовская на асме или форте, исходники утеряны). Как следствие этого пункта, поддержка стандартов осталась на уровне 2001-1998 года. Например, STL имеет проблемы (где-то пилят форк STLport). Чорт, да даже iostream нестандартный.
2. Система сборки довольно архаична, NIH синдром как он есть. С одной стороны, они изобрели свой make, линкер, подготовку PS/PDF документации (из коробки также html, сhm и т.п.). С другой стороны, свой шелл для сборки, командные файлы типа bat, часть утилит — зависимости под os/2, плохо распараллеливается под многоядерники. Хотя с ней не так уж сложно разобраться, я вот поправил у себя сборку под x86-32 из-под x86-64.
3. Кодовая база тоже архаична, например, нет никаких планов поддержки того же x86-64, хотя компилятор определённо работает под 64 бита (под те же альфы), только нужно проверять во многих местах исходники. Я вот собрал его через gcc -m64 вместо gcc -m32 и получил сходу сегфолт в wlink, пока лень разбираться подробнее (-m32 работает). wlink, кстати, генерирует elf только на выходе, а .obj — это не .o, а древний OMF формат. То есть, возникает вопрос , как слинковать OW/gcc код без objcopy/objconv. Хотя есть jwlink, который более продвинутый и менее глючный, его нет из коробки в OW.
4. Даже если предположить, что OW 2.0 будет из коробки поддерживать 64 бита, иметь нормальный STL, что дальше? Мало какой софт соберётся этим компилятором. Потому что нужна поддержка последних стандартов, оптимизаций, cистем сборки, больших типичных кодовых баз вроде boost, cmake, llvm, qt, и т.п. Cmake не собирается т.к. поддержка шаблонов нетипична.

Сейчас поддержка ow есть только в форке premake, частично в cmake (генерация wmake-файла). Можно пытаться CXX=/opt/ow/owcc make, но owcc полностью все ключики gcc не поддерживает.

C одной стороны, мы имеем компилятор, который работает везде — Windows, Linux, OS/2 (очень актуальная система), BIN. С другой стороны, он застрял в 90х — мало какой софт собирается им и мало какие системы сборки его поддерживают, да и последние 10 лет его разработка была ни шатко ни валко (+: есть Linux-32, -: нет современных стандартов С++, оптимизаций кодогенератора и линкера).

Мне нравится OpenWatcom, чессно. Простая и понятная кодовая база, система сборки, хорошо структурированный на библиотеки код, ну почти llvm. Я неспешно ковыряю его на предмет 64-битности, но прекрасно понимаю, что он очень «ограниченно годен» — потому что мало какой софт им собирается, и потому что компиляторостроение и стандарты за эти 10 (ну хорошо, 7 с открытия в 2003) году ушло вперёд. Так в чём СЕЙЧАС профит от OpenWatcom?

Чтобы выпустить отдельно коммерческую версию код для который будет браться из этой и у тех людей кто напишет патчи. Крутая бизнес модель не?

> gcc местами даже tcc сливает.

какими местами? если смотреть на форуме фороникса 'compiler deathmatch' то там видно, что tcc без ключей оптимизации собирает лучше чем gcc без оптимизаций; но gcc с хитрыми ключиками всё равно всех заруливает

Давно бы уже сделали возможность выключить эту ненужную эвристику в компиляторе.

какую эвристику?

> но gcc с хитрыми ключиками всё равно всех заруливает

с хитрыми ключиками

местами

Ну ты понял, да?

какую эвристику?

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

ведро кто нибудь уже собрал?

> Чтобы выпустить отдельно коммерческую версию код для который будет браться из этой и у тех людей кто напишет патчи. Крутая бизнес модель не?

1. Если нет разницы и код один, кто будет покупать коммерческую версию?

2. Патчи, являясь производной работой, должны быть лицензированы по GPLv3. Как их закрыть?

А кто тебе покажет код? Чем ты докажешь? Естественно патчи будут переписываться. Но идеи уже третих лиц которым не нужно платить.

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

> А кто тебе покажет код? Чем ты докажешь? Естественно патчи будут переписываться. Но идеи уже третих лиц которым не нужно платить.

Слишком сложно и рискованно. А уж если докажут, мало того что компанию распродадут, так они еще и должны останутся.

> Просто добавят энтерпрайзных фич

это же не БД, а компилятор. Какие ещё такие энтерпрайзные фичи в компиляторе?

Правильно, поэтому нужно было делать в License: LGPLv2.1 как у QtByNokia.

>Кстати а почему такая анти gcc-я реклама? Писали бы уж прямо, что на 270% быстрее icc.

Да так бы и писали, что втрое быстрее ассемблера :)

>Ждем гентушника, собравшего мир и ядро этим компилятором с тестами VS gcc

Спасибо, я на ICC наигрался :)

Тесты от Phoronix уже стали нормальными? Или как обычно подгонка и сравнение хз чего с хз с чем?

Народ, вы что опять фигню про лицензии придумываете? Для содержания закрытой версии достаточно будет всех котрибьюторов в открытую обязать передать права на код организации разработчику. Это стандартная и проверенная временем практика. И от лицензии на открытую версию никакой зависимости нет: хоть там GPLv3, хоть BSD.

Какие ещё такие энтерпрайзные фичи в компиляторе?

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

>втрое быстрее ассемблера :)

Это не солидно. Вот 300% — это Цыфра! А что такое в три раза? Пффф...

Также, желательно, чтоб число было не круглое, это создает впечатление приблизительности, неточночности и легковесности показателя. Для солидности надо использовать что-то типа «270%».

Это всё истинная правда, тебе любой маркетолог подтвердит, инфа 100%

Сцуки, кто разобрал моё ведро?!

>инфа 100% тогда уж «инфа 99,76%» %)

>инфа 99,76%

Посчитано на Pentium FPU?

В этот раз с большим нетерпением все ждём ебылдов ;)

не, это ж

Для солидности

В штатах деньги потраченые на софт пишут не в расходы а как инвестицию капитал предприятия. Поэтому основные потребители Ынтерпрайза всегда покупают много софта и по максимуму. Даже если разницы между комьюнити и Ынтырпрайз версиями вобще нету. Видел такое много раз. Просто бабло потраченое на софт публичная компания может записать в свою стоимость(в итоге)а не в расходы.

>инфа 100% тогда уж «инфа 99,76%» %)

Тут особый случай. «100%» — выражает полноту, реалистичность (не 101%), исключает любые сомнения (не 99,76%).

Нет анон, ты не маркетоид.

Называется «основные средства», и в РФ ПО учитывается так же.

Видел такое много раз.

Чистые активы — это здорово, но вот что они с амортизацией делают?

Неужели собираются RIPнуться? Печально.

>> Интересно, что повлияло на из решение открыть исходники.

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

Примеры «историй успеха» привести слабо?

> преимущество EKOPath 4 перед GCC 4.5.2 составляет от 8% до 270%

Фороникс такой фороникс. Не пишет ни ключей, которые подавались GCC, ни количество проверенных тестов и среднее на них ускорение.

Не работает

[ 37%] Generating pscrt_p-x86_32/malloc_opt_c.o
cd /home/userx/build/src/libpscrt/pscrt_p-x86_32 && /home/userx/build/bin/pathcc -c -o malloc_opt_c.o -m32 -DTARG_X8664 -I/home/userx/build/src/include -I/home/userx/compiler/src/include -pg -DHAVE_ALLOCA_H=1 -DX86_WHIRL_OBJECTS -D_SGI_SOURCE -D__GNU_BUG_WORKAROUND -DKEY -DFE_GNU_4_2_0 -D_LONGLONG -D_MIPSEL -DTARG_LINUX -D_GNU_SOURCE -DHOST_IS_BIG_ENDIAN=0 -DHOST_IS_LITTLE_ENDIAN=1 -D_LANGUAGE_C /home/userx/compiler/src/libpscrt/malloc_opt.c -O2 -DNDEBUG
gcc: ошибка: unrecognized option «-VHO:rotate»
gcc: ошибка: unrecognized option «-G8»
make[2]: *** [src/libpscrt/pscrt-static-x86_32/malloc_opt_c.o] Ошибка 1
make[2]: Выход из каталога `/home/userx/build'
make[1]: *** [src/libpscrt/CMakeFiles/pscrt-static-x86_32.dir/all] Ошибка 2
make[1]: *** Ожидание завершения заданий...
gcc: ошибка: unrecognized option «-VHO:rotate»
gcc: ошибка: unrecognized option «-G8»
make[2]: *** [src/libpscrt/pscrt_p-x86_32/malloc_opt_c.o] Ошибка 1
make[2]: Выход из каталога `/home/userx/build'
make[1]: *** [src/libpscrt/CMakeFiles/pscrt_p-x86_32.dir/all] Ошибка 2
make[1]: Выход из каталога `/home/userx/build'
make: *** [all] Ошибка 2

Ключи:

cmake ../compiler/ -DCMAKE_INSTALL_PREFIX=/opt \
-DPATH64_ENABLE_TARGETS=x86_32 \
-DPSC_CRT_PATH_x86_32=/usr/lib \
-DCMAKE_BUILD_TYPE=Release \
-DPATH64_ENABLE_MATHLIBS=ON \
-DPSC_DYNAMIC_LINKER_x86_32=/lib/ld-linux.so.2 \
-DPSC_LIBSUPCPP_PATH_x86_32=/usr/lib/gcc/i686-pc-linux-gnu/4.6.0 \
-DPSC_LIBSTDCPP_PATH_x86_32=/usr/lib/gcc/i686-pc-linux-gnu/4.6.0 \
-DPSC_LIBGCC_PATH_x86_32=/usr/lib/gcc/i686-pc-linux-gnu/4.6.0 \
-DPSC_LIBGCC_EH_PATH_x86_32=/usr/lib/gcc/i686-pc-linux-gnu/4.6.0 \
-DPSC_LIBGCC_S_PATH_x86_32=/usr/lib/gcc/i686-pc-linux-gnu/4.6.0

> оно ядро собирает?

" С позиции совместимости, EKOPath 4 не испытывает проблем со сборкой ОС NetBSD и FreeBSD, а также таких крупных проектов, как инструментарий GNU, Qt и KDE. Удалось обеспечить сборку Linux-ядра, но пока это возможно только после применения небольшого патча (дополнение: тестовая версия ядра 3.0.0 уже собирается без патча). В настоящее время компания PathScale работает в направлении обеспечения полной совместимости с доступными научными библиотеками и размещенным в публичных репозиториях открытым ПО."

http://www.opennet.ru/opennews/art.shtml?num=30858

Это победа господа. Бармен, всех угощаю!

На гитхабе стали появляться багрепорты. Вот комментарий к одному из них (про падение компилятора во время второй стадии сборки):

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

Ъnterprise Quality, ёпта! =)

Посмотрел тесты, впечатляет.
Надеюсь GCC не конец =)

>>> Тесты от Phoronix: 1 2 3

Тесты от Phoronix уже стали нормальными?

Это не тесты Phoronix. Это один из девелоперов сего чуда выложил на Phoronix свои сообщения о том, как крут его компилятор. Тестом там и не пахнет.

Ради кривоспроектированных языков вроде Си++ нужно создавать огромные, огромные, ОГРОМНЫЕ компиляторы.
---
И да, GCC воистину монстроуозен.

8)

Ради кривоспроектированных языков вроде Си++ нужно создавать огромные, огромные, ОГРОМНЫЕ компиляторы.

Точно подмечено! Лучше взять годный, грамотно спроектированный, весь из себя логичный и проверенный временем язык программирования. А потом долго, Долго, ДОЛГО насиловать мозг разработчикам прикладного ПО, чтобы они хоть как-нибудь его осилили и смогли написать хотя бы 0.001% от того объёма полезного софта, который за то же время можно написать на говнонедоязычках типа си-с-крестами.

>Ъnterprise Quality

Open64 вроде тоже пока завязан на 4.2

Ничего этого не нужно. Просто стоит самим писать хороший код на хороших ЯП.

> EKOPath 4

надеюсь эко-феминистки здесь непричем?

>Который уже нельзя закрыть и продавать.

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