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

IMHO написание более эффективного кода(с точки зрения скорости) - тоже есть оптимизация по скорости.

„Ещё добавлю: не стоит надеятся, что компилер нормально переварит "абы как" написанный код, в некоторых "клинических" случаях никакой компилятор IMHO не поможет.“

Эт точно - верно на 100%.

Да я и имел ввиду, что иногда можно (если нужно) написать код лучше, чем компилятор сделает :)

Много слов, никакой эмпирики, никакой математики.
Похоже на сходку перебравших пива сисадминов.

Про то что можно дурака валять в "эпохе До_Фига_Герцовых" процов я слышу со времён мега_герцовых, десятки мега_герцовых, сотни_мега герцовых.
С тех же пор я постоянно слышу жалобы про то что "всё тормозит", я вижу покупателей всё более герцовых процов, которые никак до нирваны "всё летает" меняя и процы и карточки и т.п.
Сам как пользователь постоянно чувствую себя надутым - как только бабки выложу за новую машину - как будто поколение софтовиков-программёров меняется на ещё более тормознутое и воз и ныне там. Так что резкое улучшение обычно связано со сменой самого софта (если повезёт) и оптимизации системы. А ведь я смотрю как "обычный пользователь".
Есть по настоящему сложные процессорные обработки и вычисления, инет кишит предложениями об "объединении ресурсов" для решения очередной задачи.
Так что болтовня про "эпохи *герцовых" - не выдерживает эмпирики. Google к примеру прежде всего революционный софт а потом уже мейнфреймы. Эльбрус - прежде всего интересные алгоритмические решения а потом уже частота.

Аргумент второй в нашем несерьёзном разговоре:
Оптимизирует не компилятор, а человек который придумал компилятор, который для реализации своих мыслей (которые в голове бывают) создал робот-автомат - компилятор и научил их ему. Тоже касается библиотек мат. обеспечения - их пишет не кремневый Интел а вполне конкретные человечки.
И каждый решает для себя что ему делать, или становится таким же человечком который и компилятор может улучшить и библиотеку или в пупсики играть.

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

НУ ЭТО ФИЛОСОСФИЯ!!! Я спросил лишь кто нибудь пробывал состязаться с компайлероам от ИНТЕЛ!!! Просто я чувствую что мне предстоит это!! Хочу выйграть эту дуэль!! Готов даже пиво поставить за советы.

The Svin
Как пользоваться VTune om?? Я знаю ты умеешь!!!

Я пользовался старым (v 2.?) Ещё в эпоху простых пней.
Там удобней было ляпы находить по параллелизации U/V.
А новый как то поставил - он мне систему обрушил, такая тормозень этот новый VTUNE! Его на бейсике писали похоже причём тяп/ляп.
Но по твоему вопросу беспокоится нечего - он идёт с тучей док включая и тюторы.
Я кстати от него только доку и оставил - там второй том (инструкции) от Intel сделан в chm. В chm как то удобней - можно программировать поиск через API, вот единственное что полезного я там для себя нашёл.
У Касперски (Крыса) в книжке тоже рассказы про VTUNE, он то ли некоторые главы то ли вообще здоровый кусок книжки и на русском и на английском где то выложил для публичного пользования. Спроси у него.

Я против переписывания с языка высокого уровня на ассемблер только ради факта, что ассемблер теоретически быстрее.
Но, я даже очень за оптимизацию кода, который часто вызывается.

Тогда еще один аспект. Не проблема написать
на ассемблере программы для матричной алгебры,
проблема оттестировать их, чтобы можно дать
рядовому юзеру. Вот поэтому и приходится
лавировать между старыми проверенными
фортранными текстами и коммерческими
оптимизированными библиотеками. То же самое
касается алгоритмов оптимизации используемых
в компиляторе. Гений конечно придумает,
но во сколько обойдется проверка его идеи ?!

Не вижу проблемы в тестировании...

1. Пишем библиотеку функций на ассемблере для матричных операций
2. Пишем тестовый контейнер: програмку, которая читает из файла матрицы+результат, вызываем библиотеку и сравниваем с результатами.

Всё автоматизировано, только надо придумать и написать входные файлы, а ещё лучше использовать ФОРТРАН для генерации такого файла.

Мы движемся по одному кругу фраза
"старыми проверенными фортранными текстами"
говорит, что кто-то их писал, значит проблемы были уже преодолены в прошлом, и преодолены людьми.
Мы должны либо сказать что "мы не люди такого" сорта либо, что "ничего нового написать без страшных потерь невозможно", что противоречит действительности так новые библиотеки постоянно выходят.
Это просто проблема своего позиционирования в мире программирования, т.е. психология, никаких практических вещей связанных с математикой или прикладным кодированием в ней нет. Если главная задача кодёра - быстрые решения по документообороту в его конторе, разумеется заставлять его писать серьёзное мат обеспечение покажется ему "слишком".
Другое дело если человек заранее готовит себя как системщик, то готовность и психологическая и проффессиональная приходят со временем.
Дело в том, что большинство системщиков ушло и уходит в ЯВУ как основной инструмент (долгая и пережёванная неоднократно тема) поэтому любители и новички просто мало видят примеров серьёзной работы и из-за этого появляется психологический момент - иллюзия, что это как-то с ассемблером связано. На самом деле связано с людьми, так сложности языка слабосравнимы с реальными профессиональными трудностями - это правильная мат модель в сложных проектах. Это как разница между десантником (начну а там поглядим) и полководцем где метод тыка дорого стоит и нужно уметь моделировать в голове (или схемах) сложные композиции. Мой личный пример не эталон но сгодится как пример, даже в небольших проектах у меня уходит где то 95 процентов на обдумывание общей модели и лишь процентов 5 на непосредственное кодирование в редакторе. Эти 95 процентов не зависят от того на чём я буду писать - я придумываю тех. описание задачи, поиском в ней связей и подводных камней как если бы у меня был робот который мог бы закодировать за меня эту задачу, от меня в данный момент требуется лишь очень точно её смоделировать.
А потом на 5 процентов времени я уже сам становлюсь этим "роботом" и кодирую.