Чем так привлекателен C++ ? - Философия программирования

Здравствуйте VladD2, Вы писали:

S>>Мне вообще-то под Солярку и СКО надо.

VD>Ну, тоды тебе на Яву. Покрайней мере пока. Или можешь сам портнуть. Только я почти уверен, что выигрыш в скорости получаемый на .NET исчезнет, так как из CLI похоже выдрано все что касается оптимизации. :(

Не, мне тоды на C++ :)

S>>Биндинги к Qt писать упаришься. А те, что есть — GPL. Нет уж, нафиг такое счастье.

VD>Ну, ты же ведь гипотетически спрашивал. :) Тебе и ответили... можно, но не стоит. Вот COM вот уже 4 года как портирован на юниксы. Что же теперь бежать под Салярку все переписывать? К тому же под писями она почила. :( Любимый тобой СКО тоже чувствует себя погано. Остается Фршишка и Линух. Я бы на метсе ребят из Редмонта тоже бы сделал выбор в пользу Шришьки. :)

Сдохла или нет, а у потенциальных (и очень жирных) клиентов оно стоит и еще долго проживет. Соляру под писи саны, кстати, вроде передумали бросать.

S>>С ними геморроя больше. А так — убил один объект, создал на его месте новый,

VD>Во-во. Даже такой маленький кусок кода уже трудночитаем. Что же будет в реальном проекте. :(

Это дело привычки. Тебе — трудночитаем, мне — нет.

VD>Нет уж я предпочитаю так:

VD>

VD>    CBitmap hbmp1;
VD>    CBitmap hbmp2;
VD>    ...
VD>

А потом разбирайся, какую битмапу использовать. Нафиг.

VD>Если нужно память экономить, то:
VD>

VD>    CBitmap hbmp;
VD>    ...
VD>    hbmp.Clear();
VD>    hbmp.Attach(hSomeApiBmp);
VD>    ...
VD>

Злые разработчики библиотеки забыли приделать к классу wxBitmap (а это был он) функцию Clear(). На самом деле, такие ситуации очень часто встречается.

>>и никаких тебе указателей — ни умных, ни глупых.

VD>А хелперы — это просто обертки. Они не обязательно являются умными и указателями. ;)

Вот тут поподробнее — как они мне без указателей один объект грохнут и другой создадут? И нафиг вообще нужны? Их же самому писать придется, вместо двух строчек кода...

S>>Идея хорошая, только в реальной жизни часто дешевле оказывается всякую мелочевку (и не только) самому писать. Глюкавые компоненты с закрытым кодом — полная лажа. А неглюкавых нет и не будет, пока революции в языках программирования не произойдет.

VD>Да с твом настроем на жизнь не просто жить. :)

VD>Ну, а исходники... Вот как раз .NET тут помог. Базовые мещи можно взять в Роторе (CLI), а остальное... на то есть Анакрино (.NET-ый дизассемблер). Я уже не мало с его помощью проблем решил.

S>>То-то они до сих пор нормальный плюсовый компилятор никак не выпустят :)

VD>А ты действительно видил гараздо более быстрые? Тогда глянь нашего шустрика:
VD>http://www.rsdn.ru/article/?devtools/perftest.xml
VD>http://www.rsdn.ru/article/?devtools/perftest2.xml
VD>http://www.rsdn.ru/article/?devtools/perftest3.xml

Там не отмечен один факт — VC 6/7 не является полноценным компилятором C++ :)

VD>Особенно забавны тесты Pi и FloatTest2. Там VC7 делает Интела в разы. Причем это очень типичные вичислительные тесты. Еще раз повторяю. Многие кто превозносят Интел просто некорректно проводят тесты. Главная оптимизация по скорости — это инлайнподстановка. Интел делает ее автоматом если включить -O3. Для VC ее нужно включать отдельным ключем (-Ob2). Все выданные мной тесты (где Интел был впереди на белом коне) грешат этой ошибкой. Они обычно вообще не включают дополнительные опции оптимизации кроме -O2 (или -Ox).

Что-то вы там с интелом нашаманили. Я, помнится, в вашем "шустрике" одну ошибку нашел — че, следующую искать?

