H>>На intuit.ru курс С# на отлично до сих пор прошел 1 человек. Вот вам и бейсик. Там 25 объемистых лекций.
S>Я не про то что он легкий/сложный. Я про то что такиеже тормоза.
Так, для справки: Тормоза — это такие люди, которые до сих пор думают, что управляемые программы всегда работают медленнее неуправляемых. Как правило, в качестве примера тормозами приводятся (если вообще приводятся) bit-crunching алгоритмы на С++; при этом типичные задачи, решаемые таким тормозом, никакого отношения к математике не имеют, а упираются в скорость сети/файловой системы/видеоплаты. А еще чаще в качестве аргумента приводятся ссылки на обсуждения в ФИДО, датируемые девяностыми годами прошлого века.

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

H>>>На intuit.ru курс С# на отлично до сих пор прошел 1 человек. Вот вам и бейсик. Там 25 объемистых лекций.
S>>Я не про то что он легкий/сложный. Я про то что такиеже тормоза.
S>Так, для справки: Тормоза — это такие люди, которые до сих пор думают, что управляемые программы всегда работают медленнее неуправляемых.
Смешно.

S>Как правило, в качестве примера тормозами приводятся (если вообще приводятся) bit-crunching алгоритмы на С++; при этом типичные задачи, решаемые таким тормозом, никакого отношения к математике не имеют, а упираются в скорость сети/файловой системы/видеоплаты. А еще чаще в качестве аргумента приводятся ссылки на обсуждения в ФИДО, датируемые девяностыми годами прошлого века.
Я не верю что код в обертке управляемого кода будет работать быстрее просто кода. Точка.

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

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

H>>>>На intuit.ru курс С# на отлично до сих пор прошел 1 человек. Вот вам и бейсик. Там 25 объемистых лекций.
S>>>Я не про то что он легкий/сложный. Я про то что такиеже тормоза.
S>>Так, для справки: Тормоза — это такие люди, которые до сих пор думают, что управляемые программы всегда работают медленнее неуправляемых.
S>Смешно.

S>>Как правило, в качестве примера тормозами приводятся (если вообще приводятся) bit-crunching алгоритмы на С++; при этом типичные задачи, решаемые таким тормозом, никакого отношения к математике не имеют, а упираются в скорость сети/файловой системы/видеоплаты. А еще чаще в качестве аргумента приводятся ссылки на обсуждения в ФИДО, датируемые девяностыми годами прошлого века.
S>Я не верю что код в обертке управляемого кода будет работать быстрее просто кода. Точка.

А при чём тут верю-неверю? Проверь.

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

_>А при чём тут верю-неверю? Проверь.

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

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

S>>Как правило, в качестве примера тормозами приводятся (если вообще приводятся) bit-crunching алгоритмы на С++; при этом типичные задачи, решаемые таким тормозом, никакого отношения к математике не имеют, а упираются в скорость сети/файловой системы/видеоплаты. А еще чаще в качестве аргумента приводятся ссылки на обсуждения в ФИДО, датируемые девяностыми годами прошлого века.
S>Я не верю что код в обертке управляемого кода будет работать быстрее просто кода. Точка.

Так он компилируется один раз при первом вызове нескомпилированного метода.

Здравствуйте, Sheridan, Вы писали:
S>>Как правило, в качестве примера тормозами приводятся (если вообще приводятся) bit-crunching алгоритмы на С++; при этом типичные задачи, решаемые таким тормозом, никакого отношения к математике не имеют, а упираются в скорость сети/файловой системы/видеоплаты. А еще чаще в качестве аргумента приводятся ссылки на обсуждения в ФИДО, датируемые девяностыми годами прошлого века.
S>Я не верю что код в обертке управляемого кода будет работать быстрее просто кода. Точка.
Смешно.
Непонятно, что значит "в обертке": почему ты не сравниваешь просто управляемый код с неуправляемым?
Непонятно, почему ты делаешь смешные заявления на основе какой-то веры. Есть объективная реальность, есть аргументы в пользу того, чтобы неуправляемый код исполнялся быстрее, есть аргументы в пользу обратного. Я так понимаю, ты себе не дал труда изучить ни те ни другие, зато потешить народ заявлениями типа "жирафов быть просто не может".

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

