2ZhekaSmith: >Честно скажу - не знаю что это за реальность. Виртуальная наверное ;))
Привожу пример из своей области:
point p = (p1 | p2) & (p3 | p4) -- вычисление пересечения двух прямых в алгебре Грассмана-Кэли. | -- внешний продукт векторов, & -- матричный продукт. Все это разворачивается в один цикл без временных матриц.

>решать несуществующие проблемы.
Из незнания не следует делать вывод о несуществовании.

>Для одного выражения? ;) Не много ли работы?
Ну, у меня же не одно выражение:) Если оно одно, то очевидно, что do_core_transform -- решение.

>Адресок если можно, посмотрю на досуге...
http://osl.iu.edu/~tveldhui/papers/techniques/
http://oonumerics.org/blitz/
http://www.osl.iu.edu/research/mtl/

2ZhekaSmith: >Глупости - разводить флейм по этому поводу.
Это не вопрос.

>Попытки перевести ядро линукса на C++ окончились отказом от таких попыток.
Как всегда, системщики переводят все на ядро линукса:) Мир линуксом не измеряется.

>Давеча посмотрел на сорцы quake2 (quake2 критичен к быстродействию?), никакими шаблонами/C++-ми там и не пахнет.
И что? А google, например, весь живет на expression templates.

>Но больше всего я обалдел, когда на http://www.xbill.org/xbill/xbill21.html прочитал...
И что? Проблема лишь в том, что этот конкретный автор не умеет программировать _на C++_.

>причем очень чуствительная к профессионализму.
Да.

>Запутать, усложнить и наделать ошибок можно гораздо больше, чем на С.
Нет.

2AC: За ссылки, спасибо, будем разбираться. А вот на это можно ссылку дать: "И что? А google, например, весь живет на expression templates. "

Это сообщение было в mailing list библиотеки boost месяцев 7-8 назад -- я ссылку на него, естественно, сейчас не дам.

2AC: Ндя, сильно:

http://osl.iu.edu/~tveldhui/papers/techniques/

впечатлен, можно сказать. Век живи - век учись :))

Google реально живет на C++, не скажу, правда, сколько там templates (тем более expression), в

http://www.google.com.ru/intl/ru/programming-contest/

темплейты, кроме стандартных не используются, такой пацанский C++ с классами. Но кто его знает, что там внутри. Thanks за инфу, и все такое ;))

"А вот что на самом деле происходит, в общем случае, нет. А очень хочется знать то, как понимает это компилятор, а не то, что задумывалось. " (с) ZhekaSmith
Ну и желания. Дают класс, пользуйся интерфейсом. Реализация пользователя
волновать не должна. На то C++ и придумывался, чтобы оградить,
запретить и предотвратить :)
Eще, посмотри на BeOS. IMHO вот так нужно писать операционки.
Программировать на чистом и прозрачном C++ в Windows или Linux невозможно,
потому что от С API, макросов и прочего не избавиться уже никогда.
Microsoft послала Win32 к черту из-за этого... ну ты знаешь про .NET

2shankara: " Ну и желания. Дают класс, пользуйся интерфейсом. Реализация пользователя волновать не должна."

Я как раз тот пользователь, которого это волнует. Если более новый компилятор позволяет убыстрить реализацию на 40%, у меня возникает законный вопрос - а все ли так с реализацией ;)) И нельзя ли ее убыстрить на 100% на старом компиляторе...

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

а быстрей всегда можно :) вопрос в том, на сколько тебе это надо, и чем ты для этого готов пожертвовать, что для этого готов предпринять?

2anonymous: смотря какие компиляторы... если оба оптимизирующие, да еще не на численных задачах, то сейчас редко отличаются...

страно, мой опыт говорит об обратном, хотя-бы на примере MSVC<->gcc<->lcc сейчас вот качается kсс,icc, погляжу, ясно, что если дело упирается в какую-нибудь подсистему типа память/диск то одинаковую производительность кода глупо обсуждать :)

PS. кто-нить может дать url c этим тестом степанова для gcc? мне казалось, что в данном случае как раз должен быть один исходник, но у меня gcc-2.95.4 на линухе выдает стабильно ~1.0, что настораживает :)

#include <stdio.h>

template <int n> int fac () { return n * fac<n-1>(); }
template <> int fac<0>() { return 1; }

int main()
{
printf ("%d\n", fac<16>());
return 0;
}

Это вот скомпилите gcc и icc и прочуствуйте разницу.

О Portland

Вклиниваюсь несколько с запозданием поэтому мог кое-что пропустить. Cмотрел компиляторы от Intel, Portland и еще некоторые и положительное могу сказать только про Фортран от Portland и то только о HPF-F90, в силу их отсутствия в Линуксе, к тому же ни один другой не компилировал так безболезненно, если вообще это удавалось сделать. Например Intel давал нерабочий код под MPI или SMP (программа выдавала совершенно не те результаты), кстати для Р!!!. Напротив С/С++ от Portland часто давал более медленный код нежели gcc, да и Intel не выделялся намного большей скоростью.

Можно сделать вывод: если есть бабки - плати, в некоторых случаях это даже рекомендуется, есть задачи, где небольшое увеличение <10% производительности очень даже важно. Тем более что бесплатных Фортранов (если это касается темы) нет и вряд ли будет. Да и не было бы коммерческих продуктов если бы они ничем не были лучше, кроме поддержки конечно :) А если нет бабок то и нет проблем.

2 ананимусу с факториалом

Ну я вот сейчас факториал этот скомпилировал - никакой разницы не почувствовал.

А вот Stepanov.cpp gcc делает быстрее чем icc.;)

Так что мой выбор gcc!

Ну я вот сейчас факториал этот скомпилировал - никакой разницы не почувствовал. На intermediate assembly (-S и для gcc и для icc) посмотри, а потом радуйся.

2last онанимус

Ну и что? Я это также посмотрел

gcc нагенирировал просто .byte определения

В итоге готовый файл после после strip

gcc - 4152 байт icc - 6792 байт (+тянет доп.библиотеки)

Вы бы еще посмотрели асм (-S) код для Hello, World! - тут Интел уж нагенерил, так нагенерил!!!:)))

Общепризнанным тестом является тест Степанова - он ведь все-тфки автор STL!;)

PS Кстати, а где я могу взять посмотреть исходный код icc подобно gcc???

> Общепризнанным тестом является тест Степанова - он ведь все-таки автор STL!;)
А printf ("Hello, World!\n"); написали Керниган и Ритчи - куда общепризнаннее. :-)
А тест с факториалом вообще не правильный: или пишите std::cout << или макросы вместо шаблонов.
Намешали тут языков, а компилятор мучайся :-))
> Кстати, а где я могу взять посмотреть исходный код icc подобно gcc???
В суде :-)) Если есть деньги на хорошего адвоката.

NikS, вы вроде жабщик, так и не лезьте в калашный ряд:)

>>NikS, вы вроде жабщик,

Так ведь JNI на Си писать придется!:) А для энтого дела нужен С/C++ компилятор:

1. Поддерживающий JNI

2. Переносимый (ну куда мне интеловый компайлер на Sun UltraSPARC или S/390)

3. Компайлер, генерирующий хороший код (особенно для "чистого" Си).

Я уверую в пользу интелового компайлера (пункт 3), когда мне _практически_ покажут реально работающую задачу распознования образов в N-слойной персептронной нейросети по методу back-propagation. А пока все это метафизика и словесная перепалка, не удовлетворяющая пунктам 1 и 2.

PS Кстати сегодня посмотрел асм код gcc для S/390. Хороший код, доложу Вам!