sample_626
я бы хотел что-то вроде этого: http://habrahabr.ru/post/149866/
Фреймворк имхо позволит писать под все 3 платформы одинаково.


Почему это? Ничто не мешает сделать так, тем более, что в мобильном мире это уже работает.
#77
Кросс-платформенные библиотеки - благо, с помощью MVC можно очень просто развертывать приложения

Про ядра вам уже ответили. Исторически изначально МС и писала "единое ядро", насколько можно понять с их слов. Потом поняли, что в заданные сроки не осилят и стали делать три ветки. Короче и там NT и там, и там.

У WP интерфейс как и у прочих веток - Modern UI (там главное "отличие" в том, что у телефона всё "вертикальное", а у ПК "горизонтальное", ориентация экрана по умолчанию разная) есть ещё декстоп, угу, просто на телефонах то он уж точно нафиг никому не упёрся. И это не вопрос разности интерфейса на разных устройствах, просто в именно в самой винде теперь два разных интерфейса. Принципиально. Декстоп и модерн. Но скоро, скорее чем думает пресловутое большинство, тоже самое большинство перестанут воспринимать это как нечто "разное".

Статья от 20 августа 2012 года, автор даже не знает как работает WP8, только догадывается. У вас на том же уровне всё.

sample_626
http://habrahabr.ru/company/touchinstinct/blog/189060/

Плитка (не смотря на убогий внешний вид) под пальцетык более подходит, чем десктопные мышеориентированные интерфейсы. Ну и, соответственно, под мышь подходит куда меньше (больше лишних движений). Потому и зафейлилась попытка скрестить ужа с ежом, натянуть на десктоп планшетный интерфейс. Особым фейлом было пытаться жто скормить привычным к "классическому" интерфейсу юзерам. Из-за чего спешно и выпускают "голубую" 8.1, которую будут раздавать бесплатно для всех пострадавших от новшеств Win8...


Не может. Разница будет около 1 порядка в производительности нативного кода и кода VM. Если, ессно, виртуалку не адаптировать к одной-единственной процессорной архитектуре...


Жесткое разграничение привилегий (вплоть до выделения отдельной "песочницы" для каждого приложения) - что, не наш метод? Ах да, забыл, могут поиметь при этом через дыры в коде, тестированием-то особо не занимаются, главное же продукт побыстрее выпустить


Угу, а ресурсоемкий софт пускай работает раз в 10 медленнее, чем на такой же платформе без ненужной прослойки
Как думаете, зачем на андроиде NDK сделали?

Может. По крайней мере лучшие умы теоретического программирования этим занимаются.
http://habrahabr.ru/post/149866/

Ускорить, урезав контроль за переполнениями и т.п. и сведя .net к некой вариации С++ с промежуточным кодом?

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

NiTr0 C++ избыточен. Это очень просто выяснить: можно знать "Весь C# (то есть знать классы на все случаи жизни (хотя бы название) + всевозможные варианты синтаксических конструкций), а вот "Весь С++" знать невозможно в принципе. В общем об этом в статье и говорится.

Переписывание узких мест на С/С++ - это стандартная практика. Но хотелось бы иметь это "из коробки". А то с этими PInvoke не очень уютно.

Алсо теоретически верхняя граница managed-языков намного выше, чем unmanaged, просто теория пока расходится с практикой. Но у теории есть одно свойство: она обязательно становится практикой, пусть даже с задержкой. Про ООП тоже сначала говорили, что это ненужное тормознутое гавно, которе жрет по 4 лишних байта на каждый объект, и страшные тормоза при вызове виртуальных методов, которому место на помойке, и на котором никто писать не будет. Прошло 50 лет, ситуация немного изменилась, на ASM/C почти никто не пишет...

sample_626
в который раз убеждаюсь, что громче всех орут о тупом .Net те, кто круче змейки на С++ ничего не писал. А еще чаще те, кто в школе проходил helloworld на бейсике и с тех пор не вырос.

Тот же MvvmCross позволяет писать один код на дохрена+ платформ, остается только допилить UI, при том, что весь BL будет один, а BL и есть основная часть любого приложения.

Знать все классы говорите? Ну-ну...
С тем же успехом можно "знать все классы" С++, идущие в комплекте определенного компилятора/фреймворка...
Вот только


Откуда такой вывод? Исполнение байт-кода на виртуальной машине в любом случае медленнее исполнения на реальном проце.


