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

A>В частности это значит что при загрузке
A>2 копий программы она займет в памяти двойное место, а не одинарное
A>как с обыкновенным exe.

Вот это место по-подробнее можно

A>Впрочем MS обещала уметь конвертировать IL в нативный код при
A>установке программы, вот это было бы полезно. Кто нибудь из дотнетеров
A>проясните это уже сделано? И на сколько это популярно?

Есть такая утилита NGen.exe, которая может создать native image. Но, на сколько я знаю, её нужно использовать до того, как программа будет упакована в инсталятор.

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

M.NET>Здравствуйте Anatolix, Вы писали:

A>>В частности это значит что при загрузке
A>>2 копий программы она займет в памяти двойное место, а не одинарное
A>>как с обыкновенным exe.

M.NET>Вот это место по-подробнее можно

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

Таким образом
1) Если часть файла не будет нужна, то ее не выкинут в swap
а просто выкинут, а потом подгрузят прямо из exe.(С этим связан
эффект что загруженный exe файл нельзя стереть или изменить)
2) Файл не загружается сразу, а просто отражается на память
и загружается по мере надобности. Т.е. даже если у тебя файл
размером в 100 Mb то загрузится только то что попользовано
(загружается все страницами по 4K)
3) Если ты загрузил 100 копий программы, то образ
exe в памяти на самом деле общий для них всех.

(Все сказанное касается и dll пока их не коснется rebase
который тоже фактически является модификация кода. Не касается модулей
загруженых с сети или сменных носителей. Подробней можно
узнать в Рихтере или статье К.Касперски "Паковать или не паковать"
в одном из журналов "программист")

Но как только приложение начинает изменять свой код, то Windows
уже не может предсказать что получится и выделяет отдельную страницу
памяти(COPY_ON_WRITE) именно поэтому всякие exepacker-ы это
плохо т.к. занимают свою память. Windows не может знать что
у них все равно образ один и тот же, вдруг они из вредности
распаковываются в другой код.

Это касается всего самомодифицирующегося кода, в том числе и
JIT компиляторов которые тоже создают код на лету.

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

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

В общем и целом пока что пострадал только один язык — VB. Остальные толко расширены. Тот же MC++ компилирует любые исходники. Можно даже COM лабать.

A>Это касается всего самомодифицирующегося кода, в том числе и
A>JIT компиляторов которые тоже создают код на лету.

Ты уверен, что все устроено именно так в CLR?

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

A>>Это касается всего самомодифицирующегося кода, в том числе и
A>>JIT компиляторов которые тоже создают код на лету.

IT>Ты уверен, что все устроено именно так в CLR?

Нет, но других путей реализации я не вижу.

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

SMS>Доброе время суток!

SMS>Что для вас значит C++?
SMS>В чем его привлекательность лично для вас ?

SMS>Было бы интересно почитать...

Как всегда бывает во флеймах, сопр тем дальше от сути, чем больше во флейме сообщений :(
Я вот не выдержал и решил сказать... А, ну так вот. Следуя примеру Мишки.НЕТ, сначала скажу за что я
не люблю С++ (да так оно и проще будет :)) ).
А не люблю я его вот за что:

1. За (местами) довольно корявый синтаксис
   
2. За множество случаев, где происходит неявное приведение типов
   
3. За то, что в его модели обработки исключений отсутствует конструкция try..finally :))
   
4. За его стандартную библиотеку (я не имею ввиду STL)
   
5. За его модель организации исходного кода (h, cpp)
   
6. За слишком много моментов с undefinite behavior и implementation-dependent
   
7. За все то, что не любят в универсальных языках программирования

Большинство этих, на мой взгляд, недостатков обусловлено backward compability, а без него С++ был бы
изначально обречен на провал.Еще больше "недостатков" привносят в язык отдельные его реализации :))

За все остальное лублу я ехо, мать-о так :super:

P.S. Но тем не менее, С++, на мой взгляд, выпоняет роль ОПП-ассемблера и сколько бы у него не было
недостатков, знать его не помашает. :user:

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

A>JIT это плохо т.к. фактически является самомодифицирующимся кодом который
A>плохо переносится Windows.

Я бы уточнил... не Windows а x86-й архитектурой. И не "самомодифицирующимся", а динамически создваваемый. Но по сути ты прав.

A> В частности это значит что при загрузке
A>2 копий программы она займет в памяти двойное место, а не одинарное
A>как с обыкновенным exe.

