Ядро FreeBSD собирается компилятором Intel

Тут интереснее знать - оно icc только собирается,
или даже работать умеет стабильно будучи им собрано ?

Саныч, а что есть в Intel такого, что нет в gcc? Назовите. И как там с рестрикт-пойнтерз?

Вы у нас просто супер специалист во всех областях, ответьте!

Саныч, ну что раз конкретный вопрос про restricted pointers, так сразу в кусты?

Саныч, болтунишка, ну где же ответ? Вопрос-то риторический!

А как в icc с int complex? Неужто поддерживает? :)))

с restricted-указателями там нормально (см последние версии), с int complex -- ХЗ (хотя зачем они для сборки ядра? -- вопрос риторический). ну а вообще, в интелевом компиляторе есть много такого, чего нет в gcc (правда фичи евонные более полезны при сборке числодробилок, чем при сборке ядра). Короче, вам про Ерему, а вы... Интереснее было б узнать результаты тестов.

> правда фичи евонные более полезны при сборке числодробилок

Опаньки!!!

int complex поддерживает или нет? "числодробилка", панимаш! :)))

> чем при сборке ядра

Ядра для Opt.64??? :)

> там нормально

Что значит "нормально" ?

> есть много такого, чего нет в gcc

И что же?

Так Вы мне не ответили про Атлон64.

что значит "нормально" для restricted-указателей? я имел ввиду соответствие стандарту ANSI -- цитата из юзер мануал для icc 7.0: "The -restrict option enables the recognition of the restrict keyword as defined by the ANSI standard. By qualifying a pointer with the restrict keyword, the user asserts that an object accessed via the pointer is only accessed via that pointer in the given scope. It is the user s responsibility to use the restrict keyword only when this assertion is true. In these cases, the use of restrict will have no effect on program correctness, but may allow better optimization."

а про фичи -- у компилятора могут быть только две фичи -- хорошее соответствие стандартам и хорошая оптимизация. все остальное -- от лукавого :) Линуховая версия интел-компилера поддерживает большинство расширений от гцц. ну а на счет оптимизации, ицц генерит хороший код при использовании SSE/SSE2 и (!) умеет _автоматически_ векторизовать код.

Да, чуть не забыл -- OpenMP (автоматическое (почти) распараллеливание)!!! вот фича, всем фичам фича!!

сорри, про Атлон забыл. Вообще говоря, Ваш вопрос некорректен -- это супернаглость требовать от _интелевого_ компилятора поддержки процов-конкурентов.

а вообще, я не пытался сказать, что ицц рвет гцц как Тузик грелку", я просто сказал, что для числодробилок на х86/IA64 ицц -- очень неплохой компилер. Так что сорри, если ненароком обидел фанов ГЦЦ :)

> OpenMP (автоматическое (почти) распараллеливание)!!! вот фича, всем фичам фича!!

Для Athlon64 забудьте.

> хорошее соответствие стандартам

Что значит "хорошее"? Соответствие либо есть, либо нет. Есть еще и расширения. В стандарте, например, нет __real__ , а в Intel оно есть. А вот int complex как?

Я думаю, что большой плюс когда ядро и юзерланд под платформу можно будет собрать "родным" компилятором.

> супернаглость требовать от _интелевого_ компилятора поддержки процов-конкурентов.

Это супернаглость требовать использования только Intel процессоров.

PS. Ну а самую известную "фичку" icc/icl Вы так и не привели :-(.

Конкретика кончилась, начались общие фразы - появился форумный всезнайка. :)

>Для Athlon64 забудьте.

Ну и что?

А когда gcc будет поддерживать HT на Intel?

> А когда gcc будет поддерживать HT на Intel?

Вы сами поняли, что сказали???

>Это супернаглость требовать использования только Intel процессоров.

А че за религия? Вполне нормальная конкуренция,

пусть AMD делает свой компилер, если ядро от него будет на 30%

быстрее чем от gcc, то будут покупать его.

Вы поняли сами, что Вы спросили про HT????? Даже для такого персонажа как Вы это просто супер!

1. про "самую известную" -- не забыл, я ее просто не знаю. это какая?

2. и, кстати, кто требует юзать только интеловские процы?

