|
maxposedon
|
icc действительно иногда побыстрее других кампиляторов
но скорость достигается за щет оптимизации кода
а не за щет оптимизации вызовов libc-функций
так что icc ничерта не ускорит....
|
|
|
|
|
Записан
|
|
|
|
iced
Гость
|
Насчет асмового либц: к cl его надо подключать ручками, т.е. через настройки линкера. всё. приплыли. то есть статически линкуем с либцами (быстрыми). гы гы. поиграю в настрадамуса опять. тебе лет 20. проработал ты ровно 0 дней за свою жисть. все `знания` тока с универа. PS. и ты случаем не один из аффторов |
|
|
|
|
Записан
|
|
|
|
iced
Гость
|
2maxposedon: ты тупой, да? тебе же ясно сказано - на ассемблере! быстрая! а ты со своими ссе привязался.
|
|
|
|
|
Записан
|
|
|
|
iced
Гость
|
а ассемблерный код собираетсяо icc (со всеми оптимизациями ссе и прочими) и линкуется статически. ыыыы. у меня сейчас истрерика случиццо.
|
|
|
|
|
Записан
|
|
|
|
|
Archi
|
icc действительно иногда побыстрее других кампиляторов Это тормозной компилятор, который генерит код, оптимизированный под Intel. 2All : В жизни не видел libc, оптимизированного под mmx/sse. 2IceD : Пожалуйста прекращай истерику и пиши по теме. Лично мои мозги под телепатию не оптимизированы. |
|
|
|
« Последнее редактирование: 09 Апрель 2006, 20:18:43 от Archi »
|
Записан
|
У меня дикая аллергия на тупость. Я сразу покрываюсь сарказмом.
|
|
|
|
spammer
|
Я может тупой, но что вызывает такой дикий приступ нездорового веселья в зале? Объясните 20-ти летнему человеку, проработавшему ровно 0 (ноль) дней, и почерпнувшему весь свой небогатый багаж "знаний" из прослушанных курсов университета. Я их менеджер... |
|
|
|
« Последнее редактирование: 09 Апрель 2006, 21:49:28 от spammer »
|
Записан
|
|
|
|
|
spammer
|
2maxposedonобщая оптимизация идет под 32-х битный x86-совместимый процессор. можно посмотреть, почему это действительно будет работать быстрее дефолтного сишного кода. Специфические оптимизации (sse, 3dnow, и т.п.) в данный момент либо отсутсвуют, либо покупаются у Майкрософт за денюжку, либо их надо очень хорошо поискать в интернете. Вопрос о том, что, к примеру, оптимизация под 3dnow не запуститься на intel-е, остается открытым. Поэтому дефолтная оптимизация пускается везде.
|
|
|
|
« Последнее редактирование: 09 Апрель 2006, 21:51:40 от spammer »
|
Записан
|
|
|
|
|
maxposedon
|
2maxposedonобщая оптимизация идет под 32-х битный x86-совместимый процессор. можно посмотреть, почему это действительно будет работать быстрее дефолтного сишного кода. Специфические оптимизации (sse, 3dnow, и т.п.) в данный момент либо отсутсвуют, либо покупаются у Майкрософт за денюжку, либо их надо очень хорошо поискать в интернете. Вопрос о том, что, к примеру, оптимизация под 3dnow не запуститься на intel-е, остается открытым. Поэтому дефолтная оптимизация пускается везде. слава богу вы что-то поняли.... 1.в Linux gcc собирает С ОПТИМИЗАЦИЕЙ под процессор, с ПОЛНОЙ (стараются)... 2.те на моем компе он соберет LIBC так что внутри будут sse/sse2/mmx инструкции на твоем что-то другое... 3. libc в Linux стыкуется динамически - и поетому бинарь что у тебя. что у меня запустится. 4. естесвенно с оптимизацией под процессор (sse/mmx) libc начинает работать быстрее 5.а теперь главное: РАЗ Libc написан на C - ТО его ЛЕГКО собрать с оптимизацией под процессор, и естесвенно работать он за щет етого будет быстрее, и именно потому: что asm-овский код не переносим LibC лучше держать написаным на C - чтоб можно было всегда пересобрать его, под новый процессор ВОТ откуда вылезли IceD-овские проценты, и ВОТ почему в Linux отработало быстрее, и ИМЕННО поетому у MSVC резалты будут похуже что с cl, что с icc 6.и еще... Специфические оптимизации (sse, 3dnow, и т.п.) - по секрету Microsoft не имеет к ним НИКАКОГО отношения, неужели даже то не понятно? - ето спеки на набор инструкций и кстати вполне открытые. amd например совсем не собираются писать кампиляторы... 7.Вопрос о том, что, к примеру, оптимизация под 3dnow не запуститься на intel-е, остается открытым. - ето уже проблемы OS Windows - в Linux как я уже говорил libc подключается динамически (по умолчанию), а механизм распространения исходниками никто не отменял.... 8.а не использование расширеных инструкций процессора(mmx/sse) ето вообще путь в никуда. ведь именно за щет качественных канвееров разбора команд и расширеных инструкций достигается высокое повышение произодительности в мультимедиа задачах. ведь именно процессоры Amd маркируются с рейтингом(там архитектура ядра МНОГО лучше Intel-овского). и они МНОГО быстрее своих Intel сородичей с той же частотой. |
|
|
|
|
Записан
|
|
|
|
|
maxposedon
|
а приступ смеха вызвает то, что вы почему-то думаете что мир ограничен Windows и x86
вы как-небудь посмотрите СКОКА существуют других архитектур процессоров,
узнайте что больше всего продаж ОС приходится на рунок handy-устройств например (КПК/Телефоны)
и задумайтесь....
может таки за С будущие системного програмирования, и может таки asm-блер ДАВНО умер? (кроме
ОЧЕНЬ уского списка задач)
|
|
|
|
|
Записан
|
|
|
|
|
maxposedon
|
вот пример...
основная часть кода strlen из glibc(всякие NULL проверки я опустил)
/* Instead of the traditional loop which tests each character,
we will test a longword at a time. The tricky part is testing
if *any of the four* bytes in the longword in question are zero. */
.....
const char *cp = (const char *) (longword_ptr - 1);
if (cp[0] == 0)
return cp - str;
if (cp[1] == 0)
return cp - str + 1;
if (cp[2] == 0)
return cp - str + 2;
if (cp[3] == 0)
return cp - str + 3;
if (sizeof (longword) > 4)
{
if (cp[4] == 0)
return cp - str + 4;
if (cp[5] == 0)
return cp - str + 5;
if (cp[6] == 0)
return cp - str + 6;
if (cp[7] == 0)
return cp - str + 7;
}
}
можно заметить что код ОЧЕНЬ похож на тот asm-овский
и я УВЕРЕН что кампилятор згенерирует код как минимум не хуже
но тут перед вами ПРИМЕР ПРИЕМУЩЕСТВА C кода
ВСЕ k8 процессоры (athlon64,>sempron3000) ОПТИМИЗИРОВАНЫ под передачу данных пачками по 64bit (ДАЖЕ в 32-битном режиме), ТВОЙ asm код бы на ето "забил" и работал бы медленние
|
|
|
|
« Последнее редактирование: 09 Апрель 2006, 22:40:46 от maxposedon »
|
Записан
|
|
|
|
|
spammer
|
Со всем вышенаписанным согласен. Хочу только отметить, что Intel Compiler расчитан именно на Intel процессоры, и, следовательно, весь код оптимизирован исключительно под них. Можно собирать его под каждый процессор по-новому, а можно и переписать для каждого нового процессора на асме (благо количество Intel-процессоров довольно невелико). Плюсы этого подхода - МАКСИМАЛЬНАЯ оптимизация (компилятор никогда не сгенерит код, равный по производительности написанному профессионалами с учетом всех особенностей конкретного процессора).
|
|
|
|
|
Записан
|
|
|
|
iced
Гость
|
Это тормозной компилятор, который генерит код, оптимизированный под Intel. ложь. icc очень неплох. особенно для математической хрени (пофиг под какой проц). 2All : В жизни не видел libc, оптимизированного под mmx/sse. заходи, посмотри. Я может тупой, но что вызывает такой дикий приступ нездорового веселья в зале? непоследовательный бред который ты несёшь. то у тебя сначала мсовский либц был написан на ассемблере. потом оказалось что на си, а ассемблерный надо ставить самому. причём зачем то компилить icc. общая оптимизация идет под 32-х битный x86-совместимый процессор. Тут можно посмотреть, почему это действительно будет работать быстрее дефолтного сишного кода. а что делать владельцам амд64?!? Специфические оптимизации (sse, 3dnow, и т.п.) в данный момент либо отсутсвуют, либо покупаются у Майкрософт за денюжку, либо их надо очень хорошо поискать в интернете. на сайте майрософта ничего такого нету. я плохо искал? Вопрос о том, что, к примеру, оптимизация под 3dnow не запуститься на intel-е, остается открытым. Поэтому дефолтная оптимизация пускается везде. у меня амд. мне что не использовать 3dnow только потому что какой-то дятел написал код на x86 ассемблере? фпень. а приступ смеха вызвает то, что вы почему-то думаете что мир ограничен Windows и x86
вы как-небудь посмотрите СКОКА существуют других архитектур процессоров, та одинх x86 зоопарк целый. терь ещё и amd64. и я УВЕРЕН что кампилятор згенерирует код как минимум не хуже лучше, лучше. ибо нормально расспаралелить инструкции человек просто не сможет. неподъёмная задача. |
|
|
|
|
Записан
|
|
|
|
iced
Гость
|
Хочу только отметить, что Intel Compiler расчитан именно на Intel процессоры, и, следовательно, весь код оптимизирован исключительно под них. бред. Можно собирать его под каждый процессор по-новому, а можно и переписать для каждого нового процессора на асме (благо количество Intel-процессоров довольно невелико). невелико. да. штук 30 всего вариаций. Плюсы этого подхода - МАКСИМАЛЬНАЯ оптимизация (компилятор никогда не сгенерит код, равный по производительности написанному профессионалами с учетом всех особенностей конкретного процессора). сгенерит. поверь мне. даже если ты найдёшь профессионала владеющего mmx, mmx2, sse, sse2, 3dnow, 3dnow2, что-там ещё было. и умеющего правильно распаралелить инструкции. |
|
|
|
|
Записан
|
|
|
|
|
spammer
|
непоследовательный бред который ты несёшь. то у тебя сначала мсовский либц был написан на ассемблере. потом оказалось что на си, а ассемблерный надо ставить самому. причём зачем то компилить icc. процитируй, пожалуйста, именно мой "бред". я утверждал (и не отказываюсь от этого), что системные функции надо писать на асме, так как они - узкое место любой системы. теперь покажи мне, где я говорил, что в MS VC по умолчанию используется асмовский вариант? имеено поэтому последовало мое второе утверждение, что для использования по умолчанию асмовских функций надо включить Intel Compiler. ты, видимо, читаешь через пост или вообще задом-наперед =) |
|
|
|
« Последнее редактирование: 10 Апрель 2006, 01:35:20 от spammer »
|
Записан
|
|
|
|
|
spammer
|
Я так понял, вопрос сошелся к тому, из чего и произошел: стоит ли писать асмовый код системных функций руками или компилятор сделает все быстрее и лучше?
Мое имхо - стоит.
|
|
|
|
|
Записан
|
|
|
|
|
maxposedon
|
Я так понял, вопрос сошелся к тому, из чего и произошел: стоит ли писать асмовый код системных функций руками или компилятор сделает все быстрее и лучше?
Мое имхо - стоит. 1. мля... е мае.... ЗАЧЕМ??? то что написано будет МЕДЛЕННЕЕ чем сгенерит кампилятор - факт 2. Зачем утяжелять узкое место, а?... 3. если таки найдется специалист по всем 3dnow то давайте подщитаем надо написать код оптимизированы под ~5 архитектур хотя бы самые основные (от i386 до amd64) для написание такого кода понадобится x3 программиста. прирост ТЕОРЕТИЧЕСКИЙ (не практический) 10%, а ЗАРПЛАТА уменьшится в 3 раза. 4. я уже не говорю что есть спецы по asm-у например в радиусе 100километров от Гродно 5. что за привычка оптимизировать что не попадя? Нет ничего хуже чем преждевременная опцимизация © Кнут 6. я УВЕРЕН что твои app будут тормазить не потому что функции медленные, а потому что ты массив будеш сортировать пузырьком (пример грубой, но достаточно показательный) 7. неужели так ТРУДНО понять что счас в основном главное ето СКОРОСТЬ разработки, именно поетому НЕ кампилируемые языки шагают по миру... |
|
|
|
« Последнее редактирование: 10 Апрель 2006, 02:05:43 от maxposedon »
|
Записан
|
|
|
|
|
spammer
|
Для критичных по скорости задач важна максимальная оптимизация. Для остальных согласен, 10% прироста можно легко пожертвовать в пользу стоимости и скорости разработки.
|
|
|
|
|
Записан
|
|
|
|
|
spammer
|
Да и не надо для каждой задачи заново переписать либц. Это делается один раз с выходом нового процессора, делается специальными людьми, которым за это платят, а не кустарными специалистами.
|
|
|
|
|
Записан
|
|
|
|
iced
Гость
|
процитируй, пожалуйста, именно мой "бред". я утверждал (и не отказываюсь от этого), что системные функции надо писать на асме, так как они - узкое место любой системы. теперь покажи мне, где я говорил, что в MS VC по умолчанию используется асмовский вариант? показываю. А в почему такой ажиотаж, что оптимизированный асмовый код делает дефолтный сишный? Это подразумевается. Потому все критичные по скорости библиотечные сишные функции (обработка строк, работа с памятью, и т.п.) и написаны на асме. вариант с тем что по умолчанию не ассемблер был гораздо позже - когда я потестил что вентовые либцы (которые таки на ассемблере по твоим словам писаны) сливают. более того. ты совсем бред несёшь. `ms vc` тут не причём. либцы - это часть ОС, а никак не дев среды. имеено поэтому последовало мое второе утверждение, что для использования по умолчанию асмовских функций надо включить Intel Compiler. ещё более бредовое чем предыдущее. Для критичных по скорости задач важна максимальная оптимизация. Для остальных согласен, 10% прироста можно легко пожертвовать в пользу стоимости и скорости разработки. и именно поэтому `критичные по скорости` задачи пишут на сях. |
|
|
|
« Последнее редактирование: 10 Апрель 2006, 14:00:08 от iced »
|
Записан
|
|
|
|
iced
Гость
|
Да и не надо для каждой задачи заново переписать либц. Это делается один раз с выходом нового процессора, делается специальными людьми, которым за это платят, а не кустарными специалистами. ёпрст. НИКТО НЕ ПЕРЕПИСЫВАЕТ ЛИБЦ. даже в мелкософте. дай линку на данную инфу или повесь себе на шею табличку `п#здун`. |
|
|
|
|
Записан
|
|
|
|
iced
Гость
|
погуглил. и в мсдне посмотрел. не нашёл. давай линк.
|
|
|
|
|
Записан
|
|
|
|
|
spammer
|
Ув. IceD, еще раз прошу отквотить такие мои утверждения как: 1. Libc в Windows написан на ассемблере. 2. В фирме Microsoft переписывают Libc под каждый новый процессор. А выводы, полученные непонятным образом на основе моих утверждений, можете оставить для своей больной фантазии. Вместе с табличкой "п**дун". Данное утверждение более того. ты совсем бред несёшь. `ms vc` тут не причём. либцы - это часть ОС, а никак не дев среды. комментировать не берусь, лишь спрошу: отчего же тогда эти либы лежат в папочке MS VC? |
|
|
|
|
Записан
|
|
|
|
iced
Гость
|
твоюмать. Ув. IceD, еще раз прошу отквотить такие мои утверждения как:
1. Libc в Windows написан на ассемблере. квотю. Потому все критичные по скорости библиотечные сишные функции (обработка строк, работа с памятью, и т.п.) и написаны на асме. Как-нибудь повтыкай папочку С:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\crt\src\intel\ или как там она у тебя назывется там лежит хороший ОПТИМИЗИРОВАННЫЙ код [/quote] после приведения результата тестов: По дефолту берется дефолтный либц - т.е. сишный. Асмовый включается Intel Compiler'ом. пошёл очередной бред. ещё раз для идиотов. КАКАЯ РАЗНИЦА КАКОЙ СИ КОМПИЛЕР СОБЕРЁТ АССЕМБЛЕРНУЮ ХРЕНЬ?!? далее, ты в упор не понимаешь как работает компилер/линковщик. то что идёт с m$vs никоим образом не относится к либц. это какие-то исходники чего-то. вполне вероятно что это исходники вентового либц. если ты захочешь собрать эти исхоники мегаоптимизирующим icc (который есессно соптимизирует x86 ассемблер под разные mmx и прочие) то тебе придётся поставлять данную либу со своей прогой (такого не видел) либо линковать статически (такого тоже не видел). --- 2. В фирме Microsoft переписывают Libc под каждый новый процессор. пжалста: Специфические оптимизации (sse, 3dnow, и т.п.) в данный момент либо отсутсвуют, либо покупаются у Майкрософт за денюжку, либо их надо очень хорошо поискать в интернете. Да и не надо для каждой задачи заново переписать либц. Это делается один раз с выходом нового процессора, делается специальными людьми, которым за это платят, а не кустарными специалистами. --- комментировать не берусь, лишь спрошу: отчего же тогда эти либы лежат в папочке MS VC? для тех кто ленится почитать доки. в венте либц это msvcrt.dll которая лежит в %WINDOWS%/system32 (или какая там енв переменная для вентового дира). то что лежит в дире m$vs - см выше. можешь попробовать собрать любую аппу clем или icc и посмотреть что оно компилит и с чем линкуется. --- резюмирую: 1. разберись что такое libc, си компилятор, линковщик, ассемблер (не язык а тулза). 2. разберись и скажи в венте из коробки таки идут libc на си или на ассемблере (что с чем я тестировал то). 3. если в венте из коробки идут libc на си, найди мне пример хоть одной проги собранной с быстрыми либцами на ассемблере (можно проверить вентовым аналогом ldd - depend walker или как там его). 4. если не найдёшь такой проги - дай мне чёткие инструкции как собрать мою прогу с быстрым ассемблерным libc. |
|
|
|
|
Записан
|
|
|
|
|
spammer
|
Короче, твою логику по выводу хитрых заключений я так и не понял (я попросил отквотить конкретные и однозначные высказывания - таковых не было), ну да и ладно. Постараюсь собрать прогу с быстрым libc в самом скором времени.
|
|
|
|
|
Записан
|
|
|
|
iced
Гость
|
Короче, твою логику по выводу хитрых заключений я так и не понял какая логика? там прямым текстом всё. Потому все критичные по скорости библиотечные сишные функции (обработка строк, работа с памятью, и т.п.) и написаны на асме. по слогам: ВСЕ КРИТИЧНЫЕ СИШНЫЕ ФУНКЦИИ НАПИСАНЫ НА АСМЕ. так как дальше ты стал кидаться примерами из m$vs - то ясно что это происходит в венте. где я неправ? прямое утверждение что либц пишется на ассемблере в майкрософте (с приведением исходника). потом противоположное заявление - что оно пишется на си (но есть и ассемблерная версия, которую надо зачем то собирать icc). |
|
|
|
|
Записан
|
|
|
|
iced
Гость
|
Постараюсь собрать прогу с быстрым libc в самом скором времени. то есть по умолчания либс (вентовый) медленный. что прямо противоречит. Потому все критичные по скорости библиотечные сишные функции (обработка строк, работа с памятью, и т.п.) и написаны на асме. |
|
|
|
|
Записан
|
|
|
|
|
spammer
|
IceD, ок, в некоторых моментах я был не совсем прав. Но я не имел ввиду что виндосовские либы написаны на асме. Это уж так скорее показалось из моего поста.
|
|
|
|
« Последнее редактирование: 10 Апрель 2006, 20:14:58 от spammer »
|
Записан
|
|
|
|
iced
Гость
|
так так так. а КАКИЕ либы на ассемблере написаны то?
|
|
|
|
|
Записан
|
|
|
|
|
spammer
|
Виндосовские =) Но -->НЕ<-- дефолтные. Если интересно, то можешь взять архивчик - это папка msvc/vc7/crt/intel |
|
|
|
« Последнее редактирование: 10 Апрель 2006, 21:39:37 от spammer »
|
Записан
|
|
|
|
iced
Гость
|
ёпрст. НЕ ХОЧУ. ты покажи где оно в диком виде водиццо.
PS. я кстати понял откуда ростут ноги что `надо собирать icc` - intel в данном случае не имеет отношения к icc - это они просто криво обозвали x86.
|
|
|
|
|
Записан
|
|
|
|
|
: 1 2 3 5 Далее» Все Вниз