по поводу String - теста(см.ссылку выше) : мне думается что причина отставания VC действительно кроется в MFC.К этому выводу меня приводит также следующая ссылка:

http://gcc.gnu.org/onlinedocs/libstdc++/21_strings/howto.html

наверняка в операторе += какая-нибудь лажа

2Ogr

>Тебе дать url с документацией по процессору и попросить тебя ею >воспользоватся при оптимизации руками? :) Или сам уже понял какую чушь >сказал? Оптимизация асемблера руками это критинизм достойный студента >первого курса заборостроительного техникума.

Этапиздец, дорогая редакция. Давай, Огр, давай, ты доставляешь немало весёлых минут :))))

Помнится, в прошлый раз я так же громко смеялся, когда ты про библиотеки для построения интерфейсов рассуждал. Бис! Хлеба и зрелищ!

ДВ

> Оптимизация асемблера руками это критинизм достойный студента первого
> курса заборостроительного техникума.

Прикольно, я вот давно хотел узнать, где учились програмить создатели mysql и mplayer ;)

2anonymous (*) (2002-01-31 03:07:41.0): "Помнится, в прошлый раз я так же громко смеялся, когда ты про библиотеки для построения интерфейсов рассуждал"
Я не совсем понимаю, про что ты говоришь, но по всей видимости с тех пор ты так и не поумнел.
2anonymous (*) (2002-01-31 03:38:53.0): "Прикольно, я вот давно хотел узнать, где учились програмить создатели mysql и mplayer ;)"
Ну то что авторы майскюля там учились сомнению просто не подлежит. Ровно так же не подлежит сомнению что именно в этом учебном заведении учишся ты, т.к. не способен отличить когда используют асемблер для использования мултимедиа расширений, наглых хаков для вызова виндосовских dll от случаев где делается оптимизация.

Кому интересно посмотрите результаты которые дает ИСС на виндах по сравнению с другими платформами на Степановской бенчмарке. Это типа про плату за абстракность кода: http://www.ne.jp/asahi/galina/home/stepanov/

Я пробовал какую-то старую версию 4.5 для виндов полтора года назад. Если кто попробует на линуксе - пришлите результаты, плз

Вова vladimir-mp3@mail.com

Ogr фанат M$, а они masm уже забросили. Какой вывод? Крутый паацааны не программируют на асме. Все, типа, на ВеЦе пересели.

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

Опус первый: Линух ядро + либы...
После 2-х дневных (в пред. итерации маялись месяц, но бросили), запустили небольшим кол-вом ядро 2.4.17 скомпилённое на ИСК - правок много, кое-что не работает (не в смысле базовых модулей :):), а из дров и аддонсов)... В первую очередь, кстати, выяснилось - что новая система работы с дровами полное дерьмо...
Субъективных выигрышей не отмечено, тесты (fork, SIGх, exchange, fopen...) - дают выигрышь в сторону ИСК на 5% - 10%... Устойчивость работы - никакая :)... Интересно то, что объпрелинк работает и над ИСК кодом, и тоже получается выигрышь по вызовам :)...
Размер ядра стал больше
Объяснимо всё базовой идеологией ядра - уж какая есть...

Опус второй: Ядро Mach32 + либы
Тут послаще, само ядро - что очень естессьно, :), не дало никакого выигрыша, однако по модулям картинка неоднозначная - если взять "толстую" конфигурацию (т.е. обилие модулей) то тогда даёт выигрышь система на ГКК (и понятно, объёмы свободной памяти больше - всё лучше)
прецентов эдак на 10-20 (полусубъективная оценка), если взять "тощую" конфигурацию (самый минимум: ядро, модули стека тцп, файловая система... может чего и забыл) - то интёл даёт пречентов до 10 выигрыша... Результ: На десктоп Маха компИлим интЁлом, на сервер - гнём всё...

