Уже сказано было, что невозможно какой-бы то не было процентной характеристикой описать преимущество одного из этих языков над другим. Производительность может разительно - не на 5, а на 500% может различаться: 1. От задачи 2. От конфигурации системы. 3. От вариантов компиляции С++-кода (компилятор, оптимизация, расширения) 4. От качества и доверительности тестового С++-кода (в первую очередь непредвзятый подход к операциям выделения-освобождения памяти).

Добавлено @ 23:41 
Кто такой Симон Робинсон? Я не знаю. Вот если бы такой зубр системного программирования, как Джефри Рихтер в своей книге про .NET такое написал... но он бы такое никогда не написал. 

Это ложная быстрота. Ява сразу после запуска отгребает себе метров 10 памяти. Выделенную память системе нифига не возвращает - ибо с одной стороны это затраты на исполнение GC, с другой - траты на операции освобождения памяти с необходимостью последующих выделений памяти для новых объектов. Как таковое исчезновение из контекста явашного объекта вовсе не означает, что память из-под него непременно будет возвращена системе (не важно, когда). На самом деле эта память используется для объектов, которые будут созданы в будущем. Именно поэтому heap всех явашных программ чудовищно разбухает прямо на глазах.

Амортизатор2, ну конечно, Джефри Рихтер у нас единственный приличный программист   . Почитайте, очень хорошо написано, на доступном языке без выкрутасов объясняются довольно сложные вещи. Правда автор чуток перегибает, когда сравнивает .NET с другими технологиями, но в целом книга весьма достойная. 

Alexeis, поддерживаю. Такое ощущения, что кроме Рихтера никого больше нет. А может просто не знают...

TIOBE Programming Community Index

Интервью про индекс TIOBE


Это сообщение отредактировал(а) SergeCpp - 24.1.2007, 10:05

Alexeis, понимаешь, таким утверждениям нельзя верить, от кого бы они не исходили. Это абсурд. Это противоречит элементарной логике. Если бы это написал Рихтер, он точно также шёл бы лесом.

  Почему? Что из того что компиляция производиться в 2 этапа? Разве это значит, что не производиться оптимизация? С# написан недавно, и в его компилятор заложены методики оптимизации полученные за многлетний опыт развития С++. Кроме того также производится оптимизация на этапе компиляции IL в машнные коды с учетом развитой архитектуры процессоров. С++ обычно оптимизируется под Pentium, а если у вас стоит Athlon 64, с поддержкой 3DNOW!, SSE, SSE2, MMX с их 128 разрядными регистрами, то их использование должно ускорить вычисления. При этом IL разробатывался учитывая опыт JAVA для того чтобы потери при динамической компиляции были минимальны. Если это все грамотно реализовано, то не вижу причин для того, чтобы код работал медленно. И там машинный код и тут. Оба оптимизированы и еще не извесно который из них оптимизирован лучше. 
  Если говорить о работе программы целиком, то тут можно согласится, что сборщик мусора, который может вмешаться и остановить выполнение программы или компиляция очередного блока, вместо его выполнения, но после того как эти операции выполнены код должен работать быстро. По крайней мере возможно сделать так чтобы это работало быстро, как оно в действительности сделано у Microsoft я не знаю.

Alexeis, всё правильно говоришь. Но дело не в этом. «Не более 5%» — это бред по определению, какие бы переменные не стояли в X vs Y. Надо указать конкретные тесты или хотя бы написать что-то вроде: «Проведённые нами исследования показывают, что C# отстаёт от Vasya Pupkin C++ compiler не более чем на 5% на задачах такого-то рода».

Что касается процессоро-зависимых оптимизаций, то это пока только планы, хотя, быть может, планы ближайшего будущего. JIT в .NET не умеет использовать SIMD. В этом легко убедиться, посмотрев сгенерированный им машинный код с помощью cordbg.

Если  вам это неизвестно, Рихтер прежде всего знаменит книгой "Windows для профессионалов", в которой детально описывает API Windows и программирование под эту систему с учетом внутренней специфики Windows. Именно поэтому я его и упомянул. Его книга про .NET - это уже поздний, и не такое значительный труд.