На главную страницу AlgoNet В сотрудничестве с ZDNet
АРХИВ СТАТЕЙ 2001-8-23 на главную / новости от 2001-8-23
AlgoNet.ru
поиск

 

Место для Вашей рекламы!

 

Все новости от 23 августа 2001 г.

Intel предлагает инструменты программирования для Linux

Компания планирует анонсировать компиляторы, преобразующие Linux-программы, написанные на языке С++ и Fortran, в команды процессоров Pentium 4 или Itanium. Компиляторы гарантируют, что программы смогут использовать преимущества новых функций микропроцессоров, отличающих Pentium 4 от его предшественников. Itanium же — в силу своей конструкции — зависит от параметров компилятора сильнее, чем большинство других процессоров. В новые компиляторы войдет несколько функций, уже присутствующих в компиляторах Intel для Windows, включая поддержку стандарта OpenMP для многопроцессорных компьютеров. Это поможет программистам создавать программы, наглядно демонстрирующие преимущества процессоров Intel.

Однако стандартным компилятором, которым пользуется большинство Linux-программистов, является GCC (недавно вышла его версия 3.0). Программисты, работающие в сфере науки (основные пользователи языка Fortran), заинтересованы в том, чтобы выжать из микропроцессора всю производительность до последнего бита, и часто пишут свое собственное программное обеспечение.

Оба Linux-компилятора планируется выпустить в сентябре. Их можно будет приобрести по цене 399 $ (скачиваемая версия) или 499 $ (версия на CD) на веб-сайте Intel для программистов.
Обсуждение и комментарии

glassy
23 Aug 2001 11:59 AM
Сливки пытаются снять до выхода следующего gcc :)
Согласен, кто-то купит, интересно все-таки, что ж там такого жизненно важного современному пользователю P4 и Itanium. Даже мне хочется посмотреть, хотя я не имею ни того, ни второго :)
Жалко только gcc team -- отдохнуть им не дают...
 

Дурак ты glassy ....
23 Aug 2001 2:50 PM
Никогда gcc не дотянется до нормального коммерческого софта. А для научых расчетов просто неприменим: код, который он генерит медленный, его производительность в разы (!!!!) отстает от кода, который генерится тем же VC++.

А ведь научные и инженерные расчеты могут требовать не часов а СУТОК даже на высокопроизводительных станциях.

Интел предлагает ОПТИМИЗИРОВАННЫЕ тулзы, наверняка код, генерируемый ими, обгонит по производительности даже VC++.
 

glassy - yljjfbyahoo.com
23 Aug 2001 5:46 PM
2Дурак:
1. Все коммерческое -- suxxx. Зайди на www.gost.ru, www.fips.ru -- 2x suxxx. Зайди. Помню еще какую-то студенческую поделку на основе базы данных, где требовали $10 за запрос. Длб-ы.

2. Коммерческий софт -- это тот, который имеет новый релиз каждый год? -- suxxx по определению.

3. Насколько ты помнишь, P4 -- шаг назад, а Itanium -- такая же новинка, как и голубоватый интерфейс XP.

4. Intel написала компиллятор для VC++, ну и заодно для Linux-систем. О нем даже говорить не стоит -- это побочный продукт.

5. Если уж компилятор направлен на науку, он обязан быть бесплатным.

6. В конце концов, стал бы я ругаться, если бы Intel сделала что-то, действительно моих кровных $300 стоило.

7. Ты уверен про "разы (!!!!)"?

И последнее -- я никогда не ругался на vcc и gcc.

Меня бесит мешание гнутого софта с коммерческим. Это очень очевидные шаги для того, чтобы задушить движение copyleft.
 

муму
24 Aug 2001 4:05 AM
Ерунда!
Это весь ваш отстойный линукс - suxxx.
Нормальные люди давно себе VC++ купили, и радуются!
 

Skull - sibskullmail.ru
24 Aug 2001 4:43 AM
2муму: нормальные программеры могут хоть на
Фортране писать... И вполне хорошие программы. А
Вам, уважаемый господин, стоит привести резонные
доводы, по которым "ваш отстойный линукс -
suxxx"... А то кричать - все мастера, а
нормально общаться лишь немногие могут.
 