Опус третий: маненечко флейма
А пофигу чем компилить, если объпрелинк всю муйню оптимизит (для интЁлов).
Огру, программист, не умеющий писать на ассемблере - просто кодировщик , если не забыл :)
Насчёт МП3 либ под видео и.т.п. ещё кто у кого чего содрал, мелкомягкие никогда не славились хорошим знанием ЦОС, всё ими используемое прикуплено на стороне (база), есть маненько и стянутого, ну а в общем, по бенчам, ничего выдающегося... Почему они были одно время впереди? - да потому что никому в то время нафиг МП не нужно было... :)

Для полноты картины еще два нехороших свойства icc. Одно просто нехорошее, второе - очень нехорошее. Сначала просто нехорошее. Формат сообщений об ошибках *очень* сильно отличается от gcc, что сильно затрудняет интеграцию icc в различные IDE. Теперь очень нехорошее. Бинарники, производимые icc, динамически прилинкованы к библиотекам, идущим с компилятором => нет никакой возможности распространять бинарники, произведенные icc. Про распространение интеловких библиотек вместе с, допустим, моим софтом просьба не заикаться.

А есть ли проблемы с include файлами в icc?

А есть ли проблемы с include файлами в icc?

А есть ли проблемы с include файлами в icc?

Тут что-то все о C, а я вот скажу о Фортране. Пересобрал интеловским компилятором MODTRAN (это такая модель радиационных свойств атмосферы, развитие модели LOWTRAN). Выигрыш в скорости вычислений по сравнению с GNU Fortran (2.95.3) --- 2,5 раза! Я в шоке. Размер бинарника, генерируемого Интелом больше, но это совершеннно неважно при таких результатах.

2DronK: кстати, fortran из того же пакета отламывается так:
ifc(size 497293)
offset e443, правим c7 04 24 48 46 на e9 12 02 00 00

Могет кто таки собирал чего-нть из системных либ (вроде Binutils) на icc ? А то без большого напильника ничего практически не собирается...

Старый пионэр

2anonymous про инклуды

icc -I/opt/intel/compiler50/ia32/include -I/usr/include -X my_file.C

Intel C/C++ быстрее чем GCC?

Я провел тест stepanov.cpp для 20000 прогонов

./intel 20000

0.15 266.67M 1.0 0.15 266.67M 1.0 .....

Total absolute time: 6.47 sec Abstraction penalty: 2.29

./ggg 20000

0.15 266.67M 1.0 0.15 266.67M 1.0 .....

Total absolute time: 2.36 sec Abstraction penalty: 1.12

Сам комментировать ничего не буду, интересно бы получить комментарии участников форума.

Замечу, что для библиотеки WINGs субъективно выигрыша icc перед gcc не дает никакого.:)

Stariy Pioner: mozhet ty esche slomal noviy PGI F77? V f90 oboyti flexlm udaetsa, v f77 - malEn'ko net.

AK

Pioner,

> fortran из того же пакета отламывается так:
> ifc(size 497293)
> offset e443, правим c7 04 24 48 46 на e9 12 02 00 00

U menia po offsetu e443 - 6c 3b 09 08 89,
a c7 04 24 48 46 voobsche v file net.

sorry, это от icpc - чего то я повторяться начал.
Правильные байты для ifc:
offset ece3, правим с7 04 24 40 60 на e9 12 02 00 00

По заказу я на халяву ничего не ломаю (может только ребра)

Старый пионэр

> sorry, это от icpc - чего то я повторяться начал.
> Правильные байты для ifc:
> offset ece3, правим с7 04 24 40 60 на e9 12 02 00 00

thank, srabotalo na perviy vzgliad.

> По заказу я на халяву ничего не ломаю (может только ребра)

da ladno, tam kstati rabota ne dlia tebia - nado sdelat' bol'she
treh pravok :)

AK

Взлом KAI C++

> kfront (size 2847600) > Offset 2ad2e8, меняем первый 0 из 00 00 00 00 a0 a8 20 08 на 1 > kfront-thin (size 1775660) > Offset 1ac888, меняем первый 0 из 00 00 00 00 84 5b 16 08 на 1

Поясните, это означает, что строчки "00 00 00 00" должны стать "01 00 00 00" ??

Спасиба.

Взлом KAI C++

