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

VD>Вот сейчас я занимаюсь переделыванием Word-ового шаблона для верстки статей для RSDN. Раньше он был создан на базе automation-API ворда и нэтив COM-библиотек. Кода на VB6 было не очень много, так как основная работа "поручалась" компонентам написанным на С/С++ — MS XML, Regex-ы и API ворда (все нэйтив и написанное на С/С++). Тормозил старый шаблон просто чудовищно, не смотря на использования в основном нэйти-кода! Даже небольшие статьи обрабатывались десятками секунд. А большие минутами (и это на весьма современном железе).
VD>Новый шаблон работает посредственно с фалом в формате Word XML 2003. Он парсит его с помощью менеджед-библиотеки System.Xml.Linq и обрабатывает (в основном в функциональном стиле). Далее он генерирует ХМЛ в формате RSDN ML и с помощью прекомпилированного в управляемый код XSLT генерирует HTML со статьей (для предварительного просмотра). Так вот даже на документы весьма большого размера обрабатываются в мгновение ОК.

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

Круто сраниваешь.
Это все равно, что бросить ферари в болото (в котором она завязнет), а запор поставить на хорошую асфальтированное покрытие. И из сравнения результатов делать вывод, что скоростные характеристики у запора "очень высокие".

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

L>Круто сраниваешь.
L>Это все равно, что бросить ферари в болото (в котором она завязнет), а запор поставить на хорошую асфальтированное покрытие. И из сравнения результатов делать вывод, что скоростные характеристики у запора "очень высокие".

Я сравниваю то что есть в реальной жизни. Дорог нет. Есть только направления. И ферари ваш (которой в прочем на поверку не ферари а банальные хадули) вязнет в трясине, а запоржец (который в прочем скорее джип VIP-уроня) позволяет передвигаться по этой пересеченке с очень высокой скоростью.

В общем, есть задача, есть и лучшее для нее решение. И нэйтив-код тут мне ничем не помогает, а наоборот, ого-го как мешает.

Мы же здесь говорили о скорости. Так вот я просто указал, что скорость получается не просто приемлемая, а невероятно высокая. И это при том, что весь используемый в проекте код — это управляемый код. Причем не малая часть этого кода написана на Nemerle. Я уверен, что будь он целиком написан на Питоне или Руби, и особенно без применения С-шнхы либ, то тормозил бы серьезно. А будь он написан на голом С в супер-оптимальном хакерском стиле, то никто бы и в микроскоп разницы в скорости не заметил.

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

VD>Мы же здесь говорили о скорости. Так вот я просто указал, что скорость получается не просто приемлемая, а невероятно высокая. И это при том, что весь используемый в проекте код — это управляемый код.

Ты просто не указал на источник тормозов в старом коде, а это вовсе не то, что старый код — unmanaged, а то, что использовался out-of-rocess automation. Используй ты его в managed-коде, тормоза никуда не пропали бы.

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

VD>Позволю себе усомниться. Чудес все же не бывает.

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


FR>>Форт не генерирует. Но добавив небольшой модуль начинает это делать. Питон тоже.

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

VD>То что для питона такой есть — это полнешая чушь. Я так понимаю ты имеешь в виду PyPy. Назвать его "модулем" можно с огромной натяжкой. Это отдельный компилятор. И он несомненно ускоряет код Питона (пусть даже и не всегда). Вот только беда в том, что Питон клинически плохо компилируется в виду своей динамической семантики. Так что эффект от его прекомпиляции не очень значительный. Причем чем более продвинутые возможности используются в программе, тем меньше толку будет от ее компиляции.

Я имею ввиду ни PyPy (это отдельная реализация питона) а Psyco http://psyco.sourceforge.net/ JIT компилятор выполненный в виде модуля к обычному CPython.
Плохо или хорошо компилируется это неважно, главное принципиальных различий от java или NET никаких.

VD>Тема холивара "Скрипы быстры как ветер" меня не трогает. Развивать я ее не намерен.

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

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

L>Ты просто не указал на источник тормозов в старом коде, а это вовсе не то, что старый код — unmanaged, а то, что использовался out-of-rocess automation.

А с чего ты взля что "использовался out-of-rocess automation"?

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