val
24 Aug 2001 5:16 AM
Dlya nauchnyh raschetov PGI Workstation klasnaya shtuka. Tam i C i C++ i Fortran i avtomaticheskoe rasparallelivanie. Napisal programmu, otladil, poshel na terminal Cray skompiliroval takim ze kompilyatorom i vse poschital za chasy. Licenziya toze sdravya dlya nauchnyh uchrezdenii - 50% discount, distributiv dlya Linux, Windows i Solaris plyus vtoruyu copiyu mozno postavit doma.
 

glassy
24 Aug 2001 7:11 AM
2му-му: Сорри, память подвела. Вспомнил я один конкретный глюк vcc. Время от времени начинает кричать "unexpected end of file".
Нормальные люди на VC++ не радуются. Они его ругают самыми разными словами, так что не 3.14zdи.
 

Egres
24 Aug 2001 9:06 AM
Народ, да что вы зациклились. Какая разница чей фирмы компилер. Главное какой разработчик!!!!
 

eXOR
24 Aug 2001 9:07 AM
2 муму && 2 Дурак:
Помнится здесь же на zdnet'е было сравнение GCC и MSVC... почитайте это дело еще раз перед тем как 3,14деть.
2 Дурак (отдельно):
Посмотри на оптимизационные ключи у GCC и у MSVC, да и вообще просто попробуй этим инструментарием хоть немного научиться пользоваться.
 

Вкуц
24 Aug 2001 10:41 AM
Хехе... Скажу честно и сразу. Под Линух не пишу. Не для кого. :) А вот по поводу "коммесческого сакс"....
Я вот проглядел тут как то свой комп и нашел что бесплатного на нем - максимум не очень большие утилиты (исключение по размеру - IE, но он условно бесплатен, поскольку надо купить Винду для него сначала). Все остальное - честно купленное. Даже Офис. Обычно я имею поглядеть софт, побаловаться с ним. А потом, если он меня устраивает, и стоит не запредельно, то я его покупаю. А если софт просто неподходит то я его не ставлю, даж если мне доплатят за это.

2 eXOR:
Ключи то ключами. Но они лишь незначительно учитывают особенности конкретного процессора. А спецкомпиляторы делают проги ЗАТОЧЕННЫМИ под него. Нормальные люди этим пользуются и пишут проги, которые различают тип оборудования, на котором выполняются и подгружают модули, скомпилированные именно для данного железа. Производительность так написанных прог может в РАЗЫ отличаться от тех, где просто ключами при компиляции поиграли. Примеры нужны? :)))))
 

Шел мимо, заглянул ...
24 Aug 2001 10:46 AM
У меня простой вопрос к высказывающимся тута. А ктонить щелкнул ссылочку, приведенную в канце статьи? Может ктонибудь знает альтернативу тому пакету софта, который перечислен по этому адресу? Расскажите пожалуйста. Тока не разрозненные источники, а именно - совместимое друг с другом и от одного производителя (такой штуки, как VTune, по моему даже у мелкомягких нету).
С уважением ...
 

alex_127
24 Aug 2001 11:28 AM
У мелкомягких есть аналайзер гораздо лучше - но его продавать нельзя ( сам не знаю почему - кажется какие-то патентные проблемы). Я и его пользовал и VTune много и знаю о чем речь

 

glassy
24 Aug 2001 12:14 PM
gcc vs vcc -- оффтопик.

Если Интел делает железо, то M$-ий аналайзер сразу станет бесполезным как только Интелу захочется.
Странная система -- продавать процы за ~400 и компилятор к нему отдельно за те же ~400.

И вообще, ссылка такого рода -- не показатель. Реклама и промоушен -- оно и в Африке необъективно.

А насчет офиса и ИЕ -- так у того же Ворда глюки с картинками, а ИЕ -- было раньше сказано, что он 404, 302, 303, 1.1, 39........
 

Igor
24 Aug 2001 12:21 PM
2 alex_127
И что это за аналайзер от MS, надеюсь не тот, что встроен в VC?
Пожалуйста ссылку...
 