> kfront (size 2847600)
> Offset 2ad2e8, меняем первый 0 из 00 00 00 00 a0 a8 20 08 на 1
> kfront-thin (size 1775660)
> Offset 1ac888, меняем первый 0 из 00 00 00 00 84 5b 16 08 на 1

Поясните, это означает, что строчки "00 00 00 00" должны стать "01 00 00 00" ??

Спасиба.

Опыт использования icc, gcc, Portland Group C показывает, что на
хорошо написанном коде разницы практически нет. Иногда получается, что программа компилированная с максимальной оптимизацией пакетами
Intel и Portland Group работает на 10-15 процентов медленее откомпилированной gcc с оптимизацией -O2 (это касается и фортрана).
При компиляции пакета LINPACK часть методов работает быстрее с кодом
сделанным одним компилятором, часть с другим и про явное преимущество
коммерческих компиляторов над gcc говорить нельзя. Достаточно хорошие
результаты получаются при компиляции Коммерческими пакетами небрежно
написанного кода, типа квантово-химических пакетов Gaussian и Gamess,
но и то скорость работы сильно зависит от качества написанного модуля.
Зачастую код откомпилированный пакетами Intel и Portland Group не
отличается стабильностью работы, даже на платформе Windows. Эти выводы
сделаны на основе 3х летнего опыта работы и компиляции квантово-
химических пакетов вышеупоминавшимися компиляторами.

2anonymous (*) (2002-01-31 19:26:05.0) Ну, вот, началась пьнка. Небрежно написанный код. Ну так дайте нам примеры "брежно" написанного кода, чтоб мы убедились на собственном опыте, как это gcc генерит код хотя бы похожий по скорости на icc. Мне вот чтой-то уже не верится, что такое возможно. icc *действительно* существенно быстрее gcc на *всех* алгоритмах, на которых я их сравнивал. Примеры могу привести, если кому надо, да их уже приведено полно. Да, еще дайте-ка нам примеров "брежного" кода, на котором icc работает нестабильно. Очень интересно. Уж выход-ли за границы массива случайно в этом "брежном" коде имеет место быть.

Stepanov Benchmark

Niks, интэресно... Глазам не верю. Оптимизацию отключили что-ли? И что за комп? Полные данные, включая параметры компиляции плз.

У меня на Pentium III 600Mhz, Win2000, Intel C++ 4.5 /O2 /G6 \Benchmarks\Stepanov\Intel>stepanov 20000

test absolute additions ratio with number time per second test0

0 0.21sec 190.48M 1.00 1 0.20sec 200.00M 0.95 2 0.20sec 200.00M 0.95 3 0.21sec 189.57M 1.00 4 0.20sec 200.00M 0.95 5 0.21sec 190.48M 1.00 6 0.20sec 199.00M 0.96 7 0.20sec 200.00M 0.95 8 0.21sec 190.48M 1.00 9 0.20sec 200.00M 0.95 10 0.21sec 189.57M 1.00 11 0.21sec 190.48M 1.00 12 0.20sec 200.00M 0.95 13 0.21sec 189.57M 1.00 14 0.21sec 190.48M 1.00 mean: 0.21sec 194.61M 0.98

Total absolute time: 3.08 sec

Abstraction Penalty: 0.98

Еще кто пробовал? http://www.ne.jp/asahi/galina/home/stepanov/

Что у Вас за комп был?

Вова

2 Vova-3

Я так и знал, что под NT icc будет работать быстрее - коммерция, понимаете. Я сравнивал под Linux SuSE 7.1. Опции компиляции были такие же, как и у Вас.

Кстати, по поводу Вашего примера с delete [] a и просто delete a я посмотрел в книгах Скота Мейерса. Он дает пример и ссылку на Строуструповский стандарт C++.

Я не научный работник - мои задачи гнать код под IBM DB2 UDB 7.2. Там ANSI 3 Dynamic SQL препроцессируется в SQC, а затем в чистый С, но на Linux только в gcc. Так что выбор для меня однозначен - только gcc на Linux. Серверы приложений (2rd tier) мы делаем на Java. Кстати, участие в www.linx.org.ru Форумах помогло мне сделать proof-of-concept IBM J2SDK 1.3.