L>Используй ты его в managed-коде, тормоза никуда не пропали бы.

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

Кстати, запускаются они так же из макросов ворда как in-process-сервер. Вся разница только в том, что вместо нэйтив компонет испоьзуется управляемые библоитеки.

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

L>>Ты просто не указал на источник тормозов в старом коде, а это вовсе не то, что старый код — unmanaged, а то, что использовался out-of-rocess automation.

VD>А с чего ты взля что "использовался out-of-rocess automation"?

В посте, на который я отвечал, не упоминались макросы, но было про VB6 и automation. Я решил, что работа с вордовым документом велась из VB. Я тебя неправильно понял. Возражение снимается с повестки.

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

FR>Там никаких чудес и нет, по сути "интерпретатор" это косвенный ассемблерный jmp. Базовые слова написаны на встроенном ассемблере
FR>в результате получается очень быстро. Вернее получалось лет пятнадцать назад, современные процессоры (хотя самые современные уже нет)

Это сотрясение воздуха. Для волнение нетривиальная работы нужно 90% команд процессора. И их "косвенное" выполнение и есть интерпретация. Кроме косвенности есть еще сужение системы типов, использование проверок и т.п. Все в месте и замедляет код. Если бы это было не так, то на можно было бы увидеть тесты демонстрирующие отсутствие разницы в скорости. А по факту пока что форт нигде где требуется производительность не применяется. Насколько мне известно в основном его применяют там где требуется очень компактная и переносимая ВМ. О Питоне даже говорить не приходится. Тормозом был, тормозом и остнется.

FR>не очень любят такую схему, ну и плюс оверхед от стека вместо регистров. Но все-равно вполне сопоставимо с си.

Пруфлинк, плиз.

FR>Я имею ввиду ни PyPy (это отдельная реализация питона) а Psyco http://psyco.sourceforge.net/ JIT компилятор выполненный в виде модуля к обычному CPython.
FR>Плохо или хорошо компилируется это неважно, главное принципиальных различий от java или NET никаких.

А кто-то говорит о принципиальной разнице? Если есть джит который компилирует 100% кода, то это, несомненно, компилятор. Ну, а то что от него нет никакого толко обесловлено тем, что он вынужден вставлять куски интерпретатора в генерируемый код (в виду динамической природы языка), ну, и другой оверхэд (вроде использования числе неограниченной точности) тоже никто не отменял.

VD>>Тема холивара "Скрипы быстры как ветер" меня не трогает. Развивать я ее не намерен.

FR>Меня тоже, просто демонстрирую что все не так просто и четко разделить эти понятия сейчас мало реально.

Да ничего ты не демонстрируешь. Ты свои абсурдные рассказы уже почитай 10 лет рассказываешь и никого не убедил. Насколько я понимаю при всем восхищении Поитоном работаешь ты на С++ или чем-то вроде того. Так почему ты свое начальство то не переубедил перейти на "компилируемый Питон"?