Zaufi
24 Aug 2001 12:56 PM
2Вкуц: боюсь даже самым мордатым компилятором не увеличить в разы производительность... ибо код который генерят С/С++ ные компилеры с точки зрения asm'a довольно таки убог (как по набору используемых команд так и по части элегантности :) и поделать с этим чо либо оч проблемно. Для того чтоб твоя прога на сях летела надо и самому много чего делать... Пример:
2 куска кода в студию... :)
int a = ;
int b = ;
// 1)
if ((a == CONST_1) && (b == CONST_2)) {...}
// 2)
if ((a == CONST_1) & (b == CONST_2)) {...}
// 10 очков тому кто угадает (догадается) где код для if'a буит короче и быстрее... (мы говорим как минимум про Пни -- других компов нет уже :)
... и таких примеров мона привести массу -- смысле када оптимизацию нада проводить самому... ибо ни какой компилятор за вас это не сделает -- он попытается соптимизить ровно то что вы написали, и если ваша прога дрянь, оптимизированый вариант буит не в разы шустрее...
продолжая тему мордатого интеловского компилера: поле деятельности сишного оптимайзера на сам деле оч мало. Сишный код состоит из push/pop, mov/lea, sub/add, test/cmp, and/or/xor, call/enter/ret, shl/shr, load/stos ну и плюс их 16ти и 8ми битные разновидности, разного рода переходы по условиям и установка/очистка флагов -- максимум чо тут мона следать это подогнать под конвейеры и грамотно распределить работу с регистрами (многие из которых в сишном коде имеют строго определенное назначение).
Юзерские проги как паравило не трогают LDT/GDT/IDT, не лузут в MSW и кэши -- а если и надо то делается это на асме (где оптимизатор ваще как класс отсутствует (приверженцы TASM'a просьба не смешить народ :)). Юзери работают опираясь на кучу библиотек уходящих корнями в ОС. Или мордатый интеловский компилер поставляется со своим libc/libstdc++?? ... и своим ядром наконец? ;))
Вобчем лучше своя башка на плечах (и $300 в кармане :)
 

kvasim
24 Aug 2001 1:04 PM
2 Zaufi.
не скажи есть еще Sun..
который оптимизировал asm под C вызовы..
что было помешь push..
весть pusр у него помещается в кольцевой регистр..
( если конечно не очень большой..)
но появляется особенность надо писать с минумов пераметровв вы вызове.-.
и Suns C компилятор гараздо эфективней именно в разы иногда ( по крайней мере когда я с ними и gcc имел дело на нашем проэкте получилось раза в 3 !!!!! :).
а дял пентюде дейсвтельно все лажа..
( хотя штtetl й дума может использлватеь недокументированные особенности свеого процесоора :) как это делает MS :).
так что быдем ждать C/C++ от AMD ( вот он обгонит Inetl это точно)
как как у него внутри риск ( и можно да не на x86 командах программировать тоерктически :).

 

Zaufi
24 Aug 2001 1:05 PM
в догонку: да способами адресации сишный код также не блещит изысками... (что также ограничивает набор инструкций).
реальный пример из жисти :) -- в одной из dllек винды (та что отвечает за криптование файлов psw :) в самой главной подпрограмме кусок кода собственно шифрующий пасворд написан на асме (использует оч хитровы#$%тый xor) -- это НАСТОЛЬКО сильно бросается в глаза чо найти это место не составляет никакой проблемы (код данной инструкции уникален во всем файле)...
 

Zaufi
24 Aug 2001 1:10 PM
2kvasim: ясен пень я грил тока про intel... -- прочее всетки в совке экзотика :) На интелах gcc ОЧ хороший компилер (сам дрюкал его не однократно с целью посмареть чо он сделает в том или ином случае) и всякий раз восхищался :) -- оптимайзер под интелы у него дай Бог каждому... о чем авторы собсно и не скромничают.
 

wanderer - y6b6f7374696eyahoo.com
24 Aug 2001 2:00 PM
2Zaufi: "поле деятельности сишного оптимайзера на сам деле оч мало. Сишный код состоит из push/pop,..." - а какие команды могли бы увеличить скорость, но принципиально не могут быть использованы сишным компилятором?
 

glassy
24 Aug 2001 2:32 PM
Еще два куска в студию:
1:
for(i=0;i<10;i++)
for(n=0;n<100;n++){...};
2:
for(n=0;n<100;n++)
for(i=0;i<10;i++){...};
Кто-нибудь рискнет указать более скорый? :)
 

