Здравствуйте, vdimas,

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

V>Там невалидность видна невооруженным взглядом и специально демонстрировалась. Получить подобную невалидность на 3-м или 5-м уровне коссвенности — легко и наблюдалось мною не раз (она возникает из-за отсутствия четких спецификаций и ограничений на параметры методов, а компилятор пропускает все подряд, есс-но).

Речь не о том вёл, качество входного кода зависит целиком от человека, задача компилятора лишь компилировать это в соответствии стандарту.

V>Насчет оптимизаций, ты зря споришь. Наличие хороших компиляторов от Intel или MC++7.0 не говорит о легкости стат-анализа кода программы на С++. Ты не можешь предвычислять участки кода (или оптимизировать алгоритм), если обращаешься к данным через указатели, значение которых устанавливается где-то вне контекста. Это же очевидно и reductor просто не находит слов (или желания) для объяснения очевидных вещей. Очевидные вещи порой сложно объяснить

Глаза боятся, а руки делают:

Whole program optimization allows the compiler to perform optimizations with information on all modules in the program. Without whole program optimization, optimizations are performed on a per module (compiland) basis.

Whole program optimization is off by default and must be explicitly enabled. However, it is also possible to explicitly disable it with /GL-.

With information on all modules, the compiler can:

• Optimize the use of registers across function boundaries.
  
• Do a better job of tracking modifications to global data, allowing a reduction in the number of loads and stores.
  
• Do a better job of tracking the possible set of items modified by a pointer dereference, reducing the numbers of loads and stores.
  
• Inline a function in a module even when the function is defined in another module.

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

.NET вот тоже не даёт начудить с указателями, потому и проигрывает в скорости на одном и том же компиляторе. Хотя там и копейки, для многих задач. Кстати, интересно что на платформе windows управляемый С++ работают со скоростью OCaml Ну и С# соответственно тоже, если не быстрее в некоторых местах.

R>>>Да чем мешает-то. Как будто он обязан всегда оставлять это представление.
R>>>Это представление — оно для GC и для внешнего кода, а не для компилятора.

GN>>Это не важно. Арифметика будет проигрывать аналогу в С++ всегда за счёт оверхеда на сдвиги (деление/умножение на 2).

V>Тебе сказали о том, что подобное представление не специфицировано. Т.е. на других компиляторах возможно другое представление. Вообще, я бы скорее выделил лишнее слово памяти, чем 1 бит

В данном случае не важно, для чего оно. Оно даёт оверхед, это снижает скорость. Вот о чём речь.

V>С++ — это универсальный язык, помимо прочего. Мне даже трудно определиться, что лучше: владение универсальным инструментом, или владение множеством узконаправленных, но идеально подходящих для конкретных случаев инструментов.

V>Достаточно много бенефитов у обоих подходов.

Действительно, даже если посчитать языки, которые дали нам возможность общаться на этом форуме, будут обе категории. Кстати, можно даже попробовать список составить

V>Но у первого подхода все бенефиты скорее организационно-административного плана, как с технической т.з., так и с т.з. управления ресурсами (людскими)

Да, это к сожалению или к счастью действительно так.