S>>А насчет отдельного оптимизатора и генератора машинного кода, так это любой фронт-енд С++ -> С так устроен.

VD>Не совсем так. На сколько я занаю толко VC7 кладет в объектники промежуточный код. Остальные помещают туда обычный машинный код. Так что логическое разделение может у них и есть, но физического нет точно. К тому же каждый компилятор на сегодня имеет свой опитизатор и кодогенератор. А тут предлагется сделать эти часть стандартными. Причем теперь даже жалкие JScript и VBS будут пользоваться всеми его приемуществами.

Front-end'ы для C++ обычно генерируют сишный код. А дальше можешь компилировать его своим любимым оптимизирующим компилятором C. Можешь даже клиенту в таком виде поставлять, чтоб он на target-системе все сам скомпилировал — украсть куски из него будет не намного проще, чем из MSIL'а.

VD>Вот, к примеру, представь... живет фанат перла... любит он этот перл до... но скорость ему перловая не нарвится. Если ждать пока создатели перла создадут компилятор и доведут его до ума, то можео и состариться, а так берем джит пишим простенький генератор MSIL-а и... и получаем производительность сравнимую с C#.

S>>Компонентные архитектуры — недостижимый в реальных условиях идеал.

VD>Да? А мы как-то ими пользуемся. :-\ В .NET любой класс по определению компонент. Да и COM-мом пользоваться можно. Хоть и тяжело...

С трудом, наверное, пользуетесь. Чужими компонентами, по крайней мере. Иначе с чего вдруг свой контейнер писать стали — чужих мало, что ли?

S>>COM мне тоже не нравиться :) Вернее, не все в нем нравится. А программированием задачи и так занимаюсь :) На С++ :))

VD>Задачи бывают разные. И все больше и больше они требуют динамизма и расширяемости на лету. Именно это и дают компонентные технологии.

Само собой, но в основном они дают повышенную падучесть :) Опять же, что называть компонентными технологиями? Вот плагины к FAR'у — это компоненты или нет?

S>>Не о том спич. Насчет типа процессора и объема памяти просто-напросто никто не спорит.

VD>Вот я тебя и спрашиваю. Что мало того что это будет учитываться? Сейчас то программы расчитаны на среднюю температуру по больнице. :)

Скажем так, большинство программ, но не все. Тот же 3D Studio MAX учитывает и объем памяти, и тип процессора.

S>>И ты всерьез полагаешь, что компилятор это может учесть? Причем сделать это лучше (хотя бы не намного хуже), чем программист?

VD>Дык его тоже прогаммист пишит. К тому же некоторые оптимизации в .NET и Яве уже есть. Та же многопроцессорность уже обрабатывается по разному. И менеджер память назный.

Многопроцессорность тривиально обрабатывается и в программах на C++. А компилятор просто не располагает всей той информацией, что и программист, и поэтому не может учесть этого должным образом.

VD>>>Учитываться могут и тип шины. И количество процессоров в системе. И скорость работы жестких дисков. И скорость сетевых соеденений. Да моло ли чего?

S>>Не смеши :)))

VD>Ну, ну. Вот как по-твоему если компонент хочет сделать вызов по сети, то для диалапа и для 100 мб эзернета код должен быть одинаковый? Даже сейчас народ вынесет такой код в отдельную длл-ку и сделает две реализации. Ну, а динамическая архитектура позволяет сделать этот процесс бедее гибким и безшевным.

Не отклоняйся от темы:) Речь шла о том, что компилятор сам (не) сможет сгенерировать из одного и того же исходника разный код для диалапа и эзернета.

S>>Это смотря как тесты выбирать.

VD>А тут ка не выбирай. Теоритические приемущества есть. На практике отставание минимельно. Еще лет пять и теория будет давать диведенты. Ты думаешь почему MS и Sun так драться начали?

Они по жизни драчливые :) Лет семь уже деруться — есть что делить, однако. А если все с джитами и нетами хорошо будет, так я на них и ругаться перестану.