S>>Я не верю что код в обертке управляемого кода будет работать быстрее просто кода. Точка.
S>Смешно.
S>Непонятно, что значит "в обертке": почему ты не сравниваешь просто управляемый код с неуправляемым?
S>Непонятно, почему ты делаешь смешные заявления на основе какой-то веры. Есть объективная реальность, есть аргументы в пользу того, чтобы неуправляемый код исполнялся быстрее, есть аргументы в пользу обратного. Я так понимаю, ты себе не дал труда изучить ни те ни другие, зато потешить народ заявлениями типа "жирафов быть просто не может".

Хорошо. Я согласен рассмотреть противоположную точку зрения. Мне это даже интересно.
Объясни пожалуйста порусски, обычным языком (Только не статьи, пожалуйста... Мне надоедает читать воду и философские рассуждения.), чем хорош управляемый код? Нет не так... Чем хорош в принципе понятно... Безопасность и все такое прочее... о! Как работает приложение с управляемым кодом? Что происходит при:
1. Запуске.
2. Вызове ф-ии из управляемой секции.
3. Вызове ф-ии из неуправляемой секции.
4.1 Закрытии приложения.
4.2 Снятии приложения.
6. Может быть чтото еще.

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

S>Хорошо. Я согласен рассмотреть противоположную точку зрения. Мне это даже интересно.
S>Объясни пожалуйста порусски, обычным языком (Только не статьи, пожалуйста... Мне надоедает читать воду и философские рассуждения.), чем хорош управляемый код? Нет не так... Чем хорош в принципе понятно... Безопасность и все такое прочее... о! Как работает приложение с управляемым кодом? Что происходит при:
S>1. Запуске.
S>2. Вызове ф-ии из управляемой секции.
S>3. Вызове ф-ии из неуправляемой секции.
S>4.1 Закрытии приложения.
S>4.2 Снятии приложения.
S>6. Может быть чтото еще.

Вообще-то, Рихтер обо всем этом очень интересно написал. Лучше его почитать, а не пересказ, это правда интересно, рекомендую

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

D> Вообще-то, Рихтер обо всем этом очень интересно написал. Лучше его почитать, а не пересказ, это правда интересно, рекомендую
За неименеем рихтера... Да и опятьже мне хочется факты. Что. Как. Ибо сколько книг не читал — везде воды дофига. Тотже страуструп и тот тудаже...

Sheridan wrote:
> Что происходит при:
> 1. Запуске.
JITинг кода или взятие готового кода из кэша.

> 2. Вызове ф-ии из управляемой секции.
Все что угодно: от отсутствия вызова из-за inlineing'а до запуска JITа,
компиляции функции и выполнения вызова.

> 3. Вызове ф-ии из неуправляемой секции.
Вот тут плохо все. Оверхед на кросс-вызовы получается больше, чем в
случае вызова неуправляемой фнуции.

> 4.1 Закрытии приложения.
Закрытие приложения. А что обязано происходить?

> 4.2 Снятии приложения.
Снятие приложения.

Как показывает практика, хорошие управляемые среды способны создавать
код, в среднем работающий ненамного медленнее компилированного (20-30%).
В некоторых крайних случаях может быть перевес в разы в любую сторону.

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

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

>> 1. Запуске.
C>JITинг кода или взятие готового кода из кэша.
Ясно.

>> 2. Вызове ф-ии из управляемой секции.
C>Все что угодно: от отсутствия вызова из-за inlineing'а до запуска JITа,
C>компиляции функции и выполнения вызова.
Тоже ясно.

>> 3. Вызове ф-ии из неуправляемой секции.
C>Вот тут плохо все. Оверхед на кросс-вызовы получается больше, чем в
C>случае вызова неуправляемой фнуции.
Это как я понял издержки управляемой среды.

>> 4.1 Закрытии приложения.
C>Закрытие приложения. А что обязано происходить?
Ну не знаю... Какие нибудь телодвижения... Типа чтоть скомпилять опять, куданибудь чтото сохранить...

>> 4.2 Снятии приложения.
C>Снятие приложения.
Ясно.

C>Как показывает практика, хорошие управляемые среды способны создавать
C>код, в среднем работающий ненамного медленнее компилированного (20-30%).
C>В некоторых крайних случаях может быть перевес в разы в любую сторону.

C>Так же практика показывает, что управляемый код в среднем жрет в разы
C>больше памяти (оверхед на GC, ориентированность на куча и т.п.)
Вот это я и имел ввиду.
Какбы повела себя управляемая среда в этом случае

