IBM выпустила высокопроизводительный C/C++ компилятор для Linux

кто-то говорил, что IBM - это про OpenSource? ж) IBM - это про продажу собственного железа. ;)

Там народ очень и очень разный. IBM - это страна с кланами, некоторые про Suse, некоторые про RedHat, очень много про Aix и Windows :-).

Но все кланы - про $$$$

не могу понять. Ты против $$$$? :-)

в http://openet.ru одну n пропустили.

Правильная ссылка: http://opennet.ru

Этот компилятор как-то с GCC сравнить можно?

>Этот компилятор как-то с GCC сравнить можно?
Можно, gcc его рвет как тузик грелку.

Ну и ? У нас жаба и mono есть.

А наф на power, что мы нелюди? даешь для i386 архитектур компиляторы!

>>Этот компилятор как-то с GCC сравнить можно? >Можно, gcc его рвет как тузик грелку. > >anonymous (*) (15.02.2005 11:33:42) Не видел пока ни одного компилятора, который был бы хуже GCC :) У gcc два достоинства - он халявный и работает везде. icc делает код иногда в разы более эффективный (я сравнивал на flops.c). Под SPARC сановский cc из WorkShop тоже рвет gcc по качеству кода.

> А наф на power, что мы нелюди?

Нелюди-нелюди.

> даешь для i386 архитектур компиляторы!

Марсианцы.

если производитель процессоров делает платные компиляторы, то он ставит преграду на пути програмиста к оптимизации на данном процессоре. а преграда эта - стоимость компилятора!

Вообще-то, на единственной нашей IBM-овской станции, сравнение gcc и компилятора cc, что идёт в комплекте с AIX, показывает, что cc генерит в среднем в 1.5 раза более быстрый код.

>Под SPARC сановский cc из WorkShop тоже рвет gcc по качеству кода.

Что верно то верно. Разве может качественный код работать в два раза быстрее?

Один и то же проект, собранный сановским cc грузит систему на ~80%, gcc на ~40% :)

> Один и то же проект, собранный сановским cc грузит систему на ~80%, gcc на ~40% :)

Ну дык это и озночает, что gcc хреновый код генерит - прога большую часть на nop-aх висит :):)

Если кто не в курсе, есть такая особенность у sparc процессоров :)

> А наф на power, что мы нелюди? даешь для i386 архитектур компиляторы!

i386 медленно но верно умирает...

>> А наф на power, что мы нелюди? даешь для i386 архитектур компиляторы!

>i386 медленно но верно умирает...

почему это???
Чем он хуже power?
Чем power лучше i386?

факты если можно???

спасибо

>i386 медленно но верно умирает...

Он не умирает а мутирует ... скоро от AMD64 и EM64Т мутантов будет не протолкнуться .... а вот RISC-динозавры мрут один за другим

Закон эволюции говорит о том что выживают не самые сильные а самые приспособливые ;)

>У gcc два достоинства - он халявный и работает везде.

Неправда. Как минимум 3. Он лучше всех поддерживает стандарт.

>> Один и то же проект, собранный сановским cc грузит систему на ~80%, gcc на ~40% :)

>Ну дык это и озночает, что gcc хреновый код генерит - прога большую часть на nop-aх висит :):)

>Если кто не в курсе, есть такая особенность у sparc процессоров :)

Т.е. nop-ы не жрут процессоры, а вместо этого выполняют всю функциональность программы (данных-то в секунду сыпется одинаково независимо от компилятора)?

Срочно сажусь штудировать доку на спарковый ассемблер. А то никогда про такие умные nop-ы не слышал. :)

Самое интересное (для меня) то, что тут на ЛОРе нездоровый ажиотаж вызывают лишь новости про сан. Вот новость
насчет ИБМ, так никто не орет, что Power RIP. И насчет других, типа МИПСа или ПА-РИСК тишина. Ну разве что
кто какой камень в стороны Альфы иногда кинет, но столько сколько обламывается сану ни достается больше никому.
К чему бы это? Может и впрямь эта компания со своей продукцией осточертела всем, включая тех, кто ее никогда не
пробовал не нюхал и не видел, хуже горькой редьки?
А тут еще выясняется, что на спарках какието "отмороженные" NOPы ...

>i386 медленно но верно умирает...
Конечно. Но разве АМД-64 это не очередная ее реинкарнация?

> Может и впрямь эта компания со своей продукцией осточертела всем

Не, ну почему же?! Ежемесячные анекдоты от МакНили и Шварца весьма недурны!

>ИБМ, так никто не орет, что Power RIP.

А чего орать? Достаточно посмотреть тесты SPEC, чтобы понять,
где Power4+ и где поделки Sun.

> А чего орать? Достаточно посмотреть тесты SPEC, чтобы понять, где Power4+ и где поделки Sun.

А где ты видел данные SPEC по SPARC?

>Т.е. nop-ы не жрут процессоры, а вместо этого выполняют всю функциональность программы (данных-то в секунду сыпется одинаково независимо от компилятора)?

