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

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

Согласен. Хотя теоретически (в смысле — с непонятным практическим смыслом) можно держать две версии бинарников: оптимизированную для работы и неоптимизированную — специально для использования с рефлексией. Другое дело, что такой подход ещё больше нагрузит память. Да и время+ресурсы на JIT-компиляцию вырастут.

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

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

K>>>>А про плавающие и косвенные ошибки ты решил скромно умолчать, или просто не в курсе что это такое?
V>>>Это от технологии не зависит.
K>>Чего-чего?

ГВ>Садись, два.

Ну только не тебе это решать
Кто там сильно умный, расскажите мне каким образом в managed code могут появляться косвенные ошибки от прохода по памяти?

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

ГВ>О, чувствуется мастерство: два предположения, и оба — с явным переходом на личности.

Отстань от меня со своей личностью, она меня совершенно не интересует. Утомил уже

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


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

ГВ>Не знаю. Не имея реального представления о процессе внутри самих Adobe, MS или Apple предполагать что-то очень трудно. Могу только монетку подкинуть, так вернее получится.

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

Отличный прогресс.

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

ГВ>>Не знаю. Правда, всего лишь "дважды в месяц" при здоровенной базе исходников — это, считай, ничто. ИМХО, разумеется. И трудно предположить, что эти считанные дыры могут заставить переписать всё на новом языке.
S>Ну вот видите, из "лечится на раз" мы перешли "присутствует в любой достаточно большой базе исходников".

Хм. Я же не говорил, что такие ошибки отсутствуют вообще. И собственно говоря, самого наличия таких дырок никогда и не отрицал.

ГВ>>Не знаю. Не имея реального представления о процессе внутри самих Adobe, MS или Apple предполагать что-то очень трудно. Могу только монетку подкинуть, так вернее получится.
ГВ>>Влияющих факторов может быть очень много: использование стороннего кода, какие-нибудь флуктуации в "давлении сроков" или, скажем, "внезапное" изменение таймингов аппаратуры. Да до хрена всего.
S>Ну вот видите, из "только если не дурить с тестированием", мы получили "очень много влияющих факторов".

Эти факторы как раз и влияют на "дурь" с тестированием.

S>Отличный прогресс.

Скорее — изменение предмета обсуждения.

Я понимаю, что ты хочешь сказать: что не смотря на то, что по моим словам, такие ошибки найти нетрудно — они, тем не менее, есть. Только у нас получится непримиримое противоречие. Ты будешь агитировать за полный переход на managed, читай, увеличивать ресурсы, необходимые конечной программе. Я — за более тщательное тестирование (или compile-time — верификацию) и, соответственно, за сокращение ресурсов, потребляемых конечной программой в эксплуатации. Ошибки могут быть и там, и там. Главная (в контексте топика) разница только в том, куда смещаются энергетические затраты: на разработку или на эксплуатацию. ИМХО, лучше сместить их на разработку.

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

K>>>>>А про плавающие и косвенные ошибки ты решил скромно умолчать, или просто не в курсе что это такое?
V>>>>Это от технологии не зависит.
K>>>Чего-чего?

ГВ>>Садись, два.
K>Ну только не тебе это решать
K>Кто там сильно умный, расскажите мне каким образом в managed code могут появляться косвенные ошибки от прохода по памяти?

А ты не хами попусту и выражайся яснее, тогда и переспрашивать не придётся. Я-то подумал вообще про все такие ошибки (и vdimas, как я понимаю — тоже), а не только про те, которые наведены ошибками работы с памятью.

См. здесь Ключевой момент:

static void Dismantle(int[] arr)
{
    GCHandle gch = GCHandle.Alloc(arr, GCHandleType.Pinned);
    IntPtr ptr = gch.AddrOfPinnedObject();
    const int OFFSET = 8 + 4000;
    Marshal.WriteInt32(ptr, OFFSET, Marshal.ReadInt32(ptr, OFFSET) + 4);
    gch.Free();
}