Может пора попробовать Скалу или Немерле (а то и прост C#)? Глядишь окажется, что по производительности труда вы приблизитесь к Питону, а по эффективности останетесь возле С++.

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

VD>Это сотрясение воздуха. Для волнение нетривиальная работы нужно 90% команд процессора. И их "косвенное" выполнение и есть интерпретация. Кроме косвенности есть еще сужение системы типов, использование проверок и т.п. Все в месте и замедляет код. Если бы это было не так, то на можно было бы увидеть тесты демонстрирующие отсутствие разницы в скорости. А по факту пока что форт нигде где требуется производительность не применяется. Насколько мне известно в основном его применяют там где требуется очень компактная и переносимая ВМ. О Питоне даже говорить не приходится. Тормозом был, тормозом и остнется.

Форт в свое время был быстрее си. Это сейчас компиляторы си эволюционировали, тогда они с ним тягаться не могли.

FR>>не очень любят такую схему, ну и плюс оверхед от стека вместо регистров. Но все-равно вполне сопоставимо с си.

VD>Пруфлинк, плиз.

Я уже тебе объяснял что форт для меня только теплые воспоминания, когда я на нем программировал интернет отсутствовал.

VD>А кто-то говорит о принципиальной разнице? Если есть джит который компилирует 100% кода, то это, несомненно, компилятор. Ну, а то что от него нет никакого толко обесловлено тем, что он вынужден вставлять куски интерпретатора в генерируемый код (в виду динамической природы языка), ну, и другой оверхэд (вроде использования числе неограниченной точности) тоже никто не отменял.

Ну так значит твое (как и другие) разделения интерпретаторов — компиляторов бестолковы.

VD>Да ничего ты не демонстрируешь. Ты свои абсурдные рассказы уже почитай 10 лет рассказываешь и никого не убедил. Насколько я понимаю при всем восхищении Поитоном работаешь ты на С++ или чем-то вроде того. Так почему ты свое начальство то не переубедил перейти на "компилируемый Питон"?

Потому что С++ лучший из доступных инструментов для решения наших задач в наших условиях.

VD>Может пора попробовать Скалу или Немерле (а то и прост C#)? Глядишь окажется, что по производительности труда вы приблизитесь к Питону, а по эффективности останетесь возле С++.

Спасибо, я бы предпочел F# или OCaml, но к сожалению они непригодны для моих задач.

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

L>В посте, на который я отвечал, не упоминались макросы, но было про VB6 и automation.

А какой смысл писать внешний код на отдельном VB6 когда он встроен в сам Ворд? Естественно под VB6 понимались макросы.

L>Я решил, что работа с вордовым документом велась из VB. Я тебя неправильно понял. Возражение снимается с повестки.

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

Конечно дело не в том, что C не умеет код генерировать. Просто для наших нужд АПИ ворда просто плохо подходит. У него нет возможности взять и прочесть внутреннюю структуру документа. Приходится читать или посимвольно, что в ворде работает ну очень медленно, или пользоваться высокоурожайными операциям вроде поиска и замены. Они работают быстрее, но их нужно выполнять намного больше чем если бы можно было прочесть структуру документа. В итоге я выбрал лобовое решение. Отказаться от использования ворда вовсе. В макросах теперь просто производится запись содержимого файла во временный MXL-файл (в формате Word XML), а потом вся работа ведется путем чтения этого файла и ручной его обработки.

Решение работает не просто быстрее, а несоизмеримо быстрее. Визуально на моем ноуте статьи обрабатываются молниеносно. Нажимаешь кнопку трансформации, и сразу же видишь как в роузере открывается HTML-предпросмотр. А вдеь при этом происходит:
1. Создание нового (невидимого) документа ворда.
2. Копирование содержимого старого документа в новый файл.
3. Принятие всех ревижонов.
4. Запись файла в формате ХМЛ (все эти пункцты — это 8 строк макросов, т.е. VB).
5. (отсюда работает управляемый код) Чтение файла через XLinq.
6. Преобразование XLinq в немерловый вариант Tag (его описание можно увидеть здесь). Кстати, он полностью неизменяемый, т.е. функциональный.
7. Несколько трансформаций (если интересно, ищи функцию Transform в файле RsdnMl.n) полученного дерева (из рекурсивного варианта Tag). Трансформации дерева даже не оптимизируются, так что каждый раз гнерируются новые копии дерева.
8. Производится парсинг таблицы метатрибутов (этого вообще не было в первой версии шаблона). Код парсинга можно увидеть в файле MetadataPersing.n. Код так же не оптимизировался и лепился, что называется в лоб. В нем кроме всего применяются функции высшего порядка которые вместе с разметкой лежат в шэш-таблицах. Можно сказать, небольшой интерпретатор DSL-я.
9. С помощью XLinq Формируется и записывается на диск XML-файл в формате RSDN ML. Мелочи вроде формирования заголовков статьи я просто пропускаю...
10. Файл сформированный на шаге 9 загружается в XslCompiledTransform который использует сборку полученную путем прекомпиляции XSL-файла в днтент-сборку с помощью утилиты xsltc.exe. Эта утилита генерирует управляему сборку содержащую тип XSL-транслятор.
11. Полученный текст помещается в шаблон HTML-файла и записывается на диск.
12. Файл отображается в броузере ассоциированном с расширением HTML с помощью Diagnostics.Process.Start(outFilePath).
13. Список ошибок возвращается в макрос. Причем я еще думаю, что видимо выброшу код макроса занимающийся отображением ошибок и замению его на ВинФормсовый, так как работа с формами в ворде примитивнейшая. Уже пришлось использовать ВыньАПИ.

И все это выполняется быстрее чем успеваешь выдохнуть.

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

FR>Форт в свое время был быстрее си. Это сейчас компиляторы си эволюционировали, тогда они с ним тягаться не могли.

Пруфлинк в студию.

FR>Я уже тебе объяснял что форт для меня только теплые воспоминания, когда я на нем программировал интернет отсутствовал.

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

FR>Ну так значит твое (как и другие) разделения интерпретаторов — компиляторов бестолковы.

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

VD>>Да ничего ты не демонстрируешь. Ты свои абсурдные рассказы уже почитай 10 лет рассказываешь и никого не убедил. Насколько я понимаю при всем восхищении Поитоном работаешь ты на С++ или чем-то вроде того. Так почему ты свое начальство то не переубедил перейти на "компилируемый Питон"?

FR>Потому что С++ лучший из доступных инструментов для решения наших задач в наших условиях.

Запамятовал твои задачи. Не напомнишь?
И еще... ты все же ответь, почему не Питон то?

VD>>Может пора попробовать Скалу или Немерле (а то и прост C#)? Глядишь окажется, что по производительности труда вы приблизитесь к Питону, а по эффективности останетесь возле С++.

FR>Спасибо, я бы предпочел F# или OCaml, но к сожалению они непригодны для моих задач.

Ну, ты всегда выбираешь весьма странные, на мой взгляд, решения. К этому я уже привык. Но все же я не пойму почему все же не Питон? Да и почему не OCaml? F# хотя бы по соображениям платформы можно отбросить. Но OCaml то чем не угодил?

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

FR>>Форт в свое время был быстрее си. Это сейчас компиляторы си эволюционировали, тогда они с ним тягаться не могли.

VD>Пруфлинк в студию.

Некогда гуглить, тут фортеры точно водятся думаю подкинут.

FR>>Ну так значит твое (как и другие) разделения интерпретаторов — компиляторов бестолковы.

VD>Это еще почему? Оно очевидно и очевидно, что даже от плохой компиляции есть выигрыш в скорости.

Потому-что толку от него все-равно никакого.

FR>>Потому что С++ лучший из доступных инструментов для решения наших задач в наших условиях.

VD>Запамятовал твои задачи. Не напомнишь?

Утилиты системные.

VD>И еще... ты все же ответь, почему не Питон то?

Потому что windows написан на Си и для глубокого с ним взаимодействия хорош именно Си/C++.

FR>>Спасибо, я бы предпочел F# или OCaml, но к сожалению они непригодны для моих задач.

VD>Ну, ты всегда выбираешь весьма странные, на мой взгляд, решения. К этому я уже привык. Но все же я не пойму почему все же не Питон? Да и почему не OCaml? F# хотя бы по соображениям платформы можно отбросить. Но OCaml то чем не угодил?

Выше, тяжеловато на OCaml и хук поставить и перехват API функций делать и писать используя только Native API.

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


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

VD>Провести грань тут не могут только псевдо-философы.
VD>На практике грань очевидна.

Угу, для многих языков грань очевидна, ты это имел ввиду под своей "практикой"?

А на моей практике нихрена не очевидна, из-за того же Форта. Например, есть компиляторы форта, берем во внимание то, что эти компиляторы Форта построены как интерпретаторы, т.е. являются интерпретаторами. Так вот проблема не в том, что сам компилятор работает по интерпретирующей схеме (ибо это не принципиально), а в том, что код целевой программы практически всегда участвует в работе компилятора, я имею ввиду определяющие и immediate слова Форта. Получается, что сам компилятор Форта состоит из некоей "базы" + часть кода целевой программы (тут напрашивается аналогия с Nemerle). Но если в случае Nemerle все "расширения" компилятора можно откомпилировать заранее, и считать их "внешними" по отношению к целевому коду, и не портящим впечатление от твоей практики, то в Форте это все замешано в кучу, т.е. идет определение immediate слова и тут же за ним его использование.

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

Мне серьезно лень спорить дальше, ибо тут действительно все очевидно, хоть и не так как тебе. Но справедливости ради стоит напомнить про Пролог, вернее, про принцип его работы, даже если мы имеем дело с его "компилирующей" версией. Так вот эта версия выполняет довольно много вычислений во время компиляции (обычно интерпретирует весь исходник), а что не вычислила полностью, или сложность превысила чего-то там, или символ объявлен как библиотечный, то идет в результат практически в первозданном виде. И хоть потом внешний интерпретатор пролога не требуется, и все очень даже нативное, и даже в одном экзешнике, но все-равно ядро остается именно VM, которую принципиально никаким процессором с никакой системой команд не заменишь, ибо эта VM работает не по коду, а по данным. И тут твои попытки несерьезного рассуждения об "принципиальном" отличии байт-кода от нативного снова уходят в ту самую псевдофилософию, на которую, как мы видим, Пролог ложил с прибором.
Ибо в контексте компилятор vs. интерпретатор отличий м/у байт-кодом и нативным уж точно нет.


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

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


VD>И когда кто-то говорит об интерпретаторе, то подразумевает, что рантайм языка не генерирует машинный код ни на какой стадии.

Опять мимо.

Давай так, твоя формулировка сообщением выше была некорректна, и разводить тут дальше бессмысленно, а то примерами закидают.
ИМХО, отличие интерпретатора от компилятора на сегодня лишь в том, что интерпретатору можно на вход подать исходный код, и он его тут же выполняет, а компилятор лишь преобразует его для выполнения "на потом". Вот это лишь существенно и позволит не запутаться, а не то, преобразует ли интерпретатор исходник в байт-код или нативный перед непосредственным исполнением. Так же как не важно в какой код преобразует компилятор — в нативный или байт-код.

Почему я не дал такое определение сразу? Из-за лени, ибо даже в этом определении стоит оговориться. Например, есть программа на том же Форте (угу, это он, родной, всю картинку портит и умы смущает), так вот, если последней строкой программы будет какое-нить " Filename.exe" SAVEPROG, то это вроде как компиляция, а если в этой же строке будет имя стартового слова — то уже интерпретация... Небольшое различие, прямо скажем.

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

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

FR>>Форт в свое время был быстрее си. Это сейчас компиляторы си эволюционировали, тогда они с ним тягаться не могли.

VD>Пруфлинк в студию.

Я тоже подписываюсь, и мне для моих тестов никто был не нужен, да и интернета тогда у нас еще не было.
Принцип быстрой работы Форта в том, что для его слов не требуется пролог-эпилог, какой требуется для ф-ий высокоуровневых языков, и который прилично тормозил программы в свое время. (Это сейчас многое инлайнится). Далее, перед вызовом каждой процедуры ЯВУ нужно запихать все операнды в стек, в отличие от Форта, программы на котором писались таким образом, чтобы состояние стека на выходе одного слова было требуемым состоянием для входа следующего. У меня разница до 2-х раз в пользу Форта доходила.

Да, на современных процах с переименованием регистров и out of order выполнением это отличие практически не влияет на быстродействие, но это из-за заточки процов на те самые классические ЯВУ. Если заточить под Форт, то это будет гладкое data-flow практически не требующее доп. оптимизации на уровне проца, т.е. эти же ресурсы транзисторов кристалла могли бы быть применены куда как более полезно, например под дополнительные АЛУ и дополнительные аппаратные треды.


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

Мы же о языках беседуем. Так вот, Форт — такой же равноправный язык.

[доказательства того, с чем я не спорил (потому что я с вами вообще не спорил) и опровержения того, чего я не утверждал (например, "на 200%") пропущены]

VD>Откровенно говоря у меня совсем нет желания агитировать за советскую власть.

[два абзаца неагитации пропущены]

VD>Это рассказ конечно не доказывает, что нэйтив-код медленнее управляемого. Но хорошо демонстрирует, что скорость у управляемых решений очень высокая [...]

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

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

В начале было слово. И на него есть ссылка.

Именно по этому код написанный на нем [Nemerle] по скорости мало отличается от кода написанного на С.

Потом вы уточнили, что "мало отличается" — это

Отрыв в несколько процентов или даже в два раза

.

Это не вопрос агитации или доказательства кто/что уместнее в каком-то проекте/для каких-то задач. Тут либо есть бенчмарки, где Nemerle/C#/etc на несколько процентов, или, хотя бы в два раза отличается от аналогичного кода на Си, либо этих примеров нет и тогда ваш изначальный тезис (о том, что код на Nemerle по скорости мало отличается) остаётся недоказанным.

Речь идёт исключительно об одной вещи — отличается ли скорость X от Y на D процентов или нет.

P.S.: ещё раз, на всякий случай. Я правда, искренне понимаю, что .NET достаточно быстрый. Но речь не о "заметной на глаз разнице", а о конкретных числах.

Здравствуйте, Temoto, Вы писали:
T>Я уже писал, что понимаю, ради чего типобезопасные рантаймы хавают проц
Хм... а я вот не понимаю. Если под типобезопасностью понимать мощную статическую типизацию, то на то она и статическая, чтобы в рантайме ничего не хавать.

T>>Я уже писал, что понимаю, ради чего типобезопасные рантаймы хавают проц
MC>Хм... а я вот не понимаю. Если под типобезопасностью понимать мощную статическую типизацию, то на то она и статическая, чтобы в рантайме ничего не хавать.

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

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

FR>Утилиты системные.

А конкретнее? Не уж то современные ОС нуждаются в утилитах от сторонних производителей?

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


FR>>Утилиты системные.

VD>А конкретнее? Не уж то современные ОС нуждаются в утилитах от сторонних производителей?

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

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

T>В начале было слово. И на него есть ссылка.

Именно по этому код написанный на нем [Nemerle] по скорости мало отличается от кода написанного на С.

T>Потом вы уточнили, что "мало отличается" — это

Отрыв в несколько процентов или даже в два раза

.

Где-то и превосходит. Особенно старые или фиговые компиляторы вроде борлондовских.

T>Это не вопрос агитации или доказательства кто/что уместнее в каком-то проекте/для каких-то задач. Тут либо есть бенчмарки, где Nemerle/C#/etc на несколько процентов, или, хотя бы в два раза отличается от аналогичного кода на Си, либо этих примеров нет и тогда ваш изначальный тезис (о том, что код на Nemerle по скорости мало отличается) остаётся недоказанным.

Бенчмарки есть. Зайти в раздел статьей и найди статьи под названием "Кто сегодня самый шустрый". Только бэнчмарки есть бэнчмарки. Они вообще мало что показывают, так как на любой выигрышный бэнчмарк всегда можно сделать бэнчмарк с обратным результатом (потому как есть масса нюансов по разному реализованных).

T>Речь идёт исключительно об одной вещи — отличается ли скорость X от Y на D процентов или нет.

А такого вообще не существует. Если разница в скорости очевидна, как например, в случае Питона и Руби, то можно о чем-то говорить. Хотя тоже тяжело, так как за счет нэйтив-библиотек и на этих языках можно создать бэнчмарки которые демонстрируют преимущества добра над разумом.

В среднем, хорошо написанный дотнет-код (а он пишется не сравнимо проще чем хороший код на С) примерно соответствует аналогичной программе написанной на С/С++. Причем чем более сложная и объемная задача решается, тем меньше разница, так как преимущества С выливаются исключительно в возможности низкоуровневой оптимизации, а на больших объемах не до оптимизаций, там намного важнее удержать абстракцию на приемлемом уровне.

T>P.S.: ещё раз, на всякий случай. Я правда, искренне понимаю, что .NET достаточно быстрый. Но речь не о "заметной на глаз разнице", а о конкретных числах.

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

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

FR>OC не нуждаются, пользователям почему-то нужно.
FR>Конкретнее дефрагментаторы, утилиты работы с реестром, твикеры, разные тонкие настройки и т. п.

А, ясно. Я это называю посой (не обижайся, плиз).
В прципе конечно тоже рынок. Только такой сойт без проблем может писать и на том же дотнете, если ОС — это Виндовс. Ну, код который должен в режиме ядра работать, конечно нужно на С писать. А все остальное — это бессмысленная трата времени.