LINUX.ORG.RU

Открыт код компилятора EKOPath 4

 ekopath, ,


0

3

Компания PathScale открыла исходный код собственного компилятора EKOPath 4. До этого компилятор выпускался под проприетарной лицензией, стоимость одной лицензии составляла порядка $2000.

Основные возможности EKOPath 4

  • Генерирует значительно более быстрый код, чем GCC
  • Оптимизации под x86_64 (Intel® 64/AMD64, поддержка Intel® MMX™, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AMD SSE4A и AVX)
  • Поддержка ISO C99/C++ 2003 и расширений GNU
  • Поддержка Fortran 90/95 и 2003
  • Поддержка DWARF4 и совместимость с GDB

В сравнении, произведенном Phoronix, преимущество EKOPath 4 перед GCC 4.5.2 составляет от 8% до 270%.

Исходный код доступен под лицензией GPLv3, поддержка коммерческих версий будет продолжена.

Также компания в скором времени планирует выпустить под свободной лицензией «убийцу CUDA», собственную реализацию GPGPU. Stay tuned.

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

>>> Подробности

★★★★★

Проверено: JB ()
Последнее исправление: madgnu (всего исправлений: 1)

> В сравнении, произведенном Phoronix, преимущество EKOPath 4 перед GCC 4.5.2 составляет от 8% до 270%.

А в чем сливает?

tensai_cirno ★★★★★
()

Ну вот, теперь выбор компилятора ещё сложнее и мучительнее

unC0Rr ★★★★★
()
Ответ на: комментарий от megabaks
[ 55%] Built target ipa-x8664
[ 55%] Built target compiler-stage
[ 55%] Built target compiler-stage-C
[ 55%] Generating pscrt-static-x86_32/malloc_opt_c.o
gcc: malloc_opt_c.o: Нет такого файла или каталога
gcc: неопознанный ключ '-PHASE:c'
make[2]: *** [src/libpscrt/pscrt-static-x86_32/malloc_opt_c.o] Ошибка 1
make[1]: *** [src/libpscrt/CMakeFiles/pscrt-static-x86_32.dir/all] Ошибка 2
make: *** [all] Ошибка 2

таки не собираецо

megabaks ★★★★
()
Ответ на: комментарий от megabaks
[ 38%] Generating pscrt_p-x86_32/malloc_opt_c.o
Built target switch_fc
gcc: malloc_opt_c.o: Нет такого файла или каталога

Похоже на ошибку в системе сборки. Счас посмотрим что у меня будет на 38% =).

Deleted
()
Ответ на: комментарий от Deleted
file:///home/megabaks/compiler/gcc_incl/mm_malloc.h
file:///home/megabaks/compiler/build/lib/include/mm_malloc.h
file:///home/megabaks/compiler/build/GCC/libiberty/CMakeFiles/iberty.dir/xmalloc.c.o
file:///home/megabaks/compiler/src/libpscrt/malloc_opt.c
file:///home/megabaks/compiler/src/libU77/malloc_.c
file:///home/megabaks/compiler/GCC/libiberty/xmalloc.c

т.е. таки должен собирацо и malloc_opt_c.o

megabaks ★★★★
()
Ответ на: комментарий от megabaks

Хренота detected:


