Ответ на »сообщение 6204« (Сергей Перовский)
___________________________

У всех оптимизирующих компиляторов есть СВОЕ промежуточное представление кода.

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

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

От процессора я вроде как не предлагал абстрагироваться.:)
Хотя тут где-то я читал, что деревья Франца наоборот, увеличивают возможность оптимизации.

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

Не понимаю что там может быть завязано именно на C. Что вообще умеет делать ICC? Надо Pepper'a спросить. :)
По моим данным, он умеет хорошо держать переменные в регистрах, вычислять константы в выражениях, находить инварианты в циклах и вообще ненужные циклы, убирать лишние вычисления (в разумных пределах), использовать SIMD.
А также знает какую инструкцию после какой лучше ставить.
Этого достаточно.
И что здесь завязано на язык?

Примеры реальной эффективности были только для игровых программ, где распоралеливание не вызывает особенных проблем.

Еще как вызывает. Я еще ни одной игры не видел, которая распараллеливалась бы хотя бы на два ядра (разве что старина Quake). В лучшем случае во других потоках считаются всякие мелочи или грузятся ресурсы с винта.

В кулуарах их специалисты признавали, что нужен другой язык и другая ОС, иначе толку от многоядерности мало.

Вот всегда интересовало - от ОС что им надо? Если распараллелить вычисления по потокам, то выигрыш будет. Причем тут ОС?
Разве что переход в режим ядра тормозит при синхронизации, но это вроде практически во всех ОС с защитой процессов. И потом есть способы синхронизации без перехода в редим ядра, у того же Интела на сайте описанные.

Ответ на »сообщение 6201« (Lisp Hobbyist)
___________________________
Задача ведь не в том, чтобы испортить жизнь сишникам, а чтобы облегчить её остальным.

Ответ на »сообщение 6202« (AVC)
___________________________
У всех оптимизирующих компиляторов есть промежуточное представление кода
У всех оптимизирующих компиляторов есть СВОЕ промежуточное представление кода.
Если сделать промежуточное представление универсальным, абстрагировавшись и от языков и от кодов процессора, то возможности оптимизации резко упадут.
Интеловское промежуточное представление сильно завязано с одной стороны на С, а с другой на базовую архитектуру их процессоров.

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

Ответ на »сообщение 6201« (Lisp Hobbyist)
___________________________

Ответ на »сообщение 6182« (Илья Ермаков)
___________________________
С аппаратной типизацией, например, дабы сишники все переповесились :-))
2. Хорошие программы на C/C++ пишутся с учетом их будущей переносимости, опыта которой этим языкам хватает. Как следствие, опасные машинно-зависимые фокусы в них достаточно хорошо локализованы.

Вспомнилось... Читал, что в 80-х г. при прогонке на Эльбрусе-2 "хороших программ на С/С++" которые считались полностью отлаженными и корректными и эксплуатировались уже не первый год, выявлялись сотни ошибок доступа к памяти :-) Даже при прогонке какого-то эталонного стандартного теста обнаружили 36 ошибок.

Ответ на »сообщение 6200« (Сергей Перовский)
___________________________

Быстродействие программы, создаваемой интеловским транслятором основано именно на прямой трансляции с С++ в коды конкретного процессора.
Это как передача мыслей на расстоянии "из мозга в мозг", что ли? :)
У всех оптимизирующих компиляторов есть промежуточное представление кода, к которому, собственно, и применяются разные способы оптимизации.

Ответ на »сообщение 6182« (Илья Ермаков)
___________________________

С аппаратной типизацией, например, дабы сишники все переповесились :-))

1. Не дождетесь. :-)

2. Хорошие программы на C/C++ пишутся с учетом их будущей переносимости, опыта которой этим языкам хватает. Как следствие, опасные машинно-зависимые фокусы в них достаточно хорошо локализованы.

3. Для Лисп-машин (которые имели аппаратную проверку типов) существует, например, такая штука, как Zeta-C, транслятор с C в Лисп. По утверждению его авторов, достаточно совместимый с другими реализациями C того времени. Из известных мне сведений об архитектуре Лисп-машин я не вижу принципиальных препятствий для реализации там же прямой трансляции в машинный код.

Ответ на »сообщение 6199« (Mirage)
___________________________
После компиляции программа переводится в некое промежуточное представление.
Тогда нужно махнуть рукой на тесты быстродействия. За такую универсальность нужно платить.
Промежуточный язык рано или поздно становится тормозом, по мере того, как в ассемблере новых версий процессоров появляются все более высокоуровневые команды. До появления MMX кому могло придти в голову, что несколько элементов массива можно обработать одной командой?
Когда-то так мучались с транслятором с фортрана на более высокоуровневый ассемблер Эльбруса.
Быстродействие программы, создаваемой интеловским транслятором основано именно на прямой трансляции с С++ в коды конкретного процессора.
Сейчас тормозом стал сам С++. Для программирования, ориентированного на  многоядерные процессоры, нужны более декларативные языки.

Ответ на »сообщение 6198« (Cepгей Poщин)
___________________________

Вообще-то в документации по командам процессора и так всё зафиксировано, только вряд ли эта литература продаётся на книжных развалах, уж больно узок круг покупателей. И, потом интересно, а что будет на входе? Текст программы на любом языке? Продолжить обсуждение, наверно уместней здесь »тема на БП №195«

После компиляции программа переводится в некое промежуточное представление. У меня, к примеру, это обратная польская нотация, отображенная в структуру данных. А еще может быть p-код, или деревья Франца. Не думаю, что потребности на данном этапе сильно отличаются для разных языков. Скорее всего уже все равно.:)
И потом уже из этого представления генерируется код. Вот на входе как раз и должна подаваться программа в таком представлении. Тогда не важно уже на каком языке была написана программа. На Обероне или на С++.:)
Надеюсь, разработчики Росы не будут повторять ошибок Интела.:)

Ответ на »сообщение 6197« (Mirage)
___________________________
будет зафиксировано (в т.ч. в документации) что на входе и что на выходе Вообще-то в документации по командам процессора и так всё зафиксировано, только вряд ли эта литература продаётся на книжных развалах, уж больно узок круг покупателей. И, потом интересно, а что будет на входе? Текст программы на любом языке? Продолжить обсуждение, наверно уместней здесь »тема на БП №195«

Вообще я Интел плохо понимаю. Зачем делать оптимизирующий компилятор для конкретных языков (сейчас есть для С++ и вроде для Фортрана), если можно сделать оптимизатор с открытой архитектурой. Т.е. будет зафиксировано (в т.ч. в документации) что на входе и что на выходе. Это и проще и больше языков, а значит и людей смогут использовать. Да и рынок тоже больше, раз уж они решили на этом зарабатывать.
Похоже ни Интелу ни АМД такая мысль даже не приходила. Может у кого знакомые там есть, дабы донести сию простую мысль до нужных людей? ;)