Здравствуйте, WolfHound, Вы писали:
WH>Например хардкод опкодов типа add, sub итп в систему команд .НЕТ привел к тому что создание аналога std::valarray из C++/STL невозможно.
Два вопроса:
1. Как это должно было быть реализовано? Я с наскока могу предложить только крайне извращённый способ — JIT заменяет op_Addition и co для встроенных типов, для всех остальных — просто вызов методов. Очевидно, вы имели в виду более юзабельный вариант.
2.А нафига иметь даже потенциальную фозможность переизобрести строку, массив etc? Точнее — пущщай оно будет, но зачем затачивать рантайм под такие крайне редкие юз-кейзы?
WH>Очень слабая система типов. Например нельзя сделать безопасный доступ без рантайм проверки к элементам массива даже если я могу доказать что индекс никогда не выйдет за приделы массива.
unsafe. Потому что с точки зрения рантайма вы занимаетесь колдунством и следовательно, он не может верифицировать IL. Без верификации мы легко получим кучу дыр в как бы безопасном коде.
Как вариант, можно предусмотреть синтаксический сахар, но внутри всё равно будет небезопасная операция.
WH>Отсутствие неизменяемых типов данных.
Если требуется — реализуется за пару часов проверкой при компиляции. Ради спортивного интереса делал рабочий прототип правила для FxCop пару лет назад. На практике оказался малополезен, т.к. большинство типов-значений можно упихнуть в структуры, а они по соглашению immutable.
WH>Отсутствие безопасных http://en.wikipedia.org/wiki/Tagged_union
FieldOffsetAttribute. Потому что в 90% случаев рантайм не сможет гарантировать валидность подобных структур. Для редких частных случаев вполне можно организовать проверку самописным правилом.
WH>Отсутствие структурных типов, что приводит к невозможности создания нормальных кортежей.
Есть тюплы, не хватает только синтаксического сахара для них. Почему тюплы — не struct разжёвывалось неоднократно, если коротко — структура с 3 и > полями будет дороже при передаче в качестве аргумента.
WH>Совершенно дебильные соглашения о вызовах и отсутствие хвостовой рекурсии. То что есть работает так что лучше бы не было.
Ну вот зачем так подставляться? tail.-префикс присутствует со 2го рантайма. Если не устраивает — могу поискать нормальный пруф.
Что характерно, все претензии никак не соотносятся с исходным утверждением — ".НЕТ быстрым быть не может."
Здравствуйте, Sinix, Вы писали:
S>1. Как это должно было быть реализовано? Я с наскока могу предложить только крайне извращённый способ — JIT заменяет op_Addition и co для встроенных типов, для всех остальных — просто вызов методов. Очевидно, вы имели в виду более юзабельный вариант.
Именно так.
И это самый прямой метод.
Почему ты называешь его извращенным не ясно.
Ибо JIT ну совершенно без разницы что знать в лицо опкод add или метод op_Addition
S>2.А нафига иметь даже потенциальную фозможность переизобрести строку, массив etc? Точнее — пущщай оно будет, но зачем затачивать рантайм под такие крайне редкие юз-кейзы?
Это нужно для того чтобы можно было писать обобщенный код.
Попробуй, создай аналог std::valarray на генериках .НЕТ.
S>unsafe. Потому что с точки зрения рантайма вы занимаетесь колдунством и следовательно, он не может верифицировать IL. Без верификации мы легко получим кучу дыр в как бы безопасном коде.
Это только тебе кажется что unsafe.
А когда я говорю доказать я имею в виду доказать.
Иди читай про type refinements
И только не говори что это ни кому не нужно.
У меня полно кода, где это не только нужно, но и очень легко доказывается.
S>FieldOffsetAttribute. Потому что в 90% случаев рантайм не сможет гарантировать валидность подобных структур. Для редких частных случаев вполне можно организовать проверку самописным правилом. Ой лол.
Не путай кривущий рантайм .НЕТ и рантайм вообще.
S>Есть тюплы, не хватает только синтаксического сахара для них.
А теперь попробуй передать анонимный тип с именованными полями из одной сборки в другую.
S>Почему тюплы — не struct разжёвывалось неоднократно, если коротко — структура с 3 и > полями будет дороже при передаче в качестве аргумента.
А это еще одна проблема не дающая нормально работать.
Имея неизменяемые структуры рантайм сам может решать делать и value или ref в зависимости от их реального размера.
S>Ну вот зачем так подставляться? tail.-префикс присутствует со 2го рантайма. Если не устраивает — могу поискать нормальный пруф.
Ты вообще читаешь, что я пишу?
Ты знаешь с какой скоростью начинает работать код?
А я знаю. Измерял и плакал.
Хотя хвостовой вызов должен быть как минимум не медленней обычного.
А знаешь по чему? А по тому что CAS.
А CAS появился из-за того что мелкософт не осилил CBS.
S>Что характерно, все претензии никак не соотносятся с исходным утверждением — ".НЕТ быстрым быть не может."
Что характерно все претензии к моим претензиям исходят из недостатка образования.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, yoriсk.kiev.ua, Вы писали:
CC>>Т.е. если я сейчас хочу писать кроссплатформенное приложение, то у меня особого выбора и нет, всё больше получается C++ для ядра и местный фреймворк для графики. YKU>А мужики-то не знают. Вот эти к примеру: http://habrahabr.ru/blogs/gdev/117564/
Что смотреть? Примитивный платформер, его хоть на HTML5 скоро можно писать будет.
Здравствуйте, WolfHound, Вы писали:
WH>Именно так. WH>Почему ты называешь его извращенным не ясно.
Ок, понял что имелось в виду. Раз уж мы хотим вызывать в генериках операторы op_***() (а иначе никак), то разумно использовать тот же синтаксис и для встроенных типов. В принципе, можно не ломать совместимость и добавить костыль для arithmetic-генериков — всё равно для каждого value-типа jit генерит свой код. Но криво, да
S>>unsafe. Потому что с точки зрения рантайма вы занимаетесь колдунством и следовательно, он не может верифицировать IL. Без верификации мы легко получим кучу дыр в как бы безопасном коде. WH>Это только тебе кажется что unsafe. WH>У меня полно кода, где это не только нужно, но и очень легко доказывается.
Я пока не убеждён, что это настолько общий случай, что окупит переработку рантайма, но спорить не буду.
S>>FieldOffsetAttribute. Потому что в 90% случаев рантайм не сможет гарантировать валидность подобных структур. Для редких частных случаев вполне можно организовать проверку самописным правилом. WH>Не путай кривущий рантайм .НЕТ и рантайм вообще.
Ок, какой рантайм может предложить достаточно общее решение без неприятных последствий?
S>>Есть тюплы, не хватает только синтаксического сахара для них. WH>А теперь попробуй передать анонимный тип с именованными полями из одной сборки в другую.
Анонимный тип и tuple — это разные вещи, не?
S>>Почему тюплы — не struct разжёвывалось неоднократно, если коротко — структура с 3 и > полями будет дороже при передаче в качестве аргумента. WH>А это еще одна проблема не дающая нормально работать. WH>Имея неизменяемые структуры рантайм сам может решать делать и value или ref в зависимости от их реального размера.
Это породит кучу неприятных сюрпризов, начиная с граблей с бинарной совместимостью и object.ReferenceEquals, которые внезапно поломаются при расширении структуры.
S>>Ну вот зачем так подставляться? tail.-префикс присутствует со 2го рантайма. Если не устраивает — могу поискать нормальный пруф. WH>Ты вообще читаешь, что я пишу?
Да, читаю.
WH> отсутствие хвостовой рекурсии
И как я должен догадаться, что отсутствие == тормоза?
WH>Ты знаешь с какой скоростью начинает работать код?
Нет — хвостовая рекурсия мне ни разу не потребовалась.
WH>А знаешь по чему? А по тому что CAS.
А можно пруф?
WH>Что характерно все претензии к моим претензиям исходят из недостатка образования.
Вам посраться или пообщаться? Если первое — беру самоотвод, если второе — поумерим тон?
Здравствуйте, Sinix, Вы писали:
S>Я пока не убеждён, что это настолько общий случай, что окупит переработку рантайма, но спорить не буду.
Ну ты статьи то почитай.
Это на самом деле чуть меньше чем 100% кода.
Причем доказательства не только скорость дают, но и делают не нужными юнит тесты.
S>Ок, какой рантайм может предложить достаточно общее решение без неприятных последствий?
Чуть меньше чем все функциональные языки, которые компилируются в нативный код.
S>Анонимный тип и tuple — это разные вещи, не?
В .НЕТ да. А по жизни нет.
Я же говорю .НЕТ кривой.
S>Это породит кучу неприятных сюрпризов, начиная с граблей с бинарной совместимостью
С бинарной совместимостью чего?
Код компилируется внутри домена.
Так что никаких проблем.
S>и object.ReferenceEquals, которые внезапно поломаются при расширении структуры.
Почему внезапно? Если хочешь object.ReferenceEquals то скажи что тип Reference.
Если не сказал, то не будет ни какого object.ReferenceEquals.
А учитывая, что ReferenceEquals нужен очень редко...
WH>>Ты знаешь с какой скоростью начинает работать код? S>Нет — хвостовая рекурсия мне ни разу не потребовалась.
А мне требовалась.
WH>>А знаешь по чему? А по тому что CAS. S>А можно пруф?
Давно читал где-то.
Да и с чего оно так тормозить то может если не из-за этого?
Ибо если это не объяснение причин, то тогда можно смело заявить что мелкософта полные ламеры. Ибо это тривиальная оптимизация, которую сделать не правильно просто не реально.
WH>>Что характерно все претензии к моим претензиям исходят из недостатка образования. S>Вам посраться или пообщаться? Если первое — беру самоотвод, если второе — поумерим тон?
А кто первым начал?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>Причем доказательства не только скорость дают, но и делают не нужными юнит тесты.
Пардон, я просто не успеваю за мыслью: начали с очень узкой фичи, и внезапно перешли к статической верификации кода. Лично я всеми конечностями за. Увы, мейнстрим-реализация от МС — code contracts — оччень малопрактична, но у них в загашнике есть Verve OS (по ссылке — pdf).
S>>Ок, какой рантайм может предложить достаточно общее решение без неприятных последствий? WH>Чуть меньше чем все функциональные языки, которые компилируются в нативный код.
Так, я по-прежнему торможу — почему-то не узнал в лицо атд и тут целиком и полностью неправ
S>>Анонимный тип и tuple — это разные вещи, не? WH>В .НЕТ да. А по жизни нет.
Ну так мы обсуждаем решения в .net И да, мне самому не нравится как в шарпе реализованы анонимные типы.
S>>Это породит кучу неприятных сюрпризов, начиная с граблей с бинарной совместимостью WH>С бинарной совместимостью чего?
Сборок. У нас есть ABI аля SomeMethod(SomeVal val). После очередной правки SomeVal внезапно становится ref-типом — или перекомпилируем весь код, или ловим исключения в рантайме. Это можно обойти, но придётся явно вводить classorstruct-типы, т.е. одними изменениями в компиляторе не обойтись.
WH>>>А знаешь по чему? А по тому что CAS. WH>Да и с чего оно так тормозить то может если не из-за этого?
Действительно нашёл пруф и там ссылаются на ту же статью, что я приводил в первом посте.
Заодно нашлась заметка про оптимизации tailcall в .NET 4/
WH>А кто первым начал?
Я? Тогда пардон и спасибо!
Здравствуйте, Sinix, Вы писали:
S>Пардон, я просто не успеваю за мыслью: начали с очень узкой фичи, и внезапно перешли к статической верификации кода. Лично я всеми конечностями за. Увы, мейнстрим-реализация от МС — code contracts — оччень малопрактична, но у них в загашнике есть Verve OS (по ссылке — pdf).
С вероятностью 99.9999% там оно и останется.
Не слушает мелкософт свой ресерч.
WH>>В .НЕТ да. А по жизни нет. S>Ну так мы обсуждаем решения в .net И да, мне самому не нравится как в шарпе реализованы анонимные типы.
Ну да. Я говорю .НЕТ жутко крив.
Ты вроде начал спорить но теперь со всем соглашаешься
S>Сборок. У нас есть ABI аля SomeMethod(SomeVal val). После очередной правки SomeVal внезапно становится ref-типом — или перекомпилируем весь код, или ловим исключения в рантайме. Это можно обойти, но придётся явно вводить classorstruct-типы, т.е. одними изменениями в компиляторе не обойтись.
Так я сразу говорил рантайм .НЕТ крив.
S>Заодно нашлась заметка про оптимизации tailcall в .NET 4/
Всеравно тормозит.
Хвостовой вызов должен быть в самом худшем случае таким же по стоимости как простой вызов.
Но обычно он должен быть дешевле.
Ибо это обычный goto.
А если еще и аргументы передавать через регистры, а не через стек то там производительность как у обычных циклов должна быть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ikemefula, Вы писали: I>Здравствуйте, Silver_S, Вы писали: S_S>>Почему тормозит WPF. Виноват скорее всего не .NET, а кривой milcore.dll, который на С++ написан.
I>А ты загляни во внутрь, там столько оверхеда, что некуда деваться.
В самом WPF или у milcore тоже доступны исходники?
В WPF конечно тоже оверхеда должно быть достаточно. Если они там так активно с Dispatcher взаимодействуют, чуть ли не на каждом вызове метода у Dispatcher спрашивают из правильного потока вызов. И с Freezable тоже...
Но тормоза кажется именно из-за самой milcore. Неправильно они все сделали.
Надо было так: первый слой это просто окно в котором лежит D3D девайс, вместе с D2D, готовые к работе и с заплатанными косяками. Хотябы только заплатки на косяки описанные в MSDN. И плюс Application (очередь сообщений и подобное).
Как ни странно, даже это сделать не так просто сделать. Sample набрость минутное дело, но сложнее если надо без косяков и кривостей при Resize, переключнии режимов полноэкранный/оконный, ....
Для первого слоя все, больше ничего не надо, никаких медиа интегрейшен.
Поверх него уже писать WPF, а кому надо, будет напрямую использовать в обход WPF.
Никкаких API на C++, COM тут не надо, полноценный managed API — ну нету у D3D функций которые надо быстро и часто вызывать, все данные в байтовых массивах подаются. Даже у D2D вызывать всякие DrawLine, почти без оверхеда — все очень быстро работает.
С++, COM программеров нельзя и близко подпускать к дизайну такого API. Они там наделают.
Вот как можно назвать такой паттерн, используемый в DX10 API ?: взять несколько разных объектов, с разным набором функций(методов). Соединить в один интерфейс, тип объекта указывать при создании. А методы этих объектов свалить в кучу, если вызовется несоответствующий метод выбрасывать Exception. Ну сэкономили они несколько записей об интерфейсах в реестре. Может тогда COM тут не нужен? У программера привыкшего к .NET рука бы не повернулась такого сделать.
WPF надо было начинать с полноценного Managed DX (а не оберткой вокруг кривого COM API).
Или если надо сразу два варианта. Только потом всякие XNA для XBox. Раз у всех Винда от MS, MS и должны этим заниматься.
Здравствуйте, Silver_S, Вы писали:
S_S>WPF надо было начинать с полноценного Managed DX (а не оберткой вокруг кривого COM API).
Соглашусь. Стоило начать с более навороченной, векторной ГУИ либы, на замену GDI+. А так, мы имеем две технологии для создания GUI на .Net, которые трудно совмещать, но у каждой есть различные, зачастую непересекающиеся с другой, достоинства. На GDI быстрее рисовать, но трудно компоновать. На WPF гораздо удобнее компоновать, но хардкорный рендеринг медлителен.
Здравствуйте, FR, Вы писали:
VD>>Ваше мнение!...
FR>Наверно не последнюю роль в этом ренессансе сыграло то что будущая Win 8 должна работать на маломощных устройствах с ARM процессорами.
Да вообще ARM в т.ч. на мобайл-платформах сильно подгадили менеджед-разработке.
Ой лол.
Если первое — беру самоотвод, если второе — поумерим тон?
Тогда пардон и спасибо