Кстати, есть тут у нас любитель (мы должны заниматься коммерческим кодированием, а не наукой) правда не гидродинамики, а газовой динамики. Он утверждал, что на вычислительных задачах Фортран бьет С++. Я на самом деле посмотрел это в книге Строуструпа "Дизайн и эволюция С++", где он признается, что С++ уступает Фортрану "в среднем на 15-30%".

Благодарю за тестовые примеры. Попрошу в соседней комнате коллег прогнать их под zOS.

Stepanov Benchmark

NikS-TNX, честно говоря, мне кажется, что здесь какая-то ошибка. На каком компе гоняли? Камень?

Не могли-бы Вы также прислать полный листинг (можно на мыло vladimir-mp3@mail.com). Интересно мне глянуть на это.

Действиьельно, для всяких эС-Ку-эЛ и банков совсем другие вещи нужны. Безопасность там всякая, которая мне полностью по-барабану. Тут мне сказать нечего, знаю все понаслышке.

>Кстати, есть тут у нас любитель правда не гидродинамики, > а газовой динамики. Он утверждал, что на вычислительных задачах > Фортран бьет С++. Я на самом деле посмотрел это в книге > Строуструпа "Дизайн и эволюция С++", где он признается, > что С++ уступает Фортрану "в среднем на 15-30%".

Прав Ваш любитель газодинамики (которая есть подобласть гидродинамики, Fluid это и Gas и Liquid), на 100% прав. Тот же интелловский фортран делает код на 10-30% лучше чем ИСС. Такова се-ля-ви. Причем на самых простых структурах, типа сложить два массива. Но уж очень не хочется на фортране писать. Не такая уж большая разница, а я свое время тоже ценю. Интел счас начал делать совместные мат библиотеки, одна и таже и для С и для Фортрана. Там действительно можно получить большую выгоду по скорости, но имеет смысл использовать только в самых критических местах.

Вова

Жду полный листинг и параметры компа, плз

2Ogr: "Тебе дать url с документацией по процессору и попросить тебя ею воспользоватся при оптимизации руками?"

Бедняга. Я понимаю, тебя это пугает, но без документации по даже не процессору, а архитектуре в целом, тюнеру делать нечего. Разве что тыкаться в слепую, пробуя разные варианты. Даже программируя на С надо знать какой код в конце концов выходит, тем более что на нем это возможно, в отличии от твоего любимого C++. Из твоих слов я могу только заключить, что в этом деле ты попросту ничего не понимаешь.

А то что на интел оптимизируют вплоть до ассемблера - секрет только для тебя и журналюг. Возьми сорцы любой серьезной либы/программы. Загляни в раздел opensource на www.intel.com, либо скачай quake1. Им, конечно, далеко до великого тебя... по невежеству...

To quantum chemist: kak by s toboi spisatsa ne v etoy pomoyke?
Moy email kulak<at>phys<point>bsu<point>unibel<point>by

2ZhekaSmith: Прочти мой первый пост обращенный к тебе, и поверь с тех пор ни чего не изменилось. Мало того ты все глубже и глубже демонстрируешь свои глупости. Просто вопрос на засыпку: и чем же так капитально отличается с++ от с, что "Даже программируя на С надо знать какой код в конце концов выходит, тем более что на нем это возможно, в отличии от твоего любимого C++."

1. Чем вредно ++?
2. В каком случае народ делает вставки асм кода в С/С++? Эссесно, речь не идет об драйверах и так далее
3. Лучшая оптимизация - продуманное написание алгоритмов.

Я тут компилил GnoArchive c ИЦЦ - так вот размер бинарника меньше в 3 раза чем у ГЦЦ. В остальном только треть исходников вообще компиляться на ИЦЦ - ГЦЦ какой-то всеядный что ли