VD>>>Через пару лет, когда идеи оптимизации воплотятся в жизнь, думаю компиляторы начнут отставать. Хотя конечно никаких супер-прорывов не будет.

S>>Да нет ни у кого никаких особенных идей по этому поводу, IMHO. А если б и были, что мешает применить их к компиляторам?

VD>Извени. Я забыл букмарк в начале своих слов постивить. Ну, ты это... того... прочти их еще раз. Думаю ответ я давал раза 4. :)

VD>Короче, дурака не включай. Сам понимаешь что мешает, что что процессоров очень много и то что компоненты (ну хоть те же длл-ки) оптимизироваться могут только в пределах одного проекта. К тому же кто тебе сказал что не применяются? В том же VC7 есть такая опция "Глобал оптимизэйшон". Так вот она пишит в объектники не машинный код, а язык а-ля MSIL. А кодогенерацией занимается линкер.

Да мне по барабану, кто там кодогенерацией занимается и какое внутренне представление данных использует связка компилятор+линкер. Если же кодогенератор у них общий, с какого перепугу джит обгонит машинный код? А начсет DLL'к под разные процы, так это уже есть.

VD>Просто динамическая оптимизация это еще большая задача чем обычная. Ну, да у MS, Sun и IBM на нее деньги должны найтись. :) Пущай мучаются...

Динамическая — это когда? В рантайме? А она что, бесплатная?

Здравствуйте VladD2, Вы писали:

VD>Здравствуйте Sergey, Вы писали:

S>>Неясно, че там интерпретировать при поиске текста регэкспами, реализованном на C++. Там достаточно построить конечный автомат (один раз для каждого регулярного выражения), и уже им искать. И я сильно сомневаюсь, что эта реализация КА (через таблицу состояний) будет работать медленней, чем код, сгенерированный из генерируемого программой описания КА на С#.

VD>Ну, тогда попробуй написать на С++ обычный if. Но так чтобы он лбые выражения мог обработать. :)

VD>У тебя выйдет огроменный и тормозной код. А ведь можно примерно так:
VD>

VD>if(SearchElem.Type == Str)
VD>  Compiler.Gen("if(strcmp(SearchElem, xxx) >= 0) ...)");
VD>else if(SearchElem.Type == Int)
VD>  Compiler.Gen("if(SearchElem >= xxx) ...)");
VD>...
VD>Compiler.Exec();
VD>

VD>И никакого полиморфизма и никаких тормозов.

Я когда-то делал примерно так:

for ( ; cur_char != '\0' && state != state_missing && state != state_found; ++cur_char)
    state = statearray[state][cur_char];

Основные затраты — на построение графа переходов КА (statearray), выполняемое при разборе выражения.

Здравствуйте Sergey, Вы писали:

S>Я когда-то делал примерно так:

S>

S>for ( ; cur_char != '\0' && state != state_missing && state != state_found; ++cur_char)
S>    state = statearray[state][cur_char];
S>

S>Основные затраты — на построение графа переходов КА (statearray), выполняемое при разборе выражения.

С Юникодом такая халява не покатит. Не заводить же полупустой Array на все 60k символов. Зато можно сгенерировать прямолинейный код с чем-нибудь типа if 'a' <= ch <= 'z' goto STATE_123;

S>>Я когда-то делал примерно так:

S>>

S>>for ( ; cur_char != '\0' && state != state_missing && state != state_found; ++cur_char)
S>>    state = statearray[state][cur_char];
S>>

S>>Основные затраты — на построение графа переходов КА (statearray), выполняемое при разборе выражения.

А>С Юникодом такая халява не покатит. Не заводить же полупустой Array на все 60k символов. Зато можно сгенерировать прямолинейный код с чем-нибудь типа if 'a' <= ch <= 'z' goto STATE_123;

Я думал, идею я ясно показал. Эта конструкция тоже тривиально реализуется без ран-тайм кодогенерации, например, так:

int i;
for (i = 0; i < intervals_size; ++i)
{
    if (interval[i].min <= cur_char && cur_char <= interval[i].max)
         break;
}
state = statearray[state][i];