Автор: Sheridan
Дата: 10.05.06

? Прав я буду если скажу что получилось бы не так вкусно как написано?

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

S>Хорошо. Я согласен рассмотреть противоположную точку зрения. Мне это даже интересно.
S>Объясни пожалуйста порусски, обычным языком (Только не статьи, пожалуйста... Мне надоедает читать воду и философские рассуждения.), чем хорош управляемый код? Нет не так... Чем хорош в принципе понятно... Безопасность и все такое прочее... о! Как работает приложение с управляемым кодом? Что происходит при:
S>1. Запуске.
Запускается точка входа. Приложение импортирует соответствующий набор DLL из дотнет фреймворк, и передает ему управление. Фреймворк анализирует метаданные основной сборки, определяет адрес управляемой точки входа и передает ей управление. Если управляемый код не был обработан при помощи NGEN, в этот момент активизируется JIT-компилятор. Он компилирует код точки входа в целевую архитектуру, подправляет указатель в соответствующей таблице и передает управление в свежескомпилированный код.
S>2. Вызове ф-ии из управляемой секции.
Я не очень понимаю, что ты имеешь в виду под "неуправляемой секцией". Если ты имеешь в виду вызов неуправляемого кода, то система формирует специальный переходник — фрагмент кода, занимающийся согласованием конвенций вызова и прочим маршаллингом.
S>3. Вызове ф-ии из неуправляемой секции.
Когда ты отдаешь в неуправляемый код указатель на callbcack, система формирует специальный переходник — фрагмент кода, занимающийся согласованием конвенций вызова и прочим маршаллингом. Фактически в неуправляемый код передается адрес этого переходника, а не управляемой функции.
S>4.1 Закрытии приложения.
Ничего интересного. То же самое, что и в нативном приложении.
S>4.2 Снятии приложения.
Это довольно сложно, в основном из-за всяких спецэффектов при наличии в стеках потоков как управляемого, так и неуправляемого кода. В идеале: во всех потоках бросается соответствующее исключение, выполняются секции catch и finally, после чего см. п. 4.1.
S>6. Может быть чтото еще.
Что-то еще: маршаллинг между управляемым и неуправляемым кодом относительно дорог (относительно вызовов внутри той или иной модели). Это очевидно: сборщик мусора должен быть единственным, кто контролирует управляемые ресурсы. На практике, переходы относительно редки — как правило в стеке вызовов присутствует не более двух переходов, а подавляющее большинство вызовов делается без маршаллинга. Вопросы, связанные со снятием/завершением приложений, можно рассматривать в контексте производительности только в шутку.

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

H>>>На intuit.ru курс С# на отлично до сих пор прошел 1 человек. Вот вам и бейсик. Там 25 объемистых лекций.
S>>Я не про то что он легкий/сложный. Я про то что такиеже тормоза.
S>Так, для справки: Тормоза — это такие люди, которые до сих пор думают, что управляемые программы всегда работают медленнее неуправляемых.
S>Как правило, в качестве примера тормозами приводятся (если вообще приводятся) bit-crunching алгоритмы на С++; при этом типичные задачи, решаемые таким тормозом, никакого отношения к математике не имеют, а упираются в скорость сети/файловой системы/видеоплаты. А еще чаще в качестве аргумента приводятся ссылки на обсуждения в ФИДО, датируемые девяностыми годами прошлого века.

Слишком общее сообщение что бы быть правильным. У C# своя ниша, в которой не только перформанс определяет победителя. Там, где победитель определяется исключительно перформансом алгоритма, у С++ неоспоримое преимущество. Это как раз ниша С++. Так что вывод напрашивается простой.

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

S>Хорошо. Я согласен рассмотреть противоположную точку зрения. Мне это даже интересно.
S>Объясни пожалуйста порусски, обычным языком (Только не статьи, пожалуйста... Мне надоедает читать воду и философские рассуждения.), чем хорош управляемый код? Нет не так... Чем хорош в принципе понятно... Безопасность и все такое прочее... о! Как работает приложение с управляемым кодом? Что происходит при:
S>1. Запуске.
S>2. Вызове ф-ии из управляемой секции.
S>3. Вызове ф-ии из неуправляемой секции.
S>4.1 Закрытии приложения.
S>4.2 Снятии приложения.