Пишут, пишут. На асме под х86 - да, мало (ввиду развития компиляторов и роста вычислительных мощностей), а вот С - используется весьма активно. То же ядро линукса со всеми драйверами - никаких С++.

С кем вы вообще разговариваете?
Я просто указал на то что статья на которую вы ссылались устарела на год, и то, о чём там мечтается или что называется "неподтверждёнными данными", уже давно работает.
На WP портированы с iOS несколько крупных игрушек, Навител это подпёртая костылищами версия еще с WM, которую никто не переписывал, но её удалось запустить каким-то образом.
W8 и WP8 постепенно обмениваются софтом, W8 ARM и W8 x86 маркеты почти идентичны.
А вам мало совместимости.

sample_626 а кнут устарел лет на 30. А быстрая сортировка вообще придумана была в каком-то там мохнатом году..

Конечно мало. Остановиться в развитии есть смерть.

Порядок это для полного хаков и ручных оптимизаций кода против толстой VM.

Подавляющее число современного софта от JIT компилируемого байткода для VM отличает только одно: применяемый компилятор.
Пишут сам софт примерно одинаково, применяя многочисленные средства автоматизации и с набивкой текста дело имея только по вопросам функционала. Уж чего, а кусков низкоуровневого кода никто не вставляет. Существенность же разницы же между JIT и "полновесными" компиляторами только вопрос времени.

Отнюдь. Банальная игра порядком следования инструкций в компиляторе, генерящем машинный код, может дать 2-кратный прирост. Да-да, соберите в gcc что-то с -march=i486, а потом - c -march=i486 -mtune=pentiumII , разница в скорости будет достигать 2 раз при использовании одного и того же набора инструкций.
Далее, JIT отнюдь не будет разворачивать циклы и т.п., к примеру, при побайтовом копировании строки известной длинны С++ бует копировать dword/qword'ами вс, потом -хвостик что не влез; JIT - сомневаюсь что будет такие трюки делать. Статическая прекомпиляция в байт-код - возможо, но как быть с неведомой на данном этапе длинной слова?
Далее, как быть с SSE и т.п. если приложение скомпилено в байт-код? Ой сомневаюсь, что малой кровью удастся его оптимизировать, а компилить JIT с полчаса тот же офис перед запуском (если делать полноценную компиляцию вместо упрощенной) - это будет весьма печально.
Далее, проверки границ массивов при доступе и т.п. рюшечки managed кода (которые, впрочем, и в расширения С++ типа Qt framework, где вместо массивов пришли списки, есть) жрут реально много ресурсов. Если от них отказаться - получаем тот же С++ вид сбоку, со всеми прелестями типа переполнения стека. Но зато с нескучным костылем в виде промежуточного байт-кода, который единственное, что будет делать - создавать дополнительные тормоза.

Вот-вот, офис, где 95% всего кода - высокоуровневые вызовы системных API.
И что в этих вызовах оптимизировать, какая разница, на яве они или в машинном коде? Он не цвета пикселей по одному считает, а заказывает системной оболочке создать окно. Скорость операций будет определяться как раз системной оболочкой.

Уж не говоря о том, что если почистить чуток лишнее и переписать нужный 99.9% функционал, будет куда шустрее последнего, несмотря на весь его машинный код.

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



Ты смотришь не с той стороны.
Все наоборот. Не VM отказываются от managed кода, а компилированные программы от традиционного.
На классическом си не пишется уже почти ничего, чистый c++ ограничен отдельными разработчиками, подавляющее число софта чуть менее чем полностью основано на тех самых "рюшечках" и автоматитически генерируемом коде.

А если нет разницы, зачем тащить больше? Задача системы дистрибуции - донести плод труда программиста от него до конечного юзера. Когда этот труд состоит из управления высокоуровневой средой разработки, а не упражнений с нативным кодом, то должна соответствовать и форма. Даже байткод является полумерой.

Грубо говоря, если я написал программу, которая выводит стандартное окно с надписью "Привет Вася", то идеальная форма этой программы Все остальное - мусор. Отходы производства. Если программист сам не копался в конкретных указателях и переменных, требуемых для создания этого окна, то их нет никакого смысла таскать вместе с программой. Результат работы компилятора легко воспроизводим.

NGen в помощь. Теоретически managed код не медленнее нативного, а верхний предел - намного больше. И теория имеет одно забавной свойство: становиться практикой