Когда-то Windows 3.х оптимизировала работу с памятью путем загрузки всего в одно адресное пространство. Память экономилась радикально но любая программа могла положить всю ОС. В NT сделали компромисный вариант и стали разделять только статические модули. Это (на практике) привело к невероятному росту потребленя памяти. Но тут к счастью эта самя память подешевела. В .Net безопастный код можно сново поместить в один процесс. В принципе это может потенциально даже сократить потребление памяти. Вот только жаль что это никому не нужно. Всем нужна в первую очередь скорость, безопастность и простота использования. В .NET все это есть. Ну, а загрузка модулей... Она почти не работала уже в NT. Те кто программирует на VC должны были заметить, что при загрузке почти любого процесса выскакивают сообщения о том что "модуль перемещен...". Это означат, что модуль нельзя разместить в ту точку адресного простраства где его предпологал разместить программист (обычно все на это просто плюют). При этом точно так же как и в .NET для модуля выделяется просраство в динамическом свопфайле и получается копия. Если уж говорить об экономии, то нужно обратить внимание на то, что размер исполняемых модулей обычно несравнимо мал по сравнению с данными приложения, а они по определению должны копироваться. Учитывая все это становится понятно, что на сегодня эканомия на загрузке модулей не стоит свечь.

A>Впрочем MS обещала уметь конвертировать IL в нативный код при
A>установке программы, вот это было бы полезно. Кто нибудь из дотнетеров
A>проясните это уже сделано? И на сколько это популярно?

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

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

M.NET>Есть такая утилита NGen.exe, которая может создать native image. Но, на сколько я знаю, её нужно использовать до того, как программа будет упакована в инсталятор.

Нет. Ее, а лоуче АПИ на котором она сделана, нужно использовать в самом инсталляторе. Предкомиляция должна делаться на конечной машине.

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

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


Повторяю... никакого самомодифицирующегося кода в .NET нет. Там есть джит-компилякия. Перед вызовом процедуры она компилируется в код процессора и выполнение происходит так же как это былобы если создать код обычным компилятором.

Оверхед есть. Код же нужно скомпилировать. Но это делается один раз (обычно при старте приложниея). Далее скорость выполнения оптимальная.

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


S>И шо, че-нибудь гуевое на нем можно слабать? Под BSD?

И шо она тебе надо? :))

Интероп есть. Подключай тот же Qt и лабай гуи. Может тебе памятник поставят (нерукотворный). ;)

S>Ты, видимо, тоже перешел в стадию забывания C++? Это всего лишь самый простой способ избежать возни с указателями в случае, если требуется повторная инициализация объекта.

Ну, я бы не стал так сильно экономить и воспользовался бы отдельными хелперами.

S>Как раз философский разговор пошел...

:)

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

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

S> Да и гибкость, что плюсовая, что нетовская, обычному человеку не нужна. Потому что даже драйверы для компьютерного железа, равно как и само железо, уже давно принято выдавать на-гора с кучей ошибок. Не говоря уж о компиляторах, библиотеках и прочем софте. А уж если от компилятора еще на порядок больше интеллекта потребуется, чтобы учитывать "пр." характеристики машины, тут такое начнется...

Вот сразу видно, что ты не понимаешь компонентного подхода. А ведь идея проса — разделяй и властвуй. На оптимизацию джита можно осадить отдельную команду. Качество ее работы можно легко проверить. Зато в конце мы получаем значительное упрощение в создании компиляторов. В бетах .NET шел пример... настоящий компилятор С++. Такого раньше небыло. И возможно стало это именно потому, что компилятор разделен на составляющие. И главную из них (оптимизатор и герератор машинного кода) писать уже не нужно.

S>Кстати, насчет отсталости — от чего именно отстал С++? Уместнее говорить об убогости или неполноценности. Беда только в том, что для меня С# ничем его не лучше. Нужен-то (мне, а не MS) кардинально другой язык, а не очередная Java с рюшечками.

Об недостатках С++ здесь говорилось не мало. Есть и неприятие нового, и отрицание разумного, и консервация проблем. Но вот для меня главное, что С++ совершенно не имеет средств создания компонентных архитектур. Я 7 лет занимался COM-ом и сейчас смело могу сказать, что CLR это лучшая реализация идей СОМ-а из всего что я видел. Причем очень важно, то что теперь можно заниматься программированием задачи, а не вечной наклюпкой объходов и замазок с целью хоть как-то упростить себе жизнь.

S>Вот меня списочек этих характеристик и интересует. Тех, которые могут учитываться при кодогенерации. Исключая количество оперативки и тип процессора.

Забавно... а что тип процессора и объем памяти это жуе не характеристики. Или они не важны? Или чистый компилятор может их учитывать тоже?

S> И особенно — как именно они будут учитываться. Поскольку ссылка на какие-то мифические характеристики, которые будут учитываться при компиляции, выглядит как демагогия. Короче говоря, толку от того, что эти характеристики известны (кроме, разве что, типа процессора), не предвидится.