Шел мимо, заглянул ...
24 Aug 2001 6:06 PM
2 wanderer:
Ты чегонибудь о MMX, SSE, SSE2 слыхал (учитывая то, что говорим только об Intel'овских камнях).
Кстати, Intel'овский компайлер при особенных ключах может и эти инструкции юзать.
 

Bear
24 Aug 2001 7:08 PM
>Никогда gcc не дотянется до нормального >коммерческого софта. А для научых расчетов >просто неприменим: код, который он генерит >медленный, его производительность в разы (!!!!) >отстает от кода, который генерится тем же VC++.

А ты похоже даже не сравнивал,
а пургу метешь.
 

21264
24 Aug 2001 9:43 PM
насчёт не интелов могу сказать, что gcc весьма
не плохо смотриться на alpha 21264, сравнивал
простенькие векторно-матричные операции при
тупой максимальной оптимизации для обоих
компайлеров(-O_MAX_NUMBER_, без всяких unroll,
omit-frame-pointer и прочих fast опциях), gcc
проиграл родному DECовскому компайлеру
пару-тройку десятков процентов, но НЕ РАЗЫ.
Может быть уже память играла роль, а не код
сгенерённый компайлером, или ещё чего железное.
А насчёт VC++ для научных расчётов это кто-то
сдуру ляпнул, есть конечно тяжёлые случаи, но
они как правило от низкой квалификации учёных
как программистов(но не как учёных!!!), их
скорее надо относить в разряд анекдотов. Иногда
дело доходит до полных маразмов, рассказал мне
недавно аспер знакомый о том, как в его
лаборатории занимающейся генетикой
_вычислительные_ программы пишутся на яве - я
так давно не смеялся.
 

wanderer - y6b6f7374696eyahoo.com
25 Aug 2001 3:29 AM
2Шел мимо:
вопрос был "какие команды не могут быть использованы сишным компилятором"
твой ответ :"Кстати, Intel'овский компайлер при особенных ключах может и эти инструкции юзать."
Я что-то не пойму твоей логики.
 

alex_127
26 Aug 2001 3:17 AM
To Igor:
Единственная ссылка на него в интернете в
http://allbusiness.findlaw.com/agreements/expedia/expediamircosftlicenseagt.html

в разделе "Microsoft Internal Software"

и он не поставляется с VC. Он ни с чем не поставляется, это я просто упомянул к тому что не надо рассказывать что кроме интела никто такого написать не может.

glassy, вы что, думаете что Интел может запретить использование команды RTDSC кому-либо?
 

MAG
27 Aug 2001 3:49 PM
Привет ребята ! :))
Странные вы какие-то ! Зачем спорить, когда книги читать надо ?
я вот что вам скажу (например 2 Zaufi и иже с ним)-- абсолютно верно то, что проги не должны быть рыхлыми, но :
1) простое понимание того факта, что интеловский сопроцессор -- стековая машина, позволяет повысить производительность вычислений с плавающей точкой до 2-х раз, и уважающий себя компилятор обязан уметь это делать (думаю что и gcc и msvc чувствуют тут себя прекрасно), чего я не скажу о программере, который пишет портабельные вещи и, соответственно, просто не имеет права(!!!!) баловаться с ASM-ом
2) а вот заточить под векторную обработку -- совсем другое дело ! если до кого-нить не догоняет, что это не раз плюнуть делать, то прошу почитать спеки на Итаниум на сайте интела для девелоперов, кому надо -- найдёт. А идея в том, что эта пакость умеет строить некие "софт"-конвейеры вычислений, то есть векторизовать обработку данных по произвольному алгоритму (за счёт чего имеет по полной программе все другие архитектуры на математике). Так вот для того чтобы проделать этакий фокус нужно знать время отработки каждой инструкции такого конвейера измеренное в циклах процессора ещё на этапе компиляции, а от процессора к процессору оно может меняться !!!! В результате при использовании ЗАТОЧЕННОГО ФИРМОВОГО КОМПИЛЕРА на математике можно получить выигрыш не в разы, а в десятки _РАЗ_ !!!!!
3) Интеловский компилер имеет все шансы уделать и "гнусный", и "мелкомягкий" и всех кто под руку попадётся !
3.1) кстати, для мат. вычислений всё же больше используется фортран, и рассказывать о том как на С и С++ писать просто незачем...
3.14 :) короче для тех кто даже обзорно не знаком с этими вещами -- RTFM !