Знамо дело работает интероп и GC. Эти штуки являются в разных условиях как преимуществами так и недостатками.
Люди которые считают интероп и GC исключительно преимуществом в равной степени идиоты как и те, что считают интероп и GC исключительно недостатком.

Интероп, GC + куча etc и разделяют экономические ниши для нативного С++ и C# .Net например.

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

[поскипано]

Спасибо.
Давай теперь посмотрим трезво.
1. Сразу оверхед — анализ метаданных, запуск при небходимости JIT'а.
2. Зачемто какието переходники и согласования вместо прямого выполнения кода. Нет, я понимаю — соблюдаются условия защиты системы от кривизны кода, но мы то сравниваем производительность дотнета и нативного кода.
3. И тут согласования...
4.2 Вот это неплохо, неплохо... Я бы даже сказал очень хорошо.
В общем имеет место быть постоянный контроль кода и ресурсов. Господа но на это же дело ресурсы тоже тратятся?
Или я опять неправ, и весь контроль выполняется "бесплатно"?

Я нив коем случае никого не хочю обидеть. Я хочю понять, отчего все ломанулись в дотнет и C# в частности. Если оттого что программировать легче и проще то согласен, там проще, легче. Но конечным пользователям то не легче. Юзерам приходится покупать железо и софт.

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

S>1. Сразу оверхед — анализ метаданных, запуск при небходимости JIT'а.
Это даже не милли это микросекунды. Причем только один раз. Так что это не оверхед.
S>2. Зачемто какието переходники и согласования вместо прямого выполнения кода. Нет, я понимаю — соблюдаются условия защиты системы от кривизны кода, но мы то сравниваем производительность дотнета и нативного кода.
Переходники нужны для работы с неуправляемым кодом. Внутри управляемого кода никаких переходников нет. Все компилируется в банальные call'ы.
S>3. И тут согласования...
Ну а как ты хотел... этоже возьня с неупиравляемым кодом...

S>В общем имеет место быть постоянный контроль кода и ресурсов. Господа но на это же дело ресурсы тоже тратятся?
S>Или я опять неправ, и весь контроль выполняется "бесплатно"?
Практически бесплатно.

S>Я нив коем случае никого не хочю обидеть. Я хочю понять, отчего все ломанулись в дотнет и C# в частности. Если оттого что программировать легче и проще то согласен, там проще, легче. Но конечным пользователям то не легче. Юзерам приходится покупать железо и софт.
Как правило купить железо дешевле чем отлавливать тараканы в С++ном коде.

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

C>Так же практика показывает, что управляемый код в среднем жрет в разы больше памяти (оверхед на GC, ориентированность на куча и т.п.)
В разы?! Ну да в разы он жрет если памяти много, а вот если памяти мало то управляемое приложение очень быстро ужимается в размерах.

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

PE> Слишком общее сообщение что бы быть правильным. У C# своя ниша, в которой не только перформанс определяет победителя. Там, где победитель определяется исключительно перформансом алгоритма, у С++ неоспоримое преимущество. Это как раз ниша С++. Так что вывод напрашивается простой.
Нет это ниша асма...

WolfHound wrote:
> C>Так же практика показывает, что управляемый код в среднем жрет в разы
> больше памяти (оверхед на GC, ориентированность на куча и т.п.)
> В разы?! Ну да в разы он жрет если памяти много, а вот если памяти мало
> то управляемое приложение очень быстро ужимается в размерах.
В разы, в разы. Имел возможность сравнивать.

Во-первых, GC для эффективной работы требует определенный overhead по
объему памяти (процентов 20%-50%). Во-вторых, объекты имеют заголовок,
который занимает размер. В-третьих, ориентированость на кучу —
value-типы используются редко.

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

C>В разы, в разы. Имел возможность сравнивать.
Что за задача?

C>Во-первых, GC для эффективной работы требует определенный overhead по объему памяти (процентов 20%-50%).
Во во проценты, а не разы.

C>Во-вторых, объекты имеют заголовок, который занимает размер.
+8 байт на объект. Не много.

C>В-третьих, ориентированость на кучу — value-типы используются редко.
И правильно. Если оптимизировать не надо то с reference типами проще, а если надо то можно и value типы использовать. Мне они понадобились лишь один раз.(в смысле написать свой value тип, а не использовать всякие там int'ы)