Комментарии 25
Имхо, C++ и CLR вещи не совместимые. Если CLR — то лучше уж C#, а если С++ — то никакого CLR, так будет лучше.
В том случае, когда у вас много полезного и питательного legacy-с++-кода (например, в GIS-приложения полно счас), без CLR C++ никуда — компилятор в самом деле выполняет большую и полезную работу о создании thunk-ов и wrapperoв, чтобы безболезненно прыгать между двумя мирами — управляемым и неуправляемым.
Кстати, благодаря этому Quake портировали на CLR за несколько дней.
Кстати, благодаря этому Quake портировали на CLR за несколько дней.
Я как бы к тому, что с CLR теряется одна из прелестей С++ — скорость, и приобретается ненужная гадость в виде кучи размытых ключевых слов only-microsoft, затачиваясь автоматически на .Net, что сворачивает понятие «универсальности» для С++ и выводит новый подвид Visual C++.
Единственная причина, которая мне хотя как-то понятна — это портирование С++ приложений на CLR, вот только зачем? GUI с Win32/MFC так просто не переносятся на WinForms, а портировать отлично работающий движок с legacy C++ на CLR, что бы получить сомнительные выгоды (какие?) и явную потерю в скорости — зачем?
Не вижу смысла в портировании Quake на CLR, вот правда, Кармак вроде и так качественно и достаточно кросплатформенно писал. Разве что «ради понта».
Единственная причина, которая мне хотя как-то понятна — это портирование С++ приложений на CLR, вот только зачем? GUI с Win32/MFC так просто не переносятся на WinForms, а портировать отлично работающий движок с legacy C++ на CLR, что бы получить сомнительные выгоды (какие?) и явную потерю в скорости — зачем?
Не вижу смысла в портировании Quake на CLR, вот правда, Кармак вроде и так качественно и достаточно кросплатформенно писал. Разве что «ради понта».
Скорость критична не всегда, а вот возможность работать с native-кодом чаще всего имеет большую ценность.
Сомнительно очень и очень. Образно говоря, вы хотите «и рыбку съесть, и на… сесть». Вам хочется удобства в работе с ОСью и GUI, но в то же время вы хотите native-код, зачем? В этом случае вы не получите валидной сборки (assembly), а это вряд ли приемлемо для серьезного софта. К тому же, если вы пользуете native-код, то очень сомнительно использование CLR, так как вы уже потеряли совместимость и переносимость, гарантированную .Net платформой, из-за native-кода. Следовательно, нет смысла либо в CLR, либо в native-коде. Опять же, тот же STL и Boost ничуть не хуже и переносимее, чем .Net возможности.
Чаще всего native-код применяют тогда, когда не знают, как это сделать в .Net, по привычке. А зачем лично вам native-код в приложениях?
Чаще всего native-код применяют тогда, когда не знают, как это сделать в .Net, по привычке. А зачем лично вам native-код в приложениях?
>>Чаще всего native-код применяют тогда, когда не знают, как это сделать в .Net, по привычке
Неправда ваша. Чаще всего нативный код применяют, когда он уже есть, и переписывать его на управляемый нецелесообразно/нет возможности/желания/ресурсов. Ниже отписался по этому поводу
Неправда ваша. Чаще всего нативный код применяют, когда он уже есть, и переписывать его на управляемый нецелесообразно/нет возможности/желания/ресурсов. Ниже отписался по этому поводу
Ну, я вообще сейчас пишу shell extension, там идет связка С++ как проставка и C# как сервер. И manaded C++ не применяю только из-за того, что использование .NET при разработке shell extension настоятельно не рекомендуется Microsoft.
А вообще для работы с COM, который не поддерживает спецификации Automation и специфическими dll лучше C++/CLI ничего не найдешь.
А вообще для работы с COM, который не поддерживает спецификации Automation и специфическими dll лучше C++/CLI ничего не найдешь.
Предназначение не в портировании кода, нет — предназначение его в том, чтобы быть glue-code между управляемым кодом и нативным (тем же COMом) — потому что в большом сложном приложении, использующем старый неуправляемый код, рукописного интеропа не оберешься, и вся логика программы пронизана деталями взаимодействия с native.
Я не понял только, почему там скорость теряется.Никто не заставляет использовать управляемые фичи везде. CLR c++ поддерживает в программе и код на чистом с++, со всеми его бенефитами типа ручного управления памятью. Там, где в коде нет обращения к CLR, все работает точно так, как и в старом добром с++, никаких изменений.
Я не понял только, почему там скорость теряется.Никто не заставляет использовать управляемые фичи везде. CLR c++ поддерживает в программе и код на чистом с++, со всеми его бенефитами типа ручного управления памятью. Там, где в коде нет обращения к CLR, все работает точно так, как и в старом добром с++, никаких изменений.
На эту тему есть куча статей в инете. Да и просто попробуйте скомпилировать и посмотреть. В любом случае ваш native-код завёрнут в CLR обёртку, а уж потом только эта обёртка вызывает реальный код. А уж при постоянно переключении туда-сюда вы явно получаете тормоза. Кроме того, любая платформа априори медленнее, чем чистый код, то есть ваша CLR часть будет чутка медленнее, даже если native-часть будет «такая же» в процессе работы.
Опять же, нет ответа на вопрос «зачем это нужно?». Вы описали как это применять («предназначение его в том, чтобы быть glue-code между управляемым кодом и нативным»), но не дали ответа на вопрос «а зачем это нужно?»
Опять же, нет ответа на вопрос «зачем это нужно?». Вы описали как это применять («предназначение его в том, чтобы быть glue-code между управляемым кодом и нативным»), но не дали ответа на вопрос «а зачем это нужно?»
>>На эту тему есть куча статей в инете
Я вам советую читать MSDN и проверять на практике. То, что вы пишете, почти неправда.
>> native-код завёрнут в CLR обёртку, а уж потом только эта обёртка вызывает реальный код
В обертку завернут (и вызывается из нее, соответственно) только тот код, который является шлюзом CLR — native. Внутри native кода никаких оберток нет.
>>А уж при постоянно переключении туда-сюда вы явно получаете тормоза
Конечно. Но это не зависит именно от CLR с++, это природа CLR в целом.
Захотели сэкономить на разработке и юзать из CLR готовый native код — извольте заплатить. Другое дело, что затраты на маршаллинг/вызов через обертки даже профайлером не улавливаются, так что тут можно сказать, что затраты на переключение контекста в теории есть, а на практике их незаметно.
>>Кроме того, любая платформа априори медленнее, чем чистый код
Это уже философия, я на нее не будут подробно отвечать. Замечу только, что native с++ — это тоже своего рода платформа над чистым оптимизированным машинным кодом, поэтому он тоже будет медленнее, причем тут замедление видно невооруженным глазом, в отличие от.
>>нет ответа на вопрос «зачем это нужно?»
Попробуйте прочесть еще раз мои предыдущие комментарии, там это есть. Я подскажу — искать надо по мысли «много существующего native-кода, который нет смысла переписывать, а юзать хочется»
Я вам советую читать MSDN и проверять на практике. То, что вы пишете, почти неправда.
>> native-код завёрнут в CLR обёртку, а уж потом только эта обёртка вызывает реальный код
В обертку завернут (и вызывается из нее, соответственно) только тот код, который является шлюзом CLR — native. Внутри native кода никаких оберток нет.
>>А уж при постоянно переключении туда-сюда вы явно получаете тормоза
Конечно. Но это не зависит именно от CLR с++, это природа CLR в целом.
Захотели сэкономить на разработке и юзать из CLR готовый native код — извольте заплатить. Другое дело, что затраты на маршаллинг/вызов через обертки даже профайлером не улавливаются, так что тут можно сказать, что затраты на переключение контекста в теории есть, а на практике их незаметно.
>>Кроме того, любая платформа априори медленнее, чем чистый код
Это уже философия, я на нее не будут подробно отвечать. Замечу только, что native с++ — это тоже своего рода платформа над чистым оптимизированным машинным кодом, поэтому он тоже будет медленнее, причем тут замедление видно невооруженным глазом, в отличие от.
>>нет ответа на вопрос «зачем это нужно?»
Попробуйте прочесть еще раз мои предыдущие комментарии, там это есть. Я подскажу — искать надо по мысли «много существующего native-кода, который нет смысла переписывать, а юзать хочется»
Есть большой проект на C++, гуи на MFC. (Буэ, как вспомню, передергивает! Извините, отвлекся.) На C# переписать такое в разумные сроки нереально, зато с помощью C++/CLR в качестве клея ето можно делать кусками, не тратя кучу времени на склеивающий код. Граница между native и CLR будет максимально плавной и приятной.
C++/CLR это реальный выход в таких случаях, экономящий кучу времени.
Кстати утверждение «любая платформа априори медленнее, чем чистый код» вообще говоря неверно, хотя на практике «в среднем» это так.
C++/CLR это реальный выход в таких случаях, экономящий кучу времени.
Кстати утверждение «любая платформа априори медленнее, чем чистый код» вообще говоря неверно, хотя на практике «в среднем» это так.
2sse
Вашу мысль я понял, окей. Хотелось бы адекватного примера, но не обязательно, в целом это не важно :)
Читать MSDN в этом случае бессмысленно, он необъективен. На хабре были замеры, если не ошибаюсь. Да и в инете много их.
> Захотели сэкономить на разработке и юзать из CLR готовый native код — извольте заплатить
Я не хотел, я то как раз против.
> что затраты на переключение контекста в теории есть, а на практике их незаметно.
Смотря в каком приложении.
2lrrr
> «любая платформа априори медленнее, чем чистый код» вообще говоря неверно
Чем же неверно? Любая прослойка — это уже потеря скорости.
Вашу мысль я понял, окей. Хотелось бы адекватного примера, но не обязательно, в целом это не важно :)
Читать MSDN в этом случае бессмысленно, он необъективен. На хабре были замеры, если не ошибаюсь. Да и в инете много их.
> Захотели сэкономить на разработке и юзать из CLR готовый native код — извольте заплатить
Я не хотел, я то как раз против.
> что затраты на переключение контекста в теории есть, а на практике их незаметно.
Смотря в каком приложении.
2lrrr
> «любая платформа априори медленнее, чем чистый код» вообще говоря неверно
Чем же неверно? Любая прослойка — это уже потеря скорости.
>>На хабре были замеры, если не ошибаюсь
Не, таких не было. был замер интеропа, но толком и не определились — кажется, осталось в пределах погрешности.
Адекватный пример — ок, их есть у меня: фирма, в которой я работал, занималась прикладной топо- и карто-графией. Соответственно, с 1996 года, с ее основания, все писалось на MVS native с++ — огромные сложные уникальные алгоритмы, свой формат компрессии данных, которым, кстати, пользуются счас Nav**q и Tele****s — короче, очень много отлаженных и «вылизанных» алгоритмов, писанных в native.
После того, как появился заказчик, который захотел .NET и особенно .NET CompactFramework (для наладонников), при помощи CLR c++ удалось поюзать большинство готовых lib и dll файлы, а кое-что (немного) пересобрать и тоже пустить в дело.
2lrrr: не ведитесь на холивары :)
Не, таких не было. был замер интеропа, но толком и не определились — кажется, осталось в пределах погрешности.
Адекватный пример — ок, их есть у меня: фирма, в которой я работал, занималась прикладной топо- и карто-графией. Соответственно, с 1996 года, с ее основания, все писалось на MVS native с++ — огромные сложные уникальные алгоритмы, свой формат компрессии данных, которым, кстати, пользуются счас Nav**q и Tele****s — короче, очень много отлаженных и «вылизанных» алгоритмов, писанных в native.
После того, как появился заказчик, который захотел .NET и особенно .NET CompactFramework (для наладонников), при помощи CLR c++ удалось поюзать большинство готовых lib и dll файлы, а кое-что (немного) пересобрать и тоже пустить в дело.
2lrrr: не ведитесь на холивары :)
Спасибо за пример. Видимо я просто не сталкивался в жизни с адекватными примерами.
> 2lrrr: не ведитесь на холивары :)
Да, наверное не стоит. Извините.
> 2lrrr: не ведитесь на холивары :)
Да, наверное не стоит. Извините.
Кстати, самое ололо тут в том что мой жызненный пример тоже почерпнут из жизни одного очень крупного GIS-related приложения под PDA :)
НЛО прилетело и опубликовало эту надпись здесь
JIT может генерировать более эффективный код чем компилятор C++, т.к. у него больше информации — например, он может кое-где инлайнить виртуальные вызовы, так как знает реальный тип объекта во время выполнения.
Ссылки по теме
shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=gpp&lang2=java&box=1
arstechnica.com/reviews/1q00/dynamo/dynamo-1.html
Ссылки по теме
shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=gpp&lang2=java&box=1
arstechnica.com/reviews/1q00/dynamo/dynamo-1.html
Извините, но синтетические тесты абсолютно ничего не говорят. Пожалуй, стоит закрыть тему. Ведь ни одна контора не пишет реальный софт на двух языках сразу, дабы мы могли сравнить, так? Следовательно реальных жизненных примеров софта нет и не будет, потому все эти споры скатываются до «если бы да кабы» либо до синтетики. А синтетика вещь субъективная. Хотя, вот выше говорил, что кваку портировали на .Net, вот бы кто сравнил с С++ вариантом, было бы реально интересно.
Кстати, в контексте нашего разговора выше об native и CLR способность JIT «иногда» генерировать «лучший» код уже неважна, как минимум в native части, а в CLR части она и не нужна, так как все алгоритмы полезные именно в native, опять же в заданном выше контексте портирования.
И вашу фразу можно удачно переписать так:
Кстати утверждение «любая платформа априори медленнее, чем чистый код» вообще говоря верно, хотя на практике «иногда» это не так.
Вот это будет правдиво и объективно.
Кстати, в контексте нашего разговора выше об native и CLR способность JIT «иногда» генерировать «лучший» код уже неважна, как минимум в native части, а в CLR части она и не нужна, так как все алгоритмы полезные именно в native, опять же в заданном выше контексте портирования.
И вашу фразу можно удачно переписать так:
Кстати утверждение «любая платформа априори медленнее, чем чистый код» вообще говоря верно, хотя на практике «иногда» это не так.
Вот это будет правдиво и объективно.
Я, только сегодня открыл для себя CLR+Visual Studio — создал проект… И что я увидел? )))
В общем меня сильно испугала заточка под мелкософт… Поэтому для своего проекта я выбрал — кросс платформенное Qt… С наиболее облегчённой логикой…
В общем меня сильно испугала заточка под мелкософт… Поэтому для своего проекта я выбрал — кросс платформенное Qt… С наиболее облегчённой логикой…
Вопрос автору, вы производите предварительную генерацию нативного кода(Ngen) на машине разработчика или на конечной машине? Делать это на девелоперской машине нет смысла т.к. Ngen затачивается под аппаратную конфигурацию данной машины.
Рекомендации по извлечению перфоманса из NGen
Рекомендации по извлечению перфоманса из NGen
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CLR и C++