3. и про поддержку НТ в компиляторе -- ничего в этом крамольного нет и бросаться словами "сами поняли чё сказали" не надо. НТ это не SMP и при распараллеливании программы компилер должен это учитывать.

> распараллеливании программы компилер должен это учитывать.

Хорошо. Примерчик кода в студию. Покажите на практическом примере, как это реализовано. С удовольствием Вас выслушаю.

> про "самую известную" -- не забыл, я ее просто не знаю. это какая?

Покажите Ваши практические познания в icc.

Помнится Линус говорил недавно: "А не использовать ли нам для сборки ядра еще какой-нить компилятор кроме ГЦЦ?" Вот, похоже БСДшники его и послушали.

Вот, нашел:
Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.
http://www.linux.org.ru/view-message.jsp?msgid=276931
Правда маленький - не совсем про icc

Все это уход от конкретных вопросов. Пока я вижу только фразы с рекламной страницы Intel, которую я читал перед загрузкой icc и icl. Вы мне примеры на HT приведите.

> Помнится Линус говорил недавно: "А не использовать ли нам для сборки ядра еще какой-нить компилятор кроме ГЦЦ?" Вот, похоже БСДшники его и послушали.

Интересно, а какой компайлер будут использовать для IBM T-Rex? Саныч уже ославился с Hercules, теперь жду очередных ляпов про что-нить типа USS.

2anonymous (*) (11.11.2003 15:10:00)

"за примерчиком в студию" сами сходите на intel.com. там в разделе для девелоперов есть статьи именно на тему оптимального распараллеливания на НТ (на вскидку по памяти -- вместо простого распараллеливания счетного процесса на две нити юзается следующий подход -- счетная нить одна, а вторая бежит рядом и закачивает в кэш данные, которые понадобятся основному процессу для дальнейшей обработки).

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

> я на ваши вопросы ответил?

про int complex, к сожалению, Вы не ответили.

> "за примерчиком в студию" сами сходите на intel.com

Я предполагал, что такой квалифицированный разработчик как Вы, в совершенстве владеющий icc, укажет точную ссылку, а не ограничится общими фразами.

> уж экзаменовать меня -- уж простите...

Позвольте, я просто скромно поинтересовался, не более того.

The parallelization methods used by Intel's compiler designers are quite interesting. The compiler starts by analyzing the data, pointer and code dependencies, and builds an internal table that shows where there are static or dynamic dependencies. Once these dependencies are identified, the compiler restructures the source code, isolating independent sections of code from each other. In some cases, if the dependencies are static, it also changes the code to substitute independent elements, for example replacing constant variables with literal constants. To pick another example, an if/then statement might be converted into a simpler "max" or "min" operation, eliminating a branch. Finally, the rearranged code is compiled into separate threads.

А separate threads, я так понимаю, могут исполнятся параллельно.

" Auto-Parallelization: The Intel C++ Compiler 7.1 includes an Auto-parallelization feature for automatic threading of loops. This feature provides developers with an easy way to take advantage of parallelism to improve application performance on multiprocessor systems. This option detects parallel loops capable of being executed safely in parallel and automatically generates multithreaded code for these loops. Automatic parallelization relieves the user from having to deal with the low-level details of iteration partitioning, data sharing, thread scheduling and synchronizations. It also provides the benefit of the performance available from multiprocessor systems, and systems that support HyperThreading technology. " http://www.intel.com/software/products/compilers/clin/clinux.htm

Саныч, icc работает и генерит как native *BSD приложение или в режиме поддержки Linux приложений в *BSD?

Э нет, коллеги, так дело не пойдет. Вы мне ДОКАЖИТЕ это на примере конкретного кода, а не copy-paste рекламные материалы уважаемой фирмы Intel. Вы мне код дайте, а я проверю Ваши результаты.

>Саныч, болтунишка, ну где же ответ? Вопрос-то риторический!

Вот ведь придурок :)

Риторический вопрос НЕ ТРЕБУЕТ ответа. :) :) :)

Особенно тогда, когда ответа у форумных болтунишек типа знатоков icc нет. :):):)

Дык он генерит код ядра.