Собсно, C - это вообще не язык, это супермакроассемблер для PDP-11. Ну для MC68x, как исключение. Это для них можно код в голове сварить. Для интеля сия операция несколько затруднительна. А C++ - к психиатру. Пока до кода дойдет - хрен знает чего/откуда навключает. btw, для PDP-11/MC68x по коду, даже оптимизированному, без проблем восстанавливается исходный c-текст

Мнение автора исключительно авторское ;)

Люди у каго нить есть долступ

к Alpha рабочей стнации - прогоните плз Stepanov's test под ней... ато у человека UPS грохнулся а она 110 вольтовая..... может только недели ч/з две получится его попросит прогнать ентот тестик...

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

2Ogr: Ладно, Огр, устал я от тебя, но так и быть отвечу. Чисто из жалости (кто-то должен же тебя просвещать), и принимая в зачет то незабываемое удовольствие, доставляемое тобой посетителям этого сайта.

C++ лично для меня плох те же, чем и программы основанные только на использовании GOTO. Это не единственный недостаток, но очень важный. В C++, в отличии от С, невозможно сказать что означает строчка:

a = b + c;

На разбор одной единственной простенькой строки надо потратить массу времени. Даже если она в конце концов является тем же, чем и в С. Тратить много времени на одну строчку - это не продуктивно.

Любимый народом stl, меня как оптимизатора, вообще, смущает. Аллах акбар, программы расчитанные на ручную оптимизацию на шаблонах не пишут, так что по работе мне этим не надо заниматься. Но вот спросил знакомый, как сделать vector чего-то там инициализированный статически (т.е. перед выполнением программы), и мне нечего было ему ответить.

2babai:

"2. В каком случае народ делает вставки асм кода в С/С++? Эссесно, речь не идет об драйверах и так далее "

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

"3. Лучшая оптимизация - продуманное написание алгоритмов. "

Ты прав, естественно. Только без знания архитектуры, трудно выбрать подходящий алгоритм. Надо ответить на массу вопросов, прежде чем писать. Где арифметика быстрее - на плавающих числах или на целых (с имитацией фиксированой точки), или возможно задействовать и то и то в параллель? Что быстрее - конкретный набор операций, или lookup table? Что лучше if или заменяющая его арифметика? Есть ли условные сохранения? И так далее. Алгоритмы, в зависимости от ответов, будут весьма разные. Причем часто отвечать на эти вопросы приходится для конкретной функции, для другой будет немного по другому.

А что делать, если алгоритмы выбраны по максимуму, а все равно надо быстрее? В молодости, я тоже думал, что эра ассемблера кончилась, да, вот жизнь она не черно-белая. Иногда и в ассемблере приходиться ручки марать.

Огришко, членососик, не позорься ты так. Тебя же хлебальничком как раз в эти, как ты их называешь, "мультимедиа-расширения" и ткнули. Соси дальше, ламеришко. Базар был про то, что на SIMD-ы пока только ручками и заоптимизируешь, компилятор всегда лажу выдаст.

Вот только одна бяда с этим фортраном - препроцессор у него кривенький. Так я и не смог CERNlib собрать...

Есть два подхода к оптимизации "сделать вумный анализ" сравнительно низкоуровневого представления. То есть по большому счёту ПОНЯТЬ чего хотел программист по его коду. Что сложно и, по моему мнению, в общем случае не алгоритмизуемо
И/ИЛИ преобразовать сравнительно высокоуровневое представление по некоторым правилам. Здесь уж программист сам говорит чего он хочет. Это как разница между символьным интегрированием и дифференцированием :)
Ссылочка по поводу "Will C++ be faster than Fortran?"
http://www.osl.iu.edu/~tveldhui/papers/iscope97/
или вот на ту же тему
http://link.springer.de/link/service/series/0558/bibs/1766/17660025.htm

Конкретнее. Например, можно использовать стандартные шаблоны для операций с векторами, а компилятору сказать чтобы он "правильно" их компилял с использованием поддержки SPMD.
По поводу раскручивания циклов в векторные операции, может у меня старые сведения, но автоматически это можно сделать только в 10% случаев. Так что нужно специально думать об этом когда цикл пишешь.