[ 31%] 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:
    /home/ivan.mironov/downloads/path64-compiler-90c8c5d/build/lib/4.0.10/x8664/be() [0x867643]
    /home/ivan.mironov/downloads/path64-compiler-90c8c5d/build/lib/4.0.10/x8664/be() [0x867d28]
    /home/ivan.mironov/downloads/path64-compiler-90c8c5d/build/lib/4.0.10/x8664/be(ErrMsgLine+0x8e) [0x867afe]
    /home/ivan.mironov/downloads/path64-compiler-90c8c5d/build/lib/4.0.10/x8664/be() [0x8690d8]
    /lib64/libc.so.6() [0x3240635300]
    /home/ivan.mironov/downloads/path64-compiler-90c8c5d/build/lib/4.0.10/x8664/be(_ZN3CSE13Do_cse_pass_2Ev+0x808) [0x786d68]
    /home/ivan.mironov/downloads/path64-compiler-90c8c5d/build/lib/4.0.10/x8664/be(_ZN11EXP_WORKLST20Generate_save_reloadEP6ETABLE+0x60) [0x787160]
    /home/ivan.mironov/downloads/path64-compiler-90c8c5d/build/lib/4.0.10/x8664/be(_ZN6ETABLE25Perform_LPRE_optimizationEv+0x3ed) [0x7f0ccd]
    /home/ivan.mironov/downloads/path64-compiler-90c8c5d/build/lib/4.0.10/x8664/be(_ZN9COMP_UNIT11Do_load_preEii+0xfb) [0x7f10cb]
    /home/ivan.mironov/downloads/path64-compiler-90c8c5d/build/lib/4.0.10/x8664/be(Pre_Optimizer+0x2999) [0x7f4e79]
    /home/ivan.mironov/downloads/path64-compiler-90c8c5d/build/lib/4.0.10/x8664/be(Perform_Global_Optimization+0xaa) [0x84bd3a]
    /home/ivan.mironov/downloads/path64-compiler-90c8c5d/build/lib/4.0.10/x8664/be() [0x4a9b32]
    /home/ivan.mironov/downloads/path64-compiler-90c8c5d/build/lib/4.0.10/x8664/be(main+0x740) [0x4a2900]
    /lib64/libc.so.6(__libc_start_main+0xed) [0x324062139d]
    /home/ivan.mironov/downloads/path64-compiler-90c8c5d/build/lib/4.0.10/x8664/be() [0x4a707d]
pathcc INTERNAL ERROR: /home/ivan.mironov/downloads/path64-compiler-90c8c5d/build/lib/4.0.10/x8664/be died due to signal 4
pathcc ERROR: core dumped
make[2]: *** [src/libpscrt/pscrt-static-x86_64/memcpy_em64t_c.o] Ошибка 1
make[1]: *** [src/libpscrt/CMakeFiles/pscrt-static-x86_64.dir/all] Ошибка 2
make: *** [all] Ошибка 2
Он падает при попытке собрать себя 8).

Deleted
()
Ответ на: комментарий от megabaks

Тут видимо причина в изначальной проприетарности. Подобные «только что открытые» продукты собрать практически невозможно, ибо для этого требуется очень сильная чёрная магия, знанием которой обладает пока только разработчик :).

Deleted
()
Ответ на: комментарий от megabaks

Ну, как то маловато будет... Вот уж по части портируемости на прочие архитектуры GCC долго ещё будет впереди всех, думаю.

one_more_hokum ★★★
()

> Генерирует значительно более быстрый код, чем GCC

Кого не послушаешь - дык все быстрее, чем GCC. Почему же GCC такой тормоз?

BattleCoder ★★★★★
()
Ответ на: комментарий от BattleCoder

> Кого не послушаешь - дык все быстрее, чем GCC.

«П*деть - не мешки ворочать» (с)

tailgunner ★★★★★
()
Ответ на: комментарий от megabaks

>надо будет запилить ебыдло + костыль в bashrc

а смысл?

/me ждет обещанного PathScale «убийцу CUDA и OpenCL»

//Что-то изю в треде не видно, пьет чтоль с горя.

devl547 ★★★★★
()

Два GPLv3 компилятора, один другого лучше...
Был у Шекли такой фантастический рассказ «Предел желаний»...

Anonymous ★★★★★
()
Ответ на: комментарий от BattleCoder

Они просто работают далеко не везде и быстрые далеко не всегда 8).

Deleted
()

А что от этого выкладывания получает сама компания? Opensource сообщество в едином порыве ринется заказывать у них поддержку?

i-rinat ★★★★★
()

Это от того, что майкрософт покупает nvidia, решили добить куду?

aptyp ★★★★
()