Может учитываться прорва характеристик. Так даже тип ОС может полиять на так какие алгоритмы применять. Для клиента нужно экономить память и максимально быстро откликаться на запросы, а для сервера напротив — обеспечивать максимальную пакетную производительность.

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

Вопрос в том, что на сегодня это все только планы. Более того в том же .NET есть рад недостатков котрые уменьшают выигрыш. Так отсуствие шаблонов приводит к нунужным виртуальным вызовам и как слествие потере производительности.

Раньше я тоже не верил, что "интерпретаторы" могут паказвать результаты хотябы близкие к компиляторам. Но с появлением джитов, я поменыл свою точку зрения. Тесты показывают, что скорость выполнения кода у того же .NET зачастую выше чем у BCC или VC6. Ну, а если сравнить скрость работы .NET-программы и ее аналога на VB6 (который между прочим позволяет получать полностью компилированные модули) показывает, что современные "интерпретаторы" очень даже ничего.


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

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

VD>>Уже месяца два как есть. Не слышал такого слова "Ротор"? MS (вроде совместно с королом) выделили из .NET независящую от платформы серверную часть и портировала ее под Фришку. Все исходники есть. Портировать это дело под разные Линухи проблем не составит.

M.NET>Адрес-то кинь А то я тут с местными Java-любителями борюсь, как бы хотелось их всех на C# пересадить...

Вот RSDN CD #1

Или у производителя http://msdn.microsoft.com/downloads/default.asp?URL=/downloads/sample.asp?url=/msdn-files/027/001/901/msdncompositedoc.xml (~ 11 меговый архив).

Основываясь на мнении товарища Анакрино это на 90% исходники CLR-а.

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

SMS>>Что для вас значит C++?
SMS>>В чем его привлекательность лично для вас ?

SMS>>Было бы интересно почитать...

DS>Как всегда бывает во флеймах, сопр тем дальше от сути, чем больше во флейме сообщений

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

Может ввести какие-нибудь правила на ответы (чтобы они не отклонялись от темы) ?
Или чтобы автор сообщения мог закрыть тему, если там начинают появляться ответы, не относящиеся к теме ...

Господа!

Давайте не будем спорить!

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

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

SMS>Что для вас значит C++?
SMS>В чем его привлекательность лично для вас ?

А я его и не люблю и люблю — я с ним (в нём?) работаю. Изменить его не могу, а потому и принимаю как есть, с достоинствами и недостатками.

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

А на одном языке пусть "разговаривает" процессор, раз железяка и камень!

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

SMS>Я не ожидал, что мой вопрос породит столь бурную дискуссию
SMS>Мне просто хотелось узнать, что думает народ по этому поводу. А он превратился в такой флейм

Да это, повторюсь, обычное явление

SMS>Может ввести какие-нибудь правила на ответы (чтобы они не отклонялись от темы) ?
SMS>Или чтобы автор сообщения мог закрыть тему, если там начинают появляться ответы, не относящиеся к теме ...

Я вот тоже как-то над чем-то подобным думал. Но пришел к выводу, что эту проблему нормальным способом не решить. А не нормальных способов не надо Тем более, что иногда, хоть спор и уходит в сторону, все женекоторые интересности проскакивают

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

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

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

VD>Повторяю... никакого самомодифицирующегося кода в .NET нет. Там есть джит-компилякия. Перед вызовом процедуры она компилируется в код процессора и выполнение происходит так же как это былобы если создать код обычным компилятором.

VD>Оверхед есть. Код же нужно скомпилировать. Но это делается один раз (обычно при старте приложниея). Далее скорость выполнения оптимальная.

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

Я тебя понял так, что компиляция проводиться при разборе регулярного выражения : "Например, регулярные выражения в .NET поддерживаю динамическую герерацию кода. Это позволяет избежать оверхэда накладываемого интерпретацией регэкспов." Соответственно, для каждого нового выражения код надо генерировать заново — так?

S>>И шо, че-нибудь гуевое на нем можно слабать? Под BSD?

VD>И шо она тебе надо? :))

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

VD>Интероп есть. Подключай тот же Qt и лабай гуи. Может тебе памятник поставят (нерукотворный). ;)

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

S>>Ты, видимо, тоже перешел в стадию забывания C++? Это всего лишь самый простой способ избежать возни с указателями в случае, если требуется повторная инициализация объекта.

VD>Ну, я бы не стал так сильно экономить и воспользовался бы отдельными хелперами.

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


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

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

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

S>> Да и гибкость, что плюсовая, что нетовская, обычному человеку не нужна. Потому что даже драйверы для компьютерного железа, равно как и само железо, уже давно принято выдавать на-гора с кучей ошибок. Не говоря уж о компиляторах, библиотеках и прочем софте. А уж если от компилятора еще на порядок больше интеллекта потребуется, чтобы учитывать "пр." характеристики машины, тут такое начнется...