Разреженный массив можно и другими способами реализовать, было бы желание. Можно и готовую библиотеку найти, при необходимости. В этом примере statearray тоже, кстати, можно сделать разреженным — у него довольно-таки регулярная структура.

PS:
А вот Бойер-Мур-Хоршпул для юникода вроде сильно извратный должен получиться.

Руками можно все, что угодно реализовать, но
1) Если ты заранее реализуешь RegExp, который тебе нужен, — зачем мучаться пусть его код сгенерирует программа.
2) Если ты задаешь его во время исполнения, то какая разница генерируется код или автомат тем более, что у тебя есть возможность выбора между этими возможностями.
Т.е. генерация кода явно не мешает, а в некоторых случаях может быть более выгодной. Вообще, генерация кода on-line открывает такие возможности, что я бы MSIL выучил только за то ... И рег. выражения только частный случай. Представь, что клиент сначала передает формат в котором будет посылать данные, сервер генерирует эффективный парсер и спокойно забирает данные.

Здравствуйте Аноним, Вы писали:

А>Руками можно все, что угодно реализовать, но
А>1) Если ты заранее реализуешь RegExp, который тебе нужен, — зачем мучаться пусть его код сгенерирует программа.

Никто и не собирается мучаться, есть же boost::regex :)

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

Вот я и говорю — разницы никакой, для регулярных выражений кодогенерация нафиг не нужна.

А>Т.е. генерация кода явно не мешает, а в некоторых случаях может быть более выгодной. Вообще, генерация кода on-line открывает такие возможности, что я бы MSIL выучил только за то ...

Дополнительные возможности редко мешают :) А для рантаймовой генерации кода, буде такая необходимость возникнет, мне хватает ассемблера x86.

А>И рег. выражения только частный случай.

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

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

Представил. Это примерно из той же категории, что и робот-гитарист Вертер:) Ты хоть раз парсер писал? А генератор парсеров? А кто в клиенте будет на ходу придумывать формат и генерировать для него грамматику? И, самый главный вопрос — зачем?

Здравствуйте Sergey, Вы писали:

S>Представил. Это примерно из той же категории, что и робот-гитарист Вертер:) Ты хоть раз парсер писал? А генератор парсеров? А кто в клиенте будет на ходу придумывать формат и генерировать для него грамматику? И, самый главный вопрос — зачем?

Да писал. Грамматику незачем генерировать. Клиент может поддерживать лишь часть ее. Кроме того, что такого в том, что клиент придумывает формат? Вполне можно написать, хотя, согласен, не просто, генератор парсеров по заданной грамматике из потока в дерево разбора. Тогда, например, можно будет легко написать свой интерпретатор простенького языка, не заморачиваясь с yaccами и lexами.

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

PS. Прошу заметить, что меня абсолютно не интересует, возможно ли реальное примение этих возможностей в коммерческих проектах. Лично мне они нравятся и я буду применять их в личных целях.

Здравствуйте Igor Trofimov, Вы писали:

IT>>>И .net врядли будет панацеей.

VD>>Дык .NET — это не язык. Там можно и на C++, и на C# и на JScript и на Перле с Эфилом, да и на MSIL-е по памяти пройтись без проблем. ;)

IT>Я говорю, что

IT>а) языка, приятного всем — не придумать
IT>б) .net — отчасти это попытка "примирить" языки за счет объединения на низком уровне.

ИМХО, больше похоже на попытку причесать все языки под одну гребёнку .NET :maniac:

IT>и говорю, что мне кажется, что проблемы "языковых войн" до конца .net не решит, потому что сам язык приходится менять (см. MC++, VB/NET, Delphi.NET) чтобы он годился в .NET. Хотя, могу ошибаться.

Вот-вот :crash:

Здравствуйте VladD2, Вы писали:

VD>Так тот самый ngen.exe и АПИ на котором он сделан как раз это и позволяют сделать. Вот толко толку от этого никакого нет. Ускоряется толко закрузка. Траты на поддержание CLR нисравнимы с мизирным выигрышем получаемым от прикомпиляции. К тому же есть еще сообщежение в пользу джита. Если происходит джит нескольких модулей (длл-ек), то джит может (пока что потенциально) делать более полную оптимизацию. Так можно будет делать инлайн-подстановки фуниций из другого модуля и избавляться от позднего совязывания (в смысле вызовов черз указаели) которое в ином случае неизбежно для компонентных архитектур.