А в портах он наверное есть, я уже не помню.

2anonymous (*) (11.11.2003 15:24:57)

оп-а. вижу ваше любопытство про поддержку всяких фич (в том числе и про НТ) уже подкреплено цитатами из документации.

про int complex -- я уже сказал (честно!) ХЗ. ну а на остальные вопросы (не увиливай) -- ответил.

а за комплимент -- спасибо. я действительно часто юзаю ицц :)) и не плохо им умею пользоваться.

> А в портах он наверное есть, я уже не помню.

Вы не уходите, пожалуйста, от вопроса. ТО, что можно пересобрать большую часть кода при помощи icc, очевидно. А как пересобрать библиотеки самого icc? Я Вас спрашиваю - icc native *BSD или нет?

> я действительно часто юзаю ицц :)) и не плохо им умею пользоваться.

Так как там насчет int complex ?

Какой код?

Код самый обычный, просто компилер от интел может выделять независимые

участки кода и параллельно исполнять их в тредах на разных

половинках проца.

> Э нет, коллеги, так дело не пойдет. Вы мне ДОКАЖИТЕ это на примере конкретного кода, а не copy-paste рекламные материалы уважаемой фирмы Intel. Вы мне код дайте, а я проверю Ваши результаты.

Да что ты к людЯм прикопался. Напиши сам что-то типа

for(int i=0;i < 10000;i++)

a[i] = b[i]*c[i] + d[i];

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

2nonymous (*) (11.11.2003 15:41:29)

вот, вот -- утрись (http://gcc.gnu.org/onlinedocs/gcc-3.1/gcc/Complex.html#Complex):

ISO C99 supports complex floating data types, and as an extension GCC supports them in C89 mode and in C++, and supports complex integer data types which are not part of ISO C99. You can declare complex types using the keyword _Complex. As an extension, the older GNU keyword __complex__ is also supported

теперь уж точно -- на все твои вопросы ответил :)))

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

Тот великолепный код, который приведен после вашего поста удовлетворяет этому условию? :))

> параллельно исполнять их в тредах на разных

Как для трэдов *BSD, так и Linux ??? :)

в портах icc для linux, а что это меняет, код он генерит под БСД

Что Вы так разнервничались?

Я вас просил ответить да или нет, а не поработать перекопировщиком текста. Так да или нет? :)

> код он генерит под БСД

А что же тогда расположено в директории

/opt/intel/compiler70/ia32/lib

Тоже код для *BSD? :)

И разве треды для Linux тождественны тредам для BSD? :))

2anonymous (*) (11.11.2003 15:50:35)

> Я вас просил ответить да или нет, а не поработать перекопировщиком текста. Так да или нет? :)

понятно -- тяжелая форма дибилизма.... впрочем, м.б. все не так страшно, просто чел аглицкий не освоит никак. будем надеяться на лучшее :)))

> Как для трэдов *BSD, так и Linux ??? :)

ХАХАХА, ну ты блин и спец! Это надо же перепутать треды системы и треды проца!

> Это надо же перепутать треды системы и треды проца!

Не надо приписывать мне лишнее, а потом с этим героически бороться.

Начнем попорядку. Как в операционной системе я вижу HT процессор?

> просто чел аглицкий не освоит никак

Нет не освоил, живу на велфере.

Правильный ответ - нет, icc complex int не поддерживает. В отличие от gcc.

Вопрос знатокам icc.

Если я уберу libcxa.so.3 будет ли у меня работать скомпилированная интелом программа? ( вычисляющая sin(1), например). Сколько icc тянет, да все, небось в исходных кодах! :)

Короче, что icc круче gcc Вы меня не убедили.

Для некоторых задач и только под Mustdie и под Linux и только под Intel процессоры (привет многочисленным пользователям Itaniumа!!!)

Будет, например, ipp20lineval портирован в *BSD - будут мои поздравления.

А пока я выбираю Athlon64, GCC и Linux.

Интел просто тиха так плакает в углу и кусает локти от обиды...

Ну, что же делать. Молодцы AMD! Обижайся, не обижайся - конкуренция, однако...

Агы. От как интелу-то поплохело, что у него очередной анонимус компилятор не потырил.