Обещают сделать сборку куте в течении месяца, мешает лишь одна бага сейчас. С++0х тож обещают в будущем, правда первым полчит закрытая версия. Поддреживает расширения ГНУ и Ядро собирает с небольшим патчем. Код получается быстрее гцц и уж темболее силэнга.

Ну чтож, отлично! Как закончат открытие будем пробовать собрать им систему...

anonymous
()
Ответ на: комментарий от unsigned

Говорят, что форк SGI'шного Pro64, который произошел 8 лет назад. Написано, что Open64 брал их код периодически. Такие дела.

anonymous
()
Ответ на: комментарий от malbolge

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

devl547 ★★★★★
()

У какого компилятора C++ самая быстрая компиляция? Нужен такой, который компилирует со скоростью сишарпа или дельфи.

zenden
()
Ответ на: комментарий от zenden

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

anonymous
()
Ответ на: комментарий от zenden

У какого компилятора C++ самая быстрая компиляция? Нужен такой, который компилирует со скоростью сишарпа или дельфи.

Уолтер Брайт хвастался, что его компилятор самый быстрый, но насколько это правда сейчас, тружно судить. И он, кажется, только 32 битный.

Vudod ★★★★★
()

PathScale? Это вроде Path64, форк Open64, gcc-шный фронтэнд + бекенд от sgi cc с работающим LTO? или это другой компилятор?

anonymous
()

> В сравнении, произведенном Phoronix, преимущество EKOPath 4 перед GCC 4.5.2 составляет от 8% до 270%.
тред — радость гентушников.

tn1
()
Ответ на: Очень ждем ебилдов! от staseg

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

пробовал как-то собрать open64 4.2.4, что-то не собиралось «из коробки».

anonymous
()
Ответ на: комментарий от anonymous

https://github.com/path64

а чем отличаются open64, path64 и сабж EKOPath4?

По open64 - хз. Path64 и ekopath4... а тоже фиг поймёшь. Если я правильно понял, то в path64 сейчас начали постепенно переносить наработки проприетарного ekopath.

Deleted
()
Ответ на: комментарий от kompas

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

пару месяцев назад на похорониксе были бенчмарки 'compiler deathmatch' (см. ссылки в обсуждении статьи на форуме с продолжениями), tcc + pcc + gcc + clang + icc + open64, по этим тестам open64 неплохо выглядел (хотя gcc с хитрыми строчками оптимизации в итоге всех зарулил, если стандартный -O2 рулил open64). Интересно, повлияло ли это.

anonymous
()
Ответ на: комментарий от megabaks

> но x86* таки больше кому нужен

Да ладно, рынок контроллеров/процессоров для встраиваемых систем покрывает рынок персоналок, как бык овцу. В любом современном автомобиле контроллеров штук *дцать понапихано, и на ассемблере ваять под них уже лениво, благо ресурсы позволяют использовать языки потяжелее, и повысокоуровневее.

one_more_hokum ★★★
()
Ответ на: комментарий от BattleCoder

> Кого не послушаешь - дык все быстрее, чем GCC.

Угу, на паре-тройке синтетических тестов, которые разработчики «всех» мучительно родили, чтоб их конпелятор хоть в чём «опережал» GCC.

one_more_hokum ★★★
()
Ответ на: комментарий от tensai_cirno

Волтер Брайт — автор компилятора Zortech C++, второго настоящего компилятора С++ (отдельного, native, то есть не транслятора в С, как CFRONT Страуструпа или Comeau C++ Комю). Первым был g++ 1.13 — декабрь 1987, вторым — Zortech C++ (он же, Datalight C, он же Zorland C, Zortech C++, Symantec C++, он же Digital Mars C++) — 1988. См. http://www.softwarepreservation.org/projects/c_plus_plus/index.html#chronology http://www.walterbright.com/

Именно задолбавшись с косяками языка С++ при написании компилятора, Волтер Брайт решил переделать С++ и изобрёл D.

Критику С++ можно нагуглить, например, по joyner96.pdf by Ian Joyner

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.