Это не настоящие nop-ы :)

Имелись в виду паузы, которые делает процессор, если команды не синхронизированы. Пр попытка использование регистра в момент, когда он ещё не згружен и тд

> А где ты видел данные SPEC по SPARC?

Шайтан. САН их всеже опубликовал

>>Т.е. nop-ы не жрут процессоры, а вместо этого выполняют всю функциональность программы (данных-то в секунду сыпется одинаково независимо от компилятора)?

>Это не настоящие nop-ы :)

>Имелись в виду паузы, которые делает процессор, если команды не синхронизированы. Пр попытка использование регистра в момент, когда он ещё не згружен и тд

Иными словами, gcc не переупорядочивает команды под очередь?

А если бы он это делал, то загрузка еще упала бы?

А что же тогда генерит сановский компилятор? Если оно в два раза тормознее даже такого gcc!?

Просто факт из учебника - идеальная программа утилизует процессор на 100%. Так что чем меньше нагрузка - тем херовее написана программа.Она просто очень медленно работает. Выполняет мало полезных инструкций в секунду.

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

>Иными словами, gcc не переупорядочивает команды под очередь?

есть такие подозрения

>А если бы он это делал, то загрузка еще упала бы?

Увеличилась бы :)

>А что же тогда генерит сановский компилятор? Если оно в два раза тормознее даже такого gcc!?

откуда дровишки ? 8) сцылку плз

По всем тестам сановский быстрее :) Я сам неоднократно компилял и гонял мелкие тесты - сановский на спарках практически всегда был быстрее

>Ну, это если программа что-то рассчитывает. А если она получает данные с железа с каким-то интервалом времени и их обрабатывает? Зачем ей грузить процессор когда она уже все обработала и ждет следующей точки данных?

В случае работы с железом между сановским и gcc разницы быть не должно, системные-то библиотеки одни и те же :)

>Ну, это если программа что-то рассчитывает. А если она получает данные с железа с каким-то интервалом времени и их обрабатывает? Зачем ей грузить процессор когда она уже все обработала и ждет следующей точки данных? brazhe

Тогда производительность нужно мерять в количестве этих самых обработанных точек за единицу времени. :)

Если одна прога обработает 2 точки за секунду, загрузив проц на 50%, а другая - 10 точек, загрузив проц на 90% - какая лучше?

;)

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

>В случае работы с железом между сановским и gcc разницы быть не должно, системные-то библиотеки одни и те же :) А при чем здесь системные библиотеки? Я верю, что данные по TCP/IP получаются довольно быстро. Время уходит на их перетряску/анализ/реакцию по результатам анализа... и т.д.

Или ACE/TAO - тоже системная библиотека. Но она тоже собирется cc/gcc.

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

>>А если бы он это делал, то загрузка еще упала бы?

>Увеличилась бы :)

А вот с этого места поподробнее. Я могу поверить (да и уверен), что процессор исполняет другой процесс (в том числе и idle) когда ожидается ввод/вывод. Но что планировщик сумеет, выполнить команду-другую из одного процесса, пока другой ждет окончания одной команды - чтобы начать следующую... ""

Или top умдряется считать и такой простой процессора? :)

>А что же тогда генерит сановский компилятор? Если оно в два раза тормознее даже такого gcc!?

>откуда дровишки ? 8) сцылку плз

Свой проект, в смысле конторы. К сожалению поделиться не могу - работодатель не позволит. :(

>По всем тестам сановский быстрее :) Я сам неоднократно компилял и гонял мелкие тесты - сановский на спарках практически всегда был быстрее

Это далеко не мелкий тест. Кучка из десятка процесов, да еще и практически каждый многопоточный... :)

А что включали эти мелкие тесты? Числодрибилки, потоки, c++, исключения, шаблоны...?

>Просто факт из учебника - идеальная программа утилизует процессор на 100%.
>Так что чем меньше нагрузка - тем херовее написана программа.Она просто
>очень медленно работает. Выполняет мало полезных инструкций в секунду.


Это древний у вас какой то учебник.
А как же многозадачность да еще вытесняемая. Ну а если в семи любимый RT посмотреть... Ай если там еще и проц ограничен на задачу (не в i386) Ай яй ай - что то тут не так.

>А что включали эти мелкие тесты? Числодрибилки, потоки, c++, исключения, шаблоны...?

по большей части числодробилки, давненько только это было

gcc 2.95, 3.0.x vs CC v5.3 (Forte 6UP2 )

как всегда лоровцы упустили суть : семейство visual age единственное что по праву носит прилагательное visual и позволяет действительно дохрена логики приложения писать одной мышкой. да именно логики, всякие обработчики левого клика мышки и прочего микрософтовское и борладновское говно знать не нужно. жаль что ibm это все свертывает.

Блин, ну и грамотеи. Вы что-нибудь слышали о мультизадачных операционных системах и о квантовании? 100% ты получишь, если откажешься от оси и введешь свою прогу в машинных кодах с консоли прямо в память, или, на крайняк, напишешь bootstrap для своей проги.