Свежо предание... По идее, такую подстановку можно делать только при уверенности, что модуль, откуда инлайнирована функция, — никогда не будет заменён. А как эту уверенность создать?

Здравствуйте Аноним, Вы писали:

А>Здравствуйте Sergey, Вы писали:

S>>Представил. Это примерно из той же категории, что и робот-гитарист Вертер:) Ты хоть раз парсер писал? А генератор парсеров? А кто в клиенте будет на ходу придумывать формат и генерировать для него грамматику? И, самый главный вопрос — зачем?

А>Да писал. Грамматику незачем генерировать. Клиент может поддерживать лишь часть ее. Кроме того, что такого в том, что клиент

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

А>придумывает формат? Вполне можно написать, хотя, согласен, не просто, генератор парсеров по заданной грамматике из потока в дерево разбора. Тогда, например, можно будет легко написать свой интерпретатор простенького языка, не заморачиваясь с yaccами и lexами.

Ты не ответил на главный вопрос — зачем это делать, если это решается гораздее более простыми средствами?

А>А что касается редкого применения самомодификации, так аппетит приходит во время еды. На С++ особо не посамомодифицируешься, а когда такая возможность легко доступна, то применение ей найдется.

Бред. Что мешает в C++ программах делать самомодифицирующиеся ассемблерные вставки?

А>PS. Прошу заметить, что меня абсолютно не интересует, возможно ли реальное примение этих возможностей в коммерческих проектах. Лично мне они нравятся и я буду применять их в личных целях.

Вирусы писать, не иначе :)

Здравствуйте Sergey, Вы писали:

[...]

S>>>Лично меня от компонентного подхода воротит. Но это уже тема для другого топика.

VD>>Это точно. Но сразу предупреждаю, заклюют.

S>Пофигу. Нехай злобствуют.

Поддерживаю.

Во первых речь идет не столько о самомодификации, сколько о генерации кода. На С++ все, что можно сделать, это сгенерировать программу на нем же или другом языке и скомпилировать (вариант компиляции сразу в машинный код слишком сложный и требует непотребного количества времени). Но не у всех есть компиляторы, да и не факт, что твоя программа скомпилируется без всяких вопросов (вдруг нет каких-то библиотек или еще чего). .NET предлагает хорошую альтернативу в самом себе.
Про простые средства я не понял. Чего может быть проще, чем написать БНФ + немного информации для lexer'а и скормить это программе, которая выдаст тебе компилятор из исходного файла в дерево. Если использовать yacc, lex выйдет сложнее, а если писать руками, то и говорить нечего. Конечно, этот пример довольно специальный, но можно предположить, например, что пользователь делает что-нибудь в GUI (модель нейронной сети, например), а программа затем генерирует код для обучения и выполнения конкретно этой нейронной сети.
>>Бред. Что мешает в C++ программах делать самомодифицирующиеся ассемблерные вставки?
Мешает то, что большую подпрограмму так не напишешь, а автоматически генерировать ассемблер гораздо сложнее, чем MSIL, кроме того, при этом лишаешься оптимизации (и может быть переносимости), проверки типов и т.п.

Здравствуйте Аноним, Вы писали:

А>Во первых речь идет не столько о самомодификации, сколько о генерации кода. На С++ все, что можно сделать, это сгенерировать программу на нем же или другом языке и скомпилировать (вариант компиляции сразу в машинный код слишком сложный и требует непотребного количества времени). Но не у всех есть компиляторы, да и не факт, что твоя программа скомпилируется без всяких вопросов (вдруг нет каких-то библиотек или еще чего). .NET предлагает хорошую альтернативу в самом себе.
А>Про простые средства я не понял. Чего может быть проще, чем написать БНФ + немного информации для lexer'а и скормить это программе, которая выдаст тебе компилятор из исходного файла в дерево.

Но ведь это можно и "на ходу" из примитивов строить.