Короче, всякие сиюминутные недостатки gcc это не тема для обсуждения здесь. ИМХО. Кого действительно интересует скорость нужно о другом думать.

Petr.Gladkikh@novocybersk.ru

"В C++, в отличии от С, невозможно сказать что означает строчка:
a = b + c; " (с) ZhekaSmith
Вообще-то, по-моему, перегрузка операторов создана для того, чтобы
заменить неизвестно что означающие функции типа:
char* a = abrakadabra (b, c);
на понятный любому человеку string a = b + c;
Конечно,можно перегрузить операторы так, чтобы это значило, к примеру,
a =+ b*c; но это, знаете ли, недостаток программера, а не языка.
В любом случае, найти, что подразумевается под оператором - дело
нескольких секунд.
"На разбор одной единственной простенькой строки надо потратить массу
времени"
Зато строчек меньше :)

Кстати, у меня что Intel, что kai очень модно колбасит -- их код вылетает на dynamic_cast в shared library для нативных методов java. Причем, с jdk 1.3 и 1.4 -- глючит, а с jdk 1.2.2 -- все ок:)

To Antihrist На SIMD есть новый класс F32vec4 -пишешь обычный С++ код, лажу как правило не выдает.

2shankara: "char* a = abrakadabra (b, c); на понятный любому человеку string a = b + c; "

А получилось, наоборот. Вместо того, чтобы смотреть одну, причем заведомо функцию (если выполняется соглашение о макросах заглавными буквами), надо посмотреть в "два" оператора, где точно так же могут быть еще такие приколы. Человек потерял власть над текстом, любая строчка может означать что угодно. В С я могу сказать точно "что в этих десяти строчках не проблем с memory leaks и выполнятся это будет не больше чем сотня тактов", а в C++ я этого не могу сказать мельком взглянув. Требуется много времени.

"В любом случае, найти, что подразумевается под оператором - дело нескольких секунд. "

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

"Зато строчек меньше :) "

Макросами можно ужать строчки очень хорошо. Но лучше этого не делать ;))

2ZhekaSmith:
А теперь давай, напиши функциями выражение наподобие A=(B*C+E*invert(F)-transpose(Z))*invert(Y)+K; А с перегруженными операторами это выражение вообще можно аккуратно развернуть в дерево, и выполнить за раз, вообще не тратясь на временные переменные, а хороший оптимизирующий компилятор это все дело хорошо заинлайнит.

2AC: Легко,

do_core_transform(A, B, C, E, F, Z, Y, K, n);

;)), кстати откуда взял такое забавное выражение? Неужто в реальности понадобилось?

Проблема не в том, чтобы такое написать, проблема в том, чтобы разобраться, что происходит. Большие проекты пишет не один человек.

Ладно, допустим код написан, далее твои действия в случае:

* найти и убрать memory leaks в этой строке * гарантировать что здесь нет багов * нет оптимизирующего компилятора C++ под данную платформу * есть, но им программа не компилируется * надо повысить скорость вычислений на 30% * одна из матриц статическая, надо подставить в выражение реальные цифры

???

2ZhekaSmith: А n, надо полагать, битовая маска операций?:)

>кстати откуда взял такое забавное выражение?
От балды:) Но в реальности похожие выражения бывают.

>Проблема не в том, чтобы такое написать, проблема в том, чтобы разобраться, что происходит.
Ага. И как разбираться с do_core_transform?

>айти и убрать memory leaks в этой строке
Отладить библиотеку для работы с матрицами и expression templates.

>гарантировать что здесь нет багов
Отладить и протестировать библиотеку для работы с матрицами и expression templates.

>нет оптимизирующего компилятора C++ под данную платформу
Теоретически да, сделать на C. Но! У меня работа не такая, как у вас (в смысле, штатного "ручного" оптимизатора). Я пишу на C++, и под наши target-платформы есть оптимизирующие компиляторы. Я не пишу под экзотику.

>есть, но им программа не компилируется
Обычно оптимизирующие компиляторы хорошо знакомы со стандартом ==> переделать те места, которые не компилируются, в силу их заведомой некорректности.