Кому может понадобиться такой или подобный код за пределами задач интеропа — могу только догадываться, но тем не менее, это "чистый" managed-код, который создаёт условия для той самой загадочной ошибки (чаще всего — AVE). Чистый в том смысле, что он не содержит прямых обращений к исполняемому unmanaged и скомпилирован с запретом unsafe.

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

ГВ>>О, чувствуется мастерство: два предположения, и оба — с явным переходом на личности.
K>Отстань от меня со своей личностью, она меня совершенно не интересует. Утомил уже

А ты прекрати апеллировать к личности и уставать не придётся.

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

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

ГВ>Согласен. Хотя теоретически (в смысле — с непонятным практическим смыслом) можно держать две версии бинарников: оптимизированную для работы и неоптимизированную — специально для использования с рефлексией. Другое дело, что такой подход ещё больше нагрузит память. Да и время+ресурсы на JIT-компиляцию вырастут.

Если рефлексия нам нужна только для получения метаинформации, то без проблем, т.к. метаинформация после JIT никуда не денется, но если эта метаинформация используется для целей динамического доступа к полям, например, даже приватным, вот тут и наступает то ограничение, что конкретное поле оптимизатор не имеет права нивелировать/преобразовать/переместить. Причем, в поле может быть ссылка на другой объект, тоже видимый только локально, если брать классические public/private, и сценарии пользования которого или даже само наличие которого как отдельного объекта в куче могло быть оптимизатором пересмотрено... Но если через динамику/рефлексию "кто-то" может активно вмешиваться в процесс работы, то это вмешательство надо обеспечивать, согласно исходной метаинформации.

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

ГВ>А ты не хами попусту

Немедленно прекрати переходить на личности

ГВ>Кому может понадобиться такой или подобный код за пределами задач интеропа — могу только догадываться, но тем не менее, это "чистый" managed-код, который создаёт условия для той самой загадочной ошибки (чаще всего — AVE).

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

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

K>Ну только не тебе это решать

Дык, ты сам нарисовался в публичном форуме, так что уж терпи.


K>Кто там сильно умный, расскажите мне каким образом в managed code могут появляться косвенные ошибки от прохода по памяти?

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

Насчет всех этих упомянутых эксплоитов... Во первых, чтобы получить контроль над машиной, код должен выполняться с определенными правами, даже нативный. А пока что переписать стек TCP на дотнет не получится, сорри, т.к. сетевые технологии постоянно обгоняют характеристики дотнета. Вот у нас стоит задача выжать всё из 10-гиговой картейки, причем не "бесконечным" медиа-потоками, а сообщениями в сотни байт... ну какой тут нафик дотнет в драйверах и АПИ? Дотнет — это параллельная такая вселенная, далекая от всех этих страшных цифр и прочей головной боли реального мира... Во вторых, доля использование legacy-кода слишком большая, т.е. это еще код не то что до-дотнетных времен, это еще С++ нормального не было и многое писалось на С, в котором обеспечить типобезопасность, достижимую современным С++ невозможно. Например, чего стоило тут обсуждение относительно исправления семантики memcpy для линухов и того, что отвалился флеш-плеер... Это ж с каких годов бага там жила? Наверно, с самых первых вариантов 93-го года. Уже лет 10 никто непосредственно memcpy в логике не юзает. И тем более не создает массивы памяти вручную. Такие вещи если делают, то сугубо в системном коде, где С++ используется как замена С и ассемблеру. В общем, это не характеристика конкретно языка, а точно такая аналогичная "возможность" как в дотнете попортить память через unsafe, либо без вcякого unsafe банально через некорректные параметры при вызове методов классов Marshal, Buffer и т.д. В общем, возможность писать безопасно есть, так же как возможность писать небезопасно, полностью аналогично дотнету, так что от разработчиков всё еще больше зависит, чем от технологий.

Ну и популярные толкаемые вещи, что вот в дотнетной программе если ошибка, то можно пользователя попросить сохранить данные всвязи с ошибкой и аккуратно закрыться... Покажи мне хоть одну такую гламурную программу! Болтовня, короче. Всё что я видел, работает точно так же как нативные приложения, разница только в диалогах сообщения об ошибке, ибо null reference он и в Африке null reference. Отличие лишь в том, что стек трейс виден детальный, т.е. быстрее можно найти ошибку (если она не та самая наведенная )