З.Ы.
Дабы не сложилось неверное мнение -- я очень хорошо(надеюсь :) знаком с аля'PC архитектурами и обзорно с суперЭВМ и векторизацией вычислений (не путать с "поверхностно" :)

З.Ы.Ы.
На провокации и тесты на вшивость не ведусь, а в том что я написал -- прошу усматривать руководство к действию и чтению литературы :)).
 

Zaufi
28 Aug 2001 3:42 AM
2wanderer: ... не трогая интеловские изобретения (т.е. оставаясь в рамках ANSI C) набор команд могли бы пополнить к примеру следующие: кучка loop'ов, cемейство bt, cbw/cwd/cwde/cdq, movzx/movsx... -- это что реально может пригодиться (быть использовано). При имении мордатого оптимизатора мона было бы и заюзать еще например pusha/popa (елибы оптимайзер заметил бы что в попрограмме будут заюзаны все регистры), команды сравнения/сложения с обменом, bswab, xlat...
современным оптимайзерам еще есь куда рости... хотя может быть разработчики заботятся о том чоб программеры не состарились компиляя их компилятором :) (объемы прог всетки растут непомерно... 1 час (или больше) на компиляцию в принципе терь не такая уж редкость)
 

Zaufi
28 Aug 2001 3:49 AM
2Шел: gcc'a тожа умеет с MMX... НО, ясен пень эт все не выходит за рамки ANSI C. А в стандарте нет типов данных заточеных под MMX/SSE/SSE2 -- соответсна в твоей проге не может появиться строк требующих заюзывания данных расширений. Максимум на что MMX годится для обычных прог это чуть (up to 30%) ушустрить работу со строками.
 

Zaufi
28 Aug 2001 4:10 AM
2MAG: а собсно никто тут и не спорит... (ну разве что дураки тока :) Просто в статья вводит некоторых читателей в заблуждение чо с выходом этих компиляторов gcc перестанет рулить :) (ну или чото вроде того). Второй абзац ме ваще не понятно к чему сюда влепили...
2Всем кто думает чо пересобрав свои проги новым компилером они получат улучшение производительности в РАЗЫ: RTFM, RTFM b еще раз RTFM (c) Ленин.
Детище интела не что иное как нижеупомянутый СПЕЦ.КОМПИЛЯТОР. Чобы заюзать все новые фичи интеловых камней они добавили туда кучу расширений (intrinsics) позволяющих вам работать с новыми типами данных и операциями НЕ ДОСТУПНЫМИ в ANSI C. Говоря проще: чобы в вашей проге появились команды MMX/SSE/SSE2 нада буит ее переделать т.е. отказаться от портабельности на не интеловские платформы. Причем переделка буит далеко не тривиальной как справедливо заметил MAG. Ну и для большей ясности: еси вы не работаете с КРУТОЙ 2D/3D графикой или какойньть навороченой математикой НИФИГА ОТ ЭТОГО КОМПИЛЕРА ВЫ НЕ ВЫИГРАЕТЕ! (ну разве что приз на конкурсе "построителей гемороев" :)
 

eXOR
28 Aug 2001 8:15 AM
2 Zaufi:
О! Вот на этой радостной ноте можно и закрывать ветку ;-))). Как раз то, чего не хватало в статье для полноты изложения.
 

Igor
28 Aug 2001 10:22 AM
2 alex_127:
Ну и как он называется и чем он лучше?
 

glassy
30 Aug 2001 9:21 AM
2alex_127: думаю :). Теоретически это всегда возможно.
2MAG: подожду порядочных бенчмарков. Надеюсь, zdnet даст знать о сверхзвуковых скоростях скомпиленных прог :)
2all: Почему есть-таки некоторые, свято верящие в разы и в десятки раз?
 

pers
31 Aug 2001 12:18 PM
2Zaufi "чобы в вашей проге появились команды MMX/SSE/SSE2 нада буит ее переделать т.е. отказаться от портабельности на не интеловские платформы"
может я ошибаюсь, но кроме интел-процов где еще используются всякие ммх'ы
если уж надо програмить с использованием ммх'ов то ни о каких других процах програ работать не будет
ну а на счет конкурса, я с тобой полностью согласен
 

 

← июль 2001 17  20  21  22  23  24  27  28  29 сентябрь 2001 →
Реклама!
 

 

Место для Вашей рекламы!