Компилятор Open64 (http://www.open64.net) для языков C, C++ и Fortran, разрабатываемый при поддержке компании AMD, обновился (http://www.open64.net/news/single-view/archive/2011/november...) до версии 5.0 и теперь включает в себя более полную поддержку стандарта языка C, архитектуры IA64 и множество оптимизаций, направленных на улучшение быстродействия приложений, собранных для процессоров серии AMD Bulldozer.
Основной упор при подготовке релиза был сделан (http://sourceforge.net/projects/open64/files/open64/Open64-5...) на оптимизирующую функциональность компилятора. Добавлено несколько новых методов оптимизации, расширены существующие. Появились новые способы развертывания циклов и преобразований if-конструкций. Компилятор теперь более интеллектуально обращается со структурами, избегая их слишком частого копирования. Появилось множество улучшений движка векторизации и несколько методов оптимизации ...URL: http://www.open64.net/news/single-view/archive/2011/november...
Новость: http://www.opennet.me/opennews/art.shtml?num=32275
реквестирую сравнение производительности числодробильных прог, скомпиленных сабжем, gcc и icc.
Как минимум с гцц и шлангом недавно сравнивал фороникс. На паре тестов он реально порвал на амдшном проце остальных. Правда в отместку он под интел вообще не смог родить рабочие бинари, равно как не смог собрать некоторые тесты.
АМД дааа... Так не любить конкурентов... ай-ай-ай...
Это они отомстили интелу за хреновую оптимизацию под амд в icc :D
> Это они отомстили интелу за хреновую оптимизацию под амд в icc :Dувидим ли мы "великое расхождение платформ"?
когда под amd64 будет только один, "свой" компилятор? а под i386 - свой? сколько мейнтейнеров проснутся седыми?
Поэтому они так и будут собирать gcc, он для обоих собирает ;)
А может целесообразно включить упомянутые "блоки оптимизации" из icc и open64 непосредственно в gcc?
> А может целесообразно включить упомянутые "блоки оптимизации" из icc и open64 непосредственно
> в gcc?На этом пути ожидается несколько грабелек:
1) А, гм, icc - как ни странно проприетарный. Поэтому вопросы к товарищу Интелу. Подозреваю что у них какие-то проблемы с интеллектуальной собственностью там, может кусок прав не их, или типа того. Во всяком случае они предпочли помогать допилить гцц для новых процессоров вместо этого (некоторые последствия оптимизации ощутили фанаты Ульриха Дреппера на федоре с оптимизированным memcpy, ломающим поведение ряда программ :D).2) Гм, если код сгенеренный для амд64 не очень работает на интеле - не понятно как с ним бороться. С интелом в смысле. Таскать 2 версии кода в 1 проге? Так она ж опухнет в 2 раза и все причастные высрут горы кирпичей когда их системы на сидюк перестанут вмещаться с двукратным отрывом.
ну речь то, вообще, про оптимайзер, у вас и сейчас код скомпилированный с march=corei7 на core2 будет фокусы показывать.
> ну речь то, вообще, про оптимайзер, у вас и сейчас код скомпилированный
> с march=corei7 на core2 будет фокусы показывать.Логично - у i7 вроде как есть новые команды. Кор2 их не поймет.
> Таскать 2 версии кода в 1 проге?source-based даже и не встретят такой проблемы на пути от исходников к бинарникам ;)
Ввиду выхода c++11 интересно было бы, в каком состоянии находится его поддержка у open64.
они только Си допилили, а вы уже про какой-то футуристический С++11 :)
> Второе достоинство компилятора в лицензии GPLv2Не достоинство, а жирный недостаток.
>> Второе достоинство компилятора в лицензии GPLv2
> Не достоинство, а жирный недостаток.А это смотря с какой точки зрения смотреть :)
>в лицензии GPLv2Что-то я не совсем понимаю какая вообще разница в версии GPL компилятора.
Или кому-то надо статически линковаться с gcc?!
да, GPLv3 было бы лучше.
>> Второе достоинство компилятора в лицензии GPLv2
> Не достоинство, а жирный недостаток.Специально для Вас сделали clang.
> Специально для Вас сделали clang.Он не уточнил в чем недостаток состоит :). Может, он наоборот фанат GPLv3? :D
Лучше бы для gcc патчи сделали.
Лучше бы сам что-нибудь полезное сделал.
Вот когда он ядро собрать сможет, тогда и посмотрим.
Сможет тогда, когда разработчики ядра будут писать на С.
в BSD kernel/userland всю собирает. А все потому что пишут на ANSI C, а не на GCC-specific-C-like-language
Ядро Линукса соответствует ISO "C" 99. и в GCC новые стандарты C обкатываются. Из специфичных GCC расширений это констрейны для inline ассемблера, но без них просто невозможно генерировать оптимальный переносимый код.
Да?
А ну-ка, умник, собери-ка его с -std=c99 -W -Wall -Wextra -Werror -pedantic -pedantic-errors
А мы над тобой поржём. Всем, так сказать, коллективом.
> А мы над тобой поржём. Всем, так сказать, коллективом.А ты чур фряшное с теми же опциями. И как, получается?
А чё, флаги компилятора уже описаны в стандартах?
Ну кроме -c, -o, -E, -s ... и то вряд ли.
Ты это к чему, умник?
Да ну?
Возьмите последнее ядро (3.0.8), посмотрите, к примеру, mm\memory.c(1671).
Это что ли C99?
И подобного добра там навалом.
> Возьмите последнее ядро (3.0.8),Какое же это последнее, если уже 3.1 вышло?!
Блин, он кроме Hello World ченить умеет компилить?!
Ща народ уже не тот пошёл, если оно не умеет компилить ядро, только лишь написав# make CC=opencc
то никто особо трахаццо и не будет, просто выкинут.
не говорил бы за всех....
> не говорил бы за всех....Вы собрали с его помощью ядро или firefox ?
HOWTO можно?вот эта,
http://svn.open64.net/filedetails.php?repname=Open64&path=&#...ну совсем не работает
CC arch/x86/kernel/asm-offsets.s
opencc WARNING: -m32 conflicts with -m64; using latter value (-m64)
opencc WARNING: -mno-mmx is ignored
opencc WARNING: SSE2 required for 64-bit ABI; enabling SSE2.
/usr/bin/gcc -D__OPEN64__="4.2.1" -D__OPENCC__=4 -D__OPENCC_MINOR__=2 -D__OPENCC_PATCHLEVEL__=1 -O2 -D__OPTIMIZE__ -D__KERNEL__ -Wp,-MD,arch/x86/kernel/.asm-offsets.s.d -isystem include -I/media/kernel/uvcvideo/arch/x86/include -Iarch/x86/include/generated -Iinclude -include /media/kernel/uvcvideo/include/linux/kconfig.h -D__KERNEL__ -Wundef -Wno-pointer-sign -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(asm_offsets) -DKBUILD_MODNAME=KBUILD_STR(asm_offsets) -xc -isystem /usr/include -E -mfpmath=387 arch/x86/kernel/asm-offsets.c -o asm-offsets.i
/usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/cc142 -O2 -Wundef -Werror-implicit-function-declaration -Wno-format-security -Wno-sign-compare -fno-omit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign -fcxx-openmp -msse2 -dx -quiet -fpreprocessed -fbuiltin -dumpbase arch/x86/kernel/asm-offsets.c asm-offsets.i -spinfile asm-offsets.spin
In file included from /media/kernel/uvcvideo/arch/x86/include/asm/alternative.h:101,
from /media/kernel/uvcvideo/arch/x86/include/asm/bitops.h:17,
from include/linux/bitops.h:23,
from include/linux/kernel.h:18,
from /media/kernel/uvcvideo/arch/x86/include/asm/percpu.h:45,
from /media/kernel/uvcvideo/arch/x86/include/asm/current.h:6,
from /media/kernel/uvcvideo/arch/x86/include/asm/processor.h:16,
from /media/kernel/uvcvideo/arch/x86/include/asm/atomic.h:7,
from include/linux/atomic.h:5,
from include/linux/crypto.h:21,
from arch/x86/kernel/asm-offsets.c:9:
/media/kernel/uvcvideo/arch/x86/include/asm/cpufeature.h: In function '__static_cpu_has':
/media/kernel/uvcvideo/arch/x86/include/asm/cpufeature.h:334: error: expected '(' before 'goto'
/media/kernel/uvcvideo/arch/x86/include/asm/cpufeature.h:334: error: expected identifier or '*' before '(' token
In file included from /media/kernel/uvcvideo/arch/x86/include/asm/atomic.h:7,
from include/linux/atomic.h:5,
from include/linux/crypto.h:21,
from arch/x86/kernel/asm-offsets.c:9:
/media/kernel/uvcvideo/arch/x86/include/asm/processor.h: In function 'native_get_debugreg':
/media/kernel/uvcvideo/arch/x86/include/asm/processor.h:501: error: implicit declaration of function '__builtin_unreachable'
make[1]: *** [arch/x86/kernel/asm-offsets.s] Ошибка 1
make: *** [prepare0] Ошибка 2
__builtin_unreachable таки Gcc-изм. Что вы хотели?
> Блин, он кроме Hello World ченить умеет компилить?!Судя по форониксу, недавно бенчившему данный компилер - с этим есть некоторые проблемы.
Если сразу ставить перед собой задачу делать переносимый код, то все прекрасно работает.Наши программы (на C++, технические числодробилки консоль/GUI на Qt) штатно компилируются gcc, icc, open64 и visual C++.
> Если сразу ставить перед собой задачу делать переносимый код, то все прекрасно
> работает.
> Наши программы (на C++, технические числодробилкиЁпть, складывать и калькулятор умеет
Так вы как раз из тех, кто хочет ядро компилить, только лишь написав "# make CC=opencc"? ;)Open64 (как и другие названные компиляторы) прекрасно работает у тех, кто желает и УМЕЕТ делать программы САМ.
А для остальных есть готовые "калькуляторы" из коробки ;)
> Так вы как раз из тех, кто хочет ядро компилить, только лишь
> написав "# make CC=opencc"? ;)
> работает у тех, кто желает и УМЕЕТ делать программы САМ.Вот вам делать нех...я, сидите и делайте, а мне этот онанизм не оплачивают.
Вот он, звериный оскал нынешнего линуксоида - "сам программировать не умею, но других обосрать не забуду" :(
> Вот он, звериный оскал нынешнего линуксоида -Это с 1991 до 2000 изучали каждый байтик.
Время ушло, альтернатив на рынке и халявных немерено.
Сейчас никто не будет допиливать то, что должно быть в первую очередь.
Более того, ради сомнительных наносекунд, для непортабильного бинарника.
И говорю же, бабло решает. Клиент захочет софтну с 8-ю видами оптимизаций,
как например у Maple библиотека ATLAS:ATHLON641024SSE2
ATHLON641024SSE2_2
ATHLON641024SSE3
ATHLON641024SSE3_2
P4EM64TSSE3
X8664SSE2Так за 2,845.00$ под все известные процы оптимизируем, жопу полижем, и спасибо скажем.
> "сам программировать не умею, но других обосрать не забуду" :(
Ты в своём дистрибутиве все баги сам, руками исправляешь?! Вот тогда сиди и не пи...ди.