А> Если использовать yacc, lex выйдет сложнее, а если писать руками, то и говорить нечего. Конечно, этот пример довольно специальный, но можно предположить, например, что пользователь делает что-нибудь в GUI (модель нейронной сети, например), а программа затем генерирует код для обучения и выполнения конкретно этой нейронной сети.

Мммм... А не утонешь с необходимым тестированием/доказательством корректности генератора? ИМХО, на примитивах всё же чуть надежнее выйдет. Ну а далее дерево примитивов — хошь в C, хошь в C++, хошь в Pascal...

>>>Бред. Что мешает в C++ программах делать самомодифицирующиеся ассемблерные вставки?
А>Мешает то, что большую подпрограмму так не напишешь, а автоматически генерировать ассемблер гораздо сложнее, чем MSIL, кроме того, при этом лишаешься оптимизации (и может быть переносимости), проверки типов и т.п.

Дык! Если тебе контроль типов на самом нижнем уровне нужен, так это означает, что наверху куча ошибок заложена. ИМХО — неправильно это.

Здравствуйте Sergey, Вы писали:

S>Соляру под писи саны, кстати, вроде передумали бросать.

Хорошо если так.

S>А потом разбирайся, какую битмапу использовать. Нафиг.

Я обычно разбираюсь сначало.

S>Злые разработчики библиотеки забыли приделать к классу wxBitmap (а это был он) функцию Clear(). На самом деле, такие ситуации очень часто встречается.

Ты случаем на VB или Дельфи не переписал? Забыли не забыли... добавь и живи спокойно дальше.

VD>>А хелперы — это просто обертки. Они не обязательно являются умными и указателями.

S>Вот тут поподробнее — как они мне без указателей один объект грохнут и другой создадут? И нафиг вообще нужны? Их же самому писать придется, вместо двух строчек кода...

Они обычно используется для временных объектов. Их время жизни определяет время жизни обертываемого объекта. Ну, а если нужно порулить вручную, то для этого и делают разные Attach-и, Detach-и и Clear-ы.

S>Там не отмечен один факт — VC 6/7 не является полноценным компилятором C++

Ну, это уже демогогия. Тебе шашечки или ехать? Этот компилятор один из самых популярных. 99% созданного кода на нем компилируется.

S>Что-то вы там с интелом нашаманили. Я, помнится, в вашем "шустрике" одну ошибку нашел — че,

Вот эта ошибка и давала Интелу приимущество. Как поправили, он сразу из лидеров вышел.

S>следующую искать?

Ищи хуже не будет.

У нас нет задачи кого-то выгородить.

S>Front-end'ы для C++ обычно генерируют сишный код. А дальше можешь компилировать его своим любимым оптимизирующим компилятором C. Можешь даже клиенту в таком виде поставлять, чтоб он на target-системе все сам скомпилировал — украсть куски из него будет не намного проще, чем из MSIL'а.

Так из мсила как раз украсть все очень легко. Там такое тайпинфо...

VD>>Да? А мы как-то ими пользуемся.

В .NET любой класс по определению компонент. Да и COM-мом пользоваться можно. Хоть и тяжело...

S>С трудом, наверное, пользуетесь. Чужими компонентами, по крайней мере. Иначе с чего вдруг свой контейнер писать стали — чужих мало, что ли?

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

VD>>Задачи бывают разные. И все больше и больше они требуют динамизма и расширяемости на лету. Именно это и дают компонентные технологии.

S>Само собой, но в основном они дают повышенную падучесть

Опять же, что называть компонентными технологиями? Вот плагины к FAR'у — это компоненты или нет?

Ты случам не с Салярки пишешь? Вот и мне кажется из IE запушенного под одной из версий Виндов. Так вот они почти полностью из компонентов состоят. И как видишь живут. Про падучесть это форменный предрассудок. Программы падают из-за ошибок, а не из-за применения тех или иных программных парадигм.

S>Скажем так, большинство программ, но не все. Тот же 3D Studio MAX учитывает и объем памяти, и тип процессора.

Видимо по этому это он медленнее всех рендерит конечные сцены.