> надо повысить скорость вычислений на 30%
Оптимизировать библиотеку для работы с матрицами и expression templates. Если надо, написать соответствующие специализации соответствующих шаблонов.

>одна из матриц статическая, надо подставить в выражение реальные цифры
Взять правильную библиотеку для работы с матрицами и expression templates:) Их есть.

2AC: Что-то я занялся глупостями ;;). С++ вполне подходит для прикладных задач слабо критичных к быстродействию, но для системных вещей я бы не стал его пользовать.

"Оптимизировать библиотеку для работы с матрицами и expression templates. Если надо, написать соответствующие специализации соответствующих шаблонов. "

Надеюсь, согласишься что либо компилятор оптимизирует, либо нет :)) Какой смысл оптимизировать один оператор, когда их выражении как минимум два, и либо компилятор сам все разрюхает либо пролетаем как ласточки над парижем ;))

2ZhekaSmith:
>то-то я занялся глупостями ;;).
Действительно. И даже глупости/предвзятости начал говорить.

>С++ вполне подходит для прикладных задач слабо критичных к быстродействию, но для системных вещей я бы не стал его пользовать.
C++ _отлично_ подходит для прикладных вычислительных/обработки данных задач, _критичных_ к быстродействию. Что имеется в виду под системными вещами?

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

2ZhekaSmith: ну не глупый человек вроде ведь, может просто попробовать? можно пойти в форум и порассуждать/потестировать, можешь сам подумать/анализировать а-то как орг в самом деле :( голословный треп на тему быстрей/медленней.

PS. вот буквально несколько дней назад, разбирались со студентом на похожую тему: нужны ему были двумерные массивы, простейшая реализация operator[] проиграла всего ~15%, чуть более хитрая еще меньше.

PPS. а ругать дополнительные возможности за то, что они предоставляют дополнительные способы решения задачи это вообще детский лепет --- давайте ругать отбойный молоток за то что им можно больше/быстрей раздолбить чем ломом :)

2AC: "От балды:) Но в реальности похожие выражения бывают. "

Честно скажу - не знаю что это за реальность. Виртуальная наверное ;)) Это типично для языков монстров - решать несуществующие проблемы.

"Ага. И как разбираться с do_core_transform? "

Очень не сложно, там будет три цикла, десяток строчек. Описание для тех кто хочет знать что задумывалось и четкий текст для тех, кто хочет узнать что получается. Я, например, transpose еще помню что такое, а вот что такое invert не знаю. Заведомо никаких выделений памяти, никаких exception'ов и т.д. Ни на какой платформе с любым компилятором.

"Отладить библиотеку для работы с матрицами и expression templates. "

Для одного выражения? ;) Не много ли работы?

"Взять правильную библиотеку для работы с матрицами и expression templates:) Их есть."

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

2AC:

"Действительно. И даже глупости/предвзятости начал говорить. "

Это не глупости и не предвзятости. Глупости - разводить флейм по этому поводу.

"C++ _отлично_ подходит для прикладных вычислительных/обработки данных задач, _критичных_ к быстродействию."

Далеко не все так думают из серьезных ребят. Попытки перевести ядро линукса на C++ окончились отказом от таких попыток. Давеча посмотрел на сорцы quake2 (quake2 критичен к быстродействию?), никакими шаблонами/C++-ми там и не пахнет. Но больше всего я обалдел, когда на http://www.xbill.org/xbill/xbill21.html прочитал "I started by converting all the code from C++ into C, as well as cleaning up a lot of really bad code and changing the build system from imake to autoconf. This was all well and good, but completely non user-visible. ". C++ - игрушка для прикладных программеров, причем очень чуствительная к профессионализму. Запутать, усложнить и наделать ошибок можно гораздо больше, чем на С. Найти ошибки тоже гораздо сложнее. Вот такое мое мнение.

"Что имеется в виду под системными вещами? "

Все что не общается с юзером напрямую и не является вещью в себе. Ядро ОС, сервера баз данных, библиотеки, кодеки и все такое...