Ну и справедливости ради, рядом положить PDB для нейтива, тоже всё увидеть можно.

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

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

V>А пока что переписать стек TCP на дотнет не получится, сорри, т.к. сетевые технологии постоянно обгоняют характеристики дотнета. Вот у нас стоит задача выжать всё из 10-гиговой картейки, причем не "бесконечным" медиа-потоками, а сообщениями в сотни байт... ну какой тут нафик дотнет в драйверах и АПИ?
Действительно. В таких задачах, как хорошо известно, рулит Эрланг — практически интерпретатор, полностью управляемый. Дотнет слишком низкоуровневый для таких задач.

V>Ну и справедливости ради, рядом положить PDB для нейтива, тоже всё увидеть можно.

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

ГВ>Хм. Я же не говорил, что такие ошибки отсутствуют вообще. И собственно говоря, самого наличия таких дырок никогда и не отрицал.
Но при этом почему-то считаешь их "мифическими".
Занятная мифическость получается: в компаниях с высокой культурой разработки и значительными инвестициями в отлов и починку этих мифических зверей их извести никак не могут. Наверное, зато, в наколенных поделках самоучек эти зверьки совсем-совсем не встречаются.

ГВ>Эти факторы как раз и влияют на "дурь" с тестированием.
А-а. Ну то есть несмотря на то, что МС уже лет пять как делает "quality-based releases" и отказывается называть заранее даты выхода продуктов, чтобы избежать проблем типа "не успеваем к релизу — давайте скипнем тестирование", и вкладывает чудовищные деньги в тестирование и верификацию своих неуправляемых программ, систематически получает проблемы.
Если у них дурь с тестированием, то остальные, скажем так, вообще никаким QA не занимаются.
Каким же тогда образом мы можем полагаться на надёжность программ на C++?

ГВ>Скорее — изменение предмета обсуждения.

ГВ>Я понимаю, что ты хочешь сказать: что не смотря на то, что по моим словам, такие ошибки найти нетрудно — они, тем не менее, есть. Только у нас получится непримиримое противоречие. Ты будешь агитировать за полный переход на managed, читай, увеличивать ресурсы, необходимые конечной программе.
С чего бы это вдруг? Нет, я буду агитировать за взвешенный подход.
Менеджед вовсе не означает гарантированного увеличения ресурсопотребления. Да, сборка мусора требовательнее к памяти, чем обычное выделение. Это не означает, что нельзя сочетать оба подхода. Более того, в высокопроизводительных серверных приложениях так и делают — выделяют часть памяти "статически". И таки память сейчас значительно менее ресурс, чем даже во времена начала дотнета.
Для роста затрат остальных ресурсов объективных причин нет.

ГВ>Я — за более тщательное тестирование (или compile-time — верификацию) и, соответственно, за сокращение ресурсов, потребляемых конечной программой в эксплуатации. Ошибки могут быть и там, и там. Главная (в контексте топика) разница только в том, куда смещаются энергетические затраты: на разработку или на эксплуатацию. ИМХО, лучше сместить их на разработку.
Угу. Вот только пока что основные результаты в компайл-тайм верификации достигнуты как раз для управляемого мира. А так как я целиком за статическую верификацию, то, естественно, моё мнение склоняется в управляемую сторону.

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

K>Больная тема?
K>А при чем тут драйверы с кодеками вообще?

Действительно! Оно же в параллельной вселенной "даётся свыше", как я мог забыть?

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

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

Не передергивай, интерпретатор там только самый верхний уровень выполняет (если ты о маршрутизаторах) по управлению временем жизни логических соединений и установке связи, механика все-равно вся нативная и даже частично аппаратная. А у дотнета дорогой получился вызов нативных ф-ий, у интерпретатора Лиспа и то дешевле. Дотнет действительно, и не высокоуровневый, но и не низкоуровневый.

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

C>Тут один минус — язык Паскаль.

Тогда MODULA-2.

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

AVK>>Как обычно — кривые алгоритмы, кривой дизайн, плохое сопряжение независимых кусков кода и косяки в стандартных библиотеках.