VD>Вот сразу видно, что ты не понимаешь компонентного подхода. А ведь идея проса — разделяй и властвуй.

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

VD>На оптимизацию джита можно осадить отдельную команду. Качество ее работы можно легко проверить. Зато в конце мы получаем значительное упрощение в создании компиляторов. В бетах .NET шел пример... настоящий компилятор С++. Такого раньше небыло. И возможно стало это именно потому, что компилятор разделен на составляющие. И главную из них (оптимизатор и герератор машинного кода) писать уже не нужно.

То-то они до сих пор нормальный плюсовый компилятор никак не выпустят :) А насчет отдельного оптимизатора и генератора машинного кода, так это любой фронт-енд С++ -> С так устроен.

S>>Кстати, насчет отсталости — от чего именно отстал С++? Уместнее говорить об убогости или неполноценности. Беда только в том, что для меня С# ничем его не лучше. Нужен-то (мне, а не MS) кардинально другой язык, а не очередная Java с рюшечками.

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

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

VD>Я 7 лет занимался COM-ом и сейчас смело могу сказать, что CLR это лучшая реализация идей СОМ-а из всего что я видел. Причем очень важно, то что теперь можно заниматься программированием задачи, а не вечной наклюпкой объходов и замазок с целью хоть как-то упростить себе жизнь.

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

S>>Вот меня списочек этих характеристик и интересует. Тех, которые могут учитываться при кодогенерации. Исключая количество оперативки и тип процессора.

VD>Забавно... а что тип процессора и объем памяти это жуе не характеристики. Или они не важны? Или чистый компилятор может их учитывать тоже?

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

S>> И особенно — как именно они будут учитываться. Поскольку ссылка на какие-то мифические характеристики, которые будут учитываться при компиляции, выглядит как демагогия. Короче говоря, толку от того, что эти характеристики известны (кроме, разве что, типа процессора), не предвидится.

VD>Может учитываться прорва характеристик. Так даже тип ОС может полиять на так какие алгоритмы применять. Для клиента нужно экономить память и максимально быстро откликаться на запросы, а для сервера напротив — обеспечивать максимальную пакетную производительность.

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

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

Не смеши :)))

VD>Вопрос в том, что на сегодня это все только планы. Более того в том же .NET есть рад недостатков котрые уменьшают выигрыш. Так отсуствие шаблонов приводит к нунужным виртуальным вызовам и как слествие потере производительности.

VD>Раньше я тоже не верил, что "интерпретаторы" могут паказвать результаты хотябы близкие к компиляторам. Но с появлением джитов, я поменыл свою точку зрения. Тесты показывают, что скорость выполнения кода у того же .NET зачастую выше чем у BCC или VC6. Ну, а если сравнить скрость работы .NET-программы и ее аналога на VB6 (который между прочим позволяет получать полностью компилированные модули) показывает, что современные "интерпретаторы" очень даже ничего.

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

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

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

S>Я тебя понял так, что компиляция проводиться при разборе регулярного выражения : "Например, регулярные выражения в .NET поддерживаю динамическую герерацию кода. Это позволяет избежать оверхэда накладываемого интерпретацией регэкспов." Соответственно, для каждого нового выражения код надо генерировать заново — так?

Ну так. Чего ж тут неясного. И если тебе надо этот регексп применить к каждой строке файла — то лучше сперва его скомпилить!

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

S>>Я тебя понял так, что компиляция проводиться при разборе регулярного выражения : "Например, регулярные выражения в .NET поддерживаю динамическую герерацию кода. Это позволяет избежать оверхэда накладываемого интерпретацией регэкспов." Соответственно, для каждого нового выражения код надо генерировать заново — так?

IT>Ну так. Чего ж тут неясного. И если тебе надо этот регексп применить к каждой строке файла — то лучше сперва его скомпилить!

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

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

S>Я тебя понял так, что компиляция проводиться при разборе регулярного выражения : "Например, регулярные выражения в .NET поддерживаю динамическую герерацию кода. Это позволяет избежать оверхэда накладываемого интерпретацией регэкспов." Соответственно, для каждого нового выражения код надо генерировать заново — так?

Именно.

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

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

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

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

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

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

    CBitmap hbmp1;
    CBitmap hbmp2;
    ...

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

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

Ну, и т.п.

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

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

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

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

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

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

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

Автор(ы): Владислав Чистяков

http://www.rsdn.ru/article/?devtools/perftest2.xml

Автор(ы): Владислав Чистяков

http://www.rsdn.ru/article/?devtools/perftest3.xml

Автор(ы): Владислав Чистяков

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IT>Ну так. Чего ж тут неясного. И если тебе надо этот регексп применить к каждой строке файла — то лучше сперва его скомпилить!

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

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

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

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

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

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

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