уже не один раз писал, и еще разочек повторю:

Кто вам такое сказал? Словари, правописание, вычисления в экселе, эксесс - что, голые вызовы API?


Особенно проверки правописания


Угу. Надо человеку открыть документ, закачал из маркета офис, и запускает его полчаса если не более... Вышел новый апдейт - опять полчаса на запуск... Еще и место куда-то утекать катастрофически начинает - кеши-то при удалении не чистятся...


Угу, угу. Примеры драйверов на с++ в студию.


Как раз таки нет..


Хоть один популярный игровой движок, юзающий дотнет, в студию. Или хоть один медиакодек. Или хоть одну СУБД. Что, нет таких?


Не спорю, если задача системы - нарисовать окошко, можно и на яваскрипте писать. Вот только когда программа реально перемалывает огромную кучу данных, и при этом выполняет операции сложнее, чем "взять из ячейки А и положить в ячейку Б" - тут уже становится пофиг на то, как удобнее разработчику. Ибо если переписывание с managed платформы на хороший, годный компилируемый язык составит несколько сот % (а особенно - если конкуренты в спину дышут) - то программерам скажут засунуть свои привычки и удобства куда подальше, и написать быстрый код. И пофиг, что вместо недели, затраченной на managed прототип, написание растянется на несколько месяцев.


Воспроизводим-то легко. Но времени на воспроизведение может потребоваться поболее суток, если тот же хромиум компилить на старой одноядерной машине, ну или на нетбуке/смартфоне... Есть желающие столько ждать?


Повторюсь. Медленнее. Из-за обязательных проверок на лету границ массивов, длины строк, преобразования типов перед вызовом ф-й API и т.п. Это есди даже не используется виртуальная машина, а код компилится напрямую в нативный. Без всех этих проверок - никакого managed не получается, имеем c++ вид сбоку, с никакой изоляцией системы от managed кода (ибо stack overflow позволит вызвать любую ф-ю API).

NiTr0 почитайте Clr via C#, много нового узнаете.



в самом худшем варианте С++ быстрее того же шарпа не более ,чем в 2 раза. В среднем - 10-30%. Про какие сотни % тут вопрос - если только про эти самые "перегнать в бенче из А в Б миллиард раз".


Unity

http://forum.ixbt.com/topic.cgi?id=26:40671
без прыжков с ужимками (тупой код, без инлайнов и unsafe, максимум - с отказом от условных переходов) - имеем где-то 3-кратное различие по скорости. Сравнивать с SSE2-оптимизированным кодом - вообще не стоит

И да, в 64бит C# имеет худшую производительность, чем в 32бит. У С++ приложений, перекомпилированных под 64бит, производительнотсь только растат (тот же xvid 64бит, к примеру, у меня в свое время показывал +80% производительности под 64бит)

И да, http://www.rsdn.ru/forum/flame.comp/2720100.1 - тут на банальном перемножении матриц дотнет слился на порядок. Тесты есть, можете проверить

Если бы даже полчаса - какая разница, тратит он их на установку программы или на компиляцию?

Только на самом деле все еще проще. Можно по-прежнему компилировать код в мгновенном режиме, как делается сейчас JIT компиляторами. Часть кода все равно так компилируется, в частности созданный в процессе работы (runtime generated code). Если же софт прямо сейчас не требуется, оптимизировать его фоновым процессом пост-инсталла.



Мы все еще об офисе? Ну давай об офисе.

Математика в офисе, т.е. экселе и акцесе, как она выполняется сейчас - крайне тормозной процесс. Обрабатывается она чистым интерпретатором и строго последовательной вычислительной программой. Скорость легко проверить. Там разрыв не на порядок от C99, а в сотни и тысячи раз.

Математика в офисе, как она может работать на виртуальной машине - runtime generated code. Вся математика на листах читается JIT компилятором и превращается в набор исполнимых сегментов. Не заоптимизированных до дыр в двадцатилетнем коде, но компилированных, и потому выполняемых с адекватной производительностью.



Байткод JVM - это не высокоуровневый ветвистый код с сотнями библиотек и перекрестных ссылок, а очень компактный, близкий к нативному C, уже обработанный и сведенный к конечному алгоритму код.

Подавляющее количество времени компилятор тратит не на перевод готового алгоритма из базовых функций C в машкод, а на дешифровку и развертывание красивых высокоуровневых конструкций в конкретную последовательность действий.