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

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

Ты чего-то там себе теоретизируешь не попробовав ни разу. Мне это не интересно. Если хоть какие-то там доказателства предъявлял, а ты рассуждаешь черт знает о чем. Зчем не дублировать ответы Вольфхунда? Он теоретические рассуждения уже ответил.

Я тебе тоже отвечал не раз, что ты не там проблему ищешь. Но ты это игнорируешь.

_>Вот именно что читать и писать — это же дикий бред.

Почему бред? Как раз это очень логично. Безопасно читать и писать разделяемые данные можно только залпом, атомарно.

_>Самая идея отображаемых в память файлов заключается в том, что после создания соответствую сущности у тебя в памяти уже образуются (причём максимально эффективно — с помощью механизма подкачки страниц виртуальной памяти) все нужные данные, с которыми ты можешь делать что угодно (можно например каст сделать к той же самой структурке). Если же тебе для работы с этими данными понадобится ещё отдельно выделять дополнительную память и копировать в неё данные из системной памяти (выделенной ОС для отображения), то это на корню убивает всю мощь данного инструмента.

Да какие проблемы то? Перходи в unsafe и используй указатели полученные через SafeMemoryMappedViewHandle.AcquirePointer.

_>Полностью согласен. И я сам стараюсь использовать исключительно кроссплатформенные библиотеки, а не вызовы API ОС. Проблема в другом: кому-то же ведь надо писать эти самые библиотеки. И если язык не предоставляет возможности для эффективного прямого вызова системных функций, то как бы ты не старался, у тебя не получится эффективной библиотеки.

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

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

Как-то для дотнета на этом механизме умудрились написать все необходимые библиотеки. Почему-то их количество и качество не уступает (с скорее сильно превосходит) плюсовые.

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

VD>>DirectX опять же никаких пробем. Есть туча игр написанных на управляемых языках использующих его и Опен ЖЛ напрямую. Да тот же WPF опять же с ним общается.

_>Ну да, ну да. ))) Только вот почему-то во многих статьях о работе библиотеки поддержки DirectX в таких языках можно найти утверждение такого типа: "возможно кто-то считает, что накладные расходы от маршалинга и т.п. механизмов языка не позволяют писать на этом языке под DirectX, но это не правда — для наших целей (мы же не собираемся писать крутую 3D игру) быстродействия хватает"...

Я не видел этих "многих статей". Зато я точно знаю как работает маршалинг. Лля простых типов используемых в DirectX никакого маршалинга не делается. Если бы это было так, то тот же WPF тормозил бы безбожно, а он летает. И игры бы тормозили, а по факту отличить игру написанную на дотнете от игры написанной на С++ нельзя.

Ты уж раз утверждаешь что-то, потрудись привести ссылки на эти твои "многие" статьи. И за объясни как же все же работает WPF и те самые игры.

В реальности то что говоришь о маршалинге не соответствует действительности на фоне тех операций, что делает DirectX в видеокарте общение с ним это сущие копейки. И маршалирга там особого нет. Просто сам DirectX мало пригоден для программирования в safe-режиме. Придется переходить на unsafe и тут уже встает вопрос, а "на хрена козе баян?". Потом люди вспомниают, что DirectX прибивает гвоздям твой софт к Винде, и что DirectX это далеко не полный игровой движок. И люди делают здравый вывод, что проще не трахаться с убогим DirectX, а взять готовый движок вроде Юнити. Ну, а раз он уже есть и это много человеколет, то на хрена писать еще один на дотнете? Вот только маршалинг ведь, при взаимодействии с движком, никуда не девается. Но это никого не трогает, так как опять же он ничтожен на общем фоне.

_>Да, и кстати, а тебе не приходило в голову, что MS не предоставляет в .net инструментов работы с DirectX (все соответствующие библиотеки сторонние) не просто так? )))

С DirectX можно работать напрямую. МС вообще нихрена не предоставляет, по большому счету. Но примеры проектов на дотнете для Direct3D есть прямо в DirectX SDK ([SDKroot]\Samples\Managed\Direct3D\Tutorials). Я их сам запускал много лет назад. Работает, естественно, все быстро. Никаких сказочных тормозов маршалинга не обнаруживается. Скачай — убедись.

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

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

Домыслы очень трудно опровергнуть. Их можно генерировать тоннами, а чтобы чтобы их провернуть нужно тратить массу времени и усилий. По этому в научном сообществе используется обобранный принцип. Утверждающий обязан сам обосновать свои утверждения. Причем не словами "я читал", а тестами, ссылками, логическими заключениями выводимыми из фактов.

Это ты ходишь по форумам и излагаешь озвучиваешь миф. Вот тебе и доказывать, что это не миф.

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

С тем же маршалингом ведь все просто. Маршалинг — это трансформация данных. Если у тебя в функции ОС нужны данные не подпадающие под форматы используемые в дотнете, то их надо преобразовать (туда и обратно). Но если функции передаются данные в ожидаемом формате и ты готов трахаться в с возвращаемым форматом, то и преобразовывать нечего. Ожидает АПИ некую структуру — так опиши ее как она есть и отдай. А память выдели сам (в стеке или АПИ-функциями) или припинь объект на время вызова (получив его указать в операторе fixed). Будет тебе скорость как в случае С. А разные там int/long и прочие примитивы не маршалятся за ненадобностью. Вот со строками другое дело. Но опять же тебе никто не мешает передавать туда указатель в исходном формате, а весь трах по преобразованию, если оно нужно, возложить на себя. В unsafe-режиме у Шарпа все для этого есть. Можно сделать и намного больше, если оно надо.

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

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

Ты чего-то там себе теоретизируешь не попробовав ни разу. Мне это не интересно. Если бы ты хоть какие-то доказательства предъявлял, а ты рассуждаешь черт знает о чем. Зачем мне дублировать ответы Вольфхунда? Он на теоретические рассуждения уже ответил.

Я тебе тоже отвечал не раз, что ты не там проблему ищешь. Но ты это игнорируешь.

_>Вот именно что читать и писать — это же дикий бред.

Почему бред? Как раз это очень логично. Безопасно читать и писать разделяемые данные можно только залпом, атомарно.

_>Самая идея отображаемых в память файлов заключается в том, что после создания соответствую сущности у тебя в памяти уже образуются (причём максимально эффективно — с помощью механизма подкачки страниц виртуальной памяти) все нужные данные, с которыми ты можешь делать что угодно (можно например каст сделать к той же самой структурке). Если же тебе для работы с этими данными понадобится ещё отдельно выделять дополнительную память и копировать в неё данные из системной памяти (выделенной ОС для отображения), то это на корню убивает всю мощь данного инструмента.

Да какие проблемы то? Переходи в unsafe и используй указатели полученные через SafeMemoryMappedViewHandle.AcquirePointer.

_>Полностью согласен. И я сам стараюсь использовать исключительно кроссплатформенные библиотеки, а не вызовы API ОС. Проблема в другом: кому-то же ведь надо писать эти самые библиотеки. И если язык не предоставляет возможности для эффективного прямого вызова системных функций, то как бы ты не старался, у тебя не получится эффективной библиотеки.

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

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

Как-то для дотнета на этом механизме умудрились написать все необходимые библиотеки. Почему-то их количество и качество не уступает (с скорее сильно превосходит) плюсовые.

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

VD>>DirectX опять же никаких пробем. Есть туча игр написанных на управляемых языках использующих его и Опен ЖЛ напрямую. Да тот же WPF опять же с ним общается.

_>Ну да, ну да. ))) Только вот почему-то во многих статьях о работе библиотеки поддержки DirectX в таких языках можно найти утверждение такого типа: "возможно кто-то считает, что накладные расходы от маршалинга и т.п. механизмов языка не позволяют писать на этом языке под DirectX, но это не правда — для наших целей (мы же не собираемся писать крутую 3D игру) быстродействия хватает"...

Я не видел этих "многих статей". Зато я точно знаю как работает маршалинг. Для простых типов используемых в DirectX никакого маршалинга не делается. Если бы это было так, то тот же WPF тормозил бы безбожно, а он летает. И игры бы тормозили, а по факту отличить игру написанную на дотнете от игры написанной на С++ нельзя.

Ты уж раз утверждаешь что-то, потрудись привести ссылки на эти твои "многие" статьи. И за одно объясни как же все же работает WPF и те самые игры.

В реальности то что говоришь о маршалинге не соответствует действительности. На фоне тех операций, что делает DirectX в видеокарте общение с ним это сущие копейки. И маршалинга там особого нет. Просто сам DirectX мало пригоден для программирования в safe-режиме. Придется переходить на unsafe и тут уже встает вопрос, а "на хрена козе баян?". Потом люди вспоминают, что DirectX прибивает гвоздям твой софт к Винде, и что DirectX это далеко не полный игровой движок. И люди делают здравый вывод, что проще не трахаться с убогим DirectX, а взять готовый движок вроде Юнити. Ну, а раз он уже есть и это много человеколет, то на хрена писать еще один на дотнете? Вот только маршалинг ведь, при взаимодействии с движком, никуда не девается. Но это никого не трогает, так как опять же он ничтожен на общем фоне.

_>Да, и кстати, а тебе не приходило в голову, что MS не предоставляет в .net инструментов работы с DirectX (все соответствующие библиотеки сторонние) не просто так? )))

С DirectX можно работать напрямую. МС вообще нихрена не предоставляет, по большому счету. Но примеры проектов на дотнете для Direct3D есть прямо в DirectX SDK ([SDKroot]\Samples\Managed\Direct3D\Tutorials). Я их сам запускал много лет назад. Работает, естественно, все быстро. Никаких сказочных тормозов маршалинга не обнаруживается. Скачай — убедись.

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

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

Домыслы очень трудно опровергнуть. Их можно генерировать тоннами, а чтобы их провернуть нужно тратить массу времени и усилий. По этому в научном сообществе используется общий принцип. Утверждающий обязан сам обосновать свои утверждения. Причем не словами "я читал", а тестами, ссылками, логическими заключениями выводимыми из фактов.

Это ты ходишь по форумам и озвучиваешь миф. Вот тебе и доказывать, что это не миф.

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

С тем же маршалингом ведь все просто. Маршалинг — это трансформация данных. Если у тебя в функции ОС нужны данные не подпадающие под форматы используемые в дотнете, то их надо преобразовать (туда и обратно). Но если функции передаются данные в ожидаемом формате и ты готов трахаться в с возвращаемым форматом, то и преобразовывать нечего. Ожидает АПИ некую структуру — так опиши ее как она есть и отдай. А память выдели сам (в стеке или АПИ-функциями) или припинь объект на время вызова (получив его указать в операторе fixed). Будет тебе скорость как в случае С. А разные там int/long и прочие примитивы не маршалятся за ненадобностью. Вот со строками другое дело. Но опять же тебе никто не мешает передавать туда указатель в исходном формате, а весь трах по преобразованию, если оно нужно, возложить на себя. В unsafe-режиме у Шарпа все для этого есть. Можно сделать и намного больше, если оно надо.