Здравствуйте, DarkEld3r, Вы писали:
VD>>Я говорю не о производительности кода, а о затратах интеллектуальных на организацию и поддержку непротиворечивого управления памятью. Чем больше программа и чем она сложнее, тем больше эти затраты. И тем проще сделать ошибку. DE>Так я тоже об интеллектуальных затратах говорю. В простых/средних случаях всё легко: написать make_unique не сложнее чем new. В сложных случаях, конечно, всё непросто, но и с GC можно напортачить и оставить висеть в памяти ненужные объекты, хоть и сложнее. То есть, думать всё равно приходится.
Тут ключевой нюанс в том, что при правильном портирование такого кода на C#
var x=new X();
в код на C++ будут возможны три разных варианта с разной вероятностью:
X x; // ~99% случаев
auto x=make_unique<X>(); // ~1% случаев
auto x=make_shared<X>(); // ~0,1% случаев (например в моём текущем проекте не понадобилось ни разу)
Т.е. вроде бы действительно кажется, что задача сложнее (всё же 3 варианта вместо одного), но с учётом вероятностей картина резко меняется. А если учесть ещё и тот факт, что первый вариант из C++ не только самый короткий в написание, но ещё и приводит к увеличению быстродействия в разы, то...
Здравствуйте, VladD2, Вы писали:
_>>Хм, ну вообще то в gcc уже давно добавили поддержку намного более высокоуровневой абстракции для реализации подобных вычислений. VD>Дык это же в компилятор добавили. Ты прочти внимательно эту статью и поймешь, что там речь идет о том, что ты сам можешь расширить компилятор нужным образом. Не ждать милости от природы, а взять ... Короче, ты понял.
Так я как бы только за такие возможности. Собственно поэтому я и хотел заполучить себе C++ с нормальными макросами и т.п. ))) Просто вот конкретно именно этот пример уже реализован, причём крупными консорциумами и на высоком уровне абстракции. )
Здравствуйте, VladD2, Вы писали:
_>>Проблемы классических реализаций GC следующие: stop-the-world и недетерминированное время сборки. И указанные вещи являются проблемой не для быстродействия (грубо говоря числодробилке это не принципиально), а для реалтаймовых и Low Latency задач. VD>Надуманные это проблемы для 99% случаев применения. Ты сам то хард-реалтайм системы пишешь? Вот поверь, что у меня ни разу не было проблем с латентностью. Вот скорость вычисления хотелось иногда по выше иметь, а с латентностью проблем нет.
Ну вообще то пишу — для МК. ) Причём сейчас это всё крайне популярное направление, которым уже и многие школьники балуются (Ардуина захватывает мир). Я конечно такой попсой (ардуинками) не страдаю, у меня серьёзные игрушки и кстати у меня там полноценный C++14. )))
Но проблем у java и .net в этой области действительно нет, просто потому что их самих тут. ))) Вот в области LL какие-то попытки выживания встречаются (в основном на базе Azul Zing).
VD>Основное время собираются эфемерные поколения. Живых объектов там мало. Сборка проходит за микросекунды. Задержку в миллисекунды ты все равно не заметишь. VD>В итоге все упирается в алгоритмы. Довольно по фигу ЖЦ у тебя или дестркуторы, если ты пытаешься обсчитать объем данных, который нельзя обсчитать за приемлемое время.
Хыхы, я конечно сам не тестировал, но по слухам от знакомых при серверном применение java/.net встречаются аж секундные задержки, когда GC надо очищать по несколько гигов.
VD>>>Ну, а 90% тормозов дотнета связаны даже не с этим, просто с посредственной кодогенерацией и в отсутствие возможностей управлять процессом кодонерерации для всех этих мемори-барьеров. _>>Нет, не верно. VD>Ты производил исследования? С чего такая уверенность? Ты хотя бы в дизассемблере код смотрел?
Вообще то это общеизвестные вещи. Но тесты тоже всё равно были (хотя бы чтобы продемонстрировать сомневающимся, хотя специалистам в данной области достаточно знать общих принципов), в том числе и на этом форуме.
Ну а в качестве теста можешь глянуть например сюда: http://xoofx.com/blog/2015/10/08/stackalloc-for-class-with-roslyn-and-coreclr/ — ускорение .Net кода на порядок (никакой LLVM и т.п. такого не даст) с помощью банального использования стековых объектов.
_>>Если ты перенесёшь .net как он есть на кодогенерацию с помощью LLVM, то вряд ли увидишь какое-то существенное увеличение быстродействия. VD>Именно, что увидишь. Только надо еще от мебори-барьеров избавиться и прочих по натыканных по коду проверок.
Лишние проверки на границы массива — это конечно тоже зло, но гораздо меньшее чем излишняя косвенность.
_>>Основные тормоза .net связаны с излишней косвенностью (размещение данных не на стеке, ссылочные типы и т.п.) VD>Ну, вот откуда ты эту ерись берешь? Какой еще косвенности? Чем указатель в плюсах отличается от указателя в ЖЦ-куче?
Вроде бы уже сотни раз тебе тут говорили, что в плюсах в большинстве случаев будет не указатель, а размещение на стеке. Это не только быстрее (см. ниже), но и позволяет применять целый набор простейших по кодированию, но при этом мощных по эффекту оптимизаций (например виртуальная функция объекта размещённого на стеке будет вызвана прямым образом и скорее всего пройдёт инлайнинг).
Далее, косвенность — это когда нам требуется для доступа к непосредственно данным сделать не одну выгрузку из памяти в регистр (процессор то работает только с ними), а несколько последовательных. Чем больше таких операций, тем хуже. Причём главное не в лишнем коде (хотя и это тоже влияет), а в нарушение работы кэша и невозможность использования SIMD. Хотя в кэше тоже есть свой предсказатель, но он мало что реально может и плохо справляется даже с первым уровнем косвенности, а уж следующие точно убивают всю эффективность. Это кстати легко измерить даже в том же C++, если сравнить проход по vector<X> и по vector<X*> (массив объектов .net выглядит именно так) — разница в разы.
_>>и рантаймовой рефлексией. VD>Слушай, ну ты такую чушь несешь, что это даже обсуждать несерьезно. Рефлексия не поднимается пока ты ее явно не позавешь. ЖЦ живет за счет знания универсального устройства объектов. Ему рефлексия вообще не нужна. VD>Сказал бы хотя бы о джите. Но рефлексия? Она тупо отирает память в борке. Но не более того.
Как мило, прямо .net — мир для эльфов. ))) Только реальность совсем другая... Сейчас кстати узнаем насколько ты с ней знаком. Если ты действительно в курсе внутреннее работы .Net, то с ходу ответишь на такой простейший вопрос: сколько памяти выделится в процессе исполнения такого кода?
class X{
public int x;
};
var x=new X();
И потом аналогичный вопрос для такого кода:
class X{
public string x="hello world";
};
var x=new X();
Ну и после демонстрации указанных чисел я надеюсь на комментарии от тебя по теме:
1. как на это всё смотрит кэш процессора (я уж даже не заикаюсь про какие-то шансы на SIMD и т.п.)
2. обеспечение работы какой никчемной технологии виновато в озвученных тобой цифрах.
_>>Именно эти два ключевых факта убивают возможностью применения огромного числа эффективных оптимизаций. VD>Ты живешь в мире фантазий. Просто задай себе вопрос. Откуда в твоей голове взялись эти представления? Ты досконально изучал вопрос? Ты сидел в дизасемблере? Ты читал блоги разработчиков ЖЦ?
Эм, а причём тут GC то? Про него не было ни слова. Ещё раз поясняю, все основные тормоза .Net можно элементарно повторить и на C++ (без всяких GC), если программировать не правильно.
VD>Вот я все это делал. И у меня нет сомнений, что ты заблуждаешься. Природа тормозов (которые ты тоже скорее всего преувеличиваешь) кроется в следующих факторах: VD>1. Для поддержки низкой латентности ЖЦ JIT и ngen забивают код кучей перехватчиков (мемори-барьеров) и прочего непроизводительного года. VD>2. Генератор кода в дотнете далек от идеала. Многие предположения, что делаются в плюсах не делаются в дотнете из соображений безопасности. VD>3. Для работы ЖЦ стэк должен иметь определенный формат. Опять же оптимизации его могут сломать. VD>4. Дотнет делает кучу рантайм-проверок. Даже при вызове метода он всегда делает проверку на ноль, чтобы сгенерировать осмысленное, легко отлаживаемое исключение, а не AV. Далее идут проверки выхода за пределы массива. Оптимизации для их делаются только для очень простеньких паттернов перебора. VD>5. В дотнете сделан овердизайн при обработке массивов. Они допускают ко/контр-вариантность. Это требует новых проверок в рантайме. Есть сопособы обойти это, но мало кто этим заморачивается. VD>6. Объект в дотнете имеет некоторый оверхэд. В С++ он тоже есть, но дотнетный объект все же по пушистее. В общем-то это копейки, но свою толику вносит. VD>7. Вот интерфейсы в дотнете действительно добавляют излишнюю косвенность. Но можно их не использовать, да и "тормоза" из-за этого не видно и в микроскоп. Новые процессоры (а где теперь взять старые?) сильно сглаживают этот недостаток за счет умного предсказания переходов VD>8. Была проблема с делегатами, но ее устранили. Сейчас лямбды делегаты быстрее интерфейсов. VD>9. ФП в Шарпе (и Немерле) приводит к созданию объектов в куче. Это можно было бы оптимизировать для множества случаев, но это не сделано. VD>10. Компилятор (JIT) халтурно относится к выравниванию. Иногда перестановка операторов местами дает двукратное изменение времени выполнения. VD>11. Дженерики в дотнете объектны. Это иногда (хотя далеко и не всегда) приводит к оверхэду. Есть мутные косяки с дженериками в статических типах. Особенно серьезные косяки с дженерик-интерфейсами. Тут есть ряд случаев, которые просто таки втыкают. В Немерле их, кстати, меньше, так как он использует сбоственные функциональные объекты и умудрился не повторить кое какие косяки Шарпа. VD>12. Дотнет часто манипулирует данными в хипе, хотя их можно было бы разместить в стеке. Тут бы помог эскейп-анализ и прочие оптимизации, но МС умудрился их не сделать за 15 лет. VD>Как видишь это совсем не то, что ты себе представлял.
Твои пункты 6 и 12 — это как раз и есть то, что я указывал, только ты постарался не использовать правильную терминологию. И эти пункты (12-ый пожалуй самый главный) и дают главные тормоза. Кроме этого в .net конечно же есть ещё много кривизны (убогие дженерики и делегаты, лишнее проверки в массивах и т.п.), но она уже даёт меньший вклад.
_>>И есть разговоры об инструментах размещения любых данных на стеке. VD>Рассуждения есть, а размещения скорее всего нет. VD>Для этого нужен анализ. Он осложняется тем, что данные запаковываются в объекты и т.п.
Имеется в виду ручное размещение, отдельной командой языка. )
_>>Вот если к такому решению приделать нормальный кодогенератор (что кстати в MS и собираются сделать, взяв свой бэкенд от C++), то уже можно получить более менее приемлемое быстродействие. Только это уже будет решение имеющее мало общего с современным большим .net'ом. ))) VD>Команда С++ уже писала кодогенератор для дотнета. Получилось не очень. Там нужны оптимизации другого рода. А на них МС боится замахнуться. Это большой объем работ. При этом чем занимается команда ЦЛР-а — не ясно. 15 жуют сопли.
Я же говорю, без фундаментальной перестройки языка никакие крутые оптимизаторы не помогут.
_>>Вообще то как раз то, что ты описал — это и есть ручное управление. VD>Нет. Ручно, это когда ты решаешь когда объект должен умереть. А когда ты решаешь, где объект живет — это не немного другое. Это, конечно, тоже требует напряжения, но совсем не того, что при продумывании времени жизни каждой ссылки.
Ну так уже сложнее, чем текущая реализация работы с памятью в C++. Вот WolfHound кидал в этой темке ссылки на свою идею — там да, действительно автоматическое управление (по его словам это всё отслеживает сам компилятор). Правда я сомневаюсь в возможности реализации подобного на практике. Но если бы вдруг у него получилось, то там бы была реально автоматика и возможно весьма эффективная.
_>>В гораздо большей степени, чем в C++. VD>Как ты умудряешься делать такие выводы? VD>Вот писал я на плюсах. Для ускорения кода вместо обычного хипа использовал пул. Потом грохал пул залпом. Единственная проблема, которая при этом возникала — это то, что грохнув пул я не был на 100% уверен, что где-то не остался указатель в этот пул, который потом может грохнуть всю программу. А тут у меня тоже самое, но с полным котролем. Ни один указатель не подвиснет. Я могу или выявить такие указатели и сгенерировать исключение, или просто пометить их нулом. VD>В чем тут сложность?
Подобный подход очевидно чуть сложнее в использование, чем стандартные методики C++. Однако на определённом редком классе задач они действительно позволяют достичь большего быстродействия. И соответственно в этих случаях их применение обосновано (берём Boost.Pool и вперёд).
Здравствуйте, Serginio1, Вы писали:
S>можно получить более менее приемлемое быстродействие. Только это уже будет решение имеющее мало общего с современным большим .net'ом. )))
Дык мы в этой теме обсуждаем портирование Немерла (точнее того расширяемого языка который мы планируем делать в этом году) под нйтив. Речь идет о создании LLVM-бэкэнда к нитре и реализации собственного рантайма.
Нас как-то не сильно волнует, что это будет совсем не .net.
S> Сейчас 2 Силара второй Core c .Net Native
И что? Там скорее доптимизации из-за переносимости.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, novitk, Вы писали:
N>Влад, я просто перестану отвечать, если ты не изменишь тон. Я не понимаю как из контекста дискуссии можно не понять о чем я писал.
Вообще-то, из контекста как раз ни разу не ясно, что в терминологии ошибся.
ОК, буду по поаккуратнее, что и с твоей стороны видеть хотелось бы.
N>Нет не дают, для полных typeclass еще нужен implicit.
Для данной задачи вроде и так не плохо. Я вообще-то не очень понимаю всей глубины этой фичи. По мне так неявные приведения типов. Прикольно, конечно, что можно можно их сделать для чужих типов. Но все же приведения они приведения и есть.
N>Ну допустим он есть, как мне сделать теперь: N>val a = List(1, 2, 3) N>val b = List(3, 4, 5) N>a * b
А что ты под этим понимаешь?
Мы вроде говорили об арифметике в дженериках.
VD>>Я особо не сравнивал с Хаскелем. N>но мнение имеешь...
Не обязательно быть курицей, чтобы судить о яичнице. Я баловался с ним, но как-то давно и был сильно расстроен необходимостью все в do заворачивать. С его системой типов я разобрался. Ничего экстраординарного там нет.
VD>>Так, например, не поддерживаются неявные приведения типов, перегрузки и т.п. N>Не нужно. В скале все это впихнули, вышло плохо.
Ну, вот на практике такой язык людям не нужен. Его удел — образцово показательный "чистый" ФП. А на практике одним ФП сыт не будешь.
VD>>А что нужно сделать, чтобы этот Data.HashTable.IO загрузить? N>сейчас нет под рукой нужного компа(*), но что-то типа: N>cabal update N>cabal install hashtable
cabal: There is no package named 'hashtable'.
You may need to run 'cabal update' to get the latest list of available
packages.
ЧЯДНТ?
VD>>Ну, можно полностью пример воспроизвести (с объявлением функции до использования)? N>import qualified Data.HashTable.IO as H N>printKey d k = do N> v <- H.lookup d k N> print v N>main = do N> ht <- H.new N> H.insert ht "sss" 42 N> printKey ht "sss" N>[/haskell] N>не проверял из за (*) ^!
Это даже не парсится:
<interactive>:12:42: error: parse error on input ‘printKey’
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Дык мы в этой теме обсуждаем портирование Немерла (точнее того расширяемого языка который мы планируем делать в этом году) под нйтив. Речь идет о создании LLVM-бэкэнда к нитре и реализации собственного рантайма.
VD>Нас как-то не сильно волнует, что это будет совсем не .net.
S>> Сейчас 2 Силара второй Core c .Net Native
VD>И что? Там скорее доптимизации из-за переносимости.
Генератор образов в машинном коде (NGEN) компилирует сборки в машинный код и устанавливает их в кэш образов в машинном коде на локальном компьютере. Однако хотя NGEN, как и .NET Native, создает машинный код, NGEN имеет существенные отличия от .NET Native:
Если для конкретного метода нет образа в машинном коде, NGEN переключается на JIT-компиляцию кода. Это означает, что образы в машинном коде должны продолжать включать метаданные и IL-код для того случая, если генератору NGEN необходимо переключиться на JIT-компиляцию. В противоположность этому .NET Native только создает образы в машинном коде и не переключается на JIT-компиляцию. В результате должны сохраняться метаданные, необходимые только для некоторых сценариев отражения, сериализации и взаимодействия.
NGEN по-прежнему полагается на полную среду CLR для таких сервисов, как загрузка сборок, удаленное и локальное взаимодействие, управление памятью, сбор мусора и, при необходимости, JIT-компиляция. В .NET Native многие из этих сервисов являются либо ненужными (JIT-компиляции), либо разрешаются во время построения и включаются в сборку приложения. Остальные сервисы, наиболее важным из которых является сбор мусора, включены в гораздо более компактную, оптимизированную среду выполнения mrt100_app.dll.
Образы NGEN, как правило, хрупкие. Например, обновление или изменение зависимости обычно требует, чтобы сборки, которые его используют, также были пересозданы NGEN. Это особенно верно для системных сборок в библиотеке классов .NET Framework. В противоположность этому .NET Native позволяет обслуживать приложения независимо друг от друга.
Здравствуйте, WolfHound, Вы писали:
WH>Миллионы мух не могут заблуждаться.
Напомню контекст: "Ускорять разработку за счёт большого количества низкоквалифицированных программистов идиотизм". Не смотря на твоё отношение, так всё равно могут (и будут) делать.
DE>>Написание сравнительно эффективного параллельного кода без утечек и расстрелов памяти после прочтения коротенького мануала. WH>Ну это просто не правда. Ничто не мешает там накосячить с многопоточностью.
И где я утверждал обратное?
В любом случае, с одной стороны имеется С++, где выстрелить в ногу, особенно если не потратить на "обучение" несколько лет, намного проще. С другой: джава/C#, которые хоть и безопаснее плюсов, но явно сложнее Go.
А последний предоставляет вполне удобные примитивы для многопоточности на уровне языка, а не тупо мьютексы, так что накосячить несколько сложнее.
Здравствуйте, alex_public, Вы писали:
_>Ну ключевое тут как раз про системное API. ) На всяческие JNI и P/Invoke без слёз не взглянешь. Не говоря уже о том, что даже запустив это, непонятно что делать с частью данных (т.к. системное API обычно основано на указателях).
Пусть так, но у шарпа и джавы весьма жирные стандартные библиотеки. Многим не приходится опускаться на уровень системного API и уж точно такие вызовы не должны быть размазаны по всему коду.
Здравствуйте, DarkEld3r, Вы писали:
_>>Ну ключевое тут как раз про системное API. ) На всяческие JNI и P/Invoke без слёз не взглянешь. Не говоря уже о том, что даже запустив это, непонятно что делать с частью данных (т.к. системное API обычно основано на указателях). DE>Пусть так, но у шарпа и джавы весьма жирные стандартные библиотеки. Многим не приходится опускаться на уровень системного API и уж точно такие вызовы не должны быть размазаны по всему коду.
Не, жирные библиотеки тут ни при чём. Они же не могут заменить функции ОС. Единственно, что они могут, это как-то обернуть вызовы к ним на свой лад. Но это во-первых работает с дикими тормозами (например если говорить о DirectX), а во-вторых обычно выглядит крайне убого (посмотри например на то, как представлены в .Net такие общеупотребительные и важные вещи, как отображаемые в память файлы).
Здравствуйте, alex_public, Вы писали:
_>Не, жирные библиотеки тут ни при чём. Они же не могут заменить функции ОС. Единственно, что они могут, это как-то обернуть вызовы к ним на свой лад. Но это во-первых работает с дикими тормозами (например если говорить о DirectX), а во-вторых обычно выглядит крайне убого (посмотри например на то, как представлены в .Net такие общеупотребительные и важные вещи, как отображаемые в память файлы).
Очередной раз убеждаюсь, что ты живешь в плену мифов.
Посмотрел я и АПИ отображаемых файлов. АПИ как АПИ. Можно прямо структуры писать и читать.
И библиотеки отлично заменяют функции ОС. Мне плевать что там внутри делается, если мне не надо обращаться к функциям ОС. Мне важно задачу решить. И она решается.
Ну, и не всегда библиотеки являются обертками над АПИ ОС. Тот же ВПФ ни разу не обертка, а соамостоятельный АПИ. Там есть ядро написанное на С, но оно очень мелкое и низкоуровневое и оно опять же не опирается на Вынь АПИ, а лезет сразу в видеоподсистему на низком уровне. Но главное, что меня это не трогает. Я использую управляемые классы и все работает быстро и качественно.
DirectX опять же никаких пробем. Есть туча игр написанных на управляемых языках использующих его и Опен ЖЛ напрямую. Да тот же WPF опять же с ним общается.
Так что в высокоуровневом коде не должно быть прямых системных вызовов, ну, или их должно быть как можно меньше. Это сильно упрощает жизнь.
Ну, а все что ты здесь заявил не более чем домыслы. И ты повторяешь их из раза в раз. Несколько поднадоел, честное слово.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
_>>Не, жирные библиотеки тут ни при чём. Они же не могут заменить функции ОС. Единственно, что они могут, это как-то обернуть вызовы к ним на свой лад. Но это во-первых работает с дикими тормозами (например если говорить о DirectX), а во-вторых обычно выглядит крайне убого (посмотри например на то, как представлены в .Net такие общеупотребительные и важные вещи, как отображаемые в память файлы).
VD>Очередной раз убеждаюсь, что ты живешь в плену мифов.
Ну пока что от тебя слышны исключительно громкие утверждения. А когда переходим к конкретике и разбору реальных технических нюансов, ты почему-то резко пропадаешь из дискуссии. )
VD>Посмотрел я и АПИ отображаемых файлов. АПИ как АПИ. Можно прямо структуры писать и читать.
Вот именно что читать и писать — это же дикий бред. Самая идея отображаемых в память файлов заключается в том, что после создания соответствую сущности у тебя в памяти уже образуются (причём максимально эффективно — с помощью механизма подкачки страниц виртуальной памяти) все нужные данные, с которыми ты можешь делать что угодно (можно например каст сделать к той же самой структурке). Если же тебе для работы с этими данными понадобится ещё отдельно выделять дополнительную память и копировать в неё данные из системной памяти (выделенной ОС для отображения), то это на корню убивает всю мощь данного инструмента.
VD>И библиотеки отлично заменяют функции ОС. Мне плевать что там внутри делается, если мне не надо обращаться к функциям ОС. Мне важно задачу решить. И она решается.
Полностью согласен. И я сам стараюсь использовать исключительно кроссплатформенные библиотеки, а не вызовы API ОС. Проблема в другом: кому-то же ведь надо писать эти самые библиотеки. И если язык не предоставляет возможности для эффективного прямого вызова системных функций, то как бы ты не старался, у тебя не получится эффективной библиотеки.
VD>DirectX опять же никаких пробем. Есть туча игр написанных на управляемых языках использующих его и Опен ЖЛ напрямую. Да тот же WPF опять же с ним общается.
Ну да, ну да. ))) Только вот почему-то во многих статьях о работе библиотеки поддержки DirectX в таких языках можно найти утверждение такого типа: "возможно кто-то считает, что накладные расходы от маршалинга и т.п. механизмов языка не позволяют писать на этом языке под DirectX, но это не правда — для наших целей (мы же не собираемся писать крутую 3D игру) быстродействия хватает"...
Да, и кстати, а тебе не приходило в голову, что MS не предоставляет в .net инструментов работы с DirectX (все соответствующие библиотеки сторонние) не просто так? )))
VD>Ну, а все что ты здесь заявил не более чем домыслы. И ты повторяешь их из раза в раз. Несколько поднадоел, честное слово.
Ну если это домыслы, то тогда ты легко опровергнул бы их фактами. Но пока что в данной теме наблюдается обратная ситуация — ты бегаешь от обсуждения конкретных фактов. )))
Здравствуйте, 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-режиме у Шарпа все для этого есть. Можно сделать и намного больше, если оно надо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
_>>Вот именно что читать и писать — это же дикий бред. VD>Почему бред? Как раз это очень логично. Безопасно читать и писать разделяемые данные можно только залпом, атомарно.
Какие ещё разделяемые данные, какая атомарность, ты вообще о чём? )
_>>Самая идея отображаемых в память файлов заключается в том, что после создания соответствую сущности у тебя в памяти уже образуются (причём максимально эффективно — с помощью механизма подкачки страниц виртуальной памяти) все нужные данные, с которыми ты можешь делать что угодно (можно например каст сделать к той же самой структурке). Если же тебе для работы с этими данными понадобится ещё отдельно выделять дополнительную память и копировать в неё данные из системной памяти (выделенной ОС для отображения), то это на корню убивает всю мощь данного инструмента. VD>Да какие проблемы то? Перходи в unsafe и используй указатели полученные через SafeMemoryMappedViewHandle.AcquirePointer.
Ну даже если забыть про очередной совет перейти к unsafe (хотя мы ничего такого хитрого не хотим, всего лишь воспользоваться одно из базовых возможностей ОС), то как нам это поможет получить класс или структуру, отображённые на данные файла? )
_>>Полностью согласен. И я сам стараюсь использовать исключительно кроссплатформенные библиотеки, а не вызовы API ОС. Проблема в другом: кому-то же ведь надо писать эти самые библиотеки. И если язык не предоставляет возможности для эффективного прямого вызова системных функций, то как бы ты не старался, у тебя не получится эффективной библиотеки. VD>Ну, так для вызова совершенно не обязательно именно хадеры читать и делать небезопасный вызов. Вот дотнетный PInvoke и делает все что нужно. Ты описываешь нужные методы в определенном формате, а дотнет сам генерит код, чтобы безопасно передать и получить данные. Для тебя такое описание автоматом становится управляемой функций.
Из минусов: надо самому писать эту обёртку и возможны существенные накладные расходы.
VD>Как-то для дотнета на этом механизме умудрились написать все необходимые библиотеки. Почему-то их количество и качество не уступает (с скорее сильно превосходит) плюсовые.
Вообще то как раз наоборот. Уступает и по количеству и по качеству. Вот например прямо сегодня случайно (там изначальная тема была по "моему профилю", так что мне кинули на неё ссылку и я по подписке на тему всё остальное тоже прочитал) увидел: https://rsdn.org/forum/dotnet/6717008.1
. И таких примеров множество.
_>>Ну да, ну да. ))) Только вот почему-то во многих статьях о работе библиотеки поддержки DirectX в таких языках можно найти утверждение такого типа: "возможно кто-то считает, что накладные расходы от маршалинга и т.п. механизмов языка не позволяют писать на этом языке под DirectX, но это не правда — для наших целей (мы же не собираемся писать крутую 3D игру) быстродействия хватает"... VD>Я не видел этих "многих статей". Зато я точно знаю как работает маршалинг. Лля простых типов используемых в DirectX никакого маршалинга не делается. Если бы это было так, то тот же WPF тормозил бы безбожно, а он летает. И игры бы тормозили, а по факту отличить игру написанную на дотнете от игры написанной на С++ нельзя.
Хы, отличить нельзя просто потому, что ни одной AAA игры на .net не существует в принципе. )))
VD>Ты уж раз утверждаешь что-то, потрудись привести ссылки на эти твои "многие" статьи. И за объясни как же все же работает WPF и те самые игры.
Очень просто. Они работают потому, что существующее железо на порядки превосходит все их потребности. Так что любые их тормоза просто не заметны пользователю. А вот если бы речь шла о задачах близких к пределу производительности современного железа (как это часто бывает в AAA играх), то тут тормоза проявили бы себя во всей красе.
VD>В реальности то что говоришь о маршалинге не соответствует действительности на фоне тех операций, что делает DirectX в видеокарте общение с ним это сущие копейки. И маршалирга там особого нет. Просто сам DirectX мало пригоден для программирования в safe-режиме. Придется переходить на unsafe и тут уже встает вопрос, а "на хрена козе баян?". Потом люди вспомниают, что DirectX прибивает гвоздям твой софт к Винде, и что DirectX это далеко не полный игровой движок. И люди делают здравый вывод, что проще не трахаться с убогим DirectX, а взять готовый движок вроде Юнити. Ну, а раз он уже есть и это много человеколет, то на хрена писать еще один на дотнете? Вот только маршалинг ведь, при взаимодействии с движком, никуда не девается. Но это никого не трогает, так как опять же он ничтожен на общем фоне.
http://code4k.blogspot.ru/2011/03/benchmarking-cnet-direct3d-11-apis-vs.html — на вот, просвещайся. ) И обрати внимание, что самый лучших из .net результатов (всего в 2,3 раза медленнее C++ аналога ) SharpDX использует не P/Invoke, а какой-то там свой полухакерский способ.
_>>Да, и кстати, а тебе не приходило в голову, что MS не предоставляет в .net инструментов работы с DirectX (все соответствующие библиотеки сторонние) не просто так? ))) VD>С DirectX можно работать напрямую. МС вообще нихрена не предоставляет, по большому счету.
Не верно. В далёкие времена существовал отдельно Managed DirectX, но сейчас он deprecated. Т.е. изначально разработка библиотеки была, но потом её в MS прикрыли по причине "The modern version of the DirectX SDK is designed for C/C++ native developers".
VD>Но примеры проектов на дотнете для Direct3D есть прямо в DirectX SDK ([SDKroot]\Samples\Managed\Direct3D\Tutorials). Я их сам запускал много лет назад. Работает, естественно, все быстро. Никаких сказочных тормозов маршалинга не обнаруживается. Скачай — убедись.
Вот, твои примеры относятся как раз этой древности. Кстати, тебе надо было дать скорее такую https://msdn.microsoft.com/en-us/library/windows/desktop/bb318658(v=vs.85).aspx ссылку. Но это всё давным давно сдохло. Сейчас для программирования под DirectX на .net используют или SlimDX или SharpDX — обе сторонние библиотеки-обёртки. И обе тормозят.
_>>Ну если это домыслы, то тогда ты легко опровергнул бы их фактами. Но пока что в данной теме наблюдается обратная ситуация — ты бегаешь от обсуждения конкретных фактов. ))) VD>Домыслы очень трудно опровергнуть. Их можно генерировать тоннами, а чтобы чтобы их провернуть нужно тратить массу времени и усилий. По этому в научном сообществе используется обобранный принцип. Утверждающий обязан сам обосновать свои утверждения. Причем не словами "я читал", а тестами, ссылками, логическими заключениями выводимыми из фактов. VD>Это ты ходишь по форумам и излагаешь озвучиваешь миф. Вот тебе и доказывать, что это не миф.
Вообще то все нужные факты, тесты и т.п. легко находятся в сети. Потому что излагаемые мною вещи для большинства специалистов являются общеизвестными фактами, а не мифами. )))
Здравствуйте, alex_public, Вы писали:
_>Что-то как-то сомнительно, что подобные вещи можно ввести опциями. Вот тот же GC или указатели — это понятно (unsafe в C# по сути это делает). А скажем размещение на стеке (причём по умолчанию), RAII, семантику перемещения, обсуждаемый тут рядом нормальный параметрический полиморфизм и т.п. разве реально включать опциями? )
Вот ввести поддержку GC — это большой труд. А а все описанное тобой без проблем. По сути С++ и был расширением для С. Все его конструкции — "сахар", который препроцессором транслировался в С. Нужно только чтобы конструкции выделяющие данные на стеке отличались от конструкций выделяющих данные в GC-куче. Вводим нечто вроде:
class A { }
manual class В { }
struct C { }
unsafe // нужно для b2
{
def a = A(); // Создался в GC-куче. В a - ссылка.def b1 = B(); // Создался в на стеке. В b - значение.def b2 = new B(); // Создался в куче OS. В b - ссылка. Управлять надо вручную.def b3 = unic B(); // Создался в куче OS. В b - ссылка. Управление автоматическое. Можно иметь только одну ссылку.def b4 = shared B(); // Создался в куче OS. В b - смарт-ссылка. Управление полу-автоматическое (на кострукторах-деструктороах).def c = C(); // Создался в на стеке. В c - значение. Всегда копируется.
} // тут b1, b3 и b4 разрушаются.
Или можно сделать так чтобы чтобы отличались типы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: _>>Что-то как-то сомнительно, что подобные вещи можно ввести опциями. Вот тот же GC или указатели — это понятно (unsafe в C# по сути это делает). А скажем размещение на стеке (причём по умолчанию), RAII, семантику перемещения, обсуждаемый тут рядом нормальный параметрический полиморфизм и т.п. разве реально включать опциями? ) VD>Вот ввести поддержку GC — это большой труд. А а все описанное тобой без проблем. По сути С++ и был расширением для С. Все его конструкции — "сахар", который препроцессором транслировался в С. Нужно только чтобы конструкции выделяющие данные на стеке отличались от конструкций выделяющих данные в GC-куче. Вводим нечто вроде:
код
VD>
VD>class A { }
VD>manual class В { }
VD>struct C { }
VD>unsafe // нужно для b2
VD>{
VD> def a = A(); // Создался в GC-куче. В a - ссылка.
VD> def b1 = B(); // Создался в на стеке. В b - значение.
VD> def b2 = new B(); // Создался в куче OS. В b - ссылка. Управлять надо вручную.
VD> def b3 = unic B(); // Создался в куче OS. В b - ссылка. Управление автоматическое. Можно иметь только одну ссылку.
VD> def b4 = shared B(); // Создался в куче OS. В b - смарт-ссылка. Управление полу-автоматическое (на кострукторах-деструктороах).
VD> def c = C(); // Создался в на стеке. В c - значение. Всегда копируется.
VD>} // тут b1, b3 и b4 разрушаются.
VD>
VD>Или можно сделать так чтобы чтобы отличались типы.
Насчёт выделения на стеке согласен, хотя я бы сделал что-то вроде такого (меньше путаницы):
class A { };
//пишу без автовыведения типов, чтобы были видны используемые типы
{
А a1(); // Создаётся на стеке. В a1 - значение.
unic<А> a2 = unic A(); // Создаётся в куче OS. В a2 - ссылка. Управление автоматическое. Можно иметь только одну ссылку.
shared<A> a3 = shared A(); // Создаётся в куче OS. В a3 - смарт-ссылка. Управление автоматическое (многопоточный счётчик ссылок).
}//тут точно разрушаются a1 и a2. И возможно a3 (если в других местах ссылка уже не нужна)
{
non_del<A> a1= GC.new<T>();// Создаётся в GC-куче. В a1 - ссылка.
non_del<A> a2= my_pool.new<T>();// Создаётся в неком моём пуле. В a2 - ссылка.
req_del<A> a3= new A();// Создаётся в в куче OS. В a2 - ссылка. Управлять надо вручную.
}//здесь никто не уничтожается. Для a3 где-то в программе надо будет вызвать delete
unsafe
{
row_ptr p=0xf0f0f0f0;//и только для такого типа доступна арифметика указателей
non_del<A> a1=row_cast<A>(p);
А a();
p=&а;//а так же возможность взять адрес у большинства типов выше
non_del<A> a2=row_cast<A>(p);
}
А что насчёт введения RAII или семантики перемещения с помощь опций? )
Здравствуйте, DarkEld3r, Вы писали:
DE>Потянуть может и потянул, но злые языки говорят, что Go им нужен чтобы легче "масштабироваться" используя не очень сильных программистов. D (а так же скала, немерле и прочие) эту нишу не закрывает никак.
А зачем было переизобретать велосипед Яву 1.0?
По мне так, любой язык можно использовать ограниченно. Не используй PM, дженерики, и т.п. и получишь Го из любого языка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, DarkEld3r, Вы писали:
DE>А как же Dart? Или игнорируем всё, что не вписывается в схему "бренд решает"?
Брэнд условие необходимое, но не достаточное. Иначе IBM засрал бы Коболом все мозги.
DE>Причём, если мне не изменяет память, Dart продвигался "именно гуглом", в отличии от Go, который позиционируется как детище Пайка.
Ну, вот отличный пример F#. Включили его в коробку с VS, по пиарили и аудитория начала расти хотя как язык он от идела очень был долек.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Продвигался?
Они, имхо, с первых версий Dart не знали что делают: то ли это язык, то ли VM, то ли вообще браузер со своим нестандартным скриптом. То ли дженерики... а что это? Опыт состоявшихся платформ и языков — игнорировали.
А веб головного мозга и вовсе эту концепцию довёл до совершенства:
— язык так себе — от JS с типами ничем не отличается;
— VM — так себе — последний раз когда я смотрел (т.е. давно) — там какие-то прототайп чейны с динамическими лукапами на мембер аксессе а информация о типах заботливо стёрта;
— генерация JS — совсем странная и долго не развивалась;
— на общем фоне — выяснилось, что поддержки в хроме как не было так и не будет — ну и какой смысл тогда? при том, что того же V8 давно хватало с головой.
Такое просто не могло взлететь, несмотря на то, что и тулсет сделали и библиотеку какую-никакую и в свой форк браузера впилили.
Когда посмотрел спустя несколько лет — стало сильно лучше, но зачем оно без поддержки в браузере — так ясно и не стало.
) SharpDX использует не P/Invoke, а какой-то там свой полухакерский способ.