V>Дык, такие вещи ни от платформы, ни от языков не зависят.

Вот именно.

V>ИМХО, гораздо важнее то, что дотнет формировал некую "культуру" программирования

Ничего он не формировал. Это не культура, а безкультурье. Всегда имеется значительная масса неграмотных разработчиков, и они в любом случае будут использовать какую то платформу. С убиением VB они просто мигрировали на шарп.
Сам же по себе шарп — весьма непростой язык, это не VB и не PHP. Просто он позволяет писать на нем в упрощенном режиме, эдакая реинкарнация С с классами в качестве С++. И чаще прощает ошибки.

V>В дотнете не так уж много приемов, характерных именно для дотнета, позволяющих добиться лучшей эффективности, когда она нужна (много других приемов более универсальны и работают для нейтива тоже)

А нужно чтобы было много?

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

V>А в дотнете встанет проблема привязать имеющуюся метаинформацию к такой "другой" оптимизированной программе, что может создать сложности для доступа к объектам через рефлексию.

Такие проблемы уже есть и никого особо не пугают. К примеру, инлайнинг методов корежит стектрейс.
Кроме того, далеко не всегда оптимизации вообще должны портить рефлексию. Устранение виртуальных вызовов, использование общей реализации для шаблонов с разными аргументами, escape анализ в джаве.
А есть ведь еще вещи, с оптимизацией не связанные, но точно так же вносящие несоответствие кода рефлексии — лямбды, итераторы, анонимные типы, async и т.п. И это, вобщем то, тоже особо никого не пугает.
Так что значимость проблемы ты сильно преувеличиваешь.

V> Учитывая, что традиционно в дотнете чуть больше чем все — библиотеки, не поможет даже суперкомпиляция, ибо в процессе работы можно загрузить другую библиотеку, которой приспичит обратиться к уже имеющейся загруженной и ранее соптимизированной суперкомпилятором библиотеке через рефлексию, и будет противоречие.

Тем не менее современный CLR умеет и межсборочную оптимизацию делать. Например, инлайнинг методов из другой сборки. Слабо компилятору С++ заинлайнить метод из другой dll?

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

C>>С++ развивается комитетом, но развивается. С++11 — несомненный шаг вперёд.

K>Но далеко не факт, что в правильном направлении

А в каком направлении должен развиваться язык, предназначенный для нейтива? Твои соображения?

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

AVK>Такие проблемы уже есть и никого особо не пугают. К примеру, инлайнинг методов корежит стектрейс.

Ну это, как раз, не страшно. В С++ это от рождения и не мешает. Тебе же не надо обеспечивать доступ к произвольной ячейке стека через рефлексию, поэтому противоречия нет.

AVK>Кроме того, далеко не всегда оптимизации вообще должны портить рефлексию. Устранение виртуальных вызовов, использование общей реализации для шаблонов с разными аргументами, escape анализ в джаве.

Ты еще забыл однократное извлечение адреса виртуальной ф-ии для многократного вызова в цикле. Конечно, это все оптимизации, как раз как я говорил — уровня 5-6-й версии С++. С которых пор он нехило продвинулся вперед, в отличие от, застрявшего в плане оптимизации на временах 2-го дотнета.

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

Ниже по ветке я интересуемый сценарий насчет рефлексии уже уточнил:

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

Например, у нас нет возможности получить метаданные текущего итератора в цикле foreach, поэтому и обеспечивать доступ не к чему.


AVK>Так что значимость проблемы ты сильно преувеличиваешь.

В С++ аналогично, один и тот же метод, который виден как экспортируемый из DLL, во внутренних вызовах инлайнится на раз. Поэтому проблема организовать точку входа для вызова ф-ии не стоит вообще. Другое дело, и во всех мануалах по работе оптимизаторов MSVC и gcc говорится, что любой экспортируемый из библиотеки символ сразу ограничивает кол-во приемов оптимизации вокруг этого символа. И далее по зависимостями оптимизация обрубается тоже, например, ф-ия должна возвращать какие-то данные, и вот эти уже данные должны быть в том виде, в котором они размечены в исходном коде. Так в дотнете, вообще все ф-ии экспортируемые с этой т.з. зрения, т.е. согласно тех же гайдов по оптимизации программ, заведомо делают невозможными подавляющую часть приемов оптимизатора.

Могу еще привести пример: есть такой популярный прием в С++, исходящий из того, что все объекты C++ с т.з. дотнета могут быть как value-type, так и ref-type. Есть некий объект, хранящий некое свое состояние в куче, например, рекурсивный фильтр, и в нем 4-8 вещественных полей. Данные ВСЕГДА подаются пачками, хоть интерфейс фильтра может, например, принимать по 1-му отсчету, не суть. Так вот, имея такой объект на куче, можно непосредственно подать ему пачку данных для обработки, просто вызывая методы объекта, а можно скопировать объект на стек, подать пачку данных и потом скопировать обратно. Разница в быстродействии, в зависимости от числа отсчетов в пачке 3-12 раз в пользу второго варианта, а это уже ого! Там просто разный код, даже если на 100% заинлайненый, он все-равно разный для обоих случаев. Первый работает с памятью через this, во втором участвуют только SSE регистры процесора, и нет никакого объекта на стеке. Так вот, для дотнета этот фокус не работает. И это я привел вырожденный случай, когда даже для дотнета не надо обеспечивать доступ через рефлексию.

V>> Учитывая, что традиционно в дотнете чуть больше чем все — библиотеки, не поможет даже суперкомпиляция, ибо в процессе работы можно загрузить другую библиотеку, которой приспичит обратиться к уже имеющейся загруженной и ранее соптимизированной суперкомпилятором библиотеке через рефлексию, и будет противоречие.

AVK>Тем не менее современный CLR умеет и межсборочную оптимизацию делать. Например, инлайнинг методов из другой сборки. Слабо компилятору С++ заинлайнить метод из другой dll?

Не люблю я слово "демагогия", но тут натуральное передергивание. Из статической библиотеки без проблем, и ты это знаешь. Так же как знаешь, что дотнетные динамические библиотеки не обладают св-вами нейтивных dll (только если не в GAC-е предкомпиленные и тоже уже нативные), ибо сколько процессов эту дотнетную dll загрузит, столько копий прошедших JIT ф-ий/методов будет, в то время как в нейтиве сообща используется уже готовый для исполнения нейтивный код, без перекомпиляции. Наверно поэтому в DLL обычно кладут такую ф-сть, которая дороже затрат на вызов, правда? А обертки и прочие кандидаты на инлайн поставляют в статических либах. Ну и еще полно либ, которые даже не статические, а идут исключительно как h-файлы. Например, объектная обертка над GDI+. Вообще прелесть, не надо загромождать клиентский комп лишними dll, из которых потом надо еще что-то инлайнить при запуске.

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

V>Ну это, как раз, не страшно. В С++ это от рождения и не мешает.

В C++ вообще нет стандартного анализируемого стектрейса, потому и не мешает.

V> Тебе же не надо обеспечивать доступ к произвольной ячейке стека через рефлексию

Что ты понимаешь под "доступ к произвольной ячейке стека"? Возможность анализа стектрейса в дотнете встроена.

V>Могу еще привести пример: есть такой популярный прием в С++, исходящий из того, что все объекты C++ с т.з. дотнета могут быть как value-type, так и ref-type. Есть некий объект, хранящий некое свое состояние в куче, например, рекурсивный фильтр, и в нем 4-8 вещественных полей. Данные ВСЕГДА подаются пачками, хоть интерфейс фильтра может, например, принимать по 1-му отсчету, не суть. Так вот, имея такой объект на куче, можно непосредственно подать ему пачку данных для обработки, просто вызывая методы объекта, а можно скопировать объект на стек, подать пачку данных и потом скопировать обратно.

Это одна из разновидностей escape-анализа и она вполне доступна для JIT. В дотнете с этим пока никто не ковырялся, а вот в джаве, где вообще нет value-типов, это одно из основных направлений развития оптимизатора.

V>Так вот, для дотнета этот фокус не работает.

Вполне работает.