Если он что-то и учитывает, то это реализовано на компонентной основе. Это конечно лучше чем ничего, но по сравнению с полной оптимизацией все же не так здорово.

S>Многопроцессорность тривиально обрабатывается и в программах на C++.

Можешь назвать хотябы 3 штуки? И не рендереры. Я лично знаю, только SQL-серверы, да и то только Oracle, MS и почивший Informix. Тут же речь идет, о том что от второго процессора могут начать выигрывать большинство программ.

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

Дык потоки — это часть того же .NET и Явы. Так что они довольно много знают. Достаточно, чтобы распаралеллить многие вычисления. Представь, при инсталяции на конкретную систему му узаем что есть четыре процесора... мы копилируем код системных библиотек так, чтобы они параллелили все что получится для этих четырех камней. На системе с двумя камнями параллелим для двух. Ну, а если процессор один, то выкидываем лишний код. На системе без процессора включаем совтвэа-эмулейшон.

VD>>Ну, ну. Вот как по-твоему если компонент хочет сделать вызов по сети, то для диалапа и для 100 мб эзернета код должен быть одинаковый? Даже сейчас народ вынесет такой код в отдельную длл-ку и сделает две реализации. Ну, а динамическая архитектура позволяет сделать этот процесс бедее гибким и безшевным.

S>Не отклоняйся от темы

Речь шла о том, что компилятор сам (не) сможет сгенерировать из одного и того же исходника разный код для диалапа и эзернета.

Дык комиляторы тоже люди делают, к тому же мне пофигу почему что-то будет работать бысрее. Мне нужен результат, ну, а то что он получин на подставах и домашних заготовках, меня не интересует. Главное, что в средах типа .NET такие оптимизации можно сделать, а в компиляруемых все нужно будет делать самому.

VD>>А тут ка не выбирай. Теоритические приемущества есть. На практике отставание минимельно. Еще лет пять и теория будет давать диведенты. Ты думаешь почему MS и Sun так драться начали?

S>Они по жизни драчливые

Ошибаешься они дерутся только за деньги. Причем исглючительно за большие.

S> Лет семь уже деруться — есть что делить, однако. А если все с джитами и нетами хорошо будет, так я на них и ругаться перестану.

Дык с ними уже и сейчас все не так плохо. Я вот перестал.

VD>>Короче, дурака не включай. Сам понимаешь что мешает, что что процессоров очень много и то что компоненты (ну хоть те же длл-ки) оптимизироваться могут только в пределах одного проекта. К тому же кто тебе сказал что не применяются? В том же VC7 есть такая опция "Глобал оптимизэйшон". Так вот она пишит в объектники не машинный код, а язык а-ля MSIL. А кодогенерацией занимается линкер.

S>Да мне по барабану, кто там кодогенерацией занимается и какое внутренне представление данных использует связка компилятор+линкер.

Ты спросил "почему такие технологии в компиляторах не используют?". Я ответил что пытаются...

S> Если же кодогенератор у них общий, с какого перепугу джит обгонит машинный код?

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

S> А начсет DLL'к под разные процы, так это уже есть.

Есть. Кто же спорит. Только мола (задача то не тривиальная) и оптимизируется только чать кода. А тут можно оптимизировать весь. Что же тут плохого?

VD>>Просто динамическая оптимизация это еще большая задача чем обычная. Ну, да у MS, Sun и IBM на нее деньги должны найтись.

Пущай мучаются...

S>Динамическая — это когда? В рантайме?

Да. Джит работает сразу после запуска приложения.

S> А она что, бесплатная?

Кто она? Оптимизатор входит в рантаймподсистему .NET и Явы...

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	22.08.02 23:32
Оценка:

От:	IT	linq2db.com
Дата:	23.08.02 05:41
Оценка:

От:	IT	linq2db.com
Дата:	23.08.02 05:48
Оценка:

От:	IT	linq2db.com
Дата:	23.08.02 06:03
Оценка:

От:	Anatolix	https://www.linkedin.com/in/anatolix/
Дата:	23.08.02 07:45
Оценка:

От:	VladD2	www.nemerle.org
Дата:	23.08.02 